Un bon cahier des charges de logiciel métier sur mesure ne commence pas par une liste d’écrans. Il décrit le travail que l’entreprise veut mieux maîtriser : les demandes qui arrivent, les décisions à prendre, les informations à vérifier, les validations, les documents produits et les exceptions à traiter. Il transforme ensuite ce fonctionnement en périmètre, règles et scénarios de test.
Cette méthode est adaptée à un outil conçu pour une entreprise déterminée, et non à un logiciel standard simplement paramétré. Elle aide à comparer une solution existante, un développement spécifique ou une combinaison des deux. Elle ne remplace pas l’analyse technique ni la relecture des conditions contractuelles, notamment pour les droits, les données et la maintenance.
Partir d’un processus observé plutôt que d’une idée d’écran
Choisissez un seul processus prioritaire : traiter une demande, préparer un devis, planifier une intervention, suivre une commande ou produire un document. Observez-le avec les personnes qui l’exécutent réellement. Demandez ce qui déclenche l’action, ce qui doit être connu, ce qui bloque et comment l’équipe sait que le dossier est terminé.
Décrivez le parcours dans l’ordre :
- événement de départ et source de la demande ;
- personne ou rôle qui prend le dossier ;
- informations obligatoires et pièces attendues ;
- décision, validation ou changement d’état ;
- notification, document ou export produit ;
- condition de clôture et éventuelle relance.
Un exemple concret vaut mieux qu’une formule comme « automatiser la gestion commerciale ». Écrivez plutôt : « lorsqu’une demande arrive par le formulaire, le responsable vérifie la zone d’intervention, attribue le dossier, demande les informations manquantes et crée une tâche de relance si aucune réponse n’est reçue ». Les écrans découleront de ces étapes.
Cette description révèle aussi les tâches qui ne doivent pas être automatisées. Une décision sensible, une exception ou une information incertaine peut nécessiter un contrôle humain. Le cahier des charges doit le signaler au lieu de supposer que chaque étape peut être exécutée automatiquement.
Définir les utilisateurs, les rôles et les responsabilités
Un même logiciel ne doit pas montrer les mêmes actions à tout le monde. Listez les profils qui utilisent l’outil et les responsabilités associées. Dans une petite entreprise, il peut s’agir de l’accueil, du responsable, d’un intervenant, de la direction et d’un administrateur technique.
Pour chaque rôle, précisez ce qu’il peut :
- consulter, créer, modifier ou supprimer ;
- valider ou refuser ;
- exporter ou partager ;
- administrer dans les réglages ;
- consulter après la clôture d’un dossier.
Ne vous contentez pas de « accès complet » et « accès limité ». Indiquez les objets concernés et les exceptions. Un intervenant peut avoir besoin de voir les informations nécessaires à sa mission sans accéder à l’ensemble des dossiers. Une personne chargée de la facturation peut modifier un statut financier sans pouvoir changer les règles de paramétrage.
Ces choix doivent être vérifiables. Ajoutez au cahier des charges un tableau simple : rôle, données visibles, actions permises, validation requise et trace conservée. Cela facilitera la conception, la recette et la discussion sur les responsabilités.
Décrire les données et les règles métier
Établissez l’inventaire des données nécessaires au processus. Distinguez les informations saisies, importées, calculées, générées et supprimées. Notez leur source, leur format, leur caractère obligatoire et leur durée d’utilité prévue.
Pour une demande client, le modèle peut contenir un contact, un service demandé, une zone géographique, un statut, une personne responsable, des échanges et des pièces jointes. Le cahier des charges doit préciser ce qui se passe si le numéro est absent, si deux dossiers semblent correspondre au même contact ou si une pièce est remplacée.
Formalisez ensuite les règles avec des phrases observables : « un dossier ne peut passer à l’étape validation que si les champs A et B sont remplis » ; « toute modification après validation crée une trace avec l’auteur et la date » ; « un utilisateur sans le rôle responsable peut proposer une clôture mais ne peut pas l’effectuer ». Évitez les formulations vagues comme « gestion flexible » ou « workflow intelligent ».
Si des données personnelles sont traitées, identifiez les personnes concernées, les accès, les opérations et les sous-traitants impliqués. La CNIL recommande notamment d’encadrer la sécurité, les responsabilités, les incidents et la restitution ou destruction des données dans la relation avec un sous-traitant ; consultez sa fiche sur la sécurité de la sous-traitance. Cette vérification décrit des points à préparer, pas une conclusion juridique sur votre projet.
Limiter une première version sans perdre le besoin essentiel
Un logiciel sur mesure devient difficile à cadrer lorsque toutes les demandes sont présentées comme prioritaires. Classez-les en trois groupes : indispensable pour le processus central, utile mais reportable, puis hypothèse à étudier. Pour chaque fonction, notez la valeur attendue, la dépendance éventuelle et le risque si elle n’est pas disponible à la première version.
La première version peut par exemple couvrir la création d’un dossier, son attribution, les validations principales, un historique, un export et une sauvegarde vérifiable. Une intégration complexe, un tableau de bord avancé ou une automatisation de cas rares peut être planifiée ensuite si elle ne bloque pas le parcours essentiel.
Cette séparation permet de comparer les offres sur un périmètre identique. Demandez que le devis distingue le développement spécifique, les composants génériques, les services tiers, la reprise de données, l’hébergement, la maintenance et les évolutions. Pour un logiciel dit propriétaire, vérifiez aussi les droits, le code, la documentation et les éléments réutilisables dans les documents applicables ; l’article L131-3 du Code de la propriété intellectuelle encadre la délimitation des droits transmis dans un acte de cession, à examiner avec un professionnel si nécessaire (texte officiel).
Décrire les intégrations, les accès et la sécurité
Un logiciel métier échange souvent avec un agenda, un CRM, un outil comptable, une messagerie ou un service de signature. Pour chaque intégration, indiquez le compte qui la contrôle, les données entrantes et sortantes, la fréquence, le format, les limites et le comportement si le service est indisponible.
Ajoutez les éléments d’exploitation : dépôt de code, environnements, hébergement, comptes administrateurs, sauvegardes, journaux, secrets et procédure de récupération. Évitez qu’un seul compte personnel du prestataire soit le point d’accès à toute l’application. Utilisez des comptes nominatifs, des rôles séparés et une procédure pour retirer un accès devenu inutile.
La sécurité doit apparaître dès la conception. L’ANSSI présente le cycle de développement sécurisé comme une démarche qui intègre la sécurité dans les étapes de conception, de développement et de déploiement ; son étude sur le S-SDLC et le DevSecOps fournit un point de départ pour discuter des pratiques adaptées au projet. Prévoyez au minimum une séparation entre test et production, une gestion des dépendances, des sauvegardes testées et un traitement documenté des incidents.
Transformer le cahier des charges en scénarios de recette
Chaque exigence importante doit donner lieu à un test. Écrivez un scénario avec un état de départ, un rôle, une action, un résultat attendu et une preuve. Ajoutez les cas d’erreur et les cas de reprise : donnée manquante, doublon, droit insuffisant, pièce invalide, service tiers indisponible, restauration ou export.
Exemple : « avec un compte responsable, créer une demande complète, l’attribuer à un utilisateur, la faire passer en validation et vérifier que l’historique conserve les deux changements ». Le scénario ne dit pas seulement que le bouton fonctionne ; il vérifie le processus et la trace attendue.
Faites exécuter les tests par les utilisateurs concernés sur un environnement séparé des données de production. Notez le résultat, la date, la personne qui valide et les écarts. Distinguez une anomalie bloquante, une correction nécessaire et une évolution hors périmètre. Cette distinction évite de transformer chaque demande apparue pendant la recette en modification implicite du projet.
La prochaine étape avant de demander un devis
Préparez une fiche de cadrage de deux à quatre pages : processus choisi, utilisateurs, données, règles, intégrations, première version, accès, sécurité, critères de recette et scénario de sortie. Faites-la relire par une personne qui réalise le travail et par une personne qui devra piloter l’outil.
Demandez ensuite une proposition qui reprend ce périmètre avec ses hypothèses, ses exclusions, ses livrables et ses conditions de maintenance. Pour discuter d’un besoin de logiciel conçu autour d’une organisation particulière, vous pouvez consulter les offres de l’Agence Digi ou présenter le contexte via la page contact. Un cahier des charges utile ne promet pas que le logiciel résoudra tout : il permet de savoir ce qui sera construit, comment le vérifier et ce qui reste à décider.