Axe 14 : Certification (provisoire)
Remarque : Ce chapitre décrit la planification de la Phase 3 (Q2–Q4 2027). Les aptitudes à la certification esquissées ici sont prévues ou planifiées. Leur atteinte dépend du succès communautaire et de l'acceptation du GCBoK. À l'heure actuelle (2026), personne ne peut le prédire sérieusement.
Objectif
Établir un schéma de certification pour la conformité Git-native sur la base du GCBoK, qui réponde aux exigences structurelles de l'ISO/IEC 24773 (BoK comme base pour les schémas de certification) — à condition que la communauté adopte le GCBoK comme standard de référence normatif.
ISO/IEC 24773 — Exigences structurelles (bref aperçu)
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 principales :
| Niveau | Terme ISO/IEC 24773 | Équivalent GCBoK (statut) |
|---|---|---|
| 1 | Knowledge Areas (KAs) | 14 axes (01–14) — existants |
| 2 | Competencies par KA | prévus — à définir par axe |
| 3 | Learning Outcomes | planifiés — objectifs d'apprentissage mesurables par Competency |
| 4 | Assessment Criteria | prévus — critères d'évaluation pour les examens |
| 5 | Professional Roles | planifiés — attribution des rôles (p. ex. Compliance Engineer, Auditor) |
| 6 | Competency Levels | prévus — niveaux (Entry / Practitioner / Expert) |
Démarche planifiée (Phase 3, Q2–Q4 2027)
1. Définition des Competencies par axe (prévue)
Pour chacun des 14 axes, il est prévu de formuler 2–4 Competencies. 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 étendus (RepositoryId, ProcessTypeId, GatewayId, VariantId) |
GCBOK-02-C2 |
Construire des chaînes de preuves (Evidence Chains) | Construire le chaînage prev_sha256, les signatures GPG et les chaînes de preuves V7GUID pour les justificatifs GoBD |
GCBOK-02-C3 |
Valider la Cryptographic Evidence Chain | Vérifier le hash de commit Git + la signature GPG + le V7GUID comme vérifiabilité O(1) |
2. Learning Outcomes par Competency (planifiés)
Par Competency, 2–3 Learning Outcomes mesurables (taxonomie de Bloom : Remember → Create).
Exemple GCBOK-02-C1 :
| LO ID | Formulation (planifiée) | Niveau Bloom |
|---|---|---|
GCBOK-02-C1-LO1 |
Être capable d'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 Dictionary | Analyze |
3. Assessment Criteria (prévus)
| Critère | Description (prévue) |
|---|---|
| Examen théorique | Choix multiple / réponses courtes 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. Mapping des Professional Roles (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évus)
| Niveau | Désignation | Prérequis (prévus) |
|---|---|---|
| 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 communautaire (PRs, Reviews, traductions) ; au moins 3 ans d'expérience |
Dépendances et risques
| Facteur | Influence sur la certification |
|---|---|
| Acceptation communautaire | Sans utilisation large du GCBoK comme ouvrage de référence, aucune demande de certification |
| Maturité des outils | Webstatic, OPA, l'outillage OSCAL doivent être stables et documentés |
| Écosystème de partenaires | Partenariats BSI/ENISA (Roadmap Phase 3) comme ancre de crédibilité |
| Cadre juridique | Les schémas de certification en DE/UE nécessitent une accréditation (DAkkS ou équivalent) |
Prochaines étapes (provisoire)
- Recueillir le feedback de la communauté (Gitea Issues, Discussions) — y a-t-il un besoin ?
- Élaborer et examiner des Pilot-Competencies pour 2–3 axes (p. ex. 02, 04, 05)
- Atelier Learning Outcomes avec des formateurs/examinateurs potentiels
- Outillage d'évaluation prototypique (basé sur webstatic ? export OSCAL ?)
- Décision : poursuite uniquement en cas d'écho communautaire positif
Références
- ISO/IEC 24773:2019 — Software and systems engineering — Certification of software and systems engineering professionals
- GCBoK chapitre 00 (Index) — Positionnement en tant que 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