Cahier des charges d’application : comment le rédiger

Pourquoi un document court vaut mieux qu’une longue spécification

Une longue spécification tente de répondre à toutes les questions avant que quiconque ait essayé le produit. Elle détaille souvent les fonctionnalités et à peine le problème. Un bon cahier des charges fait l’inverse : il est clair sur le problème, les personnes et la première version, et honnête sur ce qui reste inconnu. Visez deux à cinq pages. Au-delà, vous écrivez probablement déjà la version trois.

Écrivez-le en langage simple, comme si vous expliquiez le produit à un ami brillant qui ne connaît pas votre secteur. Évitez de nommer des technologies sans vraie raison, comme un système existant que l’équipe utilise déjà. Les développeurs proposeront la technique ; votre rôle est de rendre le problème, les personnes et les priorités impossibles à mal comprendre.

1. Le problème, en un paragraphe

Décrivez le problème tel qu’il existe aujourd’hui, sans parler de l’application. Qui le rencontre, à quelle fréquence, comment il est géré aujourd’hui et ce qu’il coûte en temps, en argent ou en erreurs. Si vous ne pouvez pas écrire ce paragraphe, le document n’est pas prêt, et aucun développeur ne pourra régler cela à votre place.

2. Utilisateurs et rôles

Listez chaque type de personne qui utilisera le produit et ce que chacune doit pouvoir faire. La plupart des logiciels métier comptent plus de rôles qu’on ne l’imagine : un administrateur, des employés aux droits différents, des clients ou des patients, parfois un partenaire ou un comptable qui ne fait que consulter. Pour chaque rôle, écrivez qui il est, ce qu’il fait dans l’application et ce qu’il ne doit jamais voir.

3. La mission unique de la version un

La version un doit bien faire une seule chose, pour un utilisateur principal. Écrivez-la en une phrase : une coordinatrice de clinique voit chaque nouvelle demande et y répond depuis un seul écran, ou un client réserve et paie une séance sans appeler. Tout ce qui figure dans la première version doit servir cette phrase. Le reste va sur une liste pour plus tard.

Gardez cette liste. Ce n’est pas un cimetière d’idées, c’est le début de votre feuille de route. Une fois la version un entre les mains de vrais utilisateurs, vous saurez lesquelles de ces idées comptent, et dans quel ordre.

Si la version un a trois missions principales, elle n’en a aucune. Choisissez celle qui rendrait le produit utile dès demain.

4. Les parcours clés, écran par écran

Décrivez pas à pas les principaux chemins d’un utilisateur, sous forme de liste d’écrans. Aucune compétence en design n’est nécessaire ; des mots simples ou des croquis suffisent. Par exemple :

Inscription : e-mail et mot de passe, confirmation de l’e-mail, choix du nom de l’entreprise.
Tableau de bord : la liste des demandes ouvertes, les plus récentes en premier, avec un filtre par statut.
Page d’une demande : détails, zone de réponse, bouton de statut, historique des modifications.
Paramètres : inviter un membre de l’équipe, choisir son rôle, retirer un accès.

Écrivez chaque parcours du point de vue de l’utilisateur, y compris ce qui se passe quand quelque chose ne va pas : un mauvais mot de passe, une liste vide, un paiement refusé.

5. Ce qui est exclu de la version un

C’est la section la plus utile du cahier des charges, et celle qui manque le plus souvent. Listez ce que vous avez décidé de ne pas construire tout de suite : l’application mobile, une deuxième langue, les rapports, les intégrations, une fonction d’IA. L’écrire protège votre budget et votre calendrier, et montre aux développeurs que vous avez fait des choix au lieu de laisser des trous.

6. Données et intégrations

Listez les principales informations que le produit conserve, comme les clients, les rendez-vous, les factures et les fichiers, et d’où elles viennent aujourd’hui. Notez les données existantes à importer, et chaque service externe auquel le produit doit se connecter : paiement, e-mail, WhatsApp, agendas, logiciel comptable. Précisez les règles éventuelles sur les données personnelles ou sensibles, et l’endroit où elles doivent être hébergées.

7. Mesures de succès et qui décide

Dites comment vous saurez que la version un fonctionne, en termes mesurables avec de vrais utilisateurs : inscriptions, comptes actifs, demandes traitées, temps gagné sur une tâche. Ce ne sont pas des objectifs à promettre, mais ce que vous mesurerez ensemble une fois le produit en ligne.

Nommez ensuite qui décide. Une personne doit valider le périmètre, les maquettes et les modifications, avec un suppléant. Les projets ralentissent quand les décisions attendent un comité ou changent selon qui était présent à la dernière réunion.

Pourquoi un Discovery Sprint vaut mieux qu’un devis ferme sur un document flou

Même un bon cahier des charges laisse des questions ouvertes. Quand il est encore flou, tout devis ferme pour l’ensemble du projet est une supposition : soit gonflé pour couvrir les inconnues, soit trop bas et suivi de demandes de modification. Un court Discovery Sprint de deux à trois semaines transforme le document en une première version fonctionnelle que vous pouvez parcourir et tester, avec un devis ferme pour le sprint lui-même. Vous décidez ensuite de la réalisation complète sur des faits, et le tarif du sprint en est déduit si vous poursuivez.

Nous avons préparé un modèle gratuit de cahier des charges d’application qui suit la structure de cet article, avec des questions pour chaque section et un exemple rempli. Téléchargez-le ci-dessous, remplissez-le à votre rythme et envoyez-le-nous quand vous êtes prêt. Nous lisons chaque document, répondons sous un jour ouvré et vous disons franchement si un Discovery Sprint ou une réalisation directe est le plus adapté.

Un MVP qui fonctionne en 2 à 3 semaines, pas des slides.Réserver un appel de cadrage de 30 min