Brief de projet pour l’IA : le modèle qui évite les prompts sans fin

Un long prompt ne remplace pas un brief de projet. Il peut détailler une sortie tout en oubliant l’utilisateur, les sources qui font autorité, les éléments à préserver et la manière de valider le résultat.

Un bon brief pour l’IA tient sur une page de référence et répond à six questions : pourquoi, pour qui, quoi, à partir de quoi, avec quelles limites et comment vérifier.

Qu’est-ce qu’un brief de projet adapté aux agents IA ?

C’est une source de contexte stable que l’agent peut relire avant une mission. Le brief décrit le résultat recherché et les règles communes. La tâche, elle, décrit le prochain changement à réaliser.

Cette distinction évite deux extrêmes : répéter tout le projet dans chaque prompt ou supposer que l’agent se souvient d’une conversation précédente. Le brief reste court ; les documents détaillés, maquettes, décisions et fichiers sont reliés comme sources.

1. 01

   Projet

   La valeur, le public et les contraintes durables.

2. 02

   Décision

   Le choix actuel et sa justification.

3. 03

   Mission

   Le prochain résultat, son périmètre et sa preuve.

Le modèle de brief de projet IA en 6 blocs

1. Résultat et public

Écrivez ce que le projet permet à une personne précise de faire. « Créer une plateforme moderne » ne donne aucune décision. « Permettre à un responsable produit de retrouver une décision et sa source en moins d’une minute » crée un résultat que l’on peut observer.

Ajoutez les deux ou trois situations prioritaires. Elles donnent à l’agent un critère pour arbitrer lorsqu’une demande locale entre en conflit avec l’usage principal.

2. Périmètre actuel

Indiquez ce qui existe, ce qui est en cours et ce qui n’appartient pas à cette phase. Le hors-périmètre est aussi important que la liste des fonctionnalités : il empêche l’agent de construire un système de notifications, une console d’administration ou une abstraction générique que personne n’a demandé.

3. Sources de vérité

Nommez la source qui fait autorité pour chaque type d’information : dépôt et branche, maquette, schéma de données, texte validé, documentation API, règles de marque et environnement de test.

Une liste de liens sans priorité ne suffit pas. Si une capture ancienne contredit le produit servi, le brief doit dire lequel l’emporte.

4. Contraintes et invariants

Les contraintes décrivent les limites techniques, légales, éditoriales ou visuelles. Les invariants nomment ce qui doit rester vrai après le changement : les utilisateurs existants gardent leurs données, une action externe demande une confirmation, le français conserve ses accents, le parcours fonctionne à 320 px.

5. Autorité et validations

Précisez ce que l’agent peut lire, modifier, exécuter ou publier. Séparez les actions réversibles des actions externes : préparer un brouillon n’est pas envoyer un email ; créer une build n’est pas déployer en production.

6. Définition de terminé

La fin doit être prouvée depuis le point de vue de l’utilisateur. Nommez le parcours à rejouer, les cas d’erreur, les contrôles techniques nécessaires et le format du compte rendu.

Exemple de brief pour une fonctionnalité produit

Ce brief n’impose pas la mise en page exacte. Il donne assez de direction pour que l’agent puisse proposer une solution sans inventer le produit.

Les erreurs qui produisent des prompts sans fin

• Décrire l’écran sans décrire l’usage. L’agent optimise la maquette, pas le travail de la personne.
• Mélanger faits et idées. Une option envisagée devient une fonctionnalité supposée existante.
• Donner plusieurs sources contradictoires. L’agent choisit silencieusement celle qui lui paraît la plus claire.
• Oublier le hors-périmètre. Chaque amélioration en suggère trois autres.
• Demander “quelque chose de professionnel”. Le critère ne permet ni décision ni validation.
• Conclure par “teste que tout fonctionne”. Sans parcours, environnement et résultat attendu, le contrôle reste vague.

Pour transformer ensuite une demande concrète en travail actionnable, voyez comment convertir un mail client en tâches claires avec l’IA.

Un brief vivant, pas un document oublié

Le brief doit changer lorsqu’une décision structurante change, pas après chaque tâche. Ajoutez une date de revue et un propriétaire. Lorsqu’une règle détaillée grandit, déplacez-la vers une page dédiée et gardez dans le brief un résumé avec le lien canonique.

Dans Stellary, le brief peut vivre dans la base de connaissances et rester relié au board, aux décisions et aux missions des agents. L’équipe ne recopie pas le même contexte dans chaque conversation ; elle maintient une source courte que le travail actif peut citer.

Le modèle à copier

Le brief doit raccourcir les missions suivantes

Un brief réussi n’est pas celui qui anticipe toutes les questions. C’est celui qui évite de redécouvrir les mêmes réponses à chaque changement.

Commencez avec une page. Reliez les sources détaillées, testez le brief sur une mission réelle, puis retirez ce qui n’aide pas l’agent à décider ou à vérifier. Le contexte utile est rarement le contexte maximal.