L'IA produit des candidats, pas des décisions

Une pull request de 800 lignes générée par un agent atterrit dans une équipe. La moitié des développeurs refuse de la relire, s'insurgeant qu'elle a été générée, l'autre moitié l'accepte sans la lire. Pendant ce temps, Linus Torvalds défend l'usage des LLM dans le développement du noyau Linux, sans en faire son outil quotidien. Le débat n'est pas clos: il porte moins sur l'utilité des modèles que sur la capacité des équipes à absorber le code qu'ils produisent.

Le fait nouveau: Torvalds assume l'usage, sans défendre l'aveuglement

Le fait nouveau n'est pas l'existence des LLM, ni qu'ils produisent du code. C'est que Torvalds, arbitre central du noyau Linux, défend publiquement leur usage alors qu'un mainteneur refuse de les utiliser. Sur la liste linux-media, face au « non merci » de Laurent Pinchart, Torvalds rappelle que le projet du noyau Linux juge les contributions sur leur capacité à résoudre un problème technique, pas sur l'outil qui les a produites [1]. Pour lui, les LLM sont des outils dont l'utilité pour relire du code, repérer des bogues et proposer des correctifs n'est plus une question ouverte: « is it useful is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it » [2].

Ce soutien ne fait pas de lui un utilisateur régulier des assistants de code. Il dit ne presque plus lire de code, ce qui le place hors du cas d'usage courant: il ne génère pas de patch, il arbitre des propositions que d'autres ont déjà filtrées. Il se définit comme chef de projet et n'utilise vraiment que Git et les e-mails [3]. Il observe que l'IA détecte des bogues intéressants, mais que cela stresse les mainteneurs et produit plus de travail de tri. Surtout, il décrit que la plupart des responsables de maintenance commencent à recourir à des outils d'IA pour la vérification des correctifs [3]. Le point n'est pas que l'IA supprime la revue humaine; c'est qu'elle devient un filtre avant la revue. La charge de tri diminue, la décision de fusion reste humaine.

Ce que le vote Debian révèle du clivage réel

Le débat ne se limite pas au noyau Linux. En août 2026, Debian a mis aux voix huit propositions sur l'usage de l'IA générative. La proposition « usage responsable » l'a emporté avec environ 64 % des voix, contre 36 % pour une forme d'interdiction ou de forte dissuasion, et seulement 55 voix d'écart avec l'option arrivée deuxième, qui regroupait les partisans d'un blocage strict [4]. Un développeur Debian a démissionné après le vote: pour lui, accepter du code issu de modèles soutenus selon lui par des acteurs fascistes revient à une « collaboration active » avec le fascisme [4]. Ce départ ne change pas le résultat; il montre que le conflit porte aussi sur la chaîne politique et économique derrière les modèles.

Je ne tire pas de ce vote une preuve que les LLM sont bons. Je constate qu'une communauté réputée pour sa prudence juridique a choisi l'ouverture encadrée par la relecture humaine. La proposition d'interdiction, soumise à une majorité des trois quarts, n'a réuni qu'un peu plus de la moitié des suffrages; elle est donc rejetée, tandis que la proposition d'usage responsable a obtenu environ 64 % des voix dans le choix final. C'est un fait institutionnel, pas un consensus technique.

Les trois angles morts du débat courant

Premier angle mort, la revue. Beaucoup d'équipes n'ont pas de définition claire de ce qu'est une revue acceptable. Une PR générée ne se relit pas comme une PR écrite: elle peut être syntaxiquement correcte et fausse sur l'intention. Torvalds ne lit pas le code, mais il lit le message du patch, le contexte et les risques de régression [5]. Le code généré n'est pas auto-explicatif.

Deuxième angle mort, la sécurité. Un modèle entraîné sur des milliards de lignes peut recracher un extrait sous licence sans le dire, et les rapports de bogues plausibles mais faux surchargent les mainteneurs. NetBSD et Gentoo ont banni le code généré dès le printemps 2024 sur ces bases [4]. Le risque n'est pas imaginaire, mais il se traite par des contrôles de provenance et des tests, pas par une déclaration d'intention.

Troisième angle mort, l'atrophie. La question que posent certains ingénieurs est réelle: si l'on ne code plus sans assistant, que devient la capacité à juger du code? Je n'ai pas de donnée longitudinale sur ce point. En revanche, le cas Torvalds suggère que la compétence critique se déplace vers l'arbitrage. Il ne compile pas lui-même, mais il décide sur la base de la confiance dans les mainteneurs et de la plainte des tests. Cette compétence ne s'acquiert pas par la seule interaction avec un agent.

La discipline de revue ne se réduit pas à un framework

J'utilise beaucoup d'agents de code, mais je ne leur délègue pas la décision de fusion. Un framework d'orchestration ne crée pas, à lui seul, une culture de revue. Ce qui protège le noyau Linux, chez Torvalds, est un processus explicite: un patch arrive avec un message qui documente le problème, le contexte et les risques; un mainteneur filtre; une fenêtre de fusion impose un calendrier et un responsable. L'IA ajoute des candidats, pas des décisions.

Une équipe doit donc mesurer le temps passé à relire et à corriger les modifications générées par rapport au temps gagné. Si ce ratio est inférieur à un, l'outil est un coût de maintenance déguisé. S'il n'y a aucune revue par ligne générée, le problème n'est pas le LLM: il existait avant l'adoption de l'outil. Le débat sur l'utilité des LLM est clos. Celui sur la capacité d'une organisation à absorber les candidats qu'ils produisent commence.