Le ticket que l'on ne peut pas supprimer

La plupart du travail de conformité est de la paperasse posée à côté du logiciel. Le droit allemand des caisses n'est pas de cet ordre. Il entre dans le schéma et le réorganise.

La règle est courte. Chaque transaction à une caisse doit être signée par un dispositif de sécurité technique certifié — une TSE — et l'enregistrement signé doit survivre dix ans, à la disposition de l'administration fiscale dans un format d'export prescrit, dès qu'elle le demande.

Relisez-la avec un œil d'ingénieur. Il n'y a pas de suppression.

Ce que « pas de suppression » fait à une conception

Prenez quelque chose de banal : une transaction de test. Tout système a un mode de recette, et tout développeur a un jour passé une commande de test en production pour voir si cela marchait.

Faites-le ici et la commande de test est dans le registre fiscal pour une décennie. Pas gênante — définitive. Impossible à retirer, puisque tout l'objet du dispositif est que rien ne puisse être retiré.

Alors « le test et la production sont séparés » cesse d'être une convention et devient une structure. Dans ce système, un appareil de caisse déclare son environnement, test ou production, et une contrainte CHECK assortie d'un index unique partiel fait d'un seul appareil en production à la fois une garantie que la base impose. Pas une règle dans un manuel. Pas une habitude. Une chose que la base refusera de vous laisser faire.

C'est la différence que font les dix ans. D'ordinaire, on écrit la contrainte qui attrape le bogue. Ici, on écrit la contrainte qui attrape la décennie.

Composer à partir de la spécification, pas de la mémoire

Les données fiscales ont un schéma, et ce schéma est publié. Le client, ici, les compose à partir de la spécification que l'interface elle-même délivre, plutôt que du souvenir qu'a l'un ou l'autre du nom des champs.

Cela paraît tatillon jusqu'à ce qu'on regarde l'alternative : un développeur lit la spécification une fois, écrit ce dont il se souvient, et livre. Les tests passent, parce qu'ils ont été écrits depuis le même souvenir. Cela échoue au contrôle, des années plus tard, d'une manière que plus personne ne peut reconstituer.

Les détails que seule la production enseigne

En voici un qui vaut le déplacement.

L'horodatage de la signature revient de l'appareil dans le format que le module de sécurité déclare — et c'est une propriété du module, non une constante de la norme. Celui de ce système annonce unixTime : des secondes depuis l'époque, sous forme de nombre. Un module configuré autrement enverra très bien une chaîne ISO.

Le code accepte donc les deux. Personne ne conçoit cela à l'avance. On l'apprend au premier ticket daté de 1970, et l'on écrit alors pourquoi dans le fichier, pour que la personne suivante ne le resimplifie pas obligeamment.

Écrire pour le contrôleur, pas pour la suite de tests

L'export embarque le certificat et la clé publique du module de sécurité. Non parce que le format réclame qu'un champ soit rempli, mais pour qu'un contrôleur puisse vérifier les signatures hors ligne, contre des racines de confiance, sans demander au système contrôlé de se porter garant de lui-même.

Omettez-le et vérifier une signature revient à faire confiance à la chose même que l'on vérifie. Le format le permet. Le sens de l'exercice, non.

Ce principe façonne l'export dans son ensemble. C'est un ensemble de seize tables dans l'ordre où l'administration les énumère — données de référence, puis clôture journalière, puis enregistrements individuels — et quand il ne peut pas être assemblé, il dit pourquoi. Un taux de TVA non figé, un code fiscal non mappé, un numéro fiscal manquant : chacun devient un problème consigné dans le résultat plutôt qu'une exception quelque part plus haut. Le rôle de l'appelant est de journaliser la tentative échouée, pas de s'effondrer dessus. Un export qui échoue en silence est pire qu'un export qui échoue.

Pourquoi ce n'est pas seulement un problème allemand

Nous faisons le même travail pour la facturation électronique en Égypte et pour ZATCA en Arabie saoudite. Les formats diffèrent, les administrations diffèrent, les échéances diffèrent.

La discipline, non. Partout où l'enregistrement survit au logiciel qui l'a produit, l'enregistrement est le produit — et le code qui l'écrit devrait être lisible par quelqu'un qui le lira des années plus tard, dans une discussion contradictoire, sans vous dans la pièce pour l'expliquer.

Parlons d'un projet où la conformité est critique