DS12 — Intégrer des partenaires externes : instance Gitea, GitCover.IdP, API/MCP
Déclencheur S7
Un entrepreneur/PME ne livre pas seulement des documents — dans l'exécution de projet (exemple : GDT, GitCover Developer Tooling pendant la durée d'une commande), des tiers (clients, donneurs d'ordre, co-workers) ont besoin d'accès au déroulement du processus et aux preuves : quels jalons sont atteints ? Quels documents sont signés ? Comment le déroulement des justificatifs et des signatures est-il documenté à l'épreuve des audits ?
La voie classique de la PME : un dossier PDF dans le stockage cloud, une pièce jointe de chat, une chaîne d'e-mails — ou un abonnement coûteux à un portail de projet. Toutes les variantes brisent la chaîne de preuves que les parties I/II ont construite.
Les niveaux de mise à l'échelle
L'approche par dépôt Git permet au petit entrepreneur de mettre à l'échelle la même prestation dont ses partenaires ont besoin — en trois niveaux :
Offline-Paket"] --> B["Stufe 2
Gitea-Instanz
per Internet"] B --> C["Stufe 3
GitCover.IdP +
API/MCP"] style C fill:#e8eef7,stroke:#2c5282
Niveau 1 — Paquet hors ligne (sans infrastructure)
Le paquet conteneur (DS10 : *.gcpn.zip) est livré au partenaire sous forme
de fichier — auto-vérifiable, sans serveur, sans compte. Suffit pour des
preuves ponctuelles (p. ex. réception d'un ouvrage contractuel).
Niveau 2 — Instance Gitea accessible via Internet
Lorsque des tiers ont besoin d'un accès permanent, l'entrepreneur rend son instance (ou une instance dédiée) Gitea accessible via Internet — comme le montre l'exemple de la GCUV, où le groupement d'entreprises propose ses dépôts sur Internet via ses propres instances Gitea (git.gitcover.org / git.gitcover.de) :
| Aspect | Mise en œuvre |
|---|---|
| Contrôle des accès | Gitea-Org/Teams (partenaires uniquement dans les dépôts de dossiers, pas dans les PII) |
| Vue des preuves | Le conteneur GCPN comme index de processus (DS05) : le partenaire navigue vers les docs individuels |
| Preuves de signature | GVB/GCPN avec mention de signature — le partenaire voit la chaîne (SHA-256, Events, renvoi fac-similé) |
| Sécurité d'audit | L'historique Git reste dans le dépôt ; le partenaire peut le cloner (chronologie complète) |
Pour le petit entrepreneur : une instance Gitea coûte un petit serveur et de la maintenance — pas d'abonnement de licence par utilisateur. Le contrôle des accès est basé sur les dépôts (Repo → Team → Member), la limite PII reste dans le répertoire gitignored (pas dans le dépôt Internet).
Niveau 3 — GitCover.IdP, API/MCP
Le véritable levier : GitCover.IdP (projet de recherche BSFZ) fait du
dépôt Git un Identity Provider — l'accès est contrôlé via des Claims
(tenant_id, org_unit_id, modèle PII à deux niveaux), et l'API/MCP
(Model Context Protocol) fournit au partenaire un accès programmatique :
| Module | Prestation pour le partenaire |
|---|---|
| GitCover.IdP | Authentification + autorisation via des Claims Git (accès uniquement aux dépôts de dossiers, PII reste exclue) |
| GitCover API | Récupération structurée : index de conteneur, chaîne de signatures, manifeste de vérification — sans connaissance de Git |
| MCP | Les agents partenaires (co-workers IA du client) peuvent interroger les dossiers de manière automatisée — garde-fous via des politiques OPA/Rego |
| GCPN-Container | reste le niveau de preuve : chaque changement d'accès et d'état est ancré par sha256 |
C'est précisément LÀ que se révèle la force de l'approche par dépôt Git : le niveau de preuve (conteneur, sidecars, chaîne SHA) est le même — que le partenaire lise le paquet hors ligne (niveau 1), navigue dans le portail Gitea (niveau 2) ou le consomme de manière automatisée via API/MCP (niveau 3). L'entrepreneur met à l'échelle l'interface, pas la preuve — et conserve le contrôle sur les PII et les droits d'accès.
Conséquence pratique pour la PME
| Situation | Niveau | Coûts |
|---|---|---|
| Preuves contractuelles ponctuelles pour un client | 1 | 0 (ZIP) |
| Exécution de projet en continu avec des co-workers (GDT) | 2 | petit serveur + Gitea (OSS) |
| Partenaire avec ses propres agents IA / automatisation | 3 | IdP + intégration API/MCP |
Les niveaux sont cumulatifs : celui qui est arrivé au niveau 3 continue d'offrir les niveaux 1 et 2. La chaîne de preuves (parties I/II) est identique à tous les niveaux.
Qualification juridique
- Le contrôle des accès est pertinent au regard du RGPD (Art. 32 TOM) : la limite PII (répertoires gitignored) reste — les tiers ne reçoivent que les dépôts de dossiers.
- Les opérations de traitement pour des donneurs d'ordre sont le cas échéant couvertes par des contrats de sous-traitance (Art. 28 RGPD) — les conteneurs documentent les dossiers comme preuve.
- eIDAS n'est pas affecté : la chaîne de signatures est la même ; le niveau d'accès ne fait pas partie de la signature.
Références croisées
- GitCover.IdP — projet de recherche BSFZ
(
ORG-1-Partner/FY2026/BSFZ/) : Gitea/GitCover comme Identity Provider - Partie IV (prévue) — cercle PII/GPG : schémas d'identité, Trust Registry
- Axe 5 : démarches — modèle de Claims à deux niveaux
(
tenant_id/org_unit_id), Inlet-Pipeline - DS10 — le paquet conteneur comme livraison de niveau 1
Créé : 260913 | Partie II, article DS12 | Série : digital-signage