MVP : couper le périmètre sans saboter le produit
5 min de lecture
À retenir
- Dix à quinze pages suffisent : au-delà, le document n’est plus lu, il est survolé.
- Décrivez les parcours utilisateurs, pas les écrans : les écrans sont le travail du prestataire.
- Toute exigence non chiffrable est une exigence qui sera interprétée à votre défaveur.
- La section la plus utile est celle qui liste ce qui n’est PAS dans le périmètre.
- Un cahier des charges sans priorisation produit des devis incomparables entre eux.
Nous recevons deux types de documents. Le premier fait soixante pages, contient une liste de deux cent quarante fonctionnalités numérotées, et ne permet pas de chiffrer quoi que ce soit. Le second fait douze pages, se lit en vingt minutes, et permet de produire un devis fiable le lendemain.
La différence n’est pas la longueur : c’est ce qui est décrit. Voici la structure que nous demandons, section par section.
1. Le contexte (1 page)
Qui vous êtes, ce que vous vendez, à qui. Comment le problème est résolu aujourd’hui, et pourquoi ça ne suffit plus. Ce que vous attendez du projet, exprimé en résultat métier — pas en fonctionnalité.
À écrire : « Nos techniciens saisissent leurs interventions le soir sur un tableur ; 15 % des rapports arrivent avec plus de trois jours de retard, ce qui décale la facturation. »
À ne pas écrire : « Nous voulons une application moderne et intuitive. »
2. Les utilisateurs (1 à 2 pages)
Pour chaque type d’utilisateur : qui il est, dans quelles conditions il utilise l’outil, avec quel appareil, et ce qui l’empêcherait de l’adopter.
Cette section change réellement l’architecture technique. « Nos techniciens travaillent souvent en sous-sol sans réseau » est une phrase qui vaut trois semaines de développement — et qui n’apparaît jamais dans une liste de fonctionnalités.
3. Les parcours (3 à 5 pages)
C’est le cœur du document, et la section que presque personne n’écrit correctement.
Pour chaque parcours important, racontez-le sous forme de récit : ce que l’utilisateur veut, ce qu’il fait, ce qui peut mal se passer, et comment ça se termine.
Le format qui marche : « En tant que technicien, je veux clôturer une intervention sur place pour ne pas avoir à la ressaisir le soir. Je scanne le numéro de série, je coche les opérations effectuées, je prends deux photos, je fais signer le client sur l’écran, je valide. Si je n’ai pas de réseau, l’intervention est enregistrée et partira automatiquement plus tard. »
Six lignes. Elles contiennent le scan, le mode hors-ligne, la signature, la synchronisation différée et la gestion des photos. Une liste de fonctionnalités n’aurait rien dit de tout ça.
4. Ce qui n’est pas dans le périmètre (1/2 page)
La section la plus utile du document, et la plus rare.
Écrivez explicitement ce que le projet ne couvre pas : « pas de facturation dans cette version », « pas de version tablette », « pas de reprise de l’historique antérieur à 2024 », « pas d’interface d’administration, les données sont gérées directement par l’équipe technique ».
Cette demi-page fait plus pour la fiabilité d’un devis que les quarante pages qui la précèdent.
5. Les contraintes (1 page)
- Techniques : systèmes existants à interfacer, format des données, authentification d’entreprise, hébergement imposé.
- Réglementaires : données personnelles, données de santé, accessibilité, secteur réglementé. Un point à traiter tôt, comme nous l’expliquons dans notre article sur la conformité RGPD.
- Organisationnelles : qui décide, qui recette, quelle disponibilité, quelles périodes de gel.
- Calendaires : dates réelles avec leur raison. « Avant le salon du 14 mars » est une contrainte ; « le plus tôt possible » n’en est pas une.
6. Les exigences non fonctionnelles (1/2 page)
Chiffrées, sinon elles ne servent à rien.
| Au lieu de | Écrivez |
|---|---|
| « L’application doit être rapide » | « Ouverture d’une fiche en moins d’une seconde sur un appareil de milieu de gamme en 4G » |
| « L’application doit supporter la charge » | « 300 utilisateurs simultanés en pointe, 5 000 comptes au total » |
| « L’application doit être fiable » | « Disponibilité de 99,5 % en heures ouvrées, sauvegarde quotidienne » |
| « L’application doit être sécurisée » | « Authentification à deux facteurs, chiffrement des données au repos, journalisation des accès » |
7. La priorisation (1/2 page)
Classez chaque parcours en trois niveaux : indispensable au lancement, important mais reportable, souhaitable un jour.
Sans cette section, tous les prestataires chiffrent l’intégralité et vous recevez des devis incomparables. Avec elle, vous obtenez des propositions structurées en phases, et vous gardez la main sur le budget. C’est le même exercice que celui décrit dans notre article sur le périmètre d’un MVP.
8. Le cadre de la consultation (1/2 page)
Budget indicatif ou fourchette acceptable, calendrier de décision, critères de choix, format de réponse attendu, interlocuteur.
10–15Pages suffisantes pour un cahier des charges utile
1/2 pageLa section « hors périmètre », la plus rentable du document
3Niveaux de priorité à attribuer à chaque parcours
Les cinq erreurs qui font exploser les devis
Décrire des écrans plutôt que des besoins. « Un écran avec un menu latéral et trois onglets » impose une solution avant d’avoir posé le problème. Le prestataire perd sa capacité à proposer mieux, et vous payez votre propre conception.
Mettre le mot « simple » partout. « Un back-office simple », « une synchronisation simple ». Ce mot ne signifie rien pour celui qui chiffre, et il cache systématiquement deux à trois semaines de travail.
Oublier les cas d’erreur. Que se passe-t-il si le paiement échoue, si l’utilisateur perd le réseau au milieu du formulaire, si deux personnes modifient la même fiche ? Non traités dans le document, ils seront traités en cours de projet — en avenant.
Confondre le lancement et la cible. Décrire le produit rêvé à trois ans donne un devis à trois ans. Décrivez la version 1, mentionnez la cible en annexe.
Ne pas nommer de décideur. Un projet sans interlocuteur unique disposant de deux à quatre heures par semaine prend 30 % plus de temps, quelle que soit la qualité du document.
Un bon cahier des charges ne décrit pas la solution. Il décrit le problème avec assez de précision pour que plusieurs solutions puissent être proposées et comparées.
Le modèle en une page
Si vous ne deviez retenir qu’un plan :
- Contexte et objectif métier chiffré
- Utilisateurs et conditions d’usage
- Parcours racontés, cas d’erreur compris
- Hors périmètre explicite
- Contraintes techniques, réglementaires, organisationnelles, calendaires
- Exigences non fonctionnelles chiffrées
- Priorisation en trois niveaux
- Cadre de la consultation
Envoyez-nous votre document, même incomplet : nous vous renvoyons gratuitement les questions qui manquent pour qu’il devienne chiffrable. C’est utile même si vous consultez ailleurs ensuite.
