Google Document AI peut produire les champs attendus d’une facture et se tromper sur le montant. Le JSON reste lisible, le pipeline fonctionne, mais la donnée qui arrive dans votre système est fausse. Une nouvelle version d’extracteur mérite donc une recette métier avant une intégration.
Le 21 septembre 2026, Google a annoncé une preview de Custom Extractor fondée sur Gemini 3.1 Flash-Lite. Pour une équipe data française, le premier point à vérifier est moins visible que le nom du modèle : la documentation ne déclare officiellement que l’anglais pour l’extraction générative. Un essai sur des documents français reste une expérimentation, pas une preuve de support contractuel ou de qualité en production.
Ce guide distingue l’annonce, les conditions d’accès et le travail de validation. Il propose un protocole de pilote et un contrôleur Python hors ligne. Les fichiers d’exemple sont fictifs. Nous n’avons pas appelé cette preview pour mesurer ses performances.
Ce que l’annonce de septembre change réellement
La version annoncée est pretrained-foundation-model-v3.1-lite-2026-07-15. La date incluse dans cet identifiant ne remplace pas la date d’annonce : la note de version est bien datée du 21 septembre. Google indique un accès en preview, du fine-tuning et les multirégions US et EU. La prise en charge des clés de chiffrement gérées par le client, ou CMEK, reste incomplète selon les régions et passe par une liste d’autorisation auprès de Google. Notes de version Document AI.
Le changement porte sur une version du modèle utilisé par Custom Extractor. Il ne transforme pas tous les processeurs Document AI en un même produit. OCR, extraction de champs et analyse de mise en page répondent à des besoins différents. Un texte correctement lu ne dit pas, à lui seul, lequel des trois montants imprimés correspond au total hors taxes.
La documentation conserve aussi des versions stables, notamment la version 1.5 fondée sur Gemini 2.5 Flash. Un essai de la nouvelle preview doit se comparer à votre solution actuelle sur les mêmes documents. Son nom ne prouve ni un gain de précision ni une baisse de facture Document AI. Versions et extraction générative.
Français, région et statut : trois vérifications distinctes
La fiche du processeur Custom Extractor présente une liste de langues comprenant le français. Elle ajoute toutefois une restriction spécifique : pour l’extraction générative, seul l’anglais est officiellement pris en charge. Lire uniquement la liste générale ferait manquer cette distinction. Le produit Custom Extractor et une version de modèle en preview ont également des statuts différents. Types de processeurs et limites.
Pour cadrer un pilote, séparez donc trois décisions :
| Question |
Preuve à conserver |
Conséquence pour le pilote |
| Quelle langue est officiellement couverte ? |
Fiche correspondant au mode génératif |
Le français reste exploratoire au vu de la documentation consultée |
| Où cette version traite-t-elle les documents ? |
Version exacte, région et restrictions associées |
Une région choisie ne répond pas à toutes les questions de traitement et de chiffrement |
| Quel statut et quels prérequis s’appliquent ? |
Preview ou stable, accès du projet, droits et limites |
Un résultat local favorable ne lève pas une restriction d’accès |
Ne transposez pas les propriétés d’une autre version à celle que vous testez. La documentation signale par exemple des comportements d’endpoint global pour certaines versions 1.6. Il faut lire la ligne correspondant à 3.1 Lite, puis vérifier les exigences de votre organisation. De même, elle mentionne explicitement les scores de confiance pour certaines versions antérieures ; cela ne suffit pas à promettre le même mécanisme pour cette preview.
Deux cas concrets pour une équipe data française
Des factures françaises alimentent un ERP
Prenons un cas fictif : une équipe reçoit des factures de fournisseurs aux mises en page différentes. Elle veut extraire le numéro, la date d’émission, le total hors taxes et la devise. Le risque principal est de confondre une valeur avec une autre : échéance à la place de date d’émission, montant TTC à la place du HT, code client à la place du numéro de facture.
Un pilote utile contient ces ambiguïtés. Il inclut aussi des documents où une information manque. Si la devise n’est pas écrite, remplir automatiquement « EUR » parce que le fournisseur est français masque une inférence. L’extraction doit préserver cette absence pour que la règle métier décide ensuite du traitement.
Dans ce cas, le français se situe hors du support officiel déclaré pour le mode génératif. L’équipe peut explorer le comportement sur des documents de test autorisés, mais elle doit garder cette limite dans sa décision. Un bon résultat sur quelques factures ne suffit pas à engager le flux de production.
Un service achats traite un corpus bilingue
Autre situation fictive : les achats reçoivent des documents anglais et français, avec des fournisseurs récurrents et quelques formats nouveaux. L’équipe peut comparer les deux langues sur des documents équivalents, puis séparer les résultats par langue et par mise en page.
Une moyenne globale cacherait facilement une faiblesse sur le français ou sur un fournisseur rare. Conservez un lot de contrôle qui n’a pas servi à ajuster le schéma. Si le modèle paraît meilleur uniquement sur les documents utilisés pendant la préparation, la comparaison ne répond pas à la question d’adoption.
La même logique vaut pour un bon de livraison : numéro de commande, quantité et unité doivent être distingués. Une valeur « 12 » n’est exploitable que si l’on sait s’il s’agit de pièces, de cartons ou d’une autre unité. Ce second schéma demande sa propre recette ; le petit contrôleur fourni ici couvre uniquement les quatre champs de facture.
Tutoriel : préparer une recette avant le premier appel
1. Écrire les quatre valeurs attendues
Téléchargez attendu.json, reponse-exemple.json et le script Python dans un même dossier. Le premier fichier représente une annotation relue ; le second imite une réponse d’extraction avec des entités plates.
{
"document_number": "FAC-0042",
"invoice_date": "6 octobre 2026",
"total_ht": "1 250,00",
"currency": "EUR"
}
Pour un document réel, préparez cette annotation avant de regarder la réponse du modèle. Une valeur null signifie que l’information est absente de la source. Elle ne signifie ni zéro, ni chaîne vide, ni valeur à deviner. Faites relire les cas ambigus par la personne qui connaît le document métier.
Le script compare le texte extrait, appelé mentionText, au texte attendu. Il conserve les séparateurs, les zéros initiaux et les dates tels qu’ils sont écrits. Seuls les espaces aux extrémités et une normalisation Unicode sont neutralisés. La conversion d’un montant en nombre ou d’une date en ISO constitue un autre contrôle, à tester séparément.
2. Vérifier que votre contrôle sait échouer
Avec Python 3.9 ou plus récent, sans bibliothèque supplémentaire :
python3 verifier_extraction.py attendu.json reponse-exemple.json
Le résultat indique conforme_au_referentiel: true. Changez ensuite le montant de la réponse en 1 520,00. Le JSON reste valide, mais le script signale valeur_differente et retourne le code 1.
Supprimez un champ, dupliquez une entité ou ajoutez un champ inattendu : la recette doit également refuser le résultat. Si le référentiel attend une absence et que l’extracteur fournit une valeur, elle est signalée. Une entrée mal structurée retourne le code 2. Ces essais vérifient le contrôleur ; ils ne mesurent pas la qualité du modèle Google.
3. Créer un processeur de test et un schéma explicite
Dans Document AI Workbench, créez un Custom Extractor dédié au pilote, avec un nom et une région identifiables. Le projet doit disposer de l’API, de la facturation et des permissions nécessaires. Vérifiez l’accès à la version souhaitée avant de préparer une campagne volumineuse. Création d’un processeur.
Créez quatre champs texte plats en mode Extract, avec une occurrence unique. Le protocole téléchargeable propose les descriptions correspondantes. Pour invoice_date, précisez « date d’émission, pas date d’échéance ». Pour total_ht, demandez le total hors taxes et excluez le montant de taxe ainsi que le total TTC.
Commencez sans entraînement : la documentation permet une extraction zero-shot à partir du schéma. Cela donne une première référence avant de décider si des exemples supplémentaires ou un entraînement sont justifiés. Les noms et descriptions des champs font partie de la configuration à conserver avec le résultat.
4. Cibler la version, puis récupérer la réponse
Pour un premier essai, utilisez un PDF court et autorisé, accompagné d’une annotation humaine. Le chemin REST peut viser une version précise :
POST https://eu-documentai.googleapis.com/v1/projects/PROJECT_ID/locations/eu/processors/PROCESSOR_ID/processorVersions/PROCESSOR_VERSION:process
Remplacez les identifiants par ceux du processeur de test et la version effectivement accessible. Le corps de requête utilise rawDocument, avec le contenu PDF encodé en base64 et mimeType égal à application/pdf. Suivez l’exemple authentifié officiel pour produire la requête dans votre projet. Un appel sur le seul processeur utilise sa version par défaut ; cibler explicitement une version évite cette ambiguïté. Envoyer une requête et référence REST.
Sauvegardez le JSON de réponse dans reponse.json, sans le réécrire à la main, puis lancez le contrôleur avec votre annotation. Ce tutoriel ne nécessite pas de changer la version par défaut d’un processeur de production. Une erreur API ou une restriction d’accès est un résultat à consigner, pas un document correctement extrait.
5. Élargir le lot et décider sur les erreurs
Après ce premier passage, ajoutez des variantes : scan incliné, plusieurs dates, fournisseur nouveau, information absente, français et anglais. Séparez les documents utilisés pour ajuster les descriptions de ceux réservés à la mesure finale. Le guide du golden dataset développe cette séparation, avec un exemple de classification plutôt que d’extraction.
Mesurez les champs corrects, manquants ou ajoutés à tort, puis la proportion de documents entièrement corrects. Gardez les dénominateurs et les langues visibles. Ajoutez les erreurs de traitement, les reprises et le temps humain de correction. Une extraction rapide qui déplace le travail vers une longue vérification peut être peu intéressante.
Chiffrer un document accepté, pas seulement une page traitée
Au 9 octobre 2026, le tarif public à l’usage de Custom Extractor est de 30 USD pour 1 000 pages sur le premier million de pages mensuelles, puis de 20 USD pour 1 000 pages au-delà. La page tarifaire indique aussi 0,05 USD par heure d’hébergement pour une version de processeur personnalisé déployée. Vérifiez les postes applicables à votre configuration et les éventuelles conditions négociées. Tarifs Document AI.
À titre de calcul, 200 pages au premier tarif représentent 6 USD de prédiction. Ce montant exclut l’hébergement applicable, le stockage et le travail humain. Il n’est pas une estimation complète du pilote. Le nom Flash-Lite ne permet pas d’appliquer directement les tarifs par jeton d’une autre API Gemini.
Pour comparer avec l’existant, additionnez traitement, reprises et revue humaine, puis divisez par le nombre de documents acceptés selon vos critères. Si ce nombre vaut zéro, le coût par document accepté n’est pas calculable : gardez le coût engagé et signalez l’absence de document validé. Ne produisez pas un ratio rassurant avec un dénominateur différent.
Quand poursuivre, et quand arrêter le pilote
Poursuivez si les documents de contrôle montrent un intérêt mesurable, si les erreurs restantes disposent d’un traitement explicite et si les conditions d’accès conviennent au périmètre envisagé. Fixez les critères avant la mesure : champ critique, erreur tolérée, revue obligatoire, coût acceptable et responsable de décision.
Arrêtez ou réduisez le périmètre si une limite documentaire empêche l’usage visé, si les erreurs critiques passent inaperçues ou si la correction absorbe le gain attendu. Pour un corpus français, le support linguistique déclaré reste un point ouvert à résoudre avant de s’engager sur un usage qui l’exige.
Enfin, notre contrôleur dispose d’une vérité terrain parce qu’il sert à la recette. En production, cette réponse attendue n’existe pas pour chaque nouveau document. Un test réussi ne remplace donc pas les contrôles métier, la gestion des exceptions et la validation humaine du futur flux. C’est cette frontière qu’un pilote doit rendre explicite avant le branchement à l’ERP.
