Passer au contenu principal

​
Notifications / annonces

Un lancement se déroule plus harmonieusement lorsque 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 appelées en renfort si quelque chose tourne mal. Le fait d’avoir quelqu’un prêt à intervenir pendant un lancement peut aider à accélérer la réponse. Assurez-vous de repérer et d’aviser toute équipe qui pourrait devoir répondre aux questions des clients, y compris sur les médias sociaux.

​
Parties à aviser

  • Clients
  • Partenaires d’affaires, le cas échéant
  • Équipe(s) responsable(s) de l’application touchée(s) par le lancement
  • Équipes de soutien
  • Équipes réseau (changements réseau, en attente, en cas de problème)
  • Équipes de sécurité (en attente, 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éparées à répondre aux questions des clients)
  • Équipes de la réussite client (préparées à répondre aux questions des clients)

​
Plan de notification

Votre plan de notification devrait comprendre des éléments comme l’ cible, les principaux messages à retenir pour cette audience, le contenu du message, la façon dont la notification sera diffusée et comment tester les messages. Voici une liste d’éléments à inclure dans le plan :
  • Audience cible (tenir compte des audiences internes et externes)
  • Message
  • Échéancier
  • Dépendances
  • Responsables (qui l’enverra)
  • Mécanisme (comment il sera communiqué)
  • Message de test et envoi (le cas échéant - tester pour s’assurer que les notifications sont envoyées)

​
Distribution des notifications

Une tactique courante consiste à déployer les notifications par lots afin d’étaler la charge initiale et de limiter la confusion en cas de problèmes imprévus. Il est plus facile de corriger des problèmes avec un petit groupe que lors d’un lancement à grande échelle.
  • Une approche consiste à commencer par un lot de notifications relativement petit, puis, si aucun problème n’est relevé, à augmenter graduellement la taille des lots.
  • Vous pouvez aussi envoyer les lots selon un calendrier progressif à l’échelle mondiale afin d’étaler la charge sur le système et de faire arriver les notifications à un moment optimal dans chaque fuseau horaire, ce qui augmente les chances que les messages soient lus.
  • Vous pouvez aussi faire 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 une fenêtre d’interruption si une interruption de service ou un temps d’arrêt est nécessaire pour un lancement. Si c’est le cas dans votre organisation, assurez-vous de déterminer si un temps d’arrêt est requis pour le basculement ou le lancement (ou pour d’autres systèmes dépendants) et de soumettre à l’avance les demandes d’interruption ou de changement nécessaires, en respectant les délais de préavis requis.

​
Plan de basculement (au besoin)

Certains lancements impliquent la transition d’une ancienne solution vers une nouvelle. Si votre projet correspond à ce scénario, vous devez veiller à recenser tout ce qui doit être fait, ainsi que les dépendances, la personne responsable de chaque tâche et les délais à prévoir. Vous pourriez aussi vouloir prévoir des remplaçants pour tous les rôles importants 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 de quoi que ce soit avant le changement ?
  • Des modifications préparatoires aux données sont-elles requises ?
  • Y a-t-il des enregistrements DNS à modifier ?
  • Y a-t-il des modifications au pare-feu ?
  • Y a-t-il de nouvelles cibles de surveillance ?
  • Y a-t-il des logiciels à déployer ?

​
Critères de lancement / d’arrêt

Dans votre plan de lancement global, il est utile d’établir des critères de lancement et d’arrêt, ainsi que de discuter à l’avance des types de problèmes qui pourraient survenir, de ceux qu’on pourrait corriger en cours de route et de ceux qui exigeraient un retour en arrière. Un plan de lancement peut prévoir des points de vérification périodiques, avec des critères précisant 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 :
  • Augmentation des inscriptions d’utilisateurs avec un minimum d’erreurs
  • Connexions des utilisateurs au rythme prévu, avec un minimum d’erreurs
  • Nombre de demandes d’assistance signalées inférieur à un certain seuil
  • Aucun problème relevé pouvant entraîner une corruption des données
Il est aussi utile d’avoir établi des critères pouvant déclencher une décision d’arrêt du lancement. La tolérance au risque varie selon l’environnement, mais voici quelques exemples de critères possibles :
  • Pourcentage élevé d’inscriptions ou de connexions d’utilisateurs entraînant des erreurs qui ne peuvent pas être résolues rapidement
  • Nombre élevé de demandes d’assistance qui ne peuvent pas être résolues rapidement
  • Situation relevée pouvant entraîner une corruption des données
  • Découverte d’un problème de sécurité grave

​
Retour arrière

Il est toujours prudent d’avoir un plan de retour arrière ou d’annulation du lancement, au cas où un imprévu surviendrait et ne pourrait pas être résolu. 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 annuler un lancement ou un basculement. Le plan de retour arrière devrait inclure les étapes à suivre, leur ordre, le temps prévu pour chacune et la personne responsable. Comprendre le temps total requis pour effectuer un retour arrière peut aider à déterminer le moment de la décision finale de poursuivre ou non, afin de respecter toute fenêtre d’interruption requise. Si des données sont migrées ou modifiées dans le cadre du lancement, le plan devrait préciser comment les rétablir, au besoin. Le retour arrière peut exiger l’exécution de scripts pour annuler des changements opérationnels ou la restauration d’une base de données à partir d’une sauvegarde effectuée avant le début du processus de lancement. Il faut également prévoir le cas où certaines données seraient saisies dans un nouveau système avant qu’un retour arrière ne soit nécessaire. Ces données ou 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 afin qu’elles ne soient pas perdues ? Si la résolution des problèmes ou le processus de retour arrière risque de prendre plus d’un quart de travail, vous devrez vous assurer qu’une personne principale, et peut-être une personne de relève, sont disponibles et prêtes à intervenir 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 à la durée pendant laquelle les gens peuvent raisonnablement fonctionner sans pause. Il peut être utile de prévoir les ressources nécessaires pour une intervention continue selon un modèle follow-the-sun, au besoin.

​
Contacts en attente

À mesure que le jour du lancement approche, il est bon 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 à intervenir au besoin. Le responsable du lancement devrait avoir les coordonnées de chaque personne figurant 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 d’avoir une salle centrale ou une visioconférence prête 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 préparation pour assurer le succès d’un lancement, mais saurez-vous comment en évaluer les résultats? Si vous définissez des critères de réussite avant le lancement, vous pourrez déterminer ce qu’il faut surveiller et si une surveillance ou des vérifications supplémentaires doivent être mises en place pour en évaluer les résultats. Par exemple, si l’un des critères de réussite est le nombre d’inscriptions ou de connexions, avez-vous un moyen d’en faire le suivi, et a-t-il été testé pour en assurer l’exactitude? Vous voudrez disposer de statistiques pour pouvoir mettre en valeur le succès de votre lancement. Vous ne voudriez pas découvrir après le lancement que vous n’avez recueilli aucune donnée permettant de quantifier tout le travail acharné que votre équipe y a consacré.

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

Ce n’est pas très agréable de penser à tout ce qui pourrait mal tourner, mais si quelque chose arrive, vous serez bien content de l’avoir fait, puisqu’un plan peut accélérer l’intervention. Voici quelques exemples à prévoir :
  • Bogue de l’application
  • Incompatibilité de l’application avec les paramètres du navigateur de l’utilisateur
  • Panne ou interruption du réseau
  • Attaque par déni de service (DoS)
  • Défaillance de l’environnement d’hébergement
  • Problèmes de charge ou de capacité
  • Problèmes de données ou de corruption
  • Découverte d’une vulnérabilité de sécurité
Si vous avez eu une période 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 de 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 de projet B2C IAM