Comment concevoir un logiciel cloud qui saisit vos factures automatiquement ?

« Nous recevons quelques centaines de factures par mois. Quelqu’un les ouvre, les ressaisit et cherche qui doit les payer. Ça ne pourrait pas se faire tout seul ? »

Si. Et c’est même devenu bien plus simple qu’il y a quelques années, mais pas pour la raison à laquelle vous pensez.

Cet article décrit la conception d’un tel système : par où arrivent les factures, comment les lire, comment décider sur quel compte du grand livre elles vont, et (la partie qu’on oublie souvent) comment déterminer si quelqu’un doit encore faire quelque chose. Pas de code, mais l’architecture et les choix qui comptent vraiment.

Et d’emblée, une mise en garde honnête : l’automatisation ne fonctionne que si le processus en dessous tient la route. Si personne ne sait aujourd’hui qui approuve les factures, vous aurez demain le même flou, en plus rapide. Nous en parlons dans quand l’IA n’est pas la solution.

D’abord : la facturation électronique simplifie les choses

En France, la réforme de la facturation électronique change la donne. Au 1er septembre 2026, toutes les entreprises doivent pouvoir recevoir des factures électroniques. L’émission devient obligatoire à la même date pour les grandes entreprises et les ETI, et au 1er septembre 2027 pour les PME et les microentreprises. Envoyer un PDF par e-mail ne suffira plus : les factures passent par des plateformes agréées (PA), dans un format structuré conforme à la norme européenne EN 16931.

Ce n’est pas un détail. Cela change la conception de fond en comble.

Une facture électronique, ce sont déjà des données structurées. Nom du fournisseur, numéro de TVA, numéro de facture, échéance, ventilation de la TVA par taux, IBAN, référence de paiement : tout y est, lisible par une machine, exact. Pas besoin d’IA pour ça. Un parser suffit, et il a raison à 100 %.

Plus vous attendez, plus la part « l’IA lit un PDF » diminue. La vraie valeur de votre logiciel n’est plus dans la lecture du document, mais dans la décision de ce qu’il faut en faire. C’est un problème bien plus intéressant, et bien plus durable.

Par où arrivent les factures ?

En pratique, il y a trois portes, et il vous les faut toutes les trois :

1. La plateforme agréée. La voie principale pour le B2B en France. Vous vous raccordez à une plateforme agréée, qui fournit une API. Devenir soi-même plateforme agréée est un tout autre projet : ce service-là, vous l’achetez.
2. L’e-mail. Une boîte dédiée, par exemple factures@votreentreprise.fr. Nécessaire pour les fournisseurs étrangers, pour les documents de type B2C et pour tous ceux qui ne sont pas encore passés à l’électronique. Travaillez ici avec des webhooks (Microsoft Graph, Gmail API) plutôt que d’interroger IMAP en boucle, si vous le pouvez.
3. Le dépôt manuel. Un simple écran de glisser-déposer. Pour les tickets de caisse, les scans, et le fournisseur qui continue d’envoyer ses factures par la poste.

Trois portes, un seul entonnoir. Tout ce qui arrive passe par exactement le même pipeline.

Comment lire une facture ?

Deux chemins, choisis automatiquement pour chaque document.

Le chemin structuré. Si vous recevez de l’UBL ou du Factur-X, vous le parsez directement. Déterministe, gratuit, sans erreur. De mois en mois, ce canal devient le plus important.

Le chemin non structuré. Les PDF et les scans vont à un modèle d’IA qui en extrait les champs dans un schéma JSON strictement défini, avec l’OCR comme étape intermédiaire pour les mauvais scans. C’est la même approche que dans traiter des documents avec l’IA, avec un schéma plus strict, puisqu’il s’agit ici de montants. Demandez au modèle un score de confiance par champ. Ce score sera plus tard le moteur de toute votre logique de décision.

Les champs dont vous aurez besoin de toute façon : fournisseur et numéro de TVA, numéro de facture, date de facture et échéance, HT/TVA/TTC avec la ventilation par taux, IBAN, référence de paiement, devise, et les lignes de facture si vous voulez pouvoir ventiler par centre de coûts.

Vient ensuite la partie où vous gagnez ou perdez la confiance : les contrôles. Ils sont ennuyeux, déterministes et bon marché.

• La somme des lignes donne-t-elle le sous-total, et le total est-il juste ?
• Les taux de TVA sont-ils des taux français valides (en métropole : 20 %, 10 %, 5,5 % ou 2,1 %) ?
• Le numéro de TVA existe-t-il vraiment ? (contrôle VIES)
• La clé de contrôle de l’IBAN est-elle correcte, et est-ce le même IBAN que la dernière fois pour ce fournisseur ?
• Avons-nous déjà vu cette facture ? Dédoublonnez sur numéro de TVA plus numéro de facture plus montant, et sur un hash du fichier d’origine.

Ce quatrième contrôle est le plus important de tous. La fraude à la facture, où quelqu’un se fait passer pour un fournisseur connu avec un autre numéro de compte, est l’erreur la plus coûteuse qu’une PME puisse commettre avec ce genre de logiciel. Un IBAN modifié chez un fournisseur de confiance, c’est exactement le signal qu’un humain ne voit pas et qu’un logiciel ne rate pas.

Comment le logiciel sait-il sur quel compte imputer ?

La tentation est grande ici de tout demander à un modèle de langage. Ne le faites pas. Une cascade en trois étapes est moins chère, plus rapide et plus précise :

1. Des règles explicites. « Le fournisseur X va toujours en 613000. » Au bout de quelques mois, cela couvre l’essentiel de votre volume, car la plupart des PME ont un noyau fixe de fournisseurs.
2. La ressemblance avec les écritures passées. Cherchez les écritures historiques les plus proches de ce client, d’après le fournisseur et le libellé. Ce qui était juste la dernière fois l’est généralement encore.
3. Le modèle d’IA, en filet de sécurité. Seulement quand les étapes 1 et 2 hésitent. Donnez alors au modèle le vrai plan de comptes du client et une poignée d’écritures comparables en exemple, sinon il invente quelque chose de plausible qui n’existe pas.

Et puis la boucle d’apprentissage : chaque correction de l’utilisateur est réinjectée. Qui modifie une proposition crée, sans s’en rendre compte, une nouvelle règle ou un nouvel exemple. Au bout de quelques semaines, le système connaît les habitudes de cette entreprise-là. C’est pour cela qu’un logiciel sur mesure l’emporte ici sur un outil générique : les habitudes de votre comptabilité ne sont pas celles de votre voisin.

Dans le logiciel comptable, vous écrivez toujours une proposition, jamais une écriture définitive. Aucun expert-comptable n’accepte une boîte noire qui écrit dans le grand livre sans qu’on lui demande. Construisez un adaptateur par logiciel derrière une seule interface interne. Pour le marché français, Pennylane, Exact Online et Odoo sont des premières cibles réalistes. Chaque envoi reçoit une clé d’idempotence, car une nouvelle tentative qui comptabilise en double est pire qu’un échec.

Quand devez-vous encore intervenir ?

C’est la partie qui rend le logiciel vraiment utile, et curieusement, c’est rarement de l’IA. C’est de la logique ordinaire, explicite.

Traiter en silence s’il existe un prélèvement SEPA en place, si le paiement est déjà rapproché, ou s’il s’agit d’un avoir qui s’impute sur une facture existante. Ne rien faire est aussi une issue.

À vérifier pour un champ à faible confiance, un fournisseur que le système n’a jamais vu, un compte proposé qui est nouveau, ou un total qui ne tombe pas juste.

Action requise quand : pas de mandat et une échéance dans moins de X jours, un montant au-dessus d’un seuil que le client fixe lui-même, un IBAN modifié, un numéro de TVA qui ne se valide pas, une facture probablement en double, ou aucune correspondance avec un bon de commande.

Et puis l’e-mail

Deux canaux, volontairement séparés :

• Un récapitulatif quotidien à heure fixe : « 6 factures saisies, 2 demandent votre attention, 4 320 € arrivent à échéance avant vendredi. »
• Une alerte isolée, et celle-là, vous la gardez sacrée. Uniquement les signaux de fraude et les échéances vraiment urgentes.

Si tout part immédiatement, tout le monde arrête de lire au bout de deux semaines. La valeur d’une alerte tient entièrement à sa rareté. Chaque e-mail mène en un clic au bon écran, et ce qui reste en suspens revient, de plus en plus insistant à mesure que l’échéance approche.

En option, et étonnamment peu coûteux à construire : générez un fichier de virements SEPA (pain.001) pour les factures approuvées. Le client le charge une fois dans sa banque au lieu de ressaisir dix fois un IBAN.

Pourquoi l’event sourcing est le bon choix ici

Pour la plupart des logiciels, l’event sourcing est une option à considérer. Pour les factures, c’est presque une évidence, à cause du cadre légal : en France, le Code de commerce impose de conserver les pièces comptables, dont les factures, pendant dix ans, et vous devez pouvoir montrer qui a fait quoi, et quand.

Nous y avons consacré un article à part, l’event sourcing pour les logiciels de PME, mais le principe est simple. Au lieu d’une ligne dans une table que vous écrasez à chaque fois, vous enregistrez chaque événement : reçue, extraite, contrôlée, classée, approuvée, comptabilisée. Ce journal n’est jamais modifié, seulement complété.

Ce que cela apporte :

• La piste d’audit est toujours intégrée. Pas besoin de construire un système de logs à part : c’est le système lui-même.
• Chaque vue est une projection. Solde ouvert, trésorerie de la semaine, statistiques par fournisseur : tout est dérivé, tout peut être reconstruit. Et tout cela peut s’afficher simplement dans un tableau de bord, au lieu du tour mensuel dans Excel.
• Vous pouvez rejouer l’historique. Vous améliorez la logique de classement ? Vous la faites tourner sur tous les anciens événements et vous voyez aussitôt ce qui aurait changé. Pour des composants d’IA, c’est précieux.
• Chaque étape est idempotente et peut être relancée. L’extraction a échoué parce que le fournisseur d’IA était en panne ? Vous relancez une étape, pas tout le document.

L’original, vous le conservez de toute façon intact dans un stockage objet, avec un hash. Ce fichier est le document légal ; tout le reste est une donnée dérivée que vous pouvez reconstruire au besoin.

Pour ceux qui veulent les détails techniques

Voici comment nous le construirions :

Tout ce qui est à l’intérieur du pointillé vous appartient et tourne sur votre infrastructure. Ce qui est à l’extérieur, vous l’achetez ou vous vous y connectez. Cette distinction compte plus qu’il n’y paraît : elle détermine où sont vos données, qui y a accès, et ce qui se passe si un fournisseur double ses prix demain.

• Go pour le pipeline de traitement. C’est un système de nombreuses petites étapes simultanées qui attendent des API externes, exactement ce pour quoi le modèle de concurrence de Go est fait. Un seul binaire lié statiquement dans un petit conteneur, peu de mémoire, un démarrage rapide.
• Vue.js pour l’écran de vérification. La seule interface qui compte vraiment : la facture à gauche, l’écriture proposée à droite, tout est modifiable, et on approuve d’une touche. Quelqu’un utilise cet écran tous les jours ; il doit être rapide et utilisable au clavier.
• PostgreSQL pour tout : l’event log, les projections et la file d’attente. Postgres fait très bien l’affaire comme file de messages à ce volume, et cela vous épargne tout un composant en production. Pas de Redis ou de Kafka à part pour une PME qui traite cinq cents factures par mois.
• Un stockage objet pour les documents d’origine, avec chiffrement et une politique de conservation de dix ans.
• Docker Compose derrière Traefik, déployé sur un cloud européen. Nous faisons tourner notre propre infrastructure chez Scaleway depuis des années, et nous expliquons ce choix dans cloud européen ou alternatives américaines.

Un choix mérite une attention particulière : quel modèle d’IA utiliser pour l’extraction et le classement. Les factures contiennent des données fournisseurs, des montants et parfois des données personnelles. Les envoyer à une API américaine est une décision, pas un détail. Les modèles européens, comme ceux de Mistral, sont ici une vraie alternative, et « vos factures ne quittent pas l’Europe » n’est pas seulement juste sur le principe : c’est aussi un argument de vente. Si vous êtes concerné par NIS2, ou si vous fournissez quelqu’un qui l’est, cette question vous sera posée de toute façon.

Comment savoir si l’IA fonctionne assez bien ?

C’est la question qui reste le plus longtemps sans réponse dans ce genre de projet, et c’est la plus dangereuse. Un logiciel classique plante quand quelque chose ne va pas. Un modèle de langage donne toujours une réponse, et cette réponse sonne aussi convaincante qu’elle soit juste ou non. Une facture mal classée ressemble exactement à une facture bien classée, jusqu’au jour où quelqu’un se met à chercher au moment de la déclaration de TVA.

C’est pourquoi ce type de système a besoin d’un jeu de test : quelques centaines de vraies factures, vérifiées à la main, avec des seuils fixés à l’avance. Un travail ennuyeux de quelques jours, et le meilleur investissement possible dans un tel projet. Un prompt se réécrit en un après-midi ; un jeu de test vérifié, non.

Ce que vous mesurez concrètement diffère selon l’étape :

• Extraction : chaque champ est-il exactement juste ? Cela se note objectivement, car il n’y a qu’un seul bon numéro de facture et un seul bon montant.
• Classement : le système propose-t-il le même compte que celui qu’aurait choisi l’expert-comptable ? Ici, deux chiffres comptent plus qu’un pourcentage global : à quelle fréquence il propose quelque chose de faux, et à quelle fréquence il n’ose rien proposer. Le second est généralement le problème le moins coûteux.
• Les règles d’action : ici, vous ne mesurez pas l’IA mais votre propre logique, qui doit être déterministe et donc prévisible à cent pour cent.

Le moment où cela se rentabilise vraiment, c’est le jour où votre fournisseur d’IA déploie une nouvelle version de modèle, ou celui où vous modifiez vous-même un prompt pour régler une réclamation. Sans jeu de test, vous ne savez pas ce que ce changement a cassé ailleurs. Avec un jeu de test, vous relancez tout le jeu et vous le voyez aussitôt. Fixez donc la version du modèle sur un snapshot précis plutôt que sur « le dernier modèle », et testez une nouvelle version d’abord en mode fantôme avant de basculer.

La boucle d’apprentissage de la section précédente est d’ailleurs ici un carburant gratuit : chaque correction faite par un utilisateur est un cas de test vérifié que vous pouvez conserver.

Comment mettre en place une telle évaluation en pratique, quels chiffres comptent vraiment et où l’AI Act entre en jeu : c’est l’objet de notre article tester et évaluer l’IA.

Où ça se passe mal, le plus souvent ?

Quelques pièges qui reviennent le plus souvent en pratique :

• Les doublons. La même facture arrive par la plateforme agréée et en « copie » par e-mail. Sans dédoublonnage, vous comptabilisez tout deux fois.
• Trop automatiser en phase 1. Qui comptabilise directement en définitif sans écran de vérification perd la confiance de l’expert-comptable à la première erreur. Et cette confiance-là, vous ne la regagnez pas.
• Trop de notifications. Le bruit est pire que le silence.
• Les avoirs, les factures d’acompte et les paiements partiels. Ils cassent tout modèle de données naïf. Prévoyez-les dès le départ.
• Croire que le problème d’IA est le plus difficile. Il ne l’est pas. Le raccordement au logiciel comptable et la gestion des cas limites prennent plus de temps que l’extraction.

Comment nous abordons cela chez Tandem Studio

Nous construisons ce type de système par phases, avec un prix fixe par phase, pour que vous puissiez décider après chaque étape si la suivante en vaut la peine.

Phase 1 : le minimum qui fonctionne déjà. Entrée par dépôt et par e-mail, extraction, écran de vérification, une connexion comptable, récapitulatif quotidien. Rien de plus. Vous mesurez ici si le gain de temps est réel. C’est exactement l’approche de l’IA en entreprise : commencer petit, voir grand.

Phase 2 : le reste de la réalité. L’entrée par la plateforme agréée, les contrôles de fraude et d’IBAN, la boucle de retour, une deuxième connexion comptable.

Phase 3 : au-delà de la saisie. Fichiers de virements SEPA, rapprochement avec les bons de commande, un tableau de bord pour les cabinets d’expertise comptable.

Cette dernière phase soulève d’ailleurs la question la plus intéressante de toutes : qui est l’acheteur ? Une PME veut « ne plus jamais rater un paiement ». Un cabinet comptable veut « que mes clients arrêtent de m’envoyer des PDF par e-mail ». Le même pipeline, une tout autre interface et un tout autre modèle de prix. Mieux vaut répondre à cette question avant la première ligne de code.

Et tout ce que nous construisons tourne sur des serveurs européens, sans dépendance à un fournisseur, avec le code, les données et l’infrastructure entre les mains du client.

Questions fréquentes

Puis-je faire saisir mes factures automatiquement sans plus les vérifier ?

Techniquement oui, mais ne commencez pas par là. Comptabilisez automatiquement ce que le système reconnaît avec une confiance élevée et qui vient d’un fournisseur connu, et faites passer le reste par un écran de vérification. À mesure que le système apprend vos habitudes, cette limite se déplace d’elle-même.

Comment savoir si l’IA est assez fiable pour lui faire confiance ?

En la mesurant plutôt qu’en se fiant à son intuition. Vous constituez un jeu de test de vraies factures avec la bonne réponse, vous convenez à l’avance du taux d’erreur acceptable, et vous relancez ce jeu à chaque modification du prompt ou du modèle. Sans cette mesure, chaque ajustement est un pari.

Ai-je besoin d’IA maintenant que la facturation électronique devient obligatoire ?

De moins en moins. Les factures électroniques sont déjà structurées et n’ont pas besoin d’IA pour être lues. L’IA reste utile pour les factures étrangères, les tickets de caisse et les scans, et surtout pour proposer le bon compte et les bonnes catégories.

Un tel système fonctionne-t-il avec mon logiciel comptable actuel ?

Oui, et c’est bien le but. Le logiciel ne remplace pas votre logiciel comptable, il le complète : il fournit des propositions d’écriture prêtes à l’emploi via l’API de Pennylane, Exact Online, Odoo, Invoice Ninja ou d’un autre logiciel.

Combien de temps un tel système conserve-t-il mes factures ?

Au moins dix ans, la durée de conservation des pièces comptables prévue par le Code de commerce. Le fichier d’origine est conservé sans modification ; toutes les données dérivées peuvent être reconstruites au besoin.

Combien coûte la construction d’un tel système ?

Cela dépend entièrement du nombre de connexions et de cas limites dont vous avez besoin. C’est pourquoi nous travaillons par phase avec un prix fixe : vous commencez petit, vous mesurez le gain de temps, et c’est seulement ensuite que vous décidez de l’étape suivante.

Ressaisir des factures est typiquement un travail qu’un logiciel fait mieux qu’un humain : répétitif, source d’erreurs et entièrement régi par des règles. Votre équipe y passe-t-elle quelques jours chaque mois ?

Racontez-nous comment vos factures arrivent aujourd’hui, et nous esquisserons ensemble ce que contiendrait la phase 1.