Une présentation de fin de vie d’un produit doit montrer ce qui va s’arrêter, qui en dépend et comment chaque groupe concerné pourra poursuivre son activité. Une date d’arrêt ne constitue pas, à elle seule, un plan de transition. Les diapositives les plus utiles relient une tâche précise à une solution de remplacement, à un responsable et aux décisions nécessaires avant l’annonce.
Ce guide illustre cette structure avec un portail de réservation fictif. Ses utilisateurs dans le navigateur, ses responsables d’intégration et les personnes qui consultent d’anciens dossiers ont besoin d’instructions différentes. Décrivez d’abord ces parcours dans une courte note, puis utilisez Presenti pour transformer le document Word en brouillon de présentation. Le diaporama explique la transition ; il ne migre ni comptes, ni réservations, ni données historiques.
Dites précisément ce qui va s’arrêter
« Nous allons retirer l’ancien portail » paraît clair à l’équipe produit. Pour un client, plusieurs questions restent ouvertes : pourra-t-il encore se connecter ? Une réservation existante restera-t-elle valable ? Son intégration fonctionnera-t-elle toujours ? Pourra-t-il retrouver les données de l’an dernier ?
Décrivez les usages affectés avant d’employer un terme de cycle de vie. Le glossaire du cycle de vie de Microsoft distingue, par exemple, dépréciation, suppression et retrait dans le cadre de ses propres politiques. Ces termes ne doivent pas remplacer une explication des changements concrets de votre service.
Pour le portail fictif, la première mesure envisagée consiste à arrêter la création de réservations dans l’ancienne interface Web. Cela ne détermine pas, en soi, le devenir des réservations existantes, des requêtes API, de l’accès aux dossiers ou de l’assistance. Présentez ces points sur des lignes séparées :
| Tâche de l’utilisateur | Changement envisagé dans l’exemple | Ce que l’équipe doit décider |
|---|---|---|
| Créer une réservation dans le navigateur | Les nouvelles réservations passent par le portail de remplacement. | Qui peut y accéder, à partir de quand et où obtenir de l’aide. |
| Gérer une réservation créée avant le changement | L’arrêt des nouvelles réservations ne règle pas cette question. | Où la consulter, la modifier ou l’annuler. |
| Créer des réservations par API | L’intégration nécessite une transition distincte. | Point d’accès, authentification, correspondance des champs, gestion des erreurs et modalités de bascule. |
| Consulter des dossiers historiques | Un parcours d’accès aux données doit être défini. | Dossiers disponibles, méthode de récupération, droits d’accès et politique de conservation applicable. |
Ce tableau évite qu’une annonce apparemment limitée ne fasse une promesse bien plus large. Il donne aussi à l’assistance une façon concrète d’expliquer le changement sans improviser de règles.
Organisez la transition par usage, pas par formule d’abonnement
Un même client peut utiliser le navigateur, maintenir une intégration et consulter des données historiques. Ces parcours peuvent se recouper : ce ne sont pas des segments de clientèle exclusifs. Si vous comptez les organisations concernées, dédupliquez ce total séparément. Additionner les effectifs des trois parcours pourrait compter plusieurs fois une même organisation.
Le guide GOV.UK sur l’arrêt d’un service part des besoins qui subsisteront et distingue les utilisateurs directs des utilisateurs d’API. C’est une question utile pour préparer le diaporama : que doit pouvoir continuer à faire chaque personne ?
| Parcours actuel | Parcours suivant | Éléments nécessaires avant de demander le changement |
|---|---|---|
| Une personne à l’accueil crée des réservations dans l’ancien portail. | Créer les nouvelles réservations dans le portail de remplacement. | Le compte concerné permet de se connecter, de créer une réservation et de trouver de l’aide ; les réservations existantes font l’objet d’instructions distinctes. |
| Un système opérationnel transmet des réservations par API. | Utiliser l’intégration de remplacement prise en charge. | Le responsable a établi la correspondance des champs et des comportements, essayé des requêtes représentatives et convenu de la bascule. |
| Un utilisateur recherche d’anciennes réservations. | Utiliser une archive ou un processus de récupération approuvé. | Une personne autorisée peut trouver et lire le dossier voulu ; les questions de conservation et d’accès ont un responsable identifié. |
Une flèche vers « Nouvelle plateforme » ne signifie pas que le travail est terminé. Montrez la tâche possible à l’arrivée. Le remplacement peut très bien créer de nouvelles réservations sans offrir de solution pour annuler une ancienne réservation. Cette lacune mérite une place sur la diapositive, même si la nouvelle plateforme compte davantage de fonctionnalités.
Pour les intégrations, rendez la correspondance concrète. Le champ référence de réservation de l’ancien service peut devenir un identifiant différent dans le nouveau. Précisez si le système appelant garde sa référence initiale, enregistre une nouvelle référence ou doit consulter une table de correspondance. Les noms sont illustratifs ici ; le contrat d’interface réel vient de votre documentation API, pas de l’auteur des diapositives.
Séparez le calendrier proposé de la promesse faite aux clients
Le diaporama interne peut afficher une date proposée alors qu’une dépendance reste à résoudre. Un avis aux clients ne devrait engager l’organisation que sur un périmètre approuvé. Indiquez clairement le statut du calendrier interne pour qu’une date provisoire ne devienne pas une promesse apparente lorsqu’une diapositive est transférée.
Dans l’exemple, l’accès par navigateur peut être prêt avant la correspondance de l’intégration. L’accès aux dossiers peut dépendre d’un troisième élément. Présentez trois lignes avec leurs propres jalons : destination disponible, utilisateurs informés, action utilisateur terminée et ancien parcours arrêté. Ne les faites pas toutes finir à la même date uniquement pour obtenir un diagramme plus régulier.
La décision de la réunion peut donc être limitée : approuver la communication sur le changement de portail Web, sans annoncer encore la date d’arrêt de l’API. Ce n’est pas la même chose qu’approuver l’arrêt de tout le service. Inscrivez la portée réelle de la décision à côté du calendrier.
Si les contrats, remboursements, exigences d’accessibilité ou obligations relatives aux dossiers influencent la transition, intégrez à la note la politique approuvée applicable et son responsable. Un modèle générique d’avis ne peut pas déterminer ces conditions. Posez la question de manière précise, par exemple « Quelle équipe approuve la poursuite de l’accès aux dossiers ? », plutôt que de remplir la diapositive d’avertissements généraux.
Rédigez trois avis pour trois tâches différentes
Les modèles suivants appartiennent à l’exemple du portail fictif. Remplacez les champs entre crochets par des informations approuvées avant de les utiliser. Chaque avis commence par la tâche concernée, puis précise l’action et le bon interlocuteur pour obtenir de l’aide.
Pour les personnes qui créent des réservations dans le navigateur
À partir du [date, heure et fuseau horaire], utilisez [lien du portail de remplacement] pour créer de nouvelles réservations. Le portail actuel cessera d’accepter de nouvelles réservations à ce moment-là. Les réservations créées avant le changement pourront être consultées, modifiées ou annulées via [parcours confirmé pour les réservations existantes]. Avant votre prochaine réservation, connectez-vous au portail de remplacement avec [instructions d’accès approuvées]. Si vous ne pouvez pas y accéder, contactez [canal d’assistance] en indiquant le nom de votre organisation et la tâche que vous cherchez à accomplir.
La phrase sur les réservations existantes est importante. Sans elle, une personne qui a réservé pour le mois prochain ne sait pas si cette annonce la concerne. Si ce parcours reste indécis, réglez-le avant d’envoyer un avis qui semble couvrir tous les utilisateurs du navigateur.
Pour les responsables d’intégration
Votre intégration utilise [API ou version concernée] pour transmettre des réservations. Cette interface doit cesser d’accepter les requêtes le [date, heure et fuseau horaire approuvés]. La documentation de remplacement se trouve à [lien de documentation]. Examinez l’authentification, les champs obligatoires, les identifiants renvoyés et le comportement en cas d’erreur de votre intégration, puis organisez la bascule avec [contact technique]. Envoyez le nom de votre intégration et le créneau de bascule proposé via [canal d’assistance]. Le changement de portail des utilisateurs du navigateur ne met pas à jour cette intégration.
Adressez cet avis aux personnes qui maintiennent l’intégration, et pas seulement au contact commercial du compte. Une annonce générale peut ne pas atteindre la personne qui doit modifier le logiciel et planifier l’intervention.
Pour les personnes qui ont besoin de dossiers historiques
Pour obtenir des dossiers du portail de réservation actuel, utilisez [parcours de récupération approuvé]. Il donne accès à [périmètre et format des dossiers confirmés] pour [utilisateurs ou rôles autorisés]. L’accès par le portail actuel change le [date, heure et fuseau horaire approuvés]. Pour toute question sur des dossiers hors du périmètre disponible ou sur les conditions d’accès, contactez [canal d’assistance aux dossiers]. Les informations de conservation applicables sont disponibles à [lien de la politique approuvée].
N’ajoutez pas « Toutes vos données seront transférées automatiquement » sans avoir établi ce périmètre et ce fonctionnement précis. Un rapport téléchargeable, une archive consultable et un historique de réservations modifiable sont des résultats différents. Nommez celui que les utilisateurs recevront réellement.
Construisez un diaporama court autour des parcours et des messages
Ouvrez avec une description précise du changement envisagé : « Déplacer les nouvelles réservations Web vers le portail de remplacement ; traiter séparément les parcours API et dossiers. » Enchaînez avec le tableau de périmètre et les trois parcours. Le public peut ainsi discuter des conséquences avant de découvrir le calendrier.
Au milieu du diaporama, présentez les jalons proposés et un avis représentatif. Placez les deux autres modèles en annexe ou dans la note jointe pour garder la réunion principale lisible. La dernière diapositive doit nommer la décision demandée, la personne habilitée à la prendre et les points non résolus qui restent en dehors de cette décision.
Dans la note Word, donnez un titre distinct à chaque parcours. Incluez le tableau de périmètre, le texte approuvé des avis et le statut de chaque jalon. Pour le brouillon de diapositives, demandez de conserver les trois parcours séparés et de laisser ouvertes les dates encore indécises. Évitez de demander à l’outil d’inventer un calendrier de migration à partir d’un simple nom de produit.
Pour un programme de communication plus large, un plan de communication avec les parties prenantes permet d’organiser les publics, canaux et responsables autour de ces avis. La présentation de fin de vie apporte le changement concret que chaque message doit expliquer.
Montrez qui aide après l’arrêt de l’ancien parcours
Le dernier jour de l’ancien portail n’est pas forcément le dernier jour du travail de transition. Une personne peut arriver par un favori enregistré, poser une question sur une ancienne réservation ou découvrir une intégration absente de l’inventaire. Donnez à l’équipe d’assistance qui prend le relais un chemin clair pour ces cas.
Dans l’exemple, l’assistance Web traite l’accès au remplacement, le contact technique répond aux questions d’intégration et le contact dossiers gère les demandes de récupération. Indiquez aux équipes quel interlocuteur prend chaque demande en charge et quelles informations transmettre. Une boîte de réception commune sans répartition claire oblige les utilisateurs à répéter leur histoire.
Terminez la réunion en consignant séparément le périmètre approuvé et les décisions restantes. Une présentation réussie rend la prochaine action compréhensible et permet à l’équipe de répondre à « Que devient mon travail ? » sans inventer de réponse.
