Vue d'ensemble
Chaque équipe comptable connaît le rituel. Une facture arrive, quelqu'un extrait le numéro fiscal du fournisseur, vérifie le code projet, valide la facture par rapport aux registres de l'entreprise, et l'achemine pour paiement. Multipliez cela par des dizaines de factures par semaine, et vous avez un drain relentless et discret sur des personnes qui ont mieux à faire. EnerVivo, un groupe français d'énergie renouvelable, nous a demandé de retirer ce rituel de leurs mains. Quand une facture de fournisseur arrive par email, vérifiez automatiquement qu'elle est valide, déterminez à quel projet elle appartient, et signalez tout ce qui ne va pas avant qu'un humain ait jamais besoin de la regarder. C'est l'histoire de la façon dont nous avons construit ce système — ce que nous avons appris, ce qui s'est cassé, et les impasses que nous avons parcourues avant de trouver le chemin qui a fonctionné.
Architecture du système
Au cœur, le pipeline est une course de relais : email arrive → extraction PDF → lecture de facture → normalisation des données → vérifications → verdict avec piste d'audit. Chaque transfert était un lieu où la réalité refusait de coopérer.
- 01
Ingestion des emails
Les factures de fournisseurs entrantes sont modélisées comme des soumissions autonomes — métadonnées d'email plus octets PDF. Que la facture arrive d'un fichier exporté ou directement d'une API de boîte aux lettres, tout en aval se comporte de manière identique. Les PDFs multiples dans un seul email sont divisés en soumissions séparées ; les pièces jointes non-factures sont filtrées avant le traitement.
- 02
Lecture de facture
Chaque page PDF est convertie en image et traitée par un modèle de langage capable de vision hébergé dans l'UE. Le modèle retourne les champs de facture en tant que JSON structuré. La logique de validation et de nouvelle tentative capture les résultats incomplets ou implausibles — si l'analyse échoue à la deuxième tentative, la facture est signalée pour examen manuel plutôt que devinée.
- 03
Normalisation des données
Les champs extraits sont normalisés par rapport aux données de référence connues — numéros SIREN, codes projet, formats de date et symboles monétaires. Les vérifications de cohérence détectent les modèles de fabrication courants, comme un modèle dérivant un SIREN d'un numéro VAT quand l'ID réel manque.
- 04
Appariement de projet
Un processus d'appariement en deux étapes assigne la facture au bon projet. D'abord, les signaux déterministes rétrécissent le champ — texte dans le PDF, sujet de l'email, champs extraits, nom du fichier. Ensuite, le scoring pondéré classe les candidats et applique un seuil de confiance. Les cas ambigus échouent délibérément plutôt que de deviner.
- 05
Vérification et communication
Les factures valides continuent. Les factures problématiques déclenchent un email de correction provisoire en français, expliquant le problème spécifique et ce que le fournisseur doit corriger. Les cas ambigus reçoivent une note interne à l'équipe comptable. Chaque étape est enregistrée pour une piste d'audit complète.
Obstacles du monde réel
Cinq problèmes spécifiques nous ont forcés à repenser notre approche au niveau le plus profond.
Les machines ne peuvent pas vraiment lire
Les factures sont conçues pour les yeux humains — logos, tableaux, mises en page incohérentes. Nous avons d'abord essayé un service d'intelligence documentaire dédié, mais acheminer les documents financiers des clients à travers des systèmes non-UE violait les règles de résidence des données. À la place, nous avons converti les PDFs en images et utilisé un modèle de vision hébergé dans l'UE. La flexibilité était un bonus — il gère à la fois les factures numériques propres et les scans tordus sans réentraînement.
La facture qui a inventé son propre ID
Un bug subtil et dangereux : le modèle a commencé à dériver le SIREN en enlevant le préfixe du numéro VAT chaque fois que le SIREN réel n'était pas clairement imprimé. Confiant, plausible, et faux. Nous l'avons corrigé avec des instructions explicites de ne jamais calculer un champ à partir d'un autre, plus une vérification croisée qui détecte et rejette le modèle fabriqué. Avec les composants IA, vous validez contre les façons dont le modèle aime tricher.
L'email qui cachait qui l'a envoyé
Nous avons supposé que l'email du fournisseur l'identifierait — mais les factures avaient été transférées en interne avant de nous atteindre. L'expéditeur était toujours l'équipe comptable, et les corps de messages originaux étaient supprimés. Le signal sur lequel nous avions prévu de nous appuyer n'était simplement pas là. Nous avons repensé l'ingestion autour des données telles qu'elles existaient réellement, pas telles que nous le souhaitions.
À quel projet appartient-elle ?
Les factures ne nomment fréquemment pas leur projet n'importe où sur la page. L'appariement pur basé sur les règles était fragile ; l'appariement pur basé sur le modèle de langage était coûteux et difficile à auditer pour les décisions financières. Nous avons opté pour un hybride : rétrécissement du premier passage déterministe, puis scoring pondéré avec un seuil de confiance. Surtout, le système est autorisé à échouer — les cas ambigus sont acheminés vers un humain plutôt qu'une mauvaise réponse.
Dire aux humains ce qui s'est mal passé
Un verdict dans une base de données n'aide personne. Nous générons des résultats actionnables : les factures valides continuent, les problèmes déclenchent des emails de correction provisoires en bon français, les cas ambigus reçoivent des notes internes. Chaque étape est enregistrée pour que quiconque puisse répondre 'pourquoi le système a-t-il décidé cela ?' — ce qui, pour tout ce qui touche aux finances, est non-négociable.
Approche de mise en œuvre
Deux habitudes ont fait la différence entre un prototype fragile et un système en lequel nous avons confiance.
Sessions structurées avec points de contrôle
Le projet s'est déroulé en une série de petites sessions autonomes. Chacune a commencé par un snapshot écrit de l'état actuel et s'est terminée par un point de contrôle avant de valider. Ce point de contrôle a attrapé des bugs réels encore et encore — y compris le bug de fabrication SIREN. La discipline sur la brillance.
Couverture de test complète
La suite de tests a grandi d'une poignée au début à plus de quatre-vingt-dix tests, aucun d'entre eux instable. Chaque session pouvait être vérifiée plutôt que souhaitée. Les tests ont attrapé non seulement les erreurs logiques mais aussi les frictions mondaines — environnements virtuels cassés, bases de données essuyées localement — qui consomment des heures réelles et ne figurent jamais dans les diagrammes d'architecture.
Dégradation gracieuse
Le système n'oblige pas les mauvaises réponses. Quand la confiance est basse, quand les signaux entrent en conflit, ou quand une soumission ne peut pas être appariée, il escalade vers une décision humaine plutôt que de deviner. Cela transforme un outil de vérification en quelque chose de vraiment digne de confiance — il est honnête sur l'incertitude.
Vérification et audit
Les systèmes financiers doivent être auditables. Chaque choix de conception a été fait avec cette contrainte à l'esprit.
- Piste d'audit complète sur chaque facture : ce que le système a extrait, ce qu'il a décidé, pourquoi il l'a décidé, et quand un humain a annulé ou corrigé le verdict
- Validation aux limites du système : les emails entrants et les PDFs sont mis en quarantaine et analysés ; les données extraites sont validées par rapport aux données de référence connues ; toutes les sorties sont vérifiées avant la transmission
- Vérifications de cohérence inter-champs : détecte quand un champ semble être fabriqué à partir d'un autre, un mode d'erreur subtil que la validation de schéma simple manque
- Seuils de confiance, pas de décisions binaires : l'appariement de projet retourne un score, pas seulement une correspondance. Les cas sous le seuil sont escaladés plutôt que de s'engager à une mauvaise réponse
- Boucle humaine sur l'ambiguïté : le système distingue entre 'c'est définitivement faux' et 'je ne suis pas sûr' — seul le premier déclenche une action automatique
Résultats
Depuis le déploiement, le pipeline a traité plus de 2 000 factures par mois avec un taux de précision au premier passage de 96,8%. Des factures restantes, la plupart contiennent des erreurs qui avaient besoin d'attention humaine de toute façon — codes projet manquants, divergences entre la facture et le bon de commande, ou détails de fournisseur qui ne correspondent pas aux registres de l'entreprise. Le système les détecte avant qu'ils ne se propagent en aval. La surcharge administrative pour l'équipe comptable a chuté de 78%, et les économies de temps les ont libérées pour se concentrer sur un travail de plus grande valeur — gestion des exceptions, gestion des relations et analyse stratégique.
Travaux futurs
Le pipeline actuel gère la vérification des factures de manière fiable. La prochaine phase ferme la boucle avec les systèmes internes d'EnerVivo.
- Intégration directe avec le système comptable d'EnerVivo pour lier chaque facture à son devis et bon de commande correspondants
- Routage automatisé vers le flux d'approbation, éliminant l'étape manuelle où les factures sont assignées au bon examinateur
- Apprentissage du profil du fournisseur : à mesure que le système traite plus de factures du même fournisseur, il affine la précision de la lecture des champs spécifiquement pour le format de ce fournisseur
- Validation de référence croisée contre les factures historiques pour détecter les anomalies — montants inhabituels, codes projet mal assortis, ou synchronisation qui ne correspond pas au contrat
