On m'envoie régulièrement deux sortes de cahiers des charges. Le premier tient en trois lignes : « un SaaS de gestion pour les cabinets, un peu comme tel outil, mais en plus simple ». Le second fait soixante pages, décrit la couleur des boutons et ne dit nulle part qui va utiliser le produit ni ce qui compte vraiment. Aucun des deux ne permet de chiffrer sérieusement, et aucun ne protège le projet.
Cet article donne le modèle que j'utilise pour cadrer un SaaS ou une application web avant de m'engager sur un périmètre et un budget fixes. Si votre projet est une app mobile, la logique est la même mais certains points changent : je les ai détaillés dans le cahier des charges d'app mobile, et je reviens plus bas sur les différences.
Ma position : un cahier des charges sert à prendre des décisions, pas à tout décrire. Il fixe le quoi et le pourquoi, rend le périmètre comparable entre prestataires et dit clairement ce qui n'est pas dans la première version. Le comment appartient au développeur, qui doit le justifier.
Pourquoi un cahier des charges court bat un pavé
Un document de soixante pages donne une impression de maîtrise. En pratique, personne ne le relit en entier, les contradictions entre la page 12 et la page 47 ne sont découvertes qu'en développement, et les vraies priorités sont noyées sous les détails. Pire : il fige des choix d'interface avant que quiconque ait vu une maquette ou testé un parcours.
Le document que je cherche se lit en une demi-heure et répond à une seule question : a-t-on assez d'éléments pour s'engager sur un périmètre, un délai et une enveloppe ? Tout ce qui n'aide pas à trancher peut attendre les ateliers de cadrage, que je décris dans ma méthode pour cadrer un projet tech.
Contexte, objectifs, utilisateurs et rôles
Le contexte tient en un paragraphe : quel problème, pour qui, comment il est résolu aujourd'hui (Excel, un outil existant, rien du tout) et pourquoi ce n'est plus tenable. C'est la section qui permet au développeur de faire les bons arbitrages quand un cas imprévu se présente.
Les objectifs doivent être vérifiables : « remplacer le fichier de suivi partagé par les cinq commerciaux », « signer les dix premiers clients payants avant l'été ». « Moderniser notre gestion » n'est pas un objectif.
Les utilisateurs et les rôles sont la section la plus sous-estimée d'un SaaS. Listez chaque type d'utilisateur avec ce qu'il peut voir et faire : administrateur du compte client, membre, invité, lecteur seul, et votre propre équipe côté support. Une matrice de droits simple, même sur une demi-page, évite des semaines de reprise : les permissions touchent chaque écran et chaque requête.
Parcours clés et périmètre en user stories
Avant la liste de fonctionnalités, décrivez trois à cinq parcours de bout en bout : l'inscription et la création du compte, l'action qui fait la valeur du produit, le paiement, l'invitation d'un collègue. Étape par étape, en langage courant. Ce sont ces parcours que je teste en démo chaque semaine, et ce sont eux qui révèlent les oublis.
Le périmètre s'écrit ensuite en user stories, au format « En tant que [rôle], je veux [action] afin de [bénéfice] ». Chacune reçoit une priorité MoSCoW :
| Priorité | Signification | Exemple |
|---|---|---|
| Must | Sans elle, la version n'a pas de sens | En tant que gestionnaire, je crée un dossier client afin d'y suivre les échanges |
| Should | Importante, mais contournable au lancement | En tant que gestionnaire, j'exporte mes dossiers en CSV |
| Could | Confort, à faire si le budget le permet | En tant que membre, je choisis un thème sombre |
| Won't | Explicitement exclue de cette version | Application mobile native, multi-devises |
La colonne Won't est celle qui protège le plus votre budget. Ce qui n'est pas écrit comme exclu finit tôt ou tard par être considéré comme promis.
Données, intégrations et back-office
Les données : quelles grandes entités le produit manipule (clients, dossiers, factures), d'où elles viennent, s'il faut reprendre un historique existant et dans quel format. Une reprise de données depuis des fichiers hétérogènes est un chantier à part entière : mieux vaut le savoir avant le devis.
Les intégrations : paiement, emails transactionnels, outil comptable, CRM, authentification d'entreprise, API d'IA. Pour chacune, précisez le sens (lecture, écriture, les deux), la fréquence et si un compte existe déjà. Une intégration à un logiciel métier sans API documentée change complètement l'estimation.
Le back-office : qui, chez vous, va créer des comptes, rembourser un client, désactiver un utilisateur, corriger une donnée ? Si la réponse est « le développeur, en base », c'est un manque. J'ai consacré un article entier au back-office d'un SaaS : il mérite sa propre liste de user stories.
Les exigences non fonctionnelles
C'est la partie que les cahiers des charges oublient presque toujours, et celle qui coûte le plus cher à ajouter après coup. Pas besoin d'être technique pour la remplir : il suffit de dire ce que vous attendez.
- Performance : volumes attendus (nombre de comptes, d'utilisateurs simultanés, de documents), pics prévisibles, temps de réponse acceptable sur les écrans clés. Des ordres de grandeur suffisent.
- Sécurité : mode d'authentification, double facteur ou non, cloisonnement strict des données entre clients, journal des actions sensibles, exigences éventuelles de vos propres clients (questionnaires sécurité, audits).
- RGPD : quelles données personnelles, quelle durée de conservation, qui y accède, quels sous-traitants. La CNIL publie un guide RGPD destiné aux équipes de développement qui sert de référence ; ma checklist RGPD pour un SaaS en donne la version opérationnelle.
- Accessibilité : le niveau visé (le RGAA en France) et si votre activité entre dans le champ des obligations légales, élargies au privé par la transposition de l'European Accessibility Act, en application depuis juin 2025. Vérifiez votre cas : la réponse change le budget.
- Hébergement : contrainte de localisation des données (France, Union européenne), exigences d'un client grand compte, sauvegardes et délai de restauration acceptable.
- Réversibilité et propriété : le code, le dépôt, l'hébergement, le nom de domaine, les comptes Stripe et emailing doivent être à votre nom. C'est ce que je pratique sur tous mes projets : tout est créé sur les comptes du client dès le premier jour. Exigez aussi une documentation de passation, détaillée dans documentation et passation.
Points réglementaires relus en octobre 2026 : les obligations RGPD et accessibilité évoluent, vérifiez-les auprès des sources officielles (CNIL, textes de transposition) au moment de rédiger.
Critères d'acceptation, planning et budget
Les critères d'acceptation disent quand une user story est terminée. Exemple : « un membre invité reçoit un email, crée son mot de passe et arrive sur l'espace de son entreprise sans voir les données des autres comptes ». Sans eux, la recette devient un débat d'interprétation. Ma façon de la mener est dans la recette fonctionnelle avant mise en ligne.
Le planning indique les dates qui comptent vraiment (un salon, une échéance contractuelle, une levée) et votre disponibilité pour les démos et la recette. L'enveloppe budgétaire, même large, est indispensable : elle permet d'ajuster le périmètre au budget plutôt que de recevoir des devis incomparables. Pour les lire et les challenger, voir comment estimer et comparer un devis tech.
Ce qu'il faut laisser au développeur
Imposer un framework, une base de données ou un hébergeur précis sans raison métier, c'est se priver de l'expertise que vous payez. Laissez au développeur :
- le choix de la stack et de l'architecture, qu'il doit expliquer en termes compréhensibles ;
- le modèle de données détaillé ;
- le découpage en lots et l'ordre de réalisation ;
- les propositions de simplification quand une user story coûte cher pour peu de valeur.
En revanche, une contrainte réelle s'écrit : une équipe interne qui reprendra le code dans un langage donné, une DSI qui impose un cloud, un SSO d'entreprise. Ce sont des faits, pas des préférences.
SaaS ou app mobile : ce qui change
| Sujet | SaaS / application web | App mobile |
|---|---|---|
| Rôles et comptes | Central : multi-comptes, équipes, invitations, droits | Souvent un seul profil par appareil |
| Monétisation | Abonnements, plans, facturation par siège ou à l'usage | Achats intégrés soumis aux règles des stores |
| Contraintes de plateforme | Navigateurs supportés, responsive | Versions iOS et Android minimales, hors ligne, notifications |
| Mise en production | Déploiement continu, sans validation tierce | Revue des stores à intégrer au planning |
| Back-office | Indispensable dès le premier client | Indispensable aussi, souvent en web à côté |
Les erreurs que je vois le plus souvent
- Décrire des écrans au lieu de besoins. « Un bouton bleu en haut à droite » ne dit pas ce que l'utilisateur cherche à faire.
- Tout mettre en Must. Si tout est prioritaire, rien ne l'est, et le prestataire choisit à votre place.
- Oublier les rôles et le cloisonnement entre clients, puis les découvrir au moment d'ouvrir le produit à un deuxième compte.
- Copier un concurrent, avec dix ans de fonctionnalités accumulées, comme base de la première version.
- Ne rien dire sur la propriété du code et des comptes, et le découvrir au moment de changer de prestataire.
- Taire le budget en espérant obtenir un meilleur prix. Vous obtenez surtout des propositions impossibles à comparer.
Un bon cahier des charges ne prévoit pas tout. Il rend explicites les décisions qui coûtent cher quand on les prend trop tard.
Le modèle à remplir
Recopiez cette trame dans votre outil habituel. Chaque section tient en quelques lignes, sauf les user stories. Une case vide est une information utile : c'est une question à traiter en atelier de cadrage.
| Section | Questions à remplir | Format |
|---|---|---|
| 1. Contexte | Quel problème, pour qui, comment est-il géré aujourd'hui ? | 1 paragraphe |
| 2. Objectifs | Que doit-on constater à 3 et 12 mois pour parler de succès ? | 3 objectifs vérifiables |
| 3. Utilisateurs et rôles | Quels types d'utilisateurs, que peut voir et faire chacun ? | Matrice rôles × actions |
| 4. Parcours clés | Inscription, action principale, paiement, invitation : étape par étape | 3 à 5 parcours numérotés |
| 5. User stories | En tant que…, je veux…, afin de… | Tableau avec priorité MoSCoW |
| 6. Hors périmètre | Qu'est-ce qui est volontairement exclu de cette version ? | Liste Won't |
| 7. Données et intégrations | Entités, reprise d'historique, outils à connecter, comptes existants | Liste par outil |
| 8. Back-office | Qui administre quoi au quotidien ? | User stories dédiées |
| 9. Exigences non fonctionnelles | Volumes, sécurité, RGPD, accessibilité, hébergement, sauvegardes | Une ligne par sujet |
| 10. Réversibilité | Au nom de qui sont le code, les comptes, le domaine, les données ? | Liste de comptes |
| 11. Critères d'acceptation | Comment saura-t-on que chaque Must est terminé ? | 1 à 3 critères par story |
| 12. Planning et enveloppe | Échéances réelles, disponibilité pour les démos, budget envisagé | Dates et fourchette |
| 13. Laissé au prestataire | Quels choix techniques délégués, quelles contraintes imposées et pourquoi ? | 2 listes courtes |
Avec ces treize sections remplies, je peux m'engager sur un périmètre et un budget fixés avant de commencer, puis montrer l'avancement en démo chaque semaine en me référant aux user stories et à leurs critères. C'est aussi ce qui permet à n'importe quel prestataire de vous répondre sur une base comparable.
On relit votre cahier des charges ensemble ?
Envoyez-moi votre document, même incomplet, ou venez avec vos notes. En un appel, je vous indique les sections qui manquent et les points qui risquent de faire déraper le budget. Réservez un créneau. À lire ensuite : cadrer un projet tech.
