La recette n’est pas le dernier rapport de l’intégrateur : c’est la décision du sponsor. Elle répond à une question que personne ne peut trancher à sa place : le métier peut-il travailler avec ce qui a été livré, sur ses cas réels, avec ses droits et ses données ? Les tests de l’intégrateur prouvent que l’outil fait ce que la spécification décrit. La recette dit si cela suffit pour lancer. Les scénarios viennent donc du métier, les critères et l’échelle de gravité se fixent avant le premier test, et le sponsor signe ce qu’il a vu passer, pas ce qu’on lui rapporte.
Prenez une demande de remise au-delà du seuil autorisé. L’intégrateur montre que la règle d’approbation se déclenche, que le statut change et que la notification part : son test est vert, et il a raison. La recette pose d’autres questions. Un commercial, connecté avec son propre profil et non avec un compte administrateur, peut-il soumettre la demande depuis l’opportunité ? Le suppléant la voit-il quand le responsable est absent ? Le contrôle de gestion retrouve-t-il le motif de la remise dans son rapport de fin de mois ? Chacune de ces questions peut échouer alors que tous les tests de l’intégrateur passent.
À quoi sert la recette, si l’intégrateur a déjà testé ?
Les deux campagnes ne répondent pas à la même question. L’intégrateur vérifie sa livraison : chaque règle, chaque champ et chaque automatisation fait ce que la spécification demande, les intégrations échangent les bons messages, les correctifs ne cassent pas ce qui marchait. C’est nécessaire, et c’est son travail. Mais ces tests partent de la spécification. Si elle a oublié un cas, les tests l’oublient aussi, et ils passent.
La recette part de l’autre bout : le travail réel. Elle ne demande pas si la règle fonctionne, mais si l’équipe peut faire sa journée. Elle teste les enchaînements d’une étape à l’autre, les exceptions, les droits d’accès vus par chaque population, les rapports dont dépend une décision. C’est le seul moment où le métier confronte l’outil à son propre travail avant que ce travail en dépende.
Il y a aussi une raison plus simple. L’intégrateur est payé pour livrer. Son rapport de tests est une pièce utile, souvent soignée, mais c’est la pièce d’une partie intéressée. Lui demander de prononcer la recette revient à lui faire noter sa propre copie. Le sponsor lit ce rapport comme une condition pour entrer en recette.
Qui écrit et qui joue les scénarios ?
Le métier, dans les deux cas. Les utilisateurs clés de chaque équipe écrivent les scénarios à partir de leurs processus : un scénario par parcours complet, du premier contact à la facture, de la requête ouverte à la requête close, avec les cas qui fâchent (le client en double, la commande annulée après validation, le responsable absent, la fiche reprise de l’ancien système). Chaque scénario porte son résultat attendu, écrit avant l’exécution, et le nom de la personne qui le joue.
Ils les jouent eux-mêmes, avec les profils et les ensembles d’autorisations des vrais utilisateurs, dans une sandbox chargée de données représentatives. Un scénario joué avec un compte administrateur ne prouve rien sur les droits. Un scénario joué sur quelques fiches de test ne prouve rien sur la qualité des données reprises : la recette s’appuie sur les répétitions de la migration de données.
L’intégrateur a un autre rôle. Il prépare l’environnement, crée les comptes, charge les données, débloque les testeurs quand l’outil les arrête, analyse les anomalies et livre les correctifs. Il relit les scénarios pour signaler ce qui sort du périmètre contractuel. Il ne les écrit pas et ne les joue pas. Le piège courant est une offre de bonne volonté : « les cas de test existent déjà, vos équipes n’ont qu’à les rejouer ». Ces cas ont été écrits par ceux qui ont construit l’outil. Ils passent par construction, et le cas oublié arrive en production.
Cela suppose des utilisateurs clés disponibles et formés avant que la recette commence. Un testeur qui découvre l’écran ne distingue pas une anomalie d’une erreur de manipulation. Le plan de formation se cale donc sur le calendrier de recette, et le temps des testeurs se réserve auprès de leurs managers dès le cadrage.
Que faut-il fixer avant le premier test ?
Les critères et l’échelle de gravité se signent avant que la première anomalie existe.
Les critères d’entrée d’abord : environnement figé, données chargées, comptes créés avec les bons droits, rapport de tests de l’intégrateur remis, testeurs formés. Si l’un manque, la recette ne commence pas. Une recette lancée sur un environnement qui bouge encore ne mesure que les livraisons de la veille.
L’échelle de gravité ensuite, avec une définition par niveau et un exemple tiré des processus du métier. Bloquant : le processus s’arrête et aucun contournement acceptable n’existe. Majeur : un contournement existe, mais il coûte du temps, crée un risque ou repose sur une seule personne. Mineur : une gêne sans effet sur le résultat. Cosmétique : un libellé, une mise en page. Le métier qualifie la gravité selon cette grille, l’intégrateur donne son avis technique, et un désaccord remonte au sponsor au lieu de se négocier ticket par ticket.
Les critères de sortie enfin : tous les scénarios critiques passés, aucun bloquant ouvert, chaque majeur ouvert accompagné d’un contournement écrit, d’un responsable et d’une date, et la liste des mineurs reportés acceptée par le métier.
Pourquoi avant ? Parce qu’une fois les tests lancés, chaque gravité devient une négociation. Quand un paiement ou la date de lancement dépend du nombre de bloquants, chaque bloquant a intérêt à devenir majeur. Une grille signée à froid tranche ces débats avant qu’ils commencent. Elle doit dire la même chose que le contrat : la recette, son contenu et ses effets se règlent avant de choisir l’intégrateur, et une grille qui contredit le contrat ne tient pas au premier désaccord.
Que signe le sponsor, et que ne signe-t-il jamais sur parole ?
Le sponsor signe un procès-verbal de recette, et ce document dit des choses précises : le périmètre testé et la version livrée, les scénarios joués et leur résultat, les anomalies ouvertes avec leur gravité, leur responsable et leur date, les réserves, la décision. Il accepte, accepte avec réserves ou refuse. Accepter avec réserves est une décision complète : chaque réserve a un responsable, une date, et une conséquence écrite si la date n’est pas tenue.
Il signe ce qu’il a vu : il assiste au passage des scénarios critiques, ceux sans lesquels l’entreprise ne lancerait pas, et lit les résultats scénario par scénario plutôt qu’un pourcentage de réussite. Un taux élevé peut cacher le seul échec qui compte.
Il ne signe jamais sur la parole d’un autre. « Tous les tests sont verts », quand ce sont ceux de l’intégrateur. « Les anomalies restantes sont mineures », sans la liste ni l’avis du métier. « On corrigera après le lancement », sans responsable ni date. Un périmètre réduit en cours de route sans que la réduction figure au procès-verbal. Une fonction annoncée pour le lot suivant ne pèse rien dans la décision : le sponsor signe ce qui tourne dans la sandbox.
Avant de signer, il demande par écrit ce que la signature déclenche au contrat : un jalon de paiement, le début d’une garantie, la fin de la présence de l’intégrateur sur le projet. Une signature qui libère un paiement et fait courir la garantie ne se donne pas pour tenir un planning.
Que faire quand la recette ne passe pas ?
Refuser fait partie des issues prévues : la recette fait son travail. La suite se décide par écrit : reporter le lancement à une date liée à la correction des bloquants et non à l’agenda de l’intégrateur ; réduire le périmètre du lancement en retirant le processus en échec, avec son propre calendrier de recette ; ou accepter avec réserves, si les seuls écarts restants sont des majeurs avec contournement.
Ce que le sponsor s’interdit : lancer quand même en comptant sur la garantie pour absorber les bloquants. Un correctif en production se fait sous la pression des utilisateurs, sans le filet de la sandbox, et les premières semaines décident de ce que les équipes penseront de l’outil.
Un nouveau cycle de recette rejoue les scénarios touchés par les correctifs, puis les scénarios critiques en entier. Un correctif qui répare une étape en casse parfois une autre, et seul un scénario de bout en bout le montre.