À l’ère où l’IA déverse du code, quand la marée se retire on voit qui nageait nu

Résumé essentiel

• En trois ans depuis l’arrivée de ChatGPT, la journée des développeurs est en train de passer de la « rédaction de code » à la « vérification des sorties de l’IA »
• Le rôle du développeur ne disparaît pas ; le centre de gravité se déplace plutôt de l’auteur de code vers le relecteur et le décideur chargé de l’approbation
• L’IA n’est pas une personne juridique et ne peut pas assumer de responsabilité ; les réglementations comme l’EU AI Act renforcent aussi l’attribution de la responsabilité aux humains
• À l’ère de l’IA, les compétences clés attendues ne sont pas les techniques de prompt, mais la capacité à prévoir les coûts de changement à long terme, à juger les abstractions et à expliciter les savoirs tacites — en substance les mêmes qualités que celles d’un bon développeur aujourd’hui
• En reprenant la distinction de Fred Brooks entre complexité accidentelle et complexité essentielle, l’IA ne résout que la première ; la complexité essentielle du domaine exige toujours le jugement humain
• La durée de validité de la maîtrise d’un outil (prompt engineering, etc.) est liée au cycle de remplacement de cet outil, tandis que la capacité de jugement de conception et d’explicitation des savoirs tacites reste valable tant que la complexité essentielle du logiciel existe

---

Résumé détaillé

Trois ans après ChatGPT

• Fin 2022, lors de l’apparition de ChatGPT, on n’imaginait pas que les progrès iraient à ce rythme
• Définition classique du développeur : une personne qui réalise l’ensemble « analyse des exigences en langage naturel → conception → implémentation directe »
• Aujourd’hui, une grande partie de la journée consiste à « transmettre le contexte à l’IA → lire, corriger et redemander du code généré »
• Les agents de code IA ont déjà dépassé le simple rôle d’assistant et atteignent, à l’échelle d’une fonction ou d’un module, un niveau difficile à distinguer du code écrit par un humain

De l’auteur au décideur

• L’acte de produire du code se déplace de « l’écriture directe » vers « le jugement sur le code »
• Par « jugement », il ne s’agit pas seulement de vérifier si la sortie de l’IA correspond à l’intention, mais de valider si l’intention métier a bien été traduite en implémentation technique
• La question clé est : « Si un bug de paiement apparaît dans du code écrit par l’IA, qui en porte la responsabilité ? »
• Comme l’IA n’est pas une personne juridique, la responsabilité revient au développeur et à l’organisation qui ont relu et approuvé le code
• EU AI Act, entré en vigueur en 2024 : obligation de supervision humaine des systèmes d’IA dans les domaines à haut risque comme la santé, la finance ou les infrastructures
• Responsabilité dans un accident de voiture autonome → constructeur et conducteur ; IA médicale approuvée par la FDA → la décision finale revient au médecin ; Flash Crash de 2010 → l’entité qui exploitait l’algorithme est visée par la régulation
• Plus l’automatisation devient avancée, plus la structure de responsabilité ne s’efface pas ; elle tend au contraire à être rattachée encore plus clairement aux humains

Compétences attendues des développeurs à l’ère de l’IA

① Capacité à prévoir les coûts de changement à long terme

• L’IA est optimisée pour produire du « code qui fonctionne » (en reproduisant les motifs les plus fréquents dans les données d’entraînement)
• Un code qui fonctionne immédiatement et un code facile à maintenir encore six mois plus tard obéissent à des critères totalement différents
• Le coût d’une mauvaise conception ne se manifeste pas au moment où le code est écrit, mais au moment où un changement devient nécessaire
• Sur LinkedIn, les publications du type « On l’a fait avec l’IA mais c’était trop difficile à maintenir, donc on a embauché des développeurs » ou « On a abandonné car on n’arrivait pas à ajouter de nouvelles fonctionnalités » se multiplient

② Capacité à évaluer le code sous plusieurs angles

• Au-delà de la justesse fonctionnelle (vérifiable par des tests), il faut considérer simultanément la qualité structurelle, les implications de performance et les aspects de sécurité
• Plus la génération de code par l’IA s’accélère, plus l’équilibre entre vitesse de production et capacité de revue se rompt facilement
• À l’époque où les humains écrivaient eux-mêmes le code, il existait une limite physique au volume produit ; l’IA, elle, peut générer des centaines de lignes en quelques secondes
• Si les critères de revue, les systèmes de revue parallèles et les gates d’automatisation sont insuffisants, la dette technique s’accumule encore plus vite
• Si beaucoup d’entreprises ne ressentent pas de gain de productivité après l’adoption de l’IA, c’est parce que la production de code s’est accélérée, mais que la revue du code généré par l’IA est devenue le goulot d’étranglement

③ Capacité d’abstraction

• L’IA peut elle aussi définir des interfaces, séparer des classes et découper des modules, et le fait correctement sur la forme
• La différence décisive : l’abstraction de l’IA repose sur une moyenne statistique, celle d’un développeur expérimenté relève d’un arbitrage dans un contexte de ressources limitées et d’avenir incertain
• Le point dangereux du code produit par l’IA : il a l’air convaincant — les fichiers sont bien séparés, les noms respectent les conventions, les patterns sont familiers
• Le problème apparaît quand il faut faire évoluer le système : « En voulant ajouter un seul moyen de paiement, on réalise seulement à ce moment-là qu’il faut modifier simultanément plusieurs parties d’une structure qui avait pourtant l’air “propre” »
• Exemple frontend : l’IA peut entasser data fetching, gestion d’état et rendu UI dans un énorme composant unique, ou au contraire créer pour un simple graphique 3 custom hooks + un context provider

④ Capacité à rendre explicite le savoir tacite

• Pour donner des instructions précises à l’IA, il faut être capable de transformer l’intuition « Il y a quelque chose qui cloche » en formulation concrète comme « Cette fonction a deux responsabilités »
• Il ne s’agit pas de techniques de prompt formelles comme few-shot ou chain-of-thought, mais de la capacité à définir clairement ce qu’il faut produire, à juger quel contexte est important, puis à le transmettre
• Durée de vie de la maîtrise des outils : liée au cycle de remplacement des outils (jQuery → React, Webpack → Vite)
• Durée de vie de la capacité de jugement de conception et d’explicitation du savoir tacite : elle reste valable tant que la complexité essentielle du logiciel existe

La nécessité de concevoir un entraînement délibéré

• On dit souvent « concentrez-vous sur ce que l’outil ne peut pas faire », mais paradoxalement les occasions de développer précisément cela diminuent

① Les deux points qu’il ne faut pas déléguer à l’IA : la conception et la revue

• La conception en amont de l’écriture du code : si l’on définit d’abord les interfaces et les frontières de responsabilité avant même d’écrire le prompt, on peut ensuite comparer la sortie de l’IA à ses propres décisions de conception
• L’habitude consistant à confier la PR review à l’IA puis à approuver s’il n’y a pas de problème apparent = « aller sur le terrain pendant le cours de sport, rester assis uniquement sur le banc, puis rentrer »

② Du temps consacré intentionnellement à coder soi-même

• Le sens de la conception naît de la connaissance de la douleur de l’implémentation. Une douleur qu’on n’a jamais vécue ne se transforme pas en intuition
• Pour un développeur junior, relire du code généré par l’IA revient un peu à « demander à quelqu’un qui apprend encore à conduire d’évaluer les décisions d’une voiture autonome »
• La capacité à coder dans le futur : non pas une tâche quotidienne, mais un entraînement pour maintenir son jugement (comme le parcours pour obtenir une licence de relecteur)

③ S’exercer à mettre en mots le « pourquoi »

• S’arrêter à « C’est bizarre » reste de l’intuition ; aller jusqu’à « Cette fonction a deux responsabilités » devient du langage
• Même quand le code produit par l’IA fonctionne, ne pas s’arrêter là, mais prendre l’habitude de se demander « Pourquoi avoir choisi cette structure ? » et « Si la structure avait été différente, quels auraient été les arbitrages ? »

Au fond, l’essentiel n’a pas changé

• Fred Brooks (1986) : complexité accidentelle (limites des outils) vs complexité essentielle (inhérente au problème lui-même)
• Ce que l’IA résout, c’est la complexité accidentelle — boilerplate, motifs répétitifs, erreurs de syntaxe
• La complexité essentielle (ambiguïté des exigences métier, équilibre entre objectifs de conception contradictoires, incertitude sur les changements futurs) ne disparaît pas, même si l’IA progresse
• Tant que l’humain reste le sujet du jugement et de la responsabilité, la nature des compétences nécessaires à ce jugement ne change pas
• Plus la production de code est automatisée, plus l’importance du discernement nécessaire pour contrôler ce qui est produit ressortira