Le mini cahier des charges à écrire avant de lancer une IA de code

Tu as ton idée, tu as ouvert ton outil d’IA préféré, et tu tapes direct : « fais-moi une appli pour… ». C’est la meilleure façon d’obtenir un résultat qui ressemble à ce que tu voulais sans l’être vraiment. La solution tient sur une page, s’écrit avant d’ouvrir l’IA, et prend quinze minutes. Voici comment la construire.

Pourquoi une page suffit à tout changer

Un ingénieur qui écrit un cahier des charges technique le résume ainsi : l’endroit le moins cher pour prendre une décision, c’est le document, pas le code déjà écrit. Revenir sur un choix avant d’avoir tapé une ligne coûte deux minutes ; revenir dessus après que l’IA a construit dix fichiers autour coûte une réécriture entière. Écrire la spec en amont oblige à se poser les questions qui, sinon, se posent trop tard.

Un article consacré spécifiquement au prompt et à l’IA de code résume bien pourquoi la plupart des tâches échouent : un périmètre flou, des contraintes cachées, des interfaces non définies, un « terminé » qui ne veut rien dire pour personne. Une spec d’une page sert justement à empêcher l’IA de remplir les blancs à ta place, avec ses propres suppositions. Et la documentation de Claude Code, l’outil en ligne de commande d’Anthropic, va dans le même sens : elle recommande de définir noms de fichiers et interfaces concernées, ce qui est explicitement hors périmètre, et une façon de vérifier que le résultat correspond au besoin, avant de laisser l’IA écrire quoi que ce soit.

Les 6 sections de ton mini cahier des charges

Tu n’as pas besoin d’un document de 10 pages. Six sections courtes suffisent pour un projet étudiant : un mémoire, un outil pour ton club, une association, un projet personnel.

• Problème : quel problème concret ce projet résout-il, en 2 à 3 phrases. Pas la solution, le problème.
• Utilisateurs : qui va s’en servir. Un seul type d’utilisateur si possible pour une première version — vouloir satisfaire tout le monde dès le départ est le meilleur moyen de ne satisfaire personne.
• Fonctionnalités du MVP : le strict nécessaire pour que l’outil serve à quelque chose. MVP veut dire « minimum viable product » : la version la plus simple qui fonctionne vraiment, pas celle qui a toutes les idées que tu as eues sous la douche.
• Données : quelles informations l’application stocke, et qui peut les voir. Cette question, posée maintenant, t’évite une mauvaise surprise plus tard (l’article de ce blog sur la sécurité d’une app vibe-codée détaille ce qui peut mal tourner si tu la sautes).
• Écrans : la liste des 3 à 5 écrans principaux, dans l’ordre où l’utilisateur les voit. Pas besoin de maquette : une liste à puces suffit.
• Critères d’acceptation : comment tu sauras que chaque fonctionnalité marche vraiment. Et surtout, ce qui est explicitement hors périmètre pour cette version — cette dernière ligne est celle qui évite le plus de dérapages.

Le modèle à copier

# Cahier des charges — [nom du projet]

## Problème
[Quel problème concret ce projet résout-il ? En 2-3 phrases, sans
décrire la solution.]

## Utilisateurs
[Qui va s'en servir ? Un seul type d'utilisateur si possible pour la
version 1.]

## Fonctionnalités du MVP
- [Fonctionnalité indispensable 1]
- [Fonctionnalité indispensable 2]
- [Fonctionnalité indispensable 3]
(Tout le reste attend une version 2 : liste-le quand même, dans une
section "Plus tard", pour ne pas l'oublier sans le mélanger au MVP.)

## Données
[Quelles informations l'appli stocke-t-elle ? Qui peut les voir ?
Est-ce que ce sont des données personnelles ?]

## Écrans
[Liste les 3 à 5 écrans principaux, dans l'ordre où l'utilisateur
les voit.]

## Critères d'acceptation
- [Comment sais-tu que la fonctionnalité 1 marche vraiment ?]
- [Comment sais-tu que la fonctionnalité 2 marche vraiment ?]
- [Ce qui est explicitement hors périmètre pour cette version.]

Remplis-le en quinze minutes, sans chercher la formulation parfaite. S’il reste des cases où tu écris « à voir » ou « peut-être », c’est le signe que la question mérite d’être tranchée avant, pas pendant que l’IA écrit du code.

Comment t’en servir avec une IA de code

Une fois la page remplie, colle-la telle quelle dans ta conversation avec ton outil d’IA (Claude Code, Cursor, Lovable, peu importe), et demande explicitement un plan avant tout code :

Voici mon cahier des charges : [colle le document].
Avant d'écrire du code, propose-moi un plan qui découpe ce
projet en petites étapes. Dis-moi aussi si tu vois des zones
floues ou des questions que je n'ai pas tranchées.

La documentation officielle de GitHub à propos de Copilot recommande la même logique dans l’autre sens : commencer par une description générale de l’objectif, puis lister les contraintes précises, et découper une tâche complexe en plusieurs tâches simples plutôt que tout demander d’un coup. Un cahier des charges fait ce travail de découpage à ta place, une bonne fois pour toutes, au lieu de le refaire à chaque message.

Et si le projet change en cours de route ?

Un cahier des charges n’est pas gravé dans le marbre. Il est normal de le mettre à jour une fois que tu commences à voir ton projet prendre forme et que de nouvelles idées apparaissent. La bonne pratique n’est pas de tout réécrire à chaque fois, mais d’ajouter les nouvelles idées dans une section « Plus tard » plutôt que de les mélanger aux fonctionnalités du MVP en cours de route : c’est exactement ce qui fait dérailler un projet, une fonctionnalité à la fois. Si un changement touche une décision déjà actée (par exemple le type d’utilisateur ou une donnée stockée), mets à jour la section concernée et signale-le explicitement à l’IA dans ton prochain message, plutôt que de la laisser deviner que quelque chose a changé.

Ce que ça évite concrètement

Sans cette étape, trois problèmes reviennent sans cesse : l’IA suppose un type d’utilisateur que tu n’avais pas en tête, elle construit une fonctionnalité « en plus » que tu n’as jamais demandée et qui complique tout, ou elle déclare le projet « terminé » alors que le seul cas qui t’intéressait vraiment ne marche pas. Un cahier des charges d’une page ne garantit pas un projet parfait, mais il transforme une conversation floue en quelque chose que tu peux pointer du doigt en disant « construis exactement ça ».

Si le projet est un rendu noté, garde cette page dans ton dossier : elle prouve que la réflexion sur le problème et les choix de conception viennent de toi, même si l’IA t’a aidé à écrire le code ensuite. Vérifie aussi les règles d’usage de l’IA propres à ton établissement avant de t’en servir pour un travail évalué.

À retenir

• Écrire une page avant de coder coûte quinze minutes et évite des heures de correction : les décisions sont moins chères à prendre dans un document que dans du code déjà écrit.
• Six sections suffisent : problème, utilisateurs, fonctionnalités du MVP, données, écrans, critères d’acceptation.
• La dernière section (ce qui est hors périmètre) est celle qui évite le plus de dérapages.
• Colle ta spec dans ta conversation avec l’IA et demande un plan avant tout code.
• Garde cette page si le projet est noté : elle documente ta réflexion, indépendamment de l’IA.

Le modèle complet, avec des exemples remplis, est disponible dans la skill cahier-des-charges-vibe.