Docuvera : Des documents AI qui prennent des décisions, pas des extractions

Il y a un moment que toute entreprise lourde en documents a vécu. Quelqu’un uploade un PDF, le fait passer dans un outil OCR, récupère en retour un mur de texte, et ensuite… et maintenant ?

L’outil a fait son travail. T’as les données. Mais tu dois toujours comprendre ce qu’elles signifient, si elles sont conformes, quoi faire ensuite. Ce n’est pas de l’automatisation. C’est de la transcription avec des étapes supplémentaires.

Cette réalisation est ce qui a mené à Docuvera.

Ce que les outils existants ratent

AWS Textract et Google Document AI sont vraiment bons dans ce qu’ils font. Ils extraient le texte des documents avec une bonne précision. Ils gèrent les tableaux, les formulaires, les signatures. Ils sont rapides et ils scalent.

Mais l’extraction, c’est l’étape un sur cinq.

L’étape deux c’est comprendre le contexte — est-ce un dossier médical ou un contrat juridique ? L’étape trois c’est la validation — est-ce que ça correspond au schéma qui t’intéresse vraiment ? L’étape quatre c’est le flagging — qu’est-ce qui manque, qu’est-ce qui est faux, qu’est-ce qui nécessite une révision humaine ? L’étape cinq c’est le routing — où vont ces informations, et quelle action ça déclenche ?

Les outils OCR du marché s’arrêtent à l’étape un et te laissent le reste. Pour une petite équipe qui traite quelques centaines de documents par mois, c’est gérable. Pour une entreprise avec des milliers de pages par semaine sur plusieurs types de documents dans plusieurs environnements réglementaires, c’est un goulot d’étranglement qui ne disparaît jamais.

Ce que Docuvera fait différemment

Le pari de base : l’intelligence de domaine est plus précieuse que l’extraction générique.

Un formulaire de prise en charge médicale n’est pas la même chose qu’une déclaration d’assurance, même si les deux sont des PDFs avec des cases à cocher et des signatures. Les champs qui importent sont différents. Les règles de validation sont différentes. Les exigences de conformité sont différentes.

Donc au lieu de construire un seul modèle qui lit tout de façon générique, nous avons construit 12 spécialisations verticales — santé, juridique, finance, logistique, construction, industrie, et plus. Chaque modèle est pré-entraîné sur des données spécifiques au domaine. Il sait à quoi ressemble un code CPT valide. Il sait la différence entre un bon de commande et un reçu de livraison.

Quand Docuvera traite un document, il produit des données structurées avec des scores de confiance, signale les anomalies par rapport aux règles du domaine, vérifie les exigences de conformité, et route le résultat vers le bon workflow. C’est ce que “des décisions, pas des extractions” signifie en pratique.

Comment nous l’avons construit

Le problème des données d’entraînement était la partie la plus difficile.

Tu ne peux pas entraîner un modèle de documents de santé sur du texte générique. T’as besoin de vrais dossiers médicaux, formulaires de prise en charge, demandes d’autorisation préalable — suffisamment d’eux, avec suffisamment de variation, pour construire quelque chose qui généralise. Nous avons fini avec des millions de points de données spécifiques au domaine sur les 12 verticales. Sourcer, nettoyer, étiqueter, et structurer ça pour l’entraînement a pris plus de temps que construire le pipeline d’inférence.

L’architecture est un pipeline multi-étapes. Premier passage : classification du document — quel type de document c’est, quel modèle vertical s’applique. Deuxième passage : extraction de champs en utilisant le modèle spécifique au domaine. Troisième passage : validation par rapport aux règles du domaine. Quatrième passage : scoring de confiance et flagging d’anomalies. Cinquième passage : formatage de la sortie et routing.

Chaque étape est réglable indépendamment. Si les documents d’un client ont des particularités spécifiques, on peut fine-tuner au niveau du modèle vertical sans toucher le pipeline principal.

La vitesse de traitement était une contrainte que nous avons prise au sérieux. Environ 2 secondes par page à l’échelle de production. C’est le débit moyen sous charge, pas un benchmark sur un document unique. Pour une équipe qui traite des milliers de pages par jour, les maths comptent.

Chiffres réels

Les métriques qui ont finalement le plus compté :

~95% de précision sur l’extraction de champs sur toutes les verticales. Ce chiffre compte moins comme titre et plus comme plancher — le scoring de confiance attrape le reste et le route vers la révision humaine plutôt que de laisser passer silencieusement des données mauvaises.

~2 secondes par page en temps de traitement moyen. Assez rapide pour que le traitement de documents ne soit plus un problème de planification.

~4,5 heures par semaine économisées par employé qui touchait précédemment des documents manuellement.

L’angle conformité

Les industries réglementées ne veulent pas seulement une extraction précise — elles ont besoin d’une piste d’audit.

Le RGPD exige de savoir quelles données personnelles existent dans tes documents, d’où elles viennent, et qui y a touché. L’OSHA exige des formats de journaux spécifiques et des politiques de rétention. La santé a le HIPAA. La finance a une douzaine de frameworks qui se recoupent.

Intégrer la conscience de la conformité dans le pipeline de traitement, pas comme un module ajouté, a changé le produit de façon significative. Docuvera signale automatiquement le PII, journalise chaque étape de traitement avec des timestamps et des versions de modèle, et produit des rapports de conformité comme sortie de premier plan.

Ça s’est avéré être un différenciateur plus important que les chiffres de précision. Les entreprises dans les industries réglementées ne veulent pas juste un processeur de documents plus rapide — elles en veulent un qu’elles peuvent auditer.

Ce que j’ai appris

Les problèmes techniques étaient difficiles. Le problème de connaissance du domaine était plus difficile.

Tu peux embaucher des ingénieurs pour construire un pipeline. Tu ne peux pas court-circuiter le processus de vraiment comprendre 12 industries assez bien pour construire des modèles utiles en production. Ça a nécessité de parler à des centaines de praticiens — des facturateurs médicaux, des coordinateurs logistiques, des chefs de projet en construction — et de comprendre non seulement quels documents ils traitent mais pourquoi certains champs comptent.

La précision n’est pas l’objectif. La qualité de décision est l’objectif. Un système qui extrait 99% des champs correctement mais route la sortie vers le mauvais workflow est pire qu’inutile.

L’intelligence de domaine se cumule. Chaque spécialisation verticale rend les adjacentes plus faciles à construire. Le fossé défensif n’est pas l’architecture du pipeline — c’est la compréhension du domaine intégrée dans les modèles.