Compliance by Design - Un entrepreneur tient son journal dans Git
Une ligne d'illustration à travers le GCBoK
Le GCBoK définit des termes, des concepts et des principes d'architecture pour
la conformité native Git. Cette série d'articles met en œuvre ces principes
dans une ligne narrative continue - à l'exemple d'une organisation fictive
KMU (espace réservé ORG-1) et de son entrepreneur (espace réservé E1).
La série montre en 37 articles et 7 parties comment un entrepreneur, de la création à la première fiche de paie jusqu'à l'utilité publique, remplit ses obligations de conformité de manière structurée, démontrable et minimisant les risques - avec Git comme Audit-Ledger, V7GUID comme identifiant unique, OSCAL comme Compliance-Statement lisible par machine et OPA/Rego comme Policy-as-Code.
Modèle des déclencheurs
La série n'est pas structurée par thèmes, mais par événements de vie. Chaque article est déclenché par un déclencheur concret dans la vie de l'entreprise :
| Déclencheur | Parties | Articles |
|---|---|---|
| A - Création | Partie I, Partie II, Partie III | ED01-ED20 |
| B - Le 1er employé | Partie IV | ED21-ED28 |
| C - FZul/BSFZ & utilité publique | Partie V | ED29-ED32 |
| D - Harness | Partie VI | ED33-ED36 |
| E - Annexe | Partie VII | ED37-ED38 |
Levier de risque : aujourd'hui bon marché, demain à l'épreuve des audits
La thèse centrale de la série : la tenue de journal native Git génère un levier de risque. Les faits saisis aujourd'hui à coût minimal (une entrée JSON avec V7GUID + référence de justificatif SHA-256) deviennent des preuves sécurisées pour les audits pour les contrôles à venir (GoBD 10 ans, AO, déclarations annuelles SV, justificatifs FZul). L'entrepreneur « investit » aujourd'hui dans une future sécurité d'audit, qui ne serait atteignable sans une gestion native Git qu'avec un effort rétroactif élevé.
Le journal est l'agenda de travail, pas une documentation de loisirs
Le journal de l'entrepreneur est tenu parce qu'il constitue la SSoT temporelle du travail réel. Il relie agenda, décisions, temps de prestation, justificatifs, contrats et validations et fournit aux différents systèmes de contrôle et de destination le même point de départ traçable :
| Relation/Objectif | Ce que le journal apporte |
|---|---|
| BSFZ/Forschungszulage | Lien avec le projet, temps de prestation, délimitation R&D et création rapide de la preuve |
| Administration fiscale/EStG/EÜR | motivation professionnelle, sphère privée/professionnelle et affectation des dépenses |
| TVA | période de prestation, lien avec la prestation, exécution du contrat et lien avec la facture |
| GoBD/AO | chaîne rétrograde/progressive de l'écriture, du justificatif, de la décision, de la validation et de la modification |
| Gestion des risques | les questions ouvertes deviennent visibles au lieu d'être reconstruites plus tard de mémoire |
| Souveraineté numérique | les faits restent dans des artefacts Git versionnés et portables ; pas de Vendor Lock-In |
Le journal est donc l'agenda selon lequel on travaille. La conformité native Git met cet agenda en œuvre dans les dépôts de tenant avec Ur-Docs, Sidecars, GCPN, schémas et historique Git. L'agent soutient la saisie et la liaison, mais ne remplace ni le justificatif ni la validation humaine.
À propos de la série
Vous trouverez la série complète avec tous les articles, diagrammes Mermaid, exemples JSON et références de sources dans l'espace dédié aux séries du GCBoK :
Vers la série d'articles - Compliance by Design
Aperçu des parties
| Partie | Thème | Déclencheur |
|---|---|---|
| Partie I | Fondamentaux (Motivation, modèle organisationnel KMU, format de journal, registre de transparence lors de la création) | Création |
| Partie II | Direction d'entreprise : GoBD & documentation (bases GoBD, justificatifs, documentation des procédures, délais, AO, sphères, VBG, registre de transparence : documenter la détermination des bénéficiaires économiques) | Déclaration d'activité |
| Partie III | Autorités & identifiants (administration fiscale, compte Bundesanzeiger & E-Bilanz, DRV, registre de transparence : exécution & exploitation courante, BA, BZSt, interfaces avec les autorités) | Démarches administratives |
| Partie IV | Employés & paie (Onboarding, assurances, caisse maladie, fiche de paie, temps de travail, salaire minimum, congés, sphères) | 1er employé |
| Partie V | FZul/BSFZ & utilité publique | FZul/utilité publique |
| Partie VI | Exigences du Harness | Implémentation |
| Partie VII | Annexe (sources, glossaire, références CDN) | Référence |
Topologie des sources et liens de référence CDN
| Rôle | Lieu | Objectif |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Dépôt 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 de sources, miroir et hub communautaire reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour l'état actuel.