OCR des factures fournisseurs au Maroc : ce qui décide

Toutes les démonstrations d’OCR se ressemblent. On dépose une facture propre, elle est lue en trois secondes, les champs se remplissent, la salle est convaincue.

Puis arrive le lot du mois : des scans de travers, des photocopies de troisième génération, une facture bilingue, une autre avec le montant corrigé au stylo. C’est là que se joue la différence entre un outil qui tient et un outil qu’on abandonne au bout d’un trimestre.

Le taux de lecture ne veut pas dire grand-chose

Un éditeur qui annonce 95 % de reconnaissance ne dit rien d’exploitable, pour une raison simple : le taux se mesure sur un échantillon que vous n’avez pas choisi.

La seule question qui compte est ailleurs : que se passe-t-il pour les 5 % restants ?

• Si la facture mal lue est comptabilisée quand même, avec un montant faux, votre OCR est un générateur d’écarts. Vous le découvrirez au rapprochement, des semaines plus tard, et vous chercherez l’erreur dans le mauvais sens.
• Si elle est mise de côté pour reprise manuelle, vous avez un outil sain. Il traite ce qu’il sait traiter et rend la main sur le reste.

Un OCR qui doute et s’arrête vaut mieux qu’un OCR sûr de lui.

Les cinq contrôles qui séparent l’outil de la démonstration

Avant toute écriture en comptabilité, une facture lue devrait passer par cinq vérifications. Aucune n’est exotique, et l’absence d’une seule suffit à ruiner l’exercice.

1. Le fournisseur existe-t-il dans le fichier tiers ? Le rapprochement doit se faire sur une donnée stable — l’ICE de préférence, pas la raison sociale, qui varie d’une facture à l’autre.

2. Le total correspond-il à la somme des lignes ? Contrôle trivial, et il attrape la majorité des erreurs de lecture sur les montants.

3. La TVA est-elle cohérente ? Base × taux = montant, sur chaque ligne et sur le pied de facture. Une TVA qui ne retombe pas signale soit une lecture fausse, soit une facture à examiner.

4. Est-ce un doublon ? Même fournisseur, même numéro de pièce, même montant. Une facture payée deux fois, c’est une trésorerie qui sort et un litige fournisseur à froid.

5. L’échéance est-elle exploitable ? Une date d’échéance mal lue déforme votre prévision de trésorerie sans jamais déclencher d’alerte.

Une facture qui échoue à l’un de ces contrôles ne doit pas être comptabilisée. Elle doit être signalée.

Ce qui complique la lecture au Maroc

Le corpus marocain a ses particularités, et un moteur entraîné ailleurs les découvre à vos frais :

• Les factures bilingues français-arabe, avec parfois des montants en chiffres arabes orientaux.
• Le pied de page réglementaire : ICE, IF, RC, patente, CNSS. Utile — c’est là que se trouve l’identifiant fiable du fournisseur — mais dense, en petits caractères, souvent le premier à se dégrader au scan.
• Les mentions manuscrites : bon de livraison rapproché à la main, montant corrigé, cachet apposé en travers du tableau.
• La qualité du support. Une part significative des factures fournisseurs arrive encore en papier, et le scan se fait avec ce que le bureau a sous la main.

Aucun de ces points n’est rédhibitoire. Mais ils expliquent pourquoi un taux mesuré sur un jeu de factures européennes ne se transpose pas.

Où l’OCR doit s’arrêter

Un principe d’architecture, et il n’est pas négociable : on ne lit jamais directement dans la base Sage, et on n’y écrit jamais directement non plus.

La lecture directe est légitime pour consulter. L’écriture directe ne l’est jamais : le modèle de données de Sage porte des règles — compteurs, cohérences entre en-tête et lignes, reports analytiques — qui ne sont pas toutes inscrites dans le schéma SQL. Une écriture qui les ignore produit une base cohérente pour SQL Server et incohérente pour Sage. Le symptôme apparaît à la clôture.

Une facture reconnue par OCR doit entrer dans Sage par le même chemin qu’une facture saisie à la main, avec les mêmes contrôles. C’est plus lent d’un ordre de grandeur. C’est la seule façon d’obtenir une comptabilité sur laquelle s’appuyer.

Payer la lecture ou payer l’écriture

Le modèle de facturation d’un OCR n’est pas un détail commercial, c’est un détail d’usage.

Si le compteur se déclenche à la lecture, chaque essai vous coûte. Vos équipes hésitent à déposer une facture douteuse, calibrent moins, et finissent par contourner l’outil pour les cas difficiles — c’est-à-dire exactement ceux qui justifiaient l’investissement.

Si le compteur se déclenche à la comptabilisation, l’incitation s’inverse : un scan illisible ne coûte rien, un essai de calibrage ne coûte rien, une facture rejetée par les contrôles ne coûte rien. On ne paie que ce qui est réellement entré en comptabilité.

C’est le modèle retenu dans OptiFlow OCR, et il n’a pas été choisi pour des raisons commerciales. Il a été choisi parce que l’autre modèle décourage précisément le comportement qu’on veut obtenir.

Corollaire pratique : le compteur doit être visible en permanence par les équipes. Personne ne devrait découvrir un quota épuisé un jour de clôture.

Le protocole de pilote, en cinq points

Si vous évaluez une solution, ne regardez pas la démonstration. Faites ceci :

1. Constituez un lot de cent factures réelles, prises au hasard sur un mois, sans écarter les mauvais scans.
2. Comptez les factures comptabilisées sans reprise. C’est votre vrai taux.
3. Comptez surtout les factures comptabilisées avec une erreur. Ce chiffre doit être zéro. S’il ne l’est pas, l’outil est disqualifié, quel que soit son taux de lecture.
4. Chronométrez la reprise manuelle des factures rejetées. Un outil qui rejette beaucoup mais rend la reprise rapide reste un bon outil.
5. Vérifiez ce qui a été facturé pendant le pilote, et sur quelle base.

Le calcul de rentabilité se fait ensuite tout seul, sur vos volumes et vos coûts, sans qu’un commercial ait besoin de vous le faire.

Pour aller plus loin

La fiche du module OptiFlow OCR détaille les contrôles appliqués avant comptabilisation et le fonctionnement du compteur.

Si vous voulez éprouver la chose sur vos propres factures plutôt que sur les nôtres, c’est l’objet de la démonstration.