Modèle de cadrage de projet : le brief qu'on aimerait recevoir

La plupart des briefs que nous recevons font deux lignes, ou quarante pages.

Le brief de deux lignes cache les décisions. Celui de quarante pages les enterre sous les écrans et les listes de fonctionnalités. Dans les deux cas, vous recevez trois devis impossibles à comparer, d'un mois à six, et vous choisissez au prix ou au feeling. Six mois plus tard, l'app fonctionne et personne sur le terrain ne l'ouvre.

Voici le document que nous aimerions recevoir avant un premier appel. Dix rubriques, une ligne d'exemple sous chacune, deux pages en tout. Il s'écrit en un après-midi, pour une app comme pour un projet IA.

Les dix rubriques : ce qu'on construit, ce qu'on ne construit pas, critères de réussite, utilisateurs, données, intégrations, contraintes, calendrier, fourchette de budget, responsable après la mise en production.

Pourquoi le brief fait le prix

Chaque devis est un pari sur ce que vous vouliez dire. Quand le brief est flou, chaque studio comble les trous à sa façon, et vous comparez trois projets différents à trois prix différents.

Les trous reviennent plus tard. Une fonctionnalité dont personne n'a parlé apparaît en semaine quatre, le planning glisse, et la discussion porte sur qui la paie.

Quand un projet dérape, la cause est rarement le code. C'est une décision que personne n'a écrite.

Un bon cadrage n'a pas besoin d'être long. Il doit répondre aux questions que l'équipe qui construit posera de toute façon, avant la première ligne de code.

Les lignes d'exemple suivent un projet imaginaire : une entreprise de 40 techniciens terrain qui veut une app mobile pour saisir ses interventions, avec une IA qui rédige le compte rendu à partir d'un mémo vocal.

Ce que vous construisez, ce que vous ne construisez pas, et comment vous le mesurez

1. Ce qu'on construit. Un paragraphe, en mots simples. Décrivez ce qui change pour quelqu'un un mardi matin, pas les écrans.

Les techniciens enregistrent un mémo vocal après chaque intervention. L'app en fait un compte rendu structuré et l'envoie au client le jour même.

2. Ce qu'on ne construit pas. C'est la ligne que la plupart des briefs sautent, et celle qui fait économiser le plus. Notez les fonctionnalités évoquées et mises de côté pour l'instant.

Pas de facturation, pas de planification, pas de cartes hors ligne dans la première version. L'outil de planning reste tel quel.

3. Critères de réussite. Comment vous saurez, trois mois après la mise en production, que ça a marché. Un ou deux chiffres, avec la valeur d'aujourd'hui à côté.

Les comptes rendus arrivent aux clients en moins de 24 heures, contre 5 jours aujourd'hui. Un technicien passe moins de 5 minutes par compte rendu.

Pour une fonctionnalité IA, ajoutez l'erreur que vous pouvez accepter, et qui la rattrape.

Un compte rendu faux coûte un coup de fil, pas un procès. La responsable administrative relit chaque compte rendu le premier mois, puis 1 sur 10.

Si vous ne pouvez pas écrire de critère de réussite, le projet n'est pas prêt à être construit. Il est peut-être prêt pour un audit.

Qui l'utilise, et avec quoi

4. Utilisateurs. Qui ouvre le produit, à quelle fréquence, sur quel appareil, et avec quelle patience. Nommez les rôles, et le nombre approximatif de personnes par rôle.

40 techniciens sur téléphones Android, souvent avec des gants. 3 personnes au bureau, sur ordinateur, qui vérifient et corrigent les comptes rendus.

5. Données. Ce qui existe aujourd'hui, où c'est stocké, à qui ça appartient, et dans quel état. Pour un projet IA, c'est cette rubrique qui décide l'essentiel de la faisabilité.

3 ans de comptes rendus en PDF sur un drive partagé, écrits à la main puis saisis. Liste clients dans le CRM. Aucun enregistrement pour l'instant.

Joignez 20 exemples réels au brief : 20 anciens comptes rendus, 20 e-mails, 20 tickets. Dix minutes de vraies données en disent plus à l'équipe qui construit que dix pages de description.

Dites où les données ont le droit d'aller. Un hébergement en Europe, dans votre cloud ou sur vos propres serveurs change l'architecture : sa place est dans le brief, pas dans la relecture du contrat.

6. Intégrations. Chaque outil dans lequel le produit lit ou écrit. Ajoutez qui gère chacun, et s'il a une API que vous avez vraiment vue fonctionner.

Lire les clients dans le CRM. Y écrire les comptes rendus terminés. Envoyer les e-mails via le prestataire actuel. L'administratrice du CRM est notre responsable administrative.

Les limites : contraintes, calendrier, budget

7. Contraintes. Les règles que vous ne pouvez pas changer : réglementation, politique de sécurité, stack déjà en place dans votre équipe, accessibilité, langues.

Les données clients restent dans l'UE. L'équipe informatique maintient l'app après la mise en production, donc elle utilise la stack que l'équipe connaît déjà.

8. Calendrier. Une date, et la raison de cette date. Un salon, un renouvellement de contrat ou une saison dit à l'équipe ce qu'on peut simplifier et ce qu'on ne peut pas.

Première version utilisée par 5 techniciens avant mars, quand la haute saison commence. Déploiement complet en juin.

Nos premières versions partent en général en production 3 à 6 semaines après le lancement du projet. Ça tient parce que la liste « ce qu'on ne construit pas » est longue. Un brief qui garde tout dans la première version tient rarement ce délai.

9. Fourchette de budget. Donnez une fourchette. Sans elle, vous recevez des propositions taillées pour le confort du studio, pas pour votre problème.

Un montant bas et un montant haut pour la première version. Coûts de fonctionnement budgétés à part, par mois.

Si vous ne savez pas quelle fourchette est réaliste, c'est une bonne question pour l'audit. Une fourchette n'affaiblit pas votre négociation. Elle permet à ceux qui construisent de vous dire ce qui tient dedans, et ce qui n'y tient pas.

10. Responsable après la mise en production. La personne qui décide de l'avenir du produit une fois qu'il tourne. Et aussi qui le répare quand il tombe un samedi, et qui paie les appels au modèle chaque mois.

Le directeur des opérations porte le produit. L'équipe informatique reprend la maintenance après trois mois d'accompagnement par le studio.

Trois choses à laisser de côté :

• Les maquettes d'écrans. Elles figent le design avant que le problème soit clair.
• La technologie, sauf si votre équipe doit la maintenir (voir rubrique 7).
• Une liste de souhaits IA. « L'IA doit répondre à toutes les questions des clients » est un souhait. « Elle rédige les réponses aux 5 questions les plus fréquentes, et une personne les envoie » est un cadrage.

Le modèle, prêt à copier

Copiez-le dans un document et envoyez-le à la personne qui porte le projet. Les cases qu'elle laisse vides sont l'ordre du jour de votre première réunion.

CADRAGE DE PROJET : [nom du projet]
Date : [date]  ·  Rédigé par : [nom, rôle]

1. Ce qu'on construit
   [Ce qui change, pour qui, en un paragraphe]

2. Ce qu'on ne construit pas
   [Fonctionnalités évoquées et mises de côté pour l'instant]

3. Critères de réussite
   [1 ou 2 chiffres, valeur actuelle et cible ; pour l'IA : taux d'erreur acceptable et qui vérifie]

4. Utilisateurs
   [Rôles, nombre de personnes, appareil, contexte d'usage]

5. Données
   [Ce qui existe, où c'est stocké, à qui ça appartient, dans quel état, où ça peut être hébergé]

6. Intégrations
   [Outils à lire ou à alimenter, responsable de chacun, API vérifiée : oui / non]

7. Contraintes
   [Réglementation, sécurité, stack existante, langues, accessibilité]

8. Calendrier
   [Date cible et sa raison]

9. Fourchette de budget
   [Bas et haut, première version et coûts de fonctionnement séparés]

10. Responsable après la mise en production
   [Une personne nommée, plus qui maintient et qui paie les coûts de fonctionnement]

Laissez une rubrique vide si vous ne savez pas. Un blanc honnête vaut mieux qu'une supposition, et il montre à l'équipe où se trouvent les premières questions.

Si vous préférez ne pas l'écrire seul

L'audit gratuit se termine par un document qui répond aux deux premières rubriques de ce modèle, les plus difficiles : ce qui vaut la peine d'être construit, et ce qui ne l'est pas. Il prend une heure sur votre activité, puis un document court. Si nous continuons ensemble, la première étape est un cadrage écrit : ce que nous construisons, ce que nous ne construisons pas, et quand ça part en production.

Envoyez votre brouillon, même à moitié vide, via la page contact. L'heure d'audit sert alors aux décisions, pas à la découverte. Pas encore de brouillon : nous remplissons les premières rubriques ensemble, et les blancs nous disent par où commencer.