Découvrir l'article
Pour traiter efficacement 250 000 documents médicaux par mois, l'assureur santé Alan a remplacé l'OCR traditionnel par des LLM optimisés via le few-shot retrieval. Le succès de cette automatisation repose sur une ingénierie robuste et un contrôle qualité strict, plutôt que sur le fine-tuning complexe de modèles. L'entreprise vise désormais 2026 avec une approche "agentique", permettant à ses équipes opérationnelles d'améliorer directement ces pipelines avec l'aide d'agents IA.
Le few-shot retrieval comme moteur : Injecter des exemples validés par des humains directement dans les LLM permet d'automatiser 70 % du traitement des documents.
L'ingénierie bat le fine-tuning : Le succès repose sur la structuration des données (Markdown), les garde-fous et le contrôle qualité, plutôt que sur le réentraînement coûteux de modèles.
L'autonomie via les agents IA : L'objectif est de permettre aux équipes opérationnelles de modifier elles-mêmes les pipelines de traitement en collaborant avec des agents IA, sans dépendre des ingénieurs.
Quand un membre Alan prend en photo sa facture d’ostéopathe et l’envoie via l’application, il s’attend à être remboursé en quelques heures. Pas en quelques jours. Aujourd’hui, 55 % des événements de soins chez Alan sont remboursés en moins de cinq minutes. Derrière cette promesse, un pipeline de traitement documentaire qui ingère 250 000 documents par mois rien qu’en France et en Belgique.
J’ai reçu Thomas Porez dans Paroles d’IA pour qu’il nous raconte deux ans d’itération sur ce sujet. Thomas est responsable du document processing chez Alan, la surtech française qui se positionne comme “partenaire santé” – pas seulement assureur. Avant Alan, il était Lead Architect chez Tinyclues. On se connaît depuis plus de dix ans, époque Adomic, où l’on optimisait les revenus publicitaires avec du Scala sur S3 – le far west du big data.
Ce qui ressort de notre échange : le traitement documentaire intelligent n’est pas un problème de modèle. C’est un problème d’ingénierie, de garde-fous et d’itération patiente.
Le point de départ chez Alan est simple et brutal. Chaque document reçu – facture de spécialiste, prescription, décompte de Sécurité sociale, devis dentaire, attestation – est envoyé à un prestataire externe (Tessi) où des opérateurs humains saisissent manuellement les informations dans un formulaire structuré. Chaque traitement coûte environ deux euros et prend plusieurs minutes, parfois plusieurs heures.
La diversité est le premier défi. Thomas l’explique sans détour : “On a des factures, des prescriptions, des décomptes de sécu, des devis, des attestations. En France, en Belgique avec plusieurs langues, en Espagne, au Canada. Les typologies de documents sont très hétérogènes.” La saisie manuelle ne scale pas. La croissance organique d’Alan rendait le modèle intenable.
Les premières tentatives d’automatisation passent par des expressions régulières appliquées sur le texte extrait par OCR. Ça fonctionne pour les documents bien structurés – les décomptes de Sécu, par exemple, dont le format change peu. Mais les limites apparaissent vite. L’OCR rate des caractères, les templates varient d’un praticien à l’autre, et les photos envoyées par les membres sont loin d’être des PDF bien formatés. Thomas décrit la réalité du terrain : “La personne a pris la facture, elle l’a mise dans sa poche, pliée en quatre, dans son portefeuille, c’est un peu corné, un peu taché, pris en photo de travers avec une ombre ou une grosse main en plein milieu.”
En 2023, l’équipe commence à expérimenter avec les LLM. Le lien avec le traitement documentaire n’est pas immédiatement évident pour tout le monde. Thomas l’admet : “Moi, de loin, je m’étais dit : mais pourquoi les LLM pour faire des extractions de docu ? Pour moi, c’était des chats, je n’arrivais pas à faire le lien.”
L’avantage décisif des LLM sur les regex apparaît rapidement : la résilience aux erreurs d’OCR. Un LLM comprend que “paracétamal” dans une facture de pharmacie signifie “paracétamol”. Il combine les signaux du document pour produire une compréhension contextuelle, pas une extraction mécanique.
Mais les LLM de 2023 posent leurs propres problèmes. Les outputs structurés sont instables. Le JSON mode, quand il existe, biaise les résultats. Thomas et son équipe doivent bâtir couche sur couche de garde-fous en Python : validation de dates, détection d’anomalies, vérification de cohérence. “Une facture qui a plus de deux ans, c’est louche. On la garde parce que c’est peut-être vrai, mais on demande à Tessie d’aller regarder le document.”
L’analogie que Thomas utilise est parlante : “J’ai l’impression d’être sur un pur-sang. Le truc est puissant, mais il faut le dompter parce qu’il peut vite partir dans le décor.”
Le vrai gain de performance vient d’une technique que Thomas recommande à tous ceux qui travaillent sur du document processing : injecter dans le prompt des exemples de traitements passés, vérifiés par des humains.
Alan contrôle 2 % de ses traitements via des opérateurs humains. Ces documents contrôlés constituent un pool de référence. Quand un nouveau document arrive, le système calcule son embedding textuel, cherche les documents similaires dans cette base de référence, et les injecte dans le prompt avec leur output structuré validé.
Thomas décrit l’impact : “D’un seul coup, on a une recette de cuisine qu’on peut appliquer à tous les documents. Plutôt que d’avoir des prompts craftés par type de document, on prend un document, on le transforme en texte, on va piocher des exemples similaires, on les injecte, et on dit : fais le traitement.”
Le pattern matching des LLM fait le reste. Le modèle comprend automatiquement que tel format de document doit produire tel output structuré, simplement parce qu’il voit des exemples similaires déjà traités. C’est cette approche qui porte les 70 % d’automatisation actuels en France.
Une limite persiste : le texte à plat perd l’information structurelle du document. Sur une facture d’ostéopathe en texte libre, ce n’est pas critique. Sur un décompte de Sécu avec des tableaux imbriqués, des codes couleurs et des colonnes mergées, c’est rédhibitoire.
En 2024, l’équipe passe à une représentation Markdown intermédiaire. AWS Textract fournit des bounding boxes et de la détection d’entités (titres, headers de tableau, cellules, signatures). Une librairie open source d’AWS, forkée et améliorée par Alan, transforme ces résultats en Markdown structuré. Les tableaux deviennent lisibles pour le LLM.
Thomas mentionne aussi des approches émergentes, notamment Pixtral de Mistral, capable d’encoder les tableaux complexes en HTML. Mais l’équipe reste pragmatique : “On a plutôt essayé d’aller saigner ce filon et d’aller au bout de cette logique plutôt que d’embrayer sur une autre approche plus incertaine.”
Le point que Thomas martèle tout au long de notre conversation : l’automatisation ne vaut rien sans mesure de qualité rigoureuse. Alan contrôle 2 % des traitements a posteriori. Les erreurs sont classées en critiques (impact sur le remboursement – une date erronée peut changer le calcul) et non critiques (le nom du médecin mal orthographié).
Le monitoring tourne en permanence. Quand une régression apparaît – Thomas cite l’exemple d’un bug sur les factures de psychologues, détecté par alerting automatique – l’équipe intervient. Les membres qui constatent une erreur contactent le support, qui peut corriger les extractions. Ces corrections remontent dans le monitoring, créant une boucle de feedback.
“C’est un conseil que je donnerais aux gens qui veulent faire du traitement de documents : bien formaliser cette notion de qualité. C’est ce qui nous permet d’avancer sereinement.”
La frustration de Thomas n’est pas sur la performance des modèles. C’est sur la bande passante humaine. “Les modèles sont assez intelligents pour automatiser 90 % des documents. Ce n’est plus un problème d’intelligence de modèles. C’est une question d’assemblage, de garde-fous.”
L’ambition pour 2026 est claire : découpler l’amélioration des pipelines de la disponibilité des ingénieurs. Alan construit un système où un “AI Supervisor” – un profil ops, pas ingénieur – travaille en binôme avec un agent IA type Claude Code. Le scénario concret : l’ops identifie un problème récurrent sur un type de document, constitue un dataset de référence avec les erreurs corrigées, et demande à l’agent de modifier les pipelines, lancer des expériences, vérifier les résultats et ouvrir une PR.
Thomas l’a testé en POC avec Claude Code : “Je l’ai vu être capable de faire des modifications de code dans la configuration de notre système, de lancer une expérience, de regarder les résultats, de s’assurer que ça avait bien corrigé les problèmes, et d’ouvrir une PR.”
La vision plus large chez Alan : “anyone can build”. Des designers ouvrent déjà des PR dans l’application. L’ingénieur se recentre sur l’infrastructure et les garde-fous. Le code devient un artefact produit par des agents, supervisé par des humains qui comprennent le métier.
Question récurrente dans le document processing : pourquoi ne pas fine-tuner un modèle sur vos données ? Thomas assume la position : “Ma conviction, c’est que c’est un combat perdu d’avance en termes de ROI. C’est lourd à mettre en place, lourd d’entraîner des modèles. Je pense que c’est la fin de la chaîne – quand on aura été au bout de ce qu’on peut faire avec les modèles généralistes.”
Pragmatisme, encore. Les modèles OpenAI via Azure (certifié HDS pour les données de santé) suffisent. Le few-shot retrieval compense l’absence de spécialisation. Le fine-tuning viendra peut-être, mais pas avant d’avoir épuisé les approches plus simples.
L’expérience d’Alan illustre une trajectoire que nous observons chez de nombreux clients : la valeur ne vient pas du modèle le plus gros ou le plus récent, mais de l’ingénierie autour du modèle. Few-shot retrieval, garde-fous de qualité, monitoring en production, routage par complexité – ce sont ces briques qui font la différence entre un POC impressionnant et un système qui tourne à 250 000 documents par mois.
Pour les entreprises qui traitent des volumes documentaires importants, trois enseignements à retenir :
Chez Molia, nous accompagnons les entreprises sur l’ensemble de cette chaîne – de l’extraction documentaire à l’industrialisation des pipelines IA en production, y compris sur des données sensibles soumises à des contraintes réglementaires fortes. C’est le coeur de notre expertise en traitement documentaire intelligent.
Cet article est tiré de l’épisode 14 de Paroles d’IA, le podcast animé par Paul Mochkovitch. Pour écouter l’échange complet avec Thomas Porez (Alan), c’est ici.
Tous droits réservés. © 2026 Molia.
