Faut-il un cahier des charges avant de consulter un prestataire d'application ? Pas un cahier figé de 80 pages, mais une vraie structure qui aide à recevoir des devis comparables. Voici ce qu'il doit contenir et ce qu'il ne doit surtout pas faire.
Cahier des charges vs brief : faire la différence
Le cahier des charges complet (80 pages, specs détaillées, choix techniques imposés) est un héritage industriel qui colle mal aux projets logiciels modernes : il fige des décisions avant validation, enferme la créativité du prestataire et coûte cher à produire pour un résultat souvent peu utile.
Le brief structuré (5-10 pages : contexte, problème, utilisateurs, contraintes) est l'approche moderne : il aligne sur ce qui compte, laisse le prestataire proposer la meilleure solution, et constitue la base du vrai cadrage qui se construit ensuite ensemble.
La structure du brief idéal
| Section | Contenu type | Longueur indicative |
|---|---|---|
| Contexte | Qui vous êtes, votre activité, l'enjeu métier qui motive le projet | 1 page |
| Problème à résoudre | Le vrai problème métier en quelques phrases, sans formuler la solution | 0,5 page |
| Utilisateurs cibles | Qui s'en sert, profils, appareils, contexte d'usage | 1 page |
| Cas d'usage clés | 5-10 scénarios concrets racontés en une phrase | 1-2 pages |
| Contraintes connues | Outils existants à conserver, données, intégrations obligatoires, RGPD | 1 page |
| Volume et croissance attendus | Utilisateurs, transactions, données : aujourd'hui et à 2-3 ans | 0,5 page |
| Budget et délai | Une fourchette honnête, vraie deadline si elle existe | 0,5 page |
Ce qu'il ne faut pas écrire
- Choix techniques imposés : « il faut du React + Node + MongoDB ». Le prestataire connaît mieux le sujet, laissez-le proposer.
- Écrans détaillés au pixel près : « bouton bleu en haut à droite avec icône... ». Description du résultat attendu, pas du design.
- Logique métier sur-spécifiée : enfermer chaque cas dans une règle figée empêche l'ajustement en cours.
- Délai irréaliste : « MVP en 2 semaines pour un SaaS B2B complet ». Préférer dire « idéalement avant date X » avec contexte.
- Liste exhaustive de 200 fonctionnalités : le MVP doit faire 1-2 choses bien, pas 200 choses mal.
Le cadrage : ce qui se construit ensuite
Le brief n'est qu'un point de départ. Une fois le prestataire choisi, on entre dans la phase de cadrage commune où on construit ensemble :
- L'architecture fonctionnelle détaillée.
- Les wireframes des écrans clés.
- Le schéma de données.
- Le plan de développement avec sprints chiffrés.
- Les critères de validation du MVP.
C'est ce travail commun qui produit le dossier de cadrage vivant qui guide le dev. Voir les livrables du cadrage et cadrer un MVP en 6 semaines.
Pour discuter de votre projet à partir d'un brief simple, prévoyez un premier appel. Voir aussi Analyse et cadrage.
Questions fréquentes
Faut-il vraiment un cahier des charges complet avant de consulter ?
Non, et c'est souvent contre-productif. Un cahier figé enferme dans des choix techniques avant validation du besoin. Mieux : un brief de 5-10 pages décrivant le contexte, le problème, les utilisateurs, les contraintes. Le prestataire propose la solution adaptée pendant le cadrage.
Comment formuler le besoin sans imposer la solution ?
Décrire le problème métier au lieu de la solution. Mauvais : « il faut un bouton bleu en haut de chaque page qui ouvre une modale avec... ». Bon : « l'utilisateur doit pouvoir lancer une nouvelle commande depuis n'importe où, en moins de 30 secondes ». Le « comment » appartient au prestataire.
Et si je veux consulter plusieurs prestataires sur le même brief ?
Possible mais piégeux. Le brief doit être identique côté formel, mais chaque prestataire le lira différemment. Plutôt qu'un benchmark de chiffres bruts, comparer les propositions : ce qu'ils proposent comme stack, méthode, équipe, hypothèses. La différence d'approche en dit plus que le prix.