Une présentation de préparation à la mise en production doit permettre à la personne habilitée à l’autoriser de répondre à trois questions : que veut-on déployer exactement, quels éléments justifient ce changement et que se passe-t-il en cas d’échec ? Commencez par la décision demandée, placez les conditions non résolues à côté des résultats et terminez par un relevé précisant qui a autorisé quoi. Une rangée de voyants verts ne suffit pas.
Préparez d’abord les notes de version vérifiées. Vous pouvez ensuite utiliser Presenti pour transformer ce texte en brouillon de présentation modifiable, en conservant les références et conditions d’autorisation dans les diapositives. L’exemple suit un service fictif de réservation de rendez-vous lors d’une réunion Go/No-Go. Les dossiers, horaires et seuils sont pédagogiques ; ils ne proviennent pas d’un déploiement réel.
Nommez la version et la décision avant de montrer l’avancement
L’équipe souhaite publier la version 2.4, qui modifie la réservation et l’annulation des créneaux. Les tarifs, la migration des comptes et l’application mobile n’en font pas partie. Le candidat examiné est le build 2.4-rc3, avec la configuration C17 et une nouvelle migration de base de données. La première exposition proposée concerne dix comptes de test internes ; l’accès des clients fera l’objet d’une décision distincte.
Au moment de la revue, les tests de réservation ont réussi. Les retards de notification sont encore à l’étude. Une répétition du retour arrière portait sur le candidat précédent, pas sur rc3 et sa migration. La première diapositive devrait donc annoncer :
Recommandation : suspendre le pilote rc3. Le comportement de réservation dispose de résultats de test, mais la récupération avec ce candidat n’a pas été démontrée. Satisfaire cette condition et caractériser le retard de notification avant de demander l’autorisation du pilote.
Cette ouverture est plus utile que « La version 2.4 est prête à 95 % ». Un pourcentage réunit des éléments dont les conséquences diffèrent. Plusieurs tâches documentaires achevées ne compensent pas l’absence d’un résultat de récupération.
Indiquez le build, la configuration, l’heure de revue et l’exposition demandée sur cette première diapositive. Si un build ou une configuration change pendant la réunion, le groupe doit savoir quels résultats restent applicables. Ne transférez pas discrètement l’approbation d’un ancien candidat à un nouvel artefact.
Montrez ce que chaque résultat permet réellement d’affirmer
Utilisez une courte synthèse des éléments disponibles et gardez les dossiers détaillés séparément. Chaque ligne doit relier une affirmation à son périmètre et à sa lacune restante. « Tests réussis » est trop large si les essais ne couvrent que les comptes internes ou un seul parcours de paiement.
| Domaine | Éléments dans cette revue fictive | Conséquence pour la décision |
|---|---|---|
| Réservation | QA-42 consigne les tests de création, d’annulation et de réservations simultanées sur rc3/C17 en préproduction. | Étaye ces parcours testés, sans établir le comportement sous toutes les charges client. |
| Notifications | MAIL-9 relève des confirmations retardées pendant un test de nouvelles tentatives ; le retard maximal et sa cause restent inconnus. | Garder l’exception visible. Ne pas déclarer les notifications prêtes ni supposer le retard sans conséquence. |
| Récupération | RB-14 concernait le candidat précédent. Aucun compte rendu ne couvre rc3 avec sa migration. | La condition de récupération convenue n’est pas remplie ; le report reste recommandé. |
| Couverture de l’assistance | OPS-6 nomme un intervenant principal, un suppléant, le créneau du pilote et le circuit d’escalade. | La couverture existe pour ce créneau, pas indéfiniment ni pour un lancement élargi. |
QA-42 et les autres identifiants sont des exemples. Dans votre diaporama, les références équivalentes doivent mener aux résultats réels, avec l’environnement, le candidat et l’heure. Gardez les données personnelles et les informations opérationnelles sensibles dans des dossiers dont l’accès est correctement restreint, plutôt que de les copier dans une présentation largement diffusée.
Le chapitre de Google sur les lancements fiables insiste sur des vérifications concrètes, pratiques et adaptées au service. Sa liste historique de préparation au lancement traite notamment du comportement en cas de panne, de la surveillance, de la récupération et du déploiement progressif. Utilisez ces points comme des questions à adapter, pas comme une norme universelle d’approbation ni comme la preuve que votre service les satisfait.
Distinguez un blocage d’une exception acceptée
Avant la réunion, convenez des conditions qui imposent un report et de celles qui peuvent être examinées pour une autorisation expressément limitée. Sinon, le statut « orange » devient une négociation sur une couleur plutôt qu’une décision sur l’exposition.
Dans cet exemple, l’équipe a convenu que le parcours de récupération du candidat devait être démontré avant tout déploiement pilote. L’absence de répétition pour rc3 constitue donc un blocage. La personne qui préside ne peut pas en faire une exception acceptée simplement en remplaçant les clients par dix salariés.
Le retard des e-mails pose une autre question. Un pilote très limité pourrait-il avancer avec cette restriction ? Le groupe devrait d’abord connaître le retard observé, la justesse de l’état des réservations, ce que verront les participants et la personne autorisée à arrêter le pilote. « Nous avons un contournement » ne répond pas à ces questions.
Pour chaque exception proposée, rédigez une fiche courte : limitation ; utilisateurs concernés ; éléments disponibles ; mesure temporaire ; rôle responsable ; échéance ou point de réexamen. Sans public défini ni terme, l’exception modifie la promesse de la version pour une durée indéterminée.
Distinguez trois issues. Go autorise le périmètre annoncé dans les conditions convenues. Go restreint autorise une exposition plus réduite et précisément décrite. No-Go laisse le changement proposé sans autorisation jusqu’au réexamen des éléments et de la décision. Aucune de ces étiquettes ne donne au présentateur une autorité qu’il ne possède pas déjà.
Dessinez un parcours de déploiement avec une possibilité de retour
Une frise qui s’arrête à « déployer » masque le travail dont dépend l’autorisation. Dessinez une courte séquence avec une décision ou une condition d’arrêt entre les étapes :
- Avant toute exposition : terminer la répétition de récupération rc3, caractériser MAIL-9 et joindre les dossiers à la nouvelle revue.
- Autorisation : l’autorité de mise en production désignée décide si ce candidat précis peut entrer dans le pilote de dix comptes.
- Observation limitée : des intervenants nommés suivent la justesse des réservations, les notifications et les signaux de surveillance convenus pendant le créneau.
- Décision suivante : maintenir la limitation, arrêter et récupérer, ou demander une exposition plus large. La première approbation n’autorise pas automatiquement la dernière option.
À titre d’illustration, supposons qu’une revue ultérieure décide d’arrêter le pilote en cas de double réservation confirmée, de confirmation retardée de plus de cinq minutes ou de perte de la surveillance nécessaire à l’observation de ces deux conditions. Ces limites sont propres à l’exemple, pas des valeurs par défaut recommandées. Une fenêtre d’observation de trente minutes pourrait faire partie du pilote limité ; elle ne démontrerait pas la fiabilité à plus grande échelle.
Placez l’autorité d’arrêt à côté de la condition d’arrêt. Dans l’exemple, le responsable d’astreinte peut interrompre le pilote, tandis que l’autorité de mise en production décide de sa reprise. Reliez le parcours de récupération au mode opératoire approuvé ; n’essayez pas de transformer le diaporama en instructions de déploiement exécutables.
Pour la migration, demandez ce que signifie « revenir en arrière ». L’ancienne application peut-elle lire les données écrites par la nouvelle ? La récupération exige-t-elle un rapprochement des rendez-vous créés pendant le pilote ? Montrez la réponse connue ou le résultat manquant. Changer de version applicative ne prouve pas, à lui seul, que les données sont redevenues exploitables.
Organisez la revue en six diapositives centrées sur la décision
Un court diaporama peut suivre la décision sans répéter le compte rendu hebdomadaire de chaque équipe :
- « Suspendre le pilote rc3 jusqu’à démonstration de la récupération. » Nommer le candidat, le périmètre, la recommandation et le rôle approbateur.
- « Les tests étayent les parcours vérifiés ; deux conditions restent ouvertes. » Présenter les éléments et leurs limites.
- « Le résultat du retour arrière précédent ne couvre pas cette migration. » Expliquer le blocage et le résultat exact attendu.
- « La première autorisation ne couvrirait que dix comptes. » Montrer les étapes, la fenêtre d’observation et l’autorité d’arrêt.
- « L’assistance est mobilisée pour le créneau proposé. » Nommer les rôles, les suppléants et le relais après ce créneau.
- « Consigner la décision et les conditions d’une nouvelle revue. » Terminer la réunion avec une décision clairement consignée.
La première diapositive porte la recommandation ; la dernière consigne la décision réelle. Elles peuvent différer. Si le groupe change le périmètre demandé, enregistrez cette modification plutôt que de réécrire ensuite la première diapositive et de perdre l’historique de ce qui a été examiné.
Pour préparer le brouillon, collez les six titres avec leurs éléments vérifiés. Une consigne utile est : « Conserve rc3/C17 sans modification. Garde la recommandation de report et la condition de récupération non résolue. Sépare éléments disponibles, étapes futures proposées et autorisation. N’invente aucun résultat de test, nom d’approbateur, date de déploiement ou gain de performance. » Vérifiez les formulations avant la mise en page finale : une présentation soignée ne doit pas transformer une étape proposée en étape approuvée.
Terminez avec un relevé de décision rempli
Voici le relevé de la réunion fictive. Il est assez court pour être lu avant le départ des participants :
Décision : No-Go pour le pilote rc3/C17 proposé sur dix comptes, consigné lors de la revue de 14:00. Aucune exposition client n’est autorisée.
Motif : Les éléments de récupération ne couvrent pas la migration du candidat. Le retard de notification n’est pas encore caractérisé.
Prochains éléments : Le responsable technique fournit le résultat de récupération propre au candidat, y compris le traitement des rendez-vous nouvellement créés. Le responsable des notifications fournit l’analyse du retard et la limitation proposée pour le pilote.
Responsable de la décision : L’autorité de mise en production désignée convoque une nouvelle réunion de revue lorsque ces dossiers sont disponibles. Le point suggéré à 16:00 sert à faire état de l’avancement, pas à autoriser un déploiement à 16:00.
Périmètre inchangé : Déploiement client, application mobile, tarifs et migration des comptes restent en dehors de cette décision.
Envoyez ce relevé avec les diapositives et les références. Si la réunion suivante aboutit à une autre décision, ajoutez une entrée pour le candidat et les conditions examinés à ce moment-là. La présentation a rempli son rôle lorsqu’une personne absente peut savoir ce qui a été autorisé, ce qui ne l’a pas été et ce qui doit se passer ensuite.
