ED02 - Le modèle d'organisation PME : Tenants, Sphères, Rôles

Problème

Un entrepreneur fonde une organisation - et se trouve confronté à la question : comment structurer mon organisation pour que les obligations de conformité soient représentées de manière clairement séparée, traçable et sûre en cas d'audit ?

La pratique actuelle dans le domaine des PME ne connaît pas de séparation nette :

• Tout dans le même panier - les documents privés et professionnels se mélangent dans une boîte aux lettres, un lecteur, un compte cloud.
• Aucune séparation des tenants - une holding avec plusieurs sociétés tient tous les livres dans une seule instance, sans qu'il soit clair à quelle société appartient chaque enregistrement.
• Aucune séparation des sphères - en cas d'utilité publique, les opérations idéelles, de gestion patrimoniale, d'activité conforme à l'objet et économiques se mélangent dans un compte, un dossier, un dépôt.
• Aucune séparation des rôles - l'entrepreneur fait tout lui-même (GF, comptable, paie, R&D), mais le dépôt ne sait pas dans quel rôle il agit à ce moment-là.
• Aucune identité claire - les enregistrements n'ont pas d'identifiant unique qui les rattache à une organisation, une sphère, un rôle.

Message clé

Structurer une organisation comme réseau GitCover signifie : Tenant (organisation), Sphère (domaine d'activité en cas d'utilité publique) et Rôle (fonction de l'acteur) sont définis comme champs obligatoires de chaque artefact - et non comme des métadonnées optionnelles. Les hooks Git vérifient à chaque commit que la séparation est complète. Il en résulte Compliance by Design : la structure de l'organisation est ancrée dans la structure du dépôt.

Compliance by Design : Tenant, Sphère et Rôle ne sont pas des étiquettes ajoutées après coup - ils sont des champs obligatoires structurels, sans lesquels un artefact n'est pas admis dans le dépôt.

Le modèle à trois niveaux : Tenant, Sphère, Rôle

Niveau 1 - Tenant (organisation)

Un Tenant est une unité organisationnelle juridiquement autonome pour laquelle il existe des obligations d'enregistrement propres. Dans le réseau GitCover, chaque Tenant est géré comme une Organization (Git User) distincte avec des dépôts Git associés (ou un espace de noms de branches propre).

Exemple pratique : Un entrepreneur (E1) dirige une holding (ORG-1) avec deux filiales (ORG-1a, ORG-1b). Chaque filiale est un Tenant propre avec son propre dépôt. La holding dispose d'un méta-dépôt qui relie les filiales via des références V7GUID - mais les livres des filiales restent séparés.

Niveau 2 - Sphère (domaine d'activité, uniquement en cas d'utilité publique)

La Sphère n'est pertinente que pour les organisations d'utilité publique - mais alors impérativement. Le droit fiscal (§ 51–68 AO) exige la séparation des quatre sphères afin de ne pas mettre en danger l'utilité publique.

Risque en l'absence de séparation des sphères : le mélange de patrimoines (§ 55 Abs. 1 Nr. 5 AO) est un motif de retrait de l'utilité publique. Une organisation d'utilité publique qui ne sépare pas les opérations économiques et idéelles risque le retrait du statut d'utilité publique - et donc une imposition ultérieure des réserves (jusqu'à 15(!) ans rétroactivement).

Niveau 3 - Rôle (fonction de l'acteur)

Le Rôle documente la fonction dans laquelle un acteur a agi. Cela est important, car dans de nombreuses organisations une même personne occupe souvent plusieurs rôles (en particulier dans les PME) - et parce que le rôle détermine quelles obligations s'appliquent.

Exemple pratique : L'entrepreneur E1 est à la fois GF, comptable, chercheur, développeur et responsable R&D. Dans le dépôt, chaque artefact documente dans quel rôle il a agi - p. ex. role: "GF" pour une décision, role: "F&E-Leiter" pour un justificatif d'heures FZul. Il reste ainsi possible de retracer si un enregistrement provient de la perspective GF (administration) ou de la perspective R&D (recherche).

Le rôle n'est pas la personne : le rôle décrit la fonction (et, pour les déclarations, la partie représentée), non l'identité. Une même personne peut agir ou signer sur un document en plusieurs rôles ; l'identité technique d'exécution (compte, clé) constitue à nouveau un niveau propre. Les cinq niveaux Personne · Fonction · partie représentée · identité d'exécution · acte de signature sont décrits dans ED03.

Mise en œuvre dans le dépôt Git

Structure des répertoires

ORG-1/                          # Tenant: KMU
├── .gitcover/                  # GitCover-Konfiguration
│   ├── LEGAL_ENTITY.gc.json   # Tenant-Identität (V7GUID)
│   ├── dictionaries/           # Sphären, Rollen, Beleg-Typen
│   └── schemas/                # JSON-Schemata für Artefakte
├── diary/                      # Tagebuch (SSoT)
│   ├── entries/                # Tages-Einträge
│   └── tenants/                # Tenant-Sichten (Symlinks)
├── registry/                   # Behörden-Identifikatoren
├── sources/                    # Belegarchiv (PDF, XML, EML)
├── sidecars/                   # .gc.md Sidecars
├── checks/                     # Fristen-Check, Sphären-Check
└── {weitere bei Bedarf}/

Artefact JSON avec Tenant, Sphère, Rôle

Chaque artefact (entrée de journal, justificatif, inscription au registre foncier) contient Tenant, Sphère et Rôle comme champs obligatoires. Principe central de la traçabilité temporelle : l'heure d'enregistrement n'est pas un champ séparé, mais est ancrée dans l'uuidV7 elle-même - comme horodatage 48 bits conformément à la RFC 9562 §5.7. L'uuidV7 peut être générée à partir d'un repère temporel prédéfini (pas seulement now()) via GitCover Helper (gc-v7guid), le reste étant complété aléatoirement. L'heure d'enregistrement est ainsi liée cryptographiquement à l'identité de l'artefact et non modifiable a posteriori.

Important - ce qui arrive dans le dépôt Git : seuls ces artefacts structurés (entrées JSON, sidecars, justificatifs) sont admis dans le dépôt Git. Les documents privés ne sont jamais admis dans le dépôt, sauf s'ils ont été explicitement introduits et classifiés comme artefact. Une fois dedans, c'est dedans.

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "docUid": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "GF",
  "tenant": "ORG-1",
  "sphere": "ideell",
  "source": "E1",
  "source_sha256": "<SHA-256-...>",
  "tags": ["lohnabrechnung", "sv-meldung"]
}

Explication de la clé composite : V7GUID (Class Identifier) classe le document/l'action au moyen du registre .gitcover (quoi/quel type). uuidV7 (Object ID) est l'identifiant concret de l'objet avec le repère temporel prédéfini (RFC 9562 §5.7, 48 bits Unix-ms). Les deux ensemble forment la GCPN Sidecar Composite Key V7GUID:uuidV7. Une représentation séparée sous forme de chaîne datetime ou date est redondante et n'est pas tenue dans les faits - l'horodatage 48 bits se trouve déjà dans l'uuidV7. Les représentations sous forme de chaîne pour le transfert DTO/HTMX relèvent de la responsabilité du harness, pas du niveau des faits.

Les hooks Git vérifient la séparation

Réseau de tenants : plusieurs organisations

Un réseau de tenants (holding avec filiales, consortium) est relié via des références V7GUID - et non via des dépôts communs. Chaque Tenant conserve sa propre comptabilité, mais le méta-dépôt de la holding peut renvoyer à des justificatifs et des entrées des filiales sans les copier.

Important : le méta-dépôt ne contient aucune écriture comptable - uniquement des renvois croisés. La comptabilité reste chez chaque Tenant. Le méta-dépôt est un

• niveau d'index*, pas un niveau de comptabilité.

Levier de risque

Exigence du harness (aperçu)

Déductible d'ED02 :

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

Sources

• AO (§§ 51–68 - utilité publique, séparation des sphères, § 55 Abs. 1 Nr. 5 - mélange de patrimoines)
• EStG (§ 3 Nr. 26/26a - forfaits, lien avec les sphères)
• GoBD (lettre BMF, documentation des procédures, séparation des tenants)
• E1/agents/ (anonymisé) - concept SSoT avec Tenant, Sphère, Rôle

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

Remarque : cette répartition des sources, du miroir et du Community Hub reflète l'état actuel et peut changer. Veuillez vérifier la source canonique correspondante sur gitcover.org pour connaître l'état actuel.