De 6 mois à 2 jours : La révolution LLM pour le traitement documentaire

Un projet qui prenait 6 mois

Automatiser le traitement des documents Know Your Customer (KYC) pour une banque : cartes d'identité, passeports, justificatifs de domicile, RIB. Extraction complète des données, validation métier, détection des incohérences. Il y a deux ans, ce type de projet RAD/LAD (Reconnaissance et Lecture Automatique de Documents) impliquait un devis sans appel :

6 mois de développement, une équipe de 3 à 5 ML engineers, budget entre 70 000 et 150 000 euros

Et encore, avec de la chance sur la collecte des données d'entraînement.

Aujourd'hui, ce même projet ?

2 jours. Une personne. Quelques euros d'API calls.

Non, il ne s'agit pas d'exagérations marketing. Il s'agit d'un changement de paradigme radical apporté par les LLM multimodaux. Laissez-moi vous montrer comment.

Dans le jargon métier français, on parle de RAD/LAD (Reconnaissance et Lecture Automatique de Documents). À l'international, le domaine est plutôt connu sous :

• IDP (Intelligent Document Processing) : terme générique pour l'ensemble
• Document AI : variante marketing
• OCR (Optical Character Recognition) : la brique de base (reconnaissance de texte)

RAD correspond à la Document Classification, LAD à l'Intelligent Data Extraction.

Ce sont ces briques fondamentales que les LLM multimodaux bouleversent.

L'enfer du deep learning classique

Pour comprendre l'ampleur de la révolution, rappelons d'abord ce qu'impliquait l'approche traditionnelle.

Le calvaire de l'annotation

Imaginez que vous deviez créer un système capable de traiter une carte nationale d'identité française. Voici ce que cela nécessitait :

1. Collecte du dataset

• Rassembler 5 000 à 10 000 images de CNI (avec consentement, anonymisation, etc.)
• Répéter l'opération pour chaque type de document : passeports, permis, factures, RIB...
• Budget annotation seule : 20 000 à 40 000 euros

2. Annotation minutieuse

• Dessiner des bounding boxes autour de chaque champ à extraire
• Nom, prénom, date de naissance, numéro de document, dates de validité...
• Pour une CNI : environ 15 à 20 zones à annoter
• Temps par image : 5 à 10 minutes
• Pour 10 000 images : 833 à 1 667 heures de travail d'annotation

3. Entraînement des modèles

Vous ne pouviez pas vous contenter d'un seul modèle. Il fallait en entraîner plusieurs :

# Modèle 1: Classification du type de document
cnn_classifier = train_document_classifier(
    images=train_set,
    labels=['cni', 'passeport', 'permis', 'facture', 'rib'],
    epochs=50,
    batch_size=32
)
# Temps d'entraînement: 24-48h sur GPU

# Modèle 2: Détection des zones d'intérêt
object_detector = train_yolo_detector(
    images=train_set,
    bboxes=annotations,
    classes=field_names,
    epochs=100
)
# Temps d'entraînement: 48-72h sur GPU

# Modèle 3: OCR pré-entraîné + post-processing custom
ocr_engine = load_pretrained_ocr("tesseract")  # ou EasyOCR, PaddleOCR
text = ocr_engine.recognize(cropped_region)
cleaned_text = apply_regex_rules(text)  # Nettoyage custom
# Temps de dev: 20-40h (intégration + règles de post-processing)

4. Le cauchemar des cas particuliers

Et ce n'est que le début. Il fallait ensuite gérer :

• Les cases à cocher (permis de conduire : catégories A, B, C...) → classificateur binaire supplémentaire
• Les variations de format (ancienne vs nouvelle CNI) → ré-entraînement partiel ou complet
• Les documents abîmés, flous, scannés de travers → data augmentation massive
• La validation métier (checksum IBAN, cohérence des dates) → couche de règles custom

Au final : 3 à 6 mois de développement, maintenance cauchemardesque, rigidité totale.

Le nouveau paradigme : poser les bonnes questions

Puis sont arrivés GPT-4, Gemini, Claude. Des modèles qui ne se contentent plus de détecter des pixels, mais qui voient et comprennent des images.

De l'entraînement au prompting

Le changement fondamental tient en une phrase : on ne cherche plus à entraîner un modèle à reconnaître des patterns, on lui demande ce qu'il voit.

Voici à quoi ressemble désormais la "détection" du type de document :

from chains.llm_chain import KYCDocumentChain

chain = KYCDocumentChain()
result = chain.classify_document("document.jpg")

# Résultat:
# {
#   "type": "carte_identite",
#   "confidence": 0.98,
#   "reasoning": "Document rectangulaire avec photo, mentions RF et CNI"
# }

Le prompt de RAD utilisé ? Une trentaine de lignes de texte :

PROMPT_CLASSIFICATION = """
Vous êtes un expert en classification de documents administratifs français.

Analysez l'image fournie et déterminez son type parmi :
- carte_identite : Carte Nationale d'Identité française
- passeport : Passeport français
- permis_conduire : Permis de conduire français
- facture : Facture de fournisseur (électricité, gaz, eau, internet, téléphone)
- rib : Relevé d'Identité Bancaire

Répondez au format JSON avec :
- type : le type identifié
- confidence : votre niveau de confiance (0.0 à 1.0)
- reasoning : votre raisonnement en une phrase
"""

C'est tout.

Pas d'entraînement. Pas de dataset. Pas de bounding boxes. Un prompt clair et une image.

L'extraction structurée sans template matching

Mais la vraie magie opère sur l'extraction des données. Avec le deep learning classique, extraire les champs d'une CNI nécessitait :

1. Localiser chaque zone (détection d'objets)
2. Appliquer l'OCR sur chaque zone
3. Post-traiter avec des regex pour nettoyer
4. Valider avec des règles métier

Avec un LLM multimodal :

from pydantic import BaseModel, Field
from datetime import date

class CarteIdentite(BaseModel):
    """Schéma structuré d'une CNI française"""
    nom: str = Field(description="Nom de famille")
    prenom: str = Field(description="Prénom(s)")
    date_naissance: date = Field(description="Date de naissance")
    lieu_naissance: str = Field(description="Lieu de naissance")
    numero: str = Field(description="Numéro du document")
    date_emission: date = Field(description="Date d'émission")
    date_expiration: date = Field(description="Date d'expiration")

    @property
    def est_valide(self) -> bool:
        """Vérifie si le document est encore valide"""
        return date.today() <= self.date_expiration

Le prompt de LAD utilisé:

PROMPT_EXTRACTION_CNI = """
Analysez cette carte nationale d'identité française et extrayez 
toutes les informations structurées selon le schéma fourni.

Pour chaque champ :
- nom : le nom de famille en MAJUSCULES
- prenom : le(s) prénom(s) avec la première lettre en majuscule
- date_naissance : au format ISO (YYYY-MM-DD)
- lieu_naissance : ville et département
- numero : le numéro unique du document (12 caractères)
- date_emission : date de délivrance (format ISO)
- date_expiration : date de fin de validité (format ISO)

Retournez un JSON valide.
"""
# Extraction
cni = chain.extract_cni("cni_exemple.jpg")
print(f"{cni.prenom} {cni.nom}")
# → "Marie DUPONT"
print(f"Valide jusqu'au : {cni.date_expiration}")
# → "Valide jusqu'au : 2028-03-15"
print(f"Document valide : {cni.est_valide}")
# → "Document valide : True"

Le LLM retourne directement un objet Pydantic validé. Les dates sont parsées automatiquement. Les types sont respectés. La validation métier est intégrée.

Temps de développement ? 2 heures pour définir le schéma et tester sur quelques exemples.

Un cas concret : le système KYC en production

Parlons chiffres concrets. Voici ce qui a été développé en 2 jours pour un démonstrateur :

Périmètre fonctionnel

5 types de documents traités :

• Cartes Nationales d'Identité
• Passeports
• Permis de conduire
• Justificatifs de domicile (factures multiples fournisseurs)
• RIB/IBAN

Fonctionnalités implémentées :

• Classification automatique (RAD - Reconnaissance Automatique de Documents)
• Extraction structurée de tous les champs (LAD - Lecture Automatique de Documents)
• Validation métier (expiration, checksum IBAN via modulo 97)
• Détection des cases cochées (permis : catégories A, B, C...)
• Vérification de cohérence inter-documents (même identité)
• Génération d'un rapport de validation

Architecture :

src/
├── chains/
│   ├── schemas/kyc_schemas.py      # Schémas Pydantic (200 lignes)
│   ├── prompts.py                  # Prompts (250 lignes)
│   └── llm_chain.py               # Chain principale (150 lignes)
├── pipeline.py                     # Pipeline multi-docs (150 lignes)
└── main.py                        # CLI (50 lignes)

Total : 800 lignes de Python.

Note : Ce décompte correspond au cœur fonctionnel. Un déploiement production ajouterait validation, logging, gestion d'erreurs (~500 lignes supplémentaires).

Pour comparaison, un système deep learning classique pour un périmètre similaire nécessite typiquement 10 000 à 15 000 lignes de code, sans compter les scripts d'entraînement et d'annotation.

Performance mesurée

Tests sur un corpus de 600 documents variés :

Du machine learning à l'ingénierie de prompts

Contrairement au deep learning classique, il n'y a plus besoin de constituer un dataset de milliers d'images annotées. Mais ne nous y trompons pas : le travail d'expertise métier n'a pas disparu, il s'est déplacé.

Au lieu d'annoter des bounding boxes pendant des semaines, on passe désormais quelques heures à formaliser notre connaissance du domaine dans des prompts structurés. C'est une forme d'apprentissage "in-context" : le modèle apprend de nos instructions et de quelques exemples, plutôt que de milliers d'échantillons.

Le gain ? Une itération en minutes plutôt qu'en jours. Un prompt qui ne fonctionne pas se corrige immédiatement. Un modèle mal entraîné nécessitait de reprendre tout le pipeline.

Limitations et garde-fous

Les LLM multimodaux ne sont pas infaillibles. Voici les pièges à éviter et les protections à mettre en place.

Ce que le LLM peut mal faire

Hallucinations structurées : Le modèle peut retourner un JSON parfaitement formaté... avec des données inventées. Un numéro de CNI plausible mais faux, une date cohérente mais incorrecte.

Variance entre appels : Contrairement à un modèle classique déterministe, le même document peut occasionnellement donner des résultats légèrement différents (temperature > 0).

Sensibilité à la qualité d'image : Documents flous, scans de travers, annotations manuscrites parasites... Le LLM galère autant que l'humain.

Cas difficiles identifiés : Certains layouts restent challengeants, notamment les grilles à colonnes multiples ou les documents avec beaucoup de cases à cocher rapprochées. Sur ces cas, prévoir des itérations de prompt plus longues ou un fallback humain.

Les garde-fous indispensables

# 1. Validation par règles métier post-extraction
def validate_cni(cni: CarteIdentite) -> ValidationResult:
    errors = []
    # Cohérence temporelle
    if cni.date_naissance >= cni.date_emission:
        errors.append("Date de naissance postérieure à l'émission")
    # Format du numéro (12 caractères alphanumériques)
    if not re.match(r'^[A-Z0-9]{12}$’, cni.numero):
        errors.append("Format de numéro invalide")
    # Note: checksum applicable sur IBAN et passeport, 
    # mais pas sur le numéro de CNI
    return ValidationResult(valid=len(errors) == 0, errors=errors)
# 2. Score de confiance et fallback humain
if result.confidence < 0.85:
    flag_for_human_review(document)
# 3. Double extraction sur cas critiques
if document.is_high_value:
    result2 = chain.extract(document, temperature=0)
    if result1 != result2:
        flag_for_human_review(document)

Règle d'or : Le LLM extrait, les règles métier valident. Ne jamais faire confiance aveuglément à une sortie de modèle.

Le cas killer : les cases à cocher

Permettez-moi d'insister sur un point qui illustre parfaitement la révolution en cours.

L'approche classique : un cauchemar technique

Prenez un permis de conduire. Il contient une grille de catégories : AM, A1, A2, A, B, BE, C1, C, etc. Certaines cases sont cochées, d'autres non.

En deep learning classique, voici ce qu'il fallait faire :

1. Localisation précise

# Annoter la position de CHAQUE case (14 catégories)
bboxes = {
    'AM': [x1, y1, x2, y2],
    'A1': [x1, y1, x2, y2],
    'A2': [x1, y1, x2, y2],
    # ... 11 autres annotations par image
}

2. Détection + Classification

# Modèle 1: Localiser toutes les cases
case_detector = train_case_detector(train_images)  # 10 000 images

# Modèle 2: Pour chaque case, décider si cochée
checkbox_classifier = train_binary_classifier(
    positive_samples=cases_cochees,
    negative_samples=cases_vides
)

3. Gestion des cas limites

• Case partiellement cochée
• Croix vs coche vs remplissage
• Cases décalées (scan de travers)
• Annotations manuscrites parasites

Coût estimé : 40 à 60 heures de développement + annotation pour cette seule fonctionnalité.

L'approche LLM : une question

Maintenant, regardez ça :

from chains.schemas.kyc_schemas import PermisConduire
permis = chain.extract_permis("permis_exemple.jpg")
print(permis.categories)
# → ["B", "A2"]

Le prompt qui permet ça :

PROMPT_EXTRACTION_CASES_COCHEES = """
Analysez ce permis de conduire et identifiez quelles catégories
sont cochées dans la grille (section 9).
Retournez la liste des catégories cochées.
"""

C'est tout.

Le LLM voit l'image. Il comprend que ce sont des cases. Il identifie lesquelles sont cochées. Exactement comme un humain le ferait.

Temps de développement : 15 minutes (incluant les tests).

Comparaison chiffrée : l'évidence du ROI

Mettons les chiffres côte à côte.

Développement initial

Exploitation et maintenance

Seuil de rentabilité

Avec les modèles actuels (Gemini 2.5 Flash/Pro), le coût opérationnel de l'approche LLM (~0.001-0.005€/doc) est équivalent voire inférieur à celui d'une infrastructure deep learning classique amortie (~0.005€/doc).

La vraie différence se joue sur le setup :

Le ROI est immédiat. Pas besoin de calcul de breakeven : l'approche LLM est moins chère dès le premier document, tout en divisant le time-to-market par 100.

Facteurs à considérer en production :

Mon conseil : L'approche LLM couvre 90% des cas d'usage. Réservez le deep learning classique aux contraintes extrêmes : latence < 100ms, millions de docs/jour, ou confidentialité interdisant tout appel externe.

Au-delà du KYC : la généralisation

Le traitement KYC n'est qu'un exemple. Cette approche révolutionne l'ensemble des solutions de RAD/LAD (Reconnaissance et Lecture Automatique de Documents) et s'applique à tout processus documentaire où :

✅ Les LLM multimodaux excellent

Documents à mise en page variable

• Factures de fournisseurs multiples (formats différents)
• Relevés bancaires
• Contrats (layouts non standardisés)

Formulaires avec logique visuelle

• Cases à cocher (on l'a vu)
• Signatures manuscrites (détection de présence)
• Grilles et tableaux complexes

Validation contextuelle

• Cohérence entre documents (même identité, dates compatibles)
• Détection d'anomalies sémantiques ("ce montant semble incohérent")
• Extraction multi-langue sans configuration

Compréhension sémantique

• Classification par contenu plutôt que par format
• Extraction d'intentions (dans emails, réclamations)
• Résumés de documents longs

Combiner intelligence LLM et rigueur déterministe

Pour des processus critiques, il est essentiel de combiner l'intelligence du LLM avec la rigueur de règles déterministes :

# Validation par règles métier après extraction LLM
def validate_extraction(cni: CarteIdentite) -> bool:
    checks = [
        cni.date_naissance < cni.date_emission,  # Né avant émission
        cni.date_emission < cni.date_expiration,  # Émission avant expiration
        len(cni.numero) == 12,                     # Format numéro
        cni.date_expiration > date.today()         # Pas expiré
    ]
    return all(checks)

❌ Quand privilégier l'approche classique

Il existe des cas où le deep learning classique reste préférable :

Volumes massifs avec formats ultra-standardisés

• Traitement de chèques (millions/jour, format fixe)
• Lecture de codes-barres
• Documents normalisés (passeports biométriques avec MRZ)

Contraintes de latence extrêmes

• Reconnaissance en temps réel (< 100ms)
• Flux vidéo haute fréquence

Budget API prohibitif

• Si > 1 million de documents/mois
• Mais attention au coût caché de la maintenance du système classique

Conclusion : un changement de paradigme pour les équipes

Les LLM multimodaux ne remplacent pas 30 ans d'évolution de l'OCR et du traitement documentaire. Les solutions matures (ABBYY, Kofax, AWS Textract) restent pertinentes pour de nombreux cas d'usage.

Ce qui change fondamentalement, c'est la vélocité de développement et l'accessibilité.

Avant : 6 mois, une équipe ML, un budget conséquent. Seuls les grands groupes pouvaient se le permettre.

Maintenant : 2 jours, un développeur, quelques centaines d'euros. Une startup peut rivaliser.

Ce n'est pas tant une révolution technologique qu'une démocratisation. Le traitement documentaire intelligent n'est plus réservé à une élite technique. Et ça, c'est un vrai game-changer.

Et demain ?

Nous sommes encore au début. GPT-4 Vision est sorti en septembre 2023, Gemini 1.0 en décembre 2023, Claude 3 en mars 2024.

J'ai développé le démonstrateur avec Gemini 2.5 Flash et Pro en octobre 2025. Le temps de finaliser cet article, Gemini 3 Pro (novembre 2025) puis Gemini 3 Flash (décembre 2025) sont déjà sortis.

Les modèles s'améliorent tous les trimestres. Les modèles open-source rattrapent leur retard. Les coûts continuent d'évoluer avec de meilleurs rapports qualité/prix.

Dans 12 mois, ce qui nécessite aujourd'hui 2 jours ne prendra peut-être que 2 heures.

Un conseil pragmatique

Si vous avez un projet de traitement documentaire, testez l'approche LLM avant de partir sur du deep learning classique.

La méthode en 5 étapes :

1. Constituez un mini-dataset de test : 50 documents représentatifs, incluant des cas limites (flous, de travers, raturés)
2. Écrivez vos prompts : Commencez simple, itérez. Comptez 2-4h par type de document.
3. Mesurez la précision : Comparez aux ground truth. Visez > 90% pour un POC.
4. Testez la variance : Même document, 5 appels. Les résultats sont-ils stables ?
5. Validez la conformité : Avant d'envoyer de vrais documents d'identité à une API externe, consultez votre DPO.

Vous saurez en une journée si l'approche est viable. Si ça fonctionne, vous venez d'économiser des mois. Si ça ne fonctionne pas assez bien, vous aurez appris en 1 jour ce qui vous aurait pris 1 mois avec l'approche classique.

Et si la confidentialité est bloquante ? Les modèles open-source multimodaux progressent vite. L'option on-premise existe.

Le paradigme a changé. De "entraîner un modèle" à "poser les bonnes questions".

Bienvenue dans l'ère du traitement documentaire intelligent.

Article rédigé dans le cadre d’une présentation à La Grosse Conf 2026. Le démonstrateur KYC a été développé en 2 jours pour illustrer concrètement le paradigm shift apporté par les LLM multimodaux dans le traitement documentaire.