La décision go/no-go : comment la préparer et qui décide

Ce que décide le go/no-go

Un go/no-go est le moment où le métier dit : cette version du CRM peut passer en production, à cette date. Ou bien : pas encore. Ce n'est pas une formalité à la fin du test. C'est la raison pour laquelle le test a été fait.

Un bon go/no-go comporte trois parties :

• Des faits. Ce qui a été testé, ce qui a réussi, ce qui est encore ouvert. Tirés des résultats de test, pas de la mémoire.
• Un jugement. Les responsables des processus disent s'ils peuvent faire leur travail avec cette version, et à quelles conditions.
• Une décision. Le comité de pilotage met en balance les faits et les jugements avec la date de mise en production, et décide.

La plupart des réunions go/no-go qui tournent mal manquent de la première partie. On se dispute sur la gravité d'une anomalie, ou sur le fait qu'un processus a été testé ou non, parce que personne n'a les chiffres. La suite de ce guide sert à garantir que les faits sont là avant le début de la réunion.

Critères de sortie : convenez-en avant la première journée de test

Les critères de sortie disent quand le test est assez bon pour passer en production. Convenez-en avec le comité de pilotage avant la première journée de test. À la fin, les émotions sont vives et les dates sont proches. C'est le mauvais moment pour décider de ce qui compte.

Des critères qui fonctionnent pour la plupart des mises en production CRM :

• Aucune anomalie Critical n'est ouverte.
• Chaque cas de test Must est réussi.
• Chaque anomalie High ouverte a un contournement ou une date de correction que le métier accepte.
• Chaque cas de test du périmètre a un résultat.
• Le responsable de chaque processus a validé.

Convenez du sens des mots

Les critères ne fonctionnent que si tout le monde utilise la même échelle. Écrivez ce que signifie chaque gravité, et partagez-le aussi bien avec les testeurs qu'avec le comité de pilotage :

Faites de même pour la priorité. Un cas de test marqué Must couvre ce qui doit fonctionner dès le premier jour, comme créer un devis ou router une requête. Si un cas de test Must échoue, la mise en production est menacée. Voir Rédiger des cas de test que les testeurs métier comprennent pour savoir comment fixer les priorités.

Écrivez ce qui n'est pas testé

Chaque UAT laisse quelque chose de côté : un pays qui passe en production plus tard, un rapport qui n'est pas prêt, une intégration testée seulement lors du test système. Mettez-le par écrit avant le test. Ainsi, personne ne pourra dire au go/no-go qu'il pensait que c'était couvert.

Qui décide

Deux groupes de personnes participent, avec des rôles différents.

Les responsables des processus valident

Pour chaque processus ou groupe du test, une personne du métier valide : le directeur commercial pour le lead-to-cash, le responsable du service client pour la gestion des requêtes, le responsable financier pour la facturation. Ils savent ce dont leurs équipes ont besoin, et ce sont eux qui vivront avec le résultat. Leur validation dit : mes équipes peuvent faire leur travail avec cette version.

Nommez-les au début du projet, pas la dernière semaine. Un responsable de processus qui découvre le test lors de la réunion go/no-go signera sans lire, ou demandera une semaine de plus.

Le comité de pilotage décide

Le comité de pilotage prend la décision pour toute la mise en production. Il réunit en général le sponsor côté métier, le chef de projet, un responsable de l'IT et, avec un intégrateur, quelqu'un du partenaire. Il met en balance ce qu'un seul responsable de processus ne voit pas : un contrat avec l'ancien CRM qui prend fin, un plan de formation, un week-end de migration, d'autres projets à la même date.

Le responsable des tests prépare, mais ne décide pas

Le responsable des tests apporte les faits et un avis. Il ne valide pas pour le métier et ne prend pas la décision. C'est en gardant ces rôles séparés que la décision tient quand quelque chose tourne mal après la mise en production.

Le rapport : ce qu'il contient

Le rapport go/no-go s'adresse à des personnes qui n'ont pas participé au test. Faites court : une page, avec le détail derrière pour ceux qui le veulent.

• Un avis. Go, go sous conditions ou no-go, avec les raisons en une ou deux lignes.
• Le périmètre. Quels processus et quelles user stories étaient dans le test, et ce qui n'a pas été testé.
• Ce qui a été testé. L'environnement, la release et le build. Un résultat appartient à une version du système.
• Les chiffres. Cas de test réussis, en échec, bloqués et non terminés.
• Par groupe ou processus. Les mêmes chiffres, avec la validation de chaque groupe.
• Par priorité. Combien de cas de test Must, Should et Could ont réussi, et quels cas de test Must n'ont pas réussi.
• Anomalies par gravité. Combien sont ouvertes, prêtes pour un nouveau test et clôturées, avec les anomalies Critical et High ouvertes nommément.
• Les validations. Qui a signé, quand, avec quelle décision et quelles conditions.
• Les risques connus. Les contournements que le métier utilisera les premières semaines, et qui les accompagne.

Envoyez le rapport la veille de la réunion. Ceux qui le lisent chez eux posent de meilleures questions.

Dans UAT StudioLe Go/no-go report du tableau de bord contient l'indication (GO, GO with conditions ou NO-GO, avec les raisons), les chiffres, l'avancement par jour, les résultats par groupe, par epic et par priorité, les anomalies par gravité, les anomalies Critical et High ouvertes nommément, et chaque validation du cycle. L'indication suit des règles fixes et n'est qu'un avis : c'est le comité de pilotage qui décide. Partagez-le en PDF ou téléchargez-le en slides pour la présentation du comité de pilotage.

Que faire des anomalies ouvertes

Il y a toujours des anomalies ouvertes à la fin d'une UAT. La question n'est pas de savoir s'il y en a, mais si chacune a une décision. Passez-les en revue avant la réunion, avec le métier et l'équipe de développement, comme lors du triage quotidien.

Reclassez avec prudence

Les derniers jours, on est tenté de faire passer une anomalie de Critical à High. C'est parfois justifié : un contournement apparaît, ou le processus s'avère rare. Faites-le ouvertement, en triage, avec le responsable du processus, et notez pourquoi. Ne le faites jamais discrètement pour embellir les chiffres. C'est ainsi qu'une mise en production échoue dès sa première semaine.

Les souhaits ne sont pas des défauts

Les testeurs trouvent des choses qu'ils aimeraient voir autrement. Si le système fonctionne comme prévu, c'est une demande d'évolution : elle va dans le backlog, pas dans cette release, et elle ne compte pas contre la mise en production.

Dans UAT StudioLe triage donne à chaque anomalie une gravité, une priorité, une personne assignée et une décision : Fix, Reject ou Change request. Avec le module AI test design, Summarize with AI dans l'onglet Issues rédige une courte synthèse des anomalies ouvertes pour la réunion go/no-go : regroupées par thème, avec ce qui bloque la mise en production. Sans le module, Summarize with your own AI fournit un prompt à coller dans l'IA de votre entreprise.

Un go sous conditions

Beaucoup de mises en production CRM obtiennent un go sous conditions. Le système est assez bon, à condition que quelque chose soit fait avant la mise en production ou juste après. C'est une décision légitime, tant que les conditions sont réelles.

Une bonne condition est :

• Concrète. L'approbation des remises pour les commandes de plus de 50 000 est corrigée et retestée, et non les approbations fonctionnent.
• Portée par quelqu'un. Une personne en est responsable, nommément.
• Datée. Avant la mise en production, ou une date dans les premières semaines qui suivent.
• Vérifiée. Quelqu'un confirme qu'elle a été remplie, et le comité de pilotage en est informé.

Surveillez le nombre de conditions. Deux ou trois, c'est normal. Quinze signifient que le test n'est pas terminé. Un go sous conditions n'est pas un moyen d'éviter un no-go.

Mise en production par étapes

Parfois, un processus n'est pas prêt alors que le reste l'est. Vous pouvez alors passer en production sans ce processus, ou avec un pays ou une équipe plus tard. Décidez-le explicitement, notez la nouvelle date de la partie qui attend, et prévoyez son propre cycle d'UAT et sa propre validation.

Validation par groupe

Demandez une validation par processus ou par groupe, pas une signature unique pour tout. Un directeur commercial ne peut pas juger la gestion des requêtes, et ne devrait pas avoir à le faire. Chaque responsable choisit l'une de trois réponses :

• Accepté : mes équipes peuvent faire leur travail avec cette version.
• Accepté sous conditions : à condition que les conditions soient remplies. Notez chacune d'elles, avec qui s'en charge et pour quand.
• Rejeté : pas assez bon pour passer en production. Demandez ce qui changerait la réponse.

Recueillez les validations avant la réunion, pour que le comité de pilotage décide sur la base d'une vue complète. Une validation appartient à une version : quand un nouveau build ou un nouveau cycle de tests suit, validez à nouveau.

Dans UAT StudioLa carte Sign-off du tableau de bord a une ligne pour l'ensemble du projet et une pour chaque groupe, avec Accepted, Accepted with conditions ou Rejected. La date, l'heure et le nombre d'anomalies Critical ouvertes sont enregistrés. Par défaut, personne ne peut accepter tant qu'une anomalie Critical est ouverte ; si No sign-off while Must test cases have not passed est coché, l'acceptation attend aussi que chaque cas de test Must ait réussi. Rejeter est toujours possible. Une validation appartient au cycle en cours.

Mener la réunion go/no-go

Planifiez la réunion en même temps que les journées de test, avec la date dans l'agenda du comité de pilotage. Prévoyez une heure. Un déroulé type :

1. Le responsable des tests présente le rapport : périmètre, chiffres, anomalies ouvertes, validations. Dix minutes, avec les chiffres à l'écran.
2. Chaque responsable de processus explique en une ou deux phrases pourquoi il a signé ainsi, et quelles sont ses conditions.
3. Questions sur les anomalies Critical et High ouvertes : y a-t-il une correction, un contournement, une date ?
4. Questions hors du test : formation, migration des données, support les premières semaines, plan de retour arrière.
5. La décision : go, go sous conditions ou no-go. Lisez-la à voix haute, avec les conditions, les responsables et les dates.

Si la décision est no-go, terminez par un plan : ce qui doit changer, un nouveau cycle de tests et une date pour le prochain go/no-go. Un no-go avec un plan est une décision de projet normale. Un no-go sans plan ressemble à un échec.

Le registre des décisions

Consignez la décision le jour même. Des mois plus tard, après un incident ou lors d'un audit, quelqu'un demandera qui a décidé de passer en production avec cette anomalie ouverte. La réponse doit se trouver en une minute.

Un registre des décisions contient, pour chaque go/no-go :

• La date, et qui était présent à la réunion.
• La décision : go, go sous conditions ou no-go.
• Chaque condition, avec son responsable, sa date et, plus tard, la date à laquelle elle a été remplie.
• Les anomalies ouvertes que le métier a acceptées, avec la raison.
• Le rapport sur lequel la décision s'est fondée, tel qu'il était à ce moment-là.

Conservez-le avec les documents du projet, et suivez les conditions les premières semaines après la mise en production, jusqu'à ce que chacune soit remplie.

Dans UAT StudioSave snapshot sur le rapport go/no-go conserve le rapport tel qu'il était au moment de la décision ; il ne change plus, et Show le rouvre plus tard. Chaque validation reste dans l'historique, y compris celles qui ont été remplacées ou retirées. Pour un auditeur, les administrateurs téléchargent l'Evidence pack : le rapport, les cas de test, les résultats et les anomalies, l'historique de chaque anomalie, chaque validation et le journal d'audit, avec une somme de contrôle pour chaque fichier.

Libre d'utilisation

Les critères de sortie, la validation et le rapport figurent aussi dans la checklist UAT pour une mise en production CRM, en fichier Excel gratuit. Pour l'ensemble du test, voir les guides d'une UAT Salesforce et d'une UAT Dynamics 365.