Réponse courte. Lire un document par IA n'est pas « passer la facture dans un modèle » : c'est un pipeline en six temps. La prise de vue redresse, recadre et refuse la photo illisible tout de suite. La lecture transforme l'image en texte, arabe et français mêlés. La mise en champs contraint la sortie à un schéma : un montant est un nombre, une date est une date, et un champ a le droit de rester vide. Chaque champ reçoit une confiance ; sous le seuil écrit avec votre comptable, il part chez un humain avec l'image recadrée. Cinq contrôles qui ne demandent aucun modèle vérifient ensuite la justesse : somme des lignes, total, date plausible, fournisseur connu, doublon. Ce qui passe s'écrit dans l'ERP ; tout est journalisé avec l'image. Le schéma garantit la forme, pas la valeur : c'est l'arithmétique, votre base et un jeu de soixante documents réels qui garantissent le reste. Huit semaines, dont deux sans code.
Ce guide s'adresse au distributeur, à la clinique, à l'agence et au cabinet comptable en Algérie dont l'équipe recopie des papiers, et au fondateur installé en France dont l'application doit accepter des pièces photographiées par ses clients. Il détaille la fonction que le guide sur l'IA dans l'application présente en un paragraphe, et il prolonge notre page sur les fonctions IA ; il décrit ce qui se construit entre la photo et l'écriture comptable.
Ce que les chiffres disent
Un schéma garantit la forme, pas la justesse. La documentation d'OpenAI sur les sorties structurées dit que la fonction « garantit que le modèle génère toujours des réponses conformes » au schéma fourni, alors que le simple mode JSON ne garantit que du JSON valide ; celle d'Anthropic dit que les sorties structurées « garantissent des réponses conformes au schéma par décodage contraint », avec des types et des champs obligatoires assurés. Les deux listent les mêmes exceptions : un refus du modèle, ou une réponse coupée par la limite de tokens, peuvent ne pas respecter le schéma. Et aucune des deux ne dit que la valeur est juste : un total de 266 203 lu 266 208 est un nombre parfaitement conforme. Ce que cela impose : le schéma évite les erreurs de forme, et ce sont des règles autour du modèle qui attrapent les erreurs de valeur.
La lecture de l'arabe et du français existe en ouvert, et elle se teste. Tesseract, le moteur de reconnaissance de caractères ouvert le plus répandu, fournit des données pour environ cent vingt langues, dont l'arabe et le français ; les modèles récents qui lisent directement l'image vont plus loin sur les tableaux, les cachets et les mises en page irrégulières. Nous ne citons pas de taux de réussite : ceux qu'on trouve sont mesurés sur des documents propres, pas sur une facture algérienne photographiée de travers avec un cachet sur le numéro. Ce que cela impose : le modèle de lecture se choisit sur soixante de vos documents réels, bons et mauvais, avec les valeurs justes saisies par votre comptable.
Ce qui n'existe pas : un taux de lecture qui vaudrait pour vous. La part des documents qui passent sans humain dépend de vos fournisseurs, de vos téléphones, de vos cachets ; dans l'exemple plus bas nous posons 82 sur 100 comme hypothèse, et nous la disons telle. Ce qui se décide en revanche, par écrit, c'est le seuil : en dessous de quelle confiance un champ part chez un humain. Plus haut, l'équipe valide davantage ; plus bas, des erreurs passent seules. Et quand les documents sont sensibles, pièces d'identité, dossiers médicaux, le chemin se décide comme dans le guide sur le déploiement privé : la lecture se fait sur vos serveurs.
Une facture photographiée devient des champs
Le pipeline ne se décrit pas par son modèle mais par ce qui arrive à la photo, du comptoir de réception à la ligne de journal.
La prise de vue se fait dans l'application : cadre guidé, redressement, recadrage, contrôle de netteté ; une photo illisible est refusée tout de suite, pendant que le papier est encore sur le comptoir, pas le lendemain. La lecture transforme l'image en texte et en structure, lignes, colonnes, zones, avec l'arabe et le français sur la même page. La mise en champs demande au modèle de remplir un schéma : fournisseur, numéro, date, lignes, total hors taxe, taxe, total toutes taxes ; un champ absent du document reste vide, et chaque valeur doit se retrouver dans le texte lu.
La confiance par champ est ce qui rend le résultat utilisable : le numéro de facture lu 0418 ou 0413 sous le cachet reçoit 0,72, sous le seuil de 0,90, et il ne s'écrit pas ; il part dans la file de validation avec l'image recadrée sur le champ, la valeur proposée, et une touche pour valider ou corriger. Les cinq autres champs, au-dessus du seuil, continuent vers les contrôles. L'écriture dans l'ERP ou la comptabilité se fait par l'intégration décrite dans le guide sur l'intégration des logiciels existants, avec une clé d'idempotence pour qu'un renvoi n'écrive pas deux fois. Le journal garde l'image d'origine, les champs, les scores, les contrôles et le nom de qui a validé quoi.
Cinq contrôles avant d'écrire
Entre la lecture et l'écriture, cinq contrôles qui ne demandent aucun modèle, seulement de l'arithmétique et votre base.
La somme des lignes égale le total hors taxe : c'est le contrôle qui attrape le chiffre mal lu dans une ligne et la page manquante d'une facture de quarante lignes. Le hors taxe plus la taxe égale le toutes taxes : il attrape le chiffre mal lu dans un total. La date est plausible : ni dans le futur, ni plus ancienne qu'une durée écrite ; il attrape le jour et le mois inversés. Le fournisseur existe dans votre base, retrouvé par son identifiant ou son nom ; un fournisseur inconnu n'est pas une erreur, c'est une fiche à créer par un humain. Ce n'est pas un doublon : même fournisseur, même numéro, même montant ; c'est le contrôle qui évite de payer deux fois la facture arrivée par e-mail puis sur papier.
Trois issues : le document dont tous les champs sont au-dessus du seuil et qui passe les cinq contrôles s'écrit seul ; celui dont un champ est sous le seuil, ou dont un contrôle échoue de peu, part chez un humain, qui ne voit que ce champ ; celui qui est un doublon ou qui est illisible est rejeté et rattaché à sa raison. La répartition de la figure, 82, 15 et 3 sur cent, est une hypothèse : elle se mesure au pilote, et elle bouge avec le seuil. Ce qui ne bouge pas : aucun document ne s'écrit sans passer les cinq contrôles, et aucun humain ne ressaisit une facture entière.
«Un schéma garantit qu'un montant est un nombre ; c'est l'arithmétique et votre base qui disent s'il est juste.»
Un exemple chiffré
Un exemple sur des hypothèses de volume, avec des règles qui n'en sont pas : un distributeur, trois cents factures et bons de livraison par jour.
Trois cents documents par jour, photographiés à la réception ou reçus en PDF : c'est notre hypothèse, à mesurer. Un seuil de 0,90 par champ, écrit avec le comptable la première semaine et réglé au pilote, champ par champ : le total peut exiger 0,95, le mode de règlement se contenter de 0,80. Soixante documents réels dans le jeu d'évaluation, par type, bons et mauvais, avec les valeurs justes : ils sont rejoués à chaque changement de modèle, d'instructions ou de seuil, et une livraison dont la note baisse est refusée, sur le principe décrit dans le guide sur la livraison.
Cent pour cent des documents journalisés avec l'image, les champs, les scores, les contrôles et le validateur : c'est ce qui permet de répondre, six mois plus tard, à « qui a saisi ce montant ». Si l'hypothèse de 82 documents sur cent écrits seuls se vérifie, l'équipe ne voit plus que cinquante-quatre documents par jour, et sur chacun un seul champ ; ce calcul est le vôtre à refaire avec votre volume et votre seuil. Ce que la lecture ne remplace pas : le comptable, qui passe de la ressaisie au contrôle des écarts.
Six documents, ce qu'on en extrait et ce qu'on contrôle
Six documents que nous lisons le plus souvent, et pour chacun ce qui est extrait et ce qui est contrôlé.
La facture fournisseur : fournisseur, numéro, date, lignes, totaux, mode de règlement ; contrôlée par l'arithmétique, le fournisseur, le doublon, et rapprochée du bon de commande. Le bon de commande client, photographié ou reçu sur WhatsApp : client, produits, quantités, unités ; chaque produit est retrouvé dans le catalogue avec les synonymes, l'unité vérifiée, le plafond de crédit et le stock consultés, comme dans le guide sur le portail B2B. Le bon de livraison signé : quantités livrées, cachet, signature ; comparées aux quantités commandées, l'écart signalé ; c'est la preuve que le prévendeur de l'application de terrain rapporte.
La pièce d'identité : nom, prénom, date de naissance, numéro, expiration, dans les deux écritures ; comparées entre elles, et validées par un humain à chaque fois, parce qu'une identité ne se devine pas. L'avis de virement et le relevé : date, montant, donneur d'ordre, référence ; rapprochés d'une facture ouverte par une règle, jamais lettrés par intuition. L'ordonnance et le résultat d'analyse : classés dans le dossier du patient, sans aucune interprétation médicale, lus sur site et validés par le praticien, comme dans le guide sur le cabinet. Les trois premiers forment une chaîne, commande, livraison, facture, qui se rapproche seule et ne demande un humain que sur l'écart.
«L'humain ne ressaisit pas la facture : il voit un champ, la valeur proposée, et valide d'une touche.»
Six pièges de la lecture de documents
Six pièges que nous voyons sur les lectures de documents que nous reprenons, et ce que le pipeline fait contre chacun.
La photo floue ou de travers : redressement, recadrage et contrôle de netteté à la prise, et une nouvelle photo demandée tout de suite si rien n'est lisible. L'arabe et le français mêlés, chiffres latins et cachet par-dessus : un modèle de lecture qui tient les deux écritures, testé sur vos documents, et les champs écrits deux fois comparés entre eux. Le champ inventé : le modèle remplit une date qui n'est pas sur le document ; le champ a le droit de rester vide, la confiance est par champ, et chaque valeur doit se retrouver dans le texte lu.
Le tableau sur plusieurs pages : lecture ligne par ligne, somme recalculée, page manquante détectée par l'écart avec le total. Le doublon : clé fournisseur, numéro et montant ; le second est bloqué et rattaché au premier. Le document sensible envoyé dehors : un chemin par type de document, sur site pour les pièces d'identité et les dossiers médicaux, Europe pour le reste, écrit la première semaine. Les deux premiers se règlent à la prise de vue et au choix du modèle ; les quatre autres dans les règles autour du modèle, et un pipeline qui ne fait que « lire » tombe dans les six.
Vu ailleurs : les sorties structurées, Tesseract, et ce qui se transpose
Deux sources disent l'essentiel. Les documentations des éditeurs disent qu'une sortie structurée respecte le schéma, sauf refus ou réponse coupée, et ne disent rien de la justesse des valeurs ; ce qui se transpose, c'est qu'on arrête d'écrire du code pour réparer du JSON et qu'on écrit à la place des contrôles sur les valeurs. La liste des langues de Tesseract dit que la lecture de l'arabe et du français existe en ouvert depuis longtemps ; ce qui se transpose, c'est qu'un document simple se lit sans envoyer quoi que ce soit dehors, et qu'un modèle plus capable ne se justifie que sur les tableaux, les cachets et les mises en page difficiles.
Ce que ces sources ne disent pas : quels documents arrivent chez vous, dans quel état, quels champs votre comptabilité attend, et quel seuil votre comptable accepte ; les deux premières semaines du projet y répondent, avec soixante de vos documents sur la table.
Les règles d'une lecture de documents qui tient
Six règles, écrites la première semaine. Un type de document à la fois, avec ses champs, ses contrôles et son seuil. Le jeu d'évaluation avant le code : soixante documents réels par type, valeurs justes saisies par votre comptable. Un champ a le droit d'être vide ; une valeur sans trace dans le texte lu est refusée. Aucune écriture sans les cinq contrôles. L'humain voit un champ, pas un document : l'image recadrée, la valeur proposée, une touche. L'image est gardée, avec les scores et le validateur, aussi longtemps que l'écriture.
Une septième règle porte sur le devis : « OCR des factures » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « lecture des factures fournisseurs photographiées, champs X, Y, Z et lignes, schéma, confiance par champ, seuil réglable par champ, cinq contrôles listés, écran de validation par champ, écriture dans tel logiciel avec idempotence, journal avec image, note mesurée sur soixante documents réels à la recette, chemin des données par type de document », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « un OCR » a chiffré la lecture, pas la fiabilité.
Six entreprises, et le document qu'on lit d'abord
Six entreprises que nous équipons souvent, et pour chacune le premier document retenu la première semaine.
- Le distributeur et le grossiste. Factures fournisseurs et bons de livraison signés, rapprochés des commandes ; c'est là que la ressaisie est la plus lourde.
- Le cabinet comptable. Factures d'achat et de vente de dizaines de clients, chacun avec ses fournisseurs ; un schéma commun, une base fournisseurs par client, un écran de validation par dossier.
- La clinique et le cabinet. Ordonnances et résultats scannés dans le dossier du patient, sur site, sans interprétation, validés par le praticien.
- L'agence immobilière et l'espace propriétaire, décrits dans le guide dédié. Pièces d'un dossier de location et quittances, lues et classées, pièces d'identité validées à la main.
- La plateforme de livraison et la prévente. Bons de livraison signés photographiés sur le terrain, lus hors ligne ou à la synchronisation décrite dans le guide sur le mode hors ligne.
- Le fondateur en France. Pièces et justificatifs déposés par les clients de son application ; lecture, contrôle, et un tableau de bord des dossiers incomplets comme dans le guide sur le tableau de bord.
Le calendrier 2027
Le calendrier est celui d'une lecture de documents complète en huit semaines, dont deux sans code.
La semaine 0 à 1 écrit les documents, les champs et les seuils : les deux ou trois types retenus, les champs par type, les contrôles, le seuil par champ, le chemin des données ; signés. La semaine 1 à 2 constitue le jeu d'évaluation : soixante documents réels par type, propres et abîmés, avec les valeurs justes saisies par votre comptable. Les semaines 2 à 4 construisent la prise de vue, la lecture, le schéma, la confiance, les cinq contrôles et le journal ; la note sur le jeu est mesurée dès la première livraison. La semaine 4 à 5 construit l'écran de validation, celui qui décide de l'adoption : s'il faut plus de quelques secondes par champ, l'équipe retourne à la ressaisie.
La semaine 5 à 6 branche l'écriture dans l'ERP ou la comptabilité, avec le rapprochement commande, livraison, facture et l'idempotence. Les semaines 6 à 8 sont le pilote sur les documents du jour : part écrite seule, part validée, part rejetée lues chaque jour, seuil réglé champ par champ, cas ajoutés au jeu d'évaluation. Chaque lot de deux semaines est démontré et recetté sur le jeu.
Ce qui fait échouer la lecture de documents
Les lectures de documents que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Un OCR sans contrôle. Le texte est lu, écrit tel quel, et les erreurs se découvrent au rapprochement.
- Pas de confiance par champ. Tout passe, ou tout part chez un humain ; rien entre les deux.
- L'humain ressaisit le document entier. L'écran de validation montre la facture, pas le champ douteux ; le gain disparaît.
- La recette sur des PDF propres. Les documents du pilote sont des photos de travers avec un cachet.
- Pas de contrôle de doublon. La même facture, reçue deux fois, est payée deux fois.
- L'image n'est pas gardée. Six mois plus tard, personne ne peut dire d'où vient le montant.
- Les pièces d'identité envoyées à un éditeur sans contrat. Le chemin des données n'a jamais été écrit.
Questions fréquentes
Les questions que nous recevons de gérants, de comptables et de fondateurs.
- L’IA peut-elle lire nos factures en arabe et en français ?
- Oui, à condition de le mesurer sur vos documents : la lecture de l'arabe et du français existe en ouvert, et les modèles récents lisent directement l'image, tableaux et cachets compris. Nous choisissons le modèle sur soixante de vos documents réels, bons et abîmés, avec les valeurs justes saisies par votre comptable, et nous ne citons pas de taux avant de l'avoir mesuré.
- Que se passe-t-il quand la lecture se trompe ?
- Deux filets. La confiance par champ : sous le seuil écrit avec vous, le champ ne s'écrit pas et part chez un humain avec l'image recadrée. Les cinq contrôles : somme des lignes, total, date plausible, fournisseur connu, doublon ; une valeur conforme au schéma mais fausse est attrapée par l'arithmétique ou par votre base. Rien ne s'écrit dans la comptabilité sans les deux.
- Un humain doit-il encore intervenir ?
- Oui, sur ce qui le mérite : les champs sous le seuil, les fournisseurs inconnus, les écarts entre commande, livraison et facture, et toujours les pièces d'identité. Il ne ressaisit pas le document : il voit un champ, la valeur proposée, et valide ou corrige d'une touche. La part de documents concernée se mesure au pilote et se règle par le seuil.
- Où vont nos documents ?
- Là où le type de document a le droit d'aller, écrit la première semaine : les pièces d'identité et les dossiers médicaux sont lus sur vos serveurs ; les factures peuvent être lues par un éditeur hébergé en Europe avec un contrat à votre nom, ou sur site si vous le demandez. L'image d'origine reste dans votre base, avec le journal.
- Cela s’intègre-t-il à notre logiciel de comptabilité ?
- Oui, par l'API quand il en a une, par fichier d'import ou par une autre voie quand il n'en a pas, avec une clé d'idempotence pour qu'un renvoi n'écrive pas deux fois. Le rapprochement commande, livraison, facture se fait avant l'écriture, et l'écran de validation n'est pas dans votre logiciel : c'est une file légère, sur ordinateur ou téléphone.
- Combien de temps pour le mettre en place ?
- Huit semaines pour deux ou trois types de documents : une pour les champs, les contrôles et les seuils, une pour le jeu d'évaluation, deux pour la lecture et les contrôles, une pour l'écran de validation, une pour l'écriture dans l'ERP, deux de pilote avec réglage du seuil. Chaque lot de deux semaines est démontré et recetté sur le jeu.