Facturation électronique : pourquoi l’interopérabilité va devenir le prochain chantier des DAF

Pendant des mois, les entreprises se sont posé une question :

Sommes-nous prêts pour la facturation électronique ?

À partir du 1er septembre 2026, la question va progressivement changer.

Elle va devenir :

Est-ce que tous nos outils sont capables de fonctionner correctement ensemble ?

Et ce n’est pas tout à fait le même sujet.

Car derrière une facture se cache aujourd’hui une chaîne de logiciels qui peut être beaucoup plus longue qu’on ne l’imagine.

• ERP
• Logiciel de facturation
• Plateforme Agréée
• Comptabilité
• Dématérialisation
• Trésorerie
• CRM
• Logiciel métier
• Reporting
• Banque

Et parfois quelques fichiers Excel qui continuent discrètement à faire le lien entre tout ce petit monde.

La facturation électronique va donc probablement avoir un effet collatéral particulièrement intéressant : elle va mettre en lumière les problèmes d’interopérabilité des systèmes d’information financiers.

Et pour les DAF, je pense que ce sera l’un des grands chantiers des prochaines années.

La réforme ne crée pas le problème. Elle le révèle.

Il serait facile d’accuser la facturation électronique de complexifier les systèmes d’information.

En réalité, beaucoup de cette complexité existait déjà.

La réforme va surtout la rendre beaucoup plus visible.

Prenons un processus relativement classique.

Une entreprise utilise :

• un CRM pour gérer ses clients et ses opportunités ;
• un ERP pour réaliser ses devis et ses factures ;
• une Plateforme Agréée pour échanger ses factures électroniques ;
• un logiciel comptable ;
• une solution de dématérialisation pour les achats ;
• un outil de trésorerie ;
• une solution de reporting.

Pris individuellement, chacun de ces logiciels peut parfaitement remplir sa mission.

Le problème apparaît entre les logiciels.

• Qui crée le client ?
• Quel outil possède la donnée de référence ?
• Qui transmet l’information à qui ?
• Que se passe-t-il lorsqu’une adresse change ?
• Où retrouve-t-on le statut d’une facture ?
• Quel système sait qu’elle a été rejetée ?
• Comment le CRM sait-il qu’elle a été payée ?
• Comment la trésorerie récupère-t-elle l’information ?
• Et que se passe-t-il lorsqu’un flux ne fonctionne plus ?

Ces questions existaient avant le 1er septembre.

La facturation électronique va simplement rendre leurs réponses beaucoup plus importantes.

Le DAF doit désormais penser en flux, et plus seulement en logiciels

Longtemps, les projets informatiques des directions financières ont souvent été abordés logiciel par logiciel.

• Changer la comptabilité
• Installer un nouvel ERP
• Déployer un outil de trésorerie
• Mettre en place une solution de dématérialisation
• Ajouter du reporting

Chaque projet pouvait avoir sa logique propre.

Mais lorsque les logiciels deviennent nombreux, cette approche atteint ses limites.

Le véritable sujet n’est plus seulement : « Quel est le meilleur logiciel pour répondre à ce besoin ? »

Il devient : « Comment ce logiciel va-t-il s’intégrer dans le reste de notre système d’information ? »

C’est un changement assez profond.

La valeur d’une solution ne dépend plus uniquement de ses fonctionnalités.

Elle dépend aussi de sa capacité à recevoir une donnée, la comprendre, la traiter puis la transmettre à d’autres systèmes.

API, connecteurs, formats de données et possibilités d’automatisation deviennent donc des critères de choix beaucoup plus stratégiques.

La réforme de la facturation électronique illustre parfaitement cette évolution.

La DGFiP a d’ailleurs placé l’interopérabilité au cœur du dispositif : les Plateformes Agréées doivent être capables d’échanger entre elles et de transmettre les informations nécessaires au nouveau système.

La logique est simple : une facture ne doit plus dépendre du fait que son émetteur et son destinataire utilisent le même logiciel.

Cette philosophie devrait, selon nous, progressivement s’étendre au reste du système d’information de l’entreprise.

Le problème n’est pas forcément d’avoir 10 logiciels

On entend souvent qu’une entreprise possède « trop d’outils ».

Je nuancerais.

Avoir plusieurs logiciels spécialisés n’est pas nécessairement un problème.

Un excellent CRM n’est pas forcément le meilleur outil comptable.

Un ERP n’est pas nécessairement la meilleure solution de trésorerie.

Un logiciel comptable n’a pas vocation à gérer parfaitement un processus commercial.

Et une solution de reporting spécialisée peut apporter beaucoup plus de valeur qu’un module générique.

Le problème n’est donc pas nécessairement d’avoir 5, 10 ou 15 applications.

Le problème est d’avoir 10 applications qui fonctionnent comme 10 îles.

Lorsque les outils ne communiquent pas, les utilisateurs deviennent eux-mêmes les interfaces.

• Ils exportent
• Ils importent
• Ils copient
• Ils recollent
• Ils ressaisissent
• Ils contrôlent
• Ils corrigent les différences

Et parfois, ils créent même un Excel pour faire communiquer deux logiciels qui n’avaient visiblement pas prévu de se parler.

C’est exactement le type de travail que l’interopérabilité doit progressivement faire disparaître.

La facture électronique va rendre la qualité des données beaucoup plus visible

Il existe un autre effet particulièrement intéressant de la réforme.

Elle oblige les entreprises à regarder leurs données de plus près.

Dans un fonctionnement largement manuel, une mauvaise donnée peut parfois être corrigée par un utilisateur.

• Une adresse erronée
• Un SIREN incorrect
• Une fiche client en double
• Une information fiscale absente
• Un établissement mal identifié
• Un utilisateur peut constater le problème et intervenir

Mais plus un processus est automatisé, moins ce fonctionnement est acceptable.

Un système informatique ne « comprend » pas qu’une donnée est probablement presque correcte.

Il exécute.

Et lorsqu’une mauvaise information est automatisée, elle peut être propagée très rapidement dans plusieurs logiciels.

L’interopérabilité ne consiste donc pas uniquement à connecter des API.

Elle nécessite également de répondre à une question fondamentale : quelle donnée est fiable, et quel logiciel en est propriétaire ?

C’est un sujet de gouvernance.

Et ce sujet concerne directement la direction financière.

Quel logiciel doit devenir la source de vérité ?

Prenons une information très simple : un client.

Cette donnée peut exister simultanément dans :

• le CRM
• l’ERP
• la comptabilité
• la Plateforme Agréée
• le logiciel métier
• l’outil de trésorerie

Mais où doit-elle être créée ?

Qui peut la modifier ?

Quelle application possède l’information de référence ?

Et lorsqu’une donnée change, comment les autres logiciels sont-ils mis à jour ?

Sans règle claire, chaque application finit par posséder sa propre version de la réalité.

Et on découvre alors :

« Dans le CRM l’adresse est correcte, mais pas dans Sage. »

« Le fournisseur existe dans la comptabilité mais pas dans l’outil achats. »

« Le SIREN est bon dans l’ERP mais pas dans l’autre base. »

Ce sont précisément ces petites incohérences qui deviennent beaucoup plus visibles lorsqu’on automatise les flux.

Avant de connecter tous les logiciels, il faut donc parfois commencer par décider qui est responsable de quoi.

Les statuts vont devenir aussi importants que les documents

La transformation est également conceptuelle.

Longtemps, lorsqu’on parlait d’une facture, on parlait essentiellement d’un document.

Demain, une facture sera de plus en plus un ensemble :

document + données + statuts + événements.

Une facture a été créée.

Elle a été transmise.

Elle a été reçue.

Elle peut être rejetée.

Acceptée.

Payée.

Et ces informations doivent pouvoir circuler.

C’est là qu’un sujet apparemment très technique devient extrêmement opérationnel.

Si une facture est rejetée sur une plateforme mais que l’ERP continue à la considérer comme correctement transmise, quelle information fait foi ?

Si le paiement est enregistré dans un système mais n’est jamais transmis au reste du SI, qui agit ?

Si un statut est mis à jour mais que l’utilisateur ne le voit pas dans son outil quotidien, peut-on réellement considérer le processus comme automatisé ?

Une bonne interopérabilité ne consiste donc pas seulement à déplacer un fichier d’un logiciel A vers un logiciel B.

Elle consiste à faire circuler correctement l’information métier.

API et connecteurs deviennent des actifs stratégiques

Il y a encore quelques années, demander à un éditeur s’il disposait d’une API pouvait presque ressembler à une question réservée aux développeurs.

Ce n’est plus le cas.

C’est désormais une question que les entreprises devraient poser avant même de sélectionner certains outils.

Une solution peut être excellente fonctionnellement.

Mais si récupérer ou envoyer une information nécessite systématiquement :

• un développement lourd
• une manipulation manuelle
• un export Excel
• une dépendance forte à un prestataire
• ou une ressaisie

elle crée une dette opérationnelle qui finira tôt ou tard par coûter cher.

À l’inverse, des API bien conçues et des connecteurs correctement maintenus permettent de construire progressivement un système d’information beaucoup plus flexible.

Le mouvement est d’ailleurs visible chez les éditeurs eux-mêmes.

Les plateformes et logiciels de gestion mettent désormais davantage en avant leurs capacités d’intégration, leurs API et leur connexion directe aux systèmes d’information.

Ce n’est pas un détail technique.

C’est une évolution du marché.

Mais connecter des outils ne suffit pas

Il existe toutefois un piège.

Celui de vouloir tout connecter parce qu’on peut tout connecter.

Automatiser un mauvais processus produit simplement… un mauvais processus automatisé.

Avant chaque projet d’interopérabilité, nous recommandons donc de répondre à quelques questions très simples :

• Quelle information voulons-nous faire circuler ?
• Pourquoi doit-elle circuler ?
• Quel logiciel la possède ?
• Quel logiciel doit la recevoir ?
• À quel moment ?
• Que se passe-t-il en cas d’échec ?
• Comment l’utilisateur le sait-il ?
• Qui est responsable du flux ?

Ces questions métier sont souvent beaucoup plus importantes que la technologie choisie pour réaliser l’interface.

Car un connecteur n’est pas une finalité.

Il doit servir un processus.

La réforme peut devenir une opportunité pour les DAF

La facturation électronique est d’abord une obligation réglementaire.

Mais s’arrêter à cette lecture serait dommage.

Elle offre aux directions financières une occasion assez rare de cartographier réellement leurs flux.

• D’où viennent les données ?
• Où passent-elles ?
• Qui les modifie ?
• Combien de ressaisies existent encore ?
• Quels contrôles sont manuels ?
• Quelles interfaces sont fragiles ?
• Quelles informations pourraient être automatisées ?
• Quels logiciels possèdent des données contradictoires ?

Et surtout :

Quelles tâches n’ont aujourd’hui aucune raison d’être encore réalisées manuellement ?

C’est probablement ici que commence le vrai retour sur investissement de la transformation digitale.

Pas nécessairement en achetant un logiciel supplémentaire.

Mais en faisant mieux travailler ensemble ceux que l’entreprise possède déjà.

De la conformité à l’architecture du système d’information financier

Je pense donc que le 1er septembre 2026 ne marque pas la fin du chantier de la facturation électronique.

Il ouvre un chantier beaucoup plus large.

Celui de l’architecture des systèmes d’information financiers.

Pendant les prochaines années, les DAF vont probablement devoir travailler de plus en plus étroitement avec les équipes informatiques, les éditeurs et leurs intégrateurs sur quatre sujets :

• la qualité de la donnée
• l’interopérabilité
• l’automatisation
• et la gouvernance des flux

L’intelligence artificielle viendra naturellement s’ajouter à cette transformation.

Mais avant de demander à une IA d’analyser parfaitement nos données, encore faut-il que nos systèmes soient capables de les faire circuler correctement.

C’est peut-être moins spectaculaire.

Mais c’est probablement beaucoup plus important.

Le futur n’est peut-être pas au logiciel qui sait tout faire

Longtemps, le rêve était celui du logiciel unique.

Une plateforme capable de gérer l’intégralité de l’entreprise.

Je crois de moins en moins à cette vision.

Les entreprises continueront probablement à utiliser plusieurs solutions spécialisées.

La différence se fera entre celles qui auront simplement empilé des logiciels…

…et celles qui auront construit un véritable écosystème.

Un système dans lequel les données circulent.

Dans lequel les ressaisies disparaissent.

Dans lequel chaque logiciel joue son rôle.

Et dans lequel l’utilisateur n’a pas besoin de comprendre toute la plomberie technique qui se cache derrière.

Parce qu’au fond, l’objectif de l’interopérabilité est extrêmement simple : faire en sorte que la complexité soit gérée par le système, plutôt que par les utilisateurs.

Et c’est exactement ce que la technologie devrait faire.

Simplifier.

BLC : connecter les outils plutôt que simplement les empiler

Chez BLC, nous accompagnons des PME et ETI autour de leur finance, de leur gestion, de leur CRM, de leur automatisation et de la facturation électronique.

Et nous constatons de plus en plus que le choix d’un logiciel n’est qu’une partie du sujet.

Sage 100, Pennylane, Pipedrive, les solutions de dématérialisation, les outils de trésorerie ou les logiciels métiers peuvent chacun répondre parfaitement à un besoin.

Notre rôle est aussi de réfléchir à la manière dont ces solutions doivent fonctionner ensemble.

• Comprendre les processus
• Définir les données qui doivent circuler
• Éviter les ressaisies
• Construire les interfaces
• Automatiser ce qui mérite de l’être

Et surtout faire en sorte que la technologie simplifie réellement le quotidien des équipes.

La facturation électronique va accélérer ce mouvement.

Et nous pensons que l’interopérabilité va devenir l’un des grands sujets des directions financières dans les prochaines années.

Le problème n’est pas d’avoir 10 logiciels. Le problème est d’avoir 10 logiciels qui fonctionnent comme 10 îles.