Pourquoi nous avons choisi les modèles de langue plutôt que l'OCR pour les notes de frais
Quand vous prenez une photo d’un reçu avec ONexpense, quelque chose se passe en coulisses qui est différent de ce que font la plupart des logiciels de notes de frais. Ce n’est pas de l’OCR traditionnel. Cet article explique pourquoi nous avons fait ce choix, ce que ça change en pratique, et quelles sont les limites que nous n’allons pas vous cacher.
L’OCR traditionnel : un outil conçu pour un autre problème
La reconnaissance optique de caractères (OCR) a été inventée pour numériser des documents imprimés uniformes : formulaires administratifs, factures structurées, livres. Son principe est simple : identifier des caractères visuels et les transcrire en texte.
Pour les notes de frais, l’OCR traditionnel a longtemps été l’unique option disponible. Son fonctionnement en trois étapes :
- Détection des zones de texte sur l’image
- Reconnaissance caractère par caractère dans chaque zone
- Assemblage du texte reconnu
Le problème, c’est que les reçus ne ressemblent pas à des formulaires administratifs. Ils sont froissés, mal éclairés, pris en photo de travers. Chaque commerçant a son propre format. La TVA peut apparaître sous dix formes différentes : « T.V.A. 20% », « TVA incluse », « dont TVA : 8,50€ », « VAT 20.0 », ou même simplement une ligne sans libellé dans un tableau. Un OCR sans couche sémantique lit des caractères mais ne comprend pas ce qu’ils signifient.
Résultat concret : pour qu’un OCR traditionnel fonctionne de manière fiable sur les reçus, il faut lui apprendre chaque format de chaque type de commerçant. C’est ce qu’ont fait les pionniers du secteur — Expensya, N2F — pendant des années : constituer des bases de règles par type de reçu, par pays, par chaîne commerciale. C’est un travail de maintenance permanent, et il reste fragile dès qu’un commerçant change de caisse enregistreuse.
Ce que les modèles de langue apportent de différent
Un modèle de langue (LLM) ne « lit » pas des caractères visuels. Il reçoit du texte et comprend son sens à partir du contexte.
Dans le cas de la reconnaissance de notes de frais, le flux de traitement est différent :
- Une couche de reconnaissance visuelle extrait d’abord le texte brut de l’image (oui, il y a toujours de l’OCR dans cette étape — mais comme outil de conversion image→texte, pas d’interprétation)
- Ce texte brut est passé au modèle de langue, qui doit répondre à la question : “Quels sont le montant total, la TVA, la date, le fournisseur, et la catégorie de cette dépense ?”
- Le modèle répond en structured output — un objet JSON directement utilisable par l’application
La différence clé : le modèle de langue n’a pas besoin d’apprendre le format de chaque reçu. Il comprend que « dont TVA : 8,50€ », « T.V.A. 20% incluse », et « VAT: 8.50 EUR » signifient tous la même chose, parce qu’il a appris le sens du langage, pas des règles de format.
En pratique, cela se traduit par :
- Meilleure robustesse sur les reçus non structurés (restaurants, artisans, petits commerçants)
- Moins d’erreurs de champ : le montant HT n’est pas confondu avec le montant TTC
- Adaptation naturelle aux formats étrangers : un reçu espagnol ou britannique pris lors d’un déplacement professionnel est traité sans règles spécifiques
- Catégorisation contextuelle : un reçu chez « Brasserie du Commerce » est reconnu comme restauration sans règle codée en dur
Ce que ONexpense fait concrètement
Chez ONexpense, la reconnaissance des reçus s’appuie sur cette approche hybride : reconnaissance visuelle du texte brut, suivie d’une extraction sémantique par modèle de langue.
Notre taux de reconnaissance dépasse 90% en moins de 5 secondes sur les reçus soumis en conditions normales. Ce taux est mesuré sur la capacité à extraire correctement les quatre champs principaux : montant total, TVA, date, et fournisseur.
Quelques précisions honnêtes sur ces 90% :
- Les 10% restants correspondent principalement à des reçus avec une qualité d’image trop dégradée (photo floue, lumière insuffisante, reçu trop froissé). Dans ces cas, l’application signale le champ non reconnu et invite l’utilisateur à compléter manuellement.
- La catégorisation automatique est une couche supplémentaire avec un taux de précision légèrement inférieur, car elle dépend aussi de la politique de catégorisation propre à chaque entreprise.
- Les reçus manuscrits (certains artisans, tickets de caisse à la main) restent difficiles, quelle que soit la technologie.
Nous ne prétendons pas que la reconnaissance est parfaite. Nous affirmons qu’elle est significativement meilleure qu’une approche purement OCR sur la diversité des reçus rencontrés par une équipe commerciale en mobilité.
Ce que ça change pour votre équipe finance
Pour le collaborateur en déplacement, la différence est immédiate : il prend une photo, les champs se remplissent, il corrige le cas échéant et soumet. Plus besoin de saisir le montant à la main ni de se demander si le TTC est le bon champ.
Pour le manager ou le responsable finance, la différence est moins visible mais plus stratégique : moins d’erreurs à corriger en validation, moins d’anomalies dans les exports comptables, moins de temps passé à relancer les collaborateurs pour des notes de frais incomplètes.
Le gain de temps que nos clients rapportent — de l’ordre de 90% par rapport à un processus manuel, selon les retours de Gerald Evers, directeur financier chez Lucien Bikes — n’est pas seulement dû à la reconnaissance automatique. Il vient aussi de la cohérence des données extraites, qui élimine les allers-retours de validation.
La prochaine étape : l’intégration avec les agents IA
La reconnaissance de reçus par LLM n’est pas seulement une amélioration de l’UX. C’est aussi un changement d’architecture qui rend les données de dépenses compréhensibles par des systèmes automatisés.
Un agent IA qui interagit avec ONexpense via API reçoit des données structurées et sémantiquement cohérentes. Il peut poser des questions comme “quelles sont les dépenses de restauration de l’équipe commerciale ce trimestre ?” et obtenir une réponse exploitable, parce que les catégories ont été extraites avec une logique compréhensible.
C’est la direction dans laquelle nous allons : ONexpense comme couche de données de dépenses que les systèmes de votre entreprise — pas seulement vos collaborateurs humains — peuvent interroger et comprendre. Nous ouvrons l’accès en accès anticipé à notre API en septembre 2026. Si vous souhaitez être informé, vous pouvez rejoindre la liste d’attente sur notre page développeurs.
Questions fréquentes
L’OCR est-il totalement abandonné dans ONexpense ?
Non. L’OCR reste présent comme couche de conversion image-vers-texte, ce qu’il fait très bien. Ce qui change, c’est que cette couche ne fait plus d’interprétation — elle fournit du texte brut au modèle de langue, qui prend en charge l’extraction sémantique.
Mon ERP utilise déjà un OCR. ONexpense est-il compatible ?
Oui. ONexpense exporte les données extraites dans des formats personnalisables (CSV, Excel, formats Sage/QuickBooks/Cegid), compatibles avec votre chaîne comptable existante. La couche de reconnaissance est interne à ONexpense ; ce que votre ERP reçoit, c’est du données structurées.
La reconnaissance fonctionne-t-elle sur les reçus étrangers ?
Oui, avec un bon taux de réussite pour les reçus en langues latines (français, anglais, espagnol, italien). Les reçus en alphabets non-latins (arabe, chinois) ne sont pas encore pris en charge.
Que se passe-t-il si la reconnaissance est mauvaise ?
L’application identifie les champs non reconnus ou de faible confiance, les met en évidence, et l’utilisateur complète manuellement. Les données corrigées alimentent notre amélioration continue.