Check-list de déploiement (check-list de mise en service)
Écrivez ce qui doit être vrai avant la mise en service, exigez la preuve que chaque point est fait et suspendez le lancement si un point critique échoue.
- Durée
- 45 min
- Participants
- 4–6
- Type de travail
- Planifier · Déployer
En bref
Une check-list de déploiement est une liste de conditions de préparation opérationnelle qu'un nouveau service ou un changement doit remplir avant sa mise en service. Chaque condition a un responsable, une échéance, un statut et, surtout, la preuve qu'elle est remplie. L'équipe convient à l'avance des points critiques et suspend le déploiement si l'un d'eux échoue.
De quoi s'agit-il
La plupart des problèmes de lancement ne sont pas des surprises. Quelqu'un savait que le service d'assistance n'avait pas été briefé, ou qu'un moyen de paiement n'avait pas été essayé, mais ce n'était écrit nulle part où les décideurs regardaient. Une check-list de déploiement rassemble ces conditions en un seul endroit avant le lancement, pour que la décision go ou no-go repose sur des faits plutôt que sur l'optimisme.
Ce qui en fait plus qu'une liste de tâches, c'est la colonne Preuve. « Fait » ne suffit pas. Chaque point demande une courte note de preuve : un relevé de test, un formulaire signé, une capture d'écran, une feuille de présence à un briefing. La check-list signale aussi certains points comme critiques. Si un point critique échoue, le déploiement attend, quelle que soit la pression pour tenir la date.
Quand l'utiliser
À utiliser quand
- Un service nouveau ou modifié est sur le point d'arriver devant le public ou un large groupe d'agents.
- Plusieurs équipes doivent être prêtes en même temps pour que le lancement fonctionne.
- Un lancement précédent a mal tourné parce qu'une chose que tout le monde croyait prête ne l'était pas.
- La direction a besoin d'une base claire et étayée pour décider go ou no-go.
À éviter quand
- Le travail est encore en conception ou en test ; une check-list si tôt devient une liste de souhaits.
- Le changement est mineur et facile à annuler, comme le texte d'une page ; une relecture rapide par un collègue suffit.
- Vous voulez un long modèle générique ; le copier sans réfléchir à votre service fera passer à côté de l'essentiel.
Ce qu'il vous faut
- Durée
- Environ 45 minutes pour construire la première version, puis un court point chaque semaine avant le lancement.
- Participants
- Quatre à six personnes : le responsable du service et un référent de chaque équipe qui doit être prête, comme la technique, les opérations, le support client et la communication.
- Matériel
- La fiche de travail avec Point de contrôle, Preuve, Responsable, Échéance et Statut ; la feuille de route ou le plan de lancement ; les résultats des tests précédents ou d'un premortem.
Comment la mener
Étape 1: Recueillir les conditions de préparation par domaine
Demandez à chaque référent de lister ce qui doit être vrai dans son domaine avant le lancement : systèmes, personnes, processus, communication, support et retour arrière. Écrivez chaque condition comme un état atteint, par exemple « Les trois types de carte permettent de payer sur le système en production ».
Étape 2: Ajouter des conditions tirées des échecs passés
Regardez ce qui a mal tourné lors des lancements précédents et dans votre premortem, si vous en avez fait un. Ajoutez une condition pour chaque risque sérieux. Ce sont souvent les points les plus précieux de la liste.
Étape 3: Signaler les points critiques
Convenez des conditions qui bloqueraient le lancement si elles échouaient : tout ce qui pourrait nuire aux usagers, faire perdre de l'argent ou des données, ou rendre le service inutilisable. Gardez la liste des critiques courte et claire. Le reste peut être corrigé peu après le lancement si nécessaire.
Étape 4: Définir la preuve de chaque point
Pour chaque condition, écrivez ce qui vaut preuve qu'elle est remplie : un journal de test, une validation signée, une feuille de présence à la formation, une transaction de test réelle. Si aucune preuve n'est possible, reformulez la condition jusqu'à ce qu'elle soit vérifiable.
Étape 5: Désigner un responsable et une échéance
Nommez un rôle responsable de chaque point et une date à laquelle il doit être rempli, en gardant une marge avant le lancement. Le responsable rassemble la preuve et met à jour le statut.
Étape 6: Revoir les statuts chaque semaine
Réunissez-vous brièvement chaque semaine pour parcourir la liste. Le statut est l'un des suivants : non commencé, en cours, rempli avec preuve, ou échoué. Concentrez l'échange sur les points critiques et sur ce qui est en retard.
Étape 7: Prendre la décision go ou no-go
À un moment convenu avant le lancement, vérifiez chaque point critique. S'ils sont tous remplis avec preuve, c'est go. Si un point critique a échoué, suspendez le déploiement, corrigez et fixez une nouvelle date. Consignez la décision et qui l'a prise.
Exemple concret
Un assureur automobile faisait passer les renouvellements de contrats par un nouvel écran de paiement en ligne. Un changement similaire, deux ans plus tôt, avait échoué le jour du lancement parce qu'un type de carte était refusé, laissant de nombreux renouvellements impayés. L'équipe a construit une check-list de déploiement six semaines avant le nouveau lancement.
Les référents de la technique, des opérations, du centre de contact et de la communication ont listé 28 conditions de préparation. Sept étaient critiques, dont « Les trois types de carte acceptés permettent de régler un renouvellement réel » et « Retour à l'ancienne page de paiement testé de bout en bout ».
Pour la condition sur les cartes, la preuve était un relevé de test d'un vrai renouvellement avec chaque type de carte sur le système en production, références à l'appui. Deux types de carte sont passés en semaine quatre. Le troisième a échoué à cause d'un paramétrage chez le prestataire de paiement.
À la réunion go ou no-go, une semaine avant le lancement, ce point critique était toujours en échec. Le responsable du service a suspendu le déploiement neuf jours le temps de corriger et retester le paramétrage, et la responsable de la communication a ajusté les messages aux clients.
Le lancement reporté s'est fait avec tous les points critiques remplis. Les appels pour problèmes de paiement le premier mois ont été bien inférieurs au niveau observé après le changement précédent.
À titre illustratifConseils et erreurs
Conseils
- Limitez les points critiques à un nombre que l'on peut garder en tête, souvent entre cinq et dix.
- Exigez une preuve qu'un observateur extérieur sceptique accepterait, pas un « oui, c'est bon » à l'oral.
- Prévoyez un moyen testé de revenir en arrière, pour qu'un lancement raté puisse être annulé vite.
- Mettez sur la liste le briefing des agents de terrain et la communication au public ; ils font partie de la préparation autant que les systèmes.
- Gardez la check-list après le lancement et servez-vous-en comme point de départ pour le suivant.
Erreurs fréquentes
- Cocher des points comme faits sans preuve, si bien que la liste rassure à tort.
- Rendre tous les points critiques, ce qui veut dire que le lancement ne peut jamais avoir lieu ou que la règle est discrètement ignorée.
- Construire la check-list la semaine du lancement, quand il ne reste plus de temps pour corriger ce qu'elle révèle.
- Lancer malgré un point critique en échec parce que la date a été annoncée.
Ce que vous obtenez
Vous repartez avec une liste partagée de ce qui doit être vrai avant le lancement, la preuve que chaque point est rempli, le rôle qui en est responsable et une règle claire pour suspendre le déploiement. La direction dispose ainsi d'une base équitable pour décider go ou no-go, et les usagers sont protégés d'échecs évitables. Reliez la check-list aux jalons de votre feuille de route et intégrez les dates de votre plan de communication avec les parties prenantes pour que chacun apprenne le changement au bon moment. Si vous n'avez pas encore imaginé comment le lancement pourrait échouer, faites d'abord un premortem.
Questions fréquentes
Que doit contenir une check-list de déploiement ?
Des conditions issues de chaque domaine qui doit être prêt : systèmes et données, personnes et formation, processus, support client, communication et un moyen testé de revenir en arrière. Ajoutez des points tirés de ce qui a mal tourné lors des lancements passés. Chaque point a besoin d'un responsable, d'une échéance et d'une preuve.
Qu'est-ce qu'une décision go ou no-go ?
C'est un moment convenu avant le lancement où le décideur vérifie les points critiques de la check-list. S'ils sont tous remplis avec preuve, le lancement a lieu. Si l'un d'eux a échoué, le lancement est suspendu jusqu'à correction. Convenez de qui décide avant le jour J.
Quelle différence entre une check-list de déploiement et un plan de projet ?
Un plan de projet décrit le travail à faire et quand. Une check-list de déploiement décrit les conditions qui doivent être vraies au terme de ce travail, preuves à l'appui. C'est une vérification finale que le plan a livré ce dont le lancement a besoin.
Fiche de l'outil
La fiche de travail que remplit votre équipe, une case par rubrique.
- Point de contrôle
- Preuve
- Responsable
- Échéance
- Statut