GitCover Symbol GCBoKGitCover Body of Knowledge

Axe 7 : Gouvernance

Statuts de GCC

Le GCBoK est publié par GitCover Commons gUG (GCC). GCC est un organisme à but non lucratif selon § 60a Abs. 1 AO, reconnu par le Finanzamt Bad Homburg v. d. H. (décision du 27.05.2026).

Les objectifs statutaires (§ 52 Abs. 2 Satz 1 AO) :

  1. Science et recherche (n° 1)
  2. Éducation, enseignement populaire et formation professionnelle (n° 7)
  3. Conseil aux consommateurs et protection des consommateurs (n° 16)
  4. Ouverture internationale et compréhension entre les peuples (n° 13)

Statuts complets, décision de reconnaissance et informations sur les dons : sur la page d'accueil GCC.

Règles communautaires GCC

Le GCBoK suit les principes open source :

Procédure de modification du GCBoK

Les modifications du GCBoK suivent un processus défini :

  1. Proposal - Issue dans le dépôt Gitea gcbok-content
  2. Review - Discussion communautaire, examen technique
  3. Draft - Pull request avec les modifications proposées
  4. Approval - Revue par la direction de GCC
  5. Merge - Intégration dans la branche main
  6. Release - Tag de release versionné

Du jugement privé au résultat démontrable

Governance ici ne signifie pas opinion dans le document, mais résultat démontrable dans le corpus. Les prescriptions personnelles de la personne autorisante - appréciations privées, pondérations, critères d'arbitrage - constituent le matériau d'entrée : elles sont protégées, ne sont pas versionnées et n'apparaissent pas dans le corpus de documentation. Ce qui en résulte, c'est le résultat de la décision : une ADR, un modèle, un règlement ou une preuve.

Pour la chaîne de preuve, cela signifie : le corpus Git atteste ce qui a été décidé et comment cela est démontrable - pas comment cela a été pesé en interne. Cette séparation protège à la fois la vie privée de la personne agissante et la force probante du dossier.

Règle pour les agents : respecter les prescriptions, documenter les résultats - ne ni citer ni reproduire l'évaluation elle-même tant que le HITL ne l'autorise pas expressément.

Versionnement

Le GCBoK utilise le Semantic Versioning (MAJOR.MINOR.PATCH) :

Composant Signification
MAJOR Modifications conceptuelles incompatibles
MINOR Nouveaux chapitres, nouvelles définitions (rétrocompatibles)
PATCH Corrections, clarifications

Auto-référentiel natif Git

Le GCBoK est versionné dans Git - l'ouvrage de référence sur la conformité native Git est lui-même hébergé dans Git. Il s'agit d'une auto-référence assumée : l'ouvrage sur l'ouvrage est versionné dans l'ouvrage.

Cadre stratégique : droit d'utilisation de la PI

AFJD (Axel Franz Johann Druschel) est, en tant que personne physique, demandeur, inventeur et titulaire permanent de tous les droits de protection. La PI reste chez AFJD - elle est mise à disposition de GCC sur base contractuelle pour utilisation (aucun transfert de propriété).

Aspect Transfert de propriété (non choisi) Droit d'utilisation par contrat (choisi)
Titulaire de la PI GCC personne physique
GCC comme concédant ? Oui -> caractère d'intérêt général menacé Non -> caractère d'intérêt général de GCC préservé
Protection contre la reprise Faible Élevée (la PI reste chez la personne physique)

Détails complets : Voir Droits de protection.

Séparation des PII : données personnelles centralisées, références dans les tenants

Les données personnelles (PII, DSGVO/GDPR) ne sont pas dispersées dans les dépôts de tenants. Chaque entité juridique tient toutes les PII dans un dépôt PII central (top-root, p. ex. REPOS/AFJD/PII/) — données de base et de contact, mentions de blocage, préavis de conservation/suppression, consentements et données particulièrement protégées. Dans les dépôts tenant/OSS/work, il n'y a que des références : l'uuidV7 de la personne comme person_uid (le type uuidV7, pas un nom de propriété) plus des informations de référence locales (fonction/rôle, droits).

Pourquoi : minimisation des données (DSGVO Art. 5), identification univoque (le nom réel n'est pas univoque) et droits des personnes concernées réellement applicables (information/suppression/portabilité) — un fait PII existe une fois, tous les autres endroits y renvoient. Les scans bruts (pièces d'identité/signatures) restent hors de Git.

Outillage : la solution GitCover.PII (UI d'autogestion analogue à un compte Google : aspects obligatoires DSGVO, mentions de blocage, rétention, données de contact) relie GitCover.IdP (IAM) et GitCover.Ledger (preuve).

SSoT normatif : OSS/TOP/.gitcover/specs/pii-separation.md.

Ordre et normalisation : les traitements sont d'abord déterminés selon la disposition GDPR (legalBasis, Art. 6/9 DSGVO) et ensuite via la référence (où/par quoi) — legalBasis est l'ancre (pas une liste libre de finalités). Les autorisations (« autorisation par l'utilisateur ») sont documentées techniquement comme GCPN et seulement référencées. Les situations DSGVO sont normalisées comme ENUMs/UNIONs dans GCBoK ; un catalogue OSCAL + ensembles d'artefacts OPA (SSoT : .gitcover/policy/pii-gdpr.catalog.json, pii_legal_basis.rego) est consommé par la fonctionnalité GitCover.PII (Policy-as-Code).

Souveraineté des données plutôt que Vendor Lock-In : les faits produits dans PII doivent pouvoir remplacer en option les graphes de comptes utilisateurs M365/MS — les données personnelles ne sont pas tenues dans une plateforme cloud, mais dans le dépôt Git. Cela permet une conformité native Git (auditable, auto-référentielle) et une pleine souveraineté des données de l'utilisateur sans Vendor Lock-In. Les faits PII constituent en même temps la base de données pour la fonctionnalité OU (GitCover.Discovery/plans/ADR-005), qui alimente System.DirectoryServices (Microsoft Active Directory) avec une structure OU/provisionnement — les personnes y figurent uniquement via person_uid ; GitCover.IdP reste serveur d'autorisation.