Projet de recherche : GitCover.IdP

Reconnaissance officielle

Le projet de recherche "Git-native Compliance für KMU: Experimentelle Entwicklung eines integrierten Identity- und Compliance-Management-Systems mit taxonomischem Identifier-System (V7GUID)" a été reconnu par le DLR Projektträger / BSFZ conformément au § 6 FZulG comme projet de R&D éligible à un financement.

Contenu de la recherche

Étude visant à déterminer si des dépôts Git basés sur Gitea peuvent servir de Single Source of Truth (SSOT) pour un système intégré de gestion des identités et de la conformité pour les PME.

Hypothèses centrales

Caractéristiques de nouveauté

Questions de recherche BSFZ F1-F5 (qualifiées Frascati)

Pertinence pour le GCBoK

Le projet de recherche reconnu par le BSFZ démontre la nouveauté scientifique et technique de l'architecture centrale de GitCover du point de vue des autorités et renforce l'autorité normative du GCBoK :

1. V7GUID comme système d'identification breveté (N1)
2. GCEP/GCAL comme mécanisme de coordination des verrous (N3)
3. AI Guard-Rails via des structures Git déterministes (N2)

Cette triple confirmation (demande de brevet + attestation BSFZ + modèle d'utilité) constitue la base empirique de la revendication du GCBoK à se positionner comme autorité normative en matière de concepts.

Pertinence des MADR au-delà de GoBD

Les MADR (Markdown Any Decision Records) sont tenues dans le GCBoK principalement comme documentation des procédures conforme à GoBD (§ 146, § 147 AO). Cependant, le constat R&D du 21.08.2026 montre : les MADR ne sont pas exclusives à GoBD. Dans de nombreuses normes et réglementations connexes, les statuts de décision et de contrôle sont définis au moyen d'enums ou de valeurs kind propres, parfois contradictoires, pour « statut ».

Vocabulaire de statut dans OSCAL et les réglementations

Constat : le vocabulaire d'obsolescence utilisé ici (active | superseded | deprecated | obsolete | review_required) couvre exclusivement le cycle de vie post-actif. Un statut antérieur à active (pas encore tranché, bloqué, en considération) n'est nulle part pris en compte.

Cycle de vie étendu (statuts pre-active)

Afin de représenter les délibérations (« we need more information/funds/community to decide »), le vocabulaire est complété par quatre statuts pre-active :

Règle de mapping pour le GCBoK

Lors de la reprise de vocabulaires de statut tiers (OSCAL, NIST, BSI, ISO, RGPD, PCI-DSS) dans la taxonomie du GCBoK, la règle suivante s'applique :

1. Les valeurs tierces « planned/not-applicable/entbehrlich » → à mapper sur planned / in_consideration (pre-active).
2. Les valeurs tierces « implemented/operational/erfüllt/in-place » → à mapper sur active.
3. Les valeurs tierces « partial/under-development/bedingt entbehrlich » → à mapper sur decision_pending ou review_required (selon le degré de maturité).
4. Les valeurs tierces « alternative/not-applicable » → selon le contexte : superseded (si remplacé) ou deprecated (si rejeté).

Ce mapping garantit l'auditabilité GoBD (§ 147 Abs. 6 AO, accès Z3), sans perdre les vocabulaires OSCAL et réglementaires tiers — une contribution centrale de la recherche du GCBoK à une documentation de conformité interopérable.

Phase 2 - AI Safety Research (à partir de 2026)

À partir de 2026, le focus s'étend à la sécurité des infrastructures d'IA. La thèse de recherche : les structures Git déterministes (V7GUID) peuvent servir de Guard Rails physiques pour des agents IA autonomes - au lieu de prompts stochastiques et injectables.

Délimitation par rapport à l'ancien projet

Le déplacement thématique de « Gitea comme IdP » vers « dépôts Git comme guardrails IA au lieu de prompts » via GCUCB nécessite une attestation BSFZ distincte en tant que nouveau projet de recherche. La délimitation au niveau des paquets de travail garantit que les deux projets restent clairement séparés et que la reconnaissance au titre de la Forschungszulage n'est pas compromise.

Questions de recherche (Phase 2)

1. Déterminisme vs. stochasticité : dans quelle mesure le contrôle d'un agent IA par un dépôt Git-Guardrail versionné peut-il être formalisé de manière déterministe, de sorte que les écarts par rapport à la Policy soient détectés au moment du build (et non seulement au moment du prompt) ?
2. Résistance à la Prompt-Injection : dans quelle mesure une couche de guardrails native Git (signée, immuable, appliquée via Git-Hook/OPA) protège-t-elle contre la « lethal trifecta » (données privées + untrusted content + exfiltration) ?
3. MCP comme Policy-Enforcement-Point : un serveur MCP avec ressource UI et iframe-UI peut-il agir comme Policy-Gate n'exposant que les outils/contextes approuvés (signés) ?
4. Auditabilité : l'historique des commits Git du dépôt de guardrails peut-il servir de piste d'audit conforme à GoBD pour les décisions de l'IA ?

Remarque : les développements de recherche et de prototypes d'AFJD (Axel Franz Johann Druschel) sont réalisés en régie propre, en dehors du temps de travail GCC. L'IP reste chez AFJD ; son utilisation est concédée au GCC sur une base contractuelle. Cette séparation garantit le statut à but non lucratif du GCC (aucune activité commerciale dissimulée).

Voir aussi : demandes FZulG et planification financière sur la GCC-Landingpage.