Déployer une technologie est difficile, et la phase pilote décide si la solution sera adoptée et si elle apportera les bénéfices attendus. Mener un pilote ressemble à piloter un avion : les premiers instants (le décollage) et les derniers (l'atterrissage) sont les plus critiques, ceux qui demandent le plus d'attention. Entre les deux, l'équipage peut relâcher un peu et s'appuyer sur le pilote automatique.
Après avoir expliqué comment mener un pilote technologique efficace (article en anglais), je détaille ici le décollage : la phase d'hypercare, et ce qu'il faut faire dans les semaines qui suivent le go-live pour que votre projet quitte le sol et atteigne sa vitesse de croisière.
La checklist de la phase d'hypercare
L'hypercare, ce sont les premières semaines après le go-live, pendant lesquelles l'équipe projet fonctionne avec un niveau de support et d'attention renforcé. Si vous n'avez qu'un écran à lire, lisez celui-ci.
- Démarrez le jour du go-live. Fixez une durée, idéalement jusqu'à la première revue du pilote.
- Nommez une petite équipe dédiée. Le chef de projet, l'équipe cœur, et le fournisseur à la table.
- Demandez au fournisseur un interlocuteur support dédié. Une seule personne qui suit et clôt chaque incident.
- Regardez chaque transaction de bout en bout. Performance technique, bénéfices obtenus, expérience utilisateur.
- Formez les utilisateurs pilotes sur deux points. Comment utiliser l'outil, et quand l'utiliser. Gardez les supports accessibles hors ligne.
- Ouvrez un canal de retour dans les deux sens. Une file de tickets ou une boîte mail, plus des focus groups de 10 à 20 utilisateurs pilotes, y compris ceux qui n'ont pas utilisé l'outil.
- Changez quelque chose chaque semaine et mesurez l'effet. Paramétrage, communication, périmètre. Revenez vite en arrière sur ce qui ne marche pas.
- Arrêtez après quelques semaines. Si ce niveau de contrôle reste nécessaire, le problème est plus profond que le déploiement.
C'est ainsi que je mène les semaines qui suivent le go-live sur les projets de digitalisation achats que je pilote.
Pourquoi l'hypercare compte
Dans un monde idéal, on n'aurait pas besoin d'hypercare. C'est sans doute pour cela que beaucoup d'organisations lancent leur solution digitale, puis attendent la fin de la période convenue pour voir s'il y a eu adoption et résultats. Dans ce monde idéal, la solution est parfaitement connectée, toutes les données circulent correctement, et les utilisateurs font exactement ce dont ils ont besoin, sans formation et sans erreur.
La réalité ? Il y a TOUJOURS des erreurs, des cas que personne n'avait prévus, et ils créent de l'insatisfaction. Pensez au poids de la première expérience : si des problèmes apparaissent et ne sont pas traités tout de suite, votre projet s'éteint faute d'adoption. Le vieil adage marketing dit qu'un utilisateur mécontent en parle à six personnes. Chaque mauvaise expérience fait boule de neige et peut donner une mauvaise réputation à la solution que vous essayez de faire adopter.
Pour éviter ces erreurs de départ, ou au moins en limiter l'effet sur l'adoption, les organisations les plus avancées mettent en place une phase d'hypercare. C'est une phase du pilote, en général les premières semaines après le go-live, pendant laquelle l'équipe projet fonctionne avec un niveau de support et de ressources renforcé. Chaque aspect de la solution est examiné, les incidents sont identifiés, suivis et résolus, pour que le premier contact avec l'outil soit réussi.
Une phase d'hypercare vise donc une vue complète de la performance fonctionnelle et technique de la solution, de bout en bout, retours utilisateurs compris. Elle sert aussi à commencer à itérer sur les KPI, les flashs hebdomadaires et les autres informations que vous allez produire pour évaluer la solution. Vous découvrirez que certains critères d'évaluation manquaient, et que d'autres comptent moins que prévu. Dans les deux cas, restez ouvert et flexible : préparez-vous à essayer, changer et expérimenter beaucoup de choses pendant ce temps limité.
Une grande part de la réussite de votre projet de digitalisation se joue dans ces quelques semaines. Faites-les compter.
L'hypercare commence le jour même où la solution arrive chez les utilisateurs finaux, et dure une période définie : idéalement jusqu'à la première revue du pilote.
Le but est de ne laisser aucun angle mort. L'attention de l'équipe projet va des indicateurs du pilote jusqu'aux aspects les plus opérationnels, jusqu'au nombre de clics des utilisateurs si c'est pertinent. Chaque transaction est regardée et comprise de bout en bout. Il n'y en aura probablement pas tant que ça : le déploiement big bang n'existe pas en transformation digitale.
Monter une équipe agile et expérimenter
L'équipe projet, fournisseurs compris, doit consacrer du temps et des ressources à produire et analyser les données, suivre les retours utilisateurs et résoudre vite chaque incident. L'hypercare est menée par le chef de projet et l'équipe cœur, mais il est souhaitable que d'autres fonctions s'impliquent. Une bonne pratique consiste à demander au fournisseur de désigner une personne dédiée au service client, de préférence l'une des meilleures de son équipe, qui devient le point focal et suit chaque incident jusqu'à sa résolution. C'est important, parce que dans la plupart des cas le service client passe par une adresse ou un numéro générique : l'information se perd, personne ne relie les points. Comprenez comment le service client de votre fournisseur est organisé, s'il existe plusieurs niveaux de support, quels sont les principaux workflows. Bien engagé, il devient un vrai facteur de réussite.
Pendant cette période, tout l'enjeu est de comprendre ce qui se passe et de le PILOTER. Suivre les KPI ne suffit pas : l'hypercare sert aussi à essayer le plus de choses possible. Ces essais peuvent être techniques (changer un paramétrage), porter sur la communication (envoyer plus de documentation, ou une autre), ou sur le périmètre (l'étendre ou le restreindre, tester des fonctionnalités jugées moins prioritaires). Quand vous prenez ces décisions, suivez leurs effets semaine après semaine pour revenir vite en arrière sur ce qui n'a pas de sens. Les organisations qui lancent un pilote et attendent la fin de la période pour voir si ça marche vont très probablement vers une déception. Celles qui réussissent expérimentent beaucoup et osent : avec un nombre limité d'utilisateurs, les risques sont très faibles, et tout essai deviendra plus complexe et plus risqué ensuite.
Ce niveau d'attention n'est pas tenable dans la durée, et c'est pour cela qu'il ne doit durer que quelques semaines. Si vous devez garder ce niveau de contrôle et de suivi au-delà, vous avez probablement un problème plus profond : soit la solution ne fonctionne pas, soit elle ne répond pas aux besoins de vos parties prenantes.
Et mettre l'utilisateur au centre
Une hypercare réussie regarde la technique (la solution fonctionne-t-elle comme prévu), mesure les bénéfices (livre-t-elle ce qui était attendu), mais se concentre surtout sur les utilisateurs et leur expérience.
Le premier objectif, à atteindre le plus vite possible, est de former les utilisateurs pilotes. La formation couvre deux volets : comment utiliser la solution (où cliquer) et quand l'utiliser (les cas d'usage où elle est pertinente). Il existe plusieurs façons de former : les sessions en direct et les office hours (article en anglais) sont mes préférées, mais les cours en ligne, les quiz et d'autres formats fonctionnent aussi. L'important est de donner ces ressources à l'utilisateur et de les rendre disponibles à tout moment, en version hors ligne. Ces documents sont souvent négligés : quelques PDF déposés sur un drive. C'est une erreur. Ce sont eux qui aident vos utilisateurs à se servir de la solution, ils doivent donc être soignés : rien n'est plus décourageant pour quelqu'un qui prend le temps de chercher une information que de trouver une documentation incohérente et à moitié finie.
Le second objectif est d'ouvrir un canal de communication dans les deux sens avec les utilisateurs et de recueillir leurs retours. L'équipe projet dispose de plusieurs KPI pour juger la performance du pilote, mais le retour qualitatif compte au moins autant, et le recueillir demande d'autres mécanismes. Un système de tickets ou une adresse mail dédiée permettent de collecter les retours de façon passive. Leur limite est le biais qu'ils introduisent : on écrit plus volontiers quand quelque chose s'est mal passé que pour dire que tout va bien. Des focus groups de 10 à 20 utilisateurs pilotes corrigent ce biais. Ils montrent comment la solution est perçue et vécue, y compris par ceux qui ne l'ont pas utilisée, qu'il faut inviter aussi. Ces sessions donnent des enseignements, positifs ou négatifs, que les données seules ne donneront jamais.
En résumé, si vous voulez que vos pilotes décollent et ne deviennent pas des projets zombies, ceux qui avancent encore mais avec si peu de vitalité qu'ils sont déjà morts, les premières semaines sont décisives. Ne manquez pas la fenêtre. Mener une hypercare structurée demande du temps et des ressources, mais c'est le seul moyen de tester et de déployer vraiment une nouvelle technologie.