Conduite de projet
Cahier des charges logiciel métier : le guide utile
Préparez un cahier des charges logiciel clair sans écrire un roman technique : objectifs, utilisateurs, flux, règles, données, sécurité et recette.
Un bon cahier des charges logiciel explique le résultat métier attendu, les utilisateurs, les parcours importants, les règles, les données et les critères d’acceptation. Il ne cherche pas à décider seul de toute la technique. Vingt pages concrètes et testables valent mieux que cent pages de fonctions vagues.
En bref
- Commencez par le problème mesurable et les utilisateurs concernés.
- Décrivez des parcours complets, y compris les erreurs et les exceptions.
- Séparez ce qui est indispensable au lancement de ce qui peut attendre.
- Écrivez des critères de recette observables : qui fait quoi, avec quelle donnée, et quel résultat doit apparaître.
À quoi sert vraiment le cahier des charges ?
Le document sert à aligner les personnes qui commandent, celles qui utilisent et celles qui construisent. Il donne une base commune pour estimer, concevoir, arbitrer et tester. Il protège surtout le projet contre deux dérives : développer des fonctions qui ne changent rien au travail et découvrir trop tard une règle essentielle.
Un cahier des charges n’est pas un contrat de divination. Les écrans et choix techniques s’affinent pendant la conception. Le document doit toutefois rendre le périmètre suffisamment précis pour que deux équipes comprennent le même projet.
La structure en neuf parties
Cette structure fonctionne pour une application interne, une plateforme web, un outil mobile ou la modernisation d’un système existant. Chaque partie peut tenir sur une ou deux pages au début.
- Contexte : activité, problème actuel et raison du projet maintenant.
- Objectifs : résultat attendu et indicateurs observables après lancement.
- Utilisateurs : rôles, responsabilités, fréquence d’usage et niveau d’accès.
- Parcours : scénarios principaux, de l’entrée à la sortie, avec exceptions.
- Règles métier : validations, calculs, statuts, délais et autorisations.
- Données : sources, qualité, historique à reprendre, exports et conservation.
- Connexions : comptabilité, paiement, messagerie, matériel, API ou fichiers.
- Contraintes : sécurité, disponibilité, appareils, réseau, langues et délais.
- Recette : cas qui prouveront que la livraison répond bien au besoin.
Transformez les souhaits en résultats observables
« Centraliser les données » ou « améliorer la productivité » ne permet ni d’estimer ni de tester. Écrivez plutôt ce qui doit devenir possible : un responsable voit le stock consolidé de trois dépôts sans demander de fichier ; une commande validée réserve automatiquement les quantités ; un opérateur retrouve l’historique d’un lot depuis son téléphone.
Un objectif utile précise la personne, l’action, la donnée et le résultat. Il peut ensuite devenir un scénario de démonstration et un cas de recette.
Définissez une première version qui tient debout
La première version n’est pas une collection arbitraire de petites fonctions. Elle doit couvrir un flux complet qui produit déjà une valeur. Par exemple : créer une commande, vérifier la disponibilité, préparer la sortie et confirmer la livraison. Un demi-module dans cinq domaines ne remplace pas un parcours utilisable.
Classez les demandes en trois groupes : indispensable au premier usage réel, nécessaire peu après, et amélioration future. Pour chaque élément indispensable, demandez ce qui se passe si vous le retirez. Si le projet fonctionne encore, il n’est probablement pas indispensable au lancement.
Écrivez la recette avant le développement
La recette décrit comment le client décidera que le logiciel fonctionne. Préparez des données d’exemple réalistes et des résultats attendus. Testez aussi les droits, les erreurs, les doublons, les pertes de connexion et les corrections.
| Trop vague | Testable |
|---|---|
| Le système gère les stocks. | Un magasinier enregistre une réception partielle et le reliquat reste visible. |
| Les accès sont sécurisés. | Un vendeur voit ses commandes mais ne peut ni modifier les marges ni exporter les clients. |
| L’application est rapide. | La recherche d’un article courant répond en moins de deux secondes sur le réseau du dépôt. |
| Les données sont importées. | Les clients, articles et soldes du fichier validé sont repris avec un rapport des lignes rejetées. |
Ce que votre prestataire doit clarifier
Le devis doit distinguer conception, construction, mise en production et maintenance. Demandez qui possède le code et les données, où le système sera hébergé, comment les sauvegardes sont vérifiées, comment les changements seront chiffrés et ce qui se passe si la collaboration s’arrête.
Une équipe sérieuse signale aussi les hypothèses et les zones encore inconnues. Un chiffre très précis posé sur un besoin encore flou n’est pas une preuve de maîtrise ; c’est souvent une incertitude cachée.
Questions fréquentes
Les réponses courtes
Qui doit rédiger le cahier des charges ?
Le responsable du besoin doit porter le contenu métier, avec les futurs utilisateurs. L’équipe technique peut faciliter les ateliers, structurer les scénarios et clarifier les contraintes, mais elle ne doit pas inventer seule les règles de l’entreprise.
Faut-il dessiner tous les écrans ?
Non. Des croquis peuvent clarifier un parcours, mais les maquettes détaillées appartiennent généralement à la phase de conception. Décider trop tôt tous les écrans peut figer une mauvaise compréhension du travail.
Quelle longueur pour un cahier des charges logiciel ?
Il n’existe pas de longueur idéale. Le document doit couvrir les flux critiques, les règles, les données, les contraintes et la recette sans répétition. Pour un premier périmètre bien contenu, quelques dizaines de pages concrètes peuvent suffire.