Recette fonctionnelle d'un outil sur mesure : ce que vos équipes doivent valider avant la mise en production
Le prestataire vous envoie une notification : « l'outil est prêt, à vous de tester ». Deux semaines plus tard, la recette se termine avec quelques bugs cosmétiques remontés. Six mois après la mise en production, les équipes contournent l'outil sur les cas complexes. La recette fonctionnelle n'est pas une formalité de fin de projet.
Donatien Lefranc
Fondateur & Président, Leando
La recette à la va-vite : ce qui arrive quand on confond test technique et validation métier
La recette se passe bien. Quelques jours, quelques utilisateurs qui cliquent sur les écrans principaux, trois ou quatre bugs mineurs remontés, corrigés en vingt-quatre heures. Le prestataire obtient le bon de livraison. La mise en production est planifiée.
Deux semaines après la mise en production, la première anomalie sérieuse remonte. Un scénario de renouvellement de contrat que l'outil ne gère pas. Puis un cas de remise conditionnelle non prévu. Puis un bug de calcul sur les contrats signés avant une certaine date. Chaque cas force un aller-retour de développement. Trois mois après la mise en production, les équipes ont appris quels scénarios éviter dans l'outil. Elles font le reste manuellement.
Ce qui s'est passé : la recette a validé le scénario nominal, pas les cas d'usage réels. Les utilisateurs ont testé ce qu'ils savaient faire avec l'outil. Ils n'ont pas testé les vingt situations atypiques qui représentent trente pour cent de leur volume quotidien. Ces situations, personne ne les avait listées avant la recette. Leur absence a produit un outil fonctionnel sur le papier, incomplet sur le terrain.
Trois erreurs qui transforment la recette en formalité sans valeur
La première : confier la recette aux utilisateurs sans leur donner de scénarios préparés. Un utilisateur testera naturellement les fonctions qu'il connaît, dans les conditions les plus simples. Il ne testera pas les variantes qu'il rencontre deux fois par mois et qui exigent un traitement différent. Ce n'est pas un manque de rigueur : c'est la nature humaine. Les scénarios de recette doivent être préparés avant la phase de test, en listant explicitement les cas particuliers.
La deuxième : laisser le prestataire piloter la recette. Le prestataire sait ce qu'il a développé. Il a naturellement tendance à présenter l'outil sur les fonctions réussies. La recette doit être pilotée par l'équipe cliente, avec des scénarios définis indépendamment de ce que le prestataire a livré. Les questions à poser : « est-ce que ce scénario que je rencontre régulièrement fonctionne ? », pas « est-ce que les fonctions livrées marchent ? »
La troisième : ne pas avoir défini ce que « conforme » signifie avant la recette. Si les critères de validation ne sont pas écrits avant de commencer, la recette produit des remontées subjectives. Chacun a ses propres attentes, ses propres niveaux d'exigence. La confusion entre « je n'aime pas l'interface » et « ce scénario ne fonctionne pas » ralentit les échanges et dégrade la relation avec le prestataire.
« On a travaillé assez vite sur leurs objets métier, sur le modèle de données et sur les règles métier implicites de manière à comprendre vraiment les différents tenants et aboutissants d'un point de vue organisationnel, stratégique et technique. Une fois qu'on a une vision claire du processus cible, validée avec le métier, on peut aller tout droit sur les développements. »
Cette logique s'applique aussi à la recette : une fois que les scénarios sont cartographiés et validés avec le métier, la phase de test devient un exercice précis, pas une exploration à l'aveugle. Les scénarios non nominaux à cartographier avant la mise en production : les scénarios qui tuent un projet SI après la mise en production.
Comment construire des scénarios de recette efficaces
Un scénario de recette efficace décrit une situation que l'équipe rencontre dans son quotidien opérationnel, avec un attendu précis. Il ne décrit pas une fonctionnalité. Il décrit ce que l'utilisateur veut accomplir.
Exemple de scénario faible : « Créer un nouveau client dans l'outil. » Cela teste la fonctionnalité. Cela ne teste pas si l'outil gère correctement la situation métier.
Exemple de scénario fort : « Un client existant depuis 2021 me contacte pour modifier son adresse de livraison sur une commande en cours de traitement. Sa remise habituelle est conditionnée à un volume annuel qui n'est pas encore atteint cette année. Je dois pouvoir modifier l'adresse sans bloquer la remise en attente. » Ce scénario teste plusieurs règles métier en même temps, dans une séquence réelle.
Pour construire ces scénarios, trois sources sont à mobiliser. Les entretiens avec les équipes terrain, en leur demandant de raconter les cinq situations les plus compliquées qu'elles ont traitées dans le mois. Les cas d'erreurs passées, remontées par le service client ou le support interne. Et les exceptions connues mais non documentées, celles que tout le monde gère intuitivement sans que personne ne les ait jamais écrites.
Les conditions d'une mise en production réussie
La mise en production ne doit pas attendre la perfection. Elle doit attendre la conformité sur les cas nominaux et les cas les plus fréquents. Les anomalies cosmétiques et les améliorations de confort peuvent attendre la V1.1. Ce qui ne peut pas attendre : les scénarios qui, s'ils ne fonctionnent pas, forceront l'équipe à revenir au processus manuel. Valider ce critère précis est plus utile que d'obtenir un outil sans aucune anomalie.
La cohabitation pendant la transition mérite d'être pensée explicitement. Pendant combien de temps l'ancien processus reste-t-il disponible en parallèle du nouvel outil ? Quelle est la condition pour basculer définitivement ? Avoir un plan de réponse à ces deux questions réduit l'anxiété des équipes et facilite l'adoption. Lire aussi : pourquoi le cadrage précède la mise en production d'un back-office commercial.
La recette fonctionnelle bien menée ne garantit pas un outil parfait. Elle garantit que les équipes ont validé ce qui compte pour elles, que les anomalies identifiées sont classées, et que la mise en production part sur une base connue plutôt qu'une base espérée. Ce n'est pas un détail de fin de projet : c'est la condition pour que la mise en production produise un effet réel plutôt qu'une adoption forcée suivie d'un retour silencieux aux anciennes habitudes.
Pour mesurer l'impact dès le départ : pourquoi définir les métriques dès le jour 1 d'un projet digital.
C'est la phase durant laquelle les équipes métier vérifient que l'outil répond à leurs cas d'usage réels, en conditions proches du terrain. Ce ne sont pas les développeurs qui réalisent la recette : ce sont les futurs utilisateurs de l'outil, accompagnés idéalement par un référent projet côté client. Le prestataire est là pour corriger, pas pour tester à la place des équipes.
Votre recette fonctionnelle est-elle prête ?
Nous aidons les équipes à préparer leurs scénarios de recette et à définir les critères de conformité avant la mise en production. Un échange de deux heures suffit pour structurer la démarche.
Préparer ma recette