Cahier des charges logiciel : décrire le travail avant les écrans

Décrire le problème et le résultat attendu

Commencez par la situation actuelle : qui fait quoi, avec quels fichiers ou logiciels, et où apparaît la difficulté. Écrivez ensuite ce qui devra être possible à la fin du projet. « Retrouver les rapports d'un équipement depuis sa fiche » est plus exploitable que « avoir une plateforme moderne et intuitive ».

Séparez le problème de la solution envisagée. Si les documents se perdent dans les e-mails, le besoin peut être de suivre leur réception ; il n'impose pas forcément une nouvelle messagerie. Notez les contraintes certaines et marquez les hypothèses à confirmer. Un désaccord visible pendant le cadrage coûte moins d'efforts à résoudre qu'une interprétation découverte à la livraison.

Nommer les utilisateurs et leurs parcours

Listez les rôles réels : personne qui saisit, responsable qui valide, client qui consulte, administrateur qui gère les accès. Pour chaque rôle, décrivez une action et son objectif. Le guide GOV.UK sur les besoins utilisateurs propose cette distinction entre acteur, action et but, puis des critères permettant de constater que le besoin est satisfait.

Exemple hypothétique : « En tant que responsable d'interventions, je veux voir les rapports incomplets pour demander une correction avant leur envoi. » Le parcours associé commence par une intervention terminée et finit par un rapport approuvé ou retourné au technicien. Précisez où arrivent les demandes de correction et ce que le client peut voir à ce moment.

Rendre les règles et exceptions vérifiables

Pour chaque parcours, fournissez un exemple normal et les variantes qui changent la décision. Que se passe-t-il si une pièce manque, si une personne quitte l'entreprise ou si deux utilisateurs modifient le dossier ? Une règle claire indique la condition, l'action attendue et la personne autorisée à passer outre lorsqu'une exception est permise.

Les critères d'acceptation décrivent un résultat observable. Ils servent ensuite à la recette. Évitez les formulations impossibles à vérifier telles que « aucune erreur » ou « très rapide » sans situation précise. Le prestataire peut proposer une mesure adaptée au contexte, que vous validez avant de développer.

• Un rapport incomplet indique les champs manquants et reste en brouillon.
• Un client consulte uniquement les dossiers qui lui sont attribués.
• Une correction laisse visible l'auteur, la date et la version concernée.
• Un envoi interrompu conserve le travail et explique comment reprendre.

Décrire les données et les connexions existantes

Joignez des exemples anonymisés ou fictifs qui reproduisent la structure utile. Listez les données à importer, les documents à produire et les logiciels avec lesquels échanger. Pour chaque information partagée, désignez sa source officielle : le nom du client vient-il du logiciel de facturation ou du nouvel outil ? Qui peut le corriger ?

Ne promettez pas une intégration sur la seule existence d'une marque de logiciel. Indiquez la version utilisée, les exports disponibles et la personne qui peut faire vérifier les accès. Le cadrage peut prévoir une étude de faisabilité avant un engagement sur la connexion. N'envoyez pas de mots de passe ou de documents confidentiels dans un dossier de consultation ouvert.

Séparer le premier lot, les suites et les exclusions

Le premier lot doit permettre de terminer un travail utile. Pour le suivi de rapports, il peut couvrir création, correction, validation et consultation. Une analyse statistique avancée ou une application mobile dédiée peut attendre si elle n'est pas nécessaire à ce parcours. Décrire explicitement ce qui attend évite de laisser croire que tout sera inclus.

Classez les demandes en indispensable au lancement, souhaité ensuite et hors périmètre. Ajoutez les dépendances : un export ne peut être validé tant que son format destinataire n'est pas connu. Désignez une personne capable de décider entre deux priorités et consignez ses arbitrages avec leur date. Le document peut évoluer sans perdre la trace du périmètre accepté.

Préparer une demande de devis comparable

Transmettez le même dossier aux prestataires et demandez des réponses structurées : compréhension du besoin, hypothèses, livrables, exclusions, travaux à votre charge, modalités de recette et suivi. Les inconnues doivent être nommées. Une offre détaillée n'est pas nécessairement plus longue ; elle permet surtout de comprendre ce qui explique son prix.

Vous pouvez partir de cette trame : contexte, utilisateurs, parcours, données, règles, interfaces, contraintes d'usage, premier lot et critères de validation. Ajoutez une liste des questions ouvertes. Des captures de l'existant et un exemple de document final apportent souvent davantage qu'un vocabulaire technique que l'équipe ne maîtrise pas. Les choix de technologie viennent après la compréhension du besoin.