Préparer un brief projet digital : le template qui évite 80% des malentendus

Un brief projet digital n'est pas un document commercial : c'est un outil d'alignement interne, qui se trouve par ailleurs être envoyé à des prestataires. Cette inversion d'intention fait la différence entre un brief utile et un brief qui produit des devis non comparables. Le brief n'est pas là pour vendre votre projet aux prestataires : il est là pour vous obliger, vous et vos parties prenantes internes, à formuler en termes opérationnels ce que vous voulez vraiment. Une fois ce travail fait, l'envoi aux prestataires devient presque secondaire.

Ce qu'un brief n'est pas

Le malentendu le plus coûteux sur les projets digitaux PME et ETI consiste à confondre brief et cahier des charges. Le brief expose le problème, le contexte et les contraintes. Le cahier des charges spécifie la solution. La confusion entre les deux produit deux types de dégâts symétriques : soit un brief trop spécifié, qui fige une mauvaise solution avant que le diagnostic soit fait, soit un cahier des charges trop flou, qui laisse les prestataires naviguer à vue sur des choix structurants.

Un brief bien construit est court par construction. Quatre à six pages suffisent. Au-delà, on entre dans la spécification, et la spécification doit se faire en co-construction avec le prestataire choisi, pas en amont. Si votre brief dépasse dix pages, vous êtes probablement en train de rédiger un cahier des charges qui aurait mérité d'être découpé en deux temps : un brief court envoyé en R0, puis une note de cadrage produite en ateliers.

Section 1 : le contexte d'entreprise

Le contexte n'est pas une présentation marketing de votre société. C'est l'information opérationnelle qui permet au prestataire de comprendre le terrain. Trois éléments suffisent : taille de l'équipe concernée par le projet, secteur d'activité, position sur le cycle de vie (création, croissance, structuration, maturité, transformation). Une page maximum, sans storytelling.

La règle de relecture est simple : si la même phrase pourrait apparaître dans le brief d'une autre entreprise du même secteur, supprimez-la. Le contexte qui sert le brief est celui qui est spécifique à votre cas : une croissance accélérée qui n'a pas été suivie par la structuration, une fusion récente qui a juxtaposé deux SI, un dirigeant qui prend ses fonctions et reprend la main sur des chantiers laissés en suspens.

Section 2 : le problème observé

C'est la section la plus importante du brief, et celle qui est presque systématiquement ratée. La majorité des briefs PME démarrent par une solution déguisée en problème : « il nous faut un outil de gestion commerciale », « nous voulons refondre le site web », « on cherche à mettre en place un ERP ». Aucune de ces phrases n'est un problème. Ce sont des hypothèses de solution.

La formulation correcte décrit un état observable et mesurable, sans nommer de solution. « Les commerciaux perdent en moyenne 6 heures par semaine à ressaisir les leads entre leur boîte mail, le devis et la facture » est un problème. « Nous avons besoin d'un CRM » est une solution. La nuance n'est pas sémantique : la première formulation laisse au prestataire la liberté de proposer une réponse qui peut être un CRM, une automatisation entre outils existants, ou une refonte de processus sans nouvel outil. La seconde l'enferme dans une catégorie de réponse, parfois la mauvaise.

« Ils avaient une vision très "on a besoin de tel outil", alors qu'en fait ils avaient besoin davantage de mettre à plat et de mieux comprendre où est-ce qu'il y avait des effets de levier avec un vrai système d'information. »

Section 3 : les parties prenantes

Un brief PME mentionne rarement les parties prenantes au-delà du commanditaire. C'est une source majeure de malentendus. Pour chaque partie prenante interne, trois informations suffisent : son rôle dans le projet (sponsor, utilisateur cible, contributeur, validateur), son niveau d'adhésion (enthousiaste, neutre, réticent, opposant), et le canal de communication privilégié.

Cette section est souvent celle qui révèle au commanditaire des angles morts dans son propre projet. Une partie prenante listée comme « validateur » qu'on n'a pas embarquée dans la phase de brief deviendra un obstacle au moment de la mise en production. Il vaut mieux découvrir cette tension en interne pendant la rédaction du brief qu'en présentation client trois mois plus tard. Pour aller plus loin sur la cartographie des parties prenantes, voir la méthode de préparation des ateliers de cadrage.

Section 4 : le périmètre, et surtout le hors-périmètre

Le périmètre se définit autant par ce qu'il exclut que par ce qu'il inclut. Le réflexe naturel des commanditaires consiste à lister ce qu'ils veulent. Le travail utile consiste à lister explicitement ce qui n'est pas dans le projet. Cette inversion produit deux effets : elle oblige à arbitrer en amont, et elle protège des dérives de périmètre en cours de mission.

La règle des trois zones donne une structure utilisable. Zone 1 : ce qui est dans le projet sans discussion possible. Zone 2 : ce qui est sujet d'arbitrage, à trancher en début de mission selon les contraintes budgétaires découvertes. Zone 3 : ce qui est explicitement exclu, et qui devra faire l'objet d'un autre projet. Une zone 3 vide est le signe d'un commanditaire qui n'a pas arbitré. Un prestataire sérieux le détectera et soit forcera l'arbitrage en début de mission, soit s'abritera derrière un avenant à chaque dérive.

Section 5 : les contraintes opérationnelles

Cinq contraintes méritent d'être nommées explicitement : le calendrier (date butoir réelle et raison de cette date), le budget (fourchette indicative, ratio inférieur à 2 entre borne basse et borne haute), les ressources internes disponibles (qui contribue, à quel taux d'allocation), la dépendance externe (autre projet, fournisseur, échéance réglementaire), et les contraintes techniques structurantes (système legacy à intégrer, choix de cloud imposé, exigence de souveraineté des données).

La fourchette budgétaire est la contrainte que les commanditaires PME hésitent le plus à partager, par crainte de voir tous les prestataires aligner leur devis sur la borne haute. C'est un risque réel mais surévalué. Un prestataire en posture partenaire utilise la fourchette pour calibrer une proposition réaliste, pas pour maximiser sa marge. Si vous redoutez l'alignement haut, c'est un signal d'alerte sur la qualité de la short list que vous consultez, pas un argument pour cacher le budget.

Section 6 : les critères de succès

Un brief sans critères de succès est un brief qui se conclura par une discussion subjective sur la qualité de la livraison. Trois à cinq critères suffisent, formulés en termes observables : un délai de traitement réduit de X à Y, un nombre d'exceptions traitées manuellement passant sous tel seuil, un taux d'adoption mesuré par tel indicateur à la fin du sixième mois, un retour sur investissement calculé selon telle méthode.

Cette section est celle qui distingue un brief de praticien d'un brief de commande. Les critères de succès posés dès le brief donnent au prestataire un objectif lisible, et donnent au commanditaire un moyen de juger la qualité du résultat au-delà de l'impression. Sur les projets data-driven dès le jour 1, ils servent aussi à piloter la mission par les chiffres plutôt que par les réunions, ce qui réduit considérablement le coût de pilotage.

Section 7 : l'existant technique et organisationnel

La dernière section décrit l'environnement dans lequel le projet va atterrir. Trois sujets minimum : les outils en place (CRM, ERP, suite collaborative, outils métier spécifiques), les processus impactés (avec une indication du niveau de formalisation existant), et les chantiers en cours qui pourraient interférer (migration, refonte parallèle, restructuration organisationnelle).

Cette section évite la mauvaise surprise du prestataire qui découvre en cours de mission un legacy non documenté sur lequel il doit pourtant brancher son livrable. Sur le cas BKW Énergie France, le legacy PHP et le datalake existant ont été identifiés en brief, ce qui a permis de calibrer une migration progressive sans big bang. Sans cette clarification amont, la tentative aurait été identique aux freelances précédents : du code sans colonne vertébrale, qui n'aurait pas survécu à l'audit groupe.

L'envoi du brief, et après

Une fois les sept sections rédigées, le brief tient en quatre à six pages, format A4. Avant de l'envoyer à plusieurs prestataires, faites-le relire par une personne qui ne participe pas au projet, idéalement opérationnelle. Une relecture extérieure repère les acronymes maison, les non-dits implicites, les hypothèses cachées. Trente minutes de relecture sauvent parfois deux semaines de R0 perdues sur des malentendus.

L'envoi du brief n'est pas la fin du travail de cadrage, c'est le début.Le brief sert à présélectionner les prestataires capables de proposer une approche pertinente. La spécification détaillée se fait ensuite, en ateliers, avec le prestataire choisi. Tenter de tout figer dans le brief est l'erreur qui produit des projets vendus cher et livrés à côté. Pour la suite du processus, l'article sur la méthode de cadrage en trois ateliers décrit la mécanique pas à pas. Et sur le choix du bon prestataire, les huit questions à poser en R0 complètent le brief par une grille de lecture comportementale.

La semaine prochaine, choisissez un projet en cours ou à venir et appliquez la structure des sept sections à un brief existant. Vous identifierez en moins de deux heures les sections qui manquent ou qui sont mal formulées, et vous aurez en main un document utilisable avec un effort minime de réécriture. C'est ce travail invisible qui décide si vos prochains devis seront comparables, et si votre projet tiendra le périmètre annoncé en fin de mission.