Satelia

Contexte

Satelia est une healthtech française qui développe des dispositifs médicaux numériques de suivi de patients à distance. L'idée centrale : permettre aux équipes médicales de maintenir un lien structuré avec leurs patients entre les consultations, via des questionnaires, du monitoring et des alertes cliniques.

J'ai rejoint l'entreprise parmi les premières recrues côté produit, d'abord en tant que Product Designer, puis en tant que Product Manager. Sur huit ans, j'ai traversé deux états très différents de la même structure : une petite équipe où tout s'improvisait avec le CEO cofondateur, puis une organisation en croissance qui approchait la centaine de collaborateurs avec une équipe produit de sept personnes.

Le produit s'articule autour de deux interfaces distinctes, avec des logiques d'usage radicalement différentes. D'un côté, une application mobile destinée aux patients (plus de dix mille utilisateurs actifs) qui accompagne leur quotidien médical avec des contenus d'éducation thérapeutique et des parcours de suivi personnalisés. De l'autre, une interface métier à destination des professionnels de santé (cardiologues, infirmières, secrétaires, équipes hospitalières) déployée dans plus de trois cents centres cliniques, hôpitaux et cabinets libéraux.

Concevoir pour ces deux audiences simultanément est une contrainte permanente : ce qui est lisible pour un cardiologue habitué à des données denses n'est pas ce dont un patient âgé a besoin à 7h du matin pour répondre à son questionnaire.

Problème

Le problème initial était posé clairement : les équipes médicales n'avaient pas de moyen structuré de suivre l'état de leurs patients entre deux rendez-vous. Les signaux d'alerte reposaient sur les patients eux-mêmes, les données restaient éparpillées, et les équipes soignantes travaillaient souvent sans visibilité sur ce qui se passait à domicile.

Avec le temps, ce que j'ai d'abord vécu comme un seul produit s'est révélé être une suite. La cardiologie était le premier terrain. L'oncologie (suivi des traitements pour cancer) et l'ambulatoire (chirurgie ambulatoire) ont pris la forme de produits distincts, chacun avec ses propres flux cliniques, ses propres rôles, ses propres contraintes réglementaires et ses propres utilisateurs. Le point commun : la même infrastructure, la même plateforme technique, mais des logiques métier et des parcours suffisamment différents pour ne pas pouvoir simplement copier ce qui existait.

En parallèle, la croissance de l'entreprise a généré un deuxième problème : plus il y avait d'utilisateurs et de retours, plus il devenait difficile de distinguer ce qui relève d'un vrai besoin produit de ce qui est du bruit. Structurer cette connaissance est progressivement devenu un sujet à part entière.

Démarche

La majorité de mon travail s'est construite autour d'un principe simple : comprendre le terrain avant de concevoir des solutions. Dans un contexte médical, les utilisateurs font face à des situations critiques, des workflows contraints et des responsabilités lourdes. On ne peut pas se permettre de concevoir à l'aveugle.

Cela passait par de l'immersion dans les pratiques des équipes soignantes, des entretiens réguliers avec les patients, et une attention constante à la distance entre ce que les utilisateurs disent vouloir et ce dont ils ont réellement besoin. La distinction n'est pas toujours évidente, surtout dans un domaine où les professionnels de santé ont des habitudes ancrées et peu de temps pour exprimer des besoins abstraits.

J'ai aussi fait le choix, dès le début, de travailler en étroite collaboration avec les équipes techniques. S'asseoir à côté des développeurs, comprendre leurs contraintes et leur façon de travailler, apprendre à ajuster les choix de conception en fonction de ce qui est réellement faisable et souhaitable. La maquette Figma n'est pas la source de vérité : c'est le code. Cette conviction a changé ma façon de spécifier, de prioriser et d'arbitrer. Elle a aussi rendu les échanges plus directs et les livraisons plus fiables.

À une période charnière, quand le produit s'est mis à accumuler de la complexité avec plusieurs spécialités, plusieurs rôles et plusieurs points d'entrée, j'ai co-animé un atelier de service blueprint. L'objectif était de mettre à plat l'ensemble des parcours : patients, médecins, infirmières, secrétaires, équipes de support, back-office. Cette méthode permet de rendre visible ce qui se passe en coulisse : les actions du service, les moments de rupture, les dépendances entre acteurs, articulés avec l'expérience vécue par l'utilisateur.

Le résultat a été un outil de référence partagé pour l'équipe produit, permettant d'ancrer les décisions dans une vision systémique plutôt que de corriger des symptômes isolés. C'est aussi ce travail qui a mis en évidence des angles morts que personne n'avait formalisés : des moments de friction entre acteurs qui n'apparaissaient pas dans les remontées terrain habituelles.

Ce que j'ai fait

J'ai travaillé sur l'ensemble du cycle produit, de la définition des besoins jusqu'au suivi post-lancement. Travailler sur un dispositif médical au sens réglementaire impose une rigueur que d'autres contextes ne demandent pas. Les spécifications fonctionnelles doivent être précises, à jour, et traçables tout au long de l'évolution du produit. Une formulation ambiguë ne génère pas seulement un bug : elle peut produire un comportement cliniquement incorrect. J'ai appris à maintenir cette rigueur sans sacrifier la vélocité, en trouvant des équilibres entre ce que la réglementation exige et ce que le rythme d'une startup impose.

Sur le fond, j'ai contribué à plusieurs chantiers transverses : des mécanismes de délégation entre équipes médicales, des systèmes de gestion d'alertes et de cas particuliers, des workflows de questionnaires adaptés aux spécificités de chaque spécialité. J'ai aussi travaillé sur l'interface patient pour structurer des parcours lisibles pour des personnes souvent âgées, peu à l'aise avec le numérique, et qui utilisent l'application dans des moments potentiellement anxiogènes.

Au fil de la croissance, j'ai également pris en charge la structuration de la connaissance utilisateur : comment centraliser les feedbacks, les relier à des hypothèses produit, distinguer le qualitatif du quantitatif, éviter que l'organisation ne prenne des décisions sur la base de verbatims mal interprétés. Ce chantier était moins visible que les features, mais il a eu des effets concrets sur la qualité des arbitrages.

Résultats & impact

Le produit a atteint plus de dix mille patients suivis et plus de trois cents structures de soins utilisatrices, en cardiologie, oncologie et chirurgie ambulatoire. Ces chiffres sont le résultat d'un travail collectif sur plusieurs années, pas d'une action isolée.

Ce que je peux dire plus précisément : les spécifications fonctionnelles que j'ai produites ont réduit les allers-retours en développement. L'atelier de service blueprint a permis de reprioriser certaines fonctionnalités qui auraient autrement été développées dans un ordre sous-optimal. Le travail sur la connaissance utilisateur a commencé à créer une culture de la décision un peu plus fondée, sans être complètement abouti au moment où j'ai quitté l'entreprise.

Sur les nouvelles spécialités : chaque nouveau produit a demandé de repartir à zéro sur la compréhension métier. Les workflows de suivi de traitement pour cancer n'ont rien à voir avec ceux de la cardiologie chronique, ni avec ceux de la chirurgie ambulatoire. C'est ce type de remise à plat régulière qui m'a le plus appris sur la façon de structurer un produit dans un domaine complexe.

Recul

Le passage d'une petite équipe à une organisation structurée est une transformation qui se gère mal si on ne l'anticipe pas. J'ai parfois été pris dans l'urgence du delivery au détriment du recul nécessaire. J'ai aussi sous-estimé la résistance que génère le fait d'introduire de la rigueur (structuration des feedbacks, gouvernance de la connaissance) dans des équipes habituées à aller vite sans formaliser.

Sur le fond produit : la question de la valeur perçue par les patients n'a pas été adressée assez tôt à mon sens. Une application médicale réduite aux questionnaires reste une expérience limitée. C'est une question stratégique qui dépasse largement le rôle de PM, mais j'aurais pu la poser plus tôt et plus clairement.

Ce qui m'a le plus appris ici, c'est la gestion de la complexité dans des systèmes à acteurs multiples. Pas la complexité technique : la complexité organisationnelle et humaine d'un produit qui s'insère dans des workflows médicaux existants, avec des professionnels de santé qui ont des habitudes ancrées et des patients qui n'ont pas demandé à utiliser une application.