Cahier des charges logiciel : le guide (et pourquoi le vôtre est trop long)

La plupart des projets de logiciel sur mesure n'échouent pas dans le code. Ils échouent dans le cahier des charges. Soit il n'y en a pas, soit c'est un document de 50 pages écrit avant d'avoir compris le problème, figé en contrat que plus personne ne relit après la deuxième semaine.

Un cahier des charges logiciel, c'est simplement une description partagée de ce que le logiciel doit faire, et pourquoi. Son rôle est de créer un accord entre vous et celui qui le construit, pas de prévoir chaque écran à l'avance. Voici comment en écrire un qui aide vraiment : une définition claire, ce qu'il faut y mettre, un exemple concret et un modèle à copier.

---

Qu'est-ce qu'un cahier des charges ?

Définition, en une phrase : un cahier des charges est le document qui décrit ce qu'un logiciel doit faire et pourquoi, comme accord écrit entre le client et celui qui va le construire. Ce n'est pas un plan technique, ni un contrat figé : c'est un point de référence partagé sur le problème à résoudre et le résultat attendu.

On distingue souvent deux formes, et les confondre est une source classique de projets qui déraillent : le cahier des charges fonctionnel (ce que le logiciel doit faire, côté métier) et le cahier des charges technique (comment il sera construit). Les deux sont utiles, mais pas au même moment.

Cahier des charges fonctionnel ou technique ?

La distinction revient sans cesse, alors clarifions-la :

• Le cahier des charges fonctionnel décrit les besoins métier : les fonctions attendues, les utilisateurs, les workflows, les résultats. Il répond à « quoi » et « pourquoi », sans présumer de la technologie. C'est celui par lequel commencer.
• Le cahier des charges technique décrit le « comment » : architecture, technologies, performances, sécurité, contraintes d'intégration. Il est souvent rédigé plus tard, avec le prestataire, une fois le fonctionnel clair.

Notre conseil : commencez par le fonctionnel, et gardez-le court. Le technique découle des choix de construction ; le figer trop tôt revient à imposer une solution avant d'avoir compris le problème.

Ce qu'il faut vraiment y mettre

Faites-le assez court pour qu'on le lise. En pratique, un cahier des charges utile tient en six points :

• Le problème et le contexte. Ce qui coince aujourd'hui, pour qui, et ce que ça coûte (temps, erreurs, argent). Pas "on veut une application", mais : "un devis prend trois heures dans un tableur et 1 sur 5 part avec une erreur de prix."
• Les utilisateurs et leur travail. Qui s'en sert et ce qu'ils cherchent à accomplir. Un outil pour deux utilisateurs avancés n'est pas le même projet qu'un outil pour cinquante utilisateurs occasionnels.
• Les workflows principaux. Les trois ou quatre choses que le logiciel doit faire de bout en bout. Décrivez le flux, pas chaque bouton.
• Indispensable ou souhaitable. Une ligne explicite entre ce dont la version 1 a besoin et ce qui peut attendre. Cette seule distinction économise plus de budget que tout le reste.
• Les contraintes. Les systèmes auxquels il doit se connecter (ERP, comptabilité, messagerie), les données qu'il manipule, les exigences de sécurité et de RGPD, et les échéances fermes.
• À quoi ressemble le succès. Un ou deux résultats mesurables : "un commercial envoie un devis juste en moins de 10 minutes", pour que tout le monde sache quand ça a marché.

C'est tout. Si votre document est plus long que ce que votre équipe lira vraiment, ce n'est pas un cahier des charges, c'est une armoire à archives.

Un exemple concret

La théorie est plus claire avec un exemple. Voici à quoi ressemble un cahier des charges fonctionnel utile, pour une PME qui veut remplacer son processus de devis sous Excel :

Une page, six points, et tout le monde sait ce qu'on construit et pourquoi. C'est un exemple, pas un gabarit rigide : adaptez-le à votre projet.

Les erreurs qui coulent les projets

• Spécifier des solutions au lieu des problèmes. "Ajoutez un menu déroulant ici" masque le vrai besoin et bloque de meilleures réponses. Décrivez le résultat, laissez celui qui construit proposer le comment.
• Figer le périmètre avant d'avoir appris quoi que ce soit. Les hypothèses les plus coûteuses sont celles écrites comme des exigences dès le premier jour et jamais remises en question.
• Ignorer la réalité des données et des intégrations. Où vivent les données aujourd'hui, dans quel état, et qu'est-ce qui doit parler à quoi ? C'est là que les projets "simples" deviennent chers.
• Aucun indicateur de succès. Sans lui, "terminé" devient une discussion au lieu d'un fait.

Notre avis : le cahier des charges est un point de départ, pas une forteresse

Nous construisons des logiciels pour vivre, et les meilleurs projets ne commencent pas par un cahier des charges parfait de 50 pages. Ils commencent par un brief clair d'une page et une première tranche à forte valeur : quelque chose de réel en quelques semaines, pas une livraison massive dans un an. On apprend plus d'une fonctionnalité qui tourne que de trois mois de spécifications.

Le développement assisté par IA rend cela encore plus vrai : il est aujourd'hui moins cher de construire une première version et d'itérer que d'essayer de tout spécifier d'avance. Alors écrivez le cahier des charges pour vous mettre d'accord sur le problème et la première tranche, puis laissez la réalité affiner le reste.

Un modèle à copier

Voici le modèle, réduit à l'essentiel. Copiez-le, remplissez-le en une page :

Oubliez le document de 50 pages

Si vous cadrez un outil sur mesure devant un cahier des charges vierge, n'en faites pas trop. Envoyez-nous la version d'une page, ou même la version brouillon, et nous vous dirons honnêtement ce qui manque et si le projet en vaut la peine. Contactez-nous.

À lire aussi : ce qu'est un logiciel sur mesure et quand il en vaut la peine, low-code, no-code ou sur mesure : comment choisir, et la modélisation des processus métier.