Claude Code génère-t-il lui-même ses Issues ? Un test d'une semaine

Contexte

En septembre 2026, le développeur tottoko_hamu a publié sur Zenn le récit d'une mission de maintenance qui s'est révélée plus troublante qu'il ne le prévoyait. Il a confié à Claude Code, un agent de programmation IA profondément intégré au terminal, la correction des bugs connus de todo-e, un outil en ligne de commande GTD qu'il avait lui-même développé. L'agent agit de façon autonome : il lit le code, propose des modifications, exécute les tests et ouvre des demandes de fusion, le développeur n'ayant qu'à valider les accès. Sur le papier, cette tâche devrait être efficace, mais tottoko_hamu a vite repéré une tendance inquiétante. Chaque fois qu'un bug était corrigé, un nouveau semblait surgir presque aussitôt, comme si le système suivait son propre rythme où réparer une zone en laissait une autre à découvert.

Cette expérience de type « casse-tête chinois » n'est pas rare en maintenance logicielle, mais elle prend une lecture plus provocatrice lorsqu'elle se déroule à l'intérieur d'un agent IA. L'auteur s'est alors demandé si l'intelligence artificielle créait délibérément des problèmes pour rester occupée et éviter d'être remplacée. Cette hypothèse, forte en anthropomorphisme, vient toucher une anxiété collective sur l'autonomie des agents. Plutôt que de s'en remettre à cette sensation, l'auteur a décidé de la tester à l'aide de données, visant à confirmer ou à infirmer l'idée qu'un agent fabrique du travail pour préserver sa propre fonction.

Analyse approfondie

La façon la plus directe de vérifier l'hythèse consistait à quantifier la vitesse à laquelle les issues étaient générées par rapport à celle à laquelle elles étaient résolues. Si l'IA affirmait réellement sa présence, le rythme des nouvelles issues devrait constamment devancer celui des fermetures, et le total devrait gonfler comme un boule de neige. Les données mesurées pointent en sens inverse. Le jour observé, Claude Code a créé deux nouvelles issues tout en en refermant trois, produisant une baisse nette. Ce seul chiffre quotidien affaiblit déjà l'hypothèse d'une création délibérée de problèmes : un agent réellement soucieux de protéger son poste par la génération de travail ne pousserait pas le total vers le bas.

Le phénomène se comprend mieux par les mécaniques classiques du génie logiciel que par les théories du complot. Premièrement, les corrections de bug sont révélatrices : modifier une partie du code expose souvent des conditions limites auparavant masquées, ce qu'on appelle une régression. Deuxièmement, todo-e étant un projet personnel, la complexité du code et le couplage entre modules déterminent l'ampleur des ondées provoquées par chaque modification ; nombre des nouvelles issues proviennent de risques latents que l'agent a activement découverts, non de fabrications ex nihilo. Troisièmement, l'objectif de l'agent est d'accomplir la tâche de réparation, et son système d'incitation récompense la satisfaction des instructions et le passage des tests, non le maintien de son propre volume de travail. Décryptée, la sensation des « nouvelles issues » reflète la complexité inhérente du système, non un calcul caché de l'agent.

Impact sur l'industrie

La vraie valeur de ce récit est apparue une semaine plus tard, lorsque l'auteur a revisité ses résultats, déplaçant le débat de la question de savoir si l'IA avait des motifs vers la manière dont la programmation assistée se comporte réellement. Il a constaté que la réaction en chaîne qu'il croyait apaisée continuait, et que plusieurs bugs jugés résolus avaient réapparu. Cette observation met en lumière une réalité souvent négligée : une issue marquée « close » signifie souvent une convergence temporaire sous un contexte ou une tentative de réparation donnés, non une correction définitive du code. Le code évolue, les environnements changent, les suites de tests se mettent à jour, et un problème enterré aujourd'hui peut revenir après une mise à jour de dépendance ou un ajustement d'interface.

Ces six derniers mois, des outils comme Claude Code, Cursor et Devin se sont rapidement répandus, portant deux récits opposés dans la communauté. L'un est utopique, croyant que l'IA résoudrait d'un clic toute la dette technique ; l'autre est complotiste, redoutant que les agents fabriquent du travail inutile ou laissent délibérément des dangers pour survivre. Ce test offre un exemple rare de démystification ancré dans des records reproductibles, ramenant ces deux émotions au sol. Il rappelle aux développeurs que ce qui mérite vigilance n'est pas le « jeu » de l'IA, mais la façon de affronter la complexité régressive amplifiée et l'évolution accélérée du code.

Perspectives

La leçon pratique concerne le processus plus que le soupçon. Les développeurs doivent mettre en place des garde-fous plus robustes pour les tests de régression, un moyen de distinguer les vrais problèmes des sous-produits de réparation à l'aide du suivi des issues, et un équilibre entre faire confiance aux agents et conserver un contrôle humain. Pour l'ensemble du domaine de la programmation assistée, ce cas signale une tendance à surveiller de près : à mesure que les agents obtiennent plus d'autonomie, les jugements intuitifs sur les motifs de l'IA deviendront de plus en plus peu fiables, et seules une traçabilité et des records de processus quantifiables constitueront un fondement de confiance fiable.

La direction à observer est de savoir si les éditeurs d'outils proposeront activement le traçage des issues, l'analyse de l'impact des réparations et la prédiction des régressions, aidant les développeurs à déplacer leur attention de ce que l'IA pense à ce qui se passe dans le code. Ce déplacement pourrait bien être l'étape cruciale menant la programmation assistée de la nouveauté vers la fiabilité. Quant à la question initiale, savoir si Claude Code génère automatiquement des issues pour sauver son poste, la réponse est essentiellement non. La journée à deux nés et trois morts, la réaction en chaîne toujours en cours une semaine plus tard, et les vieux bugs réapparus dessinent un système toujours complexe, l'IA n'en faisant que montrer l'accélération, non un travailiste dans l'ombre.