Par Alkis Papadopoullos, CEO et CTO de Coginov

Vous êtes éditeur d’ERP mid-market. Un architecte senior vous montre lundi matin une démo : un appel LLM, un schéma JSON, quelques exemples en few-shot, et voilà — l’extracteur de factures fonctionne. Il lit les en-têtes, il attrape les lignes, il sort du JSON propre qui se branche directement dans votre module Comptes fournisseurs. L’équipe estime un trimestre pour industrialiser. Le vendeur d’à-côté vous propose une plateforme d’extraction documentaire à cinq chiffres par an. La conversation « construire ou acheter » se tranche dans la salle, sur la démo, et construire gagne — parce qu’à ce stade précis, construire est effectivement bon marché.

Je vais concéder la partie facile d’emblée, précisément et sans réserve. Si votre catalogue documentaire est étroit (factures fournisseurs, bons de commande, quelques variantes), homogène (vos clients travaillent tous avec la même dizaine de fournisseurs récurrents), et si le flux ne circule que vers votre propre schéma ERP, vous devriez le construire. Un LLM frontière plus un schéma JSON plus deux semaines de prompt engineering vous amène à une qualité démo tout à fait défendable. La démonstration n’est pas mensongère. Elle est simplement incomplète.

L’argument contre le « construire » n’est pas un argument de capacité. C’est un argument de cadence.

La couche modèle évolue tous les quelques mois. GPT-4o remplace GPT-4, Claude 3.5 remplace 3, Qwen sort une nouvelle génération, Llama passe de 2 à 3 puis à 3.1. Chaque saut change les caractéristiques d’extraction — pas seulement la précision moyenne, mais la distribution des erreurs, la façon dont le modèle gère les cas limites, sa sensibilité à la mise en page, son comportement sur les documents manuscrits ou dégradés. Un train de livraison ERP, lui, avance tous les 12 à 24 mois, avec des certifications comptables, des exigences réglementaires nationales, des cycles de recette client, des matrices de compatibilité de version. Construire son propre extracteur, c’est coupler structurellement un composant rapide à un composant lent. La conséquence n’est pas théorique : la qualité d’extraction de votre produit se fige, en termes relatifs, par rapport à la frontière du modèle. Deux ans après la démo, vous n’êtes pas là où pense la démo — vous êtes deux générations de modèle en arrière, sans que personne dans votre organisation ne mesure activement l’écart.

Et c’est là que se cache le vrai coût, celui qui tue ces projets une fois passés en production. Ce n’est pas l’extracteur. L’extracteur est la partie visible et flatteuse. Le coût est dans l’appareillage autour. Nommons-le, parce que c’est la conversation que la démo esquive :

La calibration de la confiance : quand le modèle sort un numéro de TVA, quel score interne autorise le passage direct au workflow, et lequel exige une validation humaine ? Un LLM produit du texte plausible ; il ne produit pas naturellement une probabilité calibrée sur laquelle vous pouvez router.

Le routage des exceptions : quand la confiance descend, où va le document ? Qui le voit ? Combien de temps s’accumule-t-il dans une file avant de dégrader le SLA client ? Quelle interface de validation, quels raccourcis clavier, quelle télémétrie sur les corrections humaines pour renourrir l’amélioration ?

La dérive de mise en page par locataire : votre client A reçoit des factures d’une centaine de fournisseurs récurrents ; votre client B en reçoit d’une centaine différente. Le fournisseur X refond sa facture au T2. Le modèle qui marchait à 94 % sur ce gabarit tombe silencieusement. Personne ne s’en rend compte pendant six semaines parce que personne n’a instrumenté la dérive par locataire, par émetteur, par gabarit.

Le harnais de régression : le jour où vous passez de GPT-4o à son successeur — parce que vous devez, parce que le prix a bougé, parce que l’ancien est déprécié — comment savez-vous que la précision sur les factures manuscrites du client francophone n’a pas chuté de 8 points ? Il faut un corpus de test versionné, annoté, représentatif des locataires réels, exécuté à chaque mise à niveau, avec des seuils d’alerte par catégorie documentaire. Ce n’est pas un notebook Jupyter. C’est une discipline continue.

Aucun de ces quatre chantiers n’est visible dans la démo du trimestre. Chacun est un projet à part entière. Ensemble, ils constituent l’essentiel du travail réel — et l’essentiel de ce qui distingue une plateforme documentaire mature d’un joli prototype.

Nous avons touché ces murs de plein fouet en concevant l’architecture de QoreCapture pour des volumes non triviaux — de l’ordre du million de factures par an chez certains clients, avec une part importante de manuscrit, et une contrainte on-premise qui interdit d’appeler tranquillement une API cloud à chaque document. Le compromis latence/précision, la variabilité des performances entre types documentaires, la nécessité d’un router intelligent qui oriente chaque document vers le bon modèle selon sa nature — ce sont des problèmes qui n’apparaissent que quand on quitte le régime de la démo. Notre architecture hybride cloud/local est née de cette réalité-là : aucun modèle unique ne domine sur toute la distribution documentaire d’un client mid-market, et la frontière bouge trop vite pour qu’un choix figé tienne 24 mois.

Deuxième asymétrie, plus stratégique. Les documents de vos clients ne circulent pas uniquement vers votre ERP. Ils circulent aussi vers leur outil de trésorerie, vers leur DMS, vers leur solution de conformité fiscale, vers le CRM du commercial qui veut voir les bons de commande côté client. Et vos revendeurs — parlons franchement du canal Sage en France et au Québec — vendent dans des parcs hétérogènes. Le client final a rarement un seul éditeur. Un extracteur qui ne sait sortir que vers votre schéma est un extracteur qui perd la moitié de sa valeur pratique. La couche connecteurs, la standardisation via MCP, la capacité à sortir vers plusieurs destinations sans reconstruire — c’est précisément ce qui fait qu’intégrer une plateforme externe n’est pas le verrouillage qu’on craint. Le verrouillage réel est ailleurs : dans le code d’extraction propriétaire que vous ne pourrez plus maintenir à la cadence de la frontière quand votre architecte senior aura changé d’équipe.

Donc que faire lundi matin, concrètement, si vous êtes l’éditeur d’ERP dans la salle de démo ?

Posez trois questions à votre architecte, avant la décision. Un : comment mesurons-nous la dérive de précision par locataire et par gabarit d’émetteur, en continu, sans intervention humaine ? Deux : quel est notre plan opérationnel de mise à niveau du modèle sous-jacent tous les six à neuf mois, harnais de régression compris, et qui possède ce budget ? Trois : quand un client demande que ses documents alimentent aussi son outil X — pas notre ERP — combien de trimestres cela nous coûte-t-il ?

Si les trois réponses sont solides, construisez. Vous avez raison, et le trimestre annoncé est réaliste.

Si l’une des trois réponses est un haussement d’épaules poli, vous ne regardez pas un projet d’un trimestre. Vous regardez une dette d’ingénierie de trois ans, qui commencera à se manifester au moment précis où votre concurrent, lui, aura branché une couche d’extraction qu’il n’a pas à maintenir au rythme de la frontière.

La démo n’est pas le mensonge. La démo est vraie. C’est la cadence qui est le mensonge.

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