Comment rédiger un document de spécifications logicielles (avec un modèle simple)

La plupart des projets logiciels qui échouent ne sont pas dus à un code de mauvaise qualité. Ils échouent plutôt parce que les attentes des différentes parties prenantes divergent. Le responsable métier imaginait une chose, le développeur en a conçu une autre, et personne ne s'en est aperçu avant la démonstration. Un cahier des charges est l'outil le plus simple et le plus économique pour éviter ce genre de situation.

L'expression « cahier des charges » peut paraître complexe, comme un document élaboré par un comité pendant des mois. Pourtant, ce n'est pas forcément le cas. Pour la plupart des projets, un document clair de cinq à quinze pages, rédigé dans un langage simple, suffit à aligner les équipes, à établir des estimations précises et à éviter les dérives. Ce guide vous explique ce qu'il doit contenir, comment rédiger chaque partie et vous propose un modèle à utiliser. Si vous hésitez encore à développer une solution, lisez d'abord custom software vs off-the-shelf.

Pourquoi un cahier des charges est important

Un bon cahier des charges remplit plusieurs fonctions à la fois.

• Il crée une compréhension partagée. Tous les intervenants lisent la même description de ce qui sera développé.
• Il permet des estimations précises. Les fournisseurs peuvent proposer le même prix, ce qui rend les devis comparables. Notre guide des coûts des logiciels sur mesure explique comment le périmètre du projet influence le prix.
• Il contrôle le périmètre. Tout élément non documenté constitue soit une modification, soit une version ultérieure, et tout le monde le sait.
• Il réduit les reprises. Les malentendus sont généralement détectés sur papier, où ils sont moins coûteux, plutôt que dans le code.
• Il devient une référence. Les nouveaux membres de l'équipe, les testeurs et les futurs responsables de la maintenance peuvent ainsi comprendre les fonctionnalités du système.
• Il vous aide à choisir un partenaire. Présenter le même cahier des charges à plusieurs fournisseurs permet d'identifier ceux qui posent les bonnes questions ; consultez comment choisir une société de développement logiciel.

Ce que ce n'est pas

Un document de spécifications n'est pas une conception technique, et vous n'avez pas besoin de savoir comment le logiciel sera construit. Il décrit ce que le logiciel doit faire et pourquoi, et non comment il le fait. Les décisions concernant les frameworks, les bases de données et l'architecture reviennent à l'équipe de développement, en fonction de vos besoins.

Ces éléments ne sont pas figés. Les besoins évoluent au fur et à mesure de votre apprentissage, et une bonne documentation permet de gérer facilement ces changements. L'objectif est la clarté initiale, avec une méthode maîtrisée pour les adaptations ultérieures.

La structure que nous recommandons

Voici une structure qui convient à la plupart des projets. Adaptez-la à la taille du vôtre.

1. Vue d'ensemble et objectifs
2. Utilisateurs et leurs besoins
3. Périmètre : ce qui est inclus et ce qui est exclu
4. Fonctionnalités et récits utilisateurs
5. Règles et contraintes
6. Données et intégrations
7. Exigences non fonctionnelles
8. Priorités et plan de livraison
9. Indicateurs de succès
10. Questions ouvertes et hypothèses

Nous allons examiner chaque point ci-dessous.

1. Vue d'ensemble et objectifs

Commencez par un bref résumé compréhensible en une minute. Abordez trois points :

• Le problème. Que se passe-t-il actuellement ? Décrivez-le avec des exemples concrets : « Le personnel passe deux heures par jour à recopier les commandes entre feuilles de calcul, et les erreurs entraînent des retards de livraison. »
• L'objectif. Qu'est-ce qui devrait changer une fois le logiciel en place ? « Les commandes sont automatiquement transférées du site web à l'entrepôt, sans ressaisie. »
• Le contexte. Quelques phrases sur votre entreprise, afin que les lecteurs comprennent le contexte.

Cette section doit être concise. Elle a pour but d'expliquer la raison d'être du projet, et chaque décision ultérieure pourra être évaluée en fonction de celle-ci.

2. Utilisateurs et leurs besoins

Indiquez chaque type de personne qui utilisera le système et ce qu'elle devra faire. On les appelle souvent rôles ou personas d'utilisateurs.

Pour chaque rôle, écrivez :

• Qui sont-ils ? Client, réceptionniste, responsable, administrateur, etc.
• Que veulent-ils accomplir ? Leurs principaux objectifs.
• Quelles difficultés rencontrent-ils actuellement ? Les points faibles que le logiciel doit résoudre.
• Comment l'utiliseront-ils ? Appareil, fréquence d'utilisation et niveau de maîtrise technique.

Même quelques lignes par rôle sont précieuses. Si vous ne pouvez pas nommer vos utilisateurs, vous n'êtes pas prêt à développer. Cette approche permet également d'éviter l'erreur fréquente de concevoir pour le commanditaire du logiciel plutôt que pour les utilisateurs finaux.

3. Périmètre : ce qui est inclus et ce qui est exclu

Cette section est la plus susceptible d'éviter les désaccords. Rédigez deux listes.

Dans le périmètre de cette version : les fonctionnalités indispensables.

Hors périmètre pour le moment : les fonctionnalités envisagées mais délibérément reportées.

La seconde liste est tout aussi importante que la première. Il permet de consigner les bonnes idées sans les laisser gonfler la première version, et vous fournit une réponse toute prête lorsqu'on vous demande « et si… ? ». Si vous prévoyez une première version, consultez Qu'est-ce qu'un MVP ? et MVP vs produit complet pour savoir comment définir cette limite.

4. Fonctionnalités et scénarios utilisateurs

C'est le cœur du document. Décrivez ce que le système doit faire, organisé par domaine. Un format simple et efficace est le récit utilisateur :

En tant que [type d'utilisateur], je souhaite [faire quelque chose] afin de [bénéficier d'un avantage].

Exemples :

• En tant que client, je souhaite choisir un créneau horaire pour mon rendez-vous afin de ne pas avoir à appeler la clinique.
• En tant que responsable, je souhaite consulter les réservations du jour sur un seul écran afin de pouvoir planifier les effectifs.
• En tant qu'administrateur, je souhaite désactiver un compte utilisateur afin que les anciens employés ne puissent plus se connecter.

Sous chaque récit, ajoutez les critères d'acceptation : une courte liste de conditions qui doivent être remplies pour que le récit soit considéré comme terminé.

• Le client ne voit que les créneaux disponibles.
• Un e-mail de confirmation est envoyé dans la minute qui suit la réservation.
• Un créneau horaire réservé peut être modifié jusqu'à 24 heures à l'avance.

Les critères d'acceptation transforment les opinions en vérifications. Ils fournissent également aux testeurs un élément précis à vérifier.

Conseils pour rédiger des fonctionnalités efficaces

• Utilisez un langage clair. Évitez le jargon. Si un collègue non technique ne comprend pas, reformulez.
• Décrivez le comportement, pas les écrans. « Le client peut filtrer les commandes par date » est plus clair que « ajouter une liste déroulante en haut à droite ».
• Soyez précis sur les chiffres. « Rapide » et « nombreux utilisateurs » ne veulent rien dire. Dites plutôt « se charge en moins de trois secondes » ou « prend en charge 500 utilisateurs simultanément ».
• Une idée par exigence. Les exigences combinées masquent les détails et sont difficiles à tester.
• Utilisez des exemples. Un scénario concret vaut un paragraphe de description.
• Ajoutez des croquis. Un schéma, même sommaire, sur papier, dissipe beaucoup d'ambiguïté.

5. Règles et contraintes métier

Chaque entreprise a des règles que le logiciel doit respecter. On les oublie facilement car elles sont souvent instinctives. Notez-les.

Exemples :

• Les remises supérieures à 10 % nécessitent l’approbation du responsable.
• Les commandes passées après 15 h sont expédiées le jour ouvrable suivant.
• Un client ne peut pas avoir deux réservations simultanément.
• Les remboursements sont autorisés dans les 30 jours suivant l’achat.
• Les prix incluent la TVA pour les particuliers et l’excluent pour les professionnels.

Indiquez également les contraintes : limites budgétaires, délais, technologies, réglementations ou systèmes existants. Exemples : « Doit fonctionner sur notre hébergement actuel », « Doit être prêt avant la saison estivale », ou « Les données clients doivent rester dans le pays ».

Si votre secteur d’activité a des règles spécifiques, par exemple dans le domaine de la santé ou de l’éducation, mentionnez-les et confirmez les détails avec vos conseillers.

6. Données et intégrations

Expliquez quelles informations le système gère et à quoi il doit se connecter.

Données : Quels enregistrements existent (clients, commandes, produits, factures) ? À qui appartiennent ces données ? Combien de temps sont-elles conservées ? Disposez-vous déjà de données à importer depuis des tableurs ou d’autres systèmes ?

Intégrations : Listez tous les autres systèmes avec lesquels le logiciel doit communiquer : prestataires de paiement, outils comptables, services de messagerie, transporteurs, CRM, applications mobiles. Pour chacun, décrivez le sens du flux de données et sa fréquence.

Les intégrations sont une source fréquente de coûts cachés ; soyez donc aussi exhaustif que possible. Si vous n’êtes pas certain qu’un système propose une API, indiquez-le ; votre partenaire de développement pourra vérifier. Les projets qui unifient plusieurs outils, comme un CRM personnalisé (crm-software-development-cost.php) connecté à la comptabilité et à la messagerie, reposent fortement sur cette section.

7. Exigences non fonctionnelles

Ces exigences décrivent le fonctionnement requis du système, et non ses fonctionnalités. Elles sont faciles à négliger et coûteuses à ajouter ultérieurement.

• Performances : À quelle vitesse les pages doivent-elles se charger ? Combien d’utilisateurs peuvent y accéder simultanément ?
• Sécurité : Qui peut voir quoi ? Existe-t-il des exigences en matière de mot de passe, d'identifiant ou de protection des données ?
• Disponibilité. Quel est le temps d'indisponibilité acceptable ? Une sauvegarde est-elle nécessaire ?
• Compatibilité. Quels navigateurs, appareils et systèmes d'exploitation doivent être pris en charge ?
• Accessibilité. Le système doit-il respecter les normes d'accessibilité ?
• Évolutivité. Quelle croissance doit-il pouvoir gérer au cours des prochaines années ?
• Maintenabilité. Quelle documentation, quelle responsabilité du code et quel processus de transfert sont prévus ?
• Langue et région. Langues, devises, formats de date et fuseaux horaires.

Soyez réaliste. Exiger une disponibilité parfaite et une réactivité instantanée pour chaque action fait exploser les coûts. Déterminez ce qui est réellement important pour l'entreprise.

8. Priorités et plan de déploiement

Tout ne peut pas être développé en même temps. Hiérarchisez les fonctionnalités afin que l'équipe sache ce qui est le plus important. Une méthode courante et efficace est MoSCoW :

• Indispensable. Le système ne fonctionne pas sans.
• Souhaitable. Important, mais la version peut être déployée sans.
• Optionnel. Utile si le temps et le budget le permettent.
• Non inclus (pour le moment). Reconnu, mais délibérément reporté.

Ensuite, regroupez les fonctionnalités par versions. Une première version doit apporter une réelle valeur ajoutée, les versions suivantes venant l'enrichir. Cela favorise le développement par étapes, que nous recommandons pour presque tous les projets et que nous expliquons dans notre approche.

9. Indicateurs de succès

Comment saurez-vous que le logiciel a fonctionné ? Décidez avant de construire.

Exemples :

• Le temps de saisie des commandes passe de 10 à 2 minutes.
• Le nombre de rendez-vous manqués diminue d'un tiers.
• 80 % des clients réservent en ligne dans les six mois.
• L'établissement des rapports mensuels prend une heure au lieu de deux jours.

Les indicateurs permettent de maintenir le lien entre le projet et la valeur ajoutée pour l'entreprise et vous aident à déterminer si un investissement ultérieur est justifié.

10. Questions ouvertes et hypothèses

Aucun document n'est exhaustif. Soyez honnête quant à ce que vous ignorez.

• Questions ouvertes : points à trancher, avec un responsable et une date.
• Hypothèses : éléments que vous considérez comme vrais et sur lesquels repose le plan. « Nous supposons que le système comptable actuel propose une API. »

Les lister permet d'identifier les risques et aide votre partenaire de développement à les résoudre rapidement. Un bon partenaire remettra en question vos hypothèses. C'est le signe d'une équipe consciencieuse, pas d'une équipe difficile.

Un modèle simple à copier

Copiez ce plan dans un document et complétez-le.

1. Vue d'ensemble. Problème, objectif, contexte.

2. Utilisateurs. Pour chaque rôle : qui, objectifs, points de blocage, appareil et niveau de confiance.

3. Périmètre. Dans le périmètre de la version 1. Hors périmètre pour le moment.

4. Fonctionnalités. Pour chaque domaine : récits utilisateurs, chacun avec ses critères d'acceptation.

5. Règles et contraintes. Règles métier. Budget, échéance, technologie, réglementation.

6. Données et intégrations. Enregistrements traités, données à importer, systèmes à connecter, direction et fréquence.

7. Non fonctionnel. Performance, sécurité, disponibilité, compatibilité, accessibilité, évolutivité, langue.

8. Priorités. Liste MoSCoW et plan de publication.

9. Mesures de succès. Objectifs spécifiques et mesurables.

10. Questions et hypothèses ouvertes. Avec responsables et dates.

Erreurs courantes

1. Décrire une solution au lieu d'un besoin. « Nous avons besoin d'un menu déroulant » est une solution. « Le personnel doit pouvoir choisir un produit rapidement » est un besoin.
2. Manque de précision. « Convivial », « rapide » et « moderne » ne peuvent pas être testés.
3. Tenter de tout spécifier. Trop de détails trop tôt deviennent obsolètes. Détaillez la première version ; esquissez les suivantes.
4. Oublier les utilisateurs. Parlez aux personnes qui utiliseront le système, pas seulement à celles qui le paient.
5. Ignorer les exceptions. Les remboursements, les annulations, les erreurs et les cas particuliers sont les points faibles des systèmes.
6. Oublier l'administration. Quelqu'un doit gérer les utilisateurs, le contenu et les paramètres.
7. Ne permet pas de modifications. Prévoyez une procédure pour proposer, estimer et approuver les modifications.
8. Rédaction individuelle. Passez en revue le document avec les utilisateurs, les responsables et votre partenaire de développement.

Comment utiliser le document avec les développeurs

Ce document est plus efficace comme point de départ d'une discussion, et non comme un contrat immuable.

1. Partagez-le avec les fournisseurs présélectionnés et demandez-leur d'établir un devis à partir de celui-ci.
2. Soyez attentif à leurs questions. Les meilleures questions proviennent des équipes qui comprennent votre problématique.
3. Discutez des compromis. Un bon partenaire vous proposera des simplifications et des alternatives.
4. Améliorez-le ensemble. Mettez à jour le document au fur et à mesure des décisions prises.
5. Utilisez-le pendant le développement. Vérifiez la conformité du travail livré aux critères d'acceptation.
6. Maintenez-le à jour. Les modifications approuvées doivent être consignées dans le document.

Si vous ne savez pas par où commencer, de nombreuses équipes, y compris la nôtre, organisent une courte phase de découverte au cours de laquelle les exigences sont rédigées avec vous. C'est souvent la première étape la plus utile. Vous pouvez en voir un exemple sur notre page logiciels personnalisés, puis contactez-nous lorsque vous serez prêt.

Conclusion

Un cahier des charges n'est pas de la bureaucratie. C'est la meilleure assurance que vous puissiez prendre pour un projet logiciel. Il favorise la clarté, révèle les désaccords dès le début, fournit des estimations réalistes et permet au projet de rester concentré sur son objectif.

Vous n'avez pas besoin de rédiger un cahier des charges parfait. Un document clair, honnête et rédigé dans un langage simple, qui mentionne les utilisateurs, le périmètre, les fonctionnalités, les règles et les questions en suspens, vous donnera une longueur d'avance sur la plupart des projets. Si vous souhaitez de l'aide pour en rédiger un, décrivez-nous votre projet et nous vous accompagnerons.