Développer avec l'IA

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² · S&R.

Le constat

Le paradoxe de l'IA
Redoutable sur l'instant.
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 relu ni audité — les failles dorment

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

En amont
BSP
Cadrer avant de coder
Brainstorming → Spécification → Plan. On ne lance l'IA sur le code qu'avec une cible nette.
Pendant
AVEC
La mémoire vivante
L'assistant tient lui-même une doc de projet, la lit en début de session et la met à jour tout seul.
En complément
Documenter
Deux documentations — fonctionnelle et technique — tenues à jour à chaque version livrée.
En aval
S&R
Vérifier le code produit
Sécurité auditée à chaque commit, code relu à la livraison. Rien ne part sans être vérifié.

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

BSP
1 · En amont — cadrer avant de coder
Brainstorming → Spécification → Plan. Une cible nette et un plan, pas une intention floue.

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

Ce cadrage n'est pas artisanal : il s'appuie sur Superpowers, un plugin open source pour Claude Code (créé par Jesse Vincent, plus de 900 000 installations) 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.

Résultat : on démarre le développement avec une cible nette et un plan, pas avec une intention floue.
AVEC
2 · Pendant — la mémoire vivante du projet
L'assistant tient lui-même une documentation vivante, en quatre briques dont les initiales forment le mot AVEC.

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 :

BriqueRôle
AAvancementL'état vivant du projet : fait, à faire, points en suspens, prochaine action. Le premier fichier lu à chaque reprise.
VVersionsL'historique des changements par version (format Keep a Changelog). La trace de ce qui a été livré.
ÉÉvénementsLa mémoire technique : chaque piège résolu et décision marquante, pour ne jamais re-déboguer deux fois la même chose.
CClaudeLe chef d'orchestre : les règles du projet, les pointeurs vers les docs, les routines de mise à jour automatique.
Résultat : à chaque reprise, l'assistant sait immédiatement où on en est, ce qui a été livré et ce qui a déjà été résolu.
3 · En complément — la documentation de référence
Là où AVEC porte la mémoire de travail (mouvante), D² porte la documentation de référence (stable).

Deux documentations tenues à jour et synchronisées avec chaque version livrée :

Documentation fonctionnelle
Qu'est-ce que ça fait ?

Les fonctionnalités vues par l'utilisateur : écrans, comportements, options. Aucun code.

Documentation technique
Comment c'est fait ?

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.

Résultat : à tout moment, un lecteur — humain ou IA — dispose d'une photo fidèle de ce que fait le produit et de comment il est bâti.
S&R
4 · En aval — vérifier le code produit
Coder vite ne suffit pas : ce qui sort doit être relu et audité avant de partir. C'est le temps qui fait passer de CAP³ à CAP⁴.

Security & Review — deux fronts complémentaires, chacun à son moment et à sa rigueur :

S — Sécurité
À chaque commit — bloquant

Le code est audité avant chaque commit : secrets en clair, injections, permissions, failles XSS… Tant que la revue n'est pas consignée, le commit est bloqué.

R — Revue de code
À la livraison — rappel

À chaque version, une relecture qualité du code : bugs, simplifications, cohérence. Rappelée automatiquement, sans bloquer.

La distinction est nette : la sécurité est une frontière — on bloque ; la qualité est un gradient — on rappelle. On n'automatise que ce qui est mécaniquement vérifiable ; le reste reste une routine.

Résultat : du code qui part relu et sécurisé — pas juste « ça compile ».

Ce que ça change concrètement

BSP

Un cap avant de coder

Le brainstorming et le plan évitent de partir dans la mauvaise direction.

AVEC

Reprise instantanée

L'assistant sait où en est le projet sans briefing manuel.

AVEC

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é.

S&R

Rien ne part sans être vérifié

Sécurité auditée à chaque commit, code relu à la livraison — pas après coup.

Bonus

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.

Pour tout projet qui vit plus d'une session et mérite d'être cadré, suivi, documenté et vérifié.

Pourquoi ça marche

Aucune usine à gaz.

Le cadrage s'appuie sur un plugin éprouvé (Superpowers), et 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, portable, sans dépendance.

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 et relit son code.

On en parle ?