Un bon cahier des charges ne doit pas prévoir chaque écran. Il doit expliquer contexte, objectifs, utilisateurs, parcours prioritaires, contenus, données, intégrations, contraintes, critères de réussite et mode de décision. Il sert à réduire les inconnues et comparer des approches, pas à enfermer le projet dans une technologie choisie trop tôt.
Le pourquoi vient avant la liste de fonctions.
La longueur ne remplace pas les priorités.
Le projet doit être testable après le lancement.
1. Contexte et problème actuel
Décrivez comment le travail se fait aujourd’hui, les outils utilisés, les irritants et les conséquences. Cette partie permet de comprendre pourquoi le projet existe.
Ce que cela change concrètement
Dans la pratique, cette étape doit être reliée à Contexte et Utilisateurs. Expliquez l’existant et la raison du projet. Listez publics, rôles et besoins. Le but est de transformer une bonne idée en décision vérifiable plutôt qu’en simple préférence de projet.
Ajoutez également Must-have au contrôle. Priorisez ce qui doit fonctionner en V1. Pour une PME, ce niveau de précision évite les allers-retours tardifs, clarifie ce que le prestataire doit livrer et permet de relier le projet à un résultat commercial ou opérationnel.
2. Objectifs mesurables
Remplacez “moderniser le site” par des objectifs observables : augmenter les demandes qualifiées, réduire le temps de traitement, permettre une commande en ligne ou diminuer les erreurs.
Ce que cela change concrètement
Dans la pratique, cette étape doit être reliée à Utilisateurs et Must-have. Listez publics, rôles et besoins. Priorisez ce qui doit fonctionner en V1. Le but est de transformer une bonne idée en décision vérifiable plutôt qu’en simple préférence de projet.
Ajoutez également Contenu/données au contrôle. Distinguez textes, médias et données métier. Pour une PME, ce niveau de précision évite les allers-retours tardifs, clarifie ce que le prestataire doit livrer et permet de relier le projet à un résultat commercial ou opérationnel.
| Dimension | Question à poser | Bon signal |
|---|---|---|
| Contexte | Expliquez l’existant et la raison du projet. | Un tiers comprend le problème en quelques minutes. |
| Utilisateurs | Listez publics, rôles et besoins. | Les parcours sont liés à des utilisateurs réels. |
| Must-have | Priorisez ce qui doit fonctionner en V1. | Tout n’est pas marqué prioritaire. |
| Contenu/données | Distinguez textes, médias et données métier. | Les propriétaires sont identifiés. |
| Intégrations | Listez systèmes, APIs et contraintes. | Les inconnues sont visibles. |
| Gouvernance | Définissez budget, planning, décideurs et KPI. | Le processus de validation est clair. |
3. Utilisateurs et parcours
Identifiez les profils, leur niveau de connaissance et les actions principales. Une liste de fonctionnalités sans utilisateur conduit souvent à une interface incohérente.
Ce que cela change concrètement
Dans la pratique, cette étape doit être reliée à Must-have et Contenu/données. Priorisez ce qui doit fonctionner en V1. Distinguez textes, médias et données métier. Le but est de transformer une bonne idée en décision vérifiable plutôt qu’en simple préférence de projet.
Ajoutez également Intégrations au contrôle. Listez systèmes, APIs et contraintes. Pour une PME, ce niveau de précision évite les allers-retours tardifs, clarifie ce que le prestataire doit livrer et permet de relier le projet à un résultat commercial ou opérationnel.
4. Contenu, données et intégrations
Précisez les langues, les contenus existants, la migration, les données personnelles, le CRM, l’ERP, Microsoft 365, les paiements et les outils sectoriels.
Ce que cela change concrètement
Dans la pratique, cette étape doit être reliée à Contenu/données et Intégrations. Distinguez textes, médias et données métier. Listez systèmes, APIs et contraintes. Le but est de transformer une bonne idée en décision vérifiable plutôt qu’en simple préférence de projet.
Ajoutez également Gouvernance au contrôle. Définissez budget, planning, décideurs et KPI. Pour une PME, ce niveau de précision évite les allers-retours tardifs, clarifie ce que le prestataire doit livrer et permet de relier le projet à un résultat commercial ou opérationnel.
5. Priorités et critères d’acceptation
Classez les éléments en indispensable, important et ultérieur. Pour chaque parcours critique, décrivez le résultat attendu et les conditions de validation.
Ce que cela change concrètement
Dans la pratique, cette étape doit être reliée à Intégrations et Gouvernance. Listez systèmes, APIs et contraintes. Définissez budget, planning, décideurs et KPI. Le but est de transformer une bonne idée en décision vérifiable plutôt qu’en simple préférence de projet.
Ajoutez également Contexte au contrôle. Expliquez l’existant et la raison du projet. Pour une PME, ce niveau de précision évite les allers-retours tardifs, clarifie ce que le prestataire doit livrer et permet de relier le projet à un résultat commercial ou opérationnel.
Le brief devient la première version du backlog.
Après cadrage, objectifs et parcours sont transformés en user stories, critères d’acceptation, priorités et plan de livraison.
Voir notre approche produit ↗6. Budget, calendrier et gouvernance
Indiquez une enveloppe ou au moins un ordre de grandeur, les échéances réelles, les décideurs et les personnes disponibles pour valider. Cela permet de proposer un périmètre cohérent.
Ce que cela change concrètement
Dans la pratique, cette étape doit être reliée à Gouvernance et Contexte. Définissez budget, planning, décideurs et KPI. Expliquez l’existant et la raison du projet. Le but est de transformer une bonne idée en décision vérifiable plutôt qu’en simple préférence de projet.
Ajoutez également Utilisateurs au contrôle. Listez publics, rôles et besoins. Pour une PME, ce niveau de précision évite les allers-retours tardifs, clarifie ce que le prestataire doit livrer et permet de relier le projet à un résultat commercial ou opérationnel.
Questions à trancher avant de démarrer
Avant d’engager un budget, mettez les principales inconnues sur la table. Une question non tranchée n’est pas un problème si elle est visible ; elle devient un risque lorsqu’elle est cachée dans une hypothèse de devis ou découverte pendant le développement.
Répondez à ces questions avec les personnes qui utiliseront, vendront ou exploiteront la solution. Le cadrage devient alors un outil de décision interne, pas seulement un document à envoyer à une agence.
- Quel problème déclenche le projet ?
- Qui utilise la solution et pour quoi faire ?
- Quels parcours sont Must dans la V1 ?
- Qui fournit contenus et données ?
- Quelles intégrations restent à vérifier ?
- Qui décide et comment le succès sera-t-il mesuré ?
Erreurs fréquentes et signaux d’alerte
Les erreurs ci-dessous ont un point commun : elles déplacent une décision importante vers la fin du projet, moment où elle devient plus chère à corriger. Un bon processus cherche au contraire à rendre les risques visibles tôt.
Utilisez ces signaux comme critères de revue à chaque étape. Si plusieurs apparaissent en même temps, réduisez le périmètre, ajoutez une phase de cadrage ou validez un prototype avant de poursuivre.
- Imposer une technologie sans contrainte réelle
- Décrire uniquement des écrans sans expliquer le workflow
- Marquer toutes les fonctions Must
- Oublier contenu et traduction
- Cacher les inconnues au lieu de les lister
- Ne pas donner d’ordre de grandeur budgétaire
Plan d’action recommandé
La bonne décision doit pouvoir être vérifiée après le lancement. Définissez une baseline, un responsable et une fréquence de revue. Mesurez ensuite les mêmes indicateurs après le lancement afin de distinguer l’impression d’amélioration du résultat réel.
Une roadmap utile sépare le lancement des évolutions. Les fonctions secondaires doivent être priorisées à partir des données d’usage, des leads, des tickets ou des gains opérationnels plutôt qu’à partir d’une liste figée avant le projet.
- 1. Contexte — Pourquoi maintenant ?
- 2. Utilisateurs — Qui fait quoi ?
- 3. Parcours — Must / Should / Could.
- 4. Données — Entrées, sorties et intégrations.
- 5. Contraintes — Sécurité, SEO, conformité.
- 6. Gouvernance — Budget, planning, KPI, décideurs.
Construire le business case avant de demander un devis
Un projet autour de Cahier des charges pour un site ou une application : modèle utile devient plus simple à arbitrer lorsqu’il est formulé comme un investissement et non comme une liste de fonctionnalités. Commencez par écrire le résultat attendu en une phrase : davantage de demandes qualifiées, moins de ressaisie, un cycle de vente plus court, une meilleure autonomie des utilisateurs ou une réduction du risque. Cette phrase sert ensuite à évaluer chaque choix de périmètre.
Le premier niveau du business case relie Contexte à Utilisateurs. Expliquez l’existant et la raison du projet. Listez publics, rôles et besoins. Chiffrez la situation actuelle lorsque c’est possible : nombre de demandes par mois, minutes consacrées à une tâche, taux d’abandon, coût d’un outil remplacé, volume d’erreurs ou délai moyen. Même une estimation imparfaite est plus utile qu’un objectif abstrait de ‘modernisation’.
Le deuxième niveau consiste à intégrer les coûts qui apparaissent après la mise en ligne. Intégrations et Gouvernance doivent donc figurer dans la décision au même titre que le design ou le développement. Listez systèmes, APIs et contraintes. Définissez budget, planning, décideurs et KPI. Une proposition moins chère au départ peut devenir plus coûteuse si elle dépend de beaucoup d’opérations manuelles, de licences mal anticipées ou d’une architecture difficile à faire évoluer.
Enfin, donnez une valeur au risque évité. Must-have et Contenu/données influencent souvent le coût réel plus que prévu. Priorisez ce qui doit fonctionner en V1. Distinguez textes, médias et données métier. La bonne question n’est donc pas seulement ‘combien cela coûte ?’, mais ‘quel niveau d’investissement est cohérent avec le résultat, le risque et la durée de vie attendus ?’.
Trois scénarios de périmètre pour décider
Ces trois scénarios ne sont pas des packs tarifaires. Ils servent à séparer le besoin essentiel de l’ambition à moyen terme. Un bon devis doit rendre visibles ces niveaux afin que vous puissiez retirer ou reporter une fonction sans casser la logique du produit.
Comparer deux propositions sans comparer des pommes et des poires
Deux offres qui annoncent le même livrable peuvent couvrir des réalités très différentes. Pour comparer correctement, demandez aux prestataires de répondre au même périmètre, avec les mêmes hypothèses et la même définition de ‘terminé’. Le prix devient alors une conséquence de choix visibles au lieu d’un chiffre impossible à interpréter.
Exigez aussi les responsabilités : qui fournit les contenus, qui valide, qui configure les accès, qui réalise la migration, qui teste, qui héberge et qui intervient après mise en ligne ? Les zones grises sont souvent la première source de dépassement de budget ou de planning.
| Critère | Ce qu’il faut vérifier | Preuve attendue |
|---|---|---|
| Contexte | Expliquez l’existant et la raison du projet. | Un tiers comprend le problème en quelques minutes. |
| Utilisateurs | Listez publics, rôles et besoins. | Les parcours sont liés à des utilisateurs réels. |
| Must-have | Priorisez ce qui doit fonctionner en V1. | Tout n’est pas marqué prioritaire. |
| Contenu/données | Distinguez textes, médias et données métier. | Les propriétaires sont identifiés. |
| Intégrations | Listez systèmes, APIs et contraintes. | Les inconnues sont visibles. |
| Gouvernance | Définissez budget, planning, décideurs et KPI. | Le processus de validation est clair. |
Mesurer la valeur après le lancement
Le suivi doit commencer avant la mise en ligne. Choisissez deux à quatre KPI directement liés au business case, documentez leur valeur actuelle et définissez qui les relira après 30, 60 et 90 jours. Pour Contexte et Utilisateurs, privilégiez les indicateurs qui montrent un changement de comportement, pas seulement une hausse du trafic.
Ajoutez ensuite des indicateurs de qualité autour de Must-have et Contenu/données. Un produit peut convertir davantage tout en générant plus d’erreurs ou de support ; inversement, une automatisation peut réduire le temps de traitement sans améliorer la satisfaction. Les métriques doivent donc représenter plusieurs dimensions de valeur.
Enfin, reliez Intégrations et Gouvernance au coût d’exploitation. Notez les licences, le temps d’administration, le nombre de tickets, les heures de maintenance et les évolutions nécessaires. Après quelques mois, vous disposerez d’une base factuelle pour décider d’investir, de simplifier ou d’étendre la solution.
- Conversion ou adoption
- Temps gagné
- Qualité / erreurs
- Délai de traitement
- Coût d’exploitation
- Satisfaction utilisateur
Un modèle directement réutilisable
Êtes-vous prêt à avancer ?
Questions fréquentes
Dois-je imposer une technologie ?+
Seulement si une contrainte réelle l’exige. Décrivez d’abord le besoin et demandez une recommandation argumentée.
Quelle longueur viser ?+
Un document clair de quelques pages vaut mieux qu’un dossier long rempli d’hypothèses.
Puis-je envoyer des exemples ?+
Oui, en précisant ce que vous appréciez dans chaque exemple.
Faut-il indiquer le budget ?+
Un ordre de grandeur aide les prestataires à proposer un périmètre réaliste et évite des réponses qui ne jouent pas dans la même catégorie.
Le brief doit-il choisir la technologie ?+
Seulement lorsqu’une contrainte réelle l’impose. Sinon, demandez au prestataire de proposer et justifier l’architecture.