Deux façons d'industrialiser l'IA documentaire
Automatiser un flux documentaire réglementé se fait de deux manières : développer ses propres modèles, ou déployer la plateforme d'un éditeur dans son propre périmètre. Les deux peuvent atteindre le même niveau de performance sur une démonstration. Elles se départagent sur l'effort de maintenance et d'évolutivité qu'elles supposent — et sur qui le porte.
Des actes métier que peu de documents rendent simples
En banque et en assurance — et singulièrement en assurance vie — les actes métier reposent sur des liasses hétérogènes : bulletins de souscription, mandats, pièces d'identité, justificatifs, relevés, actes notariés. Chacun existe en autant de variantes qu'il y a de distributeurs, de produits et de millésimes réglementaires, et un même dossier fait cohabiter des dizaines de pages dont l'information utile est dispersée plutôt que rangée.
Valider un tel dossier ne consiste pas à lire un formulaire : il faut rapprocher des pièces entre elles, vérifier la complétude, contrôler la cohérence et appliquer des milliers de règles métier et réglementaires. Cela impose deux exigences au modèle. Distribuer son attention efficacement au fil des pages, pour aller chercher une information là où elle se trouve plutôt que de traiter chaque page isolément. Et appliquer ces règles avec une précision suffisante pour que la sortie soit exploitable sans reprise.
C'est ce niveau d'exigence qui rend la question du modèle d'exploitation décisive : un modèle figé y tient un temps, puis décroche à mesure que les formats évoluent.
La maintenance décide du coût, pas le développement
Un devis de développement décrit la construction. Or, sur la durée de vie d'un système, la construction est la plus petite des deux dépenses — et l'écart se creuse encore dès qu'il s'agit d'un système d'apprentissage.
La maintenance pèse 60 à 80 % du cycle de vie d'un logiciel classique, et davantage encore pour un système d'IA, dont le code du modèle n'est qu'une fraction minime du livrable.1,2,3
Annotation, MLOps, détection de dérive, correction humaine, orchestration, conformité, montées de version, réversibilité : ils ne disparaissent pas, ils changent de payeur.
Coût de possession, en multiples du développement initial. La part sombre est ce qui vient après la livraison.
La conséquence tient en un chiffre : là où un logiciel classique coûte au total environ trois fois son développement initial, un système d'IA en coûte environ six — le multiple à provisionner est deux fois plus élevé. Le code du modèle n'est qu'une fraction minime du livrable ; le reste — données, annotation, validation, supervision de la dérive — est de l'exploitation, et c'est elle qui décide du coût sur trois ans.
Pourquoi la maintenance ne s’arrête jamais
En banque et en assurance, les documents entrants changent en continu, pour quatre raisons qui n'ont rien d'exceptionnel. Chacune dégrade un modèle figé, et le corriger suppose un cycle complet : détecter la dégradation, constituer et annoter un nouveau lot, ré-entraîner, re-valider, redéployer.
Nouveaux distributeurs, nouveaux partenaires
Chacun arrive avec ses propres formulaires et ses propres mises en page.
Évolutions réglementaires
Elles modifient simultanément tous les formulaires d'un produit.
Dérive de canal
Photographies prises au téléphone, scans dégradés, cachets de signature électronique.
Reprises de portefeuille
Un corpus entier entre dans la chaîne du jour au lendemain.
Sa propriété la plus coûteuse est d'être silencieuse : un modèle qui dérive ne signale aucune erreur, il rend des résultats de moins en moins justes. Elle se surveille et se traite en continu.
Les huit postes de coût à chiffrer
Au-delà du développement initial, ces postes existent dans les deux approches. La question n'est pas de savoir s'ils seront payés, mais par qui.
- 1Annotation initiale et ré-annotation à chaque dérive
- 2Plateforme MLOps : registre de modèles, jeux de données versionnés, intégration continue
- 3Détection de dérive, score de confiance par champ, alerting
- 4Interface de correction humaine et reprise sur erreur
- 5Orchestration métier : ingestion, découpe des pièces, routage, idempotence, piste d’audit
- 6Conformité : intégration SIEM, gestion des secrets, contrôle d’accès, tests de sécurité
- 7Montées de version de la pile technique
- 8Réversibilité, documentation, transfert de compétences, astreinte
Où la charge s’accumule sur trente-six mois
La charge de maintenance ne se paie pas une fois : elle se reconduit, et elle suit le nombre de formats à couvrir plutôt que la loi de Moore. C'est ce qui sépare les deux trajectoires, bien plus que l'écart entre deux devis initiaux.
Charge cumulée, base 100 = première année d’un développement sur mesure.
Schéma illustratif, non une mesure. Il traduit deux hypothèses explicites : côté sur mesure, une charge annuelle de maintenance reconduite et croissant avec le nombre de formats à couvrir ; côté plateforme, la même charge mutualisée dans la licence, avec une empreinte de calcul décroissante à mesure que les modèles se compactent. Remplacez ces hypothèses par vos propres taux.
Plus grand n’est pas meilleur
Sur un domaine documentaire précis, la taille du modèle n'est pas le levier de précision qu'on croit : doubler le nombre de paramètres rapporte peu, spécialiser rapporte sept fois plus. Un modèle documentaire se juge donc sur deux axes qui ne se compensent pas — ce qu'il pèse et ce qu'il rend juste. Tous les modèles cités sont évalués sur le même jeu de test versionné, avec la même métrique.
- Pourquoi si léger
- Un modèle spécialisé sur une tâche documentaire n’a pas besoin de culture générale, il a besoin de précision sur son domaine : la taille en trop se paie en calcul sans rien rapporter
- Calcul consommé
- ~100× moins qu’un LLM généraliste
- Ce que ça permet
- Une exécution dans votre périmètre, sur votre matériel, sans dépendre d’un cloud tiers
- Trajectoire
- Empreinte décroissante à chaque version
le gain de la spécialisation
- Face à un LLM généraliste
- 5× plus de précision métier
- Détecter l’erreur
- Score de confiance par champ et contrôles de cohérence entre pièces — l’exactitude moyenne ne dit rien de ce qui se passe quand le modèle se trompe
- Corriger dans le flux
- Reprise au champ sans ressortir de l’outil, et chaque correction affine le modèle sur votre domaine
- Conformité de sortie
- 0 % de réponses inexploitables — un cas d’erreur parmi d’autres, mais celui qui bloque un acte
Ces deux axes ne se compensent pas, et c’est ce qui rend la spécialisation payante : un modèle compact coûte moins cher à exécuter tout en rendant des résultats plus justes sur son domaine, là où la course à la taille achète les deux à l’envers. Tous les modèles cités sont évalués sur le même jeu de test versionné, avec la même métrique — la comparaison est directe, sans reconstruction.
Les deux modèles d’exploitation, ligne à ligne
Les deux approches peuvent partager l'essentiel : exécution dans votre périmètre, aucune donnée sortante, modèles à poids ouverts. Elles diffèrent par le modèle d'exploitation.
Sur quelle base est amorti l'effort de maintenance des modèles ?
| Critère | Plateforme éditeur, déployée chez vous | Développement sur mesure |
|---|---|---|
| Couverture des processus au démarrage | Chaîne éprouvée en production, paramétrable dès le cadrage. | À construire processus par processus. |
| Interface de correction humaine | Incluse — c'est un produit, pas un écran à spécifier. | À développer, tester et ajuster. |
| Détection de dérive | Incluse et outillée, avec score de confiance par champ. | À concevoir et chiffrer. |
| Cadence de mise à jour des modèles | Continue : chaque version repart de la meilleure base ouverte disponible et est comprise dans la licence. | Fréquence et prix à fixer. |
| Base d’amortissement de la R&D | Toute la base clients de l'éditeur. | Votre organisation seule. |
| Réversibilité | Socle open source ; données et configuration chez vous ; poids des modèles déposés sous entiercement. | Socle open source, savoir-faire à documenter. |
| Support de niveau 3 | Contractualisé, sous engagement de service. | Selon les engagements du prestataire. |
| Dépendance homme-clé | Un éditeur, une équipe, une feuille de route publiée. | À évaluer : individu ou cabinet. |
| Trajectoire à 12 et 36 mois | Empreinte de calcul et coût décroissants. | Risque de coût croissant avec la dérive. |
L’adoption décide, et elle commence au premier jour
Un outil que les équipes ne s'approprient pas est voué à l'échec, quelle que soit la qualité du modèle. RAND et Gartner situent l'abandon des projets d'IA après la preuve de concept à un niveau élevé, pour des causes majoritairement organisationnelles.4,5
Où commence réellement l’adoption
La chaîne étant déjà en production, vos gestionnaires travaillent sur leurs propres processus dès le cadrage, sans attendre une livraison. Un développement sur mesure inverse cet ordre : l'adoption ne peut commencer qu'à la mise en production, au moment où le budget est déjà dépensé.
- 1Cadrage
- 2Simulation sur vos processus réels
- 3Correction au champ
- 4Mise en production
Adoption et spécialisation, dès le premier jour
- 1Spécification
- 2Construction
- 3Livraison
- 4Recette
- 5Mise en production
L'adoption ne peut commencer qu'ici
La spécialisation s’accumule dès le cadrage
Chaque correction au champ affine le modèle sur votre domaine. La précision progresse pendant que l'équipe apprend l'outil, au lieu de commencer après la livraison.
La charge métier existe des deux côtés
Configuration des règles, correction au champ, recette de chaque lot, double exploitation pendant la transition : elle est comparable dans les deux approches, et décroît avec la précision du modèle.
La différence est ailleurs
C'est la seule charge que vous portez avec un éditeur, quand un développement sur mesure y ajoute l'équipe de maintenance des modèles.
Quand le développement sur mesure est le bon choix
Cette approche est légitime, et il existe des cas où nous recommandons de la retenir. Trois conditions doivent être réunies simultanément :
Le périmètre documentaire est figé
Un type d'acte, un format stable, aucun nouveau partenaire, aucune évolution réglementaire attendue.
La volumétrie est faible
L'automatisation n'a pas à couvrir la totalité du flux ; un traitement manuel résiduel important reste acceptable.
Une équipe MLOps permanente existe déjà
Au moins un poste dédié, durablement financé, capable de détecter une dérive, de ré-annoter et de ré-entraîner sans appel à l'extérieur.
Si ces trois conditions sont réunies, internaliser est défendable. La troisième mérite le plus d'attention : c'est elle qui conditionne la maîtrise du coût de maintenance dans la durée.
Sources
Les chiffres de cette note proviennent des références suivantes. Ceux qui viennent de notre banc d’évaluation interne sont signalés comme tels plutôt que rattachés à une source externe.
- 1
IEEE Computer Society — Part de la maintenance dans le coût total du cycle de vie logiciel
Ordre de grandeur usuel de 60 à 80 %, repris dans la littérature de génie logiciel depuis les années 1980.
- 2
ISO/IEC/IEEE 14764:2022 — Software engineering — Software life cycle processes — Maintenance
Norme internationale qui fait de la maintenance logicielle un processus à part entière, planifié et budgété.
Consulter la source - 3
D. Sculley et al., Google — Hidden Technical Debt in Machine Learning Systems
NeurIPS 2015. Établit que le code du modèle est une fraction minime d’un système d’apprentissage en production, l’essentiel étant l’infrastructure de données, de validation et de supervision.
Consulter la source - 4
RAND Corporation — The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed
RR-A2680-1, 2024. Situe le taux d’échec des projets d’IA à un niveau élevé, pour des causes majoritairement organisationnelles plutôt que techniques.
Consulter la source - 5
Gartner — Gartner Predicts 30 % of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025
Communiqué de juillet 2024.
Consulter la source - 6
Letxbe — Banc d’évaluation interne
Jeu de test versionné, métrique unique appliquée à tous les modèles comparés, exécutions horodatées. Les résultats détaillés figurent dans le livre blanc.
Recevoir la note complète
La version détaillée — matrice comparative, protocole d'évaluation, méthode de chiffrage de la maintenance et grille de lecture d'un devis — est envoyée sur demande. Laissez votre adresse professionnelle, nous vous l'adressons directement.
Questions fréquentes sur le choix entre développer et acquérir
Quatorze réponses courtes et sourcées, sur la maintenance, la dérive, la spécialisation et la souveraineté.
Lire la FAQComparer les deux approches sur vos propres processus
Trente minutes avec un expert Letxbe pour situer votre flux documentaire et chiffrer les deux trajectoires.
Planifier un échange