Lecture seule stricte : rendre un logiciel conforme sans jamais écrire dans votre base

La première question que pose un responsable informatique, quand on parle de connecter un outil à son logiciel de gestion, est toujours la même. Est-ce que ça touche à ma base ? Est-ce que ça peut casser quelque chose ? La réponse, ici, est non. Et ce non n’est pas une promesse commerciale : c’est une contrainte technique inscrite dans la conception de l’agent. Voici comment cela fonctionne, concrètement.

Ce que veut dire “lecture seule stricte”

Beaucoup d’outils affirment lire vos données “sans rien modifier”. L’expression est floue. Nous préférons un terme précis : lecture seule stricte.

Concrètement, l’agent léger installé chez vous se connecte à votre base via ODBC (Open Database Connectivity, le standard d’accès aux bases de données). Il exécute uniquement des requêtes de lecture. Aucun ordre d’écriture n’est émis, ni directement, ni indirectement :

• aucun INSERT (création de ligne),
• aucun UPDATE (modification de ligne),
• aucun DELETE (suppression de ligne),
• aucun verrou posé sur vos tables.

Ce dernier point mérite une explication, car c’est souvent la vraie crainte. Un verrou (lock) est un mécanisme par lequel un programme réserve une ligne ou une table le temps de travailler dessus. Mal géré, il peut bloquer vos utilisateurs : une facture qu’on ne peut plus enregistrer, un écran qui tourne. L’agent ne pose pas ce type de verrou exclusif. Il lit ce qui existe déjà, comme un observateur, sans s’interposer entre vos collaborateurs et leur logiciel.

L’image juste n’est pas celle d’un plombier qui ouvre vos canalisations. C’est celle d’un compteur qui mesure le débit, posé à côté, sans jamais couper l’eau.

Pourquoi cette contrainte est non négociable

On pourrait techniquement imaginer un agent qui écrit, ne serait-ce qu’un indicateur de “ligne traitée” dans votre base. Nous avons fait le choix inverse, et ce choix structure tout le reste.

Votre logiciel de gestion (WinDev, Magic XPA, Delphi, Access, AS400/RPG, ou un Sage ou NAV d’ancienne génération) reste l’unique maître de vos données. Liakont ne s’y substitue pas, ne le remplace pas, ne le modifie pas. Il prépare, à partir d’une lecture de votre base, des données structurées destinées à la mise en conformité. Le logiciel source, lui, continue exactement comme avant. Si vous débranchez l’agent demain, il ne reste aucune trace dans votre base.

Le buffer local chiffré : tenir bon en cas de coupure

Une objection légitime arrive ensuite. “Et si le réseau tombe pendant l’extraction ?”

L’agent est conçu pour absorber cet incident sans vous demander de ressaisie. Il dispose d’un buffer local chiffré : une mémoire tampon, stockée chez vous sous forme chiffrée. En cas de coupure réseau, les données déjà lues y sont conservées. Dès que la connexion revient, le rattrapage se fait automatiquement.

Deux précisions sur ce point.

D’abord, ce buffer est chiffré. Même stockée temporairement, l’information n’est pas lisible en clair sur le disque. Ensuite, cette résilience travaille de pair avec notre supervision. Notre plateforme surveille en permanence le signe de vie de chaque agent : c’est ce que nous appelons le dead-man’s switch (littéralement “interrupteur d’homme mort”, un dispositif qui se déclenche quand le signal s’arrête). Si un agent se tait trop longtemps, nous le détectons et nous vous alertons avant que cela ne devienne un problème de conformité. Vous n’avez pas à surveiller vous-même que “ça tourne”.

L’idée directrice est simple : la coupure réseau est un incident normal de la vie informatique, pas un événement catastrophique. L’architecture est conçue pour l’absorber.

Aucune dépendance à l’éditeur de votre logiciel

C’est sans doute le point le plus libérateur, et celui que l’on comprend le mieux par contraste.

L’approche qui exige une coopération du logiciel source

Une partie des solutions de mise en conformité reposent sur une condition : que votre logiciel source expose une API (interface de programmation permettant à deux logiciels de dialoguer) ou qu’il sache produire un export dans un format précis. Sur le papier, c’est élégant.

Dans la réalité des logiciels legacy, c’est souvent un mur. L’éditeur d’origine n’existe plus, ou ne maintient plus la version que vous utilisez. Le développement spécifique d’une API se chiffre en semaines de prestation, avec un devis à la clé. Le module d’export “standard” ne sort pas tout à fait le bon format, et il faut un projet pour l’adapter. Vous vous retrouvez dépendant d’un tiers, sur un planning qui n’est pas le vôtre, pour un logiciel que vous vouliez justement garder tel quel.

Notre parti pris : lire ce qui existe déjà

L’agent ne demande rien à votre logiciel. Il ne réclame ni API, ni module d’export, ni mise à jour, ni intervention de l’éditeur. Il lit la base de données telle qu’elle est, via ODBC.

Cela change la nature du projet. Vous n’ouvrez pas un chantier de développement chez l’éditeur de votre logiciel de gestion. Vous ne dépendez pas de sa disponibilité, ni de son tarif, ni de son existence. C’est précisément parce que le marché est plein de logiciels que leur éditeur ne fait plus évoluer que cette approche prend tout son sens. Votre outil de gestion peut rester ce qu’il est : une application stable, éprouvée, que vos équipes connaissent. La conformité vient se brancher à côté, sans le bousculer.

Un déploiement de l’ordre d’une journée

Parce que l’agent n’exige pas de développement côté logiciel source, l’installation est rapide. L’ordre de grandeur que nous constatons est celui d’une journée.

Concrètement, le travail consiste à :

• installer l’agent léger sur un poste ou un serveur ayant accès à la base,
• configurer la connexion ODBC en lecture sur cette base,
• identifier les tables et champs utiles à l’extraction,
• vérifier que les premières données lues sont cohérentes.

Cet ordre de grandeur dépend évidemment de votre contexte : nombre de logiciels à raccorder, organisation de vos accès, disponibilité de la personne qui connaît votre base. C’est un repère honnête, pas un engagement chiffré universel. Mais le principe tient : sans chantier de développement préalable, le délai se compte en jours, pas en mois.

Ce que l’agent fait, et ce qu’il ne fait pas

Pour lever toute ambiguïté, posons clairement la frontière.

L’agent léger lit vos données en lecture seule stricte et les transmet, chiffrées, à notre plateforme. Là, elles sont normalisées au standard européen EN 16931, qui structure le contenu d’une facture électronique. Le mapping TVA (la correspondance entre vos codes internes et les règles de TVA) est paramétré pour votre entreprise puis validé par votre expert-comptable. Une série de contrôles qualité vérifie la cohérence, dont l’équilibre HT + TVA = TTC, porté par la règle EN 16931 BR-CO-15. Cette règle est considérée comme fatale : en cas de déséquilibre, nous bloquons plutôt que de laisser partir une facture fausse.

En revanche, Liakont n’émet pas la facture légale. Liakont est une Solution Compatible (SC), adossée à une Plateforme Agréée (PA, anciennement appelée PDP). C’est cette plateforme partenaire qui produit la facture au format réglementaire et la transmet vers le Portail Public de Facturation (PPF), devenu annuaire et concentrateur dans l’architecture dite “en Y”. Liakont prépare et transmet des données structurées ; la PA émet la facture légale. Cette distinction n’est pas un détail juridique : elle dit clairement où s’arrête notre responsabilité et où commence celle de la plateforme agréée.

Une échéance qui rend la question concrète

Cette mécanique de lecture seule prend tout son intérêt à l’approche du calendrier de la réforme. D’après les informations publiées par la DGFiP (Direction générale des finances publiques), la réception des factures électroniques devient obligatoire pour toutes les entreprises au 1ᵉʳ septembre 2026. L’émission et le e-reporting suivent au 1ᵉʳ septembre 2026 pour les grandes entreprises et les ETI (entreprises de taille intermédiaire), puis au 1ᵉʳ septembre 2027 pour les PME, TPE et micro-entreprises.

Le point à retenir : il n’est pas nécessaire de remplacer votre logiciel de gestion pour tenir ces échéances. Vous pouvez le conserver, et lui adjoindre une passerelle qui le lit sans jamais y écrire.

En résumé

La crainte de “corrompre” un logiciel de gestion en y branchant un outil de conformité est légitime. Elle perd son objet quand la lecture est strictement en lecture, quand une coupure réseau est absorbée sans ressaisie, quand l’éditeur d’origine n’a rien à fournir, et quand l’installation se compte en heures plutôt qu’en mois.

Reste une question que vous seul pouvez instruire avec votre conseil : l’état exact de vos données source et de votre mapping TVA. C’est là que la conversation devient intéressante, et c’est volontiers le point de départ d’un échange.