Conduite de projet
Cahier des charges logiciel métier : le guide utile
Préparez un cahier des charges logiciel qu'un prestataire peut chiffrer et tester : 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
- Le document part du problème à mesurer et des 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.
- En Algérie, écrivez aussi les obligations légales que le logiciel doit tenir : carnet des opérations de la loi 25-11, données inaltérables pour la caisse et la comptabilité au 1er janvier 2027.
À quoi sert 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 évite surtout deux dérives. La première consiste à développer des fonctions qui ne changent rien au travail. La seconde, à découvrir trop tard une règle métier qui bloque tout.
Rien n'oblige à tout prévoir, car les écrans et les choix techniques s'affinent pendant la conception. Le périmètre doit toutefois être assez 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 au besoin.
Transformez les souhaits en résultats observables
« Centraliser les données » ou « améliorer la productivité » ne donne rien à estimer ni à tester. Écrivez à la place 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.
Une première version qui couvre un flux complet
La première version doit couvrir un flux complet et déjà utile. 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. |
Les obligations légales à écrire dans le cahier des charges en Algérie
Certaines lois récentes demandent au logiciel lui-même de faire quelque chose. Si le cahier des charges ne les mentionne pas, le prestataire ne les chiffre pas, et vous les découvrez au moment d'un contrôle. Écrivez-les dans la partie « Contraintes », avec un cas de recette pour chacune.
Données personnelles : la loi 25-11 du 24 juillet 2025 demande un carnet automatisé des opérations. Le logiciel enregistre qui a consulté, modifié ou transmis une donnée personnelle, quand et pourquoi. Un cas de recette possible : un employé ouvre la fiche d'un client, et la consultation apparaît dans le carnet avec son nom et l'heure.
Caisse et comptabilité : la loi de finances 2026 fait démarrer au 1er janvier 2027 l'obligation de présenter, en cas de contrôle, un engagement de l'éditeur ou, pour la caisse, un certificat. Ce document atteste que personne ne peut modifier les données après coup. L'éditeur, y compris celui d'un logiciel sur mesure, doit aussi pouvoir remettre au fisc les codes, les données et la documentation. Les données se conservent jusqu'à la fin de la sixième année.
Vente en ligne : la loi 18-05 demande un site hébergé en Algérie en « .com.dz », des mentions obligatoires et une commande en trois étapes. Si le logiciel prend des commandes en ligne, ces écrans font partie du périmètre.
Ce que votre prestataire doit clarifier
Le devis doit distinguer conception, construction, mise en production et maintenance. Il doit aussi dire à qui appartiendront le code et les données, sur quel serveur tournera le système et qui contrôle les sauvegardes. Il doit enfin préciser comment le prestataire chiffrera les changements 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 devis qui n'en mentionne aucune, sur un besoin encore flou, les a simplement laissées de côté.
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 animer 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 ?
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.
Existe-t-il un modèle de cahier des charges logiciel gratuit ?
Oui. Ce guide propose un modèle Word gratuit en dix parties : contexte, objectifs, utilisateurs, parcours, règles métier, données, connexions, contraintes avec les obligations légales algériennes, priorités et recette. Il contient des tableaux à remplir, une ligne d'exemple par tableau et les questions à poser au prestataire.