Le plus avancé des outils n’est utile que si on sait qu’il existe.
Depuis un an je travaille comme product owner chez GE HealthCare, sur la gestion du projet Sherlock : un moteur de recherche pour l’immense réseau d’archives d’imagerie médicale de l’entreprise. L’outil a été créé il y a des années, et est en évolution constante. J’ai rejoint l’équipe pour piloter ces évolutions, mais aussi et surtout gérer une facette du projet qui était passée au second plan: la communication.
📁 Réalisations
✓ Identité graphique & éditoriale ✓ Newsletter ✓ Campagnes d’emailing ✓ Vidéos tutorielles ✓ Documentation ✓ Étude utilisateur-ices💪 Hard Skills
✓ Gestion de projet ✓ Design graphique ✓ Écriture, tournage et montage vidéo
✓ Rédaction💡 Soft Skills
✓ Vulgarisation ✓ Travail en équipe ✓ Prise de responsabilité
Toutes les images dans cet article ont été modifées et anonymisées pour exclure toute information potentiellement sensible.
Etat des lieux
Au moment de mon arrivée, la communication autour de Sherlock se résumait essentiellement à deux canaux :
- Des emails ponctuels : envoyés directement depuis l’adresse mail du chef de projet, par exemple lors de mises à jour
- Un forum interne : très peu utilisé
A ce stade, beaucoup de gens pensaient que l’application était en phase de sunsetting. L’enjeu était donc de re-créer du dialogue : de manière verticale, entre l’équipe technique et les utilisateur-ices, et de manière horizontale, au sein de la communauté.
Sur le plan technique, Sherlock est un outil indispensable à de nombreux-es collaborateur-ices de GE HealthCare ; mais il est aussi assez complexe, et développé par des programmeur-euses qui n’ont pas le temps de gérer la communication, la documentation, et autres contenus annexes qui facilitent l’accès à l’application.
J’ai donc pris en main cette facette du projet.
Construire une structure
La cible de notre communication est un groupe d’employé-es très occupé-es, qui reçoivent des dizaines d’email, et veulent pouvoir aller droit au but. Il ne s’agit donc pas d’envoyer des messages marketing tous les quatre matins, mais d’avoir une communication simple, directe et surtout utile.
J’organise la communication de Sherlock autour de deux piliers :
- Communication ponctuelle : un email lors d’événements importants (mise à jour, changement de mode de connexion, démo ou formation…)
- Communication récurrente : une newsletter mensuelle (points clés de l’évolution du projet, tips d’utilisation, retransmission des éventuelles nouvelles du mois) et une permanence de support technique bi-hebdomadaire
Dans les deux cas, il faut commencer par créer une structure, un template à suivre pour chaque message. D’abord pour avoir une cohérence générale sur toutes les communications, ensuite pour éviter de perdre du temps lors de communications d’urgence (mise à jour d’un patch, interruption de service…), et pouvoir informer la communauté de manière efficace.
La communication ponctuelle
Exemple de template d’email
Ici, pas besoin de réinventer la roue : il faut surtout donner envie aux destinataires d’ouvrir les emails.
Identifier clairement les emails concernant Sherlock :
- Toujours le même expéditeur : création d’une adresse d’envoi « Sherlock Communication » dédiée
- Rappel visuel : header d’email avec le logo de l’application, et un rappel de l’objet
Donner l’information principale très rapidement :
- Contenu résumé dès la première phrase de l’email
- Accroches visuelles : usage d’encadrés et de boutons pour attirer l’attention sur les informations importantes (résumé des features d’une mise à jour, appel à action…)
Un deuxième objectif important est de relier les destinataires à l’écosystème de Sherlock.
- Boite mail partagée : en répondant à l’adresse email Sherlock Communication, les utilisateur-ices écrivent d’un coup à toute l’équipe Sherlock
- Liste de liens : chaque email inclue systématiquement un lien vers la documentation et vers le forum de la communauté
Il y a eu une augmentation notable des contacts avec la communauté: elle n’est plus laissée à elle-même devant l’application, mais a une ligne directe pour nous joindre en cas de question.
Troisièmement, nous avons professionnalisé la méthode d’envoi en utilisant un gestionnaire d’emailing open-source, ListMonk. Cela nous a apporté de nombreux avantages:
- Statistiques d’ouverture et de lecture des emails
- Possibilité de dupliquer un ancien email pour optimiser la création
- Gestion de plusieurs listes d’envoi auxquelles les destinataires peuvent s’inscrire et se désinscrire
La communication récurrente
Là où les emails ponctuels servent à informer de nouvelles importantes, la newsletter mensuelle sert à maintenir un contact régulier avec les utilisateur-ices.
Elle n’est pas lue par tout le monde, et on peut s’en désabonner (contrairement aux emails ponctuels) ; il s’agit vraiment d’une ressource supplémentaire proposée à la communauté, que les gens peuvent choisir ou non d’exploiter.
Chaque newsletter suit la structure suivante :
- Edito : un mot de l’équipe et un résumé des activités du mois
- Le mois en chiffres : statistiques d’utilisation de Sherlock sur la période
- Problèmes corrigés du mois : liste des bugs signalés et corrigés
- Autour de Sherlock : informations diverses, par exemple de nouvelles règles de compliance, de la documentation mise à jour, l’annonce d’un wébinaire, un appel à beta-testeur-euses…
- Elémentaire mon cher Watson : trucs & astuces, et réponses à des questions fréquentes sur l’utilisation de certaines fonctionnalités
Certaines rubriques apparaissent une fois tous les quelques mois :
- Annonce de mise à jour prochaine
- Détail de mise à jour récente : résumé des fonctionnalités, lien vers le changelog, annonce de démo
- Roadmap : en début de trimestre, on annonce les grands projets qui vont être prioritaires sur les prochains mois
 |  |
 |  |
En plus de la newsletter, des permanences de support techniques ont été créées : les Office Hours. Deux fois par semaine, les utilisateur-ices peuvent se connecter dans une réunion Teams, pour poser leurs questions, demander de l’aide, obtenir de la documentation…
Re-colorer la communication
Pour habiller ces messages, il a été nécessaire de créer une identité graphique pour Sherlock.
Un premier travail graphique avait été fait plusieurs années plus tôt, directement sur l’application, mais il n’y avait aucun contenu correspondant applicable aux communications.
Je me charge donc de créer une charte et des éléments graphiques, à partir des éléments clé de l’identité visuelle de l’application: la forme hexagonale du logo, la bulle, la loupe, et les couleurs bleu et blanc.
 |  |  |
Exemples d’éléments graphiques combinables dans les communications
Former et informer
Une autre de mes responsabilités était la création de contenu autour de Sherlock.
- Remise à jour de la documentation, qui datait de plusieurs années et était en partie obsolète
- Création de tutoriels vidéo pour les fonctionnalités principales
- Réalisation de supports de formation
- Organisation de wébinaires (formation, démo, onboarding…)
- Réalisation de contenu marketing pour introduire Sherlock auprès de collègues qui ne l’utilisent pas encore
Dans cette facette du projet, il est nécéssaire d’être pédagogue et capable de vulgarisation. L’outil Sherlock est très technique, et il faut pouvoir faire le pont entre l’équipe technique qui a développé les fonctionnalités, et les employé-es qui vont l’utiliser au quotidien pour des besoins métier très spécifiques.
Retour d’expérience
Loin d’être une simple opération cosmétique, cette remise à jour des communications a permis de recréer un dialogue avec la communauté Sherlock. L’équipe a remarqué une réelle augmentation des feedbacks de la part des utilisateur-ices depuis que nous avons rendu la communication plus claire. Iels sont plus impliqué-es dans la vie de Sherlock et plus à même de contacter l’équipe pour des questions, des suggestions…
En retour, cela nous aide dans le travail de développement, car nous sommes au plus proche des utilisateur-ices et nous comprenons mieux leurs besoins. C’est du gagnant-gagnant, qui rappelle une fois de plus l’importance d’une communication bien ficelée même dans un projet technique.