Comment nous révisons le code écrit par l'IA (et pourquoi la révision intégrée de Claude ne suffit pas)

Les outils de codage IA écrivent une fonctionnalité qui marche en quelques minutes. Le problème n’est pas que le code soit mauvais. Le problème, c’est que personne ne vérifie comment tout s’emboîte. Chaque changement semble correct à lui seul. Six mois plus tard, l’application est lente à modifier, risquée à toucher, et personne ne sait pourquoi.

Nous réglons ça avec un système de révision en trois parties. Cet article l’explique deux fois : d’abord en mots simples pour les fondateurs, puis en détail pour les développeurs.

La version simple (pour les fondateurs)

Pensez à votre application comme à un bâtiment. L’IA est un constructeur très rapide. Elle monte des murs toute la journée, mais elle ne vérifie pas s’ils suivent le plan.

Notre système de révision, c’est l’inspecteur. Il fait trois choses :

1. Il vérifie chaque changement avant sa mise en ligne. Chaque fois qu’une fonctionnalité ou une correction est terminée, la révision cherche les bugs et compare le changement à nos 13 règles d’architecture — par exemple : « toute modification des données d’un client doit confirmer que ce sont bien ses données ». Si une règle est brisée, c’est corrigé avant la mise en ligne.

2. Il vérifie toute l’application une fois par semaine. Les petits problèmes se cachent dans le code que personne n’a touché récemment. Chaque semaine, la révision lit chaque fichier, lance chaque test et revérifie chaque problème trouvé, pour que vous ne couriez pas après de fausses alertes. Elle se souvient aussi de la liste de la semaine précédente et vous dit ce qui a été corrigé et ce qui reste ouvert.

3. Il vous dit comment votre application devrait être structurée. La plupart des applications construites vite n’ont pas de structure claire. La révision nomme la structure actuelle, signale les « fichiers fourre-tout » — un seul fichier qui en fait beaucoup trop — et recommande une structure simple pour chaque partie de l’application. Les écrans simples restent simples. Les parties risquées, comme la facturation et les connexions, reçoivent une protection supplémentaire.

Ce que vous recevez : un seul rapport, avec les problèmes classés du plus grave au moins grave, chacun avec le fichier exact et la correction. Pas de jargon. Si la même erreur revient souvent, le rapport le dit et propose une nouvelle règle pour que ça cesse.

Pourquoi c’est important : corriger un problème la semaine où il apparaît prend quelques minutes. Le corriger après six mois de code construit par-dessus prend des semaines.

La version technique (pour les développeurs)

Pourquoi la révision intégrée de Claude ne suffit pas

Claude Code inclut sa propre commande /code-review. Elle fait bien son travail : elle lit votre diff et trouve les bugs. Mais elle a trois limites :

• Elle ne connaît pas vos règles. Elle trouve des bugs, pas des violations de votre architecture. Elle ne signalera pas une route qui fait du travail de base de données directement, ni un UPDATE sans vérification de propriété, sauf si ça cause un bug évident.
• Elle ne voit que le changement. Les problèmes dans le code non touché cette semaine restent invisibles.
• Elle n’a pas de mémoire. Elle ne peut pas vous dire que la même erreur est apparue à quatre endroits ce mois-ci.

Notre système garde la force de la révision intégrée et comble ces trois limites.

Vérification 1 : pr-review — à chaque changement

S’exécute sur la branche ou le diff actuel avant la fusion. Explication complète : La compétence PR Review. Dans l’ordre :

1. Passe bugs. Un sous-agent neuf révise le diff : bugs, régressions, comportements cassés, tests manquants.
2. Passe architecture. Un deuxième sous-agent compare le diff aux 13 règles. Ce sont les mêmes règles que nous expliquons dans Comment empêcher l’IA de transformer votre app Next.js en chaos architectural — les routes ne font que coordonner, on valide à chaque frontière, chaque UPDATE/DELETE porte un prédicat user_id, la lecture-puis-écriture se fait dans une transaction avec FOR UPDATE, et ainsi de suite.
3. Passes spécialisées. Gestion des erreurs et échecs silencieux, lacunes de tests, et conception des types quand de nouveaux types apparaissent. Si les migrations ou le schéma ont changé, un audit du schéma et un audit du modèle de domaine s’exécutent aussi. Si des fichiers ont été supprimés ou renommés, une vérification du code mort s’exécute.
4. Un seul rapport. Tout est fusionné dans un fichier avec un verdict : Prêt à fusionner — Oui, Non, ou Avec corrections.
5. Correction des tests. Les tests manquants trouvés pendant la révision sont écrits, pas seulement listés.

Vérification 2 : full-review-weekly — toute l’application

Une révision de diff ne voit pas ce qui existe déjà. Une fois par semaine, cette vérification lit chaque fichier. Explication complète : La compétence de révision hebdomadaire.

• Vérifications d’outils. Lint, vérification des types, tests, vérification des migrations et npm audit. Chaque échec est noté comme constat.
• Tranches. Le code est découpé par dossiers. Chaque tranche reçoit une passe bugs et une passe des 13 règles, sur les fichiers complets.
• Passe de vérification. Un agent séparé rouvre le code pour chaque constat critique ou important et le marque confirmé ou fausse alerte. Seuls les constats confirmés comptent.
• Spécialistes. Sécurité, propriété des données et verrouillage, performance des requêtes (N+1, index manquants, sélections sans limite), schéma, frontières entre modules, frontières API et JSON, gestion des valeurs nulles, contrats d’erreur, types, lacunes de tests et code mort.
• Suivi. Les constats confirmés de la semaine précédente sont revérifiés : corrigés ou encore ouverts. Tout ce qui reste ouvert deux révisions de suite devient critique.
• Bilan des tendances. Quand la même catégorie d’erreur apparaît dans plusieurs parties de l’application, le rapport propose la formulation exacte d’une nouvelle règle — ou une nouvelle vérification automatique si une règle ne suffit pas.

La progression est sauvegardée après chaque étape. Une longue révision interrompue reprend là où elle s’est arrêtée au lieu de recommencer.

Vérification 3 : adéquation de l’architecture — quelle structure pour cette app ?

C’est la partie que la plupart des révisions oublient. Les règles disent ce qui ne va pas. Elles ne disent pas quelle forme l’application devrait avoir.

L’étape d’adéquation de l’architecture fait quatre choses :

1. Trouve votre modèle déclaré, s’il est écrit quelque part. Si oui, elle vérifie seulement les écarts.
2. Nomme la structure actuelle — avec les chemins de dossiers comme preuve.
3. Signale les fichiers fourre-tout. Un fichier est signalé quand il cumule deux de ces critères : plus de 400 lignes, plus de 15 exports, ou un mélange d’au moins deux éléments parmi l’affichage, les requêtes de base de données, les appels à des API externes et les règles d’affaires. Chacun vient avec un plan pour le découper sans risque.
4. Recommande une structure par domaine d’affaires quand aucune n’est définie — la plus simple qui convient.

Les options, de la plus simple à la plus lourde :

Structure	Bon pour
CRUD simple	Des écrans qui lisent et enregistrent des données
En couches	Séparer l’affichage, la logique et la base de données
Tranches verticales	Un dossier par fonctionnalité, avec tout ce qu’il faut dedans
Monolithe modulaire	Une seule app découpée par domaines (facturation, prospection, admin)
Clean / Hexagonale	Isoler la logique centrale des fournisseurs comme Stripe ou votre service de courriel
Conception pilotée par le domaine	Beaucoup de règles d’affaires qui changent souvent
Événementielle / CQRS	Vraies files d’attente et forte charge d’écriture
Microservices	Presque jamais pour une petite équipe

Pour la plupart des petites équipes SaaS, la réponse est un monolithe modulaire : du CRUD simple pour les écrans simples, et du Clean/Hexagonal seulement là où vivent l’argent, les connexions, l’IA ou les fournisseurs externes. Le rapport se termine par les trois premiers petits pas sûrs pour y arriver.

À quoi ressemble un constat

Chaque constat tient sur une ligne, pour que rien ne se perde :

gravité | catégorie | fichier:ligne | problème | correction

Par exemple :

critical  | ownership      | lib/invoices.ts:88    | UPDATE sans vérification user_id (R12)       | ajouter user_id au WHERE
important | simplification | app/dashboard/page.tsx:1 | fichier fourre-tout : 920 lignes, UI + BD + Stripe | découper avec un plan de refactorisation

Les catégories viennent d’une liste fixe — exactitude, sécurité, propriété, verrouillage, validation, gestion des erreurs, sûreté des types, performance, etc. — pour pouvoir suivre les tendances d’une semaine à l’autre.

Quelle vérification, quand

Situation	Utiliser
Fonctionnalité ou correction terminée	pr-review
Vérification rapide des bugs sur un petit changement	/code-review intégré de Claude
Bilan de santé hebdomadaire	full-review-weekly
App héritée ou construite par l’IA, sans structure claire	full-review-weekly — lisez d’abord la section sur l’adéquation de l’architecture

---

Obtenez le kit gratuitement

Nous donnons tout le système de révision. C’est un plugin Claude Code gratuit : les deux révisions, les 13 règles, et toutes les vérifications qu’elles utilisent. Dans Claude Code, lancez :

/plugin marketplace add kbventures/ingenix-code-review
/plugin install code-review-kit@ingenix

Ensuite, lancez /code-review-kit:pr-review après votre prochain changement, ou /code-review-kit:full-review-weekly pour vérifier toute l’application. Le code source et les instructions sont sur GitHub (en anglais).

---

Vous voulez cette révision sur votre application ?

Si votre application a été construite vite avec l’IA et que vous ne savez pas ce qui s’y cache, nous lançons la révision complète et vous expliquons le rapport — ce qui est cassé, ce qui est risqué, et les trois premières corrections qui comptent le plus.

Réserver un appel découverte gratuit