CAP4
Piloter un vrai projet avec un assistant IA, du cadrage à la vérification.
Coder vite avec l'IA, c'est acquis. Garder un projet cohérent, documenté et sûr dans la durée, beaucoup moins. CAP⁴ : une méthode de bout en bout, en quatre temps, BSP · AVEC · D² · TRS.
Le constat
Fragile dans la durée.
Les assistants IA de développement, Claude Code, Copilot, Cursor…, sont bluffants sur le moment. Mais un vrai projet ne tient pas sur l'instant.
Sans discipline, le gain de vitesse est mangé par le désordre :
- On ré-explique le contexte à chaque reprise de session
- On re-débogue des problèmes déjà résolus
- La documentation dérive jusqu'à devenir fausse
- Le code part sans être testé, relu ni audité : régressions et failles dorment
- Le code naît périmé : l'IA écrit avec les API de son entraînement, pas celles qui tournent chez vous
Il faut cadrer avant de coder, garder le fil d'une session à l'autre, documenter ce qui a été fait, et vérifier ce qui sort.
Quatre temps qui s'enchaînent
Un cadrage en amont, une mémoire pendant, une documentation qui ne ment pas, et une vérification du code avant qu'il ne parte.
La méthode en détail
Avant d'écrire la moindre ligne, on prend le temps de :
- Brainstorming : faire émerger le besoin par un questionnement socratique
- Spécification : figer ce besoin dans un document clair
- Plan : le découper en exécution, avec points de contrôle et tests
Ces trois documents sont datés, et jamais retouchés après coup. Si le code finit par s'écarter de la spec, l'écart s'écrit, se date et se motive dans l'historique de la version qui l'a pris, jamais en corrigeant l'original : on garde ce qu'on savait au moment de décider.
Ce cadrage n'est pas artisanal : il s'appuie sur Superpowers, un plugin open source pour Claude Code (créé par Jesse Vincent) qui outille précisément ces pratiques : brainstorming, plans découpés avec revues, mais aussi TDD, revue de code et débogage méthodique. BSP en est la porte d'entrée.
Pendant toute la construction, l'assistant lit cette mémoire en début de session et la met à jour automatiquement, sans qu'on ait à le lui redemander. Quatre briques :
| Brique | Rôle | |
|---|---|---|
| A | Avancement | L'état vivant du projet : fait, à faire, points en suspens, prochaine action. Le premier fichier lu à chaque reprise. |
| V | Versions | L'historique des changements par version (format Keep a Changelog). La trace de ce qui a été livré. |
| É | Événements | La mémoire technique : chaque piège résolu et décision marquante, pour ne jamais re-déboguer deux fois la même chose. |
| C | Claude | Le chef d'orchestre : les règles du projet, les pointeurs vers les docs, les routines de mise à jour automatique. |
La doc d'une bibliothèque se lit à la version installée.
Le modèle connaît les bibliothèques telles qu'elles étaient à son entraînement. Le code qui les appelle s'écrit donc d'après la documentation de la version qui tourne réellement, lue dans le fichier de verrouillage, consultée via Context7. Si Context7 est indisponible, l'assistant le dit, au lieu de revenir en silence à sa mémoire.
C'est le même principe qu'AVEC : ne pas se fier à la mémoire du modèle, mais à des sources. AVEC l'applique à la mémoire du projet, Context7 à la mémoire d'entraînement. Et c'est la réponse à « coder avec l'IA, c'est fabriquer la dette technique de demain » : le code ne naît plus périmé.
Deux documentations tenues à jour et synchronisées avec chaque version livrée :
Les fonctionnalités vues par l'utilisateur : écrans, comportements, options. Aucun code.
La stack, l'architecture, et le rôle technique des grandes fonctions de chaque module.
La règle : à chaque nouvelle version, ces deux docs sont relues et mises à jour si le changement les impacte (et créées si elles manquaient). Elles ne dérivent pas, parce que leur mise à jour fait partie de la routine de livraison.
Test · Review · Security, trois fronts complémentaires, chacun à son moment et à sa rigueur :
Une version ne sort pas sans dire ce que ses tests ont fait : quel outil (Vitest, pytest…), sur quel périmètre, avec quel résultat. Pas de tests ? Il faut écrire pourquoi, à chaque version. L'absence de tests reste une phrase qu'on relit, jamais un réglage qu'on oublie.
Une relecture qualité du diff complet de la version : bugs, simplifications, cohérence. Les remarques sont traitées ou notées, jamais ignorées en silence.
Le diff est audité avant chaque commit selon une grille propre au projet, qui nomme ses vraies surfaces d'attaque : secrets, injections, permissions, failles XSS… Tant que la revue n'est pas consignée, le commit est bloqué. Le registre, lui, ne quitte jamais la machine.
Trois rythmes, trois rigueurs. Les tests ne bloquent pas un commit : un travail en cours a le droit d'être rouge ; ils bloquent la publication, tant que la version ne dit pas ce qu'ils ont donné. La sécurité est une frontière : on bloque à chaque commit. La qualité est un gradient : on rappelle. On automatise ce qui est mécaniquement vérifiable ; le jugement reste une routine.
Des dépendances à jour, et sans faille connue.
Trois moments : à la création du projet, à l'installation de la méthode sur un projet existant, et à chaque version mineure ou majeure. L'assistant inventorie ce qui tourne réellement, mesure les écarts avec la dernière version stable et les vulnérabilités connues, puis lit avec Context7 ce qui casse, confronté à notre usage réel du code. En lecture seule : rien n'est mis à jour sans accord. Pas de brique de plus : la fraîcheur est une revue (R), les vulnérabilités relèvent de la sécurité (S).
Ce que ça change concrètement
Un cap avant de coder
Le brainstorming et le plan évitent de partir dans la mauvaise direction.
Reprise instantanée
L'assistant sait où en est le projet sans briefing manuel.
Zéro régression de connaissance
Décisions et bugs résolus sont capitalisés, pas ré-appris.
Une documentation qui ne ment pas
Fonctionnelle et technique restent alignées sur le code livré.
Rien ne part sans être vérifié
Sécurité auditée à chaque commit, tests et revue à chaque version, pas après coup.
Du code à jour dès l'écriture
Écrit d'après la doc de la version installée, pas de mémoire ; dépendances vérifiées à chaque version.
Passation facilitée
N'importe qui peut reprendre le projet en lisant quelques fichiers clairs.
Pour qui ?
Développeurs & freelances
Qui travaillent avec un assistant IA et veulent garder la main sur des projets qui durent.
Petites équipes
Qui ont besoin de cadrer, suivre, documenter et sécuriser sans monter une usine à gaz.
Projets qui durent
Ceux qui s'étalent sur plusieurs sessions et méritent d'être tenus dans le temps.
Pourquoi ça marche
476 revues.
Sur un vrai projet, la règle « une revue de sécurité par commit » était écrite dès le premier jour. Elle n'a pas été tenue. Ce n'est pas un manque de sérieux : c'est ce qui arrive à toute routine non outillée.
D'où la seconde moitié de CAP⁴ : un garde-fou exécuté par l'outil lui-même, avant chaque commit.
Ce n'est pas l'assistant qui décide de le lancer, c'est Claude Code. Il refuse le commit tant que le suivi n'est pas fait, et dit exactement ce qui manque. Il n'impose que des conditions mécaniques (un fichier existe, deux numéros s'accordent) : un garde-fou qui prétend juger finit par bloquer à tort, et par être contourné.
Aucune usine à gaz.
Le suivi tient dans quelques fichiers Markdown et un jeu de routines, versionnés avec le code. La vérification est tenue par des garde-fous mécaniques qui bloquent au bon moment. Léger et portable : quelques fichiers, des routines, et deux outils open source, Superpowers pour cadrer, Context7 pour la documentation.
La meilleure documentation, finalement, est celle que l'outil s'écrit à lui-même au fil du travail, et le meilleur audit, celui qui se déclenche tout seul avant que le code ne parte.
Coder vite, c'est acquis.
Tenir le projet dans la durée, ça se méthode.
Cadrer, se souvenir, documenter, vérifier : quatre temps, quelques fichiers, et un assistant qui tient lui-même la mémoire, teste et relit son code.
On en parle ?