HT Expertise · mandat de 3 mois et plus
HealthTech & PharmaTech Product Engineering
Une feature qui influence une décision pharma doit tracer risque, exigence, contrôle, preuve.
Transformer les décisions du client pharma en fonctionnalités dont les preuves, permissions, validations et responsabilités sont conçues avec le produit.
Toutes les preuves de cette page indiquent leur niveau de provenance, limites comprises. Voir les preuves
Le moment où ça devient un sujet
Vous reconnaissez l’un de ces moments, ou ce n’est pas encore le sujet.
Ce sont des situations datables, pas des symptômes généraux. Si aucune ne vous parle, cette page peut se refermer ici.
-
Une fonctionnalité livrée est refusée par le client pharma pour une raison réglementaire que personne n’avait vue.
-
La documentation de conformité est écrite après le développement, par quelqu’un qui n’était pas dans les arbitrages.
-
Le backlog est priorisé par ce qui est facile à construire, pas par ce que le client doit défendre.
-
Un audit client demande la traçabilité d’une fonctionnalité et l’équipe produit une capture d’écran.
Aucune de ces situations n’est urgente en soi. Chacune le devient à une date connue d’avance.
Ce que ça coûte si rien ne change
Trois blocages, et le contournement qui ne les réduit pas.
Chaque blocage reçoit une réponse plus bas — dans les offres, le déroulé ou les engagements. Aucun n’est laissé ouvert.
La conformité arrive après le produit
Écrire la documentation après coup produit un document qui décrit ce qui a été fait, pas ce qui devait l’être. L’écart se découvre chez le client, au pire moment.
Le contournement habituel, et sa limite
Recruter un profil qualité en fin de chaîne déplace le problème : il documente des décisions auxquelles il n’a pas participé.
Le besoin client est traduit deux fois
Le métier pharma parle risque, le produit parle fonctionnalité, et personne ne parle les deux. Chaque traduction perd la contrainte qui comptait.
Le contournement habituel, et sa limite
Ajouter un comité de validation ajoute un délai sans ajouter la compétence qui manque à l’interface.
La preuve n’est pas un livrable du sprint
La fonctionnalité est « terminée » quand elle marche, pas quand elle est défendable. La dette de preuve s’accumule sprint après sprint et se paie à l’audit.
Le contournement habituel, et sa limite
Ajouter une colonne « documentation » au tableau ne change rien tant que la définition de terminé ne l’inclut pas.
Pour qui, et sous quelle pression
Le décideur qui achète ce mandat, et ce qui pèse sur lui.
Product Manager éditeur HealthTech
Isabelle Fontaine
Aujourd’hui
Des retours clients pharma mal traduits en features, une documentation réglementaire toujours en retard sur le produit.
Après le mandat
Un backlog priorisé par le métier, des spécifications conformes dès la conception et un delivery vérifiable, sprint après sprint.
Un avatar de décision sert à clarifier le problème et le résultat attendu. Il reste à valider avec vos entretiens et les comportements que vous observez. Les avatars, en entier
Avant de réserver quoi que ce soit
Quatre conditions d’entrée, quatre motifs de refus.
Elles sont écrites ici plutôt que découvertes au devis. La colonne de droite a le même poids que celle de gauche.
C’est le bon mandat si
- Une décision réelle est en jeu : une promotion en production, un audit, un renouvellement, un lancement ou un remplacement de système.
- Un sponsor nommé peut arbitrer le périmètre et signer la recette.
- L’accès aux systèmes, aux données ou aux documents nécessaires est possible sous NDA dans les trois premières semaines.
- Vous éditez un produit vendu à des clients pharma, et leurs exigences réglementaires arrivent dans votre backlog.
Ce n’est pas le bon mandat si
- Vous cherchez un panorama de tendances ou une veille : le format court de la clinique de décision coûte moins cher et répond mieux.
- Le résultat attendu dépend d’une signature réglementaire que seul un rôle statutaire de votre organisation peut porter.
- Aucun accès aux preuves n’est possible : sans données, sans journaux et sans documents, il n’y a rien à rendre défendable.
- Vous cherchez un renfort de développement : ce mandat travaille sur la décision produit et la preuve, pas sur la vélocité.
Un « non » dit à cette étape coûte vingt minutes. Dit après le devis, il coûte un trimestre à tout le monde.
L’état d’arrivée
Ce que le mandat déplace.
un produit dont la conformité se rattrape en aval
un produit dont chaque fonctionnalité arrive avec sa preuve et sa responsabilité
L’état d’arrivée n’est pas « une équipe qui documente plus ». C’est une définition de terminé qui inclut la preuve, et un backlog priorisé par ce que le client devra défendre.5
Axe par axe, avant et après
Trois axes, et ce qui change sur chacun.
Un axe par ligne, comparé des deux côtés. Une colonne de frustrations face à une colonne de fonctionnalités ne serait pas une comparaison.
Moment de la conformité
Aujourd’hui
Après le développement
Après
Dans la spécification, avant l’estimation
Priorisation du backlog
Aujourd’hui
Par facilité de construction
Après
Par le risque que le client doit défendre
Définition de terminé
Aujourd’hui
La fonctionnalité marche
Après
La fonctionnalité marche et porte sa preuve
Ce qui est visé, et de quel type
Deux critères de recette, un exemple déjà construit, aucun résultat observé.
Chaque ligne indique son statut : critère de recette, estimation modélisée, ou exemple déjà construit.
-
Visé — critère de recette
Chaque user story porte le risque pharmaceutique qu’elle adresse
Critère de recette du format de story, appliqué au raffinement.
-
Visé — critère de recette
La définition de terminé inclut la preuve, et bloque la clôture sans elle
Règle d’équipe posée en phase 2, vérifiable dans l’outil de suivi.
-
Exemple — déjà construit
Mappings OHDSI/OMOP et intégrations Therapeutics Data Commons alignés sur les cas métier
R&D publique montrant la traduction métier → modèle ; les feuilles de route client restent confidentielles.
Aucun de ces résultats n’est présenté comme mesuré chez un client : les métriques de production sont sous NDA sur chaque mandat. Reste la question qui suit — sur quoi ces engagements reposent-ils ?
Ce sur quoi ça repose, et ce que ça ne prouve pas
Des preuves proportionnées à la promesse.
R&D PharmD, mappings OHDSI/OMOP et intégrations Therapeutics Data Commons alignées sur les cas métier.
Preuve technique
R&D PharmD — OHDSI/OMOP & Therapeutics Data Commons
Mappings et intégrations alignés sur des cas métier réels, pas sur des démos. • Capability demonstrated : Preuve — mappings OHDSI/OMOP et intégrations Therapeutics Data Commons alignés sur des cas métier réels.
Crédential
Université de Strasbourg — Pharmacie (6 ans)
La langue du client pharma : protocole, réglementation, qualité et donnée clinique. • Capability demonstrated : Décision — compréhension du protocole, réglementation et donnée clinique pour la prise de décision pharma.
Parcours
Conseil et delivery technique depuis 2021
Traduction de besoins en spécifications et systèmes livrables : la langue de l’équipe produit. • Capability demonstrated : Feature — traduction de besoins en spécifications et systèmes livrables.
Manquant
Métriques d'adoption clinique
Les métriques d'adoption clinique et les résultats de promotion fonctionnelle sont détaillés sous NDA. Aucun chiffre client ou résultat de production d'HealthTech n'est publiable tant que le mandat n'est pas clos.
Sources & méthodes 5 placements · 5 unités de preuve
Chaque marqueur numéroté renvoie à une observation bornée : ce qui a été mesuré, sur quelle population, sur quelle période, et ce que le chiffre n’établit pas. Une affirmation qui ne peut pas être adossée à une de ces unités perd son marqueur — elle n’est pas rattachée à une source plus vague.
-
Les spécifications de besoins utilisateurs doivent décrire les fonctions requises du système informatisé, s’appuyer sur une analyse de risque documentée et sur l’impact BPF, et rester traçables tout au long du cycle de vie.
EudraLex volume 4, annexe 11 §4.4. L’annexe s’applique à toutes les formes de systèmes informatisés utilisés dans une activité couverte par les BPF. Révision 1, en application depuis le 30 juin 2011
Ce que ce texte n’exige pas Uniquement pour les systèmes informatisés utilisés dans le cadre d’activités couvertes par les BPF. C’est une exigence de traçabilité : elle ne prescrit aucun format de user story, et elle ne classe pas un produit HealthTech comme relevant des BPF — cette qualification se fait avant.
EudraLex Volume 4, Annex 11 — Computerised Systems, §4.4 · European Commission, revision 1
-
La même annexe demande de démontrer des méthodes et des scénarios de test appropriés, en considérant les limites de paramètres du système ou du procédé, les limites de données et la gestion des erreurs.
EudraLex volume 4, annexe 11 §4.7, même périmètre BPF que §4.4. Révision 1, en application depuis le 30 juin 2011
Ce que ce texte n’exige pas Uniquement pour les systèmes informatisés utilisés dans le cadre d’activités couvertes par les BPF. Le texte exige la preuve de scénarios de test appropriés ; il ne fixe ni taux de couverture, ni outillage, ni définition de terminé — ce sont des décisions produit, pas des obligations réglementaires.
EudraLex Volume 4, Annex 11 — Computerised Systems, §4.7 · European Commission, revision 1
-
La documentation technique doit contenir les résultats et les analyses critiques de l’ensemble des vérifications et des essais de validation menés pour démontrer la conformité du dispositif.
Règlement (UE) 2017/745, annexe II §6 — produits relevant du champ du règlement sur les dispositifs médicaux. Version consolidée du 19 juillet 2026
Ce que ce texte n’exige pas Uniquement pour les produits relevant du champ du RDM : un logiciel HealthTech n’est pas automatiquement un dispositif médical. La qualification se fait avant, et c’est elle — pas le secteur du client — qui décide si cette exigence s’applique.
-
La Commission européenne indique que les fabricants devront tester les composants harmonisés de leurs produits avant leur mise sur le marché et publier les résultats de ces tests dans la documentation technique.
Systèmes de dossier de santé électronique et composants harmonisés — interopérabilité et journalisation — relevant du champ de l’EHDS. Composants harmonisés exigibles à partir de début 2029 pour le premier groupe de catégories prioritaires, début 2031 pour le second
Ce que ce texte n’exige pas Uniquement pour les systèmes de DSE et les composants harmonisés relevant du champ de l’EHDS. L’obligation n’est pas encore en vigueur et son détail dépend d’actes d’exécution à venir : c’est un calendrier à anticiper, pas une exigence opposable aujourd’hui.
Certification of EHR systems — EHDS implementation · European Commission, DG SANTE
-
Pour l’IA utilisée afin de générer ou analyser des preuves dans le cycle de vie du médicament, les principes EMA/FDA 2026 cadrent notamment la validation proportionnée au risque, la provenance traçable, l’interaction humain–IA et le suivi du cycle de vie.
IA employée pour produire ou analyser des preuves dans le cycle de vie du médicament. Janvier 2026
Ce que ce texte n’exige pas Des principes directeurs, pas une exigence opposable : le texte ne prouve ni efficacité clinique ni résultat commercial, et ne vise que l’IA employée pour produire ou analyser des preuves dans le cycle de vie du médicament.
Chaque élément indique sa nature et son niveau de provenance. Les limites sont affichées au même titre que les réalisations. Le registre complet des projets et de leur provenance
Évaluer la missionCe qui est dedans, ce qui n’y est pas
Le périmètre, ses exclusions et ses dépendances.
Dans le périmètre
- Traduction du risque pharmaceutique client en exigences produit.
- Format de story, critères d’acceptation, définition de terminé.
- Documentation par fonctionnalité et contrôles IA/data.
Hors périmètre, explicitement
- Développement des fonctionnalités elles-mêmes.
- Validation du produit chez le client final.
- Rôle de responsable qualité de l’éditeur.
Ce qui dépend de vous
- Un sponsor joignable qui tranche un arbitrage de périmètre en moins d’une semaine.
- L’accès aux systèmes, journaux ou documents concernés, sous NDA.
- Une ou deux personnes de votre équipe disponibles pour la phase de passation — sans elles, le mandat produit une dépendance au lieu d’une capacité.
Format 6–12 mois · CDI éditeur · salarié
Le déroulé, et où l’on peut s’arrêter
Quatre phases, quatre sorties possibles.
Chaque phase se termine par un artefact et une décision. Vous pouvez vous arrêter à la fin de n’importe laquelle avec quelque chose entre les mains.
-
Écart
Ce que le client doit défendre, et ce que le produit lui donne pour le faire.
Sortie de phase Carte des écarts de preuve.
-
Format
Story, critères d’acceptation et définition de terminé incluant la preuve.
Sortie de phase Format adopté par l’équipe.
-
Application
Deux ou trois fonctionnalités passent par le nouveau format, de bout en bout.
Sortie de phase Fonctionnalités livrées avec leur preuve.
-
Passation
Votre PO raffine une story au format, seul.
Sortie de phase Guide de raffinement.
Les blocs de travail
Quatre blocs, activables séparément et dans n’importe quel ordre.
Risque client
Ce que le client pharma doit défendre, traduit en exigence produit.
Spécification
Critères d’acceptation, limites explicites, responsabilité nommée.
Preuve par fonctionnalité
Produite avec la fonctionnalité, versionnée avec elle.
Contrôles IA et data
Ce que le produit calcule, ce qu’il n’affirme pas, et où la revue humaine reste requise.
Un bloc que vous tenez déjà sort du périmètre et du devis. C’est la première chose qu’on regarde à l’appel de qualification.
Ce qui est garanti, et ce qui ne peut pas l’être
Ce qui est garanti est le produit de travail, jamais le résultat d’une autorité.
Périmètre écrit avant facturation
Le périmètre, les exclusions, les dépendances et les critères de recette sont écrits et acceptés avant le premier jour facturé. Un changement de périmètre est un avenant, pas une surprise en fin de mission.
Livrables complets ou repris
Un livrable qui ne satisfait pas ses critères de recette est repris jusqu’à ce qu’il les satisfasse, sans facturation supplémentaire. Les critères sont écrits avant de produire, pas après.
Réversibilité à la sortie
Code, données, schémas, décisions et journaux vous appartiennent et partent avec vous. Aucun composant propriétaire, aucune licence, aucun hébergement dont dépendrait la suite du travail.
Frontière de confidentialité
Tout livrable ou exercice qui manipule vos données porte une classification et une règle explicite : autorisé, anonymisé, synthétique ou interdit. La règle est écrite avant la manipulation, pas constatée après.
Frontière de décision humaine
Chaque cas traité indique où l’assistance automatique s’arrête et où une validation humaine est obligatoire. Un système qui décide sans que la limite soit écrite n’est pas livré.
Noyau neutre vis-à-vis des outils
Objectifs, critères de recette et preuves sont écrits indépendamment d’un fournisseur ou d’un modèle donné. Un changement d’outil est un avenant, jamais une reprise à zéro de l’investissement.
Ce qui n’est pas garanti, et ne peut pas l’être honnêtement
- L’acceptation par votre client final n’est pas garantie : elle dépend de son propre système qualité.
- La vélocité de l’équipe n’est pas garantie ; le format ajoute du travail au raffinement et en retire à l’audit.
Les conditions contractuelles complètes — acompte, préavis, propriété intellectuelle, confidentialité — sont publiées et ne sont pas reformulées ici. Lire les conditions
Ce qui reste à lever
Quatre questions, avec la réponse et sa raison.
Les questions qui changent le périmètre, le prix ou la responsabilité sont déjà répondues plus haut. Ici, le reste.
Le format ne va-t-il pas ralentir les sprints ?
Il ajoute du temps au raffinement et en retire à la reprise et à l’audit. La phase 3 mesure les deux sur deux ou trois fonctionnalités réelles avant de généraliser.
Développez-vous les fonctionnalités ?
Non, c’est explicitement hors périmètre. Le mandat porte sur la décision produit, la spécification et la preuve ; l’implémentation reste à votre équipe.
Nos clients ont des exigences contradictoires. Comment arbitrer ?
En les ramenant au risque produit sous-jacent, où elles convergent presque toujours. Ce qui reste réellement divergent devient une option documentée, pas une branche de code.
Intervenez-vous auprès de nos clients ?
Sur demande et sous NDA, en appui de votre équipe. La relation client reste la vôtre, et l’engagement pris devant eux aussi.
La prochaine étape, en entier
Évaluer la mission en 20 minutes
Le premier échange sert à décider s’il y a un mandat, pas à le vendre. S’il n’y en a pas, vous repartez avec la raison.
- 20 minutes, en visio ou au téléphone.
- Vous, le sponsor si ce n’est pas vous, et moi. Pas de commercial : il n’y en a pas.
- On y regarde le contexte, la décision en jeu, le niveau de risque et les preuves accessibles.
- Vous repartez avec un avis fit / no-fit motivé et, si c’est fit, le périmètre et la fourchette de la première étape.
Le bon format d’intervention, avant le premier rendez-vous.
Décrivez la décision à prendre — pas votre budget. Vous repartez avec le format d’intervention adapté et les ressources qui y mènent.
Cette expertise appliquée à votre cas : quatre écrans, une lecture gratuite, et l’offre qu’elle désigne.
Preuve