WinDev, Magic XPA, AS400 : être conforme sans migrer ni exposer d’API

Vous faites tourner votre gestion sur un logiciel qui a fait ses preuves depuis dix, quinze, parfois vingt ans. Il connaît vos clients, vos remises, vos cas particuliers. Et voilà que la réforme française de la facturation électronique arrive, avec un calendrier fermé. La première question qui revient est presque toujours la même : « Faut-il tout changer ? »

La réponse courte : non, pas nécessairement. La réponse longue mérite ce panorama.

Ce que « legacy » veut vraiment dire

Un logiciel « legacy » (hérité) n’est pas un mauvais logiciel. C’est souvent l’inverse : un outil tellement adapté à votre métier que le remplacer coûterait cher, prendrait des mois, et casserait des habitudes qui font votre productivité. Le problème n’est pas la qualité métier. Le problème est la communication avec l’extérieur.

La plupart de ces environnements ont été conçus à une époque où l’on n’imaginait pas devoir transmettre des factures structurées à une plateforme tierce. Ils stockent vos données proprement, mais ils n’exposent pas toujours de moyen simple et moderne de les faire sortir. C’est là que le sujet devient technique, et c’est là que l’approche change tout.

Le calendrier qui impose le rythme

Avant le panorama, le repère de date. La réforme, pilotée par la DGFiP (Direction générale des finances publiques), est annoncée comme ferme, sans report. Pour le détail, voir notre page La réforme en clair.

Réception des factures électroniques : obligatoire pour toutes les entreprises au 1ᵉʳ septembre 2026.
Émission et e-reporting pour les grandes entreprises (GE) et entreprises de taille intermédiaire (ETI) : 1ᵉʳ septembre 2026.
Émission et e-reporting pour les PME, TPE et micro-entreprises : 1ᵉʳ septembre 2027.

L’architecture retenue est dite « en Y » : les entreprises passent par une Plateforme Agréée (PA), qui dialogue avec le PPF (Portail public de facturation), désormais annuaire et concentrateur, sans dépôt gratuit. Retenez ce point : la facture légale est émise par la PA. Pas par votre logiciel, pas par une passerelle. Les sigles de la réforme (PA, PPF, e-reporting, « en Y ») sont détaillés dans notre glossaire.

Panorama des familles legacy

Voici les environnements que l’on rencontre le plus souvent, et la difficulté typique de chacun. Les contraintes décrites sont des tendances de terrain, à confirmer cas par cas selon votre version exacte et votre intégrateur.

WinDev (et HFSQL)

Très répandu dans les PME françaises, souvent via des applications développées sur mesure par un intégrateur local. La donnée est bien structurée, mais l’application n’expose généralement pas d’interface de programmation (API, Application Programming Interface) prête à l’emploi pour la facturation électronique. Les exports natifs existent, mais restent souvent limités à des formats bureautiques pensés pour l’humain, pas pour une transmission normalisée.

Magic XPA et bases Pervasive / Btrieve

Plateforme de développement applicatif historique, fréquemment adossée à des moteurs Pervasive (anciennement Btrieve). Les schémas de données peuvent être anciens et peu documentés. L’éditeur d’origine ou l’intégrateur n’est pas toujours disponible pour faire évoluer l’application. Demander un développement spécifique d’export structuré peut donc être long, coûteux, voire impossible si la maintenance n’est plus assurée.

Delphi

Beaucoup d’applications de gestion robustes ont été écrites en Delphi. Elles fonctionnent parfaitement, mais le code source n’est pas toujours maintenu, et la personne qui maîtrisait l’application a parfois quitté l’entreprise. Toucher au code pour y greffer une brique de facturation électronique revient à rouvrir un chantier que vous aviez clos depuis longtemps.

Access et bases bureautiques

Solutions souvent nées comme outils internes, qui ont grandi avec l’entreprise. Elles tiennent une comptabilité analytique fine, mais sans véritable couche applicative séparée. L’idée d’y ajouter une API n’a, le plus souvent, jamais été envisagée. La donnée est accessible, mais l’environnement n’a pas été pensé pour communiquer.

AS400 / IBM i et programmes RPG

L’archétype du système qui ne tombe jamais en panne. Des décennies de fiabilité, des programmes en RPG qui tournent sans broncher. Mais c’est aussi un monde à part, avec ses propres conventions, ses fichiers physiques et logiques, et une rareté croissante des compétences. Développer une nouvelle interface de sortie demande un profil spécialisé, et l’arbitrage budgétaire n’est pas évident pour un système que personne ne veut perturber.

Sage et NAV (Dynamics) anciens

Versions souvent figées, parce qu’une montée de version impliquerait de revoir des paramétrages, des reprises de données, des coûts de licence. L’éditeur pousse vers les versions récentes ; vous, vous voulez juste rester conforme sans tout reconstruire. Les exports existent mais peuvent être partiels ou rigides selon la version.

Le dénominateur commun : sortir la donnée

Dans toutes ces familles, on retrouve les mêmes trois freins :

Pas d’API moderne exposée par le logiciel source.
Export limité : formats pensés pour l’impression ou la lecture, pas pour une transmission structurée.
Un éditeur ou un intégrateur qui ne bouge pas : maintenance arrêtée, compétences rares, ou devis hors de portée.

Face à cela, deux philosophies s’opposent.

Deux approches, une différence de fond

L’approche qui demande au logiciel source de produire la donnée

Certaines démarches reposent sur le principe suivant : le logiciel de gestion doit lui-même fournir la facture, soit via une API à développer, soit via un export à mettre en place côté éditeur. C’est cohérent quand le logiciel est récent et coopératif. Mais sur un environnement legacy, cela revient souvent à demander un développement spécifique sur un système que vous vouliez justement laisser tranquille. Vous dépendez alors de la disponibilité de l’éditeur, du budget, et du calendrier — alors que la date réglementaire, elle, ne bouge pas.

L’approche en lecture seule directement dans la base

Liakont, la solution e-facturation éditée par Liadenn, prend le problème par l’autre bout. Plutôt que de demander au logiciel de produire quelque chose de nouveau, la passerelle lit la donnée là où elle se trouve déjà : dans la base.

Concrètement, un agent léger se connecte en lecture seule stricte, via ODBC (Open Database Connectivity, un standard d’accès aux bases), sans aucune écriture, sans pose de verrou sur vos tables. En cas de coupure, un buffer local chiffré prend le relais pour ne rien perdre. Votre logiciel ne sait même pas qu’on le consulte : il continue son travail exactement comme avant.

C’est la distinction de fond. Là où la première approche exige une production de données par le logiciel source, la seconde se contente d’une observation de données déjà présentes. Aucune ligne de code à modifier dans WinDev, Magic, Delphi, Access, sur l’AS400 ou dans votre Sage. Aucune API à développer. Aucun export à configurer côté éditeur. Le déroulé complet est décrit sur la page Comment ça marche.

De la base lue à la conformité

Lire la donnée n’est que la première étape. Voici ce qui suit, dans les grandes lignes :

Normalisation au standard EN 16931, la norme européenne de facture électronique.
Mapping TVA paramétré par tenant (par client de la passerelle) et validé par votre expert-comptable : ce n’est pas la passerelle qui décide de votre traitement fiscal, c’est votre conseil.
Une série de contrôles qualité (de l’ordre d’une vingtaine), dont la vérification de l’équilibre HT + TVA = TTC, qui correspond à la règle EN 16931 BR-CO-15. Le principe : bloquer une facture douteuse plutôt que de transmettre quelque chose de faux.
Transmission via la PA partenaire, avec suivi des statuts. La facture légale est émise par la PA, jamais par la passerelle.
Archivage organisé en chaîne de hachages pour la valeur probante.

Sur la conservation, deux repères à garder en tête, à apprécier avec votre conseil selon votre situation : la durée fiscale de 6 ans (Livre des procédures fiscales, article L102 B) et la durée commerciale de 10 ans (Code de commerce, article L123-22).

Le point fiscal : ne pas trancher à votre place

Un logiciel legacy a souvent accumulé des cas particuliers : TVA sur la marge, débours, remises de fin d’année, mandats de facturation. Ces sujets relèvent de l’interprétation, et il convient de les vérifier avec votre expert-comptable plutôt que de les figer à l’aveugle. À titre de repères, et sans rien trancher ici, citons le CGI (Code général des impôts) : l’article 289 pour le mandat de facturation, l’article 297 A pour la TVA sur la marge (régime susceptible d’évoluer, à confirmer avec votre conseil), et l’article 267 II-2 pour les débours. Les remises de fin d’année, elles, relèvent du traitement de la base d’imposition et appellent une analyse propre à votre situation. Le mapping de la passerelle est précisément l’endroit où ces choix, une fois validés par votre conseil, se traduisent en paramètres.

Ce que cela change pour vous

Rester sur votre logiciel n’est pas un aveu de retard. C’est souvent un choix rationnel : il fonctionne, vos équipes le maîtrisent, et la migration aurait un coût bien réel. La question n’est donc pas « migrer ou disparaître », mais « comment rendre conforme l’existant sans le perturber ».

Si votre environnement figure dans ce panorama, l’étape utile est simple : identifier précisément votre base, sa version, et qui la maintient encore. C’est à partir de ce diagnostic que se décide la suite — et c’est une conversation qui mérite d’être ouverte bien avant l’échéance qui vous concerne. Pour situer votre cas, vous pouvez commencer par notre diagnostic.