Cahier des charges métier : exprimer usages et critères de recette

Décrire les utilisateurs dans leur situation réelle

Listez les rôles : personne qui saisit, responsable qui valide, équipe qui exploite les données et direction qui consulte les indicateurs. Pour chaque rôle, racontez le début et la fin du travail, les informations nécessaires et les erreurs possibles. Un cas de refus ou d’annulation est souvent plus instructif qu’un parcours normal. Identifiez les postes, les navigateurs et les contraintes de connexion qui feront partie de la recette.

Rédigez les règles sous une forme vérifiable. Par exemple : une demande refusée reste consultable par son auteur ; sa modification crée une nouvelle version avant une autre validation. Ce scénario fictif sert à discuter le comportement attendu, pas à annoncer une obligation universelle. Précisez les exceptions et le responsable habilité à les autoriser.

Cadrer les données et les interfaces

Donnez un inventaire des ensembles de données, des volumes observés et des échanges. Pour une interface comptable, indiquez le système qui fait autorité, le format attendu et la fréquence utile. Si une API n’est pas connue, inscrivez une investigation à mener plutôt qu’une intégration supposée acquise. Les documents à générer ont besoin de modèles et de règles de numérotation, même si leur aspect graphique sera travaillé ensuite.

Les exigences de sécurité doivent être décrites par besoin : contrôle des accès, comptes distincts, sauvegardes, journal des modifications et modalités d’administration. La conformité ne se résume pas à une case dans le devis. Faites identifier les données personnelles, les finalités et les responsabilités à examiner avec les personnes compétentes. Ne joignez pas de données réelles à une consultation publique.

Organiser réception et changements

Associez chaque fonction indispensable à un scénario de recette, à un résultat attendu et à un valideur. Les critères peuvent couvrir le comportement, les données ou l’exploitation. Évitez une formule comme « rapide » sans contexte ; précisez l’opération et les conditions de test, puis convenez du seuil avec le prestataire. Le plan de recette distingue les anomalies bloquantes des réserves acceptables.

Prévoyez une procédure pour les demandes nouvelles : description, incidence sur les coûts, décision et mise à jour du périmètre. Un cahier des charges reste un outil de décision, pas une promesse que tout est connu dès le premier jour. Les droits sur les livrables, les exports, la documentation et la maintenance doivent apparaître dans les pièces contractuelles appropriées. Demandez une réponse structurée qui rende visibles les hypothèses et les exclusions.

Exercice fictif pour préparer la recette

Rédigez une exigence fictive : une demande de commande passe d’un brouillon à un état soumis, puis à une décision. Pour chaque transition, indiquez l’acteur, les données obligatoires et le résultat attendu. Ajoutez un refus et une demande de correction. Le prestataire doit pouvoir convertir cette description en parcours de prototype et en scénario de recette sans inventer la règle à votre place.

Demandez aux services concernés de lire le même cas. Si la comptabilité et le commerce donnent des réponses différentes à une annulation, faites arbitrer ce point avant consultation. Les divergences deviennent des décisions identifiées, pas des demandes contradictoires laissées dans plusieurs documents. Le responsable conserve les versions et les validations.

Testez ensuite la compréhension du cahier des charges avec un candidat. Il doit lister les hypothèses qu’il a retenues, les éléments absents et les exclusions de sa proposition. Comparez sa réponse avec le cas initial. Une démonstration esthétique ne suffit pas si le cas de refus ou la reprise après erreur n’est pas traité. Cette lecture croisée améliore la consultation sans imposer prématurément une technologie.

Une fiche de consultation à remplir avec le métier

Pour utiliser cette grille, réunissez le responsable du processus, un utilisateur qui connaît les exceptions et la personne qui suivra le budget. Préparez un exemple fictif représentatif plutôt qu’une base réelle. Pour chaque ligne, faites décrire l’état actuel, le résultat voulu et la personne habilitée à arbitrer un écart. Les éléments inconnus restent identifiés comme des investigations à mener avant l’engagement de réalisation.

Demandez au candidat de reprendre cette grille dans sa proposition, avec les livrables inclus et les exclusions. Une réponse qui ne couvre qu’un cas normal doit être précisée. Les erreurs, les annulations et les reprises après incident peuvent modifier le coût et le fonctionnement. Conservez les hypothèses acceptées avec le périmètre de recette afin que le responsable puisse vérifier la livraison.

Le rôle de Suite Métier est la mise en relation. Le prestataire confirme la faisabilité, son architecture et son devis après examen du besoin. Les modalités de reprise, les droits contractuels et les engagements de support sont à convenir avec lui. Aucun délai de réalisation ni résultat financier n’est garanti par cette fiche. Le décideur reste maître du choix et de la réception.

Questions pratiques

Préparer la suite du projet

• Migration Access vers une application web : cadrage, reprise et devis
• Demander un devis et cadrer votre besoin
• Audit de l’application existante : connaître les dépendances
• Power Apps ou application sur mesure : comparer les contraintes
• ERP ou application métier : placer les règles au bon endroit
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel