Pourquoi votre ERP génère des factures, pas des preuves
Les logiciels ERP et comptables sont remarquablement bons dans la mission pour laquelle ils ont été conçus : traiter des transactions à grande échelle, appliquer des circuits d’approbation et produire une sortie structurée que d’autres systèmes peuvent exploiter. Des millions de factures sont générées ainsi chaque jour sans incident.
Mais il existe une autre mission, pour laquelle les logiciels ERP n’ont jamais été conçus, et cette distinction compte lorsqu’une administration fiscale, un tribunal ou un organisme de réglementation pose une question plus difficile que « montrez-moi la facture ».
La question à laquelle la plupart des logiciels ne savent pas répondre
Lorsqu’une facture ordinaire est contestée, produire le PDF suffit généralement. L’acheteur la reconnaît, le vendeur la confirme, et l’affaire est réglée. C’est ce flux de travail que les logiciels ERP optimisent.
Une question plus difficile ressemble à ceci : « Prouvez que cette facture existait exactement sous cette forme à cette date, qu’elle n’a pas été modifiée depuis, et que la personne qui affirme l’avoir envoyée l’a réellement envoyée via votre système. »
Ce n’est pas une question de document. C’est une question de preuve. Et la preuve obéit à d’autres exigences que le document.
Un document est l’enregistrement d’une transaction. Une preuve est un enregistrement vérifiable qui résiste à un examen indépendant, y compris à l’examen de quelqu’un qui cherche activement à la contester.
Ce que les logiciels ERP apportent
Pour être précis sur l’écart, il est utile d’être clair sur ce que les logiciels ERP font bien.
La plupart des systèmes ERP modernes offrent :
Des données de facture structurées. Les factures sont stockées dans une base de données avec des relations claires entre acheteurs, vendeurs, lignes, totaux et dates. Cela les rend interrogeables, auditables via l’interface de l’ERP lui-même, et exportables dans des formats normalisés comme le XML UBL ou CII.
Des journaux d’approbation et d’audit. La plupart des systèmes ERP enregistrent qui a approuvé quoi, et quand. Ces journaux sont utiles pour les revues de contrôle interne et peuvent démontrer que la procédure appropriée a été suivie.
La conformité de format. Pour les sorties Factur-X, ZUGFeRD, XRechnung et Peppol, les logiciels ERP modernes génèrent un XML conforme au schéma correspondant. Cela couvre l’exigence de format des obligations européennes de facturation électronique.
L’export et la portabilité. Les factures peuvent généralement être exportées en masse, en XML, en PDF, ou les deux. Cela couvre le cas d’usage de la portabilité des données.
Rien de tout cela n’est trivial. La conformité de format est un véritable problème d’ingénierie, dans la résolution duquel les éditeurs d’ERP ont investi des efforts considérables. Le propos n’est pas que les logiciels ERP sont déficients. Le propos est que la conformité de format est nécessaire, mais pas suffisante pour constituer une preuve juridique.
Ce que les logiciels ERP n’apportent pas
L’écart apparaît lorsque vous demandez une vérification indépendante de trois éléments que les procédures judiciaires exigent souvent.
La preuve d’existence à un moment précis. Un horodatage stocké dans votre propre système n’est fiable que dans la mesure où votre système l’est. Si vous contrôlez le système, une partie adverse peut soutenir que vous contrôliez aussi l’horodatage. Un horodatage RFC 3161 émis par une autorité d’horodatage indépendante est signé cryptographiquement par un tiers et ne peut pas être falsifié rétroactivement sans invalider la signature. La plupart des systèmes ERP n’émettent ni ne stockent d’horodatages RFC 3161.
La preuve d’intégrité depuis ce moment. Un fichier PDF ou XML stocké dans une base de données peut être modifié. Un enregistrement de base de données peut être mis à jour. Sans engagement de hachage indépendant (une empreinte cryptographique réalisée au moment de la création et stockée quelque part hors de votre contrôle), vous ne pouvez pas prouver que le document n’a pas été modifié depuis. La plupart des systèmes ERP ne produisent ni ne stockent d’engagements de hachage cryptographiques liés à leurs enregistrements.
Une chaîne de garde indépendante. Savoir qu’un document existe aujourd’hui dans un état donné est différent de savoir comment il est arrivé dans cet état. Une chaîne de garde enregistre chaque action effectuée sur un document (qui y a accédé, ce qui a été fait, et dans quel ordre) dans un journal résistant à la falsification. C’est la norme dans les procédures judiciaires et réglementaires, mais ce n’est généralement pas ainsi que les journaux d’audit des ERP sont mis en œuvre.
Quand cela compte en pratique
L’écart entre document et preuve n’a rien de théorique. Voici les contextes dans lesquels il apparaît.
Les enquêtes des administrations fiscales. Dans plusieurs juridictions de l’UE, les administrations fiscales ont le pouvoir d’exiger des entreprises qu’elles démontrent l’intégrité de leurs registres de factures électroniques. Une entreprise qui peut produire des factures mais ne peut pas démontrer qu’elles n’ont pas été modifiées depuis leur émission est en position plus faible qu’une entreprise capable de produire, avec la facture, une preuve cryptographique de son intégrité.
Les litiges commerciaux. Lorsqu’un acheteur conteste une facture, en affirmant qu’elle a été modifiée après coup ou que les montants ne correspondent pas à ce qui avait été convenu, le vendeur doit démontrer que le document est authentique et inchangé. Un horodatage RFC 3161 et une chaîne de hachage apportent cette démonstration. Un PDF issu d’un système ERP sans vérification indépendante ne l’apporte pas.
Les audits réglementaires dans les services financiers. Les entreprises soumises à MiFID II, à Solvabilité II ou à des cadres équivalents sont tenues de conserver leurs enregistrements d’une manière qui en démontre l’intégrité et l’authenticité. Les exigences précises varient, mais l’attente générale est que les enregistrements ne puissent pas être modifiés sans que cela soit détecté. C’est un niveau d’exigence plus élevé que le stockage ERP habituel.
Les litiges contractuels impliquant de longues durées de conservation. Les exigences de conservation des factures dans l’UE vont de 7 ans (la norme courante pour les factures de TVA) à 20 ans pour certains documents du secteur public en droit néerlandais. Sur une fenêtre de 7 ans, beaucoup de choses peuvent changer : le système ERP peut être remplacé, la base de données migrée, les fichiers PDF réexportés. Sans horodatage ni chaîne de hachage ancrés au moment de la création, prouver qu’une facture vieille de 7 ans n’a pas été modifiée devient difficile.
L’idée reçue sur la conformité de format
Une hypothèse courante veut qu’une facture conforme à Factur-X ou à Peppol soit juridiquement recevable. La conformité de format signifie que la facture est valide au regard du schéma et contient les champs requis. Elle ne dit rien du moment où le document a été créé, de son éventuelle modification, ni de la possibilité de vérifier l’enregistrement de manière indépendante.
Factur-X est un format de fichier. RFC 3161 est un protocole de preuve. Ils opèrent à des couches différentes de la pile de conformité, et l’un ne remplace pas l’autre.
Pour prendre une analogie physique : un document notarié et un document imprimé sont tous deux des documents. La certification notariale ajoute une couche de vérification indépendante, celle d’un tiers de confiance qui atteste quand et par qui le document a été signé. La conformité de format est plus proche de l’impression que de la certification notariale.
Ce qu’exige réellement la couche de preuve
Produire une preuve vérifiable pour un document numérique exige au minimum trois éléments.
Un horodatage de confiance. Un horodatage RFC 3161 émis par une autorité d’horodatage (TSA) fournit une preuve cryptographique d’existence à un instant précis. La TSA est une partie indépendante dont la signature peut être vérifiée par n’importe qui à l’aide d’outils standard. L’horodatage ne peut pas être falsifié après coup sans invalider la chaîne de signature.
Un engagement de hachage. Avant que le document soit horodaté, son contenu est haché. SealDoc calcule à la fois une empreinte SHA-256, sur laquelle la requête RFC 3161 engage l’autorité d’horodatage, et une empreinte SHA-384, qui identifie l’enregistrement dans le registre de preuves. Le hash est une empreinte du contenu. Si un seul octet du document change après le calcul du hash, l’empreinte ne correspond plus. Le hash est stocké indépendamment du document, de sorte que le document et l’empreinte peuvent être confrontés l’un à l’autre à tout moment dans le futur.
Un enregistrement de la chaîne de garde. Chaque action effectuée sur le document après sa création est journalisée (accès, conversion, archivage, récupération) avec l’identité de l’acteur, l’horodatage et l’adresse IP, et consignée dans un journal d’audit résistant à la falsification.
Ensemble, ces trois éléments répondent aux questions que posent les procédures judiciaires : si ce document existait sous cette forme à ce moment-là, s’il a été modifié depuis, et qui l’a manipulé.
La question pratique
La question compte surtout dans les circonstances suivantes : secteurs réglementés, transactions de montant élevé, longues durées de conservation, factures contestées, ou tout contexte dans lequel une partie adverse pourrait avoir intérêt à contester l’intégrité de vos enregistrements.
Pour ces cas d’usage, l’écart entre « nous avons la facture » et « nous pouvons prouver que la facture est authentique » est réel, et la conformité de format ne suffit pas à le combler.
L’approche la plus pratique consiste à intégrer la couche de preuve au moment de la création du document plutôt qu’a posteriori. Un horodatage RFC 3161 et une chaîne de hachage ajoutés au moment de la génération ne coûtent rien au moment de l’audit. Les ajouter a posteriori, ou tenter de soutenir que les enregistrements existants suffisent sans eux, est plus difficile.
SealDoc ajoute la couche de preuve à chaque document traité par le pipeline : un horodatage RFC 3161 demandé par défaut à une autorité d’horodatage européenne indépendante, une chaîne de garde SHA-256 sur les étapes de traitement, un registre de preuves SHA-384 sur l’enregistrement, et un Legal Evidence Pack, sur demande, qui réunit les deux en une seule archive auditable.