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

bboydart91 · 2026-02-19T06:17:29+09:00

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

(evan-moon.github.io)

51 points par bboydart91 2026-02-19 | 14 commentaires | Partager sur WhatsApp

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

14 commentaires

bboydart91 2026-02-19

Merci pour ces excellents retours !

Si j’ai évoqué la « responsabilité » dans mon texte, ce n’est pas parce que l’être humain ferait moins d’erreurs que l’IA sur tous les plans, mais parce que les systèmes juridiques et éthiques de la société moderne ne conçoivent encore que l’humain (ou la personne morale) comme « sujet responsable ».

Comme l’a dit gcback, si une sûreté statistique est démontrée, le système de responsabilité lui-même pourrait évoluer à l’avenir ; toutefois, au moins à court terme, j’estime que le dilemme social consistant à savoir « qui ira en prison ou indemnisera les victimes pour un accident causé par l’IA » aura du mal à suivre le rythme des avancées technologiques..!

moregeek 2026-02-19

Je pense pareil. J’ai bien aimé la lecture.

apkas 2026-02-19

Est-ce vraiment la marée qui se retire, ou est-ce qu’elle monte ? « Les compétences exigées des développeurs à l’ère de l’IA »… eh bien, encore faut-il que les développeurs continuent d’exister.

mhj5730 2026-02-19

Du point de vue de quelqu’un qui utilise réellement l’IA dans son travail, l’idée qu’on passe du développement par l’IA -> à la supervision des résultats produits par l’IA me parle vraiment profondément.
Et l’IA aide aussi énormément à résoudre la complexité essentielle. [vérification des contradictions lors de l’analyse des exigences, vérification des doublons, questionnement sur la valeur essentielle]

cocofather 2026-02-19

Il faudrait qu’il y ait encore plus de fidèles aveugles de l’IA.

moregeek 2026-02-20

Quelle en est la raison ?

armila 2026-02-19

Je pense que ce sera aussi une période de transition.
Après tout, même parmi les entraîneurs de football célèbres, beaucoup ne sont pas d'anciens joueurs.

moregeek 2026-02-19

Je pense que ce n’est pas seulement une question d’ancienneté élective : il est devenu célèbre parce qu’il a une excellente compréhension.

tested 2026-02-20

Mais comme on parle de football, ça me fait penser à Chung Mong-gyu.

tested 2026-02-20

C’est parce qu’il possède les qualités nécessaires pour entraîner une équipe de football même sans avoir été joueur professionnel, et que c’est à celui qui peut assumer la responsabilité du résultat du match d’être l’entraîneur.

chshin84 2026-02-20

C’est vrai, il existe aussi des entraîneurs qui ne sont pas d’anciens joueurs.
Mais, ces entraîneurs ne se distinguent pas parce qu’ils ne viennent pas du milieu des joueurs... mais parce que, malgré cela, ils possèdent une compréhension supérieure à celle des joueurs eux-mêmes. Dans ce domaine, on pourrait presque les qualifier de « surhumains ».

dohyun682 2026-02-19

Je suis d’accord aussi
Récemment, quand on voit les approches de type harness ou loop, on a l’impression qu’on s’oriente vers un fonctionnement où l’humain ne fournit que les specs, et où même la revue ou la QA sont gérées automatiquement par des IA entre elles.

gcback 2026-02-19

Je suis d’accord.

Au final, le niveau de contrôle et de vérification finira lui aussi par devenir supérieur chez l’IA à celui des humains, donc il sera probablement inévitable que son coût devienne inférieur à celui de la responsabilité actuellement assumée par les humains.

Que ce soit l’humain ou l’IA, c’est un jeu où, statistiquement, celui qui fait le moins d’erreurs l’emporte.

github88 2026-02-19

La démocratisation du rôle de réalisateur ? mdr. On devient réalisateur parce qu’on en a les qualités, pas pour faire réalisateur quand on ne les a pas.

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

Résumé essentiel

Résumé détaillé

À lire aussi

14 commentaires