L’OCR de factures fournisseurs est l’un des modules les plus demandés par les PME camerounaises qui passent sur SynkriaOps. Le besoin est clair : réduire la saisie manuelle de 3-4 minutes par facture à 30 secondes de validation visuelle.
Mais l’OCR généraliste « anglo-saxon » performe mal sur les factures camerounaises. Voici ce qu’on a appris à calibrer.
Le problème de la qualité photo
Première constatation terrain : 80 % des factures sont photographiées au smartphone, pas scannées. Conséquences :
- Éclairage hétérogène — souvent près d’une fenêtre, contre-jour fréquent.
- Inclinaison — la facture est rarement à plat, parfois tenue à la main.
- Reflets — sur le papier glacé des chaînes hôtelières par exemple.
- Pliures — surtout sur les bons de livraison récupérés en bordereau.
L’OCR doit faire un prétraitement perspective + débruitage + déskew avant de tenter d’extraire du texte. Sans ça, le taux d’erreur sur les chiffres explose.
Le problème du format NIU
Le NIU (Numéro d’Identification Unique) est l’équivalent camerounais du SIRET
français : 13 caractères alphanumériques (ex: M101212345678A). Il identifie
un contribuable et doit figurer sur toute facture.
Un OCR généraliste cherche un VAT EU (FR12345678901), un EIN US (12-3456789), ou un SIRET français (123 456 789 00012). Aucun de ces patterns ne matche un NIU camerounais.
SynkriaOps utilise une regex dédiée et un score de plausibilité (la première
lettre est généralement M ou P selon le statut). Sans cette extraction
explicite, le contrôle fiscal devient pénible (le NIU est obligatoire dans le
champ « identité fournisseur » d’une écriture comptable).
Le problème de la TVA à 19.25 %
La TVA camerounaise est à 19.25 % (depuis 2005). Beaucoup d’OCR généralistes pré-entraînés sur du contenu français ou allemand calibrent leurs heuristiques sur 20 % ou 19 %, et rejettent une ligne TVA à 19.25 comme « probablement un montant non-TVA ».
Ajustement nécessaire : élargir la fenêtre de plausibilité TVA aux taux courants en zone CEMAC. Tableau :
| Pays | Taux normal | Taux réduits |
|---|---|---|
| Cameroun | 19.25 % | 0 % (exonérations) |
| Gabon | 18 % | 5 % et 10 % |
| Tchad | 18 % | — |
| Congo | 18.9 % | 5 % et 8 % |
| Centrafrique | 19 % | 5 % |
| Guinée Équatoriale | 15 % | — |
Sans cette table, l’OCR « lisse » la TVA et perd la précision sur les arrondis (cf. piège suivant).
Le problème des libellés bilingues
Au Cameroun, beaucoup de factures sont en français principal mais avec mentions anglaises (« Invoice », « Tax », « Subtotal ») ou en pidgin sur des bons de livraison gros marché. L’OCR doit reconnaître à la fois :
Montant HT↔Subtotal↔Net amountTaxe sur la valeur ajoutée↔VAT↔Sales taxTotal TTC↔Grand total↔Amount due
L’erreur typique : prendre Subtotal pour le montant TTC et Total pour le
montant HT (inversion totale du sens dans certains formats US-importés).
Ce que SynkriaOps fait — et ce qu’il ne fait PAS
Ce que l’OCR SynkriaOps fait :
- Pré-traitement perspective + débruitage + déskew (via pdfjs-dist + OpenCV)
- Extraction texte par bloc avec coordonnées
- Patterns dédiés : NIU CM/GA/CG, TVA 19.25/18/15, devises XAF
- Confidence score par champ
- Validation humaine obligatoire avant écriture comptable (pas d’auto-validation)
Ce qu’il ne fait PAS :
- Auto-validation des factures > 1 million XAF (seuil paramétrable)
- Apprentissage propriétaire sur les données de chaque tenant (privacy by design — on n’agrège pas les données entre PME)
- Détection de fraude avancée (signature falsifiée, faux NIU) — c’est le rôle de l’humain comptable
Mesure terrain
Sur 600 factures fournisseurs de la PME pilote de Douala (cf. témoignage communauté), le taux d’extraction nette est de 100 % (chaque champ attendu est extrait), avec validation humaine maintenue à 100 % sur les 6 premiers mois — c’est une discipline délibérée, pas une limite technique.
Les corrections humaines effectives représentent 1.8 % des champs sur la période — typiquement un débit/crédit inversé sur un avoir mal calibré ou une ligne d’arrondi mal pondérée.
Détails techniques : apps/api/src/modules/ocr/. Le service utilise
@anthropic-ai/sdk 0.78.0 pour la couche LLM finale (extraction structurée),
backed par un pré-traitement maison pour l’image. Le pattern complet est
documenté avec les tests E2E test/ocr-realtime.e2e-spec.ts et
test/pdf-ocr-import.e2e-spec.ts.