Par Alkis Papadopoullos, CEO et CTO de Coginov

Si vous concevez aujourd’hui un pipeline d’extraction documentaire pour un client qui traite des factures fournisseurs, des bons de commande, des contrats-cadres — la question qui monopolise vos réunions d’architecture n’est plus « quel modèle utiliser ». Elle l’était en 2023. Aujourd’hui, la question est : où route-t-on chaque classe de document, et comment garantit-on que la validation reste dans le bon périmètre ?

La couche modèle s’est banalisée. Claude, GPT-4o, o1, Llama-2, Qwen — dans nos tests de détection d’entités nommées sur documents d’affaires, l’écart de score F1 entre les meilleurs modèles infonuagiques et un Llama-2 36B correctement finement ajusté tient dans quelques points de pourcentage. Nous stabilisons au-dessus de 90 % de F1 sur les deux voies. Ce qui différencie une extraction utilisable d’une extraction jetable ne se joue plus dans le choix du modèle. Cela se joue dans la topologie de routage et dans ce qui se passe après la sortie probabiliste du modèle.

Le vrai axe de décision : classe de document, résidence des données, seuil de confiance

Sur les engagements récents avec des clients Sage X3 et Sage 100cloud, nous avons cessé de raisonner en termes de « préférence de déploiement infonuagique ou local ». Ce n’est plus l’axe pertinent. L’axe pertinent est le triplet : classe de document × exigence de résidence × seuil de confiance minimal.

Concrètement, notre routeur intelligent — celui qui apprend à choisir le modèle optimal pour chaque document — ne fait pas qu’un arbitrage coût/latence/précision. Il applique une politique. Une facture fournisseur d’un client soumis à la Loi 25 avec mention contractuelle de non-sortie du périmètre : routage vers Llama-2 local, temps de réponse sous 2 secondes, seuil de confiance élevé pour envoi direct en validation automatique, en-dessous pour file de validation humaine. Un contrat standard d’un client sans contrainte de résidence : routage vers Claude ou GPT-4o, avec caching intelligent qui réduit sensiblement les appels API redondants.

Jusque-là, rien qui ne soit connu. Ce qui l’est moins, c’est la conséquence architecturale : la couche de connecteurs hérite de la topologie du routage. Si un document est inféré localement pour cause de résidence, ses appels de validation — vérifier le fournisseur, le numéro de bon de commande, le code de grand livre — doivent aussi rester à l’intérieur du périmètre. Sinon, on a bâti une architecture qui prétend respecter la résidence des données tout en fuitant les identifiants d’affaires vers un service externe au moment de la résolution. C’est un mode de défaillance silencieux et fréquent.

MCP, mais pas pour ce qu’on en dit habituellement

La plupart des textes sur Model Context Protocol le présentent comme la tuyauterie qui permet à un assistant conversationnel d’appeler des outils. C’est vrai, mais ce n’est pas l’usage à plus forte valeur pour un pipeline d’extraction.

L’usage à plus forte valeur, c’est la résolution au moment de l’inférence. Le modèle extrait le nom d’un fournisseur logistique mid-market avec une confiance élevée. Bien. Mais dans le fichier maître des fournisseurs de l’ERP du client, il en existe trois variantes — l’entité opérationnelle, la société de portefeuille, et une abréviation historique — trois entités juridiques distinctes, trois comptes de tiers différents, trois traitements comptables différents. L’extraction probabiliste, seule, ne tranche pas. Un appel MCP au fichier fournisseurs de Sage X3 au moment même de l’inférence — pas dans une étape de post-traitement décorrélée — transforme une assertion probabiliste en assertion vérifiée. Idem pour un numéro de bon de commande vérifié contre les bons ouverts. Idem pour un code de grand livre vérifié contre le plan comptable en vigueur.

Cela change la nature de la sortie. Ce n’est plus « le modèle pense que c’est X ». C’est « le modèle a proposé X, résolu contre le système de référence Y à l’instant T, et voici l’identifiant canonique ».

Client MCP et serveur MCP : la symétrie qui fait passer N×M à N+M

Le point que je vois rarement traité : un produit d’extraction sérieux doit se tenir aux deux bouts du fil MCP.

En tant que client MCP, il consomme les outils exposés par Sage, par le CRM, par le référentiel documentaire du client, par QoreUltima comme système de référence où atterrissent les assertions résolues. En tant que serveur MCP, il expose ses propres capacités d’extraction comme outils pour que l’agent d’un partenaire — l’assistant interne du client, un orchestrateur tiers, un copilote métier — appelle l’extraction comme une fonction, avec des garanties de contrat.

Cette symétrie n’est pas cosmétique. Elle transforme un problème d’intégration de N×M en N+M. Si vous avez N produits d’extraction et M systèmes d’affaires, et que chaque paire exige un connecteur bespoke, vous êtes coincé. Si chacun parle MCP dans les deux sens, chaque acteur implémente une interface, pas N-1.

Ce qui ne fonctionne pas — les compromis honnêtes

Le routage par classe de document ajoute une étape de classification préalable qui, dans nos premières itérations, faisait osciller les performances de façon marquée entre types de documents. Nous avons resserré cette variabilité avec un classifieur enrichi de métadonnées et d’analyse préliminaire de contenu, mais c’est une couche supplémentaire à maintenir, à réentraîner, et qui a ses propres modes de défaillance.

MCP au moment de l’inférence introduit une latence de résolution qui, sur des documents avec vingt entités à vérifier, se cumule. Il faut décider quelles résolutions sont bloquantes (le compte fournisseur — oui, sinon la ligne comptable est fausse) et lesquelles peuvent être asynchrones (l’enrichissement de métadonnées documentaires — non bloquant). Nous n’avons pas de règle universelle ; nous avons une matrice par classe de document, coconstruite avec le contrôleur du client.

Et le fine-tuning des modèles locaux, malgré un gain de F1 réel sur nos premiers cycles, reste coûteux à maintenir sur des cadences de mise à jour trimestrielles quand les documents-source évoluent. Nous avons industrialisé le pipeline, mais il exige une infrastructure d’annotation qu’un client sans équipe donnée dédiée ne peut pas soutenir seul.

Ce que vous pouvez faire différemment lundi

Si vous concevez ou opérez un pipeline d’extraction, arrêtez de traiter le choix du modèle comme la décision principale. La décision principale est la matrice classe de document × résidence × seuil de confiance, et le corollaire — la topologie de la couche de connecteurs doit épouser cette matrice, pas la contredire.

Deuxièmement, regardez MCP non pas comme un standard pour agents conversationnels, mais comme la couche de résolution qui transforme vos extractions probabilistes en assertions vérifiées contre les systèmes de référence de votre client. Et concevez dès aujourd’hui pour la symétrie client/serveur — sinon, dans dix-huit mois, vous réécrirez la couche d’intégration.

Le modèle est devenu la commodité. La couche de connecteurs, la politique de routage, et la discipline de résolution sont l’actif durable.

Visitez notre nouvelle page de solutions QoreCapture pour les institutions muséales!