Construire ou intégrer : la question que chaque éditeur finit par se poser
À un moment de la vie d'un logiciel de gestion, un client demande à pouvoir déposer une facture PDF plutôt que de la ressaisir. Puis un autre demande la même chose pour un relevé bancaire. Puis pour une note de frais photographiée au téléphone. Chaque demande, prise seule, ressemble à une petite fonctionnalité — jusqu'à ce que l'équipe technique réalise que lire correctement un document financier réel, avec ses polices variables, ses tableaux mal alignés et ses photos prises de travers, est un problème d'ingénierie à part entière, pas une case à cocher dans un sprint.
Cette page décrit comment une API de reconnaissance de documents s'intègre dans un logiciel de gestion existant — ce qu'elle lit, ce qu'elle renvoie, combien elle coûte à la page, et pourquoi l'hébergement des données en Union européenne n'est pas un détail secondaire quand vos propres clients sont des entreprises françaises ou européennes.
À qui s'adresse cette API
Éditeurs de logiciels de comptabilité
Lecture de factures fournisseurs et de relevés bancaires pour préremplir les écritures avant validation par l'utilisateur.
Éditeurs d'ERP et de logiciels métier
Un module de dématérialisation de documents intégré, sans construire une équipe OCR interne dédiée.
Éditeurs de note de frais
Reçus photographiés au téléphone transformés en lignes de dépense structurées, montant, date, catégorie.
Éditeurs de gestion locative et immobilière
Quittances, relevés bancaires de comptes séquestre et justificatifs de charges lus automatiquement.
Éditeurs de logiciels de paie
Bulletins de paie et justificatifs sociaux extraits pour le rapprochement avec la comptabilité générale.
Cabinets et grands comptes avec un outil interne
Un logiciel métier interne, non revendu, qui a exactement le même besoin de lecture de documents qu'un produit SaaS commercialisé.
Pourquoi construire son propre OCR coûte plus cher qu'il n'y paraît
Un premier prototype de lecture de facture, sur un jeu de documents propres et bien scannés, peut être construit en quelques semaines avec des bibliothèques d'OCR open source. Le problème n'est presque jamais ce premier prototype — c'est ce qui vient après : un relevé bancaire d'une banque jamais vue, une facture manuscrite en partie, un reçu de caisse froissé et pris en photo à contre-jour. Chaque nouveau format réel qui arrive en production révèle un cas que le prototype ne gérait pas, et l'équipe qui devait passer trois semaines sur ce module s'y retrouve encore dix-huit mois plus tard.
La variété des documents réels est sans fin
Chaque banque a son propre format de relevé, chaque fournisseur sa propre mise en page de facture — un modèle entraîné sur un échantillon fini rencontre en permanence des cas qu'il n'a jamais vus.
La maintenance ne s'arrête jamais
Un format qui change côté fournisseur ou une nouvelle banque ajoutée par un client casse silencieusement l'extraction jusqu'à ce que quelqu'un le remarque et corrige le modèle.
Le recrutement d'une équipe dédiée est un investissement lourd
Une compétence en vision par ordinateur et en traitement du langage se recrute difficilement et se rémunère en conséquence, pour un produit qui n'est pas le cœur de métier de l'éditeur.
L'infrastructure de traitement a un coût fixe
Serveurs de calcul, files d'attente, supervision — une infrastructure à faire tourner et surveiller en continu, même les mois où le volume de documents est faible.
Ce que l'API reconnaît
| Type de document | Cas d'usage typique |
|---|---|
| Facture fournisseur | Préremplissage des écritures comptables et rapprochement avec la commande |
| Relevé bancaire | Rapprochement bancaire automatique et suivi de trésorerie |
| Note de frais / reçu | Ligne de dépense structurée, montant, date, catégorie, TVA affichée |
| Bulletin de paie | Rapprochement avec les écritures de paie et les charges sociales |
| Bon de livraison | Contrôle de conformité entre commande, livraison et facture |
Ce que l'API renvoie
Chaque document envoyé revient sous la forme d'un objet JSON structuré : les champs d'en-tête (émetteur, date, numéro de pièce, montant total, TVA), les lignes de détail quand le document en contient (référence, quantité, prix unitaire), et un score de confiance par champ, pas seulement pour le document dans son ensemble. C'est ce score qui permet à votre logiciel de décider automatiquement quels champs accepter tels quels et lesquels signaler à un utilisateur pour confirmation, plutôt que de traiter chaque extraction comme certaine à 100 %.
Tarification à la page
Le tarif est fixé à la page traitée avec succès — un document qui échoue à l'extraction n'est jamais facturé. Aucun palier contractuel obligatoire à l'entrée, aucun minimum mensuel imposé : le coût suit directement le volume réel que traite votre logiciel, ce qui rend le calcul de marge simple à intégrer dans votre propre grille tarifaire.
| Volume mensuel | Ce que ça représente |
|---|---|
| Quelques centaines de pages | Un premier pilote avec un ou deux clients pour valider l'intégration |
| Quelques milliers de pages | Un module activé pour une partie de votre base client |
| Dizaines de milliers de pages et plus | Une fonctionnalité déployée à l'ensemble de votre base, avec tarif dégressif au volume |
Le détail complet des paliers figure sur la page tarifs.
Comment fonctionne l'intégration
Créez une clé API
Un compte gratuit suffit pour obtenir une clé et commencer à tester contre de vrais documents.
Envoyez un document
PDF, photo ou scan — un appel à l'API suffit pour lancer l'extraction.
Recevez le JSON structuré
Champs, lignes de détail et scores de confiance reviennent en quelques secondes.
Décidez du seuil de confiance
Acceptez automatiquement au-dessus d'un seuil, signalez pour vérification humaine en dessous.
Le détail pas à pas d'une intégration complète, avec la gestion des cas incertains et la supervision en production, est décrit dans le guide d'intégration.
Marque blanche : votre logiciel, pas le nôtre
L'intégration se fait entièrement côté serveur. Votre utilisateur final dépose un document dans votre propre interface, et voit le résultat apparaître dans votre propre logiciel — sans jamais rencontrer un écran, un logo ou une mention FlowParse. C'est votre marque qui porte la fonctionnalité, pas la nôtre — le même principe de marque blanche que celui détaillé sur la page API pour éditeurs de logiciels de gestion français.
RGPD et hébergement en Union européenne
Pour un éditeur qui vend à des entreprises françaises ou européennes, l'emplacement des serveurs n'est pas un détail technique secondaire — c'est souvent une question posée explicitement lors d'un appel d'offres ou d'une revue de sécurité par un client grand compte. Les documents transitent en TLS, sont traités sur des serveurs situés dans l'Union européenne, et sont supprimés immédiatement après extraction — aucune conservation prolongée du document original, aucun entraînement de modèle sur vos données clients.
Transmission chiffrée de bout en bout en TLS.
Traitement exclusivement sur des serveurs situés dans l'Union européenne.
Suppression du document original immédiatement après la lecture.
Aucune donnée client utilisée pour entraîner des modèles d'IA.
Le détail complet figure sur la page sécurité.
Selon le type de logiciel de gestion
| Type de logiciel | Ce que l'API apporte |
|---|---|
| Logiciel de comptabilité | Préremplissage des écritures depuis les factures et relevés bancaires |
| ERP / gestion commerciale | Rapprochement automatique entre bons de livraison, commandes et factures |
| Note de frais | Reçus photographiés convertis en lignes de dépense en quelques secondes |
| Gestion locative | Quittances et relevés de compte séquestre lus sans ressaisie manuelle |
| Logiciel de paie | Bulletins et justificatifs sociaux rapprochés de la comptabilité générale |
Le détail spécifique aux éditeurs de logiciels de comptabilité, avec l'angle plan comptable et export FEC, est traité sur la page API pour logiciels de comptabilité.
Le contexte de la facturation électronique obligatoire
La généralisation de la facturation électronique entre entreprises françaises change la nature des documents qu'un logiciel de gestion doit traiter, sans supprimer le besoin de lecture automatique : les factures reçues au format structuré via une plateforme de dématérialisation cohabitent, pendant toute la période de transition et au-delà pour les échanges internationaux, avec des factures PDF classiques, des relevés bancaires et des notes de frais qui, eux, restent des documents non structurés à lire. Le détail de cette bascule et des choix PDP/PPF est traité dans notre guide sur la facturation électronique et sur la page PDP ou PPF, que choisir.
Pour un éditeur de logiciel de gestion, cela signifie qu'une capacité de lecture de documents non structurés reste nécessaire même une fois la facturation électronique généralisée — tous les documents qu'un client dépose ne sont pas, et ne seront jamais tous, des factures structurées au format Factur-X.
Construire contre intégrer : le calcul complet
Construire en interne
Recrutement d'une compétence en vision par ordinateur, infrastructure de calcul à maintenir, mise à jour continue face aux nouveaux formats de documents, plusieurs mois avant un premier module utilisable en production.
Intégrer une API
Un tarif à la page qui suit l'usage réel, une intégration en une à trois semaines, et une équipe de vision par ordinateur qui n'a jamais besoin d'exister dans votre organigramme.
Fiabilité, exactitude et cas ambigus
Aucune extraction automatique n'est certaine à 100 % sur l'ensemble des documents réels qu'un client peut déposer — un ticket de caisse délavé, une photo prise dans un mauvais éclairage restent des cas limites pour n'importe quel moteur. La différence ne se joue pas sur la promesse d'une exactitude parfaite, mais sur ce qui se passe quand l'extraction est incertaine : un score de confiance par champ, pas seulement global, permet à votre logiciel de router automatiquement les cas ambigus vers une vérification humaine plutôt que de les intégrer silencieusement à vos données.
Un exemple chiffré
Un éditeur de logiciel de note de frais compte 200 clients actifs, chacun déposant en moyenne 40 reçus par mois — soit 8 000 documents mensuels. Au tarif à la page, ce volume représente un coût d'intégration prévisible, directement répercutable dans une grille tarifaire par utilisateur, sans les coûts fixes d'une équipe interne qui resteraient identiques que le volume double ou soit divisé par deux.
| Poste | Valeur |
|---|---|
| Clients actifs | 200 |
| Reçus déposés par client et par mois | 40 |
| Volume mensuel total | 8 000 documents |
| Équipe interne équivalente à maintenir | 1 à 2 ingénieurs à temps plein |
Sécurité et disponibilité
Une API embarquée dans un logiciel de gestion de production doit être disponible et prévisible autant que n'importe quel autre service dont votre propre produit dépend. Chiffrement en transit, suppression systématique des documents après traitement, et un comportement défini en cas d'indisponibilité brève — le document reste en file d'attente plutôt que de bloquer l'utilisateur — font partie de l'intégration dès le départ, pas d'un correctif ajouté après un premier incident.
Remplacer un OCR existant sans tout réécrire
Un éditeur qui utilise déjà un moteur d'extraction — interne ou fourni par un autre prestataire — n'a pas besoin de réécrire l'ensemble du module pour migrer. La pratique la plus courante consiste à faire tourner l'ancien et le nouveau système en parallèle sur un échantillon de documents réels, comparer les champs extraits, puis basculer progressivement le trafic une fois l'écart de qualité confirmé favorable — sans interruption de service pour les clients déjà en production.
Ce que cette API ne fait pas à votre place
Elle ne remplace pas votre logique métier
Le rapprochement comptable, le calcul de TVA applicable et la génération des écritures restent la logique de votre propre logiciel.
Elle ne conçoit pas votre interface utilisateur
L'écran de dépôt de document et l'écran de validation des champs extraits restent à construire dans votre propre produit.
Elle ne décide pas de vos seuils de confiance
C'est à votre logiciel de définir, selon votre tolérance au risque, quels scores déclenchent une vérification humaine.
Elle ne remplace pas un expert-comptable pour vos clients finaux
Elle transforme un document en données structurées ; la qualification comptable ou fiscale de ces données reste, comme aujourd'hui, une question métier.
Pour qui c'est fait
Cette API s'adresse aux équipes techniques d'éditeurs de logiciels de gestion qui préfèrent consacrer leur temps d'ingénierie à leur propre produit plutôt qu'à un moteur de lecture de documents qui n'est, pour la plupart d'entre eux, pas leur cœur de métier. Le detail des scénarios concrets, avec des exemples chiffrés par situation, est développé dans le cas d'usage API pour éditeurs de logiciels de gestion français.
Support et accompagnement à l'intégration
Une clé API livrée sans accompagnement laisse une équipe technique seule face aux premières questions concrètes — comment mapper tel champ, que faire d'un cas limite rencontré sur un document réel. L'équipe support répond en français, directement sur les questions d'intégration, sans passer par un centre d'assistance générique qui ne connaît pas le détail du moteur d'extraction.
Pour une intégration à fort enjeu — un grand compte, une migration depuis un fournisseur existant — un accompagnement plus poussé peut être organisé directement avec l'équipe technique, plutôt que de laisser une équipe cliente deviner seule le comportement attendu sur ses cas particuliers.
Précision, limites et amélioration continue
Aucun moteur d'extraction n'atteint une exactitude parfaite sur l'ensemble des documents réels qu'un client peut déposer — la question pertinente n'est pas de promettre 100 %, mais de savoir précisément où se situent les limites et comment elles sont gérées. Un score de confiance par champ, plutôt qu'une promesse globale, permet à votre intégration de distinguer un résultat fiable d'un résultat qui mérite un regard humain, ce qui compte davantage en pratique qu'un pourcentage d'exactitude affiché sur une page commerciale.
Le moteur continue par ailleurs de s'améliorer avec le volume traité — un nouveau format de document rencontré chez un client bénéficie, une fois correctement traité, à l'ensemble des intégrations qui utilisent la même API, sans qu'aucun client individuel n'ait à signaler explicitement le problème pour que la qualité progresse globalement.
Ce qui évolue dans le temps
Un schéma de réponse versionné garantit qu'une évolution du moteur d'extraction n'altère jamais silencieusement une intégration déjà en production — un nouveau champ peut être ajouté à la réponse sans casser le code existant qui ne l'attend pas encore. C'est une garantie structurelle, pas une simple promesse, qui compte particulièrement pour un éditeur dont le logiciel reste en production pendant des années sans réécriture complète.
Les nouveaux types de documents pris en charge — un format de bulletin de paie moins courant, un relevé d'une néobanque récente — s'ajoutent progressivement au moteur sans démarche particulière de votre côté : le même appel d'API bénéficie automatiquement de cette couverture élargie.