On ne vend pas de l'IA. On résout des problèmes d'affaires.

Un jeudi ensoleillé d'été, Spiria a organisé son premier hackathon entièrement consacré au développement agentique. Concrètement, le but était de créer une solution en utilisant le développement agentique (aussi connu comme IA agentique), une technologie pouvant concevoir des systèmes d'intelligence artificielle (IA) capables d'exécuter des tâches de bout en bout de manière autonome (analyser, décider, agir et itérer) sans intervention humaine constante.

Tout le monde y a participé. Que leur expertise soit en développement logiciel, en finance ou en design UX/UI, l’événement a réuni l’entièreté de l'équipe à travers le Canada. D’un de nos bureaux ou de la maison, chaque personne a choisi de développer un des 11 outils proposés, tous conçus pour répondre à des besoins réels liés aux opérations de Spiria.  

Les participantes et participants formaient une dyade avec un outil comme Codex, Claude Code ou GitHub Copilot, et avaient le soutien d’une équipe de coachs internes, des personnes ayant déjà développé une expertise avec l’agentique.  

Cette expérience a confirmé une chose : le développement agentique transforme déjà la façon dont les logiciels sont conçus et réalisés.

‍

Pourquoi faire ça?

Croyez-le ou non, être le PDG d’une compagnie de développement logiciel à l’ère de l’intelligence artificielle, surtout avec la croissance de l’agentique, ça brasse les affaires. Mais, être passionné de programmation et en avoir fait un métier c’est, pour plusieurs autres personnes passionnées comme moi, encore plus confrontant.

Je développe encore beaucoup pour le plaisir et pour l’interne chez Spiria, mais je ne connais bien évidemment pas toutes les technologies logicielles qui existent. Quand l'agentique est devenue plus sophistiquée, je savais que je devais l’essayer moi aussi en utilisant des technologies que je connais moins.  

J'ai d’abord testé Codex pour développer un outil interne pour mes collègues dans le département Culture et talents et, en quelques heures, dans une technologie que je ne maîtrise pas du tout, j’ai créé un prototype fonctionnel. J’ai immédiatement compris qu’il était temps pour moi de changer ma façon de programmer. Je ne peux plus me contenter de faire uniquement ce qui m’apportait tant de plaisir intellectuel; il m’appartient maintenant de trouver d’autres sources de stimulation.

La réalité est que les quatre dernières décennies ont été remplies de révolutions qui ont simplifié ma vie de développeur. Ici, l'agentique change mon quotidien complètement. Je savais que toute l’équipe devait vivre l’expérience par eux-mêmes pour comprendre, et l’apprendre.  

‍

Au-delà de la génération de code

Les outils d’IA ont longtemps été perçus comme des assistants capables de rédiger quelques lignes de code, de compléter une fonction ou de rappeler la syntaxe d’un langage de programmation.

Les agents actuels vont beaucoup plus loin.

Ils peuvent analyser une base de code, modifier plusieurs fichiers, exécuter des tests, repérer des erreurs, proposer une architecture, générer de la documentation et participer à des cycles complets de développement.

Cela ne signifie pas que l’expertise humaine devient moins importante. Au contraire, elle change de rôle et devient encore plus déterminante.

Un agent peut produire du code rapidement. Il ne comprend toutefois pas, à lui seul, les priorités d’une organisation, les contraintes propres à un secteur, les risques opérationnels, les exigences de sécurité ou les conséquences à long terme d’une décision technologique.

C’est précisément à cet endroit que l’expertise d’une équipe expérimentée prend toute sa valeur.

‍

Nos clients ne cherchent pas simplement la nouveauté

La majorité de nos clients ne nous demandent pas d’utiliser une technologie simplement parce qu’elle est récente ou populaire.

• Ils veulent avant tout que leur solution fonctionne.

• Ils veulent qu’elle soit sécuritaire.

• Ils veulent qu’elle soit maintenable.

• Ils veulent pouvoir la faire évoluer.

• Ils veulent éviter de dépendre d’un prototype fragile, d’un fournisseur unique ou d’un choix technologique qui deviendra rapidement un problème.

‍

Le développement agentique ne change pas ces attentes fondamentales. Il augmente plutôt notre capacité à y répondre plus rapidement.

Utilisés correctement, les agents peuvent réduire le temps consacré aux tâches répétitives, accélérer la production de premières versions, faciliter l’exploration de plusieurs avenues techniques et améliorer certains processus de validation.

Ils permettent également à nos équipes de consacrer davantage de temps aux aspects qui demandent le plus de jugement : comprendre le problème, définir la bonne architecture, protéger les données, gérer les compromis, assurer la qualité et préparer l’avenir.

‍

La vitesse ne suffit pas

Il serait facile de réduire le développement agentique à une promesse de productivité.

Produire plus rapidement est utile, mais ce n’est pas suffisant.

Un logiciel livré rapidement, mais difficile à maintenir, mal sécurisé ou mal adapté aux besoins réels, demeure un mauvais investissement.

La valeur du développement agentique dépend donc de la façon dont il est encadré.

Il faut définir clairement les responsabilités des agents, contrôler les outils et les données auxquels ils ont accès, valider leurs décisions, maintenir des normes de développement rigoureuses et intégrer leur utilisation aux pratiques existantes d’assurance qualité et de cybersécurité.

Il faut aussi éviter de confondre vitesse de génération et vitesse de livraison.

Le code ne représente qu’une partie du travail. Il faut encore comprendre les besoins, gérer les dépendances, tester les scénarios critiques, préparer le déploiement, documenter les décisions et assurer la continuité de la solution.

Le développement agentique devient réellement intéressant lorsqu’il s’intègre à l’ensemble de cette chaîne de valeur.

‍

Une nouvelle façon de mobiliser notre expertise

Chaque avancée technologique nous a permis de nous concentrer sur des problèmes plus complexes.

Les langages de haut niveau, les bibliothèques logicielles, les cadres de développement, les services infonuagiques et les outils d’automatisation ont progressivement éliminé une grande quantité de travail manuel.

Le développement agentique s’inscrit dans cette continuité, mais son impact pourrait être encore plus important.

À mesure que les agents prendront en charge une plus grande part de la production technique, la valeur se déplacera vers la capacité à bien les orienter, à évaluer leurs résultats et à intégrer leur travail dans des systèmes cohérents.

Il faudra toujours définir les bons besoins, choisir les bons paradigmes, établir les bonnes contraintes et s’assurer que les différentes composantes fonctionnent ensemble.

Il faudra toujours comprendre les utilisateurs, les opérations, les risques et les objectifs d’affaires.

C’est là que se trouve l’expertise de Spiria.

‍

Ce que Spiria apporte au développement agentique

Notre rôle n’est pas simplement de brancher un outil d’IA à un projet et d’espérer qu’il produise un résultat satisfaisant.

Nous aidons nos clients à déterminer où l’agentique peut réellement créer de la valeur.

Nous pouvons l’utiliser pour accélérer la conception d’un prototype, moderniser une application existante, automatiser certaines tâches, soutenir les équipes de développement, améliorer les essais ou explorer plus rapidement différentes solutions.

Mais nous le faisons avec la même rigueur que celle que nous appliquons à tous nos projets.

Cela signifie notamment de porter une attention particulière à l’architecture, à la sécurité, à la confidentialité, à la qualité du code, à la maintenabilité, à l’observabilité et à la pérennité des solutions.

Cela signifie aussi de choisir le bon niveau d’autonomie.

Dans certains contextes, un agent peut exécuter des tâches de manière très autonome. Dans d’autres, il doit proposer des actions qui seront révisées et approuvées par une personne.

‍

Transformer l’expérimentation en valeur durable

Notre hackathon nous a permis d’expérimenter rapidement, de confronter nos hypothèses et de mieux comprendre les capacités réelles des outils actuels.

Il nous a aussi rappelé qu’une démonstration impressionnante n’est que le point de départ.

Le véritable travail consiste à transformer cette capacité en solutions fiables, sécuritaires et durables.

C’est exactement ce que nos clients attendent de nous.

Le développement agentique ouvre la porte à de nouvelles façons de créer des logiciels. Il peut nous aider à aller plus vite, à explorer davantage et à consacrer plus d’énergie aux décisions qui comptent vraiment.

Mais sa valeur ne repose pas uniquement sur la technologie.

Elle repose sur l’expertise des personnes qui savent comment l’utiliser, comment l’encadrer et comment l’intégrer à une vision à long terme.

C’est ainsi que Spiria entend aborder le développement agentique : avec curiosité, avec pragmatisme et avec la volonté de bâtir des solutions qui fonctionnent aujourd’hui et qui continueront de fonctionner demain.
‍

Et vous... Comment votre entreprise aborde-t-elle l'IA agentique ?

Il fut un temps où intégrer l'industrie du logiciel ressemblait moins à une simple arrivée. C'était un peu plus comme une rentrée scolaire dans une toute nouvelle école.

Après des années d'apprentissage académique, devenir développeur(euse) logiciel ne signifiait pas qu'on « savait » enfin tout de notre métier. En fait, ça signifiait qu'on avait gagné le droit de commencer à apprendre autrement. On entrait comme junior. On écoutait. On respectait les personnes qui avaient déjà passé des années à « déboguer » des systèmes en production, à concevoir des intégrations fragiles, à se remettre de mauvaises abstractions et à apprendre quelles idées élégantes survivaient au contact des utilisateurs.

L'expérience ne se mesurait pas seulement en années passées au sein d'une entreprise. Elle se mesurait à la profondeur de notre compréhension, à notre jugement dans l'incertitude et à notre capacité de transmettre du savoir. Les jeunes développeur(euse)s cherchaient des mentors avec l'intensité que les influenceur(euse)s des réseaux sociaux modernes cherchent la viralité et des abonné(e)s. Le métier avait une forme de caractère sacré, parce que le travail exigeait de l'humilité.

Postuler pour un poste de développement logiciel supposait qu'on comprenait à la fois l'art et la science du métier. On était censé connaître, ou du moins être en train d'apprendre activement, les fondamentaux : TCP/IP, l'équilibrage de charge, l'indexation des bases de données, les arbres, les graphes, les tables de hachage, les algorithmes de tri et de recherche, la notation Big O, le ramassage de miettes, le « multithreading », la concurrence, la gestion de la mémoire, les patrons de conception, les principes SOLID, les stratégies de test, les techniques de réusinage (refactorisation), et le jugement difficile de savoir quand ne pas utiliser l'astuce brillante qu'on venait d'apprendre.

C'était aussi l'époque où l'autocomplétion était ce qui se rapprochait le plus d'un copilote. Face à un problème complexe, entre collègues, il était coutume d'aller prendre un café et d'en discuter et de, parfois, perdre des heures dans la mauvaise direction.

Aujourd'hui, notre environnement change. L'intelligence artificielle (IA) n'a pas rendu les fondamentaux caducs. Elle les a plutôt rendus pas mal plus faciles à contourner.

Un(e) développeur(euse) peut désormais demander à un outil d'IA d'expliquer un protocol TCP, de générer une migration de base de données, de suggérer des index, d'écrire des tests, de refactoriser une classe, de résumer du code inconnu ou d'esquisser une fonctionnalité complète. Souvent, l'outil produira quelque chose d'utile. Parfois, il produira quelque chose de faux avec assurance. Cette distinction est centrale pour l'avenir du développement logiciel.

La question qu'on se pose comme responsable de pratique n'est plus « L'IA peut-elle écrire du code? ». Elle peut le faire. Notre question est plutôt: « Qui est qualifié pour savoir si le code est correct, maintenable, sécurisé, observable et aligné avec les besoins de l'entreprise? »

‍

L'IA fait déjà partie des processus

Ce n'est pas un futur lointain. C'est déjà en train de le cas.

Regardons les données.

Le sondage 2025 Stack Overflow Developer Survey a révélé que 51 % des développeur(euse)s professionnel(le)s utilisent des outils d'IA quotidiennement, et 52 % affirment que les outils ou agents d'IA ont eu un effet positif sur leur productivité. Parmi les développeur(euse)s qui utilisent des agents d'IA au travail, environ 70 % disent que ces agents ont réduit le temps consacré à certaines tâches de développement, et 69 % disent qu'ils ont augmenté leur productivité.

En parallèle, la confiance demeure une préoccupation sérieuse. Le même sondage a révélé que 87 % des répondant(e)s s'inquiètent de l'exactitude de l'information fournie par les agents d'IA, et 81 % ont des préoccupations liées à la sécurité et à la confidentialité. L'adoption augmente, la productivité est bien réelle, mais la confiance demeure incomplète.

La recherche contrôlée révèle la même tension. L'étude largement citée de Peng et al. sur GitHub Copilot a montré que les développeur(euse)s utilisant l'outil ont complété une tâche de serveur HTTP 55,8 % plus rapidement que ceux et celles qui ne l'utilisaient pas. Les recherches de McKinsey ont aussi montré que l'IA générative peut rendre les développeur(euse)s nettement plus rapides pour la génération de code, la refactorisation et la documentation, tout en soulignant que la qualité dépend de la capacité de ces mêmes spécialistes à reconnaître ce qu'est un bon code et à l'itérer avec l'outil.

Mais le portrait n'est pas uniformément positif. Un essai contrôlé et aléatoire mené par METR en 2025 a étudié 16 développeur(seuse)s expérimenté(e)s travaillant sur de grandes bases de code open source matures auxquelles ils contribuaient depuis des années. Le résultat a surpris bien des gens : ils et elles étaient 19 % plus lents avec l'assistance de l'IA que sans elle, même s'ils et elles croyaient être environ 20 % plus rapides. Les équipes de recherches attribuent cet écart au changement de contexte, à l'itération des invites (prompts) et au coût cognitif de la révision de résultats qui semblent plausibles.

Le rapport DORA Accelerate State of DevOps 2024 ajoute une autre mise en garde. Chez les répondant(e)s qui déclarent s'appuyer sur l'IA pour au moins une partie de leur travail, l'adoption de l'IA a été associée à une diminution estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité de livraison. L'hypothèse de DORA est que l'IA pourrait aider les spécialistes en dévelopement logiciels à produire des listes de changements plus volumineuses, et les changements plus volumineux ont toujours été corrélés à une livraison plus lente et plus fragile.

Autrement dit, l'IA peut accélérer le travail, mais les gains sont inégaux et ne se traduisent pas automatiquement par de meilleurs systèmes. Les accélérations sont gagnées par jugement.

‍

Les développeur(euse)s comme chefs d'orchestre

Le rôle de développeur(euse) logiciel est en train d'être redéfini.

Il ou elle devient davantage un(e) chef d'orchestre, un(e) réviseur(e), un(e) architecte et un(e) superviseur(e) de systèmes intelligents. À mesure que les outils agentiques deviennent plus performants, un plus grand volume de travail d'implémentation peut être délégué. Le rôle humain se déplace vers le haut : définir le problème, décomposer le travail, choisir l'architecture, encadrer l'agent, valider les hypothèses, réviser les résultats et s'assurer que le système final se comporte correctement.

Cela ne signifie pas que les développeur(euse)s peuvent se permettre d'en savoir moins.

Au contraire, ils et elles doivent connaitre un plus grand éventail de choses.

Les spécialistes en développement qui travaillent avec l'IA ont besoin d'une compréhension architecturale suffisante pour reconnaître quand une conception générée ne pourra pas grandir à l'échelle, quand une limite de service est mal définie, quand une requête de base de données s'effondrera sous une charge réelle, ou quand une hypothèse de sécurité est naïve. Il leur faut une rigueur suffisante en matière de tests pour savoir si les tests générés prouvent un comportement ou ne font qu'augmenter les chiffres de couverture. Il leur faut une compréhension suffisante du produit pour remarquer quand l'implémentation satisfait techniquement la consigne, mais échoue à répondre aux utilisateurs et utilisatrices.

Les meilleur(e)s développeur(euse)s dans un environnement assisté par l'IA ne seront pas ceux et celles qui génèrent le plus de code. Ce seront les personnes qui posent de meilleures questions, encadrent le système plus efficacement, révisent avec un œil plus critique et relient les décisions techniques aux résultats d'affaires.

Même le rôle de chef d'orchestre pourrait n'être que transitoire. Aujourd'hui, réviser les résultats de l'IA est ce qui maintient l'humain véritablement dans la boucle. Par contre, lorsqu'un agent peut générer des centaines, voire des milliers de fichiers en une seule séance, notre capacité à réviser le code de façon objective ne suivra pas ce rythme. La réponse naturelle pourrait être de déléguer une partie de la révision à un autre agent, déplaçant l'humain encore plus haut dans l'équation. Le logiciel pourrait éventuellement devenir ce que le moteur est devenu pour la plupart des conducteurs de voiture: une boîte noire à laquelle on fait confiance et qu'on utilise.

‍

Les fondamentaux sont encore importants

On peut faire une analogie intéressante avec les téléphones cellulaires. Plusieurs d'entre nous ne mémorisent plus les numéros de téléphone. La technologie a rendu cela inutile dans la vie quotidienne. Par contre, il reste des moments où la mémoire, la compréhension ou la préparation sont très utiles.

L'IA pourrait avoir un effet similaire sur les fondamentaux du logiciel. Certaines connaissances passeront du rappel actif à la récupération assistée. Un(e) expert(e) pourrait ne plus se souvenir de chaque détail d'un algorithme de tri ou d'une primitive de concurrence, parce que l'outil peut l'expliquer sur demande. Mais si la personne ne peut pas évaluer cette explication, elle n'est plus assisté. elle est dépendante.

Cette dépendance comporte des risques, et ces risques sont tangibles.

L'IA peut halluciner des APIs. Elle peut produire des requêtes inefficaces. Elle peut inventer des options de configuration. Elle peut générer des tests qui valident l'implantation plutôt que le comportement. Elle peut résoudre le problème local tout en violant une contrainte architecturale plus large. Elle peut recommander avec assurance des patrons obsolètes, non sécurisés ou inadaptés au système en question.

Une analyse de 2025 portant sur 576 000 échantillons de code générés par 16 grands modèles de langage populaires a révélé que 19,7 % des dépendances de paquets étaient « hallucinées », c'est-à-dire qu'elles faisaient référence à des bibliothèques qui n'existent pas. Les modèles open source hallucinaient à un taux de près de 22 %; les modèles commerciaux, à environ 5 %. Cela a donné naissance à une nouvelle catégorie d'attaque de la chaîne d'approvisionnement que les chercheurs appellent le « slopsquatting », où des acteurs malveillants enregistrent des noms de paquets hallucinés afin que les installations suggérées par l'IA deviennent des vecteurs d'attaque. Des évaluations indépendantes du code généré par l'IA, de façon plus générale, révèlent que 29 à 45 % des échantillons contiennent des vulnérabilités de sécurité, selon le langage et le type de tâche.

C'est pour tout ça que les fondamentaux sont encore importants. Au-delà des connaissances mémorisées, le modèle mental doit encore superviser la machine. Un(e) développeur(euse) n'a pas besoin d'écrire lui-même chaque recherche binaire pour être compétent(e). Mais il ou elle doit: comprendre pourquoi l'indexation est importante et quand utiliser des index. En tant qu'expert(e), il ou elle doit comprendre la latence, les modes de défaillance, les transactions, la concurrence, la mémoire, le couplage, la cohésion, les limites des tests, l'observabilité et les compromis. Les détails peuvent être assistés. Le jugement ne peut pas être aussi facilement sous-traité.

Du moins, pas encore.

‍

Le logiciel pourrait devenir moins coûteux à produire, mais pas moins ambitieux

La fabrication automobile est devenue lourdement automatisée. La Fédération internationale de robotique a rapporté que plus d'un million de robots travaillent dans l'industrie automobile à l'échelle mondiale, des pays comme la Corée du Sud, l'Allemagne, les États-Unis et le Japon, affichant une très forte densité de robots dans la production automobile. L'automatisation a aidé les fabricants à améliorer la constance, la productivité et le débit.

Mais les voitures ne sont pas simplement devenues des objets moins chers et plus simples. Les attentes ont grandi : systèmes de sécurité avancée, navigation, capteurs, systèmes de divertissement, contrôles logiciels, améliorations de l'efficacité énergétique, fonctions d'aide à la conduite et, désormais, propulsion électriques. Le Bureau of Labor Statistics des États-Unis tient compte de ces changements lorsqu'il mesure les prix des véhicules neufs, en ajustant pour les améliorations en matière de sécurité, d'économie de carburant, de systèmes mécaniques, de confort, de commodité, de navigation, de systèmes de communication, de caméras de recul, de capteurs et d'autres améliorations fonctionnelles.

Il existe un nom pour cette dynamique en économie : le paradoxe de Jevons. Lorsqu'une ressource devient plus efficace à utiliser, la consommation totale peut augmenter plutôt que diminuer, parce que le coût plus faible débloque de nouvelles catégories de demande qui échouaient auparavant à l'analyse coûts-avantages. Ce phénomène a d'abord été observé dans l'utilisation du charbon au 19e siècle, à mesure que les machines à vapeur devenaient plus efficaces, et il est réapparu depuis via l'électricité, l'informatique et la bande passante.

La leçon, ici, n'est pas que l'automatisation rend tout « cheap » pour toujours. C'est, qu'en fait, l'automatisation change ce qui devient économiquement possible. À mesure que la production devient plus efficace, les attentes augmentent. Les produits absorbent davantage de fonctionnalités. Les marchés exigent davantage de personnalisation. Les entreprises découvrent de nouvelles façons de se démarquer.

L'IA pourrait réduire le coût de production de certains types de logiciels, notamment le code répétitif (« boilerplate »), les prototypes, les migrations, l'échafaudage de tests, la documentation, les outils internes et le travail de fonctionnalités routinières. Mais un coût plus faible ne signifiera pas nécessairement moins de travail. Cela pourrait signifier plus de logiciels, plus d'expérimentations, plus de personnalisation, plus d'intégrations, plus d'automatisation et plus de pression pour livrer plus rapidement.

Même si le coût de construction d'un logiciel diminue, l'appétit pour construire, lui, pourrait augmenter.

‍

Le goulot d'étranglement humain se déplace

Historiquement, un des goulots d'étranglement du développement logiciel était la capacité d'implantation. Combien de développeurs avons-nous? Combien de code peuvent-ils écrire? Combien de tickets peuvent-ils compléter?

L'IA change cette équation. Dans certains contextes, une équipe plus petite dotée de solides processus assistés par l'IA pourrait produire ce qui exigeait auparavant une équipe plus grande. Il serait naïf de prétendre que cela n'affectera pas les effectifs. Certaines équipes réduiront leur taille. Certains rôles se consolideront. Une partie du travail de niveau débutant pourrait être automatisée ou transformée.

Les premières données sont frappantes. Salesforce a rapporté n'avoir embauché aucun nouvel ingénieur logiciel au cours de l'exercice 2026, le PDG Marc Benioff attribuant ce changement aux agents de codage IA et citant un gain de productivité en ingénierie d'environ 30 %. Dans l'ensemble du secteur technologique américain, plus de 142 000 travailleurs ont été licenciés au cours des cinq premiers mois de 2026, l'IA étant citée comme l'une des principales raisons par les entreprises suivies par Challenger, Gray & Christmas, et l'emploi de développeur(euse)s de niveau débutant a chuté de façon significative depuis son sommet de fin 2022.

Il vaut la peine d'être honnête quant à l'endroit où les développeur(euse)s déplacé(e)s pourraient réellement se retrouver. Lorsque les robots automobiles ont remplacé les soudeurs, les effectifs déplacés ne sont pas tous devenus des superviseur(e)s de robots ou inspecteur(trice)s de soudure. L'arithmétique fonctionne rarement ainsi. Certain(e)s se sont déplacé(e)s latéralement vers des emplois de soudeur dans des entreprises qui n'avaient pas encore automatisé. D'autres ont quitté le métier complètement. Le logiciel ne fera probablement pas exception.

Les rôles de chef d'orchestre et de supervision sont réels et en croissance, mais ils ne remplacent pas, un pour un, les effectifs qu'ils consomment. Certain(e)s expert(e)s se dirigeront vers du travail technique adjacent : intégration, architecture pour des clients qui ne peuvent plus se permettre leurs propres équipes, révision de sécurité, données et ingénierie de plateforme. D'autres se dirigeront vers des rôles qui s'appuient davantage sur les capacités humaines que sur la profondeur technique : conversations avec les clients, définition des besoins, jugement produit et travail relationnel. Rester technique importera toujours, mais pas toujours au sens algorithmique d'autrefois.

Le cycle de vie autour du travail pourrait aussi se compacter. L'arc traditionnel des services (prospection, découverte, conception, construction, déploiement et gestion des applications) repose sur le fait que les phases de construction et de déploiement sont coûteuses. Lorsque ces phases s'effondrent en coût, le cycle de vie se comprime avec elles. Il n'est pas difficile d'imaginer une version à court terme où le résultat d'une découverte bien menée devient le système déployé lui-même.

Mais un autre goulot d'étranglement devient plus visible : la qualité de la prise de décision.

Que devrions-nous construire? Pourquoi? Pour qui? Quels risques sont acceptables? Qu'est-ce qui devrait être automatisé, et qu'est-ce qui devrait rester révisé par des humains? Quel code généré est suffisamment bon? Quels comportements du système comptent le plus? Quels tests protègent réellement l'entreprise? Quelles défaillances sont tolérables, et lesquelles sont existentielles?

Ce ne sont pas de simples questions de codage. On se questionne sur le produit, l'architecture, le risque et l'organisation elle-même.

Cela signifie que les développeur(euse)s devront comprendre l'entreprise plus en profondeur. Ils devront penser comme des spécialistes de l'assurance qualité, des gestionnaires de produit, des architectes, des exploitant(e)s et des réviseur(e)s de sécurité. Ils devront valider les résultats, pas seulement les implémentations qu'ils font. Ils devront savoir quand une solution générée par l'IA est techniquement impressionnante, mais stratégiquement erronée.

Les développeur(euse)s de l'avenir pourrait passer moins de temps à produire chaque ligne manuellement et plus de temps à s'assurer que le système, dans son ensemble, soit cohérent.

‍

Le risque de déqualification

Il existe une réelle préoccupation selon laquelle l'IA pourrait produire une génération de développeur(euse)s capables d'assembler des logiciels sans les comprendre. Cette préoccupation ne devrait pas être écartée comme de la nostalgie.

Si les juniors ne se débattent jamais avec le « débogage », n'apprennent jamais comment fonctionne le HTTP, ne raisonnent jamais sur les structures de données, ne voient jamais de défaillances en production et ne reçoivent jamais de mentorat de la part d'ingénieur(e)s expérimenté(e)s, l'industrie pourrait gagner en rapidité à court terme tout en affaiblissant son bassin de talents à long terme. Les données d'embauche suggèrent déjà que cet échelon est sous pression : les postes de niveau débutant, où cet apprentissage avait l'habitude de se produire, comptent parmi ceux qui se contractent le plus rapidement.

L'ancien modèle d'apprentissage avec mentor(e) et apprenti(e) était imparfait, mais il servait un but. Il offrait aux développeur(euse)s un parcours de l'imitation vers la compréhension, de la syntaxe vers la conception, de la correction de bogues vers leur anticipation.

L'IA peut aider à l'apprentissage, mais seulement si elle est utilisée de façon délibérée. Elle peut expliquer du code inconnu, générer des exemples, comparer des approches et fournir une rétroaction immédiate. Mais elle peut aussi permettre à un développeur de contourner l'inconfort dans lequel se forme la véritable compréhension.

Les organisations devront être intentionnelles. Elles ne peuvent pas simplement remettre des outils d'IA à des développeur(euse)s juniors et s'attendre à ce que la maîtrise émerge automatiquement. Le mentorat compte toujours. La révision de code compte toujours. La programmation en binôme compte toujours. Les discussions d'architecture comptent toujours. Tout comme la vieille habitude de s'éloigner du clavier pour réfléchir avant de générer davantage de code.

‍

Ce qui est vrai aujourd'hui pourrait être faux demain

Toute prédiction confiante au sujet de l'IA devrait venir avec une date d'expiration.

Ça aide de se rappeler que ce n'est pas le premier changement de ce genre, mais c'est bel et bien le plus abrupt. Le travail de développement logiciel dans les années 1980 ne ressemble en rien à celui des années 1990, qui ne ressemblait en rien à celui des années 2000, et même 2020 semble déjà lointain. Le compression de bits parce que la mémoire était rare, l'assembleur codé à la main à l'intérieur du C parce que le code de plus haut niveau était trop lent, et la traque des défauts de cache pour garder les applications réactives sont tous devenus moins centraux à mesure que nous sommes passés aux langages interprétés, aux conteneurs, aux machines virtuelles, aux environnements d'exécution gérés et aux plateformes infonuagiques.

Chaque génération de développeur(euse)s a dû abandonner quelque chose qui définissait la génération précédente. Nous devrions nous attendre à la même chose, probablement à un rythme plus rapide.

Cette progression suit un schéma : chaque génération d'outils a rehaussé le niveau d'abstraction, changé le rôle et augmenté le rendement. L'arrivée des compilateurs et des langages de haut niveau est créditée d'une amélioration d'au moins cinq fois de la productivité par rapport à la programmation en assembleur. Les machines virtuelles et les environnements d'exécution gérés ont éliminé des catégories entières de travail lié à la mémoire et à la portabilité. Les conteneurs et les systèmes d'orchestration ont transformé le déploiement en un problème de configuration. Les plateformes infonuagiques ont transformé le provisionnement matériel, la mise à l'échelle et la distribution mondiale en appels APIs. L'infrastructure en tant que code a transformé les opérations en un problème de révision de code.

À chaque étape, les développeur(euse)s produisaient davantage, en savait un peu moins sur la couche sous-jacente, et devenait responsable d'un peu plus de la couche supérieure.

Cette même progression a discrètement redéfini des titres de poste entiers. Il y a vingt ans, une organisation logicielle sérieuse aurait pu avoir besoin d'intégrateur(e)s de systèmes dédiés, d'administrateur(trice)s de bases de données et d'analystes de l'exploitation réseau. Une grande partie de ce travail a été absorbée par DevOps, les plateformes infonuagiques et les services gérés. L'adminisatration de bases de données comme rôle n'a pas disparu, mais la demande s'est déplacée vers le travail infonuagique et applicatif, tandis que l'administration routinière, qui justifiait autrefois une équipe entière, n'est aujourd'hui souvent qu'un simple paramètre de base de données gérée. Le travail d'administration système et d'exploitation réseau a suivi des trajectoires similaires. Ces rôles n'ont pas été abolis. Leur demande s'est amenuisée, leurs limites se sont brouillées, et le travail s'est déplacé.

Si ce schéma se maintient, la réponse honnête à la question « qu'advient-il des développeur(euse)s? » pourrait être la même que celle qui s'appliquait aux administrateurs de bases de données et aux intégrateurs : le rôle ne disparaît pas, mais il se rétrécit, se déplace et se reforme autour de tout ce que la prochaine couche d'abstraction laisse non automatisé.

La partie inconfortable est que les expert(e)s en développement logiciels sont, en un sens réel, en train de construire leur propre prochaine abstraction.

Les outils changent trop rapidement pour permettre la certitude. Ce qui semble risqué aujourd'hui pourrait être routinier dans six mois. Ce qui semble impressionnant aujourd'hui pourrait sembler primitif dans un an. Les frontières entre autocomplétion, assistant, agent, réviseur, testeur et implémenteur autonome sont déjà en train de s'estomper.

Donc, la position la plus sûre n'est pas de déclarer que l'IA remplacera les expert(e)s de développement logiciel, ni qu'elle ne le fera jamais. Les deux affirmations sont trop simples.

Une vision plus équilibrée serait celle-ci : l'IA change la forme économique et pratique du développement logiciel. Elle automatisera une partie du travail. Elle amplifiera les développeur(euse)s compétent(e)s. Elle exposera les pratiques d'ingénierie faibles. Elle créera de nouveaux risques. Elle réduira le coût de certains livrables et augmentera les attentes quant à ce que les équipes peuvent produire. Elle rendra les fondamentaux moins visibles, tout en rendant le jugement plus important. Le métier ne disparaît pas, mais ses rituels changent.

Le ou la développeur(euse) de l'avenir ne sera peut-être pas jugé sur la quantité de code qu'il ou elle peut personnellement taper. Le jugement sera sur sa capacité à diriger des outils intelligents, à évaluer leurs résultats, à préserver l'intégrité des systèmes, à comprendre l'entreprise, à protéger les utilisateurs et à continuer d'apprendre à mesure que le terrain bouge.

Cet avenir pourrait sembler moins « sacré » que le passé. Ou peut-être que le caractère « sacré » se déplace simplement : de la mémorisation de chaque commande, patron ou algorithme, vers le souci de savoir quand la machine a tort.

Et vous, qu'en pensez-vous de l'avenir de notre métier?

L’intelligence artificielle (IA) promet beaucoup, mais son véritable potentiel reste sous-exploité.  
Pourquoi ? Et bien, non pas parce que la technologie manque de maturité, mais parce qu’on oublie que l’usage humain reste le véritable levier de toute transformation numérique.

Eh oui, personne ne comprend les humains mieux que les humains.  
C'est là qu'intervient l'approche « human-first », une philosophie simple : mettre les humains au coeur des changements technologiques, c’est-à-dire concevoir des outils et des systèmes qui travaillent réellement pour les personnes qui les utilisent.

L’objectif n’est pas de renforcer les solutions, mais d’abord de renforcer la compréhension du travail humain avant d’y intégrer une couche d’intelligence artificielle. Vous pouvez avoir les meilleurs systèmes du monde, si vos équipes ne sont pas prêtes, rien ne fonctionnera.

Chez Spiria, c’est un constat que nous faisons chaque jour. Les entreprises qui réussissent, ne modernisent pas uniquement leur infrastructure, elles modernisent la manière dont leurs équipes interagissent avec leurs outils, leurs données et leurs processus. Elles créent un terrain où l’IA peut devenir utile, lisible et durable.

Cet article explore comment une modernisation logicielle centrée sur l’humain prépare naturellement les organisations à accueillir une IA qui s’intègre avec fluidité, soutient les équipes et améliore leur travail pour un succès durable de l’IA.

1. Moderniser pour l’IA commence par moderniser pour les humains

Moderniser d'abord, puis se demander comment faire adopter l'IA ensuite.
Combien d'organisations ont fait cette erreur ?

L’envie d’intégrer l’IA est naturelle. Elle incarne le progrès, l’innovation et l’efficacité. Pourtant, dans la pratique, elle peine souvent à s’inscrire dans des environnements qui n’ont pas été conçus pour soutenir les usages des équipes.

Le résultat ? Des systèmes techniquement impressionnants mais sous-utilisés. Des équipes frustrées qui contournent les nouveaux outils pour revenir à leurs vieilles habitudes. Un ROI décevant qui pousse la direction à douter de l'IA elle-même.

Dans notre article précédent « Pourquoi les systèmes hérités cèdent sous la pression de l’IA », nous avons exploré les obstacles techniques des données fragmentées, des architectures rigides et de la dette technologique. Mais ces obstacles techniques ne sont qu'une partie du problème. L'autre partie, celle qu'on néglige trop souvent, réside dans les silos humains et organisationnels.

C’est pourquoi l’approche centrée sur l’humain est essentiel. Moderniser les systèmes non pas en fonction de la technologie, mais en fonction des humains qui en dépendent. Il s’agit de clarifier, de simplifier et de fluidifier afin que les outils deviennent un socle compréhensible, cohérent et aligné avec la réalité du terrain.

L’IA ne crée de la valeur que si elle s’inscrit dans un environnement que les humains maîtrisent déjà. Moderniser pour l’IA signifie donc moderniser pour les humains en premier.

2. Les trois fondations du human-ready : clarté, confiance, collaboration

Avant d’explorer ces fondations, rappelons une nuance essentielle, l’approche « human-first » est la méthode, tandis qu’être « human-ready » en est le résultat. Autrement dit, une organisation atteint cet état lorsque la modernisation est réellement pensée pour les humains et mise en pratique.

Ces piliers en sont la base :

1. Clarté

La clarté consiste à rendre les systèmes lisibles, les processus compréhensibles et les outils intuitifs.
On ne parle pas d’une transparence technique, mais plutôt d’une transparence opérationnelle. Quelles données l'IA utilise-t-elle ? Pourquoi elle recommande telle action plutôt qu'une autre ? Quelles sont ses limites ?

Les équipes doivent comprendre ce qu’un système fait, comment il le fait et pourquoi il le fait.
Cette clarté réduit l’incertitude et ouvre la voie à une utilisation naturelle de l’IA.

Elle permet aux utilisateurs de savoir quand ils peuvent faire confiance à l'algorithme et quand ils doivent exercer leur jugement professionnel.

2. Confiance

La confiance est le cœur invisible de toute adoption technologique.
Elle se construit au fur et à mesure, mais surtout elle commence par la preuve.

Créer la confiance avec l’utilisation de l’IA exige des résultats tangibles et vérifiables avec des systèmes robustes et fiables. Les équipes doivent voir que l'IA améliore vraiment leur travail au lieu de le complexifier et qu'elle respecte leurs contraintes opérationnelles plutôt que de les ignorer.

La formation continue joue ici un rôle essentiel. Pas seulement au lancement d’un projet, mais au fil du temps, pour permettre aux équipes d’explorer, de poser des questions et de développer une intuition technologique.

C’est lorsque cette confiance s’installe que l’IA devient réellement utile.

3. Collaboration

La collaboration est ce qui donne vie à tout le reste.
Un projet IA échoue rarement pour des raisons algorithmiques, mais souvent parce que les humains n’ont pas été consultés assez tôt.

Préparer les équipes à collaborer avec l’IA implique de comprendre leurs irritants réels, leurs décisions critiques et leurs contraintes opérationnelles. C’est cette connaissance humaine qui permet à l’IA de trouver sa place dans le flux de travail.

Une IA peut optimiser un processus, mais seule une équipe peut en comprendre la nuance, le contexte et l’intention. C’est dans cette complémentarité que réside sa véritable valeur.

De AI-ready à Human-ready : deux notions souvent confondues

Beaucoup d’organisations se concentrent sur le fait de devenir « AI-ready », avec une infrastructure modernisée, des données centralisées et de nouveaux outils intelligents. Mais cela ne suffit pas si les humains ne sont pas prêts à utiliser ces outils.

Être « human-ready », c’est autre chose, c’est le résultat d’une approche « human-first ». C’est disposer de systèmes simples, de processus clarifiés et d’outils qui respectent les usages réels. C’est créer un terrain où les équipes comprennent la technologie, lui font confiance et peuvent l’appliquer avec discernement. Et c'est cette préparation humaine qui doit venir en premier.

Trop d'organisations traitent la modernisation comme un projet TI isolé. Elles investissent des millions dans de nouvelles infrastructures sans jamais questionner l'expérience utilisateur. Mais à quoi sert un système performant si personne ne souhaite l'utiliser ?

Les entreprises qui réussissent leur transformation ne se contentent pas d'adopter des outils IA. Elles préparent leurs équipes à les intégrer dans leurs pratiques quotidiennes, avant même le premier déploiement.

Elles adaptent leurs processus en amont. Elles clarifient leurs rôles et responsabilités avant que l'IA n'arrive. Elles construisent la confiance pendant la phase de conception, pas après les premiers échecs.

Elles investissent dans une transformation organisationnelle durable où l'humain reste au centre de la décision dès le premier jour du projet.

Et si la clé du succès IA était simplement humaine ?

La modernisation «human-first » n'est pas une mode.
C'est une philosophie de travail qui reconnaît une vérité simple, celle de la performance durable qui se construit sur des fondations humaines solides, pas seulement sur des algorithmes performants.

Moderniser, c’est créer des systèmes plus clairs, plus fiables et plus humains, des systèmes capables d’évoluer au rythme des organisations qu’ils soutiennent.

Chez Spiria, cette conviction guide notre accompagnement dans les projets de modernisation et d’intégration IA.  Nous aidons les organisations à bâtir des solutions sur mesure qui soutiennent les humains pour que l’IA puisse réellement tenir ses promesses.

Parce que le socle du succès IA repose sur une approche qui permet de construire une intelligence artificielle utile, durable et profondément humaine.

Et si la meilleure façon de réussir avec l’IA consistait simplement à remettre l’humain au cœur de la modernisation ?