Draft:Questions certification LNE pour le certificateur (Loi Finance)

Cette page a pour objet de centraliser les questions à poser au certificateur durant les premières réunions d'information sur la certification (avant le 10 octobre 2025).

Introduction: En introduction nous présenterons les spécificités du logiciel Dolibarr (développement multi-entreprise, multi-pays, logiciel de facturation plutôt que de caisse mais avec écran de point de vente ...).

Périmètre: Nous avons défini le périmètre sur la base d'une liste de fichiers qui ne devront pas être modifié pour rester dans le périmètre de la même version majeure. Notre architecture qui permet d'isoler les fichiers concernés par l'encaissement et le traçage en log inaltérable sera présenté en séance visio. Pour simplifier nous avons décider de nommer ce périmètre (modules, fichiers concernés) par le terme "Périmètre de certification Loi Finance France". Y a-t-il un terme plus adapté ? Les questions sur ce périmètre viendront peut-être lors de la séance en parcourant les autres points...

=> Actuellement on a définit tout ce qui enregistre la log inaltérable donc les fichiers du module Log Inaltérable => Pour la fonction POS, vu que tout passe par le module Log Inaltérable, faut-il inclure les fichiers pour l'écran de POS (toute modif ne pouvant avoir d'impact sur le contenu de la log inaltérable) ? Par contre, il y a la page de configuration du modèle de ticket qui serait nécessaire si on veut garantir les fonctions de champs affichés sur les tickets + page qui génère le ticket takepos/receipt.php ?

=> On utilisera le terme "Périmètre Loi Finance" ou "PLF". => Oubli d'évoquer la 2eme question.

Nos documents (utilisateurs, développeur, etc) sont déjà publiques et partagés par l'écosystème (principe de "coopétition"), mais quid des nouveaux document propres à la certification, peut on les rendre disponibles pour notre communauté, ce qui signifier qu'ils seraient "publiques" aussi, sous quelles conditions ?

Puisque tout le monde n'a pas besoin de l'inaltérabilité (seul 5 à 20% de nos utilisateurs sont concernés), on envisage de rendre le module de conformité "non" actif par défaut, mais activable par l'intégrateur ou l'utilisateur lui même. La certification ne serait donc valide que "sous réserve du paramétrage Pays = France et Module de Log Inaltérable activé". Dès lors que ce critère de paramétrage est bien mentionné dans le périmètre, est-ce envisageable de fonctionner ainsi ou faut-il faire une version spéciale "France" dans laquelle le module de conformité serait actif quoi qu'il arrive, sans nécessiter de paramétrage initial de l'application ?

=> Pas d'objection pour diffusion à la communauté Dolibarr. => Oubli d'évoquer la question sur paramétrage.

Quel est le planning possible du déroulement de certification (date communication des docs finalisés, date évaluation, ...) sachant que de notre côté on espère le code prêt pour fin février 2026 ? Y a-t-il un Audit à blanc (Audit suivi d'un délai avant le vrai Audit pour permettre les actions correctives) ?

=> Audit light à blanc en février - 2eme presta => Audit initial à planifier après recevabilité (souhait pour Avril-Mai).

Comment se déroule la certification (lieu ? visio ? étapes ? avec qui ?). Comment sont gérer les retours car j'imagine qu'il y a toujours des points identifiés ou réserves à lever ?

=> A faire en présentiel => Pas de plus value a le faire dans nos locaux => 1 seule personne peut suffire. A déterminer ultérieurement en même temps que la planification des dates d'audit initial si dans les locaux de LNE ou autres.

Notre système de log inaltérable couvre d'autres événements en plus de l'enregistrement des paiements, comme par exemple l'enregistrement de factures, même si aucune paiement n'a encore été reçu, car d'autre pays ont ce besoin. Dans la mesure où l'outil de consultation permet de filtrer par type d’événement pour ne voir que les événements soumis à besoin d'inaltérabilité de la France, pouvez vous confirmer que l'on peut rester ainsi (Sinon, parcourir ensemble la liste des types d’événements qu'il faudrait garder juste pour la France).

=> Pas d'objection à faire plus si on a bien les outils pour ne pas être surchargé du non réglementaire français.

Sur Dolibarr toute saisie de paiement est concomitant à l'émission de facture PDF qui fait office de ticket, dans le cas de l'envoi par email ou de l'impression de cette facture (qui mentionne les paiement reçus), on stock dans la log inaltérable les donnée qui composent ce PDF mais pas le fichier PDF même. Est-ce ok ?

Dolibarr est donc un logiciel de facturation, mais possède un écran Point de Vente pour des raisons de faciliter de saisie. Toutefois, chaque encaissement reste concomitant à l'enregistrement d'une facture. De même les fonctions de clôture journalière et mensuelle de ce point de vente se base sur ces factures. Le document de recevabilité réglementaire indique "Exigence n°6 : ...Les logiciels de facturation n’ont pas l’obligation de réaliser les clôtures journalière, mensuelle et annuelle sous réserve de pouvoir fournir via une fonctionnalité, à la demande de l’administration, le total du chiffre d'affaires enregistré pour une période déterminée". Comme c'est bien une facturation systématique qui est réalisé (logiciel de facturation, seul l'écran de saisie change), cela veut-il dire que l'on peut sortir écarter les exigences sur les clôtures de caisse, même si on offre quand même cette fonction de clôture, en double des notions de consultation et export du CA pour une période donnée basé sur les facture depuis l'écran d'analyse des logs inaltérables (possible vu que l'on stock aussi les événements "Facture enregistré" dans ces logs inaltérables) ? Et si oui, cette fonction de consultation du CA peut elle être en dehors du périmètre Certif logiciel de caisse?

Questions sur la purge. Les points réglementaires sur la purge sont flous car mélangent archivages et purge et ne semblent pas adaptés au cas où on ne purge jamais les logs inaltérables. Cela veut il dire qu'il faut obligatoirement avoir une fonction de purge ou peut on les considérer comme non applicable ?

=> Purge non applicable (pas de purge, même partielle), prouver et documenter que ceci est non applicable. => Ajouter dans la documentation notre périmètre cible d'utilisateur pour décrire notre faible volume pour l'aspect point de vente.

Questions sur l'impression/réimpression. Dolibarr ne permet pas l'impression de duplicata car fonctionne par Génération et impression de factures en temps réél et obligatoirement. Hors au sens de la loi, il ne peut exister qu'un seul exemplaire de facture. C'est toujours une facture entière ou un ticket facture simplifiée (avec les mentions légales d'une facture) qu'on imprime. C'est un PDF qui peut être imprimé n fois (pour la compta, pour le juriste, pour les impôts, ...). Comment concilier les exigences sur les points "duplicata" de ticket de caisse. Cette notion a-t-elle un sens pour un logiciel qui enregistre une facture systématiquement de manière concomitante avec le paiement ?

=> Si le certificateur peut avoir les totaux, on peut imaginer se concentrer sur la partie facturation. Toutefois, si les fonctions existent, l'auditeur pourrait être amené à challenger aussi sur la partie fonctions de caisse. => TODO Ajouter une traçabilité duplicata numéro X+1 à chaque impression.

Un utilisateur enregistre un paiement de 11 euros en début de mois. A la fin du mois, en faisant son rapprochement bancaire, il se rend compte qu'il a fait une erreur de saisie et qu'il y a 10 euros sur le compte. Le logiciel Dolibarr procède ainsi: Suppression logique (donc hors log inaltérable qui reste tjs non supprimable) des 11 euros puis saisi des 10 euros. Ce qui nous donne dans la Log inaltérable 3 entrées: La saisie initiale de +11 euros à la date de début de mois, puis une ligne en fin de mois pour la saisie de -11 euros qui annule l'erreur de début de mois, suivi d'une autre de +10 euros pour enregistrer la bonne valeur (ces 3 lignes se retrouvant donc en log inaltérable). Notre lecture des exigences nous laissent penser que ce fonctionnement et celui attendue, merci de confirmer.

=> Recevable de faire en 3 étapes => TODO Vérifier que ceci est bien décrit dans doc.

L'exigence 16 demande de conserver les données pour 6 ans. Hors notre solution les conservent sans limite de temps. Peut-on donc considérer que cette exigence ne sera pas un point "Non satisfaisant" car Non applicable ?

=> L'exigence EST applicable, mais serait conforme car on conserve plus longtemps.

Certains points concerne les systèmes centralisateurs. Hors notre solution est une application web, basée sur un seul système sans aucune donnée même temporaire en dehors, donc un système "centralisé" mais pas "centralisateur". Peut-on donc considérer que cette exigence ne sera pas un point "Non satisfaisant" car Non applicable ?

=> La doc donne la définition de système centralisateur. On peut s'appuyer dessus pour dire que notre appli n'est pas centralisateur donc non applicable.

Une doc parle de QU2507-0027 - Vérification fonctionnelle - Tester le fonctionnement du système pour vérifier que les "corrections" s'effectuent par des opérations de "plus" et de "moins" et non par des modifications directes des données d'origines enregistrées. Vérifier par examen de la base de données ou du fichier que les données sont effectivement enregistrées, en cas de correction. ... Cela veut-il dire qu'il faut aussi tracer de manière inaltérable chaque étape intermédiaire de saisie/remplissage du panier et ce alors même qu'il n'y a pas encore de paiement ? Et si oui faut-il aussi le faire pour les factures en backoffice ?

=> oui dans le contexte d'usage de ticket (donc si un ticket a déjà été émis, pas avant TODO), non dans le contexte de logiciel de facturation.

Compléter la doc pour indiquer que le serveur peut être local ou externe => Indiquer que c'est du SSL si local. Indiquer qu'on est en dehors du système centralisateur car on ne stock pas de données sur le client local. Le client ne peut fonctionner sans serveur actif. Les données saisi au clavier transite de manière cryptée vers le serveur en HTTPS.

Une exigence indique "...Vérifier que la restauration d’une base ou d’un dossier contenant les données protégées est empêchée ou détectée.". Pour répondre à un sinistre on doit toujours pour restaurer un système dans un état x à une date dans son intégralité. Est-ce ok si on ne propose aucune fonction de restauration partielle,uniquement de resto total en cas de sinistre majeur. Et dans ce cas, par définition, il n'est pas possible de détecter car le principe d'une resto total est d'avoir tout dans exactement le même état.

=> D'après la doc, dans exigence 15, il est indiqué "Les restaurations « système » ne pouvant être tracées par la couche applicative, les restaurations de données concernées sont les restaurations effectuées depuis l’application/le logiciel d’encaissement.". Les restaurations des données protégées (la table log inaltérable) est bien empêchée.

=> TODO Mettre dans doc organisationnel un risque sur le risque de fournir des infos sur le fonctionnement du logiciel, sa production et son architecture. -> Mettre réponse détaillé sur le fait que cela ne représente pas de risque car la totalité du processus de fabrication est déjà déterminée. => Objectif de l'association sur la production, test, veille juridique. => Comment est informée le référent qualité -> Etre abonné à bercy, Suivre la liste de veille April. Voir role du référent déjà décrit sur page wiki de l'asso. => Ajouter les activités de l'asso dans l'outil de contrôle de conformité, avec plan de test => Donc les activités annuelles du Référrent Qualité/Conformité doivent être ajouté.

Que signifie "Vérifier la présence de la mention « Système d’encaissement certifié LNE » ?

=> TODO Ajouter la mention sur les factures si flag define CERTIFLNE = 1.

Que signifie "Vérifier la traçabilité des justificatifs physiques et dématérialisé"

=> Ajouter la mention sur les justificatif PDF et tickets

Que signifie "Inclure les totaux cumulatifs de période et totaux perpétuels figés à chaque période (dev à faire LNE7) dans les logs inaltérables" ? Qu'est ce que les "données cumulatives, récapitulatives", les infos de clôture de caisse ?

=> Ajouter dans doc Orga que Les utilisateurs sont notifiée en cas de mise à jour de version majeure. Ajouter cette tache dans notre DigiQuali.

=> Ajouter d'un système pour être informé d'évolution.

Conclusion structurante:

L'usage anonyme d'une appli open source n'est plus possible. Il faut obligatoirement demander les infos de l'utilisateurs et les centraliser => Page de demande d'email au moment d'activer le module Log inaltérable si pays = FR à remonter à l'asso comme on le fait pour le ping qui remonte les versions. TODO
Le versionnement X.Y.Z avec X+1 tous les 6 mois n'est plus possible (disons "risqué" en terme de compréhension), sauf à faire l'évaluation tous les 6 mois => Solution: faire une X.0.0 puis une X.5.0 après 6 mois pour faire X+1.0.0 après 1 an (et ne modifier les fichiers du périmètre loi inaltérable que dans ces version la).
Obligation (non expressement cité mais "de fait" pour valider le SMC) d'utiliser un outil (actuellement https://digiquali.dolibarr.org) avec notre plan de contrôle et le faire réaliser tous les ans à chaque revue de certification. TODO Mettre aussi les actions annuelles du référent qualité dans la liste des checks points en plus des controles techniques.
On peut éviter les fonctions du référentiel en rapport avec la clôture si on peut avoir l'info du CA sur une plage donnée depuis la facture, ce qui implique de stocker les factures aussi dans la log inaltérable (ce qu'on fait déjà) et TODO ajouter total sur le listing Log Inaltérable.
Besoin d'ajouter une fonction de lien entre élements (log facture - log paiement) de la log inaltérable. TODO
Planning espéré: Test à blanc février, Test final Avril/Mai.
Ajouter info "Système conforme LNE" sur ticket et PDF. A faire par hook du module Log inaltérable. Ajouter aussi un compteur +1 à chaque impression de ticket.
TODO Dev d'un outil en ligne à https://www.dolibarr.org/onlinecheckarchive.php pour le contrôle des archives exportés en CSV de la log inaltérable.

A compléter...