Le plaidoyer pour une équipe de dev dirigée par un médecin : Comment l'architecture clinique crée de meilleurs logiciels médicaux

Les médecins ont attribué à leurs propres logiciels médicaux une note moyenne de 45,9 sur 100 dans une étude publiée dans Mayo Clinic Proceedings — soit un niveau insuffisant, l'équivalent d'un F. À titre de comparaison, Google obtient 93 sur la même échelle. Même Microsoft Excel, pourtant réputé fastidieux, obtient 57.

Pour mettre cela en perspective : les médecins évaluent les outils qu'ils utilisent chaque jour comme étant plus proches de l'inutilisable que de l'acceptable.

Ce n'est pas un problème marginal. C'est systémique.

Ce n'est pas un problème technologique. La technologie existe. C'est un problème de traduction — et il commence au moment où un développeur qui n'a jamais vu une salle de consultation ouvre un schéma de base de données vierge.

Je le sais parce que je suis gynécologue, et que j'en ai construit un de zéro.

Ce que vous allez apprendre dans cet article :

• Pourquoi les interfaces DME ne correspondent pas à la pensée clinique réelle — et comment l'expérience médicale conduit à un design minimaliste
• Les trois options d'infrastructure, l'hypothèse erronée qui a failli tout compromettre, et pourquoi seul un clinicien pouvait la corriger
• Comment un message WhatsApp a révélé le plus grand avantage de construire son propre logiciel
• Quelles compétences informatiques un médecin doit réellement maîtriser au sein d'une équipe tech
• Pourquoi un consultant médical ne remplace pas un médecin-fondateur — et ce que cette combinaison a concrètement produit

---

L'interface qui révèle la main du développeur

La première fois que j'ai examiné sérieusement un DME concurrent, je n'avais pas besoin de lire la documentation. Je voyais exactement comment il avait été construit.

La navigation était organisée en listes séparées : ordonnances, examens, investigations, résultats biologiques. Chaque catégorie avait son propre module, son propre écran, son propre point d'entrée.

C'était une réplique parfaite des tables de la base de données.

Le problème, c'est que ce n'est pas ainsi que fonctionne la médecine. Un médecin ne pense pas par catégories — il pense par consultations. Chaque visite a une date, un motif, des constats, une décision, un plan de suivi. Tout ce qui s'est passé ce jour-là appartient ensemble. L'ordonnance rédigée pendant une consultation appartient à cette consultation — pas à une liste globale d'ordonnances qui se mélange avec toutes les visites des cinq dernières années.

Quand j'ai conçu doctoLys, la logique était inverse : une liste chronologique de consultations, et à l'intérieur de chaque consultation, tout ce qui s'est passé lors de cette visite. La navigation devient immédiate. Le contexte n'est jamais perdu. L'interface reflète le modèle mental qu'un médecin a déjà construit après des années de dossiers papier.

Ce n'est pas une préférence de design. C'est la différence entre un logiciel adopté et un logiciel abandonné.

La question du minimalisme va encore plus loin quand on considère qui est réellement l'utilisateur. Nos utilisateurs cibles avaient passé des années — souvent des décennies — à travailler sur papier. Les faire passer à un écran avec vingt boutons, douze modules et une barre de navigation pleine d'icônes, ce n'est pas de la numérisation. C'est de l'abandon habillé en modernisation. Quand nous avons recruté un designer UX expérimenté en début de projet, son réflexe a été de s'inspirer des DME existants. Le problème, c'est que ces solutions avaient déjà échoué le test d'utilisabilité. S'inspirer de l'échec produit un échec mieux présenté.

L'intuition clinique que j'ai apportée était plus simple : une feuille de consultation papier a une date, un motif de visite, des constats, une décision et un suivi. Cinq éléments. L'interface devrait refléter exactement cela — rien de plus sur le premier écran. Chaque élément supplémentaire est une friction pour un médecin qui gère déjà une salle d'attente. Comme nous l'avons exploré dans le rôle du mobile dans l'adoption clinique, le défi du design d'interface n'est pas d'ajouter des fonctionnalités — c'est de supprimer tout ce qu'un médecin habitué au papier ne reconnaît pas immédiatement.

---

La décision de base de données que les développeurs ratent toujours

Avant de concevoir la moindre interface, il y avait une question plus fondamentale : comment structurer les données ?

J'ai dû apprendre PostgreSQL de zéro — les tables, les clés étrangères, les relations un-à-plusieurs et plusieurs-à-plusieurs. Non pas pour devenir développeur, mais parce que je comprenais quelque chose que l'équipe technique ne voyait pas : une mauvaise architecture de données dans une application médicale n'est pas un bug qu'on corrige au prochain sprint. C'est un mur qu'on heurte deux ans plus tard quand on essaie de passer à l'échelle.

Parce que je maîtrisais la réalité clinique, je pouvais définir exactement quelles entités existaient, comment elles étaient reliées, et — c'est crucial — quels cas limites le schéma devait gérer dès le départ. Une consultation peut contenir plusieurs ordonnances. Une ordonnance peut référencer plusieurs médicaments. Un suivi de grossesse a une structure complètement différente d'une consultation gynécologique classique. Ces relations sont évidentes pour tout gynécologue. Elles sont invisibles pour un développeur qui travaille à partir d'un modèle de données de santé générique.

Le résultat a été un schéma construit autour de la réalité clinique, pas de la commodité technique. Cette décision a silencieusement évité plusieurs problèmes de scalabilité qui apparaissent typiquement dix-huit mois après le lancement d'un produit.

---

Le débat infrastructure — et l'hypothèse erronée qui a failli tout compromettre

Quand nous avons commencé à discuter de l'infrastructure, trois options étaient sur la table.

Option 1 — Application bureau en local (on-premise). Avantages : aucune dépendance à la connexion internet, pas de complications liées à la souveraineté des données, pas de contraintes de conformité cloud. Inconvénients : aucun accès à distance, sécurité des données dépendante du matériel du médecin, mises à jour nécessitant une installation manuelle sur chaque poste, et — point critique — aucune possibilité viable de partage de documents.

Option 2 — Cloud avec une base de données partagée, accès multi-utilisateurs. Avantages : accessibilité, sécurité gérée centralement, mises à jour automatiques. Inconvénients : dépendance à internet, et un problème sérieux de localisation des données. Parce que doctoLys a été conçu dès le départ pour être sans frontières — pour fonctionner pour n'importe quel médecin dans n'importe quel pays, comme nous l'avons exploré dans l'architecture logicielle médicale sans frontières — une base de données cloud partagée soulève immédiatement des questions sur la localisation physique des données patients et les cadres réglementaires applicables. RGPD, HIPAA, lois locales sur les données de santé : dans un produit multi-pays, une architecture à base de données unique crée une exposition réglementaire sans solution propre.

Option 3 — Cloud avec architecture multi-tenant. Une base de données isolée par cabinet médical, avec accès multi-utilisateurs au sein de chaque cabinet. Les données de chaque médecin restent dans un emplacement défini et auditable. La conformité réglementaire devient gérable. L'accès à distance est préservé. Les mises à jour se font centralement.

L'instinct de l'équipe technique était d'écarter l'option 3 — et leur raisonnement a révélé une hypothèse critique. Ils pensaient que les médecins auraient besoin de donner à leurs confrères et à leurs patients un accès direct au dossier médical. Si c'était vrai, une architecture multi-tenant — où chaque cabinet a sa propre base de données isolée — serait effectivement problématique. Un accès partagé entre cabinets nécessiterait une base de données commune.

L'hypothèse était totalement fausse. Et seul un clinicien pouvait le savoir immédiatement.

Les médecins ne donnent pas à leurs confrères — et encore moins à leurs patients — un accès direct à leurs dossiers médicaux. Le dossier n'est pas seulement la donnée patient. C'est la note clinique personnelle du médecin : observations, impressions, incertitudes, choses notées dans le feu d'une consultation qui n'ont jamais été destinées à être lues par quelqu'un d'autre. Les médecins considèrent ce dossier comme leur propriété professionnelle, même quand les données sous-jacentes appartiennent au patient.

Ce que les médecins ont réellement besoin de partager, c'est un document statique : un compte rendu, une ordonnance, une lettre de correspondance. Un document formaté, pas un accès en direct au dossier. L'architecture multi-tenant gère cela parfaitement — le document statique est généré depuis la base de données isolée et partagé à l'extérieur. Les données elles-mêmes ne bougent pas.

Je n'étais pas non plus à l'aise avec l'option on-premise, et pour des raisons qui n'avaient rien à voir avec l'architecture. J'ai posé trois questions qu'aucun ingénieur infrastructure ne pouvait répondre depuis un tableau blanc :

Que se passe-t-il quand un médecin a besoin d'accéder à un dossier lors d'un appel d'urgence en pleine nuit ? Une application installée localement sur un ordinateur de cabinet est inaccessible. Un système cloud ne l'est pas.

Un médecin peut-il gérer un serveur local quand il tombe en panne ? Dans ma pratique en Tunisie, la réponse est non. Demander à un praticien en cabinet solo de redémarrer un serveur localhost, c'est lui demander de devenir son propre service informatique. La plupart arrêteront d'utiliser le logiciel en quelques semaines.

Les médecins accepteront-ils de perdre les données des dernières 24 heures si une sauvegarde locale échoue ? Non. Jamais. Pas une seule fois.

Nous avons construit sur cloud avec une architecture multi-tenant — et ajouté une infrastructure avec équilibrage de charge (load balancing) dès le début. La pratique médicale ne tolère aucune interruption de service. Un médecin en pleine consultation qui perd l'accès au dossier patient ne reporte pas. Il perd confiance dans le logiciel définitivement. Le load balancing n'était pas un confort à atteindre à grande échelle. C'était une exigence clinique dès le premier jour.

---

Le message WhatsApp à 2 lignes de code — et ce qu'il a révélé

Quelques mois après le lancement du MVP, j'ai reçu un message WhatsApp d'un confrère gynécologue.

« Bonjour Sadok — le nouveau module ordonnances est vraiment bien. Est-ce qu'on pourrait ajouter les dates correspondant à 37 semaines et 40 semaines d'aménorrhée sur la page principale du dossier ? »

J'ai lu, compris immédiatement, et priorisé dans la journée. La fonctionnalité représentait deux lignes de code. Il a fallu moins d'une heure à un développeur pour l'implémenter. Pour tout gynécologue qui suit des grossesses, c'est réellement utile — ces deux dates sont les bornes de la grossesse à terme, et les avoir visibles sans calcul évite un effort cognitif minime mais réel, répété des dizaines de fois par jour.

Imaginez maintenant ce qui se passe quand ce même message arrive dans un workflow produit classique. Il entre dans un système de tickets. Un product owner non clinicien le lit, ne saisit pas pleinement le contexte clinique, rédige une spécification qui rate l'essentiel, planifie la tâche pour un prochain sprint, et un développeur finit par implémenter quelque chose de légèrement inexact. Trois itérations plus tard, la fonctionnalité sort — six semaines après le message original, au lieu d'une journée.

Ce n'est pas une histoire exceptionnelle. C'est le coût standard du fossé de traduction dans le développement de logiciels médicaux. Multipliez-le par chaque demande de fonctionnalité, chaque retour utilisateur, chaque cas limite clinique — et vous commencez à comprendre pourquoi les DME obtiennent une note insuffisante.

Être simultanément l'utilisateur final, le product owner et l'expert du domaine n'est pas un avantage qu'on peut reproduire en engageant un consultant médical. C'est une propriété structurelle du produit lui-même.

---

Le problème DICOM résolu sur mon propre échographe

L'une des fonctionnalités les plus demandées par les gynécologues utilisateurs était l'intégration directe entre le DME et les appareils d'échographie — capture automatique des images et des mesures dans le dossier patient, sans ressaisie manuelle.

Toutes les solutions existantes que j'ai trouvées reposaient sur une connexion réseau local entre l'échographe et le logiciel. Notre architecture était en cloud. Les deux approches étaient incompatibles.

J'ai fait la recherche moi-même. J'ai appris le protocole DICOM — le standard pour les données d'imagerie médicale — ainsi que les comptes rendus structurés et les DICOM worklists. J'ai testé sur mon propre échographe dans mon cabinet, en générant des examens fictifs pour valider l'intégration. Parce que mes confrères me faisaient confiance en tant que pair, plusieurs d'entre eux m'ont donné accès à leurs appareils, sur différentes marques et modèles — quelque chose qu'aucun chercheur ou développeur externe n'aurait obtenu.

La solution que j'ai trouvée fonctionnait entièrement via internet, compatible avec notre architecture cloud et avec chaque modèle de machine testé. Cela a pris plus de temps qu'une investigation menée par un développeur dans un environnement réseau local. Mais cela a produit la bonne réponse — parce que je savais exactement quel résultat clinique était requis, et je n'acceptais pas une solution qui ne l'atteignait pas.

C'est ce à quoi ressemble l'avantage de traduction dans sa forme la plus concrète : non seulement comprendre le problème, mais être suffisamment reconnu par ceux qui le vivent pour obtenir un accès réel à leur environnement.

Et cela a introduit une méthodologie de test qu'aucune équipe externe ne pouvait reproduire. Avant qu'une fonctionnalité n'atteigne les utilisateurs finaux, elle passait par deux niveaux de validation. Le premier était technique — les tests standards de l'équipe dev pour détecter les bugs et les cas limites. Le second était clinique — je testais chaque fonctionnalité dans mon propre cabinet, sur de vraies consultations, face aux frictions qu'un médecin ressent réellement dans l'instant. Quand quelque chose ne fonctionnait pas, je n'ouvrais pas un ticket. Je coachais le développeur directement, en lui montrant ce que le workflow clinique exigeait et pourquoi l'implémentation actuelle le manquait. Ce n'est qu'après ce cycle — recueillir les retours, tester dans mon cabinet, affiner, valider à nouveau — qu'une fonctionnalité était déployée chez les autres médecins.

C'est la différence entre un logiciel qui passe les tests QA et un logiciel qui survit au contact d'une vraie salle de consultation.

---

« Mais un médecin consultant ne suffirait-il pas ? »

À ce stade, une objection raisonnable se pose : pourquoi le médecin doit-il être le fondateur ? Le même résultat ne pourrait-il pas être atteint en recrutant un consultant médical pour conseiller l'équipe de développement ?

En théorie, oui. En pratique, non — et la raison n'est pas une question de connaissance. C'est une question de continuité et de conséquence.

Un consultant apporte sa contribution à des moments définis — une réunion de cadrage, une revue de design, une session de test utilisateur. Mais un logiciel médical ne se construit pas à des moments définis. Il se construit dans des centaines de petites décisions quotidiennes, sur des schémas de base de données, des contrats d'API, des configurations d'infrastructure et des spécifications de fonctionnalités. Beaucoup de ces décisions semblent purement techniques en surface. Celles que j'ai décrites dans cet article — le choix cloud vs. on-premise, l'architecture multi-tenant, le schéma de base de données — m'ont toutes été présentées comme des questions techniques. C'étaient des questions cliniques déguisées.

Un consultant absent au moment où ces questions sont posées ne peut pas y répondre. Et une équipe de développement sous pression de délais n'attendra pas. Elle fera le choix techniquement raisonnable — qui est souvent le mauvais choix cliniquement.

Il y a un second problème : l'implication d'un consultant s'arrête quand le contrat se termine. Les conséquences d'une mauvaise décision architecturale, non. Elles s'accumulent silencieusement pendant dix-huit mois, puis deviennent très coûteuses à corriger — si tant est qu'elles puissent l'être.

C'est pourquoi la combinaison compte : non pas seulement la connaissance clinique, mais une implication quotidienne, une responsabilité totale, et la maîtrise technique suffisante pour reconnaître une question clinique quand elle se présente sous un déguisement technique.

Ce que cela exige concrètement — les compétences IT spécifiques, l'approche product ownership, la dynamique d'équipe — mérite son propre article. Nous l'explorons en profondeur dans un prochain article sur le management de projet en santé numérique : ce que les cliniciens doivent savoir avant de diriger une équipe de développement, et les erreurs qui tuent les projets healthtech avant qu'ils n'atteignent leur premier utilisateur.

---

Quelles compétences IT un médecin doit-il réellement maîtriser au sein d'une équipe tech ?

C'est la question pratique que soulève l'objection du consultant — et elle mérite une réponse directe.

L'objectif n'est pas de devenir développeur. C'est de maîtriser suffisamment le langage technique pour reconnaître quand une décision technique est en réalité une décision clinique, poser les bonnes questions, et évaluer les réponses qu'on reçoit.

Dans mon expérience, quatre domaines ont fait la plus grande différence :

Les fondamentaux des bases de données. Comprendre ce qu'est une table, ce que fait une clé étrangère, et ce que signifient les relations un-à-plusieurs et plusieurs-à-plusieurs suffit. Pas besoin d'écrire des requêtes SQL. Il faut pouvoir s'asseoir dans une réunion de conception de schéma et dire : « Cette relation est fausse — une consultation peut contenir plusieurs ordonnances, pas l'inverse. » Cette seule intervention, faite au bon moment, peut éviter une année de problèmes.

Les concepts d'infrastructure. VPS, cloud vs. on-premise, load balancers, sauvegardes, localisation des données — pas l'implémentation technique, mais les implications cliniques de chaque choix. Assez pour demander : « Que se passe-t-il pour nos utilisateurs si ce serveur tombe pendant deux heures ? » et comprendre la réponse.

Les bases du product ownership. Gestion du backlog, planification des sprints, rédaction de tickets. Non pas en tant que chef de projet — mais en tant que clinicien capable de transformer un message WhatsApp d'un confrère médecin en une tâche de développement précisément spécifiée dans l'après-midi.

La conscience réglementaire. RGPD, HIPAA et les lois locales sur les données de santé ne sont pas seulement des contraintes juridiques — ce sont des contraintes architecturales. Un médecin qui comprend que les réglementations sur la localisation des données varient selon les pays peut intervenir avant que la base de données soit construite, pas après qu'elle soit déployée dans le mauvais territoire.

Rien de tout cela ne requiert un diplôme en informatique. Cela demande de la curiosité, du temps, et la motivation qui vient de construire quelque chose qu'on utilise soi-même. Nous irons plus loin sur exactement ce sujet — le parcours d'apprentissage, la dynamique d'équipe et les erreurs de management qui font échouer les projets de santé numérique avant d'atteindre leurs utilisateurs — dans un prochain article sur l'entrepreneuriat en santé numérique.

---

Ce que la combinaison a concrètement produit

Ce n'est pas l'histoire d'un médecin qui a appris à coder. C'est l'histoire de ce qui se passe quand le jugement clinique est présent à chaque point de décision d'un produit logiciel — du premier schéma de base de données au dernier choix d'infrastructure.

Les résultats ont été concrets :

Moins de problèmes de scalabilité. Le schéma de base de données a été conçu autour de la réalité clinique dès le premier jour. Les refactorisations architecturales qui frappent typiquement les logiciels médicaux à 500 utilisateurs, puis à 5 000, ne se sont pas produites. Les décisions qui deviennent habituellement des surprises coûteuses ont été prises correctement avant d'écrire la première ligne de code.

Meilleure UX et meilleure rétention. L'interface centrée sur la consultation, le design minimaliste, l'onboarding sans aucune configuration informatique — ce ne sont pas des corrections issues des tests utilisateurs après le lancement. C'est le résultat d'un product owner qui était aussi un utilisateur final et qui n'acceptait pas une interface qui ne ressemblait pas à de la médecine.

Management d'équipe plus efficace. Les fonctionnalités étaient spécifiées correctement du premier coup, éliminant les allers-retours d'itérations qui consomment la majorité de la capacité d'une équipe de développement. L'exemple des 37 SA n'est pas une exception — c'est le rythme. Une fonctionnalité à deux lignes de code livrée en une journée plutôt qu'un cycle de six semaines.

Un produit qui fonctionne là où les autres ne fonctionnent pas. Parce que les décisions d'infrastructure ont été prises en tenant compte des réalités cliniques des médecins en Tunisie et dans les pays en développement au sens large — et non des hypothèses des logiciels d'entreprise occidentaux — doctoLys fonctionne en 4G, ne nécessite aucun support informatique, et n'impose aucune contrainte spécifique à un pays.

Une étude publiée dans JMIR Medical Informatics identifie systématiquement le mauvais alignement avec les workflows comme la principale raison du rejet des DME. La combinaison du jugement clinique et de l'implication technique quotidienne est le seul moyen fiable d'empêcher ce désalignement d'être intégré au produit dès le départ.

Si vous évaluez un logiciel médical — en particulier si vous exercez hors des États-Unis ou d'Europe — la question la plus importante à poser n'est pas sur les fonctionnalités ou le prix. C'est : qui a pris les décisions sur la façon dont ce produit a été construit, et cette personne a-t-elle déjà vu ce que vous voyez chaque jour en consultation ?

Tout ce qui est décrit dans cet article s'est passé avant l'ère de l'intelligence artificielle. L'avantage de traduction était réel — mais lent, manuel, et dépendant d'une seule personne présente dans la bonne salle au bon moment. Dans un prochain article, nous explorons comment l'IA a résolu le paradoxe de la saisie clinique — et pourquoi la combinaison du jugement clinique et du développement assisté par IA a rendu possibles des capacités qui n'existaient tout simplement pas avant.

Le défi n'est pas seulement de numériser la médecine — mais d'aligner le logiciel sur la pensée clinique.

---

Rédigé par Dr. Sadok Derouich, gynécologue depuis 2012, entrepreneur en santé numérique et CEO de doctoLys — l'application IA de cabinet médical conçue pour les médecins du monde entier.