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 à venir. Quelles obligations naissent, et quand ? Quels justificatifs faut-il conserver, et combien de temps ? Quels délais risque-t-on de manquer ? Quelles autorités se manifestent, quand, pour quel contrôle ?

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

• Papierasserie et listes Excel locales - impossible à retracer, non sécurisé pour les audits
• Chaos de PDF et d'e-mails lors des contrôles - les documents sont assemblés ad hoc
• Solutions en silos (logiciel de paie ici, comptabilité là, archive des justificatifs ailleurs) - sans chaîne de preuves continue
• Lacunes open source pour les obligations particulières (temps de travail, frais de déplacement, primes, BEM, FZul/BSFZ, utilité publique) - il n'existe ici quasiment aucun soutien libre
• Accumulation de risques - les obligations sont ignorées aujourd'hui cheap, pour devenir demain coûteuses sous forme d'amendes, de majorations pour retard ou de retraits

Message clé

Non seulement les documents doivent être sécurisés pour les audits - les décisions, délais et références de justificatifs doivent aussi être traçables, reproductibles et auditables. Un journal natif Git fait exactement cela : il transforme des faits saisis aujourd'hui cheap (à bon marché) (une entrée JSON avec V7GUID + référence de justificatif SHA-256) en futurs justificatifs sécurisés pour les audits. La compliance devient un levier, pas un frein.

Compliance by Design : l'« image floue » des risques futurs est atténuée dès le départ par les techniques GitCover (OSCAL, OPA, V7GUID, Git-Hooks), et non seulement lorsque le contrôleur sonnera.

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 d' expériences pratiques concrètes : dernièrement d'un contrôle d'entreprise SV auprès d'une très petite UG (anonymisée ici sous ORG-V pour « organisation précurseur ») portant sur la période 2021–2023 ; réalisé durant 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 d'employé - et pourtant il a fallu mener un contrôle d'entreprise uniquement par e-mail avec des fichiers PDF et ZIP. Les outils n'existaient pas pour ce cas minimal.
2. Authenticité des justificatifs incertaine - les PDF par e-mail n'ont aucun ancrage cryptographique. Qui a modifié quoi, quand ? La force probante n'était assurée que par une traçabilité manuelle.
3. Pas de chaîne de preuves continue - comptes de salaires, déclarations SV, justificatifs de cotisations et justificatifs de remboursement se trouvaient à des endroits différents, sans renvois croisés. Chaque demande complémentaire exigeait de nouvelles recherches.
4. Gestion des délais ad hoc - délais d'audition, délais de remboursement, délais d'opposition étaient gérés manuellement dans le calendrier. Aucune alerte en cas d'échéance imminente.
5. Export d'audit manquant - la DRV exigeait les données au format euBP (eXTra V3.4.0) ; l'administration fiscale 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 de l'employé → compte de paie suspendu - après le départ de l'employé d'alors, le compte de décompte de paie auprès du prestataire a été suspendu. Qui maintient inutilement, en générant des coûts, un compte cloud alors que la raison n'existe plus (employé parti, plus aucun décompte nécessaire) ? Mais l'assemblage du paquet de documents pour le contrôle a alors entraîné des coûts supplémentaires auprès du prestataire, qui se sont avérés à la fin plus élevés que le petit « remboursement » à la fin du contrôle.
7. Réactivation d'anciennes sauvegardes avec un ancien état du logiciel - pour rendre à nouveau accessibles les comptes de salaires 2021–2023, il a fallu réactiver les anciennes sauvegardes avec l'ancien état du logiciel - un problème pratique considérable. C'est formellement une violation de l'exigence GoBD, qui exige aussi de garantir techniquement que l'accès reste possible pendant toute la longue durée de conservation (10 ans). En pratique, cette obligation entre en conflit avec la pression économique de ne pas maintenir, en générant des coûts, des comptes cloud inutilisés. C'est précisément cette tension qui constitue une motivation centrale de GitCover : les Git-Bundles sont self-contained - ils n'exigent ni comptes cloud, ni contrats de prestataires, ni versions de logiciels. Un git clone suffit, et le délai de conservation est techniquement rempli.

Bases juridiques : AO § 146, § 147 et GoBD

La « violation de l'exigence GoBD » évoquée au point 7 a une base juridique claire - dans la Abgabenordnung (AO) et dans les GoBD (principes régissant la tenue et la conservation réglementaires des livres, enregistrements et documents sous forme électronique ainsi que l'accès aux données, courrier BMF).

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

« Lors de la tenue des livres et des autres enregistrements requis sur des supports de données, il doit notamment être garanti que pendant toute la durée du délai de conservation, les données sont disponibles à tout moment et peuvent être rendues lisibles sans délai. »

C'est la disposition centrale : quiconque comptabilise électroniquement doit garantir, pendant toute la durée du délai de conservation (10 ans pour les livres/enregistrements, 8 ans pour les justificatifs comptables, § 147 Abs. 3 AO), que les données sont disponibles à tout moment et lisibles sans délai. Un compte cloud suspendu, 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 comptes annuels [...] les documents énumérés au paragraphe 1 peuvent également être conservés sous forme de reproduction sur un support d'image ou sur d'autres supports de données, à condition que cela soit conforme aux principes d'une comptabilité régulière et qu'il soit garanti que la reproduction ou les données [...] soient, pendant toute la durée du délai de conservation, disponibles à tout moment, rendues lisibles sans délai et exploitables automatiquement. »

Encore : « disponible à tout moment », « lisible sans délai », « exploitable automatiquement ». Une ancienne version de logiciel, qui doit d'abord être réactivée, ne satisfait pas « sans délai ».

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

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

Cela signifie : si le prestataire ne maintient plus l'ancien système, l'entrepreneur doit fournir lui-même les moyens auxiliaires (logiciel, licences, matériel) pour rendre les données lisibles. C'est exactement le problème pratique du cas de genèse : anciennes sauvegardes, ancien état du logiciel, plus aucun moyen auxiliaire disponible.

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

« Si les documents visés au paragraphe 1 ont été établis à l'aide d'un système de traitement de données, l'administration financière peut, dans le cadre d'un contrôle externe [...], exiger que les données soient mises à disposition sous une forme exploitable automatiquement, selon ses spécifications. »

Lors d'un contrôle externe, l'entrepreneur doit mettre les données à disposition sous forme exploitable automatiquement - non pas comme impression PDF, mais comme données structurées. Un compte cloud suspendu 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 de comptabilité électronique doit disposer d'une documentation des procédures qui décrit 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 automatiquement. La documentation des procédures doit documenter le changement.
• Immuabilité (GoBD Rz. 146) : après la comptabilisation, les données ne doivent pas être modifiées. Les corrections doivent se faire sous forme de nouvelles entrées avec justification.

Conséquences théoriques en cas de violation

Mise en perspective pratique : dans le cas de genèse, le contrôle SV a été accepté sans réserves - aucune conséquence n'en a résulté. Mais c'était une chance : si la DRV n'avait pas accepté les données en PDF mais avait insisté sur une exploitation automatique (§ 147 Abs. 6 AO), l'entrepreneur se serait retrouvé en difficulté d'explication. 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 les 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 transactions 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 si elle permet un traitement électronique (§ 14 Abs. 1 Satz 3 UStG). Un simple document PDF n'y entre plus - depuis 2025, il s'agit d'une « autre facture ».

Le XML est le document original - pas le PDF

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

« Pour une facture électronique, il faut conserver au minimum sa partie structurée de manière à ce qu'elle demeure intacte dans sa forme originale. »

Cela signifie :

• XRechnung (basée sur XML, EN 16931) : le fichier XML est le document original. Il doit être conservé sans modification. Une visualisation PDF n'est qu'un affichage auxiliaire - elle ne remplace pas le XML.
• ZUGFeRD (hybride : PDF + XML intégré) : en cas de divergence entre la partie XML et la partie image, c'est depuis 2025 la partie structurée (XML) qui fait foi (BMF FAQ 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 à ce titre ê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 rester accessible pendant toute la durée du délai de conservation.
• Lisible sans délai (§ 147 Abs. 2) : un visualiseur XML ou le visualiseur ELSTER de factures électroniques (www.e-rechnung.elster.de) rend le fichier lisible - mais le XML lui-même est en texte clair et donc lisible même sans logiciel spécialisé.
• Exploitable automatiquement (§ 147 Abs. 6) : le XML est par définition lisible par machine - idéal pour le § 147 Abs. 6 (accès aux données lors du contrôle externe).
• Intact (§ 14b Abs. 1 UStG) : le fichier XML ne doit pas être modifié. Git le garantit par l'immuabilité après commit (hachage SHA-256).

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

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

• Directive 2014/55/EU - oblige les pouvoirs adjudicateurs à recevoir et à traiter des factures électroniques (B2G).
• EN 16931 (série de normes européennes) - définit le modèle de données sémantique des 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 des 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 repo Git peut conserver en parallèle des factures électroniques (XML) et des autres factures (PDF) - avec une séparation claire par type de justificatif dans le sidecar (v7g_taxonomy). Le Pre-Commit-Hook vérifie si les factures électroniques ont une structure XML valide (schéma XRechnung/ZUGFeRD). Ainsi, la période transitoire 2025–2027 est franchie sans rupture de support.

Déductions directes dans GitCover

Remarque - obligations des micro-entrepreneurs dès le 1er employé : souvent micro-entrepreneurs eux-mêmes, ils sont soumis à de telles obligations dès le 1er employé - 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 à partir du 1er employé ne sont donc pas des thèmes spécifiques aux grandes entreprises, mais touchent précisément les micro- et petites entreprises qui embauchent du personnel pour la première fois. GitCover vise délibérément ce seuil - le passage d'entrepreneur solo à employeur est le moment critique où les obligations de compliance augmentent de manière brutale. Les obligations dès la déclaration d'activité (classement par sphères, dispense VBG, forfaits) sont déjà traitées dans la partie II - elles naissent sans employé.

Pourquoi Git comme support de journal ?

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

1. Immuabilité après validation - les Tags et Protected Branches garantissent que les entrées de journal validées ne sont pas modifiées a posteriori (GoBD Rz. 146). Les corrections se font sous forme de nouveaux commits avec marquage d'obsolescence.
2. Traçabilité - chaque commit porte l'auteur, l'horodatage et l'intégrité cryptographique. Tout l'historique est reproductible.
3. Décentralisation - les Git-Bundles et GCEP (Advisory Locks) permettent un stockage distribué (Multi-Site, sauvegarde Off-Site) sans Single-Point-of-Failure central.

Compliance by Design - les techniques GitCover

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

• OSCAL - déclarations de compliance lisibles par machine (maturité de certification pour ISO 27001, AI Act, BSI GS++)
• OPA/Rego - Policy as Code, vérification automatisée des politiques (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)
• Git-Hooks (dédiés fonctionnellement/thématiquement) - le Pre-Commit vérifie la séparation des sphères, la conformité au schéma, le statut d'obsolescence ; le Post-Commit génère les indices 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 : l'heure de saisie n'est pas un champ séparé, mais est ancrée dans la uuidV7 elle-même, comme horodatage 48 bits selon RFC 9562 §5.7. La uuidV7 est générée à partir d'une marque temporelle prédéfinie (pas now()) via le Helper GitCover (UuidV7Gen), le reste étant complété de manière aléatoire. Ainsi, l'heure de saisie est liée cryptographiquement à l'identité de l'artefact et ne peut être modifiée a posteriori. Une représentation en chaîne datetime/date séparée est redondante et n'est pas maintenue dans les faits - la représentation en chaîne pour DTO/HTMX relève de la responsabilité du Harness.

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

Routines Helper (outils OSS GitCover) : dans work/OSS/TOP/tools/UuidV7Gen/ se trouve un Helper OSS qui fournit deux opérations centrales :

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

Ces Helper sont décisifs pour créer, à partir de clés externes (p. ex. une marque temporelle dans les données ou dans le nom de fichier), une clé uuidV7 valide - tout en documentant les exigences temporelles de la GoBD (saisie en temps utile, traçabilité). La valeur 48 bits est l'unique facteur de la dérivation de la TenantId et peut être, au lieu de l'heure système, un moment explicitement prédéfini (p. ex. issu 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 (.v7g.md) : chaque sidecar porte une Composite Key V7GUID:uuidV7 :

• V7GUID (Class Identifier) - classe le sidecar selon la Registry .gitcover (quoi/quel type)
• uuidV7 (Object ID) - identité du sidecar lui-même, générée avec marque temporelle prédéfinie/horodatage 48 bits ancré dans la GUID
• v7g_taxonomy[].v7guid - Object ID du document classé

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

Risiko-Leverage - ce qui est aujourd'hui à bon marché (cheap) et devient demain sécurisé pour les audits

Risiko-Leverage : les faits saisis aujourd'hui à coût minimal (minutes, voire de simples instants par des « agents ») deviennent de futurs justificatifs sécurisés pour les audits (heures de contrôle). L'entrepreneur « lève » une position de charge de la preuve - la compliance 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 repo 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, numéros fiscaux sont remplacées par des espaces réservés.

Remarque DSGVO : toutes les références à des personnes/entreprises dans 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 Harness (aperçu)

Déductible de ED01 :

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

Sources

• Justificatif de genèse du contrôle SV (anonymisé) : AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md section J
• GoBD (courrier BMF du 28.11.2019, BStBl I S. 1269, dernière modification 14.07.2025, BStBl I S. 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/EU (facture électronique B2G)
• RFC 9562 §5.7 (UUIDv7) - horodatage Unix-ms 48 bits
• Spécification V7GUID - work/OSS/TOP/.gitcover/specs/v7guid/ (normatif)
• DPMA Az. 10 2025 003 091.6 - demande de brevet V7GUID (revendication principale 2, revendications 5–8)
• Outil OSS GitCover UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (routines Helper gen/decode)
• DSGVO (obligation d'anonymisation lors de la publication)

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

Remarque : cette répartition entre sources, miroir et Community Hub 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.