1Dans quels cas vaut-il mieux développer ses propres modèles d'extraction en interne ?
Trois conditions cumulatives rendent le développement interne défendable et l'apport d'un éditeur marginal : périmètre documentaire figé, volumétrie faible, équipe MLOps interne permanente en place. Sinon, deux contreparties se chiffrent. Selon l'IEEE Computer Society et ISO/IEC/IEEE 14764:2022, la maintenance pèse 60 à 80 % du coût de cycle de vie d'un logiciel : pour un logiciel classique, un coût total d'environ trois fois le développement. Pour un système d'IA, provisionner le double, environ six fois : extrapolation étrangère à la norme, tirée de l'infrastructure de données, de validation et de supervision autour du code (D. Sculley et al., NeurIPS 2015). Gartner (juillet 2024) évalue à au moins 30 % les projets d'IA générative abandonnés après la preuve de concept ; la RAND Corporation (RR-A2680-1, 2024) les impute à des causes majoritairement organisationnelles. En assurance vie, la première tient rarement : nouveaux distributeurs, évolutions réglementaires, dérive de canal, reprises de portefeuille déplacent le périmètre par construction.
2Un LLM généraliste appelé en API suffit-il pour extraire des données de documents ?
Oui pour un POC : un modèle généraliste bien prompté, schéma JSON imposé, suffit à qualifier le besoin sur un échantillon restreint. Le passage en production est le point de rupture : selon Gartner (juillet 2024), au moins 30 % des projets d'IA générative sont abandonnés après la preuve de concept. Quatre choses cassent. La conformité de sortie : la part de réponses non conformes au schéma varie fortement d'un modèle à l'autre ; exigez-la mesurée sur votre propre jeu de test versionné, car elle fixe le taux d'automatisation réel autant que l'exactitude moyenne. La précision métier : l'écart entre un généraliste et un modèle spécialisé se mesure chez vous, même jeu, même métrique. Le coût au volume : une facturation au jeton suit la volumétrie annuelle réelle, qu'un échantillon ne révèle pas. Enfin, la dépendance de version : un modèle appelé à distance évolue et se déprécie sans vous, ce qui rejoue la recette du prompt et du schéma à chaque changement — une charge de maintenance récurrente que le POC ne fait pas apparaître.
3Quel budget pluriannuel provisionner pour un système d'IA d'extraction en production ?
Environ six fois le coût de développement initial : c'est une déduction du constat de l'IEEE Computer Society normalisé par ISO/IEC/IEEE 14764:2022, pas un chiffre publié. Selon l'IEEE Computer Society, la maintenance représente 60 à 80 % du coût de cycle de vie d'un logiciel ; par complément, le développement initial n'en pèse que 20 à 40 %, soit un coût de possession d'environ trois fois ce développement pour un logiciel classique. Doubler ce multiple pour un système d'apprentissage s'appuie sur le constat qualitatif de D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015 (Google), qui n'avance lui-même aucun multiple : le code du modèle n'est qu'une fraction minime du système, l'essentiel étant l'infrastructure de données, de validation et de supervision, plus la ré-annotation à chaque dérive. Le raisonnement vaut aussi pour une plateforme éditeur : seule change la répartition de la charge.
4Pourquoi tant de projets d'IA documentaire ne dépassent-ils pas le stade du POC ?
Les causes sont d'abord organisationnelles, pas techniques : la RAND Corporation (RR-A2680-1, 2024) relève un taux d'échec élevé des projets d'IA, imputable majoritairement à des facteurs d'organisation, et Gartner (juillet 2024) estime qu'au moins 30 % des projets d'IA générative sont abandonnés après la preuve de concept. L'explication est ancienne : selon Sculley et al. (Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015, Google), le code du modèle n'est qu'une fraction minime d'un système d'apprentissage en production, l'essentiel étant l'infrastructure de données, de validation et de supervision — précisément ce qu'un POC ne contient pas. Passer en production suppose de réunir huit postes d'exploitation : annotation et ré-annotation, plateforme MLOps, détection de dérive et score de confiance par champ, correction humaine, orchestration métier, conformité, montées de version, réversibilité et astreinte. Cela vaut pour toute option, plateforme éditeur comprise : un POC réussi ne dit rien de ces huit postes.
5Quels postes de coût récurrents faut-il faire chiffrer dans un projet d'IA documentaire ?
Huit postes d'exploitation à chiffrer, outre le développement : annotation initiale, ré-annotation à chaque dérive ; plateforme MLOps (registre de modèles, données versionnées, intégration continue) ; détection de dérive, score de confiance par champ ; correction humaine, reprise sur erreur ; orchestration métier ; conformité (SIEM, secrets, habilitations, tests de sécurité) ; montées de version ; réversibilité, documentation, transfert de compétences, astreinte. L'IEEE Computer Society situe la maintenance à 60-80 % du coût de possession d'un logiciel (ISO/IEC/IEEE 14764:2022) : le développement initial n'en représente que 20 à 40 %, soit un coût total d'environ trois fois le développement initial. Pour un système d'apprentissage, doubler ce multiple — environ six fois le développement : déduction, non mesure de l'IEEE. Sculley et al. (NeurIPS 2015) : le code du modèle n'y est qu'une fraction minime, l'essentiel étant l'infrastructure de données, de validation, de supervision. À concevoir et chiffrer des deux côtés : avec une plateforme éditeur, infrastructure, intégration, paramétrage, recette et exploitation restent à votre charge.
6Comment comparer les taux de précision annoncés par deux fournisseurs ?
Un taux de précision ne veut rien dire sans son protocole : quel jeu de test, quel périmètre de champs, quelle définition d'une erreur, documents propres ou flux de production réel, mesure avant ou après correction humaine. Une moyenne masque sa distribution : un champ rare mais décisif pèse peu dans une moyenne pondérée par le volume, d'où le détail champ par champ. Surtout, l'exactitude moyenne ne dit rien de ce qui se passe quand le modèle se trompe, et c'est là que se joue le coût réel. Trois capacités se testent séparément : savoir qu'on ne sait pas, via un score de confiance par champ qui permet de router un dossier douteux plutôt que de le laisser passer ; détecter l'erreur autrement que par l'exactitude, par des contrôles de cohérence entre pièces et de conformité au schéma attendu — une sortie inexploitable n'étant qu'un cas d'erreur parmi d'autres, mais celui qui bloque un acte ; et corriger dans le flux, au champ, sans ressortir de l'outil. Pour ramener deux offres sur la même base : un jeu de test versionné que vous détenez, la même métrique et le même corpus pour tous les candidats, un score de confiance par champ. Aucun chiffre de plaquette, quel qu'en soit l'auteur, ne vaut avant ce test.
7Quelles compétences internes faut-il pour exploiter une IA documentaire au quotidien ?
Une équipe d'exploitation classique peut tenir une plateforme éditeur déployée dans votre périmètre ; un développement interne demande davantage, sauf à réunir trois conditions : périmètre documentaire figé, volumétrie faible, équipe MLOps interne permanente déjà en place. D. Sculley et al. (Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015, Google) ont établi que le code du modèle n'est qu'une fraction minime d'un système d'apprentissage en production : l'essentiel est l'infrastructure de données, de validation et de supervision. La compétence à réunir n'est donc pas de construire un modèle, mais de tenir huit postes d'exploitation, à concevoir et chiffrer : annotation initiale et ré-annotation à chaque dérive ; plateforme MLOps (registre de modèles, jeux de données versionnés, intégration continue) ; détection de dérive et score de confiance par champ ; correction humaine et reprise sur erreur ; orchestration métier ; conformité ; montées de version de la pile ; réversibilité, documentation, transfert de compétences et astreinte.
8L'IA sait-elle lire des liasses dont chaque distributeur a son propre formulaire ?
Oui pour la lecture, non pour la validation. Les moteurs d'extraction documentaire savent lire les pièces d'une liasse de souscription — bulletin, mandat, pièce d'identité, RIB, justificatifs. Mais un catalogue éditeur porte sur des types de documents, jamais sur chaque variante de formulaire : en assurance vie, il y a autant de variantes que de distributeurs, de produits et de millésimes réglementaires, et chaque nouveau formulaire se recette. Ce qui décide du re-travail, autant que l'exactitude moyenne, c'est la part de sorties non conformes au schéma attendu : elle varie fortement d'un modèle à l'autre ; exigez-la mesurée sur votre propre jeu de test, pas sur un banc public. Le rapprochement des pièces, le contrôle de complétude et de cohérence restent humains. Aucun taux d'automatisation annoncé ne se transpose d'une liasse à l'autre : demandez toujours sur quel périmètre il a été mesuré.
9Faut-il continuer à relire tous les dossiers une fois l'extraction automatisée ?
Non, mais la sortie du contrôle intégral se construit : tant que les gestionnaires revérifient chaque champ, l'automatisation ne produit aucun gain, et cette question décide du retour sur investissement. Un score de confiance par champ permet de router les dossiers — validation directe, relecture ciblée, reprise complète — au lieu de tout relire, une interface de correction humaine absorbant les cas repris. Le routage n'est fiable que si les sorties respectent le schéma attendu : la part de non-conformité varie fortement d'un modèle à l'autre et pèse autant que l'exactitude moyenne sur le taux d'automatisation — exigez-la, mesurée sur votre propre jeu de test. Journaux d'audit complets et traçabilité de chaque décision rendent la baisse défendable devant le contrôle interne. Aucun taux cible ne se publie : il dépend du corpus et du risque accepté. Restent humains par construction le rapprochement de pièces, le contrôle de complétude et de cohérence, et les cas douteux.
10Comment concevoir un pilote qui permette de départager deux offres ?
Concevez le pilote pour qu'il continue en production, pas pour qu'il démontre : selon Gartner (juillet 2024), au moins 30 % des projets d'IA générative sont abandonnés après la preuve de concept. Fournissez un corpus que vous choisissez, avec les cas qui font dériver un modèle : photos au téléphone, scans dégradés, cachets électroniques, formats de nouveaux distributeurs. Imposez à tous les candidats le même jeu de test versionné et la même métrique, et écrivez les critères de réussite et d'arrêt avant de commencer. Une démo préparée ne prouve rien, d'où qu'elle vienne : exigez le traitement en direct de documents que le fournisseur n'a pas vus. Un POC « gratuit » coûte du temps métier : sélection des pièces, annotation de référence, arbitrages. Vérifiez la continuité pilote-production : une plateforme déjà en exploitation se paramètre sur vos processus réels dès le cadrage ; un développement sur mesure impose de spécifier, construire, livrer, puis seulement tester.
11Qu'est-ce que la dérive des modèles d'extraction, et comment la mesurer ?
Réel et mesurable — à condition que l'instrument de mesure reste entre vos mains. En banque et assurance, la dérive a quatre sources : nouveaux distributeurs ou assureurs, évolutions réglementaires, dérive de canal (photos au téléphone, scans dégradés, cachets électroniques), reprises de portefeuille. Le point sérieux n'est pas sa fréquence, qui dépend de votre portefeuille et ne se chiffre pas dans l'absolu, mais son silence : un modèle qui dérive continue de répondre sans signaler d'erreur. Trois instruments doivent donc rester chez vous, et servent autant à vérifier les affirmations d'un éditeur que celles d'une équipe interne : un jeu de test versionné que vous détenez et enrichissez, un score de confiance par champ, un taux de correction humaine suivi dans le temps. Selon l'IEEE Computer Society (ISO/IEC/IEEE 14764:2022), la maintenance pèse 60 à 80 % du coût de cycle de vie d'un logiciel : ce poste existe, qu'on développe ou qu'on acquière.
12Quelles garanties de réversibilité prévoir au contrat avec un éditeur ?
Trois éléments protègent, à écrire au contrat : un socle open source, vos données et configuration chez vous, les poids des modèles entiercés chez un tiers de confiance. Le reste — engagements de continuité, intentions déclarées — rassure sans protéger. La limite : ces poids ne valent que si quelqu'un sait les exécuter et reprendre huit postes d'exploitation à chiffrer, de l'annotation initiale et de la plateforme MLOps jusqu'à la conformité et à l'astreinte. La maintenance pèse 60 à 80 % du coût de cycle de vie d'un logiciel selon l'IEEE Computer Society (ISO/IEC/IEEE 14764:2022) : reprendre les poids, c'est reprendre cette part. Exigez des livrables nommés : format et versions des poids, documentation d'exploitation et de réentraînement, jeux de test versionnés, schémas de données et de configuration, procédure de restitution, déclencheurs de l'entiercement. Puis vérifiez les trois conditions d'internalisation : périmètre documentaire figé, volumétrie faible, équipe MLOps interne permanente.
13Comment justifier auprès d'un régulateur une décision prise à partir d'une extraction automatique ?
Un journal champ par champ suffit, à condition qu'il soit complet : l'explication du raisonnement, elle, n'existe pas — aucun modèle statistique n'expose réellement le sien, et un modèle compact ne fait pas exception. Ce qui se démontre : traçabilité, reproductibilité, imputabilité. Pour chaque champ : version du modèle et du jeu de règles, document source et zone d'origine de la valeur, score de confiance, horodatage, identité du valideur humain lorsqu'il est intervenu — dans des journaux d'audit complets dont toute altération est détectable, sous contrôle d'accès par rôles et authentification forte. Côté exploitation, un registre de modèles et des jeux de test versionnés permettent de rejouer la décision avec la version alors en vigueur. Sculley et al. (NeurIPS 2015) rappellent que le code du modèle n'est qu'une fraction minime d'un système d'apprentissage en production : c'est l'infrastructure de données, de validation et de supervision qui porte le dossier, RGPD, DORA et AI Act compris.
14Quelle infrastructure faut-il pour faire tourner de l'extraction documentaire en interne ?
Pour un modèle spécialisé, l'ordre de grandeur est un serveur GPU unique, pas une ferme de calcul : demandez la configuration de référence — carte, mémoire, débit soutenu — validée sur vos documents. Un repli CPU exploitable coûte du débit, pas la qualité, de quoi démarrer avant le comité. Le calcul suit la taille : demandez le nombre de paramètres, comparez-le à celui d'un LLM généraliste. À calcul comparable, sur vos liasses, c'est la spécialisation documentaire qui décide, pas la taille : tranchez par un test comparatif, même jeu versionné, même métrique pour tous. Reste la mécanique VMware : pass-through ou vGPU, pilotes, dimensionnement de l'hôte. Le GPU n'est pas le gros du sujet : Sculley et al. (NeurIPS 2015, Google) montrent que le code du modèle ne pèse qu'une fraction minime d'un système d'apprentissage en production, dominé par l'infrastructure de données, de validation et de supervision.