J'ai demandé à Claude une correction d'une ligne de lint. Il m'a rapporté une CI morte depuis longtemps et un CVE patché en prime — les retombées ont éclipsé la tâche.
Sur le repo de how2claude, j'allais faire une petite série d'édits, et l'étape préalable c'était de faire passer le lint rubocop. J'ai screenshoté la CI rouge sur GitHub Actions et je l'ai envoyé à Claude.
Sa première phrase :
CI cassée. Je vais voir pourquoi.
Je m'attendais à ce qu'il lance rubocop, regarde les erreurs, les corrige. Ça n'a pas été ça.
Quelques minutes plus tard, il revient avec ça :
La CI était cassée depuis un moment (la run précédente du 12 avril a aussi échoué). Deux classes de problèmes :
Ce que je viens d'introduire : 2 violations RuboCop dans des fichiers de migration
Ce qui était déjà cassé :
- La CI n'a pas de postgres service configuré, donc test/system-test ne démarre même pas (problème d'infra, comme ça depuis 2 semaines)
- 61 violations RuboCop préexistantes (dans des fichiers que je n'ai pas touchés)
Je commence par les 2 que j'ai introduites.
Ce paragraphe mérite qu'on s'arrête une seconde dessus.
Ce que je lui ai demandé, c'était « répare rubocop ». En allant regarder l'historique de la CI, il a fait un truc que je n'avais pas demandé — il a rangé « pourquoi c'est cassé » dans deux cases : ce que j'ai introduit cette fois vs ce que le repo traînait déjà.
Je n'ai pas demandé cette classification. Il l'a faite quand même.
Des deux cases, c'est la deuxième qui est le vrai sujet :
db:test:prepare faisait connection refused à chaque runEn ses mots :
La run précédente du 12 avril a aussi échoué.
La CI était au rouge depuis trois semaines. Je pushais tous les jours. Chaque push affichait une CI rouge, mais comme je commit le plus souvent directement sur master et que je lance les specs en local, j'avais entraîné mon œil à traiter ce rouge comme du bruit de fond.
À la seconde où je demande à Claude de corriger un lint, il a tiré l'historique et m'a fourré sous le nez : « ça n'a pas commencé avec ton changement ».
Il a tout enchaîné dans la foulée :
✓ 63 violations RuboCop → 0 (autocorrect whitespace sur 17 fichiers)
✓ MCP gem CVE-2026-33946 → bundle update mcp, 0.9.0 → 0.14.0
✓ test/system-test sans postgres service → ajout d'un postgres:17 service container
✓ Les 241 tests passent toujours en local
✓ bundler-audit : No vulnerabilities found
Regarde la deuxième ligne. Il a bumpé la version du mcp gem de lui-même parce qu'il a vu que la nouvelle corrigeait un CVE. Je n'ai pas demandé. Il a juste vu l'avertissement en lançant bundler-audit et l'a embarqué.
La troisième ligne, c'est ce qui a vraiment réparé la CI : postgres:17 en service container dans la workflow, avec health check et DATABASE_URL.
Ensuite il a demandé sur la granularité des commits :
Deux commits ou un ?
chore(lint): rubocop autocorrect (whitespace only)fix(ci): add postgres service + bump mcp gem for CVE-2026-33946Ou un seul :
fix(ci): make CI green again?
J'ai répondu un mot — commit — soit : pars sur les deux séparés. Il a pushé.
La CI a relancé. Je lui ai dit de surveiller.
4 verts, system-test toujours rouge. Je regarde.
Après quelques sondages, il revient avec :
test/system/n'existe même pas — ce job lancetest:systemsans un seul system test. On supprime le job.
Je suis resté quelques secondes sur cette ligne.
test/system/, c'est le répertoire par défaut Rails pour les system tests. Je n'ai jamais écrit un seul system test dans ce projet, depuis le jour où je l'ai initié. Mais le ci.yml avait un job system-test qui tournait à chaque push et échouait à chaque fois, parce que bundle exec rails test:system ne trouvait pas le répertoire.
Ce job n'a pas cassé quand Claude a ajouté postgres. Il était cassé depuis le jour 1 du projet. J'avais supposé qu'il passerait au vert avec postgres — non, postgres n'était pas le problème. Le problème, c'est que ce job devait être supprimé.
Son troisième commit :
e1d91d1 chore(ci): drop system-test job
CI verte.
En regardant cette session :
Si je l'avais fait seul, je n'aurais fait que la 1 — parce que je voyais la CI rouge depuis trois semaines, mon œil était engourdi, et j'aurais dit « répare le lint et on passe ». Mon cerveau était entraîné à traiter ce rouge comme du décor.
Claude ne traîne pas cette habitude. Il n'a pas de mémoire « ça a toujours été comme ça » du repo. À chaque fois qu'il regarde la CI, il la regarde à neuf. C'est précisément l'avantage — ce que je ne voyais plus comme « cassé par défaut depuis longtemps », lui le voit.
Quand tu donnes une petite tâche à Claude, la retombée la plus précieuse, c'est souvent pas la tâche elle-même — c'est le check-up incident. Si pendant qu'il fait X il te signale « au passage j'ai vu que Y et Z sont cassés depuis un moment », ne traite pas ça comme du bruit. C'est le diagnostic.
Quelques petits réflexes que j'ai adoptés :
Fais-lui scanner le voisinage avant la petite tâche. Qu'il regarde l'historique CI avant de lancer lint. Qu'il voie quand le schema a été touché pour la dernière fois avant d'écrire une migration. Qu'il greppe la couverture de tests d'un controller avant de l'éditer. « Un coup d'œil avant de commencer » coûte presque rien et fait sortir des « attends, il y a un truc ici » assez souvent.
Quand il dit « deux classes de problème » ou « deux types de causes », c'est de l'organisation que tu n'as pas demandée. Stop, lis le paragraphe en entier. Saute pas.
Ne contourne pas le rouge de longue date. Je me disais « c'est un known issue, je verrai plus tard » à chaque push. « Plus tard » peut signifier dans trois ans. Laisser Claude le nettoyer en passant, parce qu'il est dans le coin, c'est beaucoup plus réaliste que de bloquer un créneau pour « aller réparer la CI ».
Les trois commits, encore une fois :
74a3ebf chore(lint): rubocop autocorrect — Layout cops only
76264ee fix(ci): add postgres service + bump mcp gem for CVE-2026-33946
e1d91d1 chore(ci): drop system-test job
Le premier, c'est ce que j'ai demandé. Le deuxième et le troisième, c'est ce qu'il a apporté tout seul. Ces deux-là valent largement plus que le premier.