Savoir-faire et technologie pour défis d’affaires complexes

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?

Alors que les investissements en technologie d’entreprise augmentent d'en moyenne 8% par année depuis 2022 (Mckinsey, 2025), une réalité persiste : ce ne sont pas tous les projets de transformation numérique qui sont rentables. Une étude du Boston Consulting Group révèle que 70% des projets de transformation numériques ne parviennent pas à atteindre leurs objectifs, entraînant souvent de graves conséquences. Par contre, la même étude rappelle à quel point ces investissements sont payants.

Alors, où sont les écarts ?

Eh bien, ils se situent rarement au niveau d'un produit, de l’intelligence artificielle (IA) ou du développement logiciel entant que tel. Le succès se décide bien avant la première ligne de code : il repose principalement sur la planification stratégique.

Notre thèse ?  Un projet de développement de logiciel sur mesure, c’est d’abord un projet d’affaires. Donc oui. La planification stratégique est cruciale.

Pour réduire les risques et vous assurer que votre prochain projet TI soit un levier de croissance, prenez un moment pour prendre conscience de 5 mythes qui peuvent vous mettre des bâtons dans les roues.

‍

1. « Le succès dépend surtout des bons choix technologiques »

C’est vrai, les choix technologiques ont un impact. Par contre, le plus grand risque d’un projet est rarement technique. Il est bien plus souvent organisationnel. Des objectifs imprécis, un manque d’alignement ou une faible implication des équipes causent plus d’échecs que le choix de langage ou d’infrastructure lui-même. La technologie est l'outil pour répondre à un enjeu d'affaires et non pas la réponse en elle-même. Confondre les deux, c'est construire une solution qui fonctionne techniquement, mais qui ne résout rien de concret.

La réalité : Un projet logiciel est avant tout un projet d’affaires. Un logiciel d’entreprise n'est pas réussi parce qu'il fonctionne techniquement ; il est réussi parce qu'il simplifie le travail, crée un gain tangible pour votre entreprise et est adopté par vos utilisateurs et utilisatrices.

‍

2. « On peut commencer à coder, on ajustera plus tard... l'analyse c'est du temps perdu. »

Ce qui est trompeur avec le développement applicatif, c’est qu’on peut toujours faire des changements. Par contre, il y a un coût à le faire. Et plus on en fait tard dans le processus, plus le coût risque d’être élevé. S'engager dans le développement sans un cadre défini mène droit aux dépassements de coûts. Certes, un projet évolue, mais chaque changement structurel en cours de route provoque des répercussions importantes sur le budget et l’échéancier. L’analyse permet d'anticiper les contraintes critiques, identifier les besoins utilisateurs réels, et valider des hypothèses clés.

La réalité : Les besoins fondamentaux et dépendances critiques identifiés dans l’analyse (aussi appelé phase Découverte) réduisent les risques de votre projet. Commencer à développer sans cadre, c'est construire une maison sans plan. On peut toujours abattre un mur, mais ça coûte bien plus cher qu'un trait de crayon effacé sur un plan.

‍

3. « L’intelligence artificielle (IA) va rendre la planification obsolète. »

Ici, le risque n'est pas dans votre architecture logicielle. Il provient de vos décisions, et ce, d'une toute première version au produit final. L'intelligence artificielle peut générer des fonctionnalités à une vitesse record, mais elle ne peut pas dicter votre stratégie d'affaires. Plus les capacités de production augmentent, plus votre trajectoire doit être définie avec rigueur.

La réalité : L'IA ne peut pas anticiper les dépendances critiques entre vos différents systèmes ni s'assurer que l'outil règleras les irritants réels de vos équipes en usine, sur le terrain ou au bureau.

‍

4. « On préfère payer une licence pour un logiciel existant, c'est moins cher que le sur mesure. »

S'il existe une solution sur le marché qui répond parfaitement à vos besoins, c'est probablement le choix le plus judicieux. Nous serons les premiers à vous le dire. Mais quand la solution touche au cœur de vos opérations, à ce qui vous différencie de vos compétiteurs, à votre sauce secrète — là, le calcul change complètement. Un logiciel sur mesure (bien fait et abordé comme un projet d'affaires) devient un investissement. Surtout s'il centralise vos processus, remplace plusieurs outils existants, et vous fait économiser du temps et de l'argent à long terme. Dans plusieurs industries, il existe aussi des approches hybrides qui combinent des solutions existantes avec du développement sur mesure via des APIs qui permettent de cibler uniquement ce qui crée une valeur unique pour vous.

La réalité : Ce n'est pas une question de sur mesure contre existant. C'est une question d'alignement avec vos objectifs d'affaires. Demandez-vous si cette solution règle un enjeu qui vous distingue ; si elle s’intègre à votre environnement et si elle permet de sauver des coûts, du temps, ou de faire quelque chose que vos compétiteurs ne peuvent pas faire. Vous aurez votre réponse.

‍

5. « La livraison marque la fin du projet. »

Un logiciel est un actif vivant. Et son déploiement n'est pas une finalité. C'est le moment où les utilisateurs s'approprient la solution, où de nouveaux apprentissages débutent et de nouvelles idées surgissent. D'autant plus qu'on vise rarement la solution parfaite dès le départ : on livre une première version répondant aux besoins fondamentaux. Comme votre maison une fois construite, il faut l'entretenir et l'améliorer pour qu'elle conserve son utilité et sa valeur. Négliger les coûts d'adoption, de support et d'évolution dans le calcul initial peut être une grande erreur.

La réalité : Prévoyez un budget annuel d’amélioration et de maintenance logicielle selon les risques que vous êtes prêt(e)s à prendre. Une fois la solution en place, il faut l’entretenir pour qu’elle conserve son utilité et sa valeur.

‍

Ces 5 mythes ont un point en commun : ils déplacent l'attention là où le risque est le plus faible, et loin de là où il est le plus élevé. On investit dans la technologie, on choisit les bons outils, on lance le développement...et on découvre en cours de route que les objectifs étaient flous, que les utilisateurs et utilisatrices n'ont pas été consultés, ou que la solution règle le mauvais problème.

Rappelons-le : 70 % des projets de transformation numérique n'atteignent pas leurs objectifs (BCG, 2020). Pas parce que la technologie a failli. Parce que la planification stratégique, elle, n'était pas au rendez-vous.

Un projet logiciel, c'est d'abord un projet d'affaires. Et même vos collègues et patron(ne)s les plus vifs d'esprit pourraient se faire prendre par ces mythes.

Pourquoi pas leur partager cet article pour que votre prochain projet, lui, soit dans les 30 % qui réussissent ?

‍