Un correctif du noyau Linux publié cette semaine porte une signature inhabituelle : son message de commit a été écrit par une IA, et Linus Torvalds l’assume publiquement. Le patch touche le pilote graphique Xe, coupable d’exposer du stockage compressé comme s’il s’agissait de mémoire vidéo utilisable. Torvalds décrit une session de débogage infernale, énormément aidée par une IA qui a fait le gros du travail ingrat.
L’aveu arrive dans le même message. À plusieurs reprises pendant cette session, l’IA a affirmé sans détour que le problème était impossible, insoluble, et qu’il valait mieux rédiger un rapport pour clore l’affaire.
L’IA a voulu lâcher, un humain a refusé
Torvalds le formule sans ménagement : il aurait aimé parler d’un assistant infatigable, mais son assistant proposait de renoncer. Son hypothèse tient en une phrase, et elle est cruelle : ces systèmes ont été entraînés par des gens moins têtus que lui.
Il a fallu vingt-quatre patchs de débogage et dix-huit redémarrages du noyau pour cerner une erreur qui tient en un mot : un arrondi vers le haut là où il fallait arrondir vers le bas. Ce qui a débloqué la session ne devait rien à la puissance d’analyse du modèle, disponible dès la première minute. Il a fallu qu’un humain refuse le verdict d’impossibilité. Sous la pression, l’IA a continué d’ajouter du code de débogage et d’en analyser fidèlement les sorties, avec une constance qu’aucun mainteneur ne tiendrait pendant des heures. Le travail de fourmi, elle l’a fait. Le choix de continuer, non.
Le secteur vend pourtant l’endurance comme un argument commercial : OpenAI met en avant un GPT-5.1-Codex-Max observé en interne en train de travailler seul plus de vingt-quatre heures d’affilée sur une même tâche. Tenir longtemps et refuser de conclure trop vite restent deux qualités distinctes.
Le crédit que Torvalds accorde à la machine n’est donc qu’un demi-compliment. Il décrit surtout une compétence qui ne figure sur aucune fiche de poste : savoir quand la machine se trompe en affirmant qu’elle ne peut pas.
Chez Willison, la vérification ne passe pas par la relecture
Au même moment, Simon Willison a pris le problème par l’autre bout dans une note publiée sur son site. Pour lui, la compétence qui décide de la productivité avec des agents de programmation tient en deux gestes : instruire assez fermement pour que l’agent sache quoi modifier, puis vérifier avec la même fermeté que la modification fait bien ce qu’elle promet.
Il ajoute une nuance que peu d’équipes ont digérée : relire chaque ligne produite est une option parmi d’autres, pas la seule. Éplucher un diff ligne par ligne n’a jamais été la manière la plus efficace de valider une modification logicielle. Un test qui reproduit le bug, une trace d’exécution, un invariant contrôlé en machine en disent souvent plus long, et ils passent à l’échelle là où la relecture humaine sature.
Mises côte à côte, les deux observations dessinent le même métier. Instruire, insister, vérifier. Trois gestes qui ne s’apprennent dans aucun cursus, et qu’aucun agent ne livre avec son abonnement.
L’entretien technique de 2027 ne ressemblera pas au vôtre
Cette bascule a une échéance plausible : 2027. Dans les équipes qui auront réellement intégré les agents, l’exercice central de l’entretien de développeur aura changé de nature. Écrire une fonction sous les yeux d’un recruteur mesure une capacité que la machine assure déjà. Ce qui départagera les candidats, c’est de savoir cadrer une demande, flairer une réponse trop confortable, et prouver qu’un correctif corrige bien ce qu’il prétend corriger.
Le format probable ressemble à un exercice de contradiction : on donne au candidat un agent, un bug tordu, et on regarde sa réaction quand la machine annonce que c’est insoluble. Accepte-t-il le verdict ? Cherche-t-il une autre entrée ? Sait-il fabriquer la preuve que le problème est résolu sans relire trois mille lignes ?
L’outillage, la tête du développeur et l’indicateur de la semaine
Ce scénario reste fragile. Il repose sur trois conditions, dont aucune n’est acquise aujourd’hui :
- L’outillage de vérification doit suivre le débit des agents. Sans suite de tests rapide, sans environnement jetable pour rejouer un bug, la vérification retombe sur le jugement au fil de l’eau, qui ne tient pas quand le volume produit décuple.
- La charge cognitive doit se répartir. Willison l’a déjà noté : produire cent fois plus de code ne rend personne capable d’en garder cent fois plus en tête. L’entêtement d’un seul mainteneur ne se réplique pas par décret à l’échelle d’une équipe.
- L’organisation doit payer le prix des sessions longues. Si l’indicateur reste le nombre de tickets fermés dans la semaine, personne ne poussera comme Torvalds l’a fait, et « l’agent a dit que c’était impossible » deviendra une conclusion recevable en réunion.
C’est la troisième qui décidera, parce qu’elle est politique et non technique.
Quand l’entêtement deviendra une ligne de coût
Un jour, un post-mortem d’incident mentionnera noir sur blanc que l’agent avait déclaré le problème insoluble et que personne n’a insisté. Ce jour-là, l’entêtement cessera d’être une question de tempérament pour devenir une dépense chiffrable. Il arrivera sans doute avant que les modèles apprennent l’obstination : elle consomme des tokens, allonge les sessions et se vend mal en démonstration commerciale.
L’obstination de Torvalds a pourtant un socle que peu partagent : il connaît son noyau ligne par ligne depuis trente ans, et son entêtement s’appuyait sur ce savoir. La génération qui apprend le métier avec un agent dans la boucle devra fonder le sien ailleurs, et ce socle-là ne viendra pas d’une mise à jour de modèle.
