AlayaCare

En tant que gestionnaire de produit sénior et responsable de la réflexion sur le design système au sein de l'équipe « Connective Tissue » chez AlayaCare, notre mandat était de faire en sorte qu'AlayaCare ressemble à un produit unique et cohérent plutôt qu'à un assemblage de modules. Je collaborais quotidiennement avec trois développeurs front-end, et ensemble, nous avons livré les changements qui unifient le produit.

Nous n'étions pas responsables d'un flux de travail clinique ou de planification en particulier. Notre terrain de jeu se trouvait plutôt à l'intersection de ceux-ci : les pages d'aperçu sur lesquelles les utilisateurs atterrissent, la navigation globale qui leur permet de s'orienter, les notes qu'ils rédigent à travers la plateforme et le système de design (Design System) sur lequel s'appuient toutes les équipes. C'est le genre de travail qui passe inaperçu quand c'est bien fait, mais qui devient impossible à ignorer quand ça cloche.

Cette étude de cas présente mes constats, les actions que j'ai menées et les retombées concrètes. Les résultats vont d'un gain d'un point complet de CSAT sur notre page phare jusqu'aux bases posées pour rendre notre Design System exploitable par des agents IA.

Le problème

Les utilisateurs nous disaient, de différentes manières, qu'AlayaCare donnait l'impression d'être plusieurs produits cousus ensemble. J'ai constaté cette friction à quatre niveaux.

Le premier se situait au niveau des pages d'aperçu. L'Aperçu du client était l'une de nos pages les plus consultées; pourtant, l'information était éparpillée dans plusieurs onglets, l'historique des statuts, l'évaluation des risques et le suivi des contacts vivant chacun dans leur coin. Lorsque nous avons mesuré la satisfaction, le CSAT plafonnait à 2,7 sur 5. Comme les aperçus Employé, Établissement et Fournisseur partageaient le même modèle, chaque incohérence était multipliée par quatre.

Le deuxième était la navigation globale. Les gens devaient d'abord comprendre notre structure de produit interne pour arriver à trouver leurs tâches, et les rapports comme les outils de données étaient dispersés aux quatre coins de l'application.

Le troisième concernait les notes. Les notes clients, les notes d'évolution, les notes de soignants et les notes de visite avaient toutes leurs propres écrans et leurs propres règles. Certaines configurations comptaient plus de 60 sujets de notes de soignants. Une telle fragmentation multipliait les clics et favorisait les doublons.

Le quatrième était plus récent : notre système de design (Design System). Les gestionnaires de produit et les designers avaient commencé à prototyper avec des agents IA, mais le premier jet inventait souvent des éléments d'interface, mélangeait des composants non approuvés et manquait de cohérence d'un prompt à l'autre. Deux exécutions de la même intention ne donnaient que rarement un résultat conforme à AlayaCare Cloud. En tant que coresponsable du ADS, j'ai réalisé que le Design System avait été conçu pour des humains lisant de la documentation, et non pour être ingéré par un agent. Chaque dérive dans les prototypes représentait une incohérence que les équipes de design et de front-end devaient corriger par la suite.

La solution

Mon approche a été de consolider la couche de liaison : corriger les patrons réutilisables une bonne fois pour toutes, puis les déployer partout. Au quotidien, cela s'est traduit par quatre chantiers prioritaires.

Améliorer les pages d'aperçu

J'ai commencé par l'Aperçu du client, car c'était notre page maîtresse et celle qui affichait le plus faible score. J'ai travaillé de concert avec le design, l'ingénierie et le succès client pour réorganiser les onglets dispersés, introduire des cartes claires pour les infos client, les contacts, les risques et les services, regrouper les notes clients, d'évolution et de soignants dans une même section, et ajouter la possibilité d'épingler les notes de coordination. Nous avons misé sur le développement assisté par IA dans Cursor pour livrer plus rapidement. J'ai planifié un déploiement progressif sur adhésion volontaire (opt-in), accompagné d'un sondage CSAT et d'un guide d'intégration dans Pendo, afin de recueillir les commentaires des utilisateurs au fil des itérations. Puisque les profils Employé, Établissement et Fournisseur partageaient la même structure, le patron a ensuite été appliqué à ces pages.

La navigation globale

J'ai piloté une refonte de l'interface de navigation avec un menu latéral gauche rétractable, le déplacement des Paramètres hors de la navigation quotidienne, et une nouvelle section Analytique regroupant les rapports et les outils de données. Je me suis assuré que les autorisations demeuraient intactes et que les anciennes routes redirigeaient adéquatement, afin de ne briser aucun signet. La nouvelle interface a été déployée en production, dans les environnements de développement et dans les prototypes. La communauté a chaudement accueilli l'espace d'écran ainsi récupéré et le nouvel emplacement des Paramètres, tout en nous signalant que les environnements comme l'UAT nécessitaient un repère visuel plus distinct, ce que nous avons consigné dans notre carnet pour suivi.

Unifier les notes

J'ai travaillé à réduire le nombre d'écrans et d'anciens parcours pour les notes clients, d'évolution, de soignants et de visite, en commençant par un dialogue unique « Ajouter une note » et un seul endroit pour configurer les types de notes. Cette première étape était une modification strictement front-end, sans changement aux API. J'ai recueilli les premières réactions de la communauté pour les partager avec l'équipe. Les utilisateurs ont apprécié qu'on encadre la création libre de sujets, mais un menu déroulant trop long et des clics supplémentaires pour les notes d'évolution devaient être corrigés avant la disponibilité générale; nous avons donc créé des tickets pour régler la situation.

Optimiser le Design System pour le prototypage par IA

Mon principe de base était simple : un agent IA ne peut être que le reflet du vocabulaire qu'on lui fournit. En phase un, j'ai défini le problème et les critères de succès. Avec l'équipe d'ingénierie, nous avons bâti un paquet ADS lisible par machine comprenant la documentation des composants et les tokens, des règles faisant des composants ADS le seul vocabulaire d'interface autorisé, ainsi qu'une validation automatique qui rejetait tout prototype utilisant un élément hors norme. Les manques étaient documentés, pas inventés. Nous avons testé le tout en soumettant les mêmes prompts à différents gestionnaires de produit et en comparant le choix des composants.

J'ai aussi amorcé un audit DATAGRID des tableaux générés par IA afin d'identifier les écarts entre prototypes, avec l'objectif d'intégrer ces règles directement dans l'outil de prototypage pour que les résultats les respectent par défaut. Pour donner aux agents une vision claire de ce qui constitue une bonne pratique, nous avons commencé à ajouter des recettes réutilisables, comme un patron de filtrage standard. Ensuite, j'ai cadré des « blocs ADS » réutilisables — de petites compositions comme un en-tête de page de liste ou un en-tête de profil client — pour que l'agent sélectionne un bloc prêt à l'emploi plutôt que de tout reconstruire à partir des atomes à chaque fois. En parallèle des outils, nous avons instauré des rituels de produit : des revues de produit hebdomadaires par domaine et une démo mensuelle des prototypes interdomaines, pour intercepter toute dérive avant la mise en production.

Résultats

Le résultat le plus frappant a été observé sur l'Aperçu du client. Après le lancement de la refonte en mars 2026, le CSAT est passé de 2,7 à 3,7 sur 5, soit un bond d'un point complet — exactement l'objectif que nous nous étions fixé. Cela confirmait que la page répondait désormais aux questions des utilisateurs sans qu'ils aient à fouiller d'un onglet à l'autre. Le patron a ensuite été réutilisé sur les autres pages de profil, rentabilisant ainsi un investissement unique pour bonifier plusieurs expériences et nous offrir une base cohérente.

Pour la navigation et les notes, le projet en était à une étape plus préliminaire. La nouvelle interface de navigation a été déployée en production, dans les environnements de développement et dans les prototypes, nous offrant une assise solide pour la suite des travaux de routage. Les notes unifiées bénéficiaient d'une orientation claire et leurs premiers jalons progressaient bien, avec une migration plus vaste prévue ultérieurement. Des tickets étaient en place pour corriger les irritants relevés avant la sortie générale en novembre, et j'avais prévu d'intégrer une évaluation CSAT Pendo pour comparer objectivement la nouvelle expérience de prise de notes à l'ancienne avec des données réelles.

Du côté du Design System, le gain s'est mesuré dans la qualité des livrables. Dès lors que l'agent ne pouvait puiser que dans les composants ADS, et qu'une vérification bloquait toute autre tentative, un même brief générait un ensemble cohérent de composants au lieu d'un écran inventé de toutes pièces. Les prototypes sont restés beaucoup plus fidèles à ce que nous livrons réellement, ce qui a permis au design et au front-end de perdre beaucoup moins de temps à rectifier les écarts. Avec les blocs, j'anticipais un prototypage accéléré et une consommation réduite de tokens, l'agent assemblant les pages à partir de morceaux préconçus plutôt que de les régénérer de zéro. J'avais d'ailleurs prévu de mesurer ces gains concrètement plutôt que de simplement les présumer.

La grande leçon que je tire de cette expérience, c'est que la qualité d'un produit se joue souvent dans les espaces entre les fonctionnalités. Lorsque les utilisateurs reconnaissent les patrons et naviguent en toute confiance d'une section à l'autre, le produit paraît simple, même si les flux de travail sous-jacents sont complexes. Rendre un Design System lisible par des agents a permis d'étendre cette même philosophie à notre manière de bâtir nos produits.