Axe 14 : Certification (provisoire)
Remarque : Ce chapitre décrit les planifications pour la phase 3 (T2–T4 2027). Les aptitudes à la certification esquissées ici sont prévues ou planifiées. Leur obtention dépend du succès de la communauté et de l'acceptation du GCBoK. À l'heure actuelle (2026), personne ne peut sérieusement le prédire.
Objectif
Établir un schéma de certification pour la conformité Git-native sur la base du GCBoK, qui satisfait aux exigences structurelles de ISO/IEC 24773 (BoK comme base pour les schémas de certification) — pour autant que la communauté adopte le GCBoK comme standard de référence normatif.
Sources de matériel pour le schéma de certification (prévu)
Pour la construction des programmes de certification, les deux volets GCC fournissent le matériel :
- GCC (organisation/pratique de conformité) : statuts/cadre du § 60a, activités, projets, financement — ainsi que les rapports d'expérience/leçons apprises du site GCC comme faits techniques (theming, i18n, contrats de rendu) sans prétention marketing.
- GCBoK (œuvre de connaissance) : structure des axes/compétences, Learning Outcomes, critères d'évaluation et niveaux de compétence — voir les groupes de compétences de cet axe.
Il est prévu de mapper systématiquement ces sources sur les groupes de compétences et d'intégrer les rapports d'expérience comme exemples d'application dans les critères d'évaluation.
Statut : prévu/planifié — aucun programme existant. Les certificats ne seront proposés qu'après une mise en place réussie (phase 3) et l'acceptation par la communauté ; il n'existe aucun droit à la certification.
ISO/IEC 24773 — Exigences structurelles (aperçu succinct)
ISO/IEC 24773 définit comment un Body of Knowledge (BoK) doit être structuré pour pouvoir servir de base à des schémas de certification. Exigences essentielles :
| Niveau | Terme ISO/IEC 24773 | Correspondance GCBoK (statut) |
|---|---|---|
| 1 | Knowledge Areas (KAs) | 14 axes (01–14) — existant |
| 2 | Competencies par KA | prévu — à définir par axe |
| 3 | Learning Outcomes | planifié — objectifs d'apprentissage mesurables par Competency |
| 4 | Assessment Criteria | prévu — critères d'évaluation pour les examens |
| 5 | Professional Roles | planifié — attribution des rôles (p. ex. Compliance Engineer, Auditor) |
| 6 | Competency Levels | prévu — niveaux (Entry / Practitioner / Expert) |
Démarche planifiée (phase 3, T2–T4 2027)
1. Définition des compétences par axe (prévu)
Pour chacun des 14 axes, 2 à 4 Competencies doivent être formulées. Exemple (axe 02 — Concepts) :
| Competency ID | Titre (titre de travail) | Description (planifiée) |
|---|---|---|
GCBOK-02-C1 |
Appliquer la classification V7GUID | Attribuer de manière déterministe la hiérarchie L1–L6 + les champs d'identification étendus (RepositoryId, ProcessTypeId, GatewayId, VariantId) |
GCBOK-02-C2 |
Construire des chaînes de preuves (Evidence Chains) | Établir le chaînage prev_sha256, les signatures GPG, les chaînes de preuves V7GUID pour les justificatifs GoBD |
GCBOK-02-C3 |
Valider une Cryptographic Evidence Chain | Vérifier le hash de commit Git + la signature GPG + le V7GUID comme vérifiabilité en O(1) |
1a. Nouveau groupe de compétences — Onboarding, Chat-Workflow et Harness (pilote possible)
Les thèmes du prototype d'onboarding AFJD/GCUV actuel sont notés comme groupe de compétences possible pour de futures évaluations de partenaires :
| Competency ID | Titre (titre de travail) | Description (planifiée) |
|---|---|---|
GCBOK-05-C4 |
Onboarding PME auditable | Saisir un espace de travail existant comme Legal-Tenant/Group-OU et le doter, avant migration, d'une Git-Baseline, d'une identité et d'une structure de récupération |
GCBOK-03-C4 |
Chat-Workflow et protocole d'agents | Représenter les spécifications, questions, options de réponse, réponses, décisions, actions d'outils, artefacts et gates sous la forme de chat-workflow-1.0 |
GCBOK-04-C4 |
Gates de harness déterministes | Exécuter correctement les gates de schéma, SHA, politique, test, HITL, écriture et commit et détecter les états bloquants |
GCBOK-02-C4 |
Migration récupérable | Créer des checkpoints, des comparaisons d'états et des plans de restauration ; documenter les corrections sans réécriture de l'historique |
GCBOK-06-C4 |
Transfert vers les modules métier | Transmettre les résultats d'onboarding au Ledger, DMS, Portfolio et autres modules GitCover via des références |
Ce groupe est à l'état de planification, et non une reconnaissance, une accréditation ou une certification.
2. Learning Outcomes par Competency (planifié)
Par Competency, 2 à 3 Learning Outcomes mesurables (taxonomie de Bloom : Remember → Create).
Exemple GCBOK-02-C1 :
| LO ID | Formulation (planifiée) | Niveau de Bloom |
|---|---|---|
GCBOK-02-C1-LO1 |
Pouvoir expliquer les six niveaux hiérarchiques (L1–L6) et leur largeur de 4 bits | Understand |
GCBOK-02-C1-LO2 |
Déterminer la notation class correcte (L1_L2_L3_L4_L5_L6) pour une preuve donnée |
Apply |
GCBOK-02-C1-LO3 |
Détecter et corriger une classification V7GUID erronée à l'aide des règles du dictionnaire | Analyze |
Exemples de Learning Outcomes pour GCBOK-05-C4 (planifiés)
| LO ID | Formulation (planifiée) | Niveau de Bloom |
|---|---|---|
GCBOK-05-C4-LO1 |
Distinguer le Legal-Tenant, la topologie Group/OU et les sociétés liées | Understand |
GCBOK-05-C4-LO2 |
Avant une migration, créer le dépôt Git, .gitcover/, un snapshot de référence et un point de restauration |
Apply |
GCBOK-05-C4-LO3 |
Réaliser une migration de manière traçable via le Chat-Workflow, le gate HITL, le gate de validation et un checkpoint | Create |
GCBOK-05-C4-LO4 |
Restaurer un état confirmé antérieur au moyen d'un plan de restauration et vérifier l'intégrité | Analyze |
3. Assessment Criteria (prévu)
| Critère | Description (prévue) |
|---|---|
| Examen théorique | QCM / réponse courte sur les concepts, définitions, normes |
| Exercice pratique | Dans un environnement Git de test : générer un V7GUID, créer un sidecar, valider une chaîne de preuves |
| Étude de cas | Résoudre un scénario de conformité donné (p. ex. clôture annuelle GoBD) avec les moyens du GCBoK |
4. Professional Roles Mapping (planifié)
| Rôle | Axes pertinents (exemple) | Niveau de certification (prévu) |
|---|---|---|
| Compliance Engineer | 01, 02, 04, 05, 06 | Practitioner |
| Git-native Auditor | 01, 02, 05, 07, 14 | Expert |
| Developer (GitCover Stack) | 02, 03, 04, 06 | Entry → Practitioner |
| PMO / Governance Lead | 01, 05, 07, 10, 14 | Practitioner → Expert |
5. Competency Levels (prévu)
| Niveau | Désignation | Conditions préalables (prévues) |
|---|---|---|
| Entry | Compréhension des fondamentaux | Examen théorique réussi ; chapitres 01–06 du GCBoK lus |
| Practitioner | Compétence d'application | Entry + exercice pratique + 1 étude de cas ; au moins 1 an d'expérience de projet |
| Expert | Compétence de conception | Practitioner + plusieurs études de cas ; contribution à la communauté (PRs, reviews, traductions) ; au moins 3 ans d'expérience |
Parcours de certification partenaire possible (planification)
Pour les partenaires GitCover, une évaluation orientée pratique pourra être prévue ultérieurement :
- Onboarding Readiness : bootstrap du dépôt, modèle Legal-Tenant/OU et baseline.
- Workflow Literacy :
chat-workflow-1.0, dialogues, décisions et sources. - Harness Operation : guards déterministes, gates HITL et d'écriture, validation.
- Migration Evidence : checkpoints, manifestes SHA, sidecars et plan de restauration.
- Module Handover : transfert vers Ledger/DMS/Portfolio sans perte de la provenance.
- Review : évaluation indépendante d'un cas anonymisé par des examinateurs/reviewers.
L'évaluation serait une proposition de certification possible. Elle ne remplace ni une accréditation ni un examen indépendant technique, fiscal ou juridique.
Dépendances et risques
| Facteur | Influence sur la certification |
|---|---|
| Acceptation par la communauté | Sans large utilisation du GCBoK comme ouvrage de référence, pas de demande de certification |
| Maturité des outils | Webstatic, OPA, l'outillage OSCAL doivent être stables et documentés |
| Écosystème de partenaires | Partenariats BSI/ENISA (feuille de route phase 3) comme ancrage de crédibilité |
| Conditions-cadres juridiques | Les schémas de certification en DE/UE nécessitent une accréditation (DAkkS ou similaire) |
Prochaines étapes (provisoires)
- Recueillir les retours de la communauté (Gitea Issues, Discussions) — y a-t-il un besoin ?
- Élaborer et réviser des Pilot-Competencies pour 2 à 3 axes (p. ex. 02, 04, 05)
- Atelier Learning-Outcome avec des formateurs/examinateurs potentiels
- Outillage d'évaluation sous forme de prototype (basé sur webstatic ? export OSCAL ?)
- Décision : poursuite uniquement en cas d'écho positif de la communauté
Références
- ISO/IEC 24773:2019 — Software and systems engineering — Certification of software and systems engineering professionals
- GCBoK chapitre 00 (Index) — positionnement comme BoK
- GCBoK chapitre 10 (Roadmap) — phase 3 : schéma de certification (ISO/IEC 24773)
- GCBoK chapitre 11 (référence GCC) — utilité publique et autorité normative