Comment l'IA a débloqué ce que le jugement clinique seul ne pouvait pas construire

Les médecins pensent en récits.

Les logiciels exigent de la structure.

Pendant des décennies, ce décalage a contraint les cliniciens à s'adapter à des systèmes rigides — remplir des champs qui ne reflètent pas leur façon de penser, saisir des données dans un format conçu pour les ordinateurs plutôt que pour les salles de consultation.

Fin 2023, doctoLys fonctionnait. Les médecins reconnaissaient leur pratique quotidienne dedans. L'interface était organisée autour des consultations, pas des tables de base de données — une philosophie de design née de la construction en tant que clinicien, comme nous l'avons exploré dans comment une équipe dirigée par un médecin bâtit une meilleure architecture clinique. L'infrastructure tournait sans support informatique. La prise en main prenait quelques minutes.

Et j'avais toujours une liste de demandes auxquelles je ne pouvais pas répondre.

Non pas parce que les fonctionnalités étaient techniquement complexes. Mais parce qu'elles nécessitaient de résoudre une contradiction que je contemplais depuis deux ans — un paradoxe ancré dans la nature même du dossier médical. Puis les API d'IA générative sont devenues accessibles. En quelques mois, trois fonctionnalités que je croyais impossibles ont été livrées. L'une d'elles est accidentellement devenue le fondement de l'application mobile.

Ce que vous allez apprendre dans cet article :

• Le paradoxe fondamental des données médicales que les logiciels classiques ne peuvent pas résoudre
• Pourquoi les mêmes médecins qui refusaient la saisie structurée demandaient des sorties structurées
• Comment un seul coup de téléphone a conduit à une fonctionnalité qui a changé la façon dont la majorité des utilisateurs interagissent avec doctoLys
• Les trois fonctionnalités IA qui ont résolu le paradoxe — et les décisions cliniques derrière chacune
• Les deux contraintes non négociables que tout outil médical avec IA doit respecter

---

Le paradoxe que je ne pouvais pas résoudre

doctoLys était construit sur des formulaires. Formulaires d'examen clinique, formulaires biologiques, formulaires sérologiques, modèles de compte rendu d'échographie — chacun conçu pour capturer des données cliniques dans un format structuré et interrogeable. Nous avons ajouté des boutons de remplissage automatique pour réduire la saisie. Nous avons simplifié les mises en page. Nous avons itéré encore et encore sur l'expérience de saisie.

Les données d'usage racontaient une histoire claire : la majorité des utilisateurs contournaient entièrement les formulaires et écrivaient dans le champ texte libre.

Je comprenais pourquoi. Les médecins qui avaient passé des décennies avec des dossiers papier ne pensaient pas en champs et en listes déroulantes. Ils pensaient en prose. Une feuille de consultation papier est un document personnel — souligné, annoté, structuré d'une façon qui reflète la pensée de ce médecin spécifique. Les formulaires leur semblaient une langue étrangère.

Mais je savais aussi ce qu'abandonner la saisie structurée coûterait. Chaque donnée saisie en texte libre est une donnée qu'on ne peut pas agréger, interroger ou exploiter. Le médecin qui veut connaître la prévalence du diabète gestationnel dans sa patientèle a besoin de données structurées. Le tableau de bord affichant les grossesses en cours et les dates d'accouchement prévues a besoin de données structurées. Le système d'alertes cliniques a besoin de données structurées. Le texte libre est médicalement riche et informatiquement inerte.

Pendant deux ans, je n'avais pas de solution. La préférence des médecins et la valeur à long terme du produit pointaient dans des directions opposées, sans terrain d'entente — jusqu'à ce qu'il en existe un.

---

Le paradoxe — ils voulaient des sorties structurées depuis le début

En surveillant les usages, j'ai remarqué quelque chose qui accentuait considérablement le paradoxe.

Les mêmes médecins qui refusaient de remplir des formulaires structurés demandaient, de façon constante et urgente, des sorties que seule une base de données structurée peut générer :

• La liste complète des examens réalisés sur l'ensemble d'un suivi de grossesse, indépendamment de la consultation lors de laquelle ils avaient été prescrits
• Des lettres de correspondance automatiques résumant l'histoire clinique de la patiente de façon cohérente
• Des alertes en cas de règle clinique oubliée — une sérologie toxoplasmose non prescrite chez une patiente non immune, l'Aspirine non arrêtée à 34 semaines d'aménorrhée, une mise à jour des recommandations pertinente pour la situation d'une patiente spécifique

Ce ne sont pas des fonctionnalités simples. Chacune d'elles exige que les données sous-jacentes soient structurées, cohérentes et interrogeables. Les médecins demandaient les bénéfices d'une base de données structurée tout en refusant de l'alimenter.

Ce n'était pas une contradiction dans leur comportement. C'était une attente raisonnable — que l'architecture logicielle classique ne pouvait tout simplement pas satisfaire. Le mode de saisie et la valeur des sorties étaient structurellement couplés, et il n'existait aucun moyen de les découpler avec les outils de développement conventionnels.

L'IA générative les a découplés.

---

Le coup de téléphone — et la fonctionnalité qui a tout changé

En 2023, un confrère m'a appelé. Il était gynécologue dans un cabinet de groupe avec un associé plus âgé qui n'était pas à l'aise avec le clavier. Il voulait migrer des dossiers papier vers le numérique, mais la barrière du clavier rendait la chose impossible pour son associé. Existait-il une solution de transcription ?

J'ai passé quelques heures à faire des recherches. Ce que j'ai trouvé n'était pas seulement un outil de transcription — c'était une réponse complète à un problème que je n'avais pas encore pleinement formulé.

Les grands modèles de langage gèrent la transcription avec une capacité que les outils de transcription dédiés ne peuvent pas égaler : ils sont nativement multilingues, ils reconnaissent la terminologie médicale quand on leur donne le contexte clinique approprié dans le prompt système, et — point crucial — ils peuvent formater la sortie transcrite selon un modèle prédéfini. Pas seulement transcrire et déverser. Transcrire, interpréter et structurer.

J'ai construit un prompt qui reproduisait la structure d'une vraie consultation gynécologique : antécédents, motif de consultation, examen clinique, examens complémentaires, ordonnances, conduite à tenir. Le médecin parle. Le modèle transcrit l'audio, reconnaît le contenu clinique et formate automatiquement la sortie dans les sections correspondantes du modèle de consultation.

La fonctionnalité a été livrée en quelques jours.

Le retour des utilisateurs a été inattendu. Ce n'était pas seulement une solution pour les médecins peu à l'aise avec le clavier. En quelques semaines, la dictée vocale avec mise en forme par IA était devenue le mode de saisie principal de la majorité des utilisateurs de doctoLys — y compris ceux qui utilisaient l'application depuis des mois avec une saisie clavier. Des médecins qui n'avaient jamais se plaint de taper ont basculé volontairement.

La raison est devenue évidente rétrospectivement. La voix est la façon dont les médecins ont toujours enregistré leur réflexion clinique. La feuille de consultation papier a toujours été une transcription de ce que le médecin a observé et décidé sur le moment. Supprimer le clavier n'a pas changé le workflow — il l'a restauré.

Cette fonctionnalité est ensuite devenue le fondement de l'application mobile doctoLys. Comme nous l'avons exploré dans le rôle du mobile dans l'adoption clinique, le smartphone est le dispositif naturel pour un workflow qui commence par la voix. La fonctionnalité de transcription IA a rendu cette architecture non seulement possible, mais inévitable.

---

De la transcription à la base de données — l'extraction automatique des résultats d'examens

La percée de la transcription a clarifié quelque chose sur ce que l'IA générative pouvait réellement faire pour un système de dossier médical. Ce n'était pas seulement un meilleur mode de saisie. C'était une couche de traduction entre le langage clinique non structuré et les entrées structurées en base de données.

Cette intuition a conduit directement à la deuxième fonctionnalité.

Les médecins reçoivent des résultats d'examens — comptes rendus biologiques, comptes rendus d'imagerie, lettres de confrères spécialistes — directement dans leur messagerie, sous forme de pièces jointes PDF ou d'images. Le workflow classique consiste à lire manuellement chaque document et à taper les valeurs pertinentes dans les champs correspondants de l'application. Pour un cabinet chargé, c'est un coût en temps réel, répété des dizaines de fois par semaine.

L'alternative avec IA : le document arrive, le modèle le lit, extrait les valeurs cliniquement pertinentes, les structure dans un schéma JSON prédéfini aligné sur le modèle de données de l'application, et les charge directement dans le dossier patient. Le médecin vérifie et confirme. Le document devient une entrée en base de données en quelques secondes.

Du point de vue du développement produit, cette fonctionnalité a nécessité de résoudre un problème sans lien avec la transcription : le modèle doit produire de façon fiable un JSON structuré, pas de la prose. Cela exige une ingénierie de prompt soignée — définir le schéma exact, spécifier comment gérer les champs manquants, contrôler les hallucinations sur les valeurs numériques. Chacune de ces décisions d'ingénierie nécessitait qu'un clinicien définisse à quoi ressemble la sortie correcte. Un développeur construisant cela sans apport clinique produirait une extraction techniquement fonctionnelle qui rate la moitié des cas limites qu'un médecin repérerait en trente secondes.

---

Le résumé de consultation — et le moteur de règles cliniques

La troisième fonctionnalité est la plus ambitieuse sur le plan structurel, et celle qui a le plus directement résolu le paradoxe initial.

Chaque fois qu'une nouvelle consultation est ajoutée au dossier d'une patiente — qu'elle soit saisie au clavier, dictée ou importée — le texte de la consultation est envoyé au modèle avec deux instructions. Première instruction : structurer ce texte selon le modèle spécifique à la spécialité et retourner un résumé clair. Deuxième instruction : vérifier le contenu clinique par rapport à un ensemble de règles prédéfinies et retourner les recommandations avec le résumé.

Les règles sont cliniques, pas techniques. Elles ont été rédigées par un clinicien :

• La sérologie toxoplasmose a-t-elle été prescrite pour une patiente non immune à l'âge gestationnel approprié ?
• L'Aspirine a-t-elle été arrêtée à 34 semaines d'aménorrhée pour une patiente sous prophylaxie à faible dose ?
• Existe-t-il une mise à jour des recommandations pertinente pour la situation spécifique de cette patiente ?

Le médecin reçoit le résumé structuré et les recommandations basées sur les règles ensemble, immédiatement après l'enregistrement de la consultation. Le dossier patient reste en saisie texte libre si c'est ainsi que le médecin préfère travailler. Mais le modèle a simultanément extrait le sens clinique structuré de ce texte libre et l'a vérifié par rapport aux règles.

Le médecin qui refusait de remplir un champ "diabète gestationnel" dispose maintenant d'un système qui lit sa note de consultation, identifie le diagnostic et vérifie que les étapes de prise en charge appropriées sont en place — sans aucune saisie supplémentaire.

La saisie est libre. La sortie est structurée. Le paradoxe est résolu.

Pour le rendre concret : un clinicien écrit « Patiente non immune à la toxoplasmose, 12 SA, acide folique prescrit, prochaine consultation dans 4 semaines. » Aucun formulaire rempli. Aucun champ structuré sélectionné. Le modèle lit cette note, extrait le statut immunologique, l'âge gestationnel et les ordonnances en cours, les structure dans le dossier patient, et vérifie simultanément : la sérologie toxoplasmose n'a pas été prescrite pour une patiente non immune à 12 SA — une lacune clinique. La recommandation apparaît avec le résumé de consultation. Le médecin confirme ou corrige. La base de données est mise à jour. L'alerte est résolue. Tout cela depuis une phrase rédigée exactement comme elle l'aurait été sur papier.

---

Les décisions qui nécessitaient un clinicien — pas un développeur

Avant de pouvoir construire ces fonctionnalités, j'ai dû comprendre comment ces modèles fonctionnent réellement — et deux questions architecturales nécessitaient des réponses que seul le jugement clinique pouvait apporter.

Bien utiliser un LLM ne consiste pas à choisir le bon modèle. Il s'agit de concevoir un système où le contexte est contrôlé, les sorties sont contraintes à un format défini, et les résultats sont vérifiables par le clinicien avant de faire partie du dossier. Chacune de ces trois exigences a une définition clinique, pas seulement technique.

Un glossaire pour les cliniciens. Un LLM — Large Language Model, ou grand modèle de langage — est la technologie derrière des outils que la plupart des médecins ont déjà croisés : ChatGPT, Gemini, et les assistants IA similaires. C'est un système d'IA entraîné sur d'immenses quantités de texte, capable de lire, interpréter et générer du langage. Imaginez un assistant extrêmement compétent qui aurait lu la quasi-totalité d'internet, y compris une quantité considérable de littérature médicale. Il ne stocke pas vos données et n'apprend pas de vos patients. Il lit ce que vous lui envoyez, le traite, et retourne une réponse structurée.

La clé pour bien utiliser un LLM est ce que le domaine appelle un prompt système — un ensemble d'instructions données au modèle avant tout envoi de contenu patient. Le prompt système définit le rôle que joue le modèle, le format que doit suivre la sortie, la terminologie en usage, et les règles applicables. Le prompt utilisateur est le contenu effectivement traité — la note de consultation, le document de laboratoire, l'audio dicté. Ensemble, ils déterminent la qualité de la sortie.

La différence que fait le contexte n'est pas marginale — c'est la différence entre une fonctionnalité utilisable et une fonctionnalité fiable. Considérez la même note de consultation envoyée à un LLM de trois façons différentes :

• Sans contexte : le modèle retourne un résumé générique qui pourrait appartenir à n'importe quelle spécialité médicale. Il peut mal interpréter les abréviations, manquer la signification clinique et produire une sortie dans le mauvais format.
• Avec prompt système uniquement : le modèle sait qu'il traite une consultation gynécologique et formate la sortie correctement. Il ne sait toujours pas que "34 SA" signifie 34 semaines d'aménorrhée, qu'une sérologie toxoplasmose manquante est une lacune à signaler, ou que l'acide folique prescrit au troisième trimestre indique quelque chose de différent du premier.
• Avec prompt système + contexte du dossier patient : le modèle dispose des antécédents de la patiente, de son statut immunologique connu, de l'âge gestationnel actuel et des ordonnances en cours. Il reconnaît que la sérologie toxo est absente pour une patiente non immune à 12 SA, la signale dans les recommandations, et formate le résumé de consultation avec la structure spécifique à la gynécologie.

Le troisième scénario est ce que doctoLys envoie. Le contexte du dossier patient voyage avec le texte de la consultation. Le prompt système a été rédigé par un clinicien qui sait à quoi ressemble une sortie "correcte" dans un cabinet de gynécologie réel. La sortie est cliniquement fiable — non pas parce que le modèle est médical-spécifique, mais parce que le contexte l'est.

LLM local vs. LLM cloud. L'instinct de l'équipe technique penchait vers un modèle hébergé localement — aucune donnée ne quitte le système, pas de dépendance au cloud, pas de coût par token. Le raisonnement clinique pointait vers le cloud. Les modèles les plus performants disponibles via les API cloud sont considérablement plus puissants que tout ce qui peut être déployé localement à notre échelle d'infrastructure. Ils sont nativement multilingues — une exigence non négociable pour un produit utilisé en Tunisie, en France, en Afrique de l'Ouest et au Moyen-Orient. Et la préoccupation concernant la confidentialité, bien que réelle, a une solution technique propre : l'identité du patient est supprimée du texte avant tout envoi de requête. Le modèle reçoit uniquement le contenu clinique, sans information identifiante. La réponse était évidente une fois la question formulée cliniquement plutôt que techniquement.

LLM généraliste vs. LLM médical spécifique. Des modèles de langage médicaux spécifiques existent, entraînés sur la littérature clinique et les données de santé structurées. Le cas en leur faveur semble intuitif. Le cas contre eux est plus solide : les LLM généralistes ont suffisamment progressé pour que, combinés à des prompts système cliniques bien construits, ils surpassent les modèles médicaux spécialisés sur les tâches pratiques qu'une application de cabinet médical requiert. Le prompt système porte le contexte clinique. Le modèle apporte la capacité de raisonnement. La combinaison — et spécifiquement la qualité de l'ingénierie de prompt — est là où la connaissance du clinicien devient irremplaçable.

L'ingénierie de prompt en médecine n'est pas une tâche technique. Elle nécessite de savoir que "34 SA" signifie 34 semaines d'aménorrhée, que l'absence d'un résultat sérologique est cliniquement différente d'un résultat normal, qu'une ordonnance d'acide folique a un poids différent au premier trimestre par rapport au troisième. Ces distinctions ne viennent pas d'une page de documentation. Elles viennent de années de pratique clinique.

---

Deux contraintes non négociables

Toutes les fonctionnalités IA de doctoLys fonctionnent sous deux contraintes non négociables.

Validation humaine avant enregistrement. Toute sortie du modèle — qu'il s'agisse d'une transcription, d'un résultat d'examen extrait ou d'un résumé de consultation — est présentée au médecin comme une proposition, pas comme un enregistrement sauvegardé. Le médecin vérifie, corrige si nécessaire, et confirme avant que quoi que ce soit soit écrit dans la base de données.

La crainte principale que les médecins expriment quand l'IA est introduite dans les workflows cliniques est l'hallucination. C'est le terme utilisé dans le domaine pour un mode d'échec spécifique et bien documenté : un LLM générant du contenu plausible en forme mais factuellement incorrect. Le modèle ne sait pas qu'il a tort. Il produit une sortie confiante et bien structurée — et cette sortie peut contenir une valeur biologique inventée, un diagnostic mal attribué, une ordonnance manquante, ou un calcul d'âge gestationnel subtilement erroné. Dans un contexte clinique, ce n'est pas un bug logiciel. C'est un risque pour la sécurité des patients.

La préoccupation est légitime. Elle est aussi, avec la bonne conception, gérable.

L'étape de validation est la réponse directe. La sortie du LLM est un premier jet — jamais un enregistrement sauvegardé. Le médecin la lit avant que quoi que ce soit soit écrit dans la base de données. Les erreurs sont détectées au moment où elles ne coûtent rien : une correction avant enregistrement, pas une conséquence après. Le modèle apporte vitesse et structure. Le médecin apporte jugement et responsabilité. Ni l'un ni l'autre ne remplace l'autre, et le workflow est plus rapide que la saisie depuis zéro même en incluant l'étape de vérification.

En pratique, les taux d'hallucination sont significativement plus faibles quand le LLM dispose d'un contexte clinique riche — le dossier patient, le prompt système spécifique à la spécialité, l'historique des consultations. Un modèle travaillant avec un contexte complet fait moins d'erreurs qu'un modèle travaillant depuis un prompt vide. C'est une raison supplémentaire pour laquelle la qualité du prompt système compte autant que le modèle lui-même.

Ce n'est pas seulement une bonne conception produit. En vertu du règlement européen sur l'IA (AI Act), les systèmes d'IA médicaux classifiés à haut risque exigent une supervision humaine significative. Un outil d'aide à la décision clinique qui écrit directement dans un dossier médical sans confirmation du médecin ne satisfait pas cette exigence. L'étape de validation est à la fois une exigence réglementaire et clinique — le médecin reste responsable de chaque entrée dans le dossier.

Suppression de l'identité patient avant traitement. Avant qu'un texte de consultation, un document ou une transcription vocale soit envoyé à une API LLM externe, toute information identifiant le patient est supprimée du contenu. Nom, date de naissance, numéros d'identification, adresse — rien de tout cela ne quitte le système. Le modèle reçoit uniquement le contenu clinique. C'est une exigence architecturale, pas une option de configuration, et elle a été intégrée au pipeline des fonctionnalités dès le premier jour de développement.

---

Ce que cette combinaison a réellement débloqué

Les trois fonctionnalités — transcription vocale avec mise en forme par IA, extraction document-vers-base-de-données, et résumé de consultation avec moteur de règles cliniques — ne sont pas des ajouts indépendants à doctoLys. Elles sont trois expressions de la même capacité sous-jacente : une couche de traduction entre la façon dont les médecins travaillent naturellement et les données structurées qu'un système de dossier médical utile requiert.

Aucune d'elles n'aurait été possible avec le développement logiciel classique. Non pas parce que la technologie n'existait pas — les API de transcription existaient avant les LLM. Mais parce que la combinaison spécifique du jugement clinique dans l'ingénierie de prompt, de la compréhension de ce que la sortie structurée doit contenir, et de la capacité à tester les fonctionnalités dans un cabinet en activité réelle a produit des résultats qu'une équipe techniquement compétente sans ancrage clinique n'aurait pas pu atteindre.

Le médecin qui voulait connaître la prévalence du diabète gestationnel dans sa patientèle dispose maintenant de cette donnée — parce que le modèle l'a extraite des notes de consultation qu'il rédigeait déjà. Le tableau de bord des grossesses avec les dates d'accouchement prévues en temps réel se met à jour automatiquement — parce que la consultation mise en forme par IA inclut les champs structurés qui l'alimentent. Les alertes cliniques se déclenchent correctement — parce que les règles ont été rédigées par quelqu'un qui a géré des centaines de grossesses à risque et sait exactement où se produisent les omissions.

Le jugement clinique a construit le produit. L'IA a étendu ce qu'il pouvait faire. La combinaison a produit des capacités qu'aucun des deux n'aurait pu atteindre seul.

L'avenir du logiciel médical n'est pas dans des formulaires toujours plus structurés. C'est dans des systèmes qui comprennent d'abord les cliniciens — et structurent les données ensuite.

Ceci est la première partie d'une série en trois articles sur l'IA dans doctoLys. Dans le prochain article, nous explorons le développement assisté par IA — comment l'IA générative a changé ce qu'un médecin-développeur peut construire seul, et ce que cela signifie pour la vitesse, le coût et la qualité du développement de logiciels de santé.

---

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.