Trois problèmes en un
La note de frais est pénible pour trois personnes différentes, et pour trois raisons différentes.
Pour celui qui avance l’argent, c’est une corvée décalée dans le temps : il faut garder des tickets, se souvenir du motif de ce déjeuner du 12, remplir un tableau en fin de mois, et attendre. Le ticket perdu, c’est de l’argent personnel qui ne revient pas — et c’est ce qui rend le sujet plus sensible qu’il n’en a l’air.
Pour celui qui contrôle, c’est un travail de vérification ligne à ligne, sans enjeu dans quatre-vingt-dix pour cent des cas, et inconfortable dans les autres : refuser une dépense à un collègue est désagréable, surtout quand la règle est floue.
Pour l’entreprise, c’est de la TVA non récupérée sur les justificatifs perdus, des délais de remboursement qui abîment le climat, et une visibilité nulle sur les dépenses avant la clôture.
Ce qu’on automatise
La capture. Photo au moment de la dépense, envoyée sur le canal habituel. Tant que la capture est différée, les tickets se perdent.
L’extraction. Date, montant total, montants de TVA par taux, commerçant, moyen de paiement.
La catégorisation. Repas, transport, hébergement, fournitures, à partir du commerçant et du contenu.
Les contrôles. Plafonds, doublons — la même dépense envoyée deux fois, cas plus fréquent qu’on ne croit —, cohérence de date, justificatif obligatoire, TVA récupérable ou non selon le poste.
Le circuit de validation. Vers le bon valideur, avec relance s’il ne répond pas, et escalade au bout d’un délai.
L’export comptable et la mise en paiement au cycle de paie ou au virement suivant.
L’archivage. Justificatif conservé sous forme numérique avec son empreinte et sa date de capture.
Comment ça marche techniquement — pour qui veut le détail
La capture. Une boîte IMAP dédiée, un webhook de messagerie interne, ou un point de dépôt authentifié. La photo arrive avec ses métadonnées EXIF : date de prise de vue et, si la personne l’a autorisé, position. La date EXIF est un excellent contrôle de cohérence contre la date lue sur le ticket, et elle détecte les ressaisies tardives.
Le prétraitement de l’image. Redressement de perspective — un ticket photographié de biais se recadre par détection de quadrilatère sous OpenCV —, correction de contraste adaptative, conversion en niveaux de gris. Les tickets thermiques pâles gagnent beaucoup à un simple étirement d’histogramme. Cette étape pèse plus sur le résultat final que le choix du moteur de lecture.
L’extraction, en couches. D’abord Tesseract en local, suivi d’expressions régulières sur les motifs stables : dates en plusieurs formats, montants avec séparateur décimal virgule ou point, lignes de TVA (TVA 10,00 % 2,73), numéro de SIRET du commerçant quand il figure. Beaucoup de tickets se résolvent entièrement à ce niveau, sans qu’aucune donnée ne sorte. Ensuite seulement, sur les tickets mal lus, un modèle multimodal recevant l’image et renvoyant un objet contraint par un schéma Zod ou Pydantic : {date, total_centimes, tva: [{taux, montant}], commercant, categorie, confiance}. La sortie est validée avant d’être acceptée ; un modèle qui renvoie un total incohérent avec la somme des lignes est rejeté, pas corrigé.
Les contrôles arithmétiques. Le total doit égaler la somme des lignes HT et des TVA, aux arrondis près. La somme des TVA doit être cohérente avec les taux français en vigueur. Un montant qui échoue à ces contrôles élémentaires est renvoyé en saisie assistée, même si le modèle était confiant. C’est le garde-fou qui coûte le moins cher et qui attrape le plus d’erreurs.
La détection de doublon. Trois niveaux : empreinte SHA-256 de l’image (même fichier renvoyé) ; empreinte perceptuelle type pHash (même ticket rephotographié, donc fichier différent) ; et triplet métier (commerçant, date, montant) par la même personne, qui attrape le ticket saisi une fois par photo et une fois à la main. Ce troisième niveau est celui qui rapporte.
Le barème kilométrique. Distance calculée par un service de routage — OSRM ou Valhalla auto-hébergés sur des données OpenStreetMap, ce qui évite d’envoyer les trajets des salariés à un service tiers. Barème stocké en table, versionné par année et par puissance fiscale.
Le circuit de validation. Une machine à états en PostgreSQL : capturée → extraite → contrôlée → en_validation → validée | refusée → exportée → payée. Les relances de validateur sortent d’une table d’échéances consommée par un travailleur régulier, comme pour tout ordonnancement durable. Une validation par lot — le valideur voit les vingt dépenses de la semaine sur un écran avec les anomalies en tête — divise le temps de contrôle par rapport à une validation pièce par pièce.
L’archivage à valeur probante. La copie numérique d’un justificatif doit, pour remplacer l’original papier, respecter des exigences de fidélité et de durabilité. On conserve l’image d’origine non retouchée — pas seulement la version redressée —, son empreinte, sa date de capture, et on stocke le tout en écriture non modifiable. L’image traitée sert à la lecture, l’image d’origine sert de preuve.
L’export. Écriture comptable au format attendu par votre outil, ou fichier normalisé. Les montants sortent en centiers convertis au dernier moment, et chaque écriture porte l’identifiant de la dépense d’origine — ce qui permet de remonter du grand livre à la photo du ticket en un clic, y compris deux ans plus tard.