ED05 - Fondamentaux de la GoBD : traçabilité, vérifiabilité, immuabilité
Problème
Un entrepreneur se lance dans la comptabilité - et se trouve confronté à la question : Que demande concrètement la GoBD, et comment la satisfaire sans logiciel spécialisé coûteux ?
La pratique actuelle dans le secteur des PME :
- La GoBD, un livre aux sept sceaux - la GoBD (circulaire du BMF, 146 pages) est abstraite, formulée en langage juridique, à peine accessible aux profanes
- « C'est le conseiller fiscal qui s'en occupe » - beaucoup d'entrepreneurs délèguent la GoBD à des conseillers fiscaux sans comprendre eux-mêmes ce qui est exigé - et en paient le prix
- Solutions en silos - logiciel de paie, comptabilité, archive des pièces justificatives, chacun séparément, sans conformité GoBD de bout en bout
- Le PDF comme « électronique » - beaucoup pensent qu'un PDF sur un disque dur satisfait la GoBD - mais la GoBD exige une exploitabilité par machine (§ 147 Abs. 6 AO), pas seulement un archivage
- Aucune documentation des procédures - la GoBD Rz. 64–91 exige une documentation des procédures, mais qui, dans une PME, en possède une ?
- Modifications ultérieures - des écritures sont « corrigées » sans que la modification soit traçable - la GoBD Rz. 146 exige l'immuabilité
Message clé
La GoBD exige trois principes clés que Git satisfait by Design :
- Traçabilité (GoBD Rz. 146) - chaque entrée doit être traçable (Qui ? Quand ? Quoi ? Pourquoi ?)
- Vérifiabilité (GoBD Rz. 147) - la comptabilité doit être vérifiable (traçabilité rétrograde/progressive)
- Immuabilité (GoBD Rz. 146) - après la comptabilisation, les données ne doivent pas être modifiées (corrections sous forme de nouvelles entrées)
Git satisfait les trois structurellement - non pas au moyen de contrôles ultérieurs, mais par l'architecture elle-même :
Rz. 146"] G --> P["Vérifiabilité
Rz. 147"] G --> U["Immuabilité
Rz. 146"] N --> GN["Git : auteur du commit
+ horodatage
+ message de commit"] P --> GP["Git : V7GUID + SHA-256
traçabilité rétrograde
et progressive"] U --> GU["Git : Tags + Protected Branches
+ marquage d'obsolescence
corrections sous forme de nouveaux commits"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style P fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GN fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GP fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GU fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
Compliance by Design : la conformité GoBD ne naît pas d'une vérification ultérieure, mais du choix du support. Qui travaille dans des dépôts Git satisfait traçabilité, vérifiabilité et immuabilité structurellement - non pas au moyen de Controls supplémentaires.
GoBD - Origine et portée
La GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) est une circulaire du BMF du 28.11.2019 (BStBl I S. 1269), modifiée en dernier lieu le 14.07.2025 (BStBl I S. 1502).
| Propriété | Valeur |
|---|---|
| Émetteur | Ministère fédéral des Finances (BMF) |
| Nature juridique | Instruction administrative (pas une loi, mais contraignante pour les bureaux des impôts) |
| Base | § 146 AO (prescriptions d'ordre), § 147 AO (conservation), HGB (§§ 238–241) |
| Portée | Pour tous les entrepreneurs qui comptabilisent par voie électronique (en pratique : tous) |
| Volume | 146 numéros marginaux (Rz.) |
Important : la GoBD n'est pas une « recommandation » - c'est l' instruction administrative d'après laquelle les bureaux des impôts contrôlent. Qui ne satisfait pas la GoBD risque une estimation (§ 162 AO), des majorations de retard (§ 152 AO) et, dans le pire des cas, une procédure pénale fiscale (§ 370 AO).
Les trois principes clés de la GoBD en détail
1. Traçabilité (GoBD Rz. 146)
GoBD Rz. 146 : « La comptabilité doit être établie de telle sorte qu'un tiers expert puisse, dans un délai raisonnable, se faire une vue d'ensemble des opérations commerciales et de la situation de l'entreprise. »
Cela signifie : un vérificateur (ou un conseiller fiscal, ou un fonctionnaire des impôts) doit pouvoir retracer dans un délai raisonnable ce qui s'est passé.
| Exigence GoBD | Comment Git la satisfait |
|---|---|
| Qui a comptabilisé ? | git log --author montre chaque auteur de commit |
| Quand a-t-on comptabilisé ? | uuidV7 contient un horodatage 48 bits (RFC 9562 §5.7) |
| Qu'a-t-on comptabilisé ? | le diff du commit montre exactement ce qui a été ajouté/modifié |
| Pourquoi a-t-on comptabilisé ? | le message de commit documente la justification |
| Dans quel rôle ? | champ role dans l'artefact JSON (GF, comptable, responsable R&D) |
Qui ? Quand ? Quoi ?"] P --> SH["git show
détails du commit"] P --> DF["git diff
Qu'est-ce qui a changé ?"] P --> V7["uuidV7 decode
heure de saisie exacte"] GL --> R["Traçabilité
dans un délai raisonnable"] SH --> R DF --> R V7 --> R style P fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SH fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DF fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
2. Vérifiabilité (GoBD Rz. 147)
GoBD Rz. 147 : « La comptabilité doit être établie de telle sorte qu'elle puisse être vérifiée. »
Cela signifie : la comptabilité doit être traçable de manière rétrograde et progressive (voir ED03) :
- Rétrograde : de l'écriture comptable → pièce justificative → entrée de journal → V7GUID
- Progressive : de la pièce justificative → écriture comptable → grand livre → bilan d'ouverture
| Exigence GoBD | Comment Git la satisfait |
|---|---|
| Traçabilité rétrograde | source_sha256 dans l'entrée de journal → pièce justificative |
| Traçabilité progressive | V7GUID dans la pièce justificative → entrée de journal → grand livre |
| Exploitabilité par machine (§ 147 Abs. 6 AO) | JSON-Schema-First - données structurées, pas de PDF |
| Exhaustivité | le Pre-Commit-Hook vérifie que chaque entrée du grand livre possède un source_sha256 |
3. Immuabilité (GoBD Rz. 146)
GoBD Rz. 146 : « Les inscriptions ne doivent pas être modifiées de telle manière que le contenu original ne puisse plus être établi. »
Cela signifie : après la comptabilisation, les données ne doivent pas être modifiées. Les corrections doivent être effectuées sous forme de nouvelles entrées avec justification.
| Exigence GoBD | Comment Git la satisfait |
|---|---|
| Aucune modification ultérieure | les commits Git sont immuables (hachage SHA-256) |
| Corrections sous forme de nouvelles entrées | nouveaux commits avec obsolescence: superseded_by |
| Correction traçable | git log montre original + correction + justification |
| Protected Branches | branche main protégée, pas de Force-Pushes |
| Tags comme marqueurs de validation | les Tags marquent les états validés (immuables) |
Commit 1"] B --> TAG["Tag v1.0
validé"] K["Correction nécessaire"] K --> C["Écriture de correction
Commit 2"] C --> OBS["obsolescence:
status: superseded
superseded_by: Commit 2"] B --> OBS style B fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style TAG fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style K fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style C fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style OBS fill:#E5E7EB,stroke:#6B7280,color:#0F1B33
Important : Git permet techniquement
git rebaseetgit commit --amend
- mais seul un historique linéaire sans réécriture est conforme à la GoBD. Le Pre-Commit-Hook vérifie qu'aucun Force-Push n'est effectué sur
mainet que les corrections sont effectuées sous forme de nouveaux commits avec marquage d'obsolescence.
GoBD et AO - la base juridique
prescriptions d'ordre
pour la comptabilité"] AO --> S147["§ 147 AO
conservation
des documents"] S146 --> GoBD["GoBD
(circulaire du BMF)
concrétisation
pour les systèmes électroniques"] S147 --> GoBD GoBD --> R146["Rz. 146
Traçabilité
Immuabilité"] GoBD --> R147["Rz. 147
Vérifiabilité"] GoBD --> R64["Rz. 64–91
documentation des procédures"] GoBD --> R152["Rz. 152
délais de conservation"] style AO fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style S146 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S147 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style R146 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R147 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R64 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R152 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
| Source juridique | Contenu | Lien avec la GoBD |
|---|---|---|
| § 146 Abs. 1 AO | écritures « individuellement, complètement, correctement, en temps utile et de manière ordonnée » | Rz. 146 (traçabilité) |
| § 146 Abs. 4 AO | aucune modification rendant le contenu original méconnaissable | Rz. 146 (immuabilité) |
| § 146 Abs. 5 AO | « disponibles à tout moment et lisibles sans délai » | Rz. 152 (disponibilité) |
| § 147 Abs. 2 AO | « pouvoir être exploités par machine » | Rz. 147 (vérifiabilité) |
| § 147 Abs. 3 AO | délais de conservation (10/8/6 ans) | Rz. 152 (conservation) |
| § 147 Abs. 6 AO | accès aux données lors d'un contrôle externe (Z1/Z2/Z3) | Rz. 147 (accès aux données) |
Accès aux données GoBD (Z1, Z2, Z3)
La GoBD définit trois types d'accès que l'administration fiscale peut utiliser lors d'un contrôle externe :
| Type d'accès | Description | Comment Git le prend en charge |
|---|---|---|
| Z1 (accès direct) | le vérificateur utilise le système de l'entrepreneur | git log, git show, git grep directement dans le dépôt |
| Z2 (accès indirect) | le vérificateur donne des consignes, l'entrepreneur effectue l'exploitation | git log --since, git grep, export JSON |
| Z3 (remise de support de données) | l'entrepreneur remet les données sur un support de données | git bundle comme archive self-contained |
Z3 est la force de Git : un
git bundlecontient l'intégralité du dépôt (historique, commits, Tags) dans un seul fichier - self-contained, pas de Cloud-Account, pas de licence logicielle. Le vérificateur peut reconstituer le dépôt sur son système avecgit cloneet effectuer toutes les opérations Z1/Z2. C'est l'export Z3 conforme à la GoBD « by Design ».
Extension GitCover : Static-Web comme accès du vérificateur (Z3+)
Au-delà de git bundle, les GitCover Tools (s'ils sont installés
et utilisés) peuvent générer, dans le cadre d'une clôture de période, un
site statique navigable dans un navigateur à partir du Tenant Evidence Package.
Ce site contient :
- Tous les documents DMS (pièces justificatives, factures, contrats) en HTML/PDF
- Contrats pluri-périodes et documents de longue durée
- États (grand livre, journal, BWA, bilan)
- Règles de procédure (documentation des procédures, plan comptable)
- Sidecars (
.v7g.mdavec V7GUID, SHA-256, taxonomie) - Preuves d'intégrité (manifeste avec sommes de contrôle)
(clôture de période)"] EP --> GB["git bundle
(base Z3)"] EP --> SW["Générateur Static-Web
(GitCover Tool)"] GB --> CL["git clone
(le vérificateur reconstitue le dépôt)"] SW --> FS["Filesystem-Based-Web
(HTML + PDF + JSON)"] FS --> BR["Navigateur
(le vérificateur navigue)"] FS --> IDX["Pages d'index
(par date, type de pièce, V7GUID)"] FS --> NAV["Navigation
(rétrograde/progressive)"] FS --> SRH["Recherche
(texte intégral, SHA-256, V7GUID)"] style EP fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GB fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SW fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style CL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style FS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style BR fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style IDX fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style NAV fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style SRH fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
La méthode la plus sûre de toutes : un Filesystem-Based-Web ne nécessite aucun système IAM, aucune infrastructure serveur, aucune base de données, aucune connexion réseau. Le vérificateur ouvre
index.htmldans son navigateur - hors ligne, en local, sans authentification. L'intégrité est garantie par le manifeste avec sommes de contrôle SHA-256, et non par des droits d'accès. C'est la forme la plus sûre d'accès pour le vérificateur, car il n'existe aucune surface d'attaque.
| Propriété | git bundle (Z3) | Static-Web (Z3+) |
|---|---|---|
| Le vérificateur nécessite | Git installé | uniquement un navigateur |
| Navigation | CLI (git log, git show) |
navigateur (clic, recherche) |
| États | manuellement via git grep |
pages d'index pré-générées |
| Documents DMS | dans le dépôt (PDF, XML) | intégrés en HTML/PDF |
| Documentation des procédures | Markdown dans le dépôt | rendue en HTML |
| Intégrité | Git-SHA-256 | manifeste + SHA-256 par fichier |
| IAM nécessaire | non | non |
| Réseau nécessaire | non | non |
| Surface d'attaque | minimale | minimale (Filesystem only) |
Exemple pratique : l'entrepreneur (
E1) établit la clôture de période pour FY2026. Le GitCover Tool génère un Tenant Evidence Package avecgit bundle(pour les vérificateurs techniquement avertis) et un site statique (pour les vérificateurs qui souhaitent n'utiliser qu'un navigateur). Les deux sont remis sur une clé USB - self-contained, hors ligne, sans IAM. Le vérificateur choisit lui-même s'il exécutegit cloneou s'il ouvreindex.html.
Levier de risques
| Aujourd'hui (cheap) | Demain (à l'épreuve des audits) | Risque atténué |
|---|---|---|
| Dépôt Git comme support de comptabilité | GoBD Rz. 146/147 satisfaites by Design | estimation § 162 AO |
git log comme preuve |
traçabilité dans un délai raisonnable | contestation de la régularité |
| V7GUID + SHA-256 par entrée | traçabilité rétrograde/progressive | déclassement de la valeur probante |
| Tags + Protected Branches | immuabilité après validation | violation de la GoBD par modification ultérieure |
git bundle comme export Z3 |
remise de support de données sans Cloud-Account | violation de la GoBD due à d'anciens systèmes non disponibles |
| Marquage d'obsolescence | corrections traçables | modifications dissimulées |
| Static-Web comme Z3+ (clôture de période) | accès du vérificateur sans IAM, uniquement navigateur | **violation de la GoBD due à des données inaccessibles/inadaptées au vérificateur ** |
Exigences Harness (aperçu)
Déductibles de ED05 :
| ID | Exigence | Priorité |
|---|---|---|
| FA-6.1 | Documentation des procédures en tant qu'artefact Git versionné | MUST |
| FA-6.2 | Grand livre (journal) en JSON avec V7GUID + SHA-256 par entrée | MUST |
| FA-6.5 | Conservation de 10 ans via Evidence-Packages (Git-Bundles) | MUST |
| FA-6.6 | Immuabilité après validation (Tags, Protected Branches) | MUST |
| FA-6.7 | Générateur Static-Web pour la clôture de période (Z3+) : site web navigable dans un navigateur à partir du Tenant Evidence Package, sans IAM, Filesystem-Based | SHOULD |
| TA-2.1 | Pre-Commit : validation JSON-Schema | MUST |
| TA-2.4 | Pre-Commit : vérification du statut d'obsolescence (pas de commit sur obsolete) |
SHOULD |
La liste complète des exigences dans Harness-Anforderungen.md.
Sources
- GoBD (circulaire du BMF du 28.11.2019, BStBl I S. 1269, modifiée en dernier lieu le 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - prescriptions d'ordre, § 147 - conservation, § 162 - estimation, § 152 - majoration de retard)
- HGB (§§ 238–241 - obligation de comptabilité)
AFJD/agents/(anonymisé) - concept SSoT avec utilisation de Git conforme à la GoBDGitCover.Ledger/docs/02-Tenant-Evidence-Package.md- concept du Tenant Evidence Package (clôture de période, rôles du dépôt, règles d'exhaustivité)GitCover.Toolbox- toolset GitCover (analyse, V7GUID, composants UI)
Topologie des sources et liens de référence CDN
| Rôle | Emplacement | Objectif |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Stockage canonique (signé GPG, versionné) |
| Public OSS Mirror / CDN | codeberg.org/gitcover-commons | Miroir en lecture seule ; découverte FLOSS |
| Community Hub | github.com/gitcover-commons | Issues & Discussions ; référence du code source sur Codeberg |
Remarque : cette attribution des sources, du miroir et du Community Hub reflète l' état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour connaître l'état actuel.