L'IA se nettoie elle-même

Ton repo devient de plus en plus sale à chaque fois qu'un agent IA livre une fonctionnalité. Le code mort s'accumule. Des branches se cassent et restent là. Des patterns de nommage dérivent. Rien de tout ça n'est dramatique. Ça s'accumule juste, fonctionnalité après fonctionnalité, jusqu'à ce que la codebase soit plus lente à changer et plus effrayante à toucher.

Cet article présente une équipe de nettoyage qui s'occupe de tout ça pour toi, sur un planning, pendant que tu dors. Trois workflows. Un planificateur. Chacun prend un type de bazar différent et le gère discrètement. Tu te réveilles, tu lis un e-mail, et tu sais ce qui a été balayé, ce qui a été réparé, et ce qui nécessite encore un regard humain.

Les trois petits bazars qui deviennent de grands bazars

La plupart des problèmes de codebase ne commencent pas gros. Ils commencent petits et restent petits un moment. Puis quelques fonctionnalités plus tard, la petite version a des copies dans trois autres endroits, et le nettoyage prend une semaine au lieu d'une heure.

Voici les trois qui apparaissent le plus dans les repos lourds en IA.

1. Du code mort que personne ne supprime

L'agent livre une fonctionnalité. Une semaine plus tard tu livres une version différente de cette fonctionnalité. L'ancien code est encore là. Personne ne le supprime parce que personne n'est sûr si quelque chose l'utilise encore. Trois fonctionnalités plus tard, ton repo a trois helpers abandonnés, deux routes inutilisées, et une page entière vers laquelle aucun lien ne pointe plus.

Sur un projet moyen, le code mort atteint environ 18% du repo en quelques mois. C'est du code qui passe par les vérifications de type, le lint, le bundling, et qui est chargé à chaque build. Ça ralentit les cold builds, confond les nouveaux contributeurs, et rend les refactorings plus effrayants qu'ils ne devraient l'être.

Le problème n'est pas de trouver le code mort. Un linter peut faire ça. Le problème, c'est de le supprimer en toute sécurité. Tu dois savoir que supprimer le fichier ne casse vraiment rien. La plupart du temps, personne n'a la patience de vérifier ça ligne par ligne, donc le code mort reste.

2. Des branches cassées qui bloquent la livraison

Un run d'agent se termine. Il dit que la fonctionnalité est faite. Tu pull la branche le matin et le build est rouge. Erreur de type, test qui échoue, import manquant. Petite chose. Tu la corriges en dix minutes.

Sauf que tu fais ça plusieurs matins par semaine. Dix minutes ici. Vingt minutes là. Deux jours entiers par mois perdus à corriger un handoff cassé avant même de pouvoir commencer le vrai travail. Et si la casse atterrit sur main, chaque autre fonctionnalité attend dessus.

La correction est simple en théorie. L'agent devrait corriger sa propre casse. En pratique, ça signifie lancer les tests, lire l'erreur, modifier le bon fichier, et ne pas aggraver les choses en devinant. C'est une boucle que la plupart des agents ne peuvent pas fermer seuls sans structure supplémentaire.

3. Des patterns qui dérivent silencieusement

Tu as quatre fonctionnalités qui font toutes à peu près la même chose : auth, billing, notify, search. Elles suivent toutes un pattern. Même forme de dossier. Mêmes noms de fichiers. Même nommage pour les fonctions clés.

Puis une fonctionnalité dérive. L'agent nomme quelque chose légèrement différemment. Ou divise un fichier que les autres gardent ensemble. Ou saute un pattern que les autres partagent tous. Seul, c'est bien. Trois fonctionnalités plus tard, un nouvel agent voit celle qui a dévié et copie cette forme au lieu de l'originale. Tu as maintenant un fork dans ta propre codebase que personne n'a accepté.

La dérive est le bazar le plus coûteux des trois. Un fichier mort coûte une suppression. Une branche cassée coûte une matinée. Une dérive qui se propage dans trois autres fonctionnalités coûte un vrai refactoring sur tout le dossier.

L'équipe de nettoyage

Le système, c'est trois workflows Claude Code qui tournent sur un planning overnight. Tu peux les voir comme une équipe de nettoyeurs, chacun avec un job étroit.

Un planificateur réveille l'équipe la nuit. Il déclenche chaque workflow dans l'ordre. Chacun écrit une courte note dans un log partagé. La dernière étape assemble le log en un e-mail et te l'envoie.

Rien ne part sur main tout seul. Les modifications de slop-cleaner se font derrière des tests. /heal travaille sur une branche latérale, pas sur main. /drift signale seulement, il ne réécrit pas. Tu restes la personne qui accepte ou rejette le rapport du matin.

Nettoyeur un : slop-cleaner

Le job de slop-cleaner est de supprimer le code mort sans rien casser.

L'astuce, c'est l'ordre. La plupart des outils de code mort scannent, listent, puis laissent un humain supprimer. C'est lent parce que personne ne veut être la personne qui casse la prod en supprimant le mauvais fichier. Le workflow inverse l'ordre : écrire le filet de sécurité d'abord, puis supprimer, puis relancer le filet de sécurité.

Étape un, écrire les tests de régression. L'agent regarde les fichiers qui sont sur le point d'être touchés et écrit un petit test pour chacun qui a encore un appelant. L'objectif n'est pas une couverture complète. L'objectif est un signal vert qui dit "les parties qui comptent fonctionnent encore." Ces tests sont commités sur une branche latérale pour qu'un humain puisse les lire.

Étape deux, supprimer le code mort. L'agent utilise une vérification statique pour lister les candidats : fichiers avec zéro imports entrants, fonctions jamais appelées, routes sans liens, types jamais référencés. Il les supprime en petits lots.

Étape trois, relancer les tests. Si chaque test est encore vert, les suppressions tiennent. Si un test devient rouge, la suppression spécifique qui l'a causé est annulée. L'agent n'essaie pas de "corriger" le test. Il suppose que la suppression était mauvaise et la rollback. Rien de subtil.

Le résultat est un repo qui s'allège sans la peur habituelle. En un run overnight, l'équipe a supprimé 412 lignes de code mort dans un SaaS de taille moyenne. Zéro test cassé. Zéro page qui a arrêté de s'afficher. Le matin suivant, le reviewer a parcouru le diff, cliqué sur approuver, et est passé à autre chose.

Slop-cleaner ne fonctionne que si le filet de test est honnête. Si l'agent écrit de faux tests qui passent toujours, tout le pattern s'effondre. Le workflow applique une règle : chaque test doit appeler une vraie fonction et asserter une vraie sortie. Les tests qui n'importent jamais le fichier sous test sont rejetés.

Nettoyeur deux : /heal

Le job de /heal est de réparer les branches cassées sans mettre du code cassé sur main.

Quand /heal se réveille, il lit la liste des branches de fonctionnalités récentes. Pour chacune, il lance le build, la vérification de type, et la suite de tests. Si une branche est rouge, /heal commence à travailler dessus.

Le détail important : /heal travaille sur une branche latérale, pas sur l'originale. Il copie la branche cassée dans quelque chose comme heal/feature-name, fait ses modifications là, et laisse l'originale intacte. Main reste propre tout le temps. L'auteur original est toujours propriétaire de la décision de correction.

La boucle de correction est serrée. /heal lit le premier check qui échoue et pose une question : quel changement fait passer ce check spécifique ? Il modifie la plus petite surface possible, relance le check, et passe à l'échec suivant. Il ne refactorise pas. Il n'améliore pas. Il ferme seulement les signaux rouges.

Après la boucle, /heal lance tout à nouveau. Si toutes les vérifications passent, il note sa propre confiance sur une échelle de zéro à cent. Le score est basé sur des signaux simples : est-ce que la correction a touché un fichier de test ou un fichier source, combien de lignes ont changé, est-ce que les erreurs étaient claires et étroites ou vagues et larges, est-ce que le même test a échoué deux fois de suite avant de passer.

Puis /heal écrit un court verdict et l'envoie par e-mail. Le verdict inclut le nom de la branche, le score de confiance, les fichiers exacts modifiés, et une raison en une ligne. Quatre-vingt-douze pourcent de confiance, deux fichiers touchés, import manquant dans le handler. Ce genre de note.

Un humain décide toujours s'il faut merger. Une haute confiance avec un diff serré obtient généralement un oui. Une basse confiance ou un diff large obtient un regard plus attentif. L'objectif n'est pas de supprimer la revue humaine. L'objectif est de s'assurer que l'humain revoit une correction propre et étroite plutôt qu'une branche rouge brute.

Nettoyeur trois : /drift

Le job de /drift est de détecter la divergence de pattern entre les fonctionnalités récentes avant qu'elle se propage.

Quand /drift se réveille, il construit une carte des patterns de ta codebase. Il choisit un petit ensemble de fonctionnalités (généralement les cinq à dix dernières) et enregistre la forme de chacune : disposition des dossiers, noms de fichiers, noms de fonctions, style d'import, emplacement des tests. C'est un snapshot simple, pas une analyse profonde.

Puis il compare. Si quatre fonctionnalités ont la même forme et qu'une fonctionnalité est légèrement différente, celle-là est un outlier. /drift ne réécrit pas l'outlier. Il le signale.

Un signalement ressemble à ça : "notify utilise sendNotification alors que auth, billing, et search utilisent sendEmail. Dérive de nommage. Coûte 4x à corriger après trois autres fonctionnalités qui le copient." C'est assez spécifique pour agir dessus et assez vague pour laisser la décision finale à un humain.

Pourquoi signaler plutôt que corriger. Parce que la dérive n'est pas toujours mauvaise. Parfois l'outlier est le bon choix et les quatre autres sont le legacy. Un humain peut dire lequel est lequel. Un agent ne peut pas, parce que la règle change selon l'intention. Donc /drift fait le travail pour lequel un agent est doué (repérer le pattern) et laisse le jugement à toi.

La fenêtre critique est tôt. Si /drift attrape la dérive dans notify avant que trois autres fonctionnalités copient le pattern, la correction est un fichier. Si il l'attrape après, la correction est quatre fichiers plus la coordination entre équipes. C'est de là que vient le "coûte 4x à corriger."

Une nuit, un planning

Le planificateur est simple. Un déclencheur, une entrée style cron, déclenche à une heure fixe chaque nuit.

Quand il déclenche, une nouvelle session Claude Code démarre. L'orchestrateur lit l'état actuel du repo et lance les trois workflows dans l'ordre : slop-cleaner, puis /heal, puis /drift. Chacun écrit une courte note dans un log partagé à ./overnight.log.

L'ordre compte. Slop-cleaner tourne en premier parce qu'il rétrécit le code sous revue. /heal tourne en second parce qu'il répare ce qui est cassé maintenant. /drift tourne en dernier parce qu'il lit la version la plus propre du repo, après que les deux autres ont fait leur travail.

Chaque nettoyeur a un budget de temps. S'il tourne trop longtemps, le workflow termine cette étape et passe à la suivante. L'objectif est un e-mail du matin prévisible, pas une nuit parfaite. Le travail inachevé est signalé et repris la nuit suivante.

Rien dans ce setup ne nécessite une plateforme cloud. Une vraie entrée crontab sur ta machine fonctionne. Une tâche planifiée Claude Code Desktop fonctionne. Le choix est opérationnel, pas architectural. Ce qui compte, c'est que le déclencheur déclenche, qu'une nouvelle session se réveille, et que l'orchestrateur sait où commencer.

Le rapport du matin

La dernière étape du run overnight assemble le log en un e-mail et l'envoie. Le format est court, lisible d'un coup d'œil, et ordonné de "ne nécessite rien" à "nécessite une revue."

Un vrai log du matin ressemble à ça :

overnight.log - janitor crew
01:00  Slop-cleaner swept the repo
       412 dead lines removed. Tests green.

02:30  /heal rescued a broken branch
       Fixed on side branch. 92% confidence.

04:00  /drift caught a naming gap
       1 file out of pattern. Flagged.

07:00  Verdict emailed to you
       3 cleanups ready for review.

Tu le lis avec ton café. Quatre minutes, max. Chaque ligne a une heure, un court résultat, et un chiffre qui te dit à quel point le nettoyeur était confiant. Les nettoyages avec une haute confiance obtiennent généralement une approbation sur le champ. La dérive signalée obtient un coup d'œil rapide et soit un correctif soit "laisse ça, c'est intentionnel."

La forme de l'e-mail est le point. Court. Concret. Ordonné. Pas de résumés en prose. Pas de remplissage "l'agent a travaillé dur cette nuit." Tu veux savoir ce qui a changé, à quel point le nettoyeur est sûr, et ce que tu dois en faire. Rien d'autre.

Comment construire ta propre version

Tu n'as pas besoin de toute la stack pour obtenir le bénéfice. Le pattern est simple. Commence avec cette forme et étends-la.

Écris trois petits workflows. Garde-les étroits. Slop-cleaner supprime le code mort seulement si un test passe. /heal répare les branches cassées seulement sur une branche latérale. /drift signale la divergence de pattern seulement sur les fonctionnalités récentes. Chacun a un seul job et un seul format de sortie.

Mets-les derrière un planificateur. Cron, c'est bien. Une session Claude Code planifiée, c'est bien. Tu n'as pas besoin d'une file de jobs ou d'un bus de messages. Tu as besoin d'un ping qui réveille l'équipe à une heure fixe.

Écris les tests de régression avant la suppression, à chaque fois. C'est la règle qui rend slop-cleaner sûr. Si l'agent ne peut pas écrire un test honnête pour le fichier qu'il veut supprimer, la suppression ne se fait pas. Cette seule règle vaut tout le workflow.

Garde /heal sur une branche latérale. Main doit rester propre. Si la correction de /heal est mauvaise, la branche latérale est jetée et la branche cassée originale attend encore un humain. Pas de surprises sur main, jamais.

Fais signaler /drift, pas corriger. C'est la règle la plus difficile à tenir. Les agents veulent "améliorer" le code quand ils le voient. Pour la dérive, c'est le mauvais mouvement. Un pattern qui semble mauvais pourrait être intentionnel. Le job de l'agent est de le mettre en évidence et s'arrêter. Le job de l'humain est de décider ce que le pattern devrait être à l'avenir.

Termine chaque run avec un e-mail court et structuré. Heure, résultat, chiffre, raison en une ligne. Rien d'autre. Si tu ne peux pas parcourir tout l'e-mail en moins de cinq minutes, le nettoyeur fait trop de travail en une nuit. Divise-le.

Où else ce pattern s'applique

Une fois que tu as une équipe de nettoyage qui tourne sur du code, la même forme fonctionne pour d'autres types de bazar qui brûlent lentement.

Nettoyeur de contenu. Un workflow qui balaie les vieux posts de blog, signale les sections périmées, et écrit une note à l'auteur. Il ne réécrit pas. Il signale.

Nettoyeur analytique. Un workflow qui vérifie le nommage des événements dans tout ton produit pour détecter les dérives, signale les outliers, et propose une liste canonique. Même carte de patterns que /drift, entrées différentes.

Nettoyeur de dépendances. Un workflow qui scanne les packages inutilisés, écrit un test qui importe chacun des actifs, et supprime le reste si les tests passent encore. Même filet de sécurité que slop-cleaner, appliqué à package.json.

L'idée centrale n'est pas "l'IA nettoie le code." C'est "les petits bazars sont gérés sur un planning, derrière un filet de sécurité, dans un format que tu peux lire en cinq minutes." Ça fonctionne pour le code, le contenu, l'analytique, et tout ce qui s'accumule silencieusement entre les grands livraisons.

Une équipe. Un planning. Trois jobs étroits. Un repo plus propre le matin et un e-mail qui respecte ton temps. C'est tout le système.