Le jour où on a failli shipper une clé API en production
On était un vendredi soir. Un développeur avait pushé un fix urgent pour un client. Le code marchait, les tests passaient, la PR avait l'air propre. Sauf qu'il y avait une clé API Stripe hardcodée dans un fichier de config. En clair. Dans le repo.
Notre reviewer automatisé l'a détectée 45 secondes après le push. Quarante-cinq secondes. Le temps que le développeur ouvre Slack pour demander une review, le bot avait déjà commenté la ligne exacte avec un message sans ambiguïté : "Secret détecté. Merge bloqué."
C'est ce jour-là que j'ai arrêté de considérer l'automated code review comme un nice-to-have.
Pourquoi on a automatisé nos revues
Avant, nos revues de PR prenaient en moyenne 4 heures. Pas parce que le code était complexe, parce que les reviewers étaient occupés. Un développeur ouvre une PR à 10h, le reviewer la regarde à 14h, laisse trois commentaires sur du formatting, un sur un nom de variable, et un vrai commentaire d'architecture. Le développeur corrige, re-push, et attend encore 2 heures pour l'approbation.
Quatre heures pour ce qui aurait dû prendre 20 minutes. Multiplié par 8 à 12 PRs par jour selon les projets. Le calcul était simple : on perdait entre 30 et 50 heures par semaine en friction de review.
Le problème n'était pas la compétence des reviewers. Le problème, c'était qu'on leur demandait de faire un travail qu'une machine fait mieux et plus vite : vérifier le formatting, scanner les patterns interdits, compter la couverture de tests.
Les règles globales : le CLAUDE.md et les hooks
La première chose qu'on a mise en place, c'est un fichier de règles globales. Chez nous, c'est le CLAUDE.md. Chaque repo en a un. Il contient les conventions du projet : style de code, patterns autorisés, patterns interdits, seuils de couverture, règles de nommage.
Mais un fichier de règles ne sert à rien si personne ne le lit. Alors on l'a rendu exécutable. Chaque règle est associée à un check CI qui s'exécute automatiquement sur chaque PR.
Concrètement, nos checks vérifient :
- Sécurité : aucun secret, aucune clé API, aucun mot de passe dans le code. On utilise des scanners de secrets qui bloquent le merge immédiatement. Pas de warning, pas de "à corriger plus tard". Bloqué.
- Conventions de nommage : les fichiers, les variables, les fonctions suivent les patterns définis dans le CLAUDE.md. Un composant React qui s'appelle `data_handler` au lieu de `DataHandler` ? Rejeté.
- Couverture de tests : chaque PR doit maintenir ou améliorer le seuil de couverture. Chez nous, c'est 80% minimum sur le code modifié. Pas négociable.
- Patterns interdits : `console.log` en production, `any` en TypeScript sans justification, imports circulaires, fichiers de plus de 400 lignes. Tout ça est détecté et commenté automatiquement.
- Taille de PR : au-delà de 500 lignes modifiées, la PR est flaggée. Pas bloquée, mais flaggée. Les grosses PRs cachent des bugs. C'est un fait.
Ces hooks pre-merge tournent en moins de 90 secondes. Le développeur a un retour avant même d'avoir quitté son terminal.
L'IA comme premier reviewer
Les checks CI attrapent les violations mécaniques. Mais il y a une couche au-dessus : la review contextuelle. C'est là que les reviewers IA entrent en jeu.
On utilise Claude et CodeRabbit sur nos repos. Dès qu'une PR est ouverte, le reviewer IA analyse le diff complet et laisse des commentaires en moins de 2 minutes. Il détecte les bugs potentiels, les edge cases non couverts, les incohérences avec le reste du codebase.
Ce qui est intéressant, c'est la complémentarité. L'IA est excellente pour repérer un `null` non géré dans une fonction qui reçoit des données d'une API. Elle est excellente pour dire "cette fonction fait 3 choses, il faudrait la découper". Elle est excellente pour rappeler qu'un test manque pour le cas d'erreur.
Elle est mauvaise pour juger si l'architecture d'un module est la bonne. Elle est mauvaise pour savoir si ce refactoring va poser un problème de performance dans 6 mois. Elle est mauvaise pour comprendre le contexte métier qui explique pourquoi ce code "bizarre" est en fait correct.
C'est pour ça qu'on garde des reviewers humains.
Le workflow concret
Voici comment ça se passe, du push à l'approbation :
- Le développeur ouvre une PR.
- En 30 secondes, les checks CI tournent : linting, sécurité, couverture, conventions.
- En 2 minutes, le reviewer IA analyse le diff et laisse ses commentaires inline.
- Le reviewer humain arrive sur une PR déjà annotée. Les problèmes mécaniques sont résolus ou flaggés. Il peut se concentrer sur ce qui compte : la logique métier, l'architecture, les choix de design.
- Le reviewer humain approuve ou demande des changements. Sur les points qui comptent vraiment.
Résultat : le temps moyen de review est passé de 4 heures à 1h20. Les commentaires des reviewers humains sont passés de 60% syntaxe / 40% substance à 10% syntaxe / 90% substance. La qualité des discussions en review a augmenté parce que les humains ne perdent plus leur énergie sur des détails que la machine gère mieux.
Trust but verify
J'entends souvent deux positions extrêmes. Il y a ceux qui veulent tout automatiser, "si l'IA dit que c'est bon, on merge". Et il y a ceux qui ne font confiance à rien, "un bot ne comprend pas mon code".
Les deux ont tort.
100% de review automatisée est un fantasme. Vous avez besoin d'humains pour les décisions d'architecture, pour le contexte métier, pour les choix qui vont impacter la dette technique dans deux ans. Aucune IA ne sait ça aujourd'hui.
Mais 80% de review automatisée pour la syntaxe, les patterns et la sécurité ? Ce n'est pas de l'innovation. C'est de la discipline. C'est comme utiliser un correcteur orthographique avant d'envoyer un email important. Personne ne dit "je fais confiance à mon orthographe, pas besoin de relecture". Enfin, presque personne.
Notre approche, c'est "trust but verify". On fait confiance au système automatisé pour les 80% mécaniques. Et on vérifie avec des humains pour les 20% qui demandent du jugement.
Ce qu'on a appris
Trois choses qu'on n'avait pas prévues :
Premièrement, les développeurs écrivent mieux quand ils savent qu'un bot va relire. Ce n'est pas de la peur, c'est un feedback loop. Quand tu sais que chaque `console.log` oublié va te revenir en commentaire en 30 secondes, tu arrêtes de les laisser traîner. En six mois, le nombre de violations détectées par PR a baissé de 70%.
Deuxièmement, les reviewers humains sont plus heureux. Personne n'aime passer 20 minutes à compter les espaces et vérifier les imports. Quand on leur enlève ce travail, ils peuvent faire ce qu'ils font le mieux : penser.
Troisièmement, la confiance dans le code livré a augmenté. On dort mieux. Parce qu'on sait que chaque ligne qui arrive en production a été scannée pour les secrets, vérifiée pour la couverture, et relue par un humain qui avait le temps de réfléchir au lieu de compter les points-virgules.
Comment commencer
Si vous n'avez rien en place, commencez par trois choses :
- Un scanner de secrets dans votre CI. C'est non négociable. Un secret en production coûte plus cher que six mois de tooling.
- Un linter avec des règles strictes et un check bloquant. Pas des warnings. Des erreurs.
- Un reviewer IA, Claude, CodeRabbit, peu importe, qui tourne sur chaque PR et laisse des commentaires avant le reviewer humain.
Ça prend une journée à mettre en place. Ça vous fait gagner des centaines d'heures par trimestre. Et ça vous évite de shipper des clés API un vendredi soir.