ED02 - Le modèle d'organisation PME : tenants, sphères, rôles

Problème

Un entrepreneur crée 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 auditable ?

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

• Tout dans le même pot - 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 toutes les comptabilités dans une seule instance, sans qu'il soit clair à quelle société appartient chaque enregistrement.
• Aucune séparation des sphères - dans le cadre de l'utilité publique, les opérations idéelles, de gestion patrimoniale, conformes à l'objet statutaire 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 (DG, comptable, paie, R&D), mais le dépôt ne sait pas dans quel rôle il agit à un moment donné.
• Aucune identité claire - les enregistrements n'ont pas d'identifiant unique qui les associe à une organisation, une sphère, un rôle.

Message clé

Structurer une organisation en tant que groupement 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. Ainsi naît Compliance by Design : la structure de l'organisation est ancrée dans la structure du dépôt.

Compliance by Design : le tenant, la sphère et le rôle ne sont pas des étiquettes ajoutées après coup - ce sont des champs structurels obligatoires, 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 indépendante pour laquelle il existe des obligations d'enregistrement propres. Dans le groupement 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 branche 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 comptabilités des filiales restent séparées.

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 elle est alors impérative. Le droit fiscal (§ 51–68 AO) exige la séparation des quatre sphères afin de ne pas mettre en danger le caractère d'utilité publique.

Risque en cas d'absence de séparation des sphères : la confusion des patrimoines (§ 55 Abs. 1 Nr. 5 AO) est un motif de retrait du caractère d'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 rétroactive des réserves (jusqu'à 15(!) ans en arrière).

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

Le rôle documente dans quelle fonction un acteur a agi. C'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 DG, comptable, chercheur, développeur et responsable R&D. Dans le dépôt, chaque artefact documente dans quel rôle il a agi - par ex. role: "GF" pour une décision, role: "F&E-Leiter" pour un justificatif d'heures FZul. Ainsi reste traçable si un enregistrement provient de la perspective DG (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é. La 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.v7g.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/                   # .v7g.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, pièce, entrée de registre foncier) contient le tenant, la sphère et le rôle comme champs obligatoires. Principe central de la traçabilité temporelle : le moment d'enregistrement n'est pas un champ séparé, mais ancré dans la uuidV7 elle-même - comme horodatage 48 bits conformément à RFC 9562 §5.7. La uuidV7 peut être générée à partir d'un repère temporel prédéfini (pas seulement now()) via GitCover Helper (UuidV7Gen), le reste étant rempli avec de l'aléatoire. Ainsi, le moment d'enregistrement est cryptographiquement lié à l'identité de l'artefact et ne peut pas être modifié après coup.

Important - ce qui arrive dans le dépôt Git : seuls ces artefacts structurés (entrées JSON, sidecars, pièces) 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. Ce qui est une fois dedans 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 la 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

Groupement de tenants : plusieurs organisations

Un groupement 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 pièces et des entrées des filiales sans les copier.

Important : le méta-dépôt ne contient aucune écriture comptable - seulement 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 - confusion des patrimoines)
• EStG (§ 3 Nr. 26/26a - forfaits, référence à la sphère)
• GoBD (circulaire BMF, documentation de procédure, 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 affectation des sources, du miroir et du hub communautaire reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour l'état actuel.