Garder son logiciel métier ou tout migrer : les 4 choix d'un éditeur face à la réforme

Vous éditez un logiciel de gestion. WinDev, Magic XPA, Delphi, Access, un applicatif AS400/RPG, une version ancienne de Sage ou de NAV. Vos clients l’utilisent tous les jours. Et la réforme de la facturation électronique vous oblige à prendre une décision que vous auriez préféré repousser.

Le calendrier ne laisse pas de marge. La réception des factures électroniques devient obligatoire pour toutes les entreprises au 1ᵉʳ septembre 2026. L’émission et l’e-reporting (transmission des données de transaction à l’administration) s’imposent aux grandes entreprises et aux ETI (entreprises de taille intermédiaire) à la même date, puis aux PME, TPE et micro-entreprises au 1ᵉʳ septembre 2027. Ces dates proviennent du calendrier DGFiP (Direction générale des finances publiques). À ce jour, aucun report n’est annoncé.

Pour vous, éditeur, la question n’est pas seulement technique. C’est une question de parc installé et de revenu récurrent. Voici les quatre options qui s’offrent à vous, leurs implications, et leurs limites.

D’abord, posez le calcul du parc menacé

Avant de comparer les solutions, évaluez le risque. Un client qui ne peut plus émettre ou recevoir ses factures dans les règles cherchera une alternative. Et l’alternative, souvent, c’est de quitter votre logiciel pour un produit “compatible” clé en main.

Chaque client perdu représente une perte de revenu de maintenance récurrent. Le montant exact dépend de votre propre grille tarifaire, que vous êtes seul à connaître. Multipliez ce montant par le nombre de clients dont la conformité dépend de vous. Le résultat n’est pas un coût ponctuel : c’est une perte qui se répète, année après année.

Ce calcul change la lecture des options. Une dépense d’investissement se compare à un flux de revenus protégé, pas à un coût isolé.

Option 1 : tout développer en interne

L’approche la plus naturelle pour un éditeur : ajouter le module de conformité directement dans votre logiciel. Vous maîtrisez le code, vous maîtrisez les données, vous gardez la main.

Le coût de développement initial varie fortement selon la complexité de votre applicatif et la richesse de votre modèle de données. Estimez-le avec vos équipes sur votre cas précis. Mais le chiffre initial n’est pas le vrai sujet.

Le vrai sujet, ce sont trois engagements durables :

• L’échéance. Vous développez en parallèle de votre roadmap habituelle. Si un autre chantier glisse, c’est l’échéance réglementaire qui est à risque. Et celle-là ne se négocie pas.
• La conformité à la norme EN 16931 (le standard européen de facture électronique structurée) et à ses règles de gestion, dont la règle BR-CO-15 qui impose l’équilibre HT + TVA = TTC. Une facture qui ne respecte pas ces contrôles est rejetée.
• La maintenance fiscale dans la durée. La réforme va vivre. Les règles de mapping TVA, les formats, les exigences de la plateforme évolueront. Chaque évolution sera une charge récurrente pour vos équipes, sur un sujet qui n’est pas votre cœur de métier.

Cette option a du sens si la conformité fait partie de votre différenciation produit et si vous avez la capacité d’absorber durablement une veille fiscale et normative. Soyez honnête avec vous-même sur ce dernier point.

Option 2 : attendre

Attendre est une option. Il faut la nommer pour l’évaluer.

L’argument : la réforme a déjà connu des ajustements de calendrier par le passé, donc autant ne pas mobiliser de ressources trop tôt.

Le contre-argument : le calendrier actuel est présenté comme fermé par la DGFiP, sans report annoncé. La première échéance, la réception obligatoire pour toutes les entreprises, tombe au 1ᵉʳ septembre 2026. Attendre, c’est concentrer la charge de développement sur une fenêtre courte, au moment où la demande de vos clients sera la plus forte et où les ressources techniques seront les plus rares.

Attendre comporte aussi un risque commercial silencieux. Pendant que vous attendez, vos clients, eux, ne peuvent pas attendre. Ceux qui cherchent une réponse maintenant la trouveront ailleurs. Le coût de l’attente ne se voit pas dans un budget : il se voit dans le parc, plus tard.

Option 3 : exporter à la main ou ressaisir

Solution de repli : extraire les données de votre logiciel, puis les ressaisir ou les charger dans un outil tiers pour produire les factures conformes.

C’est réalisable à très petite échelle. Mais cette approche se heurte vite à trois murs :

• Le volume. La ressaisie manuelle ne tient pas sur des centaines ou des milliers de factures par mois.
• L’erreur. Chaque saisie manuelle introduit un risque d’écart entre la donnée source et la donnée transmise. Or les contrôles de la norme sont implacables : une facture déséquilibrée est bloquée.
• Le suivi. La réforme ne s’arrête pas à l’envoi. Il faut suivre les statuts (reçue, rejetée, encaissée) et conserver les pièces. Un processus manuel ne trace pas correctement ce cycle de vie.

Cette option peut dépanner une micro-structure sur une transition courte. Comme réponse durable pour un parc de clients, elle ne tient pas.

Option 4 : intégrer une couche de conformité externalisée en lecture seule

Quatrième voie : ne pas réécrire votre logiciel, mais lui adjoindre une couche de conformité externe qui lit vos données sans jamais les modifier.

C’est l’approche que porte Liakont, le produit édité par Liadenn. Le principe tient en deux idées.

Lecture seule stricte

Un agent léger se connecte à la base de votre logiciel via ODBC (interface standard d’accès aux données) en lecture seule stricte : aucun INSERT, aucun UPDATE, aucun DELETE, aucun verrou posé sur vos tables. Votre logiciel continue de fonctionner exactement comme avant. La couche de conformité observe, elle n’intervient pas.

Concrètement : les données lues sont normalisées au standard EN 16931, le mapping TVA est paramétré par client et validé par l’expert-comptable de ce client (le paramétrage fiscal n’est jamais décidé unilatéralement), puis une série de contrôles qualité vérifie la cohérence, dont l’équilibre HT + TVA = TTC imposé par BR-CO-15. En cas d’écart, on bloque plutôt que de laisser passer une facture fausse.

Point à clarifier, car il structure tout le reste : Liakont ne produit pas la facture légale. La facture au format Factur-X et son acheminement vers l’administration relèvent d’une Plateforme Agréée (PA, anciennement appelée PDP), partenaire de la solution. Liakont est une Solution Compatible adossée à cette PA : il prépare et transmet des données structurées, la PA émet et route la facture vers le Portail Public de Facturation (PPF), devenu annuaire et concentrateur dans l’architecture dite “en Y”. Cette séparation des rôles est volontaire : la responsabilité de l’émission légale reste chez l’acteur agréé pour cela.

Architecture à plug-ins

Pour vous, éditeur, l’intérêt est de ne pas porter la veille réglementaire. La couche de conformité est mutualisée entre clients et évolue de son côté au rythme de la réforme. Votre logiciel garde son périmètre. L’intégration se fait par connecteur, sans refonte de votre code applicatif.

S’ajoute une supervision proactive : un mécanisme de détection de silence (dead-man’s switch) repère l’arrêt d’un agent et alerte avant que la non-conformité ne survienne, plutôt que de constater le problème après coup. L’archivage des pièces s’appuie sur une chaîne de hashes, dans une logique de valeur probante, sur une durée alignée sur les repères de conservation : à titre de repère, 6 ans au plan fiscal (Livre des procédures fiscales, art. L102 B) et 10 ans au plan commercial (Code de commerce, art. L123-22). Il convient de vérifier la durée applicable à votre situation avec votre conseil.

Les limites, dites clairement

Cette voie n’est pas magique. Elle suppose que vos données soient lisibles via ODBC et suffisamment structurées pour être mappées. La qualité du résultat dépend de la qualité des données source : un champ TVA absent ou ambigu dans votre base devra être clarifié, et cette clarification relève de l’analyse de l’expert-comptable du client, pas d’un automatisme. Certaines fonctions sont opérationnelles, d’autres en construction ou sur la feuille de route. Méfiez-vous, d’ailleurs, du discours “cinq lignes de code suffisent” qu’on entend parfois autour des convertisseurs génériques : transformer un export brut en facture conforme et contrôlée, suivre ses statuts et l’archiver, ce n’est pas une simple conversion de format.

Comment trancher

Résumons la grille de lecture :

• Développer soi-même protège votre maîtrise produit, mais vous engage sur une échéance à risque et une maintenance fiscale durable.
• Attendre ne fait que déplacer la charge vers une fenêtre plus étroite et plus risquée, en exposant votre parc entre-temps.
• Ressaisir dépanne à la marge, mais ne tient ni en volume ni en fiabilité.
• Externaliser une couche en lecture seule protège votre parc sans toucher à votre code, au prix d’une dépendance à un partenaire et d’une qualité conditionnée par vos données.

Aucune de ces options n’est universellement bonne. Le bon choix dépend de la taille de votre parc, de la valeur du revenu de maintenance en jeu, de votre capacité à porter une veille réglementaire dans la durée, et de l’état de vos données. Mettez ces quatre paramètres en face des quatre options, et la décision se dessine d’elle-même.

Si vous voulez approfondir le scénario de la couche externalisée et voir comment elle s’articule avec votre logiciel sans le remplacer, la page dédiée aux éditeurs détaille le fonctionnement du connecteur et le partage des responsabilités avec la Plateforme Agréée.