AMME — Trois métiers aux besoins opposés, et un brief qu'il a fallu réécrire

Le brief : connecter trois métiers dans un écosystème

En France, la coordination des soins infirmiers à domicile repose encore largement sur l'informel : SMS entre infirmières, ordonnances papier, appels aux pharmacies. AMME voulait structurer tout cela dans une plateforme unique. Le défi n'était pas de digitaliser un processus existant, mais d'en créer un là où il n'y en avait jamais eu, entre des métiers très différents.

On m'a fait intervenir pour la conception et le cadrage : concevoir le produit, le spécifier, poser son architecture. Le développement et le lancement relevaient du client. Ce que montre cette étude, c'est donc ma façon de cadrer un problème et de décider — pas un produit en production avec ses métriques.

Trois métiers, trois logiques qui se contredisent

Pour comprendre ce que devait être ce produit, j'ai mené des entretiens avec les trois métiers concernés : infirmières, pharmaciennes et patients. Il en est ressorti une tension de fond — leurs besoins se contredisent en partie.

Le patient veut de la simplicité, aucun effort. L'infirmière a besoin de l'inverse : un outil dense et rapide, qui ne lui fait jamais répéter deux fois la même action — avec une nuance supplémentaire, entre exercice libéral et salarié, à gérer dans une seule interface. La pharmacie, elle, exige fiabilité et précision absolues, ce qui impose des contraintes aux deux autres.

Concevoir ici, ce n'était pas juxtaposer trois interfaces. C'était accepter que chaque décision a un coût quelque part. Mais avant d'arriver à ces arbitrages, une question plus en amont s'imposait : est-ce qu'on résolvait le bon problème ?

Le vrai problème n'était pas celui du brief : sortir de l'écosystème

Le brief partait d'un écosystème interdépendant : patient, infirmière et pharmacie connectés dans une même boucle. J'ai défendu l'inverse — un produit autonome d'abord —, et c'est la décision dont je suis le plus fier sur ce projet.

Lancer un écosystème, c'est devoir convaincre trois acteurs en même temps. Trois problèmes concrets en découlent.

Le premier, c'est l'effet poule et œuf, à trois cette fois. La pharmacie ne s'inscrit pas tant qu'aucune infirmière du secteur n'utilise l'outil ; l'infirmière ne s'inscrit pas tant qu'aucune pharmacie ne reçoit ses ordonnances ; le patient n'y vient que si son infirmière le lui demande. Personne ne bouge en premier.

Le troisième est réglementaire. Faire dialoguer pharmacie, infirmière et Sécurité sociale impose des certifications HDS de bout en bout, et des délais qui s'allongent à chaque acteur ajouté. Un produit autonome peut être certifié seul, plus vite.

À ces arguments structurels s'ajoutait une logique de marché : des produits interdépendants forment un édifice fragile — si l'un rate son lancement, tout l'ensemble s'effondre. Arriver sur le marché avec un seul produit, qui crée de la valeur immédiatement, est un pari bien plus sûr.

Il a fallu plusieurs séances de cadrage pour faire adopter ce cap. La décision finale : une application qui centralise et apporte de la valeur même si les autres acteurs ne sont pas encore là, les fonctions d'écosystème venant ensuite comme des couches additionnelles. Ça a réorienté toute la conception qui a suivi.

L'ordonnance comme point d'entrée unique

C'est la décision qui sert les trois métiers à la fois, et celle qui incarne le mieux la promesse du produit. Aujourd'hui l'ordonnance circule en papier et chacun la ressaisit. J'ai défendu le scan unique : l'ordonnance est capturée une fois, puis ses informations sont transmises automatiquement à l'infirmière et à la pharmacie.

Plus complexe à développer, mais c'était le seul choix cohérent avec la promesse : ne pas digitaliser le désordre, le supprimer. Simple pour le patient, gain de temps pour l'infirmière, fiabilité pour la pharmacie — une seule décision, trois besoins servis.

Un calendrier qui s'adapte au contexte, pas deux interfaces

Côté infirmière, j'aurais pu faire deux interfaces, une libérale et une salariée. Plus simple, mais lourd à maintenir et faux dans l'esprit : une infirmière reste une infirmière, c'est son contexte qui change.

J'ai donc conçu un seul calendrier avec un filtre. Par défaut elle voit « Tous », peut basculer sur « Moi », et les rendez-vous des collègues sont identifiés visuellement quand elle travaille en cabinet. Les statuts sont codés par couleur pour une lecture rapide. Le même écran sert une libérale seule et une salariée en cabinet de cinq.

Une interface pharmacie dense, par choix

Dans un produit unifié, on est tenté d'harmoniser visuellement les interfaces. Pour la pharmacie, ç'aurait été une erreur. J'ai conçu une vue kanban sur tablette : trois colonnes (en attente, prêtes, récupérées), des cartes colorées selon le paiement, l'ordonnance lisible directement, deux actions principales.

C'est l'écran le plus dense du produit, et c'est voulu : les pharmaciennes ont l'expertise pour le lire et en ont besoin. Le simplifier, ç'aurait été en faire un outil qu'elles auraient contourné dès la première semaine.

Le périmètre couvrait aussi un backoffice national (pilotage du réseau, statistiques régionales, planning, RH), un onboarding pour cinq profils avec leurs vérifications propres (RPPS, SIRET, n° de Sécurité sociale) et un outil de tournée — autant de chantiers que je détaille volontiers de vive voix.

Valider et itérer avec le client et les experts métier

Le travail ne s'est pas arrêté aux maquettes. J'ai fait valider les interfaces par le client et par des experts métier, lors de sessions de test, puis itéré sur l'ergonomie, les fonctionnalités et la compréhension des écrans. Dans un produit où une infirmière manipule une ordonnance ou un numéro de Sécurité sociale, vérifier qu'une interface n'est pas seulement utilisable mais comprise n'est pas optionnel.

La conformité comme outil de conception

Intégrer le RGPD et l'HDS dès la conception, plutôt qu'en fin de projet, a orienté beaucoup de décisions : accès par rôle, données limitées au strict nécessaire pour chaque interface, consentements clairs, signature des feuilles de soins via carte CPS. Quand on n'affiche que ce dont l'utilisateur a besoin, l'interface devient plus claire, pas moins.

Ce que j'en retire

Concevoir dans un secteur régulé demande une honnêteté que le B2C n'exige pas. Quand une interface manipule un numéro de Sécurité sociale ou une ordonnance, il ne suffit pas que ce soit clair : il faut que l'utilisateur comprenne ce qu'il fait et pourquoi ça compte. C'est plus dur à obtenir.

J'ai aussi appris à remettre en question un brief, même venu d'en haut. Sortir du modèle écosystème pour aller vers un produit autonome remettait en cause la vision de départ, mais c'était nécessaire. Une partie du travail, c'est de savoir dire que le bon problème n'est pas celui qu'on vous a donné — et de le démontrer plutôt que de l'affirmer.

S'il était sorti, l'indicateur que j'aurais suivi en priorité n'aurait pas été le nombre d'infirmières inscrites, mais leur usage dans la durée : une infirmière qui reste active semaine après semaine prouve que le produit autonome crée de la valeur seul — c'était tout le pari. Un second signal aurait confirmé la stratégie de couches : la fréquence à laquelle une infirmière active fait entrer un deuxième acteur, sa pharmacie ou ses patients.

Enfin, un projet qui ne sort pas apprend autant qu'un projet livré. Parfois plus, parce qu'on ne peut pas se cacher derrière le résultat.