Photographier une ordonnance avec son téléphone et obtenir, dix secondes plus tard, la liste structurée de ses médicaments, leurs doses, leur durée et leur fréquence : c'est l'expérience que DossiMed propose à l'utilisateur. Derrière cette simplicité visible, le pipeline technique combine deux générations d'intelligence artificielle, un soin particulier porté à la confidentialité, et une frontière soigneusement gardée avec la responsabilité médicale. Cet article expose la logique de notre approche, sans entrer dans le détail des prompts, des modèles ni des paramètres internes.
Le défi de l'ordonnance manuscrite
Si vous avez déjà essayé d'utiliser un OCR grand public sur une ordonnance médicale, vous connaissez le résultat. Le texte produit ressemble à une suite de caractères incohérents, ponctuée de fragments reconnaissables. La cause est multiple :
- Écriture rapide et non standardisée — l'écriture médicale est souvent cursive, inclinée, et compressée
- Abréviations propres au métier — Dsp, mane, nocte, cp, amp ne figurent dans aucun dictionnaire grand public
- Mises en page hétérogènes — en-tête, corps de prescription, signature, tampon et mentions légales se mélangent sans grille fixe
- Langues mêlées — en-tête arabe, corps en français, noms latins de molécules dans un même document
- Qualité d'image dégradée — éclairage de cabinet, photo prise à la va-vite, document froissé ou partiellement caché
Pour un OCR généraliste, chacun de ces facteurs dégrade la précision. Mis bout à bout, ils rendent l'extraction inutilisable.
La pire conséquence d'un OCR médical défaillant n'est pas l'illisibilité : c'est l'erreur silencieuse. Un dosage mal lu peut produire un résultat plausible mais faux. Cela impose, pour une application santé, une approche radicalement différente du simple OCR.
Un pipeline en deux étages
L'approche que nous avons retenue s'articule en deux étages successifs, chacun spécialisé dans une tâche que les modèles d'IA actuels savent bien faire séparément.
Étage 1 — Extraction visuelle
Le premier étage est confié à un service moderne de Document Intelligence. Ce type de service est entraîné sur des documents structurés (factures, contrats, formulaires médicaux) et reconnaît à la fois les caractères et la mise en page. Il produit deux artefacts :
- Un texte brut qui restitue la séquence de mots du document
- Une représentation tabulaire qui reconnaît les colonnes et les lignes lorsque le document en contient (bilan biologique, par exemple)
À ce stade, on a transformé une image en texte. Mais ce texte reste bruité, ambigu et non structuré sémantiquement.
Étage 2 — Extraction sémantique
Le second étage est confié à un modèle de langage de génération frontière, configuré pour produire un JSON structuré à partir du texte brut. Le rôle de ce modèle est triple :
- Identifier les entités médicales — noms de médicaments, doses, fréquences, durées, instructions de prise, nom du médecin prescripteur, spécialité, date d'émission, lieu d'exercice
- Catégoriser le document — une ordonnance de médication, un compte-rendu d'analyse et une imagerie médicale n'ont pas la même structure attendue ; la catégorisation guide la suite du traitement
- Corriger les noms de médicaments mal orthographiés — l'OCR a renvoyé Glecnvanc 50 mg ; le modèle de langage propose Glivec 50 mg avec une note de confiance, et peut déclencher une vérification pharmacologique en ligne pour les cas ambigus
Le résultat est un JSON propre, prêt à être consommé par l'application : liste des médicaments avec leurs paramètres, métadonnées du document, indicateurs de confiance, alertes éventuelles.
La discipline de la vie privée
Un pipeline d'IA documentaire en santé soulève une question évidente : qu'est-ce qu'on envoie au modèle d'IA ? La régulation européenne, et la décence, imposent que la réponse soit la plus minimale possible.
Aucune donnée nominative du patient n'est transmise au modèle. Le nom, la date de naissance, le numéro de sécurité sociale, les allergies, les conditions chroniques préexistantes — rien de tout cela ne traverse les frontières du serveur d'IA. Le modèle reçoit uniquement le contenu textuel du document, qu'il doit transformer en structure.
Ce principe a deux implications pratiques :
- Limitation du risque de fuite — même un incident chez le fournisseur d'IA tiers ne révélerait pas l'identité des patients
- Conformité RGPD simplifiée — aucune donnée de catégorie particulière (article 9) ne quitte la juridiction européenne au sens élargi
La conséquence négative — qui mérite d'être nommée — est que le modèle ne peut pas s'appuyer sur le contexte patient pour lever les ambiguïtés. Dans ces cas, la ligne d'extraction est marquée comme nécessitant une révision utilisateur, et l'application demande une confirmation manuelle.
Le multilinguisme dans l'IA documentaire
Le pipeline doit gérer indifféremment des ordonnances rédigées en français, en arabe, en anglais, et fréquemment en plusieurs langues simultanément (en-tête arabe, corps français, signature en latin). Cette caractéristique, banale dans la pratique médicale du Maghreb et du Moyen-Orient, est un défi technique sous-estimé.
L'arabe pose particulièrement problème : son alphabet cursif complique l'OCR, et la direction d'écriture droite-gauche introduit des artefacts dans la séquence textuelle si le pipeline n'est pas correctement configuré.
Notre choix : ne pas pré-déclarer la langue du document. Le pipeline détecte automatiquement la langue dominante en s'appuyant sur les caractères et le vocabulaire reconnus, et adapte le post-traitement en conséquence. Pour l'utilisateur, cela signifie qu'il photographie son ordonnance comme elle est, sans avoir à choisir une option de langue.
La validation humaine en dernier maillon
Une décision de conception structurelle distingue DossiMed des outils d'aide à la décision médicale : l'utilisateur valide toujours le résultat de l'extraction. Lorsque le pipeline a produit le JSON structuré, l'application l'affiche dans l'écran de détail avec les champs éditables. L'utilisateur peut corriger un nom mal lu, ajuster une dose, modifier la fréquence, supprimer une ligne. Ce qui générera les rappels est ce que l'utilisateur a validé, pas ce que l'IA a inféré.
Ce pattern n'est pas seulement une décision UX. C'est une décision réglementaire. En ne prenant aucune décision médicale autonome — pas de proposition de dose, pas d'alerte d'interaction médicamenteuse, pas d'interprétation de résultat biologique — DossiMed reste sous le seuil de classification dispositif médical logiciel au sens du règlement européen MDR 2017/745. L'IA propose, l'utilisateur dispose, le médecin prescripteur reste responsable.
La gestion des cas d'erreur
Aucun pipeline d'IA n'est parfait. Le nôtre prévoit explicitement les cas d'erreur, et les gère sans masquer la difficulté à l'utilisateur.
Confidence OCR trop basse — image floue, document partiellement caché, lumière insuffisante. Le statut de la prescription est mis à needs_review plutôt que de produire une extraction incertaine. L'application invite l'utilisateur à reprendre la photo dans de meilleures conditions, ou à corriger manuellement les champs.
Incertitude du modèle de langage — lorsque le LLM signale une incertitude sur un médicament ou une posologie, le champ correspondant est affiché avec un indicateur visuel. L'utilisateur sait qu'il doit vérifier avec son ordonnance avant que le calendrier de prise ne soit généré.
Document non médical — un filtre préalable détecte l'absence des marqueurs médicaux attendus (ordonnance, posologie, analyse, laboratoire, etc.) et rejette poliment le document avant le traitement coûteux. Cette discipline protège à la fois la qualité de l'expérience utilisateur et le coût d'exploitation : on ne paie pas un appel d'IA générative pour traiter une photo de chat.
Ce que le pipeline garantit
- Aucun secret ou donnée nominative transmis au modèle d'IA tiers
- Validation utilisateur obligatoire avant toute génération de rappel
- Statut needs_review explicite en cas de confiance insuffisante
- Rejet préalable des documents non médicaux pour maîtriser les coûts
- Portabilité : la couche extraction peut être remplacée par n'importe quel fournisseur concurrent
Une plateforme prête à porter
Le pipeline complet — extraction visuelle, extraction sémantique, validation, intégration dans la base structurée — est implémenté en quelques fonctions edge serverless. Il est portable d'un fournisseur d'IA à un autre : la couche d'extraction visuelle peut être remplacée par n'importe quel service de Document Intelligence concurrent ; la couche sémantique peut être remplacée par n'importe quel modèle frontière capable de produire du JSON structuré — modèles managés par les grands fournisseurs cloud, modèles open weights auto-hébergés.
Cette portabilité est une propriété précieuse pour une organisation qui voudrait déployer DossiMed dans son cloud souverain ou avec son propre LLM interne. Le code applicatif ne fait aucune supposition irréversible sur le fournisseur sous-jacent.
Pour les patients, le résultat est une application qui transforme une photo froissée d'ordonnance en un dossier médical structuré, lisible, partageable avec leur médecin. Pour les organisations qui pourraient en hériter, c'est une plateforme dont le moteur d'IA documentaire peut être branché sur l'infrastructure de leur choix.
DossiMed est édité par REC, une SUARL tunisienne totalement exportatrice. Pour toute question commerciale ou de partenariat stratégique, écrivez à contact@dossimed.ai.