Cahier des charges logiciel : le guide complet pour bien lancer votre projet

Dans la plupart des projets logiciels qui dérapent, le problème ne vient pas du code. Il vient d'un besoin mal exprimé, compris différemment par le client et par l'équipe de développement, puis découvert trop tard, au moment de la recette. Le cahier des charges est l'outil qui permet d'éviter ce scénario : il transforme une intention (« nous voulons digitaliser nos inscriptions ») en un ensemble d'exigences vérifiables.

Ce guide présente la structure que nous recommandons à nos clients, la façon d'exprimer les besoins pour qu'ils soient exploitables, et les pièges que nous rencontrons le plus souvent.

Pourquoi le cahier des charges conditionne la réussite du projet

Un cahier des charges n'est pas un exercice administratif. Il remplit trois fonctions très concrètes :

• Aligner les parties prenantes : direction, utilisateurs métier, service informatique et prestataire partagent la même vision du résultat attendu.
• Permettre une estimation fiable : un prestataire ne peut chiffrer correctement que ce qu'il comprend. Plus le besoin est flou, plus les devis intègrent de marges de sécurité, ou d'hypothèses qui se révéleront fausses.
• Servir de référence lors de la recette : à la livraison, chaque fonctionnalité est vérifiée par rapport à ce qui avait été demandé. Sans référence écrite, la recette devient une négociation.

Cahier des charges fonctionnel ou technique ?

On confond souvent deux documents qui n'ont ni le même auteur ni le même objectif.

En tant que client, votre rôle est de produire un excellent cahier des charges fonctionnel. Imposer des choix techniques à ce stade (« le logiciel doit être développé en tel langage ») n'est pertinent que si une contrainte réelle l'exige, par exemple la compétence de votre équipe interne qui assurera la maintenance.

La structure que nous recommandons

1. Le contexte et les objectifs

Présentez votre organisation, la situation actuelle et, surtout, les objectifs mesurables du projet. « Améliorer la gestion » n'est pas un objectif ; « réduire le délai de traitement d'une inscription de trois jours à une journée » en est un.

2. Le périmètre

Précisez ce qui est inclus et, tout aussi important, ce qui ne l'est pas. Une liste explicite des exclusions évite de nombreux malentendus.

3. Les utilisateurs et leurs rôles

Listez chaque profil (administrateur, gestionnaire, client, agent terrain…), son nombre approximatif, son niveau d'aisance numérique et les appareils qu'il utilise.

4. Les processus métier

Décrivez les processus actuels et cibles, idéalement sous forme de schémas simples. C'est souvent en décrivant un processus que l'on découvre les cas particuliers.

5. Les exigences fonctionnelles

Le cœur du document : ce que le logiciel doit permettre de faire, exprimé du point de vue de l'utilisateur (voir ci-dessous).

6. Les exigences non fonctionnelles

Performance, sécurité, disponibilité, accessibilité, compatibilité : les critères de qualité du logiciel.

7. Les données et les interfaces

Quelles données existent déjà et devront être reprises ? Avec quels outils le logiciel devra-t-il échanger (comptabilité, paiement, messagerie, annuaire d'entreprise) ?

8. Les contraintes et le cadre du projet

Budget indicatif, échéances, contraintes réglementaires, hébergement souhaité, modalités de maintenance et de réversibilité.

Exprimer les besoins : user stories et critères d'acceptation

La manière la plus efficace d'exprimer un besoin fonctionnel est la user story : une phrase courte qui précise qui a besoin de quoi, et pourquoi. Elle est complétée par des critères d'acceptation qui décrivent précisément le comportement attendu.

En tant que secrétaire de scolarité,
je veux enregistrer le paiement d'un acompte sur une inscription,
afin de suivre le reste à payer de chaque famille.

Critères d'acceptation :
- Étant donné une inscription de 150 000 FCFA sans paiement,
  quand j'enregistre un acompte de 50 000 FCFA,
  alors le reste à payer affiché est de 100 000 FCFA.
- Un reçu numéroté est généré et peut être envoyé par e-mail ou SMS.
- Un acompte ne peut pas dépasser le reste à payer.

Ce format a un avantage décisif : chaque critère devient un test lors de la recette. Il n'y a plus d'ambiguïté sur ce qui est « terminé ».

Prioriser avec la méthode MoSCoW

Tous les besoins n'ont pas la même valeur. Classer chaque exigence permet de construire une première version utile rapidement, puis de l'enrichir :

• Must have : indispensable, sans quoi le logiciel n'a pas de sens.
• Should have : important, mais un contournement temporaire est possible.
• Could have : souhaitable si le budget et le calendrier le permettent.
• Won't have (this time) : écarté de cette version, à réexaminer plus tard.

Si plus de la moitié de vos exigences sont classées « Must have », la priorisation n'a probablement pas été faite sérieusement.

Les exigences non fonctionnelles, trop souvent oubliées

Elles ne décrivent pas ce que fait le logiciel, mais la qualité avec laquelle il le fait. Les omettre expose à de mauvaises surprises coûteuses :

• Performance : nombre d'utilisateurs simultanés, temps de réponse acceptable, volumes de données à cinq ans.
• Disponibilité : le service peut-il être interrompu la nuit ? Quel délai de rétablissement est acceptable en cas d'incident ?
• Sécurité : types de données manipulées, niveaux d'accès, traçabilité des actions, exigences de protection des données personnelles.
• Contexte d'usage : utilisation sur mobile, sur des réseaux lents, hors connexion.
• Accessibilité : utilisateurs malvoyants, langues à prendre en charge.
• Réversibilité : propriété du code source, export des données, documentation fournie en fin de contrat.

Les erreurs les plus fréquentes

• Décrire des solutions au lieu de besoins : « un bouton rouge en haut à droite » plutôt que « l'utilisateur doit pouvoir annuler une commande en cours ».
• Rédiger sans les utilisateurs finaux : le document reflète alors la vision de la direction, pas la réalité du terrain.
• Vouloir tout couvrir dès la première version : le projet s'alourdit, les délais s'allongent et la valeur arrive tard.
• Oublier la reprise des données : c'est souvent l'une des tâches les plus longues d'un projet de remplacement d'outil.
• Figer le document : un cahier des charges trop rigide empêche d'intégrer ce que l'on apprend en cours de route.

Un document vivant

Dans une démarche agile, le cahier des charges n'est pas un contrat gravé dans le marbre. Il fixe le cap, les objectifs et les contraintes ; le détail des fonctionnalités est ensuite affiné sprint après sprint, avec des démonstrations régulières qui permettent de corriger la trajectoire.

Un bon cahier des charges ne cherche pas à tout prévoir. Il rend explicite ce qui compte vraiment, pour que chaque décision prise en cours de projet puisse s'y référer.

En résumé : votre liste de contrôle

• Les objectifs du projet sont mesurables.
• Le périmètre et les exclusions sont explicites.
• Chaque profil d'utilisateur est identifié.
• Les besoins sont exprimés en user stories avec critères d'acceptation.
• Les exigences sont priorisées.
• Les exigences non fonctionnelles sont décrites.
• Les données à reprendre et les interfaces sont listées.
• Les conditions de maintenance et de réversibilité sont précisées.

Vous préparez un projet et souhaitez être accompagné dans la rédaction de votre cahier des charges ? C'est précisément le rôle de nos consultants en assistance à maîtrise d'ouvrage.