Un OCR prêt à être déployé en 2026 : le playbook du CTO pour les documents LATAM

Si votre produit touche aux factures, boletos, pièces d’identité ou QR codes Pix au Brazil, l’OCR n’est plus un « nice to have » en 2026. C’est un levier de revenus — et un risque si vous le déployez mal. Avec Mistral OCR 4.1 qui fait parler de lui, Gemini 3.7 Flash de Google qui met l’accent sur la vitesse, et le nouveau mode « Ultrafast » d’OpenAI qui vante des baisses de latence d’un ordre de grandeur, la tentation est de greffer une API de modèle de vision à votre app et de s’arrêter là. N’en faites rien. Vous obtiendrez une précision de démo et des rétrofacturations de production.

Ce playbook est ce que nous livrons aux fintechs et aux marketplaces opérant à travers Brazil et LATAM : un cadre de décision, une architecture de référence, et les arbitrages à assumer — coût, latence, confidentialité et risques de cas extrêmes. Nous nous appuierons sur des documents latino‑américains concrets (factures NF‑e/NFC‑e, boletos, pièces d’identité CNH/RG, QR Pix) et sur les réalités du matériel Android d’entrée de gamme et d’une connectivité intermittente.

Pourquoi ce sujet, pourquoi maintenant

Trois choses ont changé au cours des 12 derniers mois :

• Les modèles de vision se sont stabilisés pour l’imprimé. Les VLM modernes et les modèles spécialisés en OCR atteignent 95–99 % d’exactitude au niveau des caractères sur des écritures latines propres, hors distribution. L’extraction sensible à la mise en page (tables, libellés) dépasse largement les bricolages à base de regex pour les lignes d’articles.
• La latence s’est effondrée. Les modes « Flash » et « Ultrafast » amènent le first‑byte sous 300–600 ms pour de petites images et sous 1,5 s pour des scans A4. Sur des téléphones milieu de gamme, des pipelines OCR quantifiés embarqués renvoient les champs clés en 120–300 ms par recadrage.
• Les coûts sont prévisibles. L’OCR cloud est typiquement à 0,01–0,10 $ par page, les API VLM souvent à 0,05–0,30 $ par image selon la résolution et les tokens. Pour 100 k documents/mois, vous choisissez entre environ 1 k$–30 k$ de coût variable et du capex/ingénierie pour du on‑device ou de l’auto‑hébergé.

Très bien. Mais une « bonne » précision OCR en moyenne ne suffit pas. L’écosystème documentaire du Brazil ne tolère pas l’à‑peu‑près. Un seul chiffre mal lu dans une clé d’accès NF‑e de 44 chiffres ou un CPF/CNPJ avec clé de contrôle invalide se traduit par des rapprochements échoués, des rejets KYC ou, en fintech, une exposition réglementaire.

Définissez « done » d’abord : la précision au niveau des champs

N’acceptez pas le « CER/WER » du fournisseur comme boussole. En production, vous vous souciez de la justesse par champ et des invariants en aval.

• Champs critiques à exactitude parfaite. CPF (11 chiffres, 2 clés de contrôle), CNPJ (14 chiffres, 2 clés de contrôle), clé d’accès NF‑e/NFC‑e (44 chiffres, clé de contrôle), charge utile Pix BR Code (CRC). Visez ≥99,95 % d’exactitude par champ, car vous pouvez valider de manière déterministe.
• Champs non critiques mais à fort impact métier. Total de facture, date d’émission, CNPJ/IE du vendeur, descriptions/quantités des lignes. Visez ≥99 % sur les totaux/dates après validation et ≥95 % pour les lignes, avec un filet de sécurité en revue humaine.
• Classification de document. Distinguer boleto vs fatura vs DANFE vs CNH vs RG vs recibo. Visez ≥99,5 % de classification, car le reste de votre pipeline dépend des bons gabarits.

Écrivez ces objectifs avant de choisir un modèle. « 98 % de précision OCR » peut encore faire échouer 1 facture sur 5 au niveau document si les erreurs résiduelles touchent vos champs critiques.

Un cadre de décision pour CTO : où doit tourner l’OCR ?

Option A : On‑device d’abord, cloud en repli

À choisir si : vous traitez des données PII/financières (risque LGPD/CPRA), vous avez besoin d’une UX sous la seconde et votre app peut imposer un flux de capture guidé. C’est notre défaut pour la capture grand public (permis, reçus, QR Pix).

• Avantages : latence minimale ; confidentialité by design (les PII ne quittent pas l’appareil avant validation) ; capture hors ligne ; coût ~0 par image à l’échelle ; résilience aux pannes d’API.
• Inconvénients : effort d’ingénierie (sélection de modèles, quantification, redressement, post‑traitement) ; matériel Android hétérogène (3–6 Go de RAM, NPUs instables) ; budgets de taille d’app élevés (gardez les modèles sous 30–60 Mo par tâche).

Option B : OCR ou VLM en edge / auto‑hébergé

À choisir si : vous avez besoin de traitement par lots (ingestion back‑office), pouvez garder les images dans une VPC privée et souhaitez limiter le verrouillage fournisseur. Exécutez un OCR spécialisé plus un modèle de mise en page sur des GPU dans votre région cloud ou on‑prem.

• Avantages : unit economics prédictibles (instances amorties) ; pas de fuite PII chez un fournisseur ; possibilité de fine‑tune ou de distillation ; latence rapide en région (100–300 ms de RTT).
• Inconvénients : complexité infra ; capacity planning ; vous possédez l’ops modèle ; toujours un coût (GPU/CPU, ingénieurs d’astreinte).

Option C : APIs cloud VLM/OCR uniquement

À choisir si : vous devez prouver la valeur rapidement, le volume est faible/modéré (≤20 k docs/mois) et le time‑to‑market prime. Utilisez les paliers « Flash/Ultrafast » pour les flux interactifs.

• Avantages : mise en production la plus rapide ; excellente précision moyenne ; infra minimale ; tarification simple.
• Inconvénients : risque de transfert de PII ; variance de latence côté fournisseur ; pics de coût à l’échelle ; fragile sur les queues (reflets, froissements, tampons, polices non standard).

Notre règle empirique : capture grand public → on‑device d’abord. Back‑office/volumétrie → edge ou auto‑hébergé. Prototype → API maintenant, mais concevez en double source pour pouvoir permuter.

Une architecture de référence qui sort vraiment en prod

1) Une capture qui évite le garbage‑in

• Guidage en temps réel : détection de texte on‑device pour guider le cadrage, vérifier les reflets et l’inclinaison, avec feedback en temps réel. N’acceptez que lorsque les seuils de mise au point/contraste sont atteints.
• Redresser et débruiter sur l’appareil : correction de perspective, binarisation et suppression des ombres réduisent davantage la confusion des modèles en aval que n’importe quel prompt sophistiqué.
• Recadrages ROI (régions d’intérêt) : plutôt que d’envoyer une A4 entière, recadrez les zones probables (zone de clé d’accès, encadré des totaux, zone d’identification du document). Les ROI réduisent latence et tokens par 5–10x.

2) Extraction primaire : choisir le bon outil par champ

• Déterministe quand c’est possible : pour les QR/Pix, utilisez d’abord une bibliothèque code‑barres/QR. Pour les clés d’accès, un OCR sensible aux lignes avec biais en faveur des chiffres surpasse un VLM généraliste.
• OCR spécialisé pour les blocs de texte : un petit modèle OCR latin quantifié, embarqué, vous donne 95–98 % de CER sur de l’imprimé propre. Pour des tampons/surimpressions compliqués, escaladez vers un VLM cloud/edge avec compréhension de la mise en page.
• Modèle de mise en page pour les tableaux : si vous avez besoin des lignes d’articles, utilisez un modèle de structure de tableau (par ex., un transformer de vision entraîné sur des documents) avant l’OCR texte brut. Vous voulez des limites de cellules, pas un mur de texte.

3) Post‑traitement qui impose la vérité métier

• Checksums et validateurs de format : CPF, CNPJ, clé d’accès NF‑e et CRC Pix sont déterministes. Rejetez ou recapturez tôt si invalide.
• Invariants inter‑champs : validez que le Total égale la somme des articles plus taxes/frais ; date ≤ maintenant ; le CNPJ correspond au nom du vendeur via registre ; le code‑barres du boleto correspond à la ligne imprimée. Ces invariants corrigent plus d’erreurs OCR qu’un nouveau passage de modèle.
• Normalisation : émettez un schéma strict (types, unités, dates ISO, devise) et rejetez les parsings ambigus. La production déteste les « peut‑être ».

4) Escalade et humain dans la boucle

• Routage sensible à la confiance : pour chaque champ, calculez un score de confiance. Si le score < seuil ou si les invariants échouent, escaladez : second modèle, puis revue humaine.
• Retentatives ciblées : demandez aux utilisateurs un recadrage plus serré de l’encadré des totaux ou de la clé d’accès, pas une recapture complète. Économise 70–80 % de friction sur les reprises.
• UI de revue avec raccourcis clavier : si vous avez besoin d’humains, rendez‑les rapides. 10–20 secondes par doc, contre 2 minutes, quand l’UI est optimisée pour les champs, pas pour les images.

5) Confidentialité, stockage et suppression

• Rédaction on‑device : masquez CPF/CNPJ avant l’upload quand vous n’avez besoin que des totaux ou des dates. Minimisez ce qui quitte le téléphone.
• Stockage objet à courte durée de vie : rétention par défaut 24–72 h pour les images brutes ; conservez plus longtemps les champs structurés selon la politique. Chiffrement au repos et en transit ; séparation des clés pour images vs données extraites.
• DSR et audit : journalisez quel processeur a traité quelle image, la version de modèle et les prompts. Rendez la suppression vérifiable.

Budgets de latence qui n’agaceront pas vos utilisateurs

• Capture interactive : 300–800 ms pour afficher « C’est bon » après le déclenchement. Les ROI permettent du sous‑300 ms sur Android milieu de gamme pour les champs clés.
• Facture A4 complète : 1,0–2,5 s de bout en bout avec edge/cloud ; masquez avec une UI optimiste (affichez d’abord le vendeur/la date, puis les lignes d’articles).
• Back‑office par lots : le débit prime sur la latence par doc. Visez ≥10 docs/s/GPU pour l’OCR standard et ≥2–5 docs/s/GPU pour l’extraction mise en page+table à 300 DPI.

Ne streamez pas les images jeton par jeton ; le streaming brille pour la génération de texte, pas pour l’OCR. À la place, streamez des résultats structurés dès que chaque champ est validé.

Des coûts que vous pouvez défendre auprès de votre CFO

En 2026, les fourchettes typiques que nous voyons en production :

• APIs d’OCR cloud : 0,01–0,10 $/page pour l’OCR général ; ajoutez 0,02–0,08 $ pour l’extraction de tableaux si facturée séparément.
• APIs de compréhension d’image VLM : 0,05–0,30 $/image selon la résolution et la tokenisation. Multi‑image (recto/verso d’une ID) double le coût.
• OCR/VLM auto‑hébergé : amortissez GPU/CPU et l’ops. Une machine GPU milieu de gamme peut traiter de l’ordre de 500 k–2 M de pages/mois pour l’OCR standard avec un batching soigné ; les modèles de mise en page tournent 2–5x plus lentement. Le coût unitaire effectif atterrit souvent à 0,002–0,02 $/page à régime établi.
• On‑device : coût variable quasi nul ; vous payez en ingénierie et taille d’app. Comptez 2–3 mois‑ingénieur pour livrer un flux Android capture+OCR robuste si vous partez d’une bonne base.

À 100 k docs/mois, l’écart entre 0,02 $ et 0,20 $ par doc, c’est 2 k$ vs 20 k$ mensuels. Dimensionnez votre architecture en conséquence — et gardez une porte de sortie pour changer de palier au gré du volume.

Évaluez en sceptique

• Constituez votre propre jeu de test. 1 000+ documents réels Brazil/LATAM : reçus froissés, tampons sur les totaux, polices de caisses, prises de vue en basse lumière, artefacts de papier thermique. Des scans synthétiques propres ne vous apprennent rien.
• Mesurez la justesse par champ et l’acceptation. Suivez la précision/rappel par champ et un taux global « document accepté sans aide humaine ». Votre étoile polaire est l’acceptation avec coût par doc accepté, pas le CER.
• Instrumentez les échecs de queue. Journalisez les images qui échouent aux invariants ou aux seuils de confiance. Votre dérive de données se cache dans ces queues. Passez en revue chaque semaine et réinjectez dans la sélection de modèles ou l’UX de capture.
• Versionnez tout. Hash d’image, paramètres de pré‑traitement, version de modèle, prompt (le cas échéant), code de post‑traitement. Vous avez besoin de reproductibilité pour les audits et les régressions.

Sécurité, confidentialité et LGPD sans drama

• Minimisez les données en mouvement. Si vous n’avez besoin que du total de facture et de la date, n’uploadez pas l’image entière. Rédigez ou recadrez sur l’appareil.
• Due diligence côté fournisseurs. Si vous devez utiliser des OCR/VLM cloud, négociez des addendums de traitement des données, l’ancrage régional (Brazil/US) et des politiques de rétention=0. Vérifiez par un audit au niveau du trafic (wire‑level), pas seulement la doc.
• Rédaction et tokenisation. Remplacez les CPF/CNPJ bruts dans les logs et l’analytique par des tokens irréversibles. Votre SIEM ne doit jamais voir les numéros réels.
• SLA de suppression. Définissez des rétentions courtes par défaut et rendez‑les visibles en interne. Construisez une suppression en un clic par ID utilisateur/document pour les DSR.

Pièges Brazil/LATAM à anticiper

• Papier thermique et tampons : les NF‑e et reçus ont souvent des fonds non uniformes et des surimpressions « PAID ». Le pré‑traitement aide plus que changer de modèle. Essayez un seuillage adaptatif avant de réessayer.
• Formats régionaux : virgules décimales vs points (R$ 1.234,56). Normalisez les nombres selon les règles de locale avant d’appliquer les invariants.
• Polices mixtes et impressions matricielles : les anciennes caisses produisent des caractères qui trompent l’OCR générique. Entraînez ou biaisez pour les chiffres dans les zones numériques ; privilégiez ROI + modèles « chiffres seuls » pour codes‑barres et clés d’accès.
• IDs avec hologrammes (CNH/RG) : attendez‑vous à des reflets. Guidez les utilisateurs à incliner légèrement et capturer en angle ; redressez ensuite.
• Zones blanches de connectivité : agents de terrain et chauffeurs passent hors ligne. On‑device d’abord sauve votre NPS.

À propos de ces « polices anti‑scraper »

Vous avez vu des titres sur la nouvelle arme du web contre les scrapers d’IA : des polices adversariales qui paralysent un OCR naïf. Très bien. Elles élèvent la barre pour le scraping occasionnel. Mais dans votre pipeline, vous contrôlez la capture et le pré‑traitement. Avec un bon passage de redressement/binarisation et des modèles entraînés sur des écritures latines, ces polices ne comptent pas pour les factures et les IDs. Le vrai ennemi, c’est la mauvaise lumière et le flou de mouvement, pas des glyphes malins.

Build vs buy : un partage pragmatique

• Buy : l’OCR de commodité pour des scans propres, la structure de tableau pour les lignes, et l’ingestion back‑office par lots si vous manquez d’ops GPU. Commencez avec des APIs réputées et exigez de vrais SLA.
• Build : l’UX de capture, le pré‑traitement on‑device, la logique ROI, les validateurs, les invariants et votre UI de revue. Ce sont vos douves défendables et là où se gagnent l’essentiel des victoires coût/latence.
• Hybrid : voie rapide on‑device pour les champs clés ; escalade vers un VLM cloud/edge pour les cas brouillons ou les lignes d’articles ; revue humaine pour les 1–3 % restants.

Un plan de déploiement sur 60 jours

1. Semaines 1–2 : définir les objectifs par champ et les invariants. Assembler un jeu d’or de 1 000 documents. Choisir un OCR on‑device de base et une API cloud de secours.
2. Semaines 3–4 : livrer la capture guidée avec redressement/débruitage et recadrages ROI. Implémenter les validateurs pour CPF/CNPJ/NF‑e/CRC Pix et les totaux monétaires.
3. Semaines 5–6 : scoring de confiance et routage d’escalade. Construire une UI de revue minimale. Instrumenter l’acceptation et le coût par doc accepté.
4. Semaines 7–8 : ajouter l’extraction de tableaux si nécessaire. Ajuster les seuils pour < 2 % de revue humaine sur des docs propres. Verrouiller la confidentialité (rédaction, rétention, DPA fournisseur).

À quoi ressemble le « bon » en production

• UX de capture sous la seconde pour les champs clés sur Android milieu de gamme (120–300 ms par passage ROI ; moins de 800 ms de bout en bout pour « C’est bon »).
• ≥99,95 % de précision sur CPF/CNPJ/clé d’accès/CRC Pix avec zéro faux positifs (tous rattrapés par les validateurs).
• ≥99 % d’acceptation de facture sans revue humaine sur DANFE propre ; ≤5 % de revue sur le bruit long tail ; < 0,05 $ par doc accepté à 100 k/mois.
• Capacité double source (on‑device + un chemin cloud/edge) avec politiques commutables et routage par champ.
• Confidentialité by design : rédaction on‑device des PII non nécessaires ; TTL 72 h pour l’image brute ; sortie chiffrée et typée uniquement.

Points clés

• La précision OCR moyenne est hors sujet — optimisez l’acceptation par champ avec validateurs et invariants.
• On‑device d’abord pour la capture grand public ; edge/auto‑hébergé pour le bulk ; API cloud pour les prototypes. Gardez une échappatoire double source.
• La latence se joue dans la capture et le pré‑traitement, pas dans les prompts. Le redressement et les ROI apportent les plus gros gains.
• Les coûts sont maîtrisables si vous routez par champ et n’escaladez que lorsque la confiance ou les invariants échouent.
• La confidentialité est une fonctionnalité produit, pas un document de politique. Rédigez on‑device, minimisez les uploads et supprimez de manière agressive.