Briefer un développeur web : la trame qui évite les retards

Vous avez signé avec un développeur, le projet démarre, et au bout de 3 semaines vous découvrez qu'il a compris autre chose que ce que vous vouliez. 9 fois sur 10, ce n'est pas son niveau technique qui est en cause. C'est le brief de départ qui était trop flou pour qu'il sache où mettre le curseur.

Briefer un développeur web, ça paraît évident. En pratique, c'est l'étape la plus sous-estimée d'un projet web et celle qui détermine 80 % du résultat final. Un brief approximatif vous coûte des semaines de retours en arrière. Un brief précis vous fait gagner des jours sur la livraison et change la qualité du livrable final.

Le brief n'est pas le cahier des charges

Beaucoup de TPE confondent les deux documents. Le cahier des charges sert à comparer plusieurs prestataires avant de signer. Vous l'envoyez à 2 ou 3 candidats, vous récupérez des devis, vous choisissez. C'est un document commercial. Le brief, lui, sert à cadrer la mission avec le prestataire choisi, juste après la signature. C'est un document opérationnel.

La conséquence pratique : le brief est plus court, plus précis, plus orienté action. Là où le cahier des charges parlait du contexte général et des objectifs business, le brief parle du livrable exact attendu pour chaque page, des critères d'acceptation, et du planning. Si vous avez déjà rédigé un cahier des charges site web propre, le brief reprend 30 % de son contenu et ajoute la partie opérationnelle.

Si vous n'avez pas fait de cahier des charges parce que vous avez choisi votre développeur sur recommandation directe, le brief joue les deux rôles à la fois. Il est alors un peu plus long, autour de 4 pages. C'est le scénario le plus fréquent en TPE et c'est le sujet de cet article.

Les 6 sections d'un brief qui évite les retours en arrière

Voici la trame qui couvre les projets de site vitrine, site de réservation, ou refonte pour une TPE ou une PME. Vous pouvez la copier telle quelle dans un document Notion, Google Doc ou Word.

1. Le but business du projet, en 2 phrases

Pas "avoir un site moderne". Mais : "permettre aux clients de réserver une consultation en ligne sans appeler le secrétariat, pour récupérer 4 heures par semaine de standard téléphonique". Le développeur a besoin de cette ligne pour arbitrer pendant le projet. Quand il devra choisir entre deux options techniques, il choisira celle qui sert le mieux votre but. Sans but explicite, il choisira celle qui est la plus rapide à coder.

2. Le périmètre exact de cette mission

La liste des livrables avec un niveau de détail concret. Pas "un site complet". Mais : "page d'accueil, page services avec 3 fiches détaillées, page contact avec formulaire à 4 champs, page mentions légales et politique de confidentialité, intégration du module de réservation Calendly". Comptez les pages, comptez les composants, listez les intégrations externes.

Cette liste devient la base du chiffrage. Si elle est floue, le devis sera flou. Si elle est précise, vous pouvez identifier exactement ce qui a été livré et ce qui manque au moment de la recette.

3. Ce qui est explicitement hors périmètre

La section que personne n'écrit, et qui sauve les projets. Indiquez explicitement les choses que vous ne voulez pas dans cette mission, ou pour lesquelles vous payerez plus tard. Exemples : "pas de blog dans cette V1", "pas de version anglaise", "pas de paiement en ligne", "rédaction des textes assurée par moi, pas par le développeur", "création de logo non incluse".

Cette précaution évite deux écueils. Le premier : que le développeur estime à la louche un livrable que vous n'attendiez pas, et augmente son devis pour rien. Le second : que vous découvriez à mi-projet que la version anglaise "vous avait paru évidente" alors qu'elle n'était pas chiffrée. Le hors-périmètre écrit force la conversation à avoir lieu au moment du brief, pas en cours de route.

4. Les critères d'acceptation

Pour chaque livrable significatif, comment vous saurez que c'est "bon". Pas "le site doit être beau". Mais : "le score PageSpeed Insights doit être supérieur à 80 sur mobile", "le formulaire de contact doit envoyer l'email dans la minute qui suit la soumission", "les pages doivent être indexées par Google dans les 7 jours après mise en ligne".

Un critère d'acceptation est testable. Si vous ne savez pas comment tester, ce n'est pas un critère, c'est un avis. Les avis se discutent à l'infini. Les critères se mesurent en 5 minutes.

5. Le rythme et les points de validation

À quelle fréquence vous voulez voir l'avancement, et sous quelle forme. Trois options viables :

• Point hebdo de 30 minutes : démo de ce qui a été codé dans la semaine, vous validez ou demandez des ajustements. Convient à un projet de 3 à 8 semaines.
• Validation par jalons : 3 ou 4 livraisons partielles dans le projet (maquettes, intégration, fonctionnalités, recette finale). Vous validez chaque jalon avant de passer au suivant. Convient à un projet long ou un client peu disponible.
• Validation finale uniquement : risqué. À éviter sauf si vous avez déjà travaillé avec ce développeur et que vous savez à quoi vous attendre.

Précisez aussi par quel canal la communication se fait : email, Slack, WhatsApp, outil dédié. Et qui est l'interlocuteur unique côté client. Plus de deux interlocuteurs, c'est trois fois plus de risque de signal contradictoire.

6. Les contraintes techniques et accès

Ce que le développeur doit savoir techniquement avant de commencer. Hébergeur déjà choisi, nom de domaine acheté, intégrations existantes à connecter, charte graphique disponible ou pas, accès aux outils tiers (Stripe, Mailchimp, Calendly). Pour chaque accès, qui le crée et qui le transmet.

Les contraintes légales aussi : RGPD, mentions légales, RGAA si vous êtes une structure publique ou parapublique. Si vous n'êtes pas sûr, voir les obligations légales en 2026. Mieux vaut surcharger cette section que de découvrir une obligation à la livraison.

Le piège du brief écrit trop précis

Il y a un excès symétrique au brief flou : le brief qui spécifie au pixel près le résultat attendu. Vous écrivez le brief comme si vous étiez le développeur. Couleurs exactes, espacements en pixels, choix de typo, structure HTML. Vous croyez vous protéger, vous bridez la qualité.

Un brief trop précis a deux effets négatifs. Le premier : le développeur ne peut plus apporter ses choix techniques. Vous lui demandez d'exécuter, pas de proposer. La qualité finale ne dépasse pas la vôtre, alors que vous avez payé pour qu'elle la dépasse. Le second : le brief devient le contrat. Tout ce qui n'est pas écrit n'est pas livré. Vous découvrez à la fin que des comportements évidents pour vous n'ont pas été codés parce qu'ils n'étaient pas dans le document.

Le bon niveau de précision : décrire le quoi (ce que l'utilisateur doit pouvoir faire), pas le comment (comment c'est codé). Décrire les contraintes (performance, accessibilité, légal), pas les choix techniques (framework, bibliothèque, structure de dossier). Le développeur propose le comment, vous validez. Cette répartition vous protège des erreurs techniques que vous n'auriez pas su éviter.

Comment réagir quand le développeur pose des questions sur le brief

Un développeur qui pose 10 questions sur votre brief est un bon développeur. Ça veut dire qu'il a lu en profondeur, qu'il a identifié les zones grises, et qu'il préfère clarifier maintenant plutôt que coder une mauvaise hypothèse pendant 3 jours. Acceptez les questions, prenez le temps d'y répondre par écrit, et mettez à jour le brief avec les réponses.

Un développeur qui ne pose aucune question, soit n'a pas lu le brief, soit a déjà décidé qu'il ferait ce qu'il a envie de faire. Les deux situations finissent mal. Si vous envoyez un brief et que vous recevez "ok je m'y mets" 5 minutes plus tard, demandez-lui de reformuler en 5 lignes ce qu'il a compris. Vous serez fixé.

Sur un projet récent, le brief disait "page contact avec formulaire". J'ai livré un formulaire à 4 champs nom-email-téléphone-message. Le client en attendait 8 champs plus une carte Google Maps avec adresse et horaires d'ouverture. Une journée de re-travail qu'un brief de 15 lignes en plus aurait évitée. Depuis, je pose toujours la question : "combien de champs dans le formulaire et lesquels, et est-ce qu'il faut une carte sur la page contact". Ça paraît bête, c'est précisément ce qui distingue un brief utile d'un brief décoratif.

Template de brief à reprendre

Voici la trame complète sous forme de tableau récapitulatif, avec le niveau de détail attendu pour chaque section et le temps de rédaction estimé. Comptez 2 à 3 heures de travail pour un brief de qualité sur un projet de 4 à 6 semaines.

Pour gagner du temps sur le premier brief, partez de cette structure et adaptez. Les sections sont indispensables, le niveau de détail s'ajuste à la taille du projet. Un brief de 2 pages bien structuré vaut mieux qu'un brief de 10 pages mal organisé.

Si vous travaillez avec un développeur pour la première fois, ajoutez un septième point en fin de brief : le mode de gestion des imprévus. Qui arbitre si le projet doit déborder, dans quelle limite, et avec quel surcoût. Cette ligne paraît défensive, elle est en réalité protectrice pour vous et pour le développeur. Pour creuser comment choisir le bon développeur avant même de le briefer, voir choisir un développeur freelance sans se planter.

Le brief comme outil de cadrage, pas comme arme juridique

Une dernière chose. Le brief n'est pas un contrat. Son but n'est pas de "prouver" quelque chose au développeur ni de le piéger sur un détail. Son but est de créer un terrain d'entente avant le code, pour que les surprises soient discutées en amont, pas constatées à la livraison.

Un bon développeur lira votre brief, fera des contre-propositions, signalera les points où il pense que vous vous trompez, et co-construira la version finale avec vous. Si votre brief est traité comme un cahier d'exercices à remplir sans discussion, vous avez le mauvais prestataire. Si votre brief est traité comme un document évolutif qu'on enrichit ensemble, vous avez probablement signé avec la bonne personne.

Pour un retour direct sur un brief en cours de rédaction avant de l'envoyer à votre développeur, échangeons 30 minutes.