Le développeur, réviseur plutôt que producteur

Pendant longtemps, écrire du code était le cœur visible du métier : on produisait des lignes, et c'est en les produisant qu'on pensait le problème. L'IA renverse ce centre de gravité. Elle rédige le squelette, le brouillon, les tests candidats ; ce que le développeur fait de plus en plus, ce n'est plus produire ce code, c'est le réviser. Le déplacement n'est pas un truc d'outillage : c'est un changement de rôle, presque d'identité. Et il porte un piège précis. Là où produire vous forçait à réfléchir, réviser peut se faire mollement — d'un œil, en tamponnant un code fluide qui « a l'air juste ». Ce volet parle de cette bascule : devenir réviseur de référence sans laisser la revue se vider de son jugement.

Le centre de gravité du métier a basculé

Produire du code n'a jamais été qu'un moyen. Mais c'était un moyen exigeant : pour écrire une fonction, il fallait la comprendre, choisir sa structure, anticiper ses cas limites. Le jugement vivait dans la frappe — chaque ligne écrite était une micro-décision. Quand l'IA prend en charge la production, ce jugement ne disparaît pas ; il doit changer de place. Il migre de l'écriture vers la revue (Fig. 1). Le développeur cesse d'être d'abord un producteur pour devenir un réviseur de référence : celui qui lit ce que la machine a produit, le juge, et décide s'il entre dans la base. C'est le prolongement direct du fil rouge posé dès « écrivons-nous encore du code ? » — moins à la main, autant par l'esprit — mais vu ici sous l'angle du rôle : ce que le métier devient quand la production se délègue.

Cette bascule n'est pas inédite. L'automatisation l'a déjà imposée à d'autres métiers, et une analyse fondatrice l'avait anticipée. Dès 1983, dans « Ironies of Automation » (Automatica, vol. 19, n° 6), Lisanne Bainbridge décrivait un paradoxe : automatiser la production ne supprime pas le rôle humain, elle le transforme en surveillance — et cette surveillance demande plus de compétence, pas moins. Sa formule est nette : « on peut soutenir que l'opérateur doit être davantage qualifié que la moyenne, et non moins ». Transposée au développement, la leçon est frappante : déléguer la production à l'IA ne rend pas le développeur superflu, elle déplace son effort vers un acte — réviser — qui exige un discernement au moins égal à celui qu'il fallait pour produire.

Réviser mollement : le biais d'automatisation

Le danger de cette bascule n'est pas de mal produire — c'est de mal réviser. Et la façon de mal réviser a un nom précis (Fig. 2). Face à un code généré, net, plausible, bien indenté, la tentation est de le lire d'un œil et de l'approuver parce qu'il « a l'air juste ». Ce réflexe est documenté. Le profil « IA générative » du NIST (AI 600-1) le décrit sans détour : « avec le temps, les humains peuvent trop se fier aux systèmes d'IA générative ou percevoir à tort leur contenu comme de meilleure qualité que celui produit par d'autres sources. Ce phénomène est un exemple de biais d'automatisation, ou de déférence excessive envers les systèmes automatisés. » Réviser mollement, c'est exactement cela : céder à la fluidité de la sortie au lieu de la juger.

Le référentiel OWASP le pointe du même doigt. Dans son Top 10 des risques des applications à base de grands modèles de langage, l'entrée « LLM09:2025 Misinformation » définit la surconfiance en une phrase : « La surconfiance survient lorsque les utilisateurs accordent une confiance excessive au contenu généré par un modèle, sans en vérifier l'exactitude. » Or ce qui rend la fluidité si trompeuse, c'est qu'elle ne signale rien. Une étude de l'université Stanford présentée à l'ACM CCS 2023, « Do Users Write More Insecure Code with AI Assistants? » (Perry, Srivastava, Kumar, Boneh), l'a mesuré : les participants équipés d'un assistant « écrivaient un code nettement moins sûr » — et, plus troublant, « étaient plus enclins à croire qu'ils avaient écrit un code sûr ». Le code paraissait juste ; il ne l'était pas. Un réviseur qui se fie à cette apparence hérite du même faux sentiment de sécurité. C'est le même angle mort que la dette de compréhension : plus l'aide arrive fluide et sans friction, moins on s'arrête pour la juger vraiment.

Le muscle qui s'atrophie

Il y a une seconde ironie, plus sournoise, dans cette bascule. En déléguant la production, on cesse de pratiquer le geste par lequel on affûtait son jugement. Or ce jugement est précisément ce dont la revue a besoin. Bainbridge l'avait posé pour les opérateurs industriels, et la phrase se lit aujourd'hui comme un avertissement pour le développement : « les compétences physiques se dégradent lorsqu'elles ne sont pas utilisées. » Elle ajoutait un constat qui résonne encore plus fort : les systèmes automatisés d'alors étaient « surveillés par d'anciens opérateurs manuels, dont ils exploitent les compétences — que les générations suivantes d'opérateurs ne pourront pas avoir ». Un développeur qui n'a jamais écrit lui-même ce qu'il révise juge sur un capital de compétence qu'il ne renouvelle plus.

La conséquence pratique n'est pas de refuser l'IA, mais de traiter la revue comme l'endroit où l'on entretient ce muscle, au lieu de le laisser fondre. Lire un code généré en se demandant « comment l'aurais-je écrit, et pourquoi celui-ci diffère ? » est un exercice actif, pas un tampon. C'est aussi pourquoi spécifier avant de générer et juger les tests à l'ère de l'IA restent des compétences à cultiver : elles obligent à penser le problème et le critère de réussite, exactement ce que la simple production déléguée cesse d'entraîner. Le réviseur qui garde la main sur ces gestes reste capable de juger ; celui qui les abandonne devient dépendant d'une sortie qu'il n'a plus les moyens de contester.

Répondre de ce que l'on fusionne

La bascule de rôle se referme sur un point non négociable : la responsabilité. Produire du code se délègue à l'IA ; en répondre, non. Le droit le formule d'ailleurs dans les mêmes termes que le génie logiciel. Le règlement européen sur l'IA, à son article 14, impose que les systèmes à haut risque puissent être supervisés par des personnes physiques, lesquelles doivent pouvoir « décider […] de ne pas utiliser le système, ou d'ignorer, passer outre ou inverser sa sortie », tout en restant conscientes de « la tendance à se fier ou à trop se fier automatiquement » à ce que produit un système — le biais d'automatisation, nommé jusque dans la loi. Transposé au poste de travail : accepter un code généré est une décision, jamais une formalité. Le réviseur peut toujours l'écarter — et c'est précisément ce pouvoir qui fonde sa responsabilité.

Le fil rouge de la série tient donc ici encore : l'IA déplace le travail, pas la responsabilité. Le centre de gravité passe de produire à vérifier — et cette vérification, la revue, devient le lieu où le développeur exerce ce qui reste irréductiblement son métier : comprendre, juger, décider, répondre. C'est un point de passage humain au même titre que les nœuds de vérification humains que la série cartographie. Un outil qui produit en deux secondes ne vous dispense pas de la seule question qui, elle, n'a pas de raccourci : ce code, l'ai-je vraiment jugé, et suis-je prêt à en répondre ? Devenir réviseur plutôt que producteur, ce n'est pas travailler moins : c'est déplacer sa vigilance là où elle compte désormais.