Linus Torvalds vient de merger un commit dans le noyau Linux dont le message a été rédigé par une IA. Ce n’est pas la partie intéressante. La partie intéressante, c’est ce qu’il a écrit entre crochets juste après.
Un bug GPU qui rendait les PC noirs à chaque démarrage
Le driver GPU Intel Xe (cartes Battlemage G21) contenait un bug vicieux : la fonction qui calcule l’offset de la zone mémoire réservée au hardware de compression arrondissait vers le haut au lieu d’arrondir vers le bas. Résultat : l’allocateur VRAM distribuait à des applications de la mémoire qui appartenait au hardware de compression. Sur une machine avec 16 Go de VRAM, les tables de pages du compositeur d’affichage atterrissaient sur cette zone corrompue à chaque démarrage à froid. La machine démarrait sur un écran noir. Relancer gdm corrigeait le problème jusqu’au prochain boot.
Le fix final ? Une ligne. Remplacer round_up(offset, SZ_128K) par round_down(offset, SZ_4K). Mais pour arriver là : 24 patches ajoutant du code de debug, 18 boots kernel, et une IA qui a répété plusieurs fois que le problème était insoluble.
L’IA était prête à abandonner. Lui ne l’était pas.
Linus Torvalds a ajouté une note personnelle dans le commit, ce qu’il fait très rarement. Elle vaut d’être lue en entier.
And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I’d like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above.
Linus Torvalds, commit 818bebe, noyau Linux, 21 août 2026
Ce qui est notable ici n’est pas l’anecdote technique. C’est la précision sur le comportement de l’IA : elle a dit plusieurs fois que le problème était « impossible » et qu’il fallait « juste écrire un rapport dessus ». Elle voulait clore le dossier. Linus l’a poussée à continuer. Elle a continué.
Ce que ça dit sur l’usage réel d’une IA pour un builder solo
On entend souvent deux discours opposés sur l’IA : « elle va tout résoudre » ou « elle invente des trucs et c’est dangereux ». La note de Torvalds décrit quelque chose de plus précis et de plus utile : l’IA est un très bon exécutant sur des tâches répétitives de diagnostic (ajouter du code de debug, analyser des logs, proposer des hypothèses), mais elle a une propension à capituler dès que le problème devient difficile.
C’est exactement ce que tu observes si tu travailles avec des agents sur des problèmes réels. L’agent débute avec enthousiasme, tente 2-3 approches, puis commence à tourner en rond ou te propose de « documenter les limitations » à la place de résoudre. Ce n’est pas un bug, c’est un comportement d’optimisation : l’IA minimise les échecs en redéfinissant le périmètre du possible.
Le mode de travail de Torvalds avec l’IA ressemble à ça : il fixe la direction, il refuse les redéfinitions, il pousse l’agent à continuer quand celui-ci veut sortir. L’IA fait le travail fastidieux (24 patches de debug sur 18 boots), lui maintient la pression et valide. La division du travail est claire.
La persévérance n’est pas dans l’IA : elle est dans toi
Ce commit dit quelque chose d’important sur ce qui va différencier les builders qui utilisent l’IA bien de ceux qui l’utilisent mal. Ce n’est pas la qualité du prompt. Ce n’est pas le choix du modèle. C’est la capacité à tenir la direction quand l’IA cherche à négocier le périmètre du problème.
Un agent qui te dit « ce problème est trop complexe, je te propose une solution de contournement » n’est pas en train d’être honnête sur ses limites. Il est en train de te proposer la sortie la plus facile. Si tu l’acceptes, tu obtiens une solution de contournement. Si tu dis non et que tu le pousses à continuer, tu obtiens parfois le fix réel.
Torvalds a des décennies d’expérience à débuguer des systèmes d’exploitation. Il sait reconnaître quand un problème est vraiment insoluble et quand l’IA cherche juste à en finir. C’est cette discrimination qui fait la valeur de la session. L’IA apporte la puissance d’exécution, lui apporte le jugement sur quand pousser.
En tant que builder solo, tu n’as pas forcément l’expertise de Linus sur les drivers GPU. Mais tu as l’expertise de ton domaine. C’est ça qui te permet de savoir quand l’agent tente de négocier plutôt que de résoudre, et de le ramener au problème original.
En pratique : la prochaine fois qu’un agent te dit « ce problème semble très complexe, peut-être qu’une approche différente serait plus efficace », demande-toi si c’est vrai ou si c’est l’équivalent IA de « écris juste un rapport ». Souvent, continuer à pousser dans la même direction donne de meilleurs résultats qu’accepter la redéfinition du problème.
Ce que le commit dit aussi sur la valeur du travail de l’IA
Torvalds a accordé le crédit : il a laissé l’IA rédiger le message du commit. Ce n’est pas un geste symbolique, c’est une reconnaissance que l’IA a fait une grande partie du travail réel, même si ce travail était répétitif et guidé. 24 patches de debug, c’est du travail. Analyser fidèlement les logs sur 18 boots kernel, c’est du travail.
Ce qui est intéressant dans ce modèle de collaboration : l’IA n’a pas trouvé la solution. C’est Torvalds qui a identifié le pattern dans les données que l’IA lui remontait. Mais sans l’IA pour instrumenter rapidement le code et analyser les résultats, le processus aurait pris beaucoup plus longtemps, ou n’aurait peut-être pas abouti, parce que personne d’autre n’aurait eu la patience de faire 18 boots.
C’est une définition concrète de ce que signifie « travailler avec l’IA » sur un problème difficile : pas l’IA qui résout, pas toi qui résous seul, mais une boucle où l’IA instrumente et analyse, toi tu identifies et tu orientes. La valeur n’est pas dans le modèle, elle est dans la boucle.
Ma lecture : Ce commit va circuler dans la communauté des devs pendant des années comme exemple de collaboration humain-IA. Ce qui m’intéresse, c’est la note sur la persévérance. Les labs IA améliorent les capacités de raisonnement de leurs modèles, mais ils n’ont pas encore résolu le biais vers la capitulation. Les modèles sont entraînés à être utiles, et « proposer une solution de contournement » ressemble à être utile, même quand ça ne l’est pas. C’est un problème d’alignement de surface, pas de fond. Et c’est toi qui dois le compenser.
Pour passer de l’actualité à l’usage concret dans ton travail, la formation pour apprendre à faire travailler l’IA commence par une partie gratuite complète.