Passer au contenu principal

​
Notifications / annonces

Le lancement se déroulera plus facilement si toutes les parties prenantes sont au courant du lancement imminent et comprennent le plan de lancement, ainsi que leur rôle et leurs responsabilités. En plus d’aviser les équipes qui participeront activement au lancement, il peut être utile d’aviser celles qui pourraient être mises à contribution si quelque chose tourne mal. Avoir quelqu’un en renfort pendant un lancement peut aider à accélérer l’intervention. Assurez-vous d’identifier et d’aviser toute équipe qui pourrait devoir répondre aux questions des clients, y compris sur les réseaux sociaux.

​
Parties à aviser

  • Clients
  • Partenaires d’affaires, le cas échéant
  • Équipe(s) d’application touchée(s) par le lancement
  • Équipes de soutien
  • Équipes réseau (changements réseau, en veille en cas de problème)
  • Équipes de sécurité (en veille en cas de problème)
  • Équipes marketing (prêtes pour les annonces et à réagir aux problèmes)
  • Équipes des médias sociaux (prêtes à surveiller les médias sociaux et à répondre)
  • Équipes des ventes (prêtes à répondre aux questions des clients)
  • Équipes de la réussite client (prêtes à répondre aux questions des clients)

​
Plan de notification

Votre plan de notification devrait inclure des éléments tels que l’ cible, les principaux points à communiquer à cette audience, le contenu du message, le plan de diffusion de la notification et la façon de tester le message. Voici une liste des éléments à inclure dans le plan :
  • Audience cible (tenir compte des audiences internes et externes)
  • Message
  • Calendrier
  • Dépendances
  • Responsables (qui l’enverra)
  • Mécanisme (comment il sera communiqué)
  • Message test et validation de l’envoi (le cas échéant - effectuer un test pour s’assurer que les notifications sont envoyées)

​
Distribution des notifications

Une tactique courante consiste à diffuser les notifications par lots afin de répartir la charge initiale et de limiter la confusion en cas de problème imprévu. Il est plus facile de corriger des problèmes avec un petit groupe que lors d’un déploiement massif.
  • Une approche consiste à commencer par un lot de notifications relativement restreint, puis, si aucun problème n’est détecté, à augmenter progressivement la taille des lots.
  • Vous pouvez aussi envoyer les lots selon un calendrier échelonné à l’échelle mondiale afin de répartir la charge sur le système et de faire en sorte que les notifications arrivent à un moment optimal dans chaque fuseau horaire, ce qui augmente la probabilité que les messages soient lus.
  • Vous pouvez effectuer un lancement progressif auprès d’une partie des utilisateurs, par exemple certains clients, certaines régions ou tout autre regroupement pertinent pour votre application.

​
Fenêtres d’interruption (au besoin)

Certaines organisations exigent une demande officielle pour obtenir une fenêtre d’interruption si une interruption de service ou un temps d’arrêt est nécessaire pour une mise en production. Si c’est le cas dans votre organisation, veillez à déterminer si un temps d’arrêt est nécessaire pour le basculement ou la mise en production (ou pour d’autres systèmes dépendants) et à soumettre à l’avance les demandes d’interruption ou de changement requises, en respectant les délais de préavis applicables.

​
Plan de basculement (au besoin)

Certaines mises en service impliquent un basculement d’une solution existante vers une nouvelle solution. Si votre projet correspond à ce scénario, assurez-vous de recenser tout ce qui doit être fait, ainsi que les dépendances, la personne responsable de chaque tâche et le calendrier requis. Vous pourriez aussi prévoir des remplaçants pour tous les rôles clés ou dans chaque région, au cas où quelqu’un tomberait malade de façon imprévue ou serait autrement indisponible. Voici une liste de vérification des éléments à prendre en compte pour le plan de basculement :
  • Avez-vous documenté le plan de basculement et le plan de retour arrière, au besoin ?
  • Faut-il faire des sauvegardes avant le changement ?
  • Des changements préparatoires aux données sont-ils requis ?
  • Y a-t-il des enregistrements DNS à modifier ?
  • Y a-t-il des changements à apporter au pare-feu ?
  • Y a-t-il de nouvelles cibles de surveillance ?
  • Y a-t-il des logiciels à déployer ?

​
Critères go/no-go

Dans votre plan de lancement global, il est utile de définir des critères go/no-go et de discuter à l’avance des types de problèmes qui pourraient survenir, de ceux qui pourraient être résolus en cours de route et de ceux qui exigeraient un retour en arrière. Un plan de lancement peut préciser des points de vérification périodiques, avec des critères indiquant ce qu’il faut évaluer à chaque étape et combien de temps un problème peut rester non résolu. Pour chaque étape du lancement, il est utile de définir des critères de réussite indiquant que le lancement se déroule comme prévu et peut se poursuivre. Voici quelques exemples de critères :
  • Croissance des inscriptions d’utilisateurs avec un minimum d’erreurs
  • Connexions des utilisateurs au rythme prévu, avec un minimum d’erreurs
  • Nombre de problèmes signalés au soutien inférieur à un certain seuil
  • Aucun problème relevé susceptible d’entraîner une corruption des données
Il est également utile d’avoir défini des critères pouvant déclencher une décision « no-go » afin d’interrompre le 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 entraînant des erreurs qui ne peuvent pas être résolues rapidement
  • Nombre élevé de problèmes de soutien qui ne peuvent pas être résolus rapidement
  • Situation relevée susceptible d’entraîner une corruption des données
  • Découverte d’un problème de sécurité critique

​
Retour arrière

Il est toujours prudent d’avoir un plan expliquant comment effectuer un retour arrière ou annuler un lancement, au cas où surviendrait un problème imprévu impossible à résoudre. Passer en revue le plan de lancement pour chaque étape qui implique un changement peut aider à repérer les tâches ou les modifications nécessaires pour revenir en arrière après un lancement ou un basculement. Le plan de retour arrière doit inclure les étapes à suivre, leur ordre, le temps prévu pour chacune et la personne responsable. Comprendre le temps total nécessaire pour effectuer un retour arrière peut aider à déterminer quand prendre la décision finale de poursuivre ou non, de façon à respecter toute fenêtre d’interruption requise. Si des données sont migrées ou modifiées dans le cadre du lancement, le plan doit préciser comment les rétablir, au besoin. Le retour en arrière peut nécessiter l’exécution de scripts pour annuler des 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 faut aussi prévoir le cas où certaines données sont saisies dans un nouveau système avant qu’un retour en arrière ne soit nécessaire. Ces données / transactions devront-elles être abandonnées lors du retour arrière, ou aurez-vous un moyen de les récupérer et de les appliquer ailleurs pour éviter de les perdre? 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 peut-être une personne secondaire, sont disponibles et prêtes à gérer la situation pendant chaque quart de travail. Si un problème exige une intervention prolongée, bien au-delà d’un seul quart de travail, il y a des limites au temps pendant lequel les gens peuvent raisonnablement fonctionner sans pause. Il peut être utile de prévoir des ressources pour une intervention de type « follow-the-sun », au besoin.

​
Contacts en attente

À l’approche du jour du lancement, il est recommandé d’identifier toutes les personnes-ressources qui pourraient être nécessaires pour le dépannage ou la résolution de problèmes et de leur demander de se tenir prêtes à aider au besoin. Le responsable du lancement devrait avoir les coordonnées de chaque personne sur la liste des contacts en attente afin d’accélérer les communications. S’il y a une « salle de lancement » physique ou virtuelle, les personnes en attente devraient savoir où elle se trouve et être prêtes à s’y joindre au besoin. Le fait de prévoir une salle centrale ou une visioconférence peut accélérer les communications et le dépannage entre toutes les parties si un problème survient.

​
Critères de réussite

Il faut beaucoup de planification pour qu’un lancement soit une réussite, mais saurez-vous comment en évaluer le succès? Si vous définissez des critères de réussite avant le lancement, vous pouvez déterminer ce qu’il faut surveiller et si une surveillance ou des vérifications supplémentaires doivent être mises en place pour évaluer le lancement. Par exemple, si l’un des critères de réussite est le nombre d’inscriptions ou d’ouvertures de session, avez-vous un moyen de le surveiller, et ce moyen a-t-il été testé pour en garantir l’exactitude? Vous voudrez disposer de statistiques pour pouvoir démontrer le succès de votre lancement. Vous ne voulez pas découvrir après le lancement que vous n’avez recueilli aucune donnée pour quantifier tout le travail acharné que votre équipe y a consacré.

​
Plan des risques et des mesures d’atténuation

Ce n’est pas agréable de penser à tout ce qui pourrait mal tourner, mais s’il se passe quoi que ce soit, vous serez content de l’avoir fait, car le fait d’avoir un plan peut accélérer l’intervention. Voici quelques exemples à prévoir :
  • Bogue logiciel
  • Incompatibilité de l’application avec les paramètres du navigateur de l’utilisateur
  • Défaillance ou panne du réseau
  • Attaque DoS
  • Défaillance de l’environnement d’hébergement
  • Problèmes de charge ou de capacité
  • Problèmes de données ou de corruption
  • Vulnérabilité de sécurité découverte
Si vous avez eu une phase bêta, il peut être utile d’en examiner les résultats afin de cerner d’autres scénarios de défaillance possibles.

​
Guide de planification du projet

Nous mettons à votre disposition un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons. Guide de planification du projet B2B IAM