La recette fonctionnelle n’est pas la cérémonie qui clôt un projet ERP, CRM ou applicatif. C’est le moment où l’entreprise vérifie que l’outil permet réellement d’exécuter son activité, y compris lorsque les données sont imparfaites, qu’un utilisateur se trompe ou qu’une interface tombe en défaut. La signer sur la base d’une démonstration fluide revient à accepter un risque que le fournisseur a soigneusement évité de montrer.
La promesse qu’on entend partout : « une démo réussie suffit »
Le discours est séduisant : les développements sont terminés, les tests techniques sont au vert et le consultant maîtrise parfaitement le scénario présenté. Quelques utilisateurs assistent à une démonstration, vérifient les principaux écrans, puis le dirigeant signe le procès-verbal de recette afin de ne pas retarder le déploiement.
Dans cette vision, la recette est une formalité administrative. Le fournisseur a déjà testé la solution ; les métiers n’auraient plus qu’à confirmer qu’elle ressemble aux maquettes et que les boutons répondent.
Cette promesse repose sur une confusion entre trois opérations :
- La démonstration montre que le fournisseur sait exécuter un scénario préparé.
- Le test technique vérifie le comportement d’un composant, d’une interface ou d’une infrastructure.
- La recette fonctionnelle établit si les utilisateurs peuvent accomplir les opérations métier attendues dans les conditions prévues au contrat.
Une démonstration peut donc être impeccable alors que les droits d’accès sont incorrects, que les exports comptables sont incomplets ou qu’une commande partiellement livrée devient impossible à facturer.
Ce qui est vrai : les métiers doivent décider
Oui, les utilisateurs doivent participer à la recette. Un développeur peut confirmer qu’un calcul s’exécute conformément à une règle programmée ; seul le responsable métier peut déterminer si cette règle correspond à la manière dont l’entreprise accorde une remise, bloque une commande ou traite un litige.
Le référentiel consacré aux tests d’acceptation de l’ISTQB associe explicitement analystes métier, responsables de produit et testeurs à la définition des critères, à la conception des tests et à leur suivi. Il distingue notamment l’acceptation par les utilisateurs, l’acceptation contractuelle et l’acceptation réglementaire.
Mais faire participer les métiers ne signifie pas les installer devant le logiciel avec la consigne « essayez et dites-nous si cela fonctionne ». Il faut leur remettre :
- un parcours précis à exécuter ;
- des données de départ maîtrisées ;
- un résultat attendu vérifiable ;
- une règle de classement des anomalies ;
- une preuve à conserver pour chaque test.
Ces éléments doivent être préparés à partir des exigences du projet. Si elles restent ambiguës, la recette ne les corrigera pas : elle transformera chaque anomalie en débat d’interprétation. C’est pourquoi elle doit prolonger le travail réalisé lors du cadrage et de la rédaction du cahier des charges, et non tenter de le remplacer à la fin.
Ce qui est faux, ou seulement vrai sous conditions
« Si le scénario nominal fonctionne, l’outil est prêt »
Le scénario nominal est celui que tout le monde connaît : créer un client, saisir une commande, livrer, facturer et enregistrer le paiement. Il est nécessaire, mais il révèle rarement les difficultés les plus coûteuses.
La recette doit aussi couvrir les exceptions réelles : client en doublon, remise hors barème, livraison partielle, avoir, facture rejetée, article indisponible, utilisateur absent, données obligatoires manquantes ou synchronisation interrompue. Lorsqu’un CRM et un ERP échangent des informations, il faut vérifier non seulement que l’information part, mais aussi qu’elle arrive une seule fois, au bon endroit, avec un statut compréhensible. Notre guide sur l’intégration entre CRM et ERP détaille ce risque de continuité entre applications.
« L’absence de bug pendant la session prouve la qualité »
Non. Le syllabus Foundation Level de l’ISTQB rappelle qu’un test exhaustif est irréalisable, sauf cas trivial, et qu’une solution sans défaut détecté peut encore ne pas répondre au besoin réel. La bonne question n’est donc pas « avons-nous tout testé ? », mais « avons-nous testé en priorité ce qui peut arrêter, fausser ou désorganiser l’activité ? ».
Le niveau de test doit être proportionné au risque métier. Une couleur d’icône incorrecte et un calcul de taxe erroné ne peuvent pas recevoir la même priorité.
« Le fournisseur peut écrire et valider seul les tests »
Il peut préparer le référentiel, configurer les données et apporter des preuves techniques. Il ne doit pas être seul à décider qu’un résultat est acceptable.
La répartition raisonnable est la suivante :
| Objet contrôlé | Responsable de la validation | Preuve attendue |
|---|---|---|
| Parcours métier | Responsable du processus | Résultat obtenu comparé au résultat attendu |
| Droits et profils | Référent applicatif et métier | Matrice des accès effectivement vérifiée |
| Interfaces et données | Chef de projet | Rapprochement entre sources et destinations |
| Correction d’une anomalie | Utilisateur ayant constaté l’écart | Nouveau test et trace du résultat |
| Reprise ou retour arrière | Prestataire et responsable interne | Procédure exécutée dans l’environnement prévu |
« On utilisera une copie de la production, ce sera plus réaliste »
Seulement sous des conditions strictes. La CNIL demande d’utiliser des données fictives ou anonymisées pour les développements et les tests. Si des données réelles sont indispensables en préproduction, cet environnement doit être protégé au niveau requis et l’accès limité aux personnes habilitées. Copier librement des clients, salariés ou coordonnées bancaires dans un environnement de recette multiplie les accès et les lieux de stockage.
Ce que ça coûte quand on y va sans préparation
Le premier coût apparaît après le déploiement : les utilisateurs découvrent qu’une étape manque et créent un fichier parallèle. L’application reste officiellement la référence, mais la réalité opérationnelle se répartit entre l’ERP, des tableurs, des courriels et des vérifications manuelles.
Le deuxième coût est la dette technique. Pour corriger rapidement un défaut de conception, le fournisseur ajoute un paramètre spécifique, un script ou une règle exceptionnelle. Ces corrections rendent les évolutions suivantes plus difficiles à tester et augmentent la dépendance à ceux qui savent pourquoi elles ont été ajoutées.
Le troisième coût est contractuel. La portée exacte du PV dépend des clauses signées, mais il peut déclencher un paiement, ouvrir une période de garantie ou constater l’acceptation d’un périmètre. Signer avec une liste d’anomalies mal qualifiées affaiblit la capacité du dirigeant à distinguer une correction due d’une nouvelle demande facturable.
Enfin, une recette improvisée consomme le temps des collaborateurs sans produire de décision. Les mêmes anomalies sont signalées plusieurs fois, certaines disparaissent dans les courriels et personne ne sait quelle version a réellement été testée. C’est l’un des problèmes récurrents d’un projet IT piloté sans fonction de DSI clairement attribuée.
La façon raisonnable d’y aller
Figer la règle de décision avant d’ouvrir la recette
Le sponsor, le chef de projet et le responsable métier établissent une matrice d’acceptation avant la première session. Le livrable indique quels écarts bloquent la mise en production, lesquels autorisent une signature avec réserves et lesquels rejoignent le backlog d’évolution. La décision ne doit pas dépendre de la pression du calendrier le jour de la signature.
Tester des chaînes métier, pas une collection d’écrans
Chaque responsable de processus exécute le parcours depuis l’événement déclencheur jusqu’à son résultat comptable, commercial ou opérationnel. La fenêtre de recette couvre au moins un cycle métier complet pertinent pour l’application. Le livrable est un cahier de tests traçable reliant chaque scénario à une exigence, un résultat attendu et une preuve.
À titre d’illustration, la recette d’un processus de vente ne s’arrête pas à la création d’une commande. Elle suit aussi la modification, la livraison, la facturation, l’avoir éventuel et la transmission des écritures, avec des profils utilisateurs différents.
Préparer l’environnement, les accès et les données
Le responsable applicatif fournit, pendant toute la fenêtre de recette, une version identifiée, des comptes correspondant aux profils réels et un jeu de données fictives représentatif. Le livrable comprend la version testée, la matrice des habilitations et la description du jeu de données. Changer discrètement de version en cours de recette invalide les preuves déjà collectées.
Rejouer après chaque correction significative
Le prestataire corrige ; l’utilisateur ayant découvert l’anomalie rejoue le test ; le chef de projet déclenche les tests de non-régression sur les fonctions susceptibles d’avoir été affectées. Une anomalie n’est pas fermée parce qu’un développeur annonce qu’elle est résolue, mais lorsque le résultat attendu est reproduit et tracé.
Séparer aptitude fonctionnelle et service régulier
Une solution peut réussir les tests préparés puis se dégrader en usage courant. Sans appliquer mécaniquement les règles de la commande publique à un contrat privé, il est utile de reprendre la distinction du CCAG applicable aux techniques de l’information et de la communication entre vérification d’aptitude et vérification de service régulier. Ce référentiel public prévoit une observation du service sur trente jours ; votre contrat doit retenir une période cohérente avec le cycle métier et préciser les critères de disponibilité, de performance et de correction.
Notre position chez D1 Consulting
Nous refusons deux extrêmes : la recette symbolique organisée la veille du déploiement et l’usine à gaz documentaire qui cherche à tester chaque combinaison théorique. Une PME a besoin d’une recette proportionnée, orientée vers ses risques réels et reliée aux engagements de son contrat.
Notre offre de Direction de projet IT couvre le cadrage de la stratégie de recette, la construction des scénarios, l’organisation des utilisateurs, le suivi des anomalies, la préparation du PV et la conduite du passage en production. Nous pouvons intervenir comme direction de projet ou DSI partagée afin que le fournisseur ne soit pas à la fois celui qui livre, celui qui teste et celui qui prononce l’acceptation.
👉 Réservez un diagnostic gratuit de 30 minutes pour identifier vos parcours critiques, vos critères de signature et les angles morts de votre prochaine recette.
