Reconstruire l'application patient d'une société de téléconsultation en 30 jours

Mission de trois mois (avril à juillet 2026) pour une société de santé numérique qui équipe des pharmacies de cabines de téléconsultation. Premier product designer de l'entreprise, j'ai reconstruit l'application patient avec un tech lead et deux développeurs, tout en posant un design system, un système de gestion produit et le cadre de conception d'un assistant IA qui n'a pas le droit de diagnostiquer.

Le modèle économique dépend du nombre de consultations réellement lancées. Un patient qui entre dans le tunnel et n'en sort pas a déjà coûté son acquisition. Or, sur un an, 80 % des patients ne consultent qu'une fois : le parcours ne donne aucune raison de revenir une fois l'ordonnance remise. L'organisation n'aidait pas : aucune fonction design, une bibliothèque de composants gelée depuis plus d'un an, un pilotage produit éclaté entre plusieurs outils, une équipe produit en réduction et un budget très contraint. Le 15 juin, la direction fixe deux priorités, le volume de consultations et l'application mobile, avec une soumission aux stores le 15 juillet.

Une revue de l'application existante, début juin, relève quatre problèmes qui ne se traitent pas par un correctif : une session fragmentée (connecté à l'application, déconnecté de la consultation), une double navigation, un accueil qui se réorganise selon les objets connectés actifs, et un tunnel de 8 à 13 écrans avec un écran de saisie de mutuelle que 3 % des patients réussissaient à remplir. L'architecture suivait les fonctionnalités empilées plutôt que le parcours. Déshabiller la coquille aurait conservé la vue web embarquée, donc la double session : la reconstruction s'est imposée.

J'ai retiré ce qui séduisait le plus. La première version recentre l'application sur la consultation en ligne : sortent du périmètre les objets connectés, les métriques de santé, l'analyse par IA et l'abonnement. Raison économique : la consultation est remboursée et monétisée au volume. Raison réglementaire : ces briques exposaient le produit à une requalification en dispositif médical, avec une certification de 18 à 36 mois face à une échéance de 30 jours. J'ai porté ce retrait devant une direction qui tenait à ces fonctions.

La mutuelle sort du tunnel au profit d'une avance de frais et d'une explication claire du remboursement. Un écran dont le taux d'échec approche 100 % ne collecte pas une donnée, il fabrique des abandons. Ma première hypothèse, repousser l'authentification jusqu'à la salle d'attente, a été abandonnée et documentée : l'appel aux droits de l'Assurance Maladie exige une identification avant la mise en relation.

L'assistant IA n'a pas le droit de diagnostiquer. Plutôt qu'une clause dans les conditions d'utilisation, la limite est visible dans l'interface : bandeau de périmètre permanent, structure de réponse imposée (information, contexte, action), escalade vers un médecin déclenchée par le contenu de la conversation et jamais par un compteur, refus conçu comme un parcours avec une sortie réelle. Deux boutons d'accueil (« décrire un symptôme », « comprendre une ordonnance ») ont été retirés : une affordance est une promesse, et celle-ci annonçait un acte médical. Le cadrage non médical a été validé par la DPO, avec anonymisation des données avant envoi au modèle.

Sur le design system, la migration complète de la bibliothèque Angular existante était intenable sans équipe design ni budget. J'ai construit un système neuf en parallèle, avec un vocabulaire de tokens commun, pour tout ce qui est nouveau : deux dépôts, près de 90 composants, 12 rampes de couleur, une échelle typographique à 13 niveaux et des mises en page pour trois contextes (bureau, mobile, tablette de cabine). Coût assumé : deux verts de marque coexistent un temps, avec une règle de préséance écrite. Un pack de skills Claude Code génère du code aligné sur le système : sans équipe design, la gouvernance passe par l'outil plutôt que par le document.

L'application patient a été reconstruite en React Native en réutilisant les briques natives de la consultation. Maquettes présentées aux développeurs 48 heures après l'arbitrage, sprints d'une semaine avec une démo testable à chaque fin, trois builds en deux semaines. La spécification compte 7 epics, 24 user stories et huit sections d'écrans avec leurs quatre états (vide, chargement, données, erreur). En salle d'attente, jamais de temps d'attente affiché : la position varie en continu, et un chiffre figé mentirait et ruinerait la confiance dans le reste de l'écran.

Côté pilotage produit, j'ai audité six bases (trois échelles de priorité incompatibles), migré le suivi de Jira vers Notion en quatre bases reliées par une seule chaîne, requalifié 92 demandes héritées et ouvert un formulaire d'entrée à toute l'entreprise. Le modèle a été éprouvé sur quinze situations réelles avant déploiement : quatre passent, onze coincent, sept correctifs. Passation documentée à une PO junior. Un deck de vision de dix slides présenté au comité de direction a obtenu deux arbitrages : une seule application avec soin et prévention séquencés, et un ordre de priorité entre programmes, pharmacie et objets connectés.

Ce qui n'est pas mesuré : l'application n'était pas encore publiée à mon départ, le design system n'a pas de mesure d'adoption, le système de gestion produit n'avait vécu qu'une semaine et l'assistant n'a jamais été ouvert au public. La refonte du tunnel reste une hypothèse argumentée tant que la complétion par étape n'est pas suivie. Restaient ouverts à la passation : la qualification réglementaire exacte de l'application, un bug de session qui déconnecte l'utilisateur quinze minutes après une consultation, et une authentification sans mot de passe jamais testée en production.

Ce que je ferais autrement : poser la mesure avant la refonte du tunnel (complétion par étape, abandon, temps d'accompagnement en officine), obtenir dès la première semaine les confirmations techniques dont dépendait la fiche store, instrumenter l'adoption du design system dès sa première version, et écrire la gouvernance du système de gestion produit avant de configurer l'outil.