ED01 - Motivation : Pourquoi un entrepreneur tient son journal dans Git

Problème

Un entrepreneur fonde une organisation - et se trouve face à une image floue des risques futurs. Quelles obligations naissent quand ? Quels justificatifs doivent être conservés combien de temps ? Quels délais risquent d'être manqués ? Quelles administrations se manifestent quand pour quel contrôle ?

La pratique actuelle dans le secteur des PME est marquée par :

• paperasse dispersée et listes Excel locales - non traçables, non conformes à l'audit
• chaos de PDF et d'e-mails lors des contrôles - les documents sont rassemblés à la hâte
• solutions isolées (logiciel de paie ici, comptabilité là, archive de justificatifs ailleurs) - sans chaîne de preuve continue
• lacunes open source pour des obligations particulières (temps de travail, frais de déplacement, primes, BEM, FZul/BSFZ, utilité publique) - il n'existe pratiquement aucun support libre ici
• accumulation de risques - les obligations sont aujourd'hui ignorées à faible coût, jusqu'à ce qu'elles deviennent coûteuses demain sous forme d'amendes, de majorations de retard ou de retraits

Message clé

Non seulement les documents doivent être conformes à l'audit - mais aussi les décisions, délais et références de justificatifs doivent être traçables, reproductibles et auditables. Un journal natif Git fait exactement cela : il transforme des faits saisis aujourd'hui à faible coût (bon marché) (un enregistrement JSON avec V7GUID + référence de justificatif SHA-256) en futures preuves conformes à l'audit. La conformité devient un levier, non un frein.

Compliance by Design : L'« image floue » des risques futurs est réduite par les techniques GitCover (OSCAL, OPA, V7GUID, hooks Git) dès le départ, et non seulement lorsque le contrôleur sonne à la porte.

Le journal comme agenda de travail entrepreneurial

Le journal n'est pas un carnet privé et pas non plus un calendrier de temps de travail tenu après coup. Il est la SSoT temporelle du travail : l'agenda montre quelle prestation, décision ou clarification a vu le jour quand et à quel justificatif, contrat ou dossier elle renvoie. Ainsi, la même preuve de travail peut servir différents objectifs, sans construire une nouvelle histoire pour chaque contrôle :

• BSFZ/FZulG : les projets de R&D, le temps de prestation et la délimitation sont documentés sans délai.
• FA/EStG/EÜR : la motivation entrepreneuriale et les parts privées/professionnelles restent traçables.
• USt : la période de prestation, l'exécution du contrat et la référence à la facture deviennent liables.
• GoBD/AO : le justificatif, la décision, la validation et la modification forment une chaîne rétrograde/progressive.
• Risque et portabilité : l'exploitation ne dépend pas de la mémoire d'une seule personne ou d'un portail fournisseur ; les faits se trouvent dans des artefacts Git ouverts et versionnés.

La règle est simple : Le journal décrit l'agenda ; les dépôts conservent la preuve. Un agent ne peut déduire du journal que ce que portent les Ur-Docs liés et les sidecars. Ainsi, la conformité n'est pas gérée comme un travail supplémentaire ultérieur, mais comme un flux de travail normal.

Genèse : le contrôle SV comme déclencheur pratique

L'idée GitCover n'est pas née dans une tour d'ivoire, mais de expériences pratiques concrètes : plus récemment d'un contrôle d'entreprise SV auprès d'une micro-UG (ici anonymisée en ORG-V pour « organisation précurseur ») pour la période 2021–2023 ; réalisé sur la période 02/2024–03/2025. Le contrôle a révélé des points de douleur que les techniques GitCover adressent.

Chronologie du contrôle SV

Que s'est-il passé ?

Résultat financier (net)

Points de douleur - ce que le contrôle a révélé

1. Pas de bureau, pas de fax, pas de salarié - et devoir néanmoins traiter un contrôle d'entreprise uniquement par e-mail avec des fichiers PDF et ZIP. Les outils n'existaient pas pour ce cas minuscule.
2. Authenticité des justificatifs incertaine - les PDF envoyés par e-mail n'ont pas d'ancrage cryptographique. Qui a modifié quoi et quand ? La force probante n'était assurée que par une traçabilité manuelle.
3. Pas de chaîne de preuve continue - les comptes de paie, déclarations SV, attestations de cotisations et justificatifs de remboursement se trouvaient à différents endroits, sans renvois. Chaque question nécessitait une nouvelle recherche.
4. Gestion des délais ad hoc - les délais d'audition, de remboursement, d'opposition étaient gérés manuellement dans le calendrier. Aucune alerte en cas d'expiration imminente.
5. L'export d'audit manquait - la DRV demandait des données au format euBP (eXTra V3.4.0) ; le FA aurait exigé un support de données Z3. Les deux n'étaient possibles qu'avec un logiciel spécialisé ou une préparation manuelle.
6. Départ du salarié → compte de paie mis en pause - après le départ du salarié de l'époque, le compte de décompte de paie chez le prestataire a été mis en pause. Qui maintient inutilement un compte cloud générant des coûts lorsque la raison n'existe plus (salarié parti, plus de décomptes nécessaires) ? La compilation du dossier de documents pour le contrôle a alors exigé des coûts supplémentaires chez le prestataire, qui étaient finalement plus élevés que le petit « remboursement » à la fin du contrôle.
7. Réactivation d'anciennes sauvegardes avec une ancienne version logicielle - pour rendre à nouveau accessibles les comptes de paie 2021–2023, il fallait réactiver les anciennes sauvegardes avec l'ancienne version logicielle - un problème pratique considérable. C'est formellement une violation des règles de l'obligation GoBD que de ne pas veiller aussi techniquement à ce que, pendant la longue période de conservation (10 ans), l'accès soit toujours possible. En pratique, cette obligation entre en conflit avec la pression économique consistant à ne pas maintenir des comptes cloud inutilisés en générant des coûts. Précisément cette tension est un motif central de GitCover : les bundles Git sont autonomes - ils n'ont besoin ni de comptes cloud, ni de contrats avec des prestataires, ni de versions logicielles. Un git clone suffit, et le délai de conservation est techniquement respecté.

Bases juridiques : AO § 146, § 147 et GoBD

La « violation des règles de l'obligation GoBD » évoquée au point 7 a une base juridique claire - dans la loi fiscale (AO) et dans les GoBD (principes pour la tenue et la conservation régulières des livres, enregistrements et documents sous forme électronique ainsi que pour l'accès aux données, lettre du BMF).

AO § 146 Abs. 5 - Disponibilité pendant le délai de conservation

« Lors de la tenue des livres et des autres enregistrements nécessaires sur supports de données, il faut notamment garantir que pendant la durée du délai de conservation, les données soient disponibles à tout moment et puissent être rendues lisibles sans délai. »

C'est la disposition centrale : quiconque comptabilise électroniquement doit, pendant toute la période de conservation (10 ans pour les livres/enregistrements, 8 ans pour les justificatifs comptables, § 147 Abs. 3 AO), garantir que les données sont disponibles à tout moment et lisibles sans délai. Un compte cloud mis en pause, qui n'est réactivé que contre des coûts supplémentaires, viole cette obligation - les données ne sont pas « disponibles à tout moment », mais seulement contre paiement et avec retard.

AO § 147 Abs. 2 - Conservation sur supports de données

« À l'exception des bilans annuels [...] les documents énumérés à l'alinéa 1 peuvent aussi être conservés sous forme de reproduction sur un support d'image ou sur d'autres supports de données, si cela correspond aux principes d'une comptabilité régulière et s'il est garanti que la reproduction ou les données [...] sont, pendant toute la durée du délai de conservation, disponibles à tout moment, peuvent être rendues lisibles sans délai et exploitées par machine. »

Encore une fois : « disponibles à tout moment », « lisibles sans délai », « exploitables par machine ». Une ancienne version logicielle qui doit d'abord être réactivée ne satisfait pas à l'exigence « sans délai ».

AO § 147 Abs. 5 - Moyens aux frais du contribuable

« Quiconque présente des documents à conserver sous la forme d'une reproduction sur un support d'image ou sur d'autres supports de données est tenu de fournir à ses frais les moyens nécessaires pour rendre les documents lisibles. »

Cela signifie : si le prestataire ne tient plus à disposition l'ancien système, l'entrepreneur doit lui-même fournir les moyens (logiciel, licences, matériel) pour rendre les données lisibles. C'était précisément le problème pratique du cas de genèse : anciennes sauvegardes, ancienne version logicielle, plus aucun moyen disponible.

AO § 147 Abs. 6 - Accès aux données lors d'un contrôle externe

« Si les documents visés à l'alinéa 1 ont été établis à l'aide d'un système de traitement de données, l'administration fiscale peut, dans le cadre d'un contrôle externe [...] exiger que les données soient mises à disposition sous forme exploitée par machine selon ses prescriptions. »

Lors d'un contrôle externe, l'entrepreneur doit mettre les données à disposition sous forme exploitable par machine - pas sous forme d'impression PDF, mais sous forme de données structurées. Un compte cloud mis en pause, qui n'offre qu'un export PDF, ne suffit pas.

GoBD - Documentation des procédures et changement de système

Les GoBD concrétisent ces dispositions de l'AO pour les systèmes électroniques. Exigences centrales :

• Documentation des procédures (GoBD Rz. 64–91) : chaque système électronique de comptabilité doit disposer d'une documentation des procédures décrivant la procédure, l'environnement système, les mesures organisationnelles et les contrôles internes. En cas de changement de système, la documentation des procédures doit être mise à jour.
• Changement de système/migration (GoBD Rz. 146–150) : lors d'un changement de système, il faut garantir que les données de l'ancien système restent disponibles, lisibles et exploitables par machine. La documentation des procédures doit documenter le changement.
• Immutabilité (GoBD Rz. 146) : après l'écriture, les données ne doivent pas être modifiées. Les corrections doivent être effectuées sous forme de nouvelles écritures avec justification.

Conséquences théoriques en cas d'infraction

Mise en perspective pratique : dans le cas de genèse, le contrôle SV a été accepté sans objections

• il n'y a eu aucune conséquence. Mais c'était de la chance : si la DRV n'avait pas accepté les données sous forme de PDF, mais avait insisté sur une exploitation par machine (§ 147 Abs. 6 AO), l'entrepreneur se serait trouvé en difficulté pour s'expliquer. La conservation conforme aux GoBD n'est pas une obligation théorique - elle devient réelle à chaque contrôle externe.

Pourquoi Git résout le problème

Git satisfait aux exigences AO/GoBD by Design :

Facture électronique : les formats XML sont des documents originaux au sens de l'AO

Depuis le 1er janvier 2025, la facture électronique est obligatoire pour les opérations entre entreprises nationales (§ 14 UStG, Wachstumschancengesetz). Une facture électronique n'existe que si elle est émise, transmise et reçue dans un format électronique structuré et permet un traitement électronique (§ 14 Abs. 1 Satz 3 UStG). Un simple document PDF n'entre plus dans cette catégorie - il s'agit depuis 2025 d'une « autre facture ».

Le XML est le document original - pas le PDF

Le point décisif pour la conservation : dans une facture électronique, la partie structurée (XML) est le document original au sens de l'AO, et non un PDF éventuellement joint ou une image lisible par l'homme. Le BMF précise (FAQ sur la facture électronique, question 13) :

« Pour une facture électronique, au moins sa partie structurée doit être conservée de manière à ce qu'elle soit intacte dans sa forme d'origine. »

Cela signifie :

• XRechnung (basé sur XML, EN 16931) : le fichier XML est le document original. Il doit être conservé inchangé. Une visualisation PDF n'est qu' une aide à l'affichage - elle ne remplace pas le XML.
• ZUGFeRD (hybride : PDF + XML intégré) : en cas d'écarts entre la partie XML et la partie image, depuis 2025, c'est la partie structurée (XML) qui fait foi (FAQ BMF question 12a). L'image PDF n'est plus déterminante.

AO § 147 - La facture électronique comme justificatif comptable

Les factures électroniques sont des justificatifs comptables au sens du § 147 Abs. 1 Nr. 4 AO et doivent donc être conservées huit ans (§ 147 Abs. 3 AO). En tant que documents électroniques, les exigences AO/GoBD s'appliquent :

• Disponible à tout moment (§ 147 Abs. 2) : le fichier XML doit être accessible pendant toute la période de conservation.
• Lisible sans délai (§ 147 Abs. 2) : un visualiseur XML ou le visualiseur de factures électroniques ELSTER (www.e-rechnung.elster.de) rend le fichier lisible - mais le XML lui-même est en texte clair et donc aussi lisible sans logiciel spécialisé.
• Exploitable par machine (§ 147 Abs. 6) : le XML est par définition lisible par machine - idéal pour § 147 Abs. 6 (accès aux données lors d'un contrôle externe).
• Intact (§ 14b Abs. 1 UStG) : le fichier XML ne doit pas être modifié. Git y satisfait par l'immutabilité après commit (hash SHA-256).

Réglementations à l'échelle de l'UE : EN 16931 et directive 2014/55/UE

La facture électronique repose sur le droit de l'UE :

• Directive 2014/55/UE - oblige les acheteurs publics à recevoir et traiter les factures électroniques (B2G).
• EN 16931 (série de normes européennes) - définit le modèle de données sémantique pour les factures électroniques (CEN/TC 434). XRechnung et ZUGFeRD sont des mises en œuvre nationales de cette norme EN.
• ViDA (VAT in the Digital Age) - extension prévue à l'échelle de l'UE de l'obligation de facture électronique et introduction d'un système de déclaration pour les données de transaction. L'obligation allemande de facture électronique prépare ViDA.

Pourquoi Git est idéal pour les factures électroniques

Conseil pratique : un dépôt Git peut conserver en parallèle des factures électroniques (XML) et d'autres factures (PDF) - avec une séparation claire par type de justificatif dans le sidecar (v7g_taxonomy). Le hook pre-commit vérifie si les factures électroniques ont une structure XML valide (schéma XRechnung/ZUGFeRD). Ainsi, la période transitoire 2025–2027 est couverte sans rupture de média.

Déductions directes dans GitCover

Remarque - obligations des micro-entrepreneurs dès 1 salarié : souvent, même les micro-entrepreneurs sont soumis dès le 1er salarié à de telles obligations - enregistrement du temps de travail (ArbZG), documentation du salaire minimum (MiLoG), congés/maladie/BEM (BUrlG/EFZG/SGB IX), déclaration à la sécurité sociale (SGB IV). Les obligations traitées dans la partie IV dès 1 salarié ne sont donc pas des sujets spécifiques aux grandes entreprises, mais concernent précisément les micro- et petites entreprises qui embauchent pour la première fois du personnel. GitCover s'adresse délibérément à ce seuil - le passage de l'entrepreneur solo à employeur est le moment critique où les obligations de conformité augmentent brusquement. Les obligations dès l'enregistrement de l'activité (classement des sphères, exonération VBG, forfaits) sont déjà traitées dans la partie II - elles naissent sans salarié.

Pourquoi Git comme support de journal ?

Git est à l'origine un système de contrôle de version - mais il apporte trois propriétés qui le rendent by Design adapté à la conformité :

1. Immutabilité après validation - les tags et les branches protégées garantissent que les entrées de journal validées ne sont pas modifiées après coup (GoBD Rz. 146). Les corrections sont effectuées sous forme de nouveaux commits avec marquage d'obsolescence.
2. Traçabilité - chaque commit porte l'auteur, l'horodatage et l'intégrité cryptographique. Toute l'historique est reproductible.
3. Décentralité - les bundles Git et GCEP (Advisory Locks) permettent un stockage distribué (multi-site, sauvegarde hors site) sans point unique de défaillance central.

Compliance by Design - les techniques GitCover

La série montre comment les techniques suivantes réduisent dès le départ l'« image floue » des risques futurs :

• OSCAL - déclarations de conformité lisibles par machine (maturité de certification pour ISO 27001, AI Act, BSI GS++)
• OPA/Rego - Policy as Code, contrôle automatisé des règles (séparation des sphères, délais, plausibilité des groupes de cotisation)
• V7GUID Uniqueness - identifiants uniques et stables dans le temps au-delà des noms de fichiers (basés sur UUIDv7, triables, sans collision)
• Hooks Git (dédiés fonctionnellement/matériellement) - pre-commit vérifie la séparation des sphères, la conformité au schéma, le statut d'obsolescence ; post-commit génère des index et met à jour les délais
• Types d'artefacts de code et entrées - JSON-Schema-First, obligation de sidecar, signature temporelle {YYMMDD HHmm}, références de justificatifs SHA-256

Principe central de la traçabilité temporelle : le moment de saisie n'est pas un champ séparé, mais est ancré dans l'uuidV7 lui-même, comme horodatage de 48 bits selon RFC 9562 §5.7. L'uuidV7 est généré à partir d'une marque temporelle prédéfinie (pas now()) via le helper GitCover (gc-v7guid), le reste étant rempli aléatoirement. Ainsi, le moment de saisie est cryptographiquement lié à l'identité de l'artefact et ne peut pas être modifié après coup. Une représentation séparée datetime/date sous forme de chaîne est redondante et n'est pas tenue dans les faits - la représentation sous forme de chaîne pour DTO/HTMX est de la responsabilité du harness.

Référence RFC : la composante d'horodatage de 48 bits de l'uuidV7 correspond à RFC 9562 §5.7 (UUIDv7) - millisecondes Unix depuis l'époque (1970-01-01T00:00:00Z), 48 bits, plage de valeurs 0 … 2⁴⁸−1 (portée jusqu'à env. l'an 10889). La spécification V7GUID est déposée de manière normative dans work/OSS/TOP/.gitcover/specs/v7guid/ ; la demande de brevet associée est DPMA Az. 10 2025 003 091.6.

Routines helper (GitCover OSS Tools) : dans work/OSS/gc-v7guid se trouve un helper OSS qui fournit deux opérations centrales :

• gen - génère une uuidV7 via Guid.CreateVersion7() (.NET) (avec une marque temporelle prédéfinie si nécessaire, pas seulement now()) et renvoie le label, l'UUID et l'horodatage ISO décodé.
• decode - extrait la composante d'horodatage de 48 bits d'une uuidV7 donnée et la renvoie sous forme d'horodatage ISO 8601.

Ces helpers sont décisifs pour créer, à partir de clés étrangères (par ex. une marque temporelle dans les données ou dans le nom de fichier), une clé uuidV7 valide - et en même temps documenter les exigences temporelles des GoBD (saisie rapide, traçabilité). La valeur de 48 bits est le seul facteur de la dérivation de TenantId et peut, au lieu de l'heure système, être aussi un moment explicitement prédéfini (par ex. à partir d'une marque temporelle d'un certificat ELSTER, date d'un reçu avec TSE, etc.) - l' interprétation suit la documentation des procédures.

Principe du sidecar (.gc.md) : chaque sidecar porte une clé composite V7GUID:uuidV7 :

• V7GUID (Class Identifier) - classe le sidecar selon le registre .gitcover (quoi/quel type)
• uuidV7 (Object ID) - identité du sidecar lui-même, générée avec une marque temporelle prédéfinie/horodatage de 48 bits ancré dans le GUID
• v7g_taxonomy[].v7guid - Object ID du document classifié
• sha256 - identité du document original classifié — la preuve d'originalité, toujours et partout (même si le document migre : indépendant du chemin/du nom, calculé à partir du contenu)

Ainsi, non seulement le document est identifié de manière unique (par son SHA-256), mais aussi l'acte de classification lui-même - y compris le moment (dans uuidV7), qui a classifié et dans quel rôle. Pas de champ datetime séparé.

Levier de risque - ce qui est aujourd'hui bon marché (cheap) et devient demain conforme à l'audit

Levier de risque : des faits saisis aujourd'hui à coût minimal (minutes, voire des instants par des « agents ») deviennent de futures preuves conformes à l'audit (des heures de contrôle). L'entrepreneur « soulève » une position de charge de la preuve - la conformité comme levier.

Ce que montre cette série

La série suit un entrepreneur fictif (E1) qui dirige une organisation KMU (espace réservé, forme juridique ouverte) et tient son journal dans un dépôt Git. La structure s'inspire d'un concept SSoT réel, mais est entièrement anonymisée - toutes les données de personnes, d'entreprises, HRB, IBAN et de numéro fiscal sont remplacées par des espaces réservés.

Remarque RGPD : toutes les références aux personnes/entreprises de cette série sont fictives ou anonymisées. Toute ressemblance avec des organisations réelles est fortuite et non intentionnelle.

Aperçu de la série

Exigence du harness (aperçu)

Déductible de ED01 :

La liste complète des exigences se trouve dans Harness-Anforderungen.md.

Sources

• Justificatif de genèse du contrôle SV (anonymisé) : E1/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md section J
• GoBD (lettre du BMF du 28.11.2019, BStBl I p. 1269, dernière modification du 14.07.2025, BStBl I p. 1502)
• AO (§§ 146, 147, 152, 162, 370, 379)
• SGB IV (§ 28p - contrôle d'entreprise)
• UStG (§ 14 - facture électronique, § 14b - conservation)
• FAQ du BMF sur la facture électronique (état mars 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
• EN 16931 (série de normes européennes, CEN/TC 434)
• Directive 2014/55/UE (facture électronique B2G)
• RFC 9562 §5.7 (UUIDv7) - horodatage Unix en ms sur 48 bits
• Spécification V7GUID - work/OSS/TOP/.gitcover/specs/v7guid/ (normative)
• DPMA Az. 10 2025 003 091.6 - demande de brevet V7GUID (revendication principale 2, revendications 5–8)
• Outil OSS GitCover gc-v7guid - work/OSS/gc-v7guid (routines helper gen/decode)
• RGPD (obligation d'anonymisation lors de la publication)

Topologie des sources et liens de référence CDN

Remarque : cette attribution des sources, du miroir et du hub communautaire reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sous git.gitcover.org/GCC pour l'état actuel. source canonique sur gitcover.org pour l'état actuel.