Skip to main content

​
Notifications / annonces

Pour qu’un lancement se déroule bien, il est utile que toutes les parties prenantes soient au courant du lancement à venir et comprennent le plan de lancement ainsi que leur rôle et leurs responsabilités. En plus d’aviser les équipes qui participeront activement, il peut aussi être utile d’aviser celles dont on pourrait avoir besoin si quelque chose se passe mal. Le fait d’avoir quelqu’un de garde 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, s’il y a lieu
  • Équipes responsables des applications touchées par le lancement
  • Équipes de soutien
  • Équipes réseau (changements au réseau, en garde en cas de problème)
  • Équipes de sécurité (en garde en cas de problème)
  • Équipes de marketing (prêtes pour les annonces et à réagir en cas de problème)
  • É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 comme l’ cible, les principaux points à retenir pour cette audience, le contenu du message, le plan de diffusion de la notification et la façon de tester les messages. Voici une liste d’éléments à inclure dans le plan :
  • Audience cible (tenir compte des audiences internes et externes)
  • Message
  • Moment de l’envoi
  • Dépendances
  • Responsables (qui l’enverra)
  • Mécanisme (comment le message sera communiqué)
  • Message test et livraison (s’il y a lieu - 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 d’étaler 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 lancement d’envergure.
  • Une approche consiste à commencer avec un lot de notifications relativement petit, puis, si aucun problème n’est relevé, à augmenter graduellement la taille des lots.
  • Vous pouvez aussi envoyer des lots selon un calendrier échelonné à l’échelle mondiale pour répartir la charge qui atteint le système en même temps et 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 faire un lancement progressif auprès d’une partie des utilisateurs, comme certains clients, certaines régions ou un autre regroupement pertinent pour votre application.

​
Fenêtres d’indisponibilité (au besoin)

Certaines organisations exigent une demande officielle de fenêtre d’indisponibilité lorsqu’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 tout délai de préavis applicable.

​
Plan de bascule (au besoin)

Certaines lancements impliquent la bascule 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, le responsable de chaque tâche et l’échéancier requis. Vous pourriez aussi prévoir des remplaçants pour tous les rôles importants ou dans chaque région, au cas où quelqu’un tomberait malade à l’improviste ou serait autrement indisponible. Voici une liste de vérification des éléments à prendre en compte pour le plan de bascule :
  • Avez-vous documenté le plan de bascule et le plan de retour arrière, au besoin ?
  • Faut-il effectuer des sauvegardes avant le changement ?
  • Des modifications préparatoires aux données sont-elles requises ?
  • Des enregistrements DNS doivent-ils être modifiés ?
  • Des modifications au pare-feu ?
  • De nouvelles cibles de surveillance ?
  • Un logiciel à déployer ?

​
Critères de décision go / no-go

Dans votre plan de lancement global, il est utile d’établir des critères de décision go/no-go et de discuter à l’avance des types de problèmes qui pourraient survenir, de ceux qui pourraient être réglés et de ceux qui exigeraient un retour à une version antérieure. 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 demeurer non résolu. Pour chaque étape du lancement, il est utile de définir des critères de succès qui indiquent que le lancement se déroule comme prévu et peut se poursuivre. Voici quelques exemples de critères possibles :
  • Croissance du nombre d’inscriptions d’utilisateurs avec un minimum d’erreurs
  • Connexions des utilisateurs au rythme prévu, avec un minimum d’erreurs
  • Problèmes signalés au soutien sous un certain seuil
  • Aucun problème relevé qui pourrait mener à une corruption des données
Il est aussi utile d’avoir défini des critères pouvant déclencher une décision de « 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 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 problèmes de soutien qui ne peuvent pas être résolus rapidement
  • Situation relevée pouvant 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 de retour arrière ou de rétablissement 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 comporte un changement peut aider à cerner les tâches ou les modifications requises pour effectuer un retour arrière ou une bascule. Le plan de retour arrière devrait inclure les étapes à suivre, leur séquence, le temps probable pour chacune et la partie responsable. Comprendre le temps total nécessaire pour effectuer un retour arrière peut aider à déterminer le moment de la décision finale de go/no-go afin de respecter toute fenêtre d’indisponibilité 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 rétablissement peut exiger l’exécution de scripts pour annuler les changements opérationnels ou la restauration d’un stockage 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’il doive être rétabli. Ces données / transactions devront-elles être abandonnées lors du retour arrière, ou aurez-vous un moyen de les consigner et de les appliquer ailleurs pour éviter qu’elles ne soient perdues? Si la résolution des problèmes ou le processus de rétablissement risque de prendre plus d’un quart de travail, vous voudrez vous assurer qu’une personne principale, et peut-être une personne secondaire, soit disponible et prête à gérer la situation pendant chaque quart de travail. Si un problème entraîne la nécessité d’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 fonctionner de façon réaliste sans pause. Il peut être utile de prévoir des ressources pour une intervention de type follow-the-sun, au besoin.

​
Personnes-ressources de garde

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

​
Critères de succès

La préparation d’un lancement réussi demande beaucoup de planification, mais saurez-vous comment en évaluer les résultats? Si vous définissez des critères de succès avant le lancement, vous pourrez déterminer quoi surveiller et si une surveillance supplémentaire ou des vérifications additionnelles doivent être mises en place pour évaluer le lancement. Par exemple, si l’un des critères de succès est le nombre d’inscriptions ou d’ouvertures de session, avez-vous un moyen d’en faire le suivi et avez-vous vérifié que ces données sont exactes? Vous voudrez disposer de statistiques pour pouvoir mettre en valeur le succès de votre lancement. Vous ne voudrez pas découvrir après le lancement que vous n’avez recueilli aucune donnée pour mesurer 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 à ce qui pourrait mal tourner, mais s’il arrive quoi que ce soit, vous serez bien content de l’avoir fait, car le fait d’avoir 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
  • 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 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 au 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