Quand on ouvre un outil d'IA avec « fais-moi une appli de carnet alimentaire », il produit quelque chose en une minute. Le problème, c'est tout ce qu'il a décidé à votre place : d'où viennent les calories, ce qui se passe quand la photo est floue, ce que voit l'utilisateur quand rien ne marche. Il a choisi une réponse par défaut à chacune de ces questions, sans vous les poser.
Le brief sert à prendre ces décisions avant. C'est le document qu'on distribue au début de chaque soirée AI First, et c'est la compétence qu'on y travaille le plus. Ce guide en décrit la structure, avec des exemples tirés des vrais briefs. Ils sont tous dans la bibliothèque.
Pourquoi écrire avant de demander
Une IA qui code va vite. Ce qui prend du temps, c'est de corriger une application qui fait autre chose que ce qu'on voulait, parce qu'on ne l'avait pas dit. Écrire d'abord coûte vingt minutes et en économise souvent beaucoup plus.
Ce n'est pas une lubie de meetup. Anthropic raconte que son équipe juridique, qui n'a pas de développeurs, travaille de cette façon avec Claude Code : une spécification d'abord, l'implémentation ensuite, étape par étape (Anthropic, juillet 2025).
Les six parties d'un brief
1. Une personne et son problème
Un brief AI First commence toujours par quelqu'un. Pas par une liste de fonctionnalités. Pour l'édition 08, c'était Nadia, qui sort de chez le médecin avec la consigne de noter ce qu'elle mange pendant un mois :
« Ce que je voudrais, c'est prendre la photo et passer à autre chose. Que ça reconnaisse, que ça note, et que je corrige quand c'est à côté. Et surtout, je veux savoir d'où sortent les chiffres. »
Ces trois phrases contiennent déjà le produit : partir d'une photo, laisser l'utilisateur corriger, montrer la source de chaque chiffre. Écrire la situation de cette façon oblige à savoir pour qui on construit. C'est aussi la partie que l'IA comprend le mieux.
2. Ce que, jamais comment
Le brief décrit ce que l'application doit faire. Il ne dit rien de l'architecture, des écrans ou du langage. Les briefs AI First le posent dès le début :
« Ce brief décrit ce que l'application doit faire, jamais comment le faire. Aucune architecture imposée, aucune maquette, aucun format de réponse, aucun prompt fourni. »
Pour son propre projet, c'est la même règle : décrire le comportement attendu, et laisser l'outil proposer la technique. Vous gardez la main sur ce qui compte pour l'utilisateur, il garde la main sur ce qu'il fait mieux que vous.
3. Ce que l'application doit faire
Une liste courte de fonctionnalités, chacune commençant par un verbe et suivie d'une phrase qui dit ce qu'on attend. Dans le brief de l'édition 08 :
- Partir d'une photo. Une photo prise sur le moment ou choisie dans la pellicule, et c'est tout.
- Aller chercher les chiffres ailleurs. Les valeurs nutritionnelles viennent d'Open Food Facts. Le modèle sert à reconnaître, jamais à chiffrer.
- Savoir ne rien trouver. Une photo sans nourriture, un plat introuvable dans la base : chacun de ces cas a sa réponse, et aucune ne consiste à afficher un chiffre plausible.
Cinq lignes de ce genre suffisent pour une première version.
4. Les règles, c'est-à-dire les cas où ça se passe mal
C'est la partie qu'on oublie le plus souvent, et celle qui fait la différence entre une démo et un outil utilisable. Une règle dit ce qui doit se passer dans un cas précis, en général un cas d'échec :
- « Une photo de chien, de facture ou de salle de réunion se solde par “ce n'est pas un repas”. Test de la soirée : photographier son clavier. »
- « Clé absente, quota dépassé, base injoignable : chacun a son message et sa suite. “Une erreur est survenue” ne renseigne personne. »
Une règle bien écrite se teste en dix secondes. Si vous ne savez pas comment la vérifier, elle est trop vague.
5. Les décisions à trancher
Certaines questions n'ont pas de bonne réponse, seulement des choix qui se défendent. Les briefs AI First en laissent une ou deux ouvertes, marquées « À trancher ». Pour le carnet alimentaire :
Une assiette avec une viande, un féculent et un légume, c'est une ligne de carnet ou trois ? Une seule ligne est simple à lire mais introuvable telle quelle dans la base. Trois lignes collent mieux aux données mais demandent de valider trois fois.
Dans votre propre brief, notez ces questions et tranchez-les vous-même. Si vous ne le faites pas, l'IA le fera sans le dire, et vous découvrirez son choix plus tard.
6. Des paliers
Un brief AI First a trois paliers : Socle, Avancé, Poussé. Le Socle suffit à repartir avec quelque chose d'utile. Chaque palier a une note de cadrage qui dit ce qu'il n'exige pas, par exemple : « Ce palier n'exige ni compte, ni serveur, ni rien qui survive à la fermeture de l'onglet. »
Les paliers servent à avancer par versions qui tournent. On donne le Socle à l'IA, on vérifie, puis on passe au suivant. Demander les trois d'un coup, c'est obtenir un résultat qu'on ne sait plus corriger.
Le modèle à copier
LA SITUATION
Qui a le problème, dans quel contexte. Deux ou trois phrases, si possible avec ses mots.
CE QUE L'APPLICATION DOIT FAIRE (palier 1)
- Verbe + ce qu'on attend, en une phrase.
- …
LES RÈGLES
- Quand [cas précis], alors [comportement attendu].
- Quand ça échoue (réseau, clé, donnée absente) : [ce que voit l'utilisateur].
À TRANCHER
- [La question] : [mon choix, et pourquoi].
CE QUE CE PALIER N'EXIGE PAS
- Pas de compte, pas de serveur, pas de sauvegarde… (selon le cas)
PALIERS SUIVANTS
- Palier 2 : …
- Palier 3 : …Du brief au premier message
Une fois le brief écrit, quelques habitudes aident :
- Donner la situation et le premier palier seulement, avec les règles qui le concernent.
- Demander à l'outil de reformuler ce qu'il a compris et de poser ses questions avant de coder. Ses questions montrent ce que le brief a laissé flou.
- Tester chaque règle à la main une fois la première version prête. Photographier son clavier, couper le réseau, entrer une valeur absurde.
- Passer au palier suivant seulement quand le premier tient.
Le test prend plus de temps qu'on ne croit. Au compte rendu de l'édition 08, la reconnaissance des plats composés était le point faible : sur un cassoulet, le modèle répondait « haricots blancs ». Il aurait fallu essayer les prompts sur une série de photos dont on connaît la bonne réponse, et presque personne n'en a eu le temps en deux heures.
Questions fréquentes
Quelle longueur doit faire un brief ?
Une page pour un premier palier. Les briefs des soirées sont plus longs parce qu'ils couvrent trois paliers et servent à une salle entière. Pour un outil personnel, la situation, cinq fonctionnalités et autant de règles suffisent.
Faut-il écrire le brief en anglais ?
Non. Les outils actuels comprennent très bien le français, et les briefs AI First sont tous en français. Écrire dans sa langue aide surtout à être précis.
Le brief remplace-t-il le prompt ?
Il le prépare. Le brief est le document de référence ; les messages à l'outil en reprennent des morceaux, palier par palier, et on y revient quand le résultat dérive.