Des audiences, cas d’usage et équipes différents, mais aucune base UX commune.
5chatbots
Étude de cas

LE PROJET
Probayes exploitait plusieurs chatbots au sein du Groupe La Poste, répondant à des besoins internes comme externes : support aux collaborateurs, assistance juridique, signalement d’incidents ou encore service client.
Chaque chatbot avait évolué séparément, avec ses propres fonctionnalités, patterns d’interaction et conventions rédactionnelles. Probayes souhaitait créer une base UX commune capable de guider les évolutions futures sans imposer la même expérience à tous les produits.
J’étais Lead UX/UI Designer sur la mission, aux côtés d’une UX Designer. J’organisais le travail Design, maintenais la roadmap du projet, pilotais les principaux ateliers et présentations, et étais responsable de la cohérence globale de la direction Design.
LA PROBLÉMATIQUE
Des audiences, cas d’usage et équipes différents, mais aucune base UX commune.
5chatbots
01Diagnostic
Avant de standardiser quoi que ce soit, nous devions comprendre quels problèmes étaient spécifiques à chaque chatbot et lesquels pouvaient devenir des principes communs.
Nous avons combiné un audit des cinq expériences avec un benchmark, 10 entretiens avec les responsables des chatbots et 8 tests utilisateurs menés sur des chatbots internes et orientés clients.
Cela nous a permis d’obtenir une vision plus globale du problème avant de définir des règles communes : qualité UX existante, comportements utilisateurs, besoins métier et pratiques déjà mises en place par chaque équipe.





02Synthèse
Chaque problème récurrent était analysé sous deux angles : d’abord comme un problème propre à un produit, puis comme un pattern pouvant justifier un principe commun.
Introduction trop dense
Principe d’onboarding
Réponses trop longues
Principe de rythme conversationnel
Incompréhensions répétées
Principe de récupération et d’escalade
Parcours de sortie peu clair
Redirection plus claire vers un humain ou un canal alternatif
03Alignement
Je voulais que les responsables des cinq chatbots participent directement à la construction des guidelines. Ils avaient la vision la plus proche de la manière dont chaque chatbot était utilisé au quotidien, des problèmes récurrents rencontrés et des retours remontés par les utilisateurs. Leur expertise était essentielle pour challenger notre recherche et s’assurer que le futur framework répondait à de véritables besoins opérationnels.
Pour clôturer la phase de recherche, j’ai organisé une journée complète d’ateliers autour de deux sujets complémentaires.
L’atelier fonctionnel s’appuyait sur environ 30 cartes de fonctionnalités afin de comparer les cas d’usage, faire émerger les besoins récurrents et identifier ce qui pouvait être mutualisé entre les cinq chatbots.
L’atelier autour de l’identité portait sur la personnalité, le ton de voix et les Do’s & Don’ts conversationnels. Il nous permettait d’explorer comment créer davantage de cohérence sans effacer ce qui rendait chaque chatbot spécifique.
Ces ateliers nous ont apporté un ensemble d’insights plus riche, mais pas une solution prête à l’emploi. Nous avons ensuite ramené ces enseignements dans le travail Design afin d’analyser les patterns, prioriser ce qui devait devenir commun et les transformer en une direction cohérente pour les guidelines.




Contributions des parties prenantes, puis synthèse Design
Contraintes, besoins et pratiques quotidiennes des responsables de chatbots.
Audit, benchmark, entretiens et tests utilisateurs.
Structuration, arbitrage et cohérence entre les cinq produits.
Formalisées par l’équipe Design : un vote en atelier ne constitue jamais à lui seul une décision de design.
04Framework
Après plusieurs mois, le problème n’était plus de trouver des difficultés : nous en avions identifié beaucoup.
Le véritable enjeu était de transformer les enseignements issus de cinq produits, des utilisateurs, des responsables de chatbots, du benchmark et des ateliers en une base réellement réutilisable par les équipes.
Nous avons structuré des principes communs autour des moments clés d’une expérience conversationnelle : onboarding, premières actions, conversation, erreurs, redirection vers un humain, feedback et fin de conversation.
L’objectif n’était pas de rendre les cinq produits identiques, mais de définir les endroits où la cohérence apportait de la valeur et ceux où les besoins spécifiques devaient être conservés.
01
Audit, benchmark, entretiens, tests et résultats des ateliers.
02
Problèmes apparaissant dans plusieurs produits.
03
Règles UX et rédactionnelles définies une fois pour l’ensemble des chatbots.
04
Des documents que les équipes pouvaient appliquer et adapter à leur propre chatbot.

05Handoff
Nous avons volontairement séparé le framework en plusieurs livrables ciblés plutôt que de produire un document unique et exhaustif. Cela rendait les recommandations plus faciles à parcourir, à maintenir et à appliquer dans différents contextes de chatbot.
Le travail a d’abord été présenté et affiné avec l’équipe projet, puis partagé avec l’ensemble de l’équipe Probayes. Il donnait aux différentes équipes chatbot une base commune qu’elles pouvaient réutiliser et adapter dans le temps.
Livrables finaux

06Réflexion
La partie la plus précieuse de ce projet n’a pas été de définir un chatbot idéal, mais d’apprendre à transformer des enseignements fragmentés issus de cinq produits différents en un framework commun sans effacer leurs différences.
Ce projet a fait évoluer ma manière de penser la cohérence entre plusieurs produits. Être cohérent ne signifie pas rendre toutes les expériences identiques. Il s’agit de donner aux équipes une base commune suffisamment solide pour leur permettre de réutiliser des patterns, de prendre de meilleures décisions et de continuer à adapter l’expérience à leurs propres utilisateurs et à leur contexte.
Les guidelines et le template de référence étaient notre manière de rendre cette base concrète et directement exploitable.
Si je prolongeais la mission aujourd’hui, j’accompagnerais au moins l’un des chatbots dans les étapes suivantes : test de la nouvelle expérience, collaboration Design–Dev, QA, mise en production puis observation post-lancement.
Cela permettrait de boucler la démarche entre la définition d’un framework réutilisable et la validation de son efficacité dans un produit réel.