🧭Cadrer un projet avec un LLM
La compétence qui change tout. Avant d'écrire une ligne de code, on transforme une idée floue en cahier des charges net, en discutant avec un LLM. 80 % du résultat se joue ici.
Si vous ne deviez lire qu’une seule fiche de ce site, ce serait celle-ci.
La machine, Linux, l’agent, les modèles : c’est de l’outillage. Ça s’apprend en un week-end. Ce qui sépare un projet qui aboutit d’un projet qui part en vrille, ce n’est jamais la puissance du mini-PC ni le modèle utilisé. C’est la qualité du cadrage en amont. Un agent surpuissant lancé sur une idée floue produit beaucoup de code… qui ne fait pas ce que vous vouliez. Un agent moyen guidé par un cahier des charges net produit exactement la bonne chose.
Pourquoi un LLM est l’outil parfait pour cadrer
Vous pourriez écrire votre cahier des charges seul, dans un coin. Mais un LLM est un partenaire de réflexion redoutable avant d’être un exécutant. Il ne se fatigue pas, ne juge pas vos questions bêtes, et surtout : il fait remonter les angles morts. Vous lui décrivez votre idée, il vous pose les vingt questions que vous n’aviez pas vues venir. C’est un entretien de cadrage gratuit, à la demande.
Le piège classique, c’est de sauter cette étape : ouvrir l’agent et taper « fais-moi une app de gestion de tâches ». L’agent va deviner. Il va deviner la pile technique, le stockage, l’auth, le design, et il devinera mal, parce que vous ne lui avez pas dit. Vous passerez ensuite trois heures à corriger ses suppositions. Le cadrage, c’est remplacer les suppositions par des décisions.
La boucle complète
Cadrer n’est pas une étape isolée : c’est le premier maillon d’une boucle que vous allez répéter à chaque projet.
Brief
Une idée en deux phrases
Cadrage
Cahier des charges avec le LLM
Mémoire
CLAUDE.md + fichiers mémoire
Build
L'agent code, vous pilotez
Relecture
Tests, sécurité, second avis
Déploiement
Tunnel, mise en ligne
↻ et on reboucle : chaque retour affine le cadrage et la mémoire.
Étape par étape : de l’idée floue au cahier des charges
Ouvrez une conversation avec un LLM (l’interface web, ou votre agent en mode discussion) séparée de votre projet de code. Ici, on ne code pas. On réfléchit.
Posez le brief brut, en deux phrases
N’essayez pas d’être précis tout de suite. Lâchez l’idée telle quelle :
« Je veux un petit tableau de bord qui regroupe les sorties ciné de la semaine, avec affiches et notes, accessible depuis mon téléphone. »
C’est suffisant pour démarrer. Le LLM va faire le reste du travail de clarification.
Demandez-lui de vous interviewer, pas de répondre
La phrase magique :
« Avant de proposer quoi que ce soit, pose-moi toutes les questions nécessaires pour cadrer ce projet : usages, utilisateurs, contraintes techniques, ce qui est explicitement hors périmètre. Une question à la fois si besoin. »
C’est l’inversion clé. Vous ne voulez pas qu’il code. Vous voulez qu’il vous extraie les décisions de la tête.
Répondez, et laissez les vraies contraintes émerger
« Pour qui ? » → vous seul, ou l’équipe ? « Les données viennent d’où ? » « Ça doit tourner même hors-ligne ? » « Combien d’utilisateurs en même temps ? » Chaque réponse ferme une porte que l’agent aurait sinon ouverte au hasard.
Faites-lui rédiger le cahier des charges
Une fois l’interview finie :
« Synthétise tout ça en un cahier des charges structuré : objectif, utilisateurs, fonctionnalités (priorisées), pile technique, ce qui est hors périmètre pour la v1, et les risques. »
Vous obtenez un document. Relisez-le. Corrigez. C’est votre cahier des charges, pas le sien.
Découpez en jalons livrables
Dernier geste : « Découpe ça en 3 à 5 jalons, chacun livrable et testable indépendamment, du plus simple au plus complet. » Vous tenez votre feuille de route. L’agent attaquera le jalon 1, pas le projet entier d’un coup.
Ce qu’un bon cahier des charges contient
Peu importe le format, visez ces rubriques. C’est ce qui transforme « fais une app » en quelque chose qu’un agent exécute sans deviner :
- L’objectif en une phrase. Si vous ne pouvez pas le dire en une phrase, le projet n’est pas mûr.
- Les utilisateurs et leur usage réel. « Moi, depuis mon canapé, sur téléphone » est une spec. « Les gens » n’en est pas une.
- Les fonctionnalités, priorisées. Ce qui est dans la v1, ce qui attend. La priorisation est la décision difficile.
- La pile technique et les contraintes. Langage, framework, où ça tourne, hors-ligne ou pas, budget.
- Le hors-périmètre, explicite. La rubrique la plus sous-estimée. Écrire « pas d’authentification en v1, pas de multi-utilisateur » empêche l’agent de bâtir une usine à gaz.
- Les risques et inconnues. Les trucs dont vous n’êtes pas sûr. L’agent peut vous aider à les lever en premier.
Les pièges du cadrage
Du cahier des charges au projet vivant
Le cadrage ne meurt pas une fois le code lancé. Votre cahier des charges devient le socle de la mémoire du projet. Concrètement :
- Vous déposez le cahier des charges (ou son résumé) dans le
CLAUDE.md/AGENTS.mddu projet. L’agent le relit à chaque session, voir Les fichiers mémoire. - À chaque jalon livré, vous revenez au cahier des charges : ce qui a changé, ce qu’on a appris, ce qu’on reporte. C’est le « ↻ on reboucle » du schéma.
- Les décisions répétées (« on utilise toujours telle lib », « on ne touche jamais à tel dossier ») se cristallisent en règles dans la mémoire, et vous cessez de les répéter.