Si vous planifiez un routage des modèles OCR, la difficulté n’est pas de trouver un modèle capable de lire du texte à partir d’une image ou d’un PDF. La vraie difficulté consiste à décider quel chemin doit traiter l’OCR de texte brut, quel chemin doit traiter les formulaires et les tableaux, et quel chemin est autorisé, en premier lieu, à toucher des documents réglementés.
C’est pourquoi le routage des modèles OCR doit commencer par la politique, et non par la préférence envers un fournisseur. Un point de terminaison OCR texte à faible coût peut néanmoins être le mauvais chemin pour les factures. Un extracteur structuré de haute qualité peut néanmoins être le mauvais chemin pour des tâches d’archivage en masse. Et un chemin qui semble bon marché peut quand même devenir coûteux si ses limites synchrones imposent des reprises ou un mécanisme de secours.
Au 14 juillet 2026, la page d’accueil publique et la page de tarification de Flatkey positionnent le produit comme une passerelle IA unifiée avec une seule clé, un seul solde et des contrôles de routage. Le flux public de tarification vérifié pour ce brouillon exposait également des modèles capables d’OCR ou proches de la vision-OCR, tels que qwen-vl-ocr, deepseek-ocr et deepseek-ocr-2. Cet article reste rédigé comme un guide de routage plutôt que comme une garantie de catalogue : les lecteurs doivent vérifier le flux de modèles en direct et la page de tarification avant de connecter du trafic OCR de production.
Ce que le routage des modèles OCR optimise vraiment
Un bon routage des modèles OCR ne cherche pas un seul gagnant. Il attribue la bonne charge documentaire au bon chemin.
En pratique, les équipes équilibrent généralement cinq variables :
- Profondeur d’extraction : l’OCR de texte brut, la reconstruction de la mise en page, les tableaux, les formulaires, l’extraction clé-valeur et les signatures ne doivent pas relever d’un chemin par défaut unique.
- Unité de facturation : certains services facturent l’OCR simple à la page, tandis que d’autres augmentent fortement les coûts dès que vous demandez une extraction structurée.
- Contraintes documentaires : les limites de pages en synchrone, les limites en asynchrone, les plafonds de taille de fichier et les plafonds de requêtes par page affectent directement la fiabilité du routage.
- Contrôles des données : la conservation, la région et les frontières contractuelles peuvent éliminer des chemins avant même que vous ne compariez la qualité.
- Sécurité du fallback : un fallback n’est valide que s’il peut gérer la même classe de fichier, le même nombre de pages et la même classe de conformité sans dégradation silencieuse.
C’est là le vrai rôle du routage des modèles OCR. Ce n’est pas un classement. C’est un moteur de politique de charge de travail.
Commencer le routage de l’API OCR IA en normalisant d’abord les unités
Le premier mode d’échec du routage de l’API OCR IA consiste à comparer des prix qui semblent similaires mais sont associés à des résultats très différents.
Avant de comparer les chemins, réduisez chaque chemin à la même unité :
- Coût effectif en dollars par page pour l’OCR de texte brut
- Coût effectif en dollars par page pour l’extraction structurée
- Coût effectif en dollars par page pour les modules complémentaires ou les processeurs à plus forte valeur ajoutée
- Nombre maximal de pages par requête synchrone
- Nombre maximal de pages par tâche asynchrone
Les pages officielles de tarification actuelles rendent le décalage évident :
| Fournisseur | Signal tarifaire officiel vérifié le 2026-07-14 | Enseignement pour le routage |
|---|---|---|
| Google Document AI | Enterprise Document OCR : $1.50 / 1,000 pages ; modules complémentaires OCR : $6 / 1,000 pages |
Bon rappel que le prix de base de l’OCR et les couches d’amélioration sont distincts |
| Azure Document Intelligence | Lecture : $1.50 / 1,000 pages ; modèles préconstruits : $10 / 1,000 pages ; extraction personnalisée : $30 / 1,000 pages |
Un même document peut basculer entre des niveaux de coût très différents selon les exigences de sortie |
| Amazon Textract | Exemple Detect Document Text : $0.0015 / page ; tableaux : $0.015 / page ; formulaires : $0.05 / page ; exemple tableaux + formulaires + requêtes : $0.070 / page |
L’extraction structurée peut multiplier le coût de l’API OCR bien au-delà de l’extraction de texte de base |
C’est ici que le coût de l’API OCR est généralement mal interprété. Les équipes ne comparent que les tarifs OCR en texte brut, puis routent les factures, formulaires fiscaux et contrats via des niveaux de fonctionnalités qu’elles n’avaient jamais budgétés.
Pour l’examen du coût de l’API OCR, posez trois questions avant la mise en production :
- S’agit-il d’un devis pour de l’OCR en texte brut ou pour de l’extraction structurée ?
- Le prix du parcours distingue-t-il séparément les formulaires, tableaux, requêtes ou modules complémentaires ?
- Les limites de pages forceront-elles la tâche vers un chemin asynchrone ou de repli plus coûteux ?
Si vous ne pouvez pas répondre à ces trois questions, votre estimation du coût de l’API OCR est encore incomplète.
Utilisez des classes de charge de travail au lieu d’un route OCR par défaut
L’erreur suivante dans le routage de l’API OCR IA consiste à faire passer chaque document par le même chemin.
Cela crée généralement le pire des deux mondes :
- L’OCR d’archives à faible coût est sur-traité.
- Les charges de travail d’extraction de formulaires sont sous-spécifiées.
- Le repli devient risqué, car la route de secours ne peut pas reproduire la même forme d’extraction.
Une meilleure approche consiste à définir à l’avance des classes de routage :
| Charge de travail | Meilleur comportement de routage | Pourquoi c’est important |
|---|---|---|
| OCR en texte brut | En premier, la route texte approuvée la moins coûteuse | Sensible au coût et généralement tolérant envers une sortie plus simple |
| OCR sensible à la mise en page | Router vers des modèles qui conservent les paragraphes, titres et tableaux | Nécessaire pour le découpage en segments, la recherche ou les interfaces de revue |
| Formulaires/factures structurés | Router uniquement vers des extracteurs avec prise en charge de schéma ou une sortie clé-valeur fiable | L’exactitude doit être évaluée sur les champs, pas sur le texte brut |
| PDF volumineux en lot | Privilégier des routes asynchrones avec des plafonds de pages élevés et un comportement de file d’attente prévisible | Les limites en synchrone peuvent autrement casser le repli |
| Documents réglementés | Router uniquement vers des fournisseurs déjà validés pour les règles de conservation et de région | Le chemin le moins cher est sans importance s’il viole la politique documentaire |
C’est là que le routage des modèles d’IA documentaire devient plus utile qu’un benchmark OCR générique. Le routage des modèles d’IA documentaire vous permet de séparer « lire la page » de « extraire les champs métier » avant que les coûts et les mécanismes de secours n’explosent en production.
Placez des garde-fous de qualité avant le secours
La plupart des équipes disent vouloir de la qualité OCR, mais elles ne mesurent que la précision des caractères. C’est trop superficiel pour un véritable routage des modèles d’IA documentaire.
Votre politique de routage devrait évaluer la qualité selon la charge de travail :
- OCR de texte brut : exhaustivité du texte, ordre de lecture, prise en charge multilingue, tolérance à l’écriture manuscrite
- OCR de mise en page : limites des tableaux, hiérarchie des titres, regroupement des paragraphes
- Extraction de champs : précision clé-valeur, stabilité de la normalisation, visibilité des erreurs
- Opérations : parité synchrones/asynchrones, prise en charge des fichiers, plafonds de pages, limites de requêtes
La documentation sur les tarifs et les quotas d’Amazon Textract montre pourquoi cela compte. L’OCR est inclus dans les sorties d’Analyze Document, mais les requêtes synchrones PDF et TIFF sont limitées à 1 page, tandis que les tâches asynchrones PDF et TIFF peuvent aller jusqu’à 3 000 pages. La documentation sur les limites de service d’Azure relie directement le comptage des pages et le débit au comportement de facturation et de limitation. Google Document AI publie des quotas de pages par minute et de requêtes par minute selon le type de processeur.
C’est l’élément manquant dans de nombreux guides de routage de modèles OCR : le secours ne consiste pas seulement à savoir « quel fournisseur est disponible ». Le secours consiste à déterminer « quel fournisseur peut accepter la même classe de document sans casser la forme de sortie, les limites de pages ou la politique de coûts ».
Construisez des classes de secours autour des limites des documents
La conception la plus sûre du routage d’API OCR IA utilise des classes de secours explicites plutôt qu’un basculement large entre fournisseurs.
Voici un exemple pratique :
- Classe A : OCR synchrone sur une seule page pour les captures d’écran, les pièces d’identité ou les numérisations simples
- Classe B : OCR asynchrone multipage pour les grands PDF
- Classe C : extraction structurée pour les factures, les formulaires et les contrats
- Classe D : documents réglementés avec un ensemble de fournisseurs restreint
Définissez ensuite le secours uniquement à l’intérieur de la classe :
- Un routeur de Classe A peut basculer vers un autre routeur OCR synchrone.
- Un routeur de Classe B ne devrait basculer que vers un autre routeur asynchrone capable d’absorber le même nombre de pages.
- Un routeur de Classe C ne devrait basculer que vers un routeur qui préserve la structure des champs, et non vers du texte brut seul.
- Un routeur de Classe D ne devrait basculer qu’à l’intérieur de la même frontière de conformité.
C’est à cela que ressemble, en pratique, un routage des modèles d’IA documentaire fiable.
Arbre de décision pratique pour le routage des modèles OCR
flowchart TD
A[Nouvelle tâche de document] --> B{Besoin de champs structurés ?}
B -->|No| C{Fichier monopage ou petit fichier synchrone ?}
B -->|Yes| D{Flux de travail facture/formulaire/contrat ?}
C -->|Yes| E[Utiliser l’itinéraire OCR brut approuvé le moins coûteux]
C -->|No| F[Utiliser l’itinéraire OCR asynchrone avec marge de capacité en pages]
D -->|Yes| G[Utiliser l’itinéraire d’extraction structurée approuvé]
D -->|No| H[Utiliser l’itinéraire OCR tenant compte de la mise en page]
E --> I{L’itinéraire principal échoue ?}
F --> I
G --> J{Un repli équivalent préserve-t-il le schéma de sortie ?}
H --> I
I -->|Yes| K[Repli uniquement dans la même classe de taille de fichier et de limite de pages]
I -->|No| L[Retourner le résultat]
J -->|Yes| M[Repli vers un itinéraire structuré préapprouvé]
J -->|No| N[Escalader pour revue manuelle ou rerouter vers la file batch]
K --> L
M --> L
N --> L
Cet arbre de décision est le cœur du routage des modèles OCR. Construisez-le une fois, puis mappez les itinéraires dans l’arbre au lieu de réécrire la logique métier à chaque fois qu’un nouveau modèle OCR ou qu’un nouveau contrat apparaît.
Où Flatkey s’insère
Le positionnement public de Flatkey compte ici, car la douleur du routage OCR ne concerne rarement un seul appel de modèle. Elle se situe dans tout ce qui entoure l’appel : plusieurs fournisseurs, des unités de tarification mixtes, un fallback peu clair et une visibilité limitée sur les dépenses.
Le flux de tarification Flatkey en direct vérifié le 14 juillet 2026 affichait des entrées visibles capables d’OCR ou adjacentes à l’OCR, notamment qwen-vl-ocr, deepseek-ocr et deepseek-ocr-2, aux côtés de modèles d’image et de vision plus larges. Cela n’élimine pas la nécessité de valider la qualité de sortie ou la disponibilité actuelle. En revanche, cela rend l’histoire de la couche de contrôle plus pertinente pour les équipes qui comparent des options de routage d’API OCR IA via une seule passerelle plutôt que via des comptes fournisseurs dispersés.
Autrement dit : le routage des modèles OCR n’aide que si l’ingénierie, la finance et la sécurité peuvent examiner les mêmes itinéraires, la même logique de tarification et les mêmes classes d’échec. C’est le problème qu’un processus de passerelle unifié est censé résoudre.
Une liste de contrôle de lancement en quatre points
Avant de mettre le routage des modèles OCR en production, confirmez ces quatre éléments :
- Tarification normalisée par unité : vous pouvez expliquer le véritable coût de l’API OCR par itinéraire, pas seulement selon l’argument commercial du fournisseur.
- Classes de charge de travail : l’OCR brut, l’OCR de mise en page, l’extraction structurée et les documents réglementés ne partagent pas un chemin par défaut unique.
- Gates de qualité : chaque itinéraire est testé par rapport à la forme exacte de sortie requise par la charge de travail.
- Limites de fallback : le basculement reste dans la même classe de capacité en pages, de type de fichier et de conformité.
Si vous en omettez une seule, le routage des modèles OCR se transforme en tentatives répétées et en exceptions au lieu d’un système durable.
Conclusion
La meilleure stratégie de routage des modèles OCR est généralement ennuyeuse dans le bon sens du terme. Elle rend le coût de l’API OCR comparable, garde l’OCR simple peu coûteux, route l’extraction structurée vers le bon niveau et refuse de basculer vers un itinéraire qui ne peut pas traiter ce même document en toute sécurité.
C’est le standard à viser. Commencez par valider le catalogue en direct et la tarification que vous pouvez réellement acheter aujourd’hui, puis concevez le routage des modèles d’IA documentaire autour des unités de pages, des niveaux de fonctionnalités et des classes de fallback, ensemble plutôt qu’un par un.
Si vous souhaitez consulter la vue actuelle du catalogue public de Flatkey et de sa grille tarifaire avant de connecter de nouveaux itinéraires OCR, commencez par la page de tarification.
