Préparations du jour du lancement (Commerce de détail)

Un lancement se déroule plus facilement si toutes les parties prenantes sont informées du lancement imminent et comprennent le plan de lancement ainsi que leur rôle et leurs responsabilités. Outre la notification des équipes qui seront activement impliquées, il peut être utile de notifier les équipes susceptibles d’être sollicitées en cas de problème. Le fait d’avoir quelqu’un en attente pendant le lancement peut aider à accélérer la réponse. Veillez à identifier et à prévenir toute équipe susceptible de devoir répondre aux questions des clients, y compris sur les médias sociaux.

• Clients

• Partenaires commerciaux, le cas échéant

• Équipe(s) chargée(s) de l’application concernée(s) par le lancement

• Équipes d’assistance

• Équipes réseau (changements dans le réseau, en attente, en cas de problèmes)

• Équipes de sécurité (en attente, en cas de problèmes)

• Équipes marketing (prêtes pour les annonces, réponse aux problèmes)

• Équipes des médias sociaux (prêtes à surveiller les médias sociaux, à réagir)

• Équipes de vente (prêtes à répondre aux questions des clients)

• Équipes chargées de la réussite des clients (prêtes à répondre aux questions des clients)

Votre plan de notification doit inclure des éléments tels que l'audience cible, les principaux enseignements pour l'audience, le contenu du message, les plans de distribution de la notification et la manière de tester le message.

Voici une liste d’éléments à inclure dans le plan :

• Audience cible (considérer les audiences internes et externes)

• Message

• Le moment choisi

• Dépendances

• Parties responsables (qui l’enverra)

• Mécanisme (comment il sera communiqué)

• Test du message et de la livraison (le cas échéant - test pour s’assurer que les notifications ont été envoyées)

Une tactique courante consiste à diffuser les notifications par lots afin de répartir la charge initiale et de réduire le risque de confusion en cas de problèmes imprévus. Il est plus facile de corriger les problèmes au sein d’un petit groupe que lors d’un lancement massif.

• Une approche consiste à commencer par un lot relativement petit de notifications et, si aucun problème n’est identifié, à augmenter la taille des lots au fil du temps.

• Vous pouvez également envoyer des lots selon un calendrier qui tient compte des fuseaux horaires dans le monde entier pour répartir la charge qui frappe le système en une seule fois et faire en sorte que les notifications arrivent à un moment optimal dans chaque fuseau horaire afin d’augmenter la probabilité que les messages soient lus.

• Vous pouvez procéder à un lancement en douceur pour une partie des utilisateurs, par exemple des clients individuels, des régions ou tout autre groupe pertinent pour votre application.

Certaines organisations imposent une demande formelle de fenêtre d’interruption si des interruptions de service ou des temps d’arrêt sont nécessaires pour un lancement. Si votre organisation l’impose, veillez à déterminer si des temps d’arrêt sont nécessaires pour le basculement ou le lancement (ou d’autres systèmes dépendants) et déposez les demandes d’arrêt ou de modification nécessaires avant que les délais ne soient respectés.

Certains lancements impliquent le passage d’une solution précédente à une nouvelle solution. Si votre projet correspond à ce scénario, vous devez vous assurer d’identifier tout ce qui doit se produire ainsi que les dépendances, la partie responsable de chaque tâche et le calendrier nécessaire. Vous pouvez prévoir des remplaçants pour tous les rôles importants ou dans chaque région, au cas où quelqu’un serait malade ou indisponible. Voici une liste de vérification des éléments à prendre en considération pour le plan de transition :

• Avez-vous documenté le plan de basculement et le plan de retour en arrière si nécessaire?

• Des sauvegardes sont-elles nécessaires avant le changement?

• Des modifications de données préparatoires sont-elles nécessaires?

• Y a-t-il des enregistrements DNS à modifier?

• Y a-t-il des modifications à apporter aux pares-feu?

• De nouvelles cibles de surveillance?

• Un logiciel doit-il être déployé?

Dans votre plan de lancement global, il est utile d’avoir des critères de réussite ou d’échec et d’avoir discuté à l’avance des types de problèmes qui pourraient survenir et qui pourraient être résolus ou qui nécessiteraient un retour en arrière. Un plan de lancement peut spécifier des calendriers de contrôle périodiques avec des critères d’évaluation à chaque point de contrôle et la durée pendant laquelle un problème ne peut être résolu.

Pour chaque étape du lancement, il est utile de définir des critères de réussite qui indiquent que le lancement se déroule comme prévu et peut se poursuivre. Voici quelques exemples de critères :

• Les inscriptions d’utilisateurs augmentent avec un minimum d’erreurs

• Connexion des utilisateurs au rythme prévu, avec un minimum d’erreurs

• Problèmes d’assistance signalés inférieurs à un certain seuil

• Aucun problème susceptible d’entraîner une corruption des données n’a été identifié.

Il est également utile d’avoir identifié les critères qui pourraient déclencher une décision d’arrêt du lancement. La tolérance au risque varie d’un environnement à l’autre, mais voici quelques exemples de critères :

• Pourcentage élevé d’inscriptions ou de connexions d’utilisateurs donnant lieu à des erreurs qui ne peuvent être résolues rapidement.

• Nombre élevé de problèmes d’assistance qui ne peuvent être résolus rapidement

• Identification d’une condition susceptible d’entraîner une corruption des données

• Découverte d’un problème de sécurité de haute gravité

Il est toujours judicieux de prévoir un plan de retour en arrière ou d’inversion d’un lancement, au cas où quelque chose d’imprévisible se produirait et ne pourrait être résolu. L’évaluation du plan de lancement pour chaque étape impliquant un changement peut aider à identifier les tâches ou les changements nécessaires pour revenir sur un lancement ou une conversion.

Le plan de retour en arrière doit comprendre les étapes à suivre, la séquence, la durée probable de chaque étape et la partie responsable. La compréhension du temps cumulé nécessaire au retour en arrière peut aider à déterminer le moment de la décision finale d’acceptation ou de refus afin de s’inscrire dans la fenêtre d’interruption de service requise.

Si des données sont migrées ou modifiées pour le lancement, le plan doit prévoir comment les annuler, si nécessaire. Le retour en arrière peut nécessiter l’exécution de scripts pour annuler les changements opérationnels ou la restauration d’un magasin de données à partir d’une sauvegarde effectuée avant le début du processus de lancement.

Il est également nécessaire de prévoir le cas où certaines données sont saisies dans un nouveau système avant qu’il ne doive être annulé. Ces données/transactions devront-elles être abandonnées lors du retour en arrière ou disposerez-vous d’un moyen de les capturer et de les appliquer ailleurs afin qu’elles ne soient pas perdues?

Si la résolution des problèmes ou le processus de retour en arrière risque de prendre plus d’un quart de travail, vous devrez vous assurer qu’une personne principale et éventuellement une personne secondaire sont disponibles et prêtes à s’occuper de la situation pendant chaque quart de travail. Si un problème nécessite une intervention prolongée, bien au-delà d’un quart de travail, il y a des limites à la durée pendant laquelle les personnes peuvent raisonnablement travailler sans interruption. Il peut être utile de prévoir des ressources pour une intervention en continu à travers les fuseaux horaires, si cela s’avère nécessaire.

À l’approche du jour du lancement, il est conseillé d’identifier tous les contacts susceptibles d’être nécessaires pour résoudre les problèmes et de leur demander de se tenir prêts à intervenir en cas de besoin. Le responsable du lancement doit disposer des coordonnées de chaque personne figurant sur la liste de réserve afin d’accélérer les communications.

S’il existe une « salle de lancement » physique ou virtuelle, les personnes en attente doivent savoir où elle se trouve et être prêtes à la rejoindre si nécessaire. La préparation d’une salle centrale ou d’une vidéoconférence peut accélérer les communications et le dépannage entre toutes les parties en cas de problème.

La réussite d’un lancement passe par une planification poussée, mais savez-vous comment évaluer le lancement? Si vous définissez des critères de réussite avant le lancement, vous pouvez déterminer ce qu’il faut surveiller et si un contrôle ou des vérifications supplémentaires doivent être mis en place pour évaluer le lancement. Par exemple, si l’un des critères de réussite est le nombre d’inscriptions ou de connexions, disposez-vous d’un moyen de le contrôler et l’avez-vous testé pour vous assurer qu’il est exact?

Vous aurez besoin de statistiques pour pouvoir vanter le succès de votre lancement. Vous ne voulez pas vous rendre compte, après le lancement, que vous n’avez saisi aucune donnée permettant de quantifier le travail acharné de votre équipe.

Il n’est pas très amusant de penser à tout ce qui pourrait mal tourner, mais si quelque chose se produit, vous serez heureux de l’avoir fait, car un plan peut accélérer la réaction. Voici quelques exemples à prévoir :

• Bogue d’une application logicielle

• Incompatibilité de l’application avec les paramètres du navigateur de l’utilisateur

• Défaillance ou panne du réseau

• Attaque en déni de service (DoS)

• Défaillance de l’environnement d’hébergement

• Problèmes de charge/de capacité

• Problèmes de données/de corruption

• Découverte d’une faille de sécurité

Si vous avez eu une période bêta, il peut être utile d’examiner les résultats de la bêta pour identifier d’autres scénarios de défaillance possibles.

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées.