Démonstration et recette ERP : tester les bons scénarios

Une démonstration aide à explorer une offre ; la recette vérifie ce qui a été livré. Utilisez des scénarios proches de votre activité pour les deux, mais précisez leur statut. Un parcours montré avant signature ne devient un engagement que s’il est repris dans le périmètre convenu. Définissez donc les résultats attendus et les critères bloquants avant la mise en service.

Préparer des scénarios de bout en bout

Un bon scénario suit une opération jusqu’à son résultat final. Décrivez le contexte, les données d’entrée, les rôles et les contrôles. Incluez un parcours normal et une exception significative. Pour une vente, ne vous arrêtez pas à la création de la facture : vérifiez aussi le règlement ou l’export prévu. Limitez le nombre de scénarios pour pouvoir les observer correctement. Les candidats doivent travailler sur une base commune, tout en expliquant les différences de méthode. Évitez les tests uniquement conçus pour reproduire les écrans de l’ancien outil.

Observer les actions et les limites

Pendant la démonstration, notez les étapes manuelles, les composants utilisés et les droits nécessaires. Demandez ce qui appartient au standard et ce qui a été préparé spécifiquement pour la séance. Vérifiez que la version présentée correspond à l’offre chiffrée. Si une fonction n’est pas montrée, classez-la comme point à confirmer. Un commentaire oral peut expliquer une possibilité sans prouver qu’elle sera livrée. Faites relire le compte rendu et demandez la correction des désaccords. Cette trace aide ensuite à construire le périmètre et les tests de recette.

Définir les critères de réussite

Pour chaque test, indiquez l’état initial, les actions, le résultat attendu et la personne qui valide. Ajoutez les contrôles de données et les permissions. Un critère doit être observable : document généré, montant rapproché, accès refusé ou journal disponible. Les formulations comme « simple » ou « performant » demandent une définition adaptée à votre contexte. Si un délai de traitement est important, convenez du jeu de données et des conditions de mesure. Ne fabriquez pas un seuil universel à partir d’une préférence personnelle ; le métier et l’équipe technique doivent l’accepter.

Classer les anomalies sans masquer les réserves

Distinguez blocage d’un processus indispensable, défaut contournable et amélioration demandée. Les catégories doivent être définies avant les discussions difficiles. Une réserve ne devient pas mineure uniquement parce que le calendrier est tendu. Attribuez chaque anomalie, fixez son traitement et prévoyez un nouveau test. Conservez le résultat initial et la preuve de correction. Si un contournement temporaire est accepté, décrivez sa charge et sa date de réexamen. La décision de lancement doit rendre visibles ces conditions plutôt que de présenter une validation globale sans réserve.

Relier recette et mise en service

La recette fonctionnelle ne couvre pas seule l’exploitation, les droits, les sauvegardes et le support. Préparez une liste de préparation opérationnelle avec contacts, procédures et responsabilités. Vérifiez que les utilisateurs savent obtenir de l’aide et que les données finales sont rapprochées. Un lancement peut être progressif si le processus le permet, mais il faut décrire les interfaces avec l’ancien système. Les conditions contractuelles liées à l’acceptation doivent être examinées avant signature. En cas d’enjeu important, faites-vous accompagner pour vérifier les conséquences d’une validation ou d’un silence.

Exemple de travail

Exemple de test illustratif : une commande partiellement livrée doit produire une facture limitée à la quantité livrée, conserver le reliquat et permettre un retour. Le jeu d’essai définit les quantités et les droits des participants. Le résultat attendu précise les documents, le stock et la trace de validation. Si la démonstration contourne le retour par une correction manuelle non prévue, notez cette limite. Lors de la recette, utilisez le scénario convenu dans l’environnement livré et conservez les résultats. Ce test ne constitue pas une règle comptable générale ; adaptez-le avec les personnes compétentes à votre activité.

Fiche de vérification

Élément	Question à documenter	Preuve ou responsable
Précondition	État du système	Données et droits
Action	Étape exécutée	Personne et méthode
Résultat	Comportement attendu	Preuve conservée
Réserve	Écart constaté	Responsable et nouveau test

À faire dans votre équipe

Demandez à un futur utilisateur de rejouer un scénario sans l’aide de la personne qui l’a préparé. Observez les consignes manquantes et les décisions implicites. Si deux personnes interprètent différemment le résultat attendu, clarifiez le test avant de l’utiliser pour accepter une livraison. Ajoutez ensuite un cas de droit insuffisant et un cas de donnée invalide. Ces exceptions montrent si le système protège réellement le processus. Rassemblez les résultats dans un registre unique avec version, environnement et date réelle d’exécution. La répétabilité du test est essentielle : un succès impossible à reproduire ne constitue pas une base solide pour lever une réserve.

Questions fréquentes

La démonstration vaut-elle recette ?

Non. Elle peut guider les exigences, mais la recette porte sur le périmètre et l’environnement livrés selon les modalités convenues.

Combien de scénarios faut-il écrire ?

Choisissez assez de parcours pour couvrir les processus indispensables et leurs exceptions importantes. La qualité des contrôles compte davantage qu’un nombre arbitraire.

Peut-on lancer avec des réserves ?

Cela dépend de leur effet et des conditions contractuelles. Une décision explicite doit décrire les risques acceptés, les contournements et le traitement attendu.

Pour poursuivre

Sources et portée

Microsoft — options de licence Business Central — référence officielle consultée le 30 octobre 2026.

Les démarches, tableaux et scénarios sont des propositions de méthode propres à ce guide. La référence officielle permet de vérifier les conditions ou notions mentionnées ; elle ne valide pas les hypothèses chiffrées illustratives et ne constitue pas un classement de produits.