La compétence de révision hebdomadaire : un bilan de santé complet de votre application

Chaque changement dans une application client est vérifié avant sa mise en ligne. Mais certains problèmes n’apparaissent que quand on regarde toute l’application d’un coup. Alors, une fois par semaine, nous révisons tout. Nous appelons ça full-review-weekly. Cette révision fait partie du système que nous décrivons dans Comment nous révisons le code écrit par l’IA. Cet article l’explique en détail : 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 à une maison. Vérifier chaque nouvelle pièce pendant la construction, c’est bien. Mais de temps en temps, il faut quand même une inspection complète, de la cave au grenier, y compris les pièces que personne n’a touchées cette année.

La révision hebdomadaire, c’est cette inspection. Elle fait cinq choses :

1. Elle lit chaque fichier. Pas seulement ce qui a changé cette semaine. Les bugs se cachent entre les changements : deux parties correctes chacune de leur côté peuvent être fausses ensemble.

2. Elle écarte les fausses alertes. Les outils de révision signalent des choses qui semblent fausses mais qui sont correctes. Une deuxième vérification rouvre le code derrière chaque problème grave et confirme qu’il est réel. Vous ne voyez que ce qui compte.

3. Elle lance des vérifications d’experts. Sécurité, protection des données, vitesse, conception de la base de données et structure, chacune examinée à part.

4. Elle se souvient de la semaine précédente. Chaque problème de la semaine dernière est revérifié : corrigé ou encore ouvert. Tout ce qui reste ouvert deux semaines de suite devient prioritaire. Rien n’est oublié en silence.

5. Elle repère les tendances. Si le même genre d’erreur apparaît partout dans l’application, la correction n’est pas une ligne de code. Le rapport propose une nouvelle règle pour que l’erreur cesse de revenir.

Ce que vous recevez : un seul résumé, avec les problèmes classés du plus grave au moins grave, les cinq prochaines corrections à faire, et ce qui a été corrigé depuis la semaine dernière.

Ce qu’elle a trouvé sur une de nos applications : lors d’une révision le 18 octobre 2026, elle a lu 504 fichiers, confirmé 4 problèmes critiques et 85 importants, et écarté 72 fausses alertes. L’un d’eux : une modification de paiement qui pouvait se perdre. Un autre : un nouveau client qui ne pouvait pas terminer son achat. Le lendemain, 17 corrections étaient en ligne, dont 13 avec un nouveau test.

La version technique (pour les développeurs)

Pourquoi une révision hebdomadaire à part

Une révision de diff, comme pr-review, ne voit que ce qui a changé. Elle ne peut pas attraper la dérive dans du code que personne n’a touché, les problèmes qui traversent plusieurs fichiers, ni la même erreur répétée partout. La révision hebdomadaire lit les fichiers complets et garde un historique d’une révision à l’autre.

Elle fonctionne sur toute application web TypeScript ou JavaScript, avec une structure à la racine (app/, lib/) ou sous src/.

Phase 0 : vérifications d’outils

Source : outils standards, utilisés tels quels. L’ordre et la façon dont les échecs deviennent des constats sont sur mesure.

Chacune s’exécute, et la révision continue même en cas d’échec :

• npm run lint
• npm run typecheck, ou npx tsc --noEmit s’il n’y a pas de script
• npm run test
• npm run db:migrations:check
• npm audit --omit=dev

Un outil en échec est noté comme constat. Un script absent aussi, comme lacune de tests. Elle ne lance jamais d’effacement ni de réinitialisation de base de données.

Phase 1 : tranches

Source : sur mesure.

Un script découpe le code en tranches par dossier et liste tout fichier non couvert, pour que rien ne soit sauté en silence. Chaque tranche reçoit deux sous-agents, l’un après l’autre :

• Passe code. Bugs, logique fausse, cas limites, entrées dangereuses, vérifications d’accès manquantes, secrets exposés, boucles et requêtes sans limite, catch silencieux, types faibles.
• Passe architecture. Chaque fichier comparé aux 13 règles. Chaque constat nomme la règle, par exemple R12 : UPDATE sans prédicat user_id.

Phase 2 : vérification

Source : sur mesure.

Un sous-agent de plus rouvre le code derrière chaque constat critique ou important et le marque CONFIRMED ou FALSE, avec une raison d’une ligne. Seuls les constats confirmés comptent dans le résumé et le bilan. Les constats des spécialistes passent par la même étape.

Phase 3 : spécialistes

Source : sur mesure, sauf la liste de sécurité, adaptée de everything-claude-code (MIT).

Jusqu’à trois en même temps, chacun sur tout le code :

Spécialiste	Cherche
Sécurité	Authentification, routes API, middleware, secrets
Propriété et verrouillage	Chaque UPDATE/DELETE/upsert vérifié pour un prédicat user_id, et FOR UPDATE sur la lecture-puis-écriture
Performance	Requêtes lentes, index manquants, N+1, SELECT sans limite, LIMIT manquant
Schéma	Contraintes manquantes et règles d’affaires absentes dans schema.dbml
Frontières entre modules	Imports entre modules, code de fournisseur hors des adaptateurs
Adéquation de l’architecture	Structure actuelle, fichiers fourre-tout, structure recommandée par domaine d’affaires
Frontières	Contrats d’API, lecture du JSON, valeurs nulles, conversion des rangées, contrats d’erreur
Types, tests, code mort	Types dangereux, lacunes de tests, exports inutilisés et vieilles cales

L’adéquation de l’architecture, c’est l’étape des conseils. Elle attrape les erreurs d’architecture de la phase de croissance avant qu’elles coûtent cher. Elle nomme la structure actuelle, signale les fichiers fourre-tout, et recommande la structure la plus simple qui convient à chaque domaine. L’échelle complète, du CRUD simple aux microservices, est dans Comment nous révisons le code écrit par l’IA.

Phase 4 : suivi

Source : sur mesure.

Les constats confirmés de la semaine précédente sont comparés au code actuel : FIXED ou OPEN. Tout ce qui reste ouvert deux révisions de suite devient critique.

Phase 5 : résumé

Source : sur mesure.

SUMMARY.md donne les chiffres, les constats critiques et importants confirmés par catégorie, un court bloc par spécialiste, et les cinq prochaines actions.

Phase 6 : bilan des tendances

Source : sur mesure.

Un fichier cumulatif compte les constats par catégorie d’une révision à l’autre, mesurés en tranches touchées :

• 2 à 3 tranches : proposer une modification d’une norme de code ou d’une règle d’architecture, avec la formulation exacte.
• 4 ou plus : proposer un nouveau vérificateur, ou resserrer celui qui aurait dû l’attraper.
• Déjà couvert par une règle, encore 4 ou plus : la règle ne fonctionne pas ; proposer une règle de lint ou un test qui l’impose.

Elle ne fait que proposer. C’est vous qui décidez quoi changer.

Chaque constat tient sur une ligne

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

Les catégories viennent d’une liste fixe, pour suivre les tendances d’une semaine à l’autre : exactitude, sécurité, propriété, verrouillage, validation, gestion des erreurs, sûreté des types, valeurs nulles, fuite de frontière, frontières entre modules, sûreté des requêtes, performance, sûreté des migrations, code mort, lacune de tests, simplification.

Elle survit à un plantage

Source : sur mesure.

Une révision complète est longue. Chaque phase écrit son propre fichier sur le disque avant de répondre, et une liste PROGRESS.md suit ce qui est fait. Si la révision s’arrête à cause d’un plantage ou d’une limite de jetons, le prochain lancement reprend à la première étape non terminée.

Ce qui est sur mesure, ce qui est intégré, et pourquoi

Claude Code n’a pas de révision intégrée de tout le code. Sa commande /code-review ne voit que le diff et n’a aucune mémoire d’une révision à l’autre. La plus grande partie de cette compétence est donc sur mesure. Là où un bon outil standard fait déjà le travail, nous l’utilisons tel quel.

Partie	Source	Pourquoi
Lint, vérification des types, tests, npm audit	Outils standards, utilisés tels quels	Le même travail dans tous les projets. Les reconstruire n’apporte rien.
Liste de sécurité	Adaptée de everything-claude-code (MIT)	Une bonne liste ouverte existait déjà. Nous l’avons adaptée à ce processus.
Tranches et les deux passes sur fichiers complets	Sur mesure	Un réviseur général ne peut pas lire 500 fichiers d’un coup, et ne connaît pas vos 13 règles.
Passe de vérification	Sur mesure	Sans elle, les fausses alertes enterrent les vrais constats et on cesse de faire confiance au rapport.
Spécialistes propriété, performance, schéma, modules, adéquation de l’architecture, frontières, types, tests et code mort	Sur mesure	Chacun cible un défaut que nous trouvions sans cesse dans le code écrit par l’IA.
Suivi, bilan des tendances, reprise	Sur mesure	Aucun outil standard ne se souvient des révisions passées ni ne propose de nouvelles règles.

Notre règle simple : utiliser l’outil par défaut quand le travail est le même pour tous les projets. Aller sur mesure quand la vérification dépend de vos règles ou d’un défaut qui revient sans cesse.

Quand un développeur senior prend le relais

La révision hebdomadaire trouve des candidats. Un développeur senior de notre équipe décide de ce qu’ils veulent dire. Pour le code sensible côté sécurité (authentification, paiements, permissions, données personnelles, tout ce qui supprime ou déplace des données), ce qui est lu à la main dépend de la sensibilité du code et de l’étape où en est l’application.

Étape	Ce qui est lu à la main
MVP	La révision hebdomadaire est facultative. Quand elle tourne, les constats critiques sont corrigés. Pas de lecture ligne par ligne.
Avant le lancement	Une révision hebdomadaire complète, puis un développeur senior lit tout le code sensible ligne par ligne avant l’arrivée des vrais utilisateurs.
En production, avec des revenus	La révision tourne chaque semaine. Un développeur senior lit chaque constat critique et important dans le code sensible, vérifie la correction à la main, et lit les changements à cet endroit avant la fusion.

---

Obtenez le kit gratuitement

full-review-weekly fait partie de notre plugin Claude Code gratuit, avec pr-review, 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:full-review-weekly pour vérifier toute l’application. Lisez la compétence elle-même 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 hebdomadaire 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