Comment rédiger le cahier des charges d’un logiciel métier ?

Observer le processus actuel avant d’imaginer le logiciel

Choisissez trois opérations fréquentes, coûteuses ou risquées et suivez-les du déclenchement à la clôture. Notez qui agit, dans quel outil, avec quelle donnée, quelle validation et quelle exception. Collectez des exemples anonymisés de documents et de messages plutôt qu’une liste de souhaits abstraits.

Distinguez règle métier, habitude locale et contournement causé par l’outil actuel. Automatiser un contournement peut figer un mauvais processus au lieu de le simplifier.

• Déclencheur et résultat final
• Rôles et responsabilités
• Données créées ou modifiées
• Décisions et exceptions
• Temps perdu et risque associé

Écrire des besoins vérifiables

Formulez chaque besoin comme un résultat observable : “le responsable affecte une intervention à un technicien disponible et celui-ci reçoit les informations nécessaires”. Évitez “interface moderne”, “gestion intuitive” ou “système complet” sans critère.

Ajoutez un scénario nominal, une exception et une règle d’acceptation. Exemple : si deux interventions se chevauchent, le logiciel avertit avant validation sans modifier silencieusement le planning.

• En tant que rôle
• Je veux réaliser une action
• Afin d’obtenir un résultat
• C’est accepté lorsque la preuve est observable

Choisir un MVP qui termine un parcours important

Classez les besoins selon valeur, fréquence, risque et dépendance. Le MVP n’est pas la version la moins chère ni une collection d’écrans : il doit permettre de terminer au moins un parcours prioritaire sans ressaisie critique dans un tableur.

Placez le reste dans une feuille de route conditionnelle. Une fonctionnalité liée à une hypothèse doit attendre que l’usage précédent soit validé. Cette discipline réduit le délai avant retour utilisateur et évite de financer des fonctions jamais utilisées.

Cartographier données, intégrations et migration

Pour chaque objet — client, dossier, intervention, produit, facture — indiquez les champs indispensables, la source, le propriétaire, la durée de conservation et les personnes autorisées. Listez les imports, exports et API avec leur fréquence et leur comportement en cas d’échec.

La reprise de données mérite un lot propre : nettoyage, correspondance des champs, jeu d’essai, contrôle des totaux et procédure de retour arrière. “Importer l’historique” ne suffit pas à chiffrer le travail.

• Source et qualité des données
• Volume et historique à reprendre
• Formats et API disponibles
• Règles en cas de conflit
• Export de sortie documenté

Intégrer la sécurité et la continuité dès le périmètre

Décrivez l’authentification, les rôles, les actions sensibles, la journalisation, le chiffrement des échanges, les sauvegardes et les délais de restauration attendus. Appliquez le moindre privilège : chaque profil n’accède qu’aux données et actions nécessaires.

Ajoutez les environnements de test et production, la gestion des secrets, les mises à jour, la notification d’incident et les responsabilités. Le niveau doit être proportionné aux données et aux conséquences d’une indisponibilité ; une promesse de “sécurité totale” serait trompeuse.

Préparer la recette avec les futurs utilisateurs

Construisez un jeu de données représentatif mais maîtrisé et attribuez chaque scénario à une personne. Testez parcours normal, droit insuffisant, donnée manquante, panne d’intégration et export. Un test “ça marche chez le développeur” ne constitue pas une recette.

Consignez résultat attendu, résultat obtenu, gravité, décision et date de correction. Définissez ce qui bloque la mise en production et ce qui peut rejoindre la feuille de route.

• Critère mesurable
• Responsable du test
• Donnée de test
• Résultat attendu
• Décision signée

Cadrer propriété, maintenance et sortie

Le contrat doit distinguer code spécifique, composants tiers, licences, hébergement, documentation, accès et données. Précisez les formats d’export, l’assistance à la sortie et ce qui continue de fonctionner après la fin de la collaboration.

La maintenance doit nommer surveillance, sauvegarde, correction, mise à jour, évolution, délai de réponse et canal de support. Sans cette précision, deux parties peuvent utiliser le même mot pour des obligations très différentes.

Écrire les exigences non fonctionnelles et la volumétrie

Un parcours correct peut devenir inutilisable s’il répond trop lentement, ne supporte pas les volumes ou reste indisponible au mauvais moment. Indiquez utilisateurs simultanés, volume initial, croissance estimée, taille des fichiers, horaires critiques et dépendances externes. Définissez des objectifs mesurables proportionnés, sans promettre une disponibilité absolue.

Ajoutez accessibilité, appareils, navigateurs, journalisation, localisation, durée de conservation, temps de restauration et performance attendue sur les opérations critiques. Chaque exigence doit avoir une méthode de test et un responsable.

• Volumétrie actuelle et à 24 mois
• Temps de réponse par opération
• Objectifs de sauvegarde et restauration
• Accessibilité et appareils
• Supervision et alertes

Définir gouvernance, calendrier et budget par lots

Construisez une matrice RACI : qui est responsable de l’exécution, qui approuve, qui est consulté et qui est informé pour le cadrage, le prototype, les données, la sécurité, la recette et la mise en production. Une seule personne approuve chaque décision afin d’éviter les validations contradictoires.

Découpez le budget en cadrage, prototype, MVP, intégrations, migration, recette, déploiement et maintenance. Le calendrier associe dépendance, livrable, validation et marge de risque. Une fourchette honnête explicite ses hypothèses : disponibilité des API, qualité des données, nombre de rôles et délais de retour.

• Lot et livrable
• Hypothèses et exclusions
• Responsable et approbateur
• Budget ou fourchette
• Critère de passage au lot suivant

Exemple rempli : planifier une intervention

Entreprise fictive : Atelier Horizon. Déclencheur : un devis signé. Rôle : planificateur. Données : adresse, compétences requises, durée, matériel et créneaux. Règle : proposer uniquement un technicien disponible possédant la compétence. Exception : aucune disponibilité dans le délai promis. Sortie : intervention affectée et client informé.

Critères de recette : un chevauchement est bloqué ; un utilisateur sans droit ne voit pas les données financières ; une panne de messagerie conserve la mission et crée une alerte ; l’export contient les champs convenus. NFR illustratifs : pages critiques testées sous charge convenue, sauvegarde vérifiée et restauration répétée avant production. Ces valeurs doivent être fixées selon le risque réel.

• R : chef de projet métier
• A : dirigeant
• C : techniciens et comptabilité
• I : support et prestataire d’hébergement