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?