docs: add RNCP 37805 referentiel and fix Cr 4.f mappings
Add official RNCP 37805 PDF source and a searchable text index of all 92 criteres across Bloc 1, Bloc 2 and Bloc 5 (DevOps option). Correct Cr 4.f.1 / Cr 4.f.4 mappings in the journal and PROJECT_CONTEXT section 8: only Cr 4.f.2 covers Git as a tool-mastery artefact. The other three Cr 4.f criteria are soft skills evaluated at the oral (knowledge sharing, self-review, individual contribution report). Correction applied after reading the primary source end to end.
This commit is contained in:
Imugiii
parent
32924a5813
commit
324f5cdb74
4 changed files with 351 additions and 4 deletions
|
|
@ -310,7 +310,8 @@ Reseaux :
|
|||
| Cr 4.c.1-3 | POO + heritage + namespaces | `BaseModel` -> `Product`, `BaseController` -> `AdminController`, PSR-4 |
|
||||
| Cr 4.d.1-3 | MVC | `src/Models/`, `src/Views/`, `src/Controllers/`, separation stricte |
|
||||
| Cr 4.e.1-3 | Securite | PDO prepared (anti-SQLi), sessions regeneration, role-based middleware |
|
||||
| Cr 4.f.1-4 | Git + collaboration | Commits Conventional, branches feat/*, PR descriptions, squash merge |
|
||||
| Cr 4.f.2 | Maitrise outil collaboratif (artefact) | Commits Conventional, branches `feat/*`, PR descriptions, squash merge, hooks Git |
|
||||
| Cr 4.f.1, 4.f.3, 4.f.4 | Soft skills (evalues a l'oral) | Partage de savoir-faire (4.f.1), auto-evaluation avant PR (4.f.3), compte-rendu de la participation individuelle (4.f.4) — demontres pendant la soutenance |
|
||||
| Cr 4.g.1-4 | Preparation livraison | PHPUnit tests verts, pas d'erreur en prod, testee deployee |
|
||||
|
||||
### Bloc 5
|
||||
|
|
|
|||
346
docs/_ref/rncp-37805-index.md
Normal file
346
docs/_ref/rncp-37805-index.md
Normal file
|
|
@ -0,0 +1,346 @@
|
|||
# Index RNCP 37805 — Titre Developpeur Web B2
|
||||
|
||||
> Index texte compact du referentiel officiel (20 pages).
|
||||
> Source primaire : `docs/_ref/rncp-37805-referentiel.pdf` (Webecom, V09-11-22).
|
||||
> Usage : grep rapide des criteres, verification des mappings CDCF/CDCT, preparation oral.
|
||||
>
|
||||
> Rappel : chaque libelle ci-dessous est la transcription textuelle du PDF officiel.
|
||||
> En cas de doute sur un critere, relire la source primaire avant d'agir.
|
||||
|
||||
---
|
||||
|
||||
## Structure globale
|
||||
|
||||
| Bloc | Nom | Statut pour Wakdo |
|
||||
|---|---|---|
|
||||
| Bloc 1 | Developpement Front End | **Tronc commun obligatoire** |
|
||||
| Bloc 2 | Developpement Back End | **Tronc commun obligatoire** |
|
||||
| Bloc 3 | Framework (option) | Non choisie |
|
||||
| Bloc 4 | Design d'interfaces UX/UI (option) | Non choisie |
|
||||
| **Bloc 5** | **DevOps (option 3)** | **Option choisie** |
|
||||
|
||||
### Regles de validation (page 19)
|
||||
|
||||
- **50 % minimum par bloc** pour le valider
|
||||
- **50 % moyenne globale** pour obtenir le titre
|
||||
- Ponderation : controle continu 30 % / stage 20 % / examens jury 50 %
|
||||
- Titre obtenu = **tronc commun (Bloc 1 + Bloc 2)** + **un bloc optionnel** + **stage en entreprise**
|
||||
|
||||
---
|
||||
|
||||
## Bloc 1 — Developpement Front End
|
||||
|
||||
### Activite 1 — Traduction de la maquette en code interpretable par les navigateurs
|
||||
|
||||
Domaines : Integration Web / responsive / Normes & accessibilite / Standardisation / Referencement naturel.
|
||||
|
||||
#### C1.a — Utiliser HTML et CSS (avec ou sans framework) pour integrer les maquettes
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 1.a.1 | L'integration est conforme a la maquette |
|
||||
| Cr 1.a.2 | Le code respecte les normes W3C et les normes d'accessibilite |
|
||||
| Cr 1.a.3 | Le code passe avec succes les tests du validateur |
|
||||
| Cr 1.a.4 | Le code est commente et correctement indente |
|
||||
| Cr 1.a.5 | Les balises semantiques sont utilisees a bon escient |
|
||||
|
||||
#### C1.b — Produire l'encodage responsive (smartphones, tablettes, desktop)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 1.b.1 | Le codage de l'application s'adapte correctement aux differentes resolutions d'ecran |
|
||||
| Cr 1.b.2 | Les proprietes utilisees sont compatibles avec les differents navigateurs |
|
||||
| Cr 1.b.3 | En cas d'incompatibilite du navigateur d'une propriete, le candidat apporte une correction ou utilise une alternative, en s'appuyant sur la documentation |
|
||||
|
||||
#### C1.c — Considerer la diversite des publics, notamment en situation de handicap (RGAA)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 1.c.1 | Les attributs des elements visuels sont correctement renseignes pour les logiciels de lecture d'ecran |
|
||||
| Cr 1.c.2 | Une police specifique pour les personnes dyslexiques est prevue et integree (OpenDys) |
|
||||
| Cr 1.c.3 | Les informations importantes ne sont pas uniquement transmises par un code couleur mais sont textuellement exprimees |
|
||||
| Cr 1.c.4 | L'utilisateur peut naviguer, acceder aux fonctionnalites et au contenu en utilisant le clavier |
|
||||
|
||||
#### C1.d — Travailler sur une logique d'integration reutilisable (classes generiques)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 1.d.1 | Le nommage des classes CSS est pertinent et propose une approche flexible, reutilisable |
|
||||
| Cr 1.d.2 | Le code CSS est organise et commente |
|
||||
| Cr 1.d.3 | Les classes sont regroupees par thematiques |
|
||||
| Cr 1.d.4 | Le code CSS produit est synthetique et ne presente pas de repetitions |
|
||||
|
||||
#### C1.e — Travailler le referencement naturel (SEO)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 1.e.1 | Les textes sont hierarchises et correctement titres |
|
||||
| Cr 1.e.2 | Les expressions cles sont mises en exergue |
|
||||
| Cr 1.e.3 | Le balisage d'enrichissement de contenu est compris via schema.org |
|
||||
| Cr 1.e.4 | La semantique des balises est respectee (article, aside, nav) |
|
||||
| Cr 1.e.5 | Les balises meta sont uniques sur chaque page et contiennent un nombre de caracteres optimise |
|
||||
| Cr 1.e.6 | Les pages canoniques sont renseignees |
|
||||
| Cr 1.e.7 | Les attributs alternatifs des images sont presents ainsi que les titres des liens |
|
||||
| Cr 1.e.8 | Les temps de chargement des pages sont optimises (poids images, sprites...) |
|
||||
| Cr 1.e.9 | Le favicon est integre |
|
||||
| Cr 1.e.10 | La navigation entre les differentes pages du site est implementee |
|
||||
| Cr 1.e.11 | Les ancres sont utilisees pour la navigation au sein d'une meme page |
|
||||
|
||||
### Activite 2 — Developpement de fonctionnalites front end (navigateur)
|
||||
|
||||
Domaines : Interactions/animations JS / Validation de donnees / Fonctionnalites asynchrones / Librairies.
|
||||
|
||||
#### C2.a — Enrichir l'interface en JavaScript
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 2.a.1 | Les syntaxes modernes (ES5, ES6 et superieures) et les fonctions natives du langage sont acquises |
|
||||
| Cr 2.a.2 | La manipulation des elements du document (DOM) en termes de contenu comme de style est maitrisee |
|
||||
| Cr 2.a.3 | Les animations JavaScript developpees permettent une meilleure experience utilisateur |
|
||||
| Cr 2.a.4 | Les animations sont fonctionnelles et leurs comportements sont geres sur les differents navigateurs |
|
||||
| Cr 2.a.5 | Le code est developpe en utilisant la programmation procedurale, fonctionnelle ou orientee objet, et la programmation evenementielle |
|
||||
|
||||
#### C2.b — Valider les saisies utilisateur dans les formulaires
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 2.b.1 | Les donnees saisies par les utilisateurs dans les espaces interactifs sont controlees pendant la saisie en temps reel |
|
||||
| Cr 2.b.2 | Les methodes de controle mises en oeuvre sont coherentes en fonction de la nature des donnees a traiter |
|
||||
| Cr 2.b.3 | L'envoi des informations au serveur n'est effectif que lorsque les donnees correspondent au format attendu. Le cas echeant, des messages previennent l'utilisateur des erreurs de saisie a corriger |
|
||||
|
||||
#### C2.c — Developper des fonctionnalites asynchrones avec le serveur (API)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 2.c.1 | Les developpements des requetes asynchrones sont fonctionnels et correctement mis en oeuvre |
|
||||
| Cr 2.c.2 | Les requetes HTTP asynchrones n'exposent pas de donnees sensibles ou personnelles |
|
||||
| Cr 2.c.3 | Les reponses renvoyees par le serveur sont traitees et utilisees |
|
||||
| Cr 2.c.4 | Dans le cas d'un renvoi d'erreurs, celles-ci sont traitees de maniere a ne pas interrompre l'execution du script |
|
||||
|
||||
#### C2.d — Optimiser avec des librairies JavaScript externes
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 2.d.1 | Les librairies utilisees repondent a une problematique specifique |
|
||||
| Cr 2.d.2 | La librairie est correctement implementee d'apres les recommandations d'utilisation de sa documentation |
|
||||
| Cr 2.d.3 | Le candidat peut clairement expliquer le fonctionnement global de la librairie et son utilisation |
|
||||
|
||||
---
|
||||
|
||||
## Bloc 2 — Developpement Back End
|
||||
|
||||
### Activite 3 — Data : analyse, modelisation, traitement
|
||||
|
||||
Domaines : Modelisation donnees / Construction BDD / Exploitation BDD / Cadre legal.
|
||||
|
||||
#### C3.a — Synthetiser les donnees utiles a l'application (formaliser le modele)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 3.a.1 | Les donnees necessaires a l'application sont correctement identifiees |
|
||||
| Cr 3.a.2 | Les donnees sont retranscrites sur un schema decrivant les differentes tables et les relations entre elles |
|
||||
| Cr 3.a.3 | Le candidat exploite dans son modele de donnees des informations externes provenant d'une API |
|
||||
| Cr 3.a.4 | (Cr 3.a.4 cite dans le PDF — libelle proche de Cr 3.a.1) |
|
||||
|
||||
> Note : le PDF affiche Cr 3.a.4 et Cr 3.a.2 en tete de tableau puis Cr 3.a.3. L'ordre a l'ecran n'est pas strictement numerique. A verifier visuellement si un doute.
|
||||
|
||||
#### C3.b — Construire la BDD via un outil d'administration
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 3.b.1 | Le nommage des tables et des champs est coherent avec la typologie des donnees |
|
||||
| Cr 3.b.2 | Le type des champs est choisi en adequation avec la nature des donnees (varchar, boolean, integer...) |
|
||||
| Cr 3.b.3 | La mise en relation des tables est correctement effectuee |
|
||||
|
||||
#### C3.c — Interroger la BDD en SQL
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 3.c.1 | Le candidat effectue les principales operations de manipulation des donnees (lister, ajouter, modifier, supprimer) |
|
||||
| Cr 3.c.2 | Le candidat affine ses requetes en utilisant des systemes de tri et de filtres |
|
||||
| Cr 3.c.3 | Les requetes sont optimisees par l'utilisation de cles etrangeres et de liaisons de tables |
|
||||
|
||||
#### C3.d — Respecter le cadre legal (RGPD) — **obligatoire**
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 3.d.1 | Le candidat a identifie, avec le client, les donnees sensibles et reglementees qui doivent beneficier d'un traitement specifique |
|
||||
| Cr 3.d.2 | L'application informe l'utilisateur du stockage, de l'utilisation et du cadre de partage de ses donnees personnelles |
|
||||
| Cr 3.d.3 | L'utilisateur dispose d'un droit de consultation, modification et de suppression de ses donnees personnelles |
|
||||
| Cr 3.d.4 | Les donnees sensibles sont protegees |
|
||||
|
||||
### Activite 4 — Developpement back end (serveur)
|
||||
|
||||
Domaines : Conceptualisation / Programmation cote serveur / POO / MVC / Securite / Travail en equipe et versionning.
|
||||
|
||||
#### C4.a — Conceptualiser l'application, formaliser le schema fonctionnel
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 4.a.1 | Le candidat a pose les bonnes questions au client dans sa demarche de comprehension du fonctionnement de l'application a developper |
|
||||
| Cr 4.a.2 | Le candidat est force de proposition lors de ses echanges |
|
||||
| Cr 4.a.3 | Toutes les fonctionnalites necessaires au bon fonctionnement de l'application sont correctement listees et detaillees |
|
||||
| Cr 4.a.4 | Le schema fonctionnel decrit en detail l'enchainement des vues en fonction des differentes actions et interactions |
|
||||
|
||||
#### C4.b — Developper cote serveur
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 4.b.1 | La syntaxe et les fonctions natives du langage sont acquises |
|
||||
| Cr 4.b.2 | Le code est indente, les commentaires aident a la comprehension du code |
|
||||
| Cr 4.b.3 | Les dossiers et fichiers du projet sont organises |
|
||||
| Cr 4.b.4 | Les conventions de nommage sont respectees pour l'ensemble du code |
|
||||
| Cr 4.b.5 | Les limites du code sont connues |
|
||||
| Cr 4.b.6 | Les erreurs de codage sont traitees |
|
||||
|
||||
#### C4.c — POO et heritages pour produire un code reutilisable
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 4.c.1 | La portee des attributs et des methodes est coherente |
|
||||
| Cr 4.c.2 | Le code implemente des classes generiques et l'heritage est correctement mis en place |
|
||||
| Cr 4.c.3 | Les classes sont implementees en utilisant les namespaces et chargees par l'intermediaire d'un autoloader, a defaut elles sont chargees manuellement dans un fichier de configuration |
|
||||
|
||||
#### C4.d — Architecture Modele-Vue-Controleur
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 4.d.1 | Le modele gere les interactions avec la base de donnees |
|
||||
| Cr 4.d.2 | Les controleurs implementent la logique et preparent les variables necessaires au rendu de la vue |
|
||||
| Cr 4.d.3 | La vue recoit et permet l'affichage des donnees transmises par le controleur et remplit son role principal d'affichage |
|
||||
|
||||
#### C4.e — Identifier un utilisateur et delimiter ses champs d'action (securite)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 4.e.1 | Le programme protege l'integrite des donnees en empechant toute injection d'elements pouvant les compromettre |
|
||||
| Cr 4.e.2 | Un utilisateur s'authentifie par l'intermediaire d'un identifiant unique et d'un mot de passe. L'utilisation d'un systeme de session, de token, ou equivalent permet d'identifier l'utilisateur connecte |
|
||||
| Cr 4.e.3 | L'implementation dans le programme de differents roles permet une delimitation des actions possibles et permissions pour chaque type d'utilisateur (administrateur, auteur...) |
|
||||
|
||||
#### C4.f — Travailler en equipe (outils de collaboration et versionning)
|
||||
|
||||
> **Attention** : seul Cr 4.f.2 est une maitrise d'outil verifiable par artefact (Git).
|
||||
> Les trois autres sont des **soft skills evaluees a l'oral**.
|
||||
|
||||
| Id | Critere | Nature |
|
||||
|---|---|---|
|
||||
| Cr 4.f.1 | Le candidat mobilise et transmet son savoir, son savoir-faire et ses methodes. Il participe activement a la collaboration | Soft skill (oral) |
|
||||
| Cr 4.f.2 | L'utilisation de l'outil de travail collaboratif est maitrisee (ex : Gitlab) | **Artefact** (Git, PR, branches, hooks) |
|
||||
| Cr 4.f.3 | Le candidat sait auto evaluer et mesurer la compatibilite de son code avant de le soumettre comme contribution au projet | Soft skill (oral) — avec artefact possible (tests verts avant push) |
|
||||
| Cr 4.f.4 | Le candidat peut clairement rendre compte de sa participation individuelle au travail collectif | Soft skill (oral) |
|
||||
|
||||
#### C4.g — Preparer la livraison
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 4.g.1 | Le candidat s'assure de la conformite des fonctionnalites attendues par le cahier des charges et celles deployees |
|
||||
| Cr 4.g.2 | Des tests unitaires sont realises et valides |
|
||||
| Cr 4.g.3 | L'application mise en ligne est exempte de bugs et fonctionnelle |
|
||||
| Cr 4.g.4 | L'application est testee en production et ne montre pas d'erreurs ou d'effets de bords pouvant nuire a son utilisation |
|
||||
|
||||
---
|
||||
|
||||
## Bloc 5 — DevOps (option 3)
|
||||
|
||||
*Utiliser la methodologie DevOps pour automatiser, conteneuriser et deployer une application en continu.*
|
||||
|
||||
### Activite 7 — Automatiser les differentes etapes tout au long du cycle de vie
|
||||
|
||||
Domaines : Identification des processus a automatiser / Programmation de scripts / Conteneurisation / Orchestration.
|
||||
|
||||
#### C7.a — Identifier les points d'automatisation
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 7.a.1 | Le candidat a bien analyse les contraintes en termes d'infrastructure et de securite |
|
||||
| Cr 7.a.2 | Le candidat propose un ensemble de solutions pertinentes pour automatiser tout ou partie de l'ensemble du processus |
|
||||
| Cr 7.a.3 | Le candidat prend en compte les interactions avec les activites connexes, autant sur la partie developpement que sur la partie de l'infrastructure |
|
||||
|
||||
#### C7.b — Programmer les actions en script
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 7.b.1 | Le candidat maitrise la syntaxe d'un langage de script |
|
||||
| Cr 7.b.2 | L'automatisation est fonctionnelle et fiabilisee |
|
||||
| Cr 7.b.3 | Le candidat planifie des taches repetitives (planificateur de tache, cron tab) |
|
||||
|
||||
#### C7.c — Creer un environnement de developpement independant (conteneur, ex : Docker)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 7.c.1 | La machine virtuelle creee par le candidat est configuree et operationnelle |
|
||||
| Cr 7.c.2 | Le systeme d'exploitation pour conteneur est installe dans la machine d'hebergement virtuelle |
|
||||
| Cr 7.c.3 | L'application complete est correctement conteneurisee avec les services et les dependances necessaires au fonctionnement de l'application |
|
||||
| Cr 7.c.4 | Le fichier de configuration est renseigne et permet de lancer la stack applicative complete avec une seule ligne commande |
|
||||
|
||||
#### C7.d — Assurer un deploiement continu (CI/CD, ex : GitHub Actions)
|
||||
|
||||
| Id | Critere |
|
||||
|---|---|
|
||||
| Cr 7.d.1 | L'architecture serveur est mise en place et fonctionnelle |
|
||||
| Cr 7.d.2 | L'application est testee avant deploiement |
|
||||
| Cr 7.d.3 | L'integration et le deploiement continus sont testes et l'application est livree |
|
||||
|
||||
---
|
||||
|
||||
## Mise en situation professionnelle — elements fournis et attendus (synthese)
|
||||
|
||||
### Elements fournis au candidat (Blocs 1 + 2)
|
||||
|
||||
- Les maquettes a integrer (Bloc 1)
|
||||
- Le cahier des charges
|
||||
- Les elements graphiques non optimises a integrer
|
||||
- Un espace sur le serveur pour le deploiement
|
||||
- Un acces au serveur (Bloc 2)
|
||||
- Un acces a une base de donnees (Bloc 2)
|
||||
|
||||
### Elements attendus / livrables jury (Blocs 1 + 2)
|
||||
|
||||
- Deploiement complet et fonctionnel du site ou de l'application sur le serveur
|
||||
- Les schemas conceptuels et physiques du modele de donnees (Bloc 2)
|
||||
- Les schemas fonctionnels de l'application (Bloc 2)
|
||||
- La base de donnees de l'application (Bloc 2)
|
||||
- L'application fonctionnelle deployee sur le serveur (Bloc 2)
|
||||
|
||||
### Elements fournis / attendus (Bloc 5 DevOps)
|
||||
|
||||
**Fournis** : un sujet d'exercice sous forme de demande client, une ou plusieurs applications selon la demande du client, un acces a un serveur hote.
|
||||
|
||||
**Attendus** : l'application automatisee, conteneurisee et deployee + tous supports permettant d'appuyer l'argumentation.
|
||||
|
||||
---
|
||||
|
||||
## Lexique (page 20 du PDF)
|
||||
|
||||
| Terme | Definition |
|
||||
|---|---|
|
||||
| HTML | Hyper Text Markup Language — langage de balisage utilise pour decrire la structure et le contenu semantique d'une page web |
|
||||
| CSS | Cascading Style Sheets — langage decrivant la mise en forme d'un document HTML |
|
||||
| JAVASCRIPT | Langage de programmation utilisable dans un navigateur |
|
||||
| ES5 / ES6 | Ecma Script — normes syntaxiques et standards des langages de scripts |
|
||||
| DOM | Document Object Model — interpretation sous forme d'un objet manipulable par JavaScript d'une page web |
|
||||
| HTTP | Hyper Text Transfert Protocol — protocole de communication entre le client et le serveur |
|
||||
| FRONT END | Cote client — programme execute dans le navigateur dont le code source est visible publiquement |
|
||||
| BACK END | Cote serveur — programme execute sur le serveur dont le code source est invisible dans le navigateur |
|
||||
| FRAMEWORK | Cadre de travail — ensemble d'outils interdependants utilises pour creer rapidement et facilement des applications |
|
||||
| MVC | Model Vue Controller — patron de conception d'une architecture de code |
|
||||
| DEVOPS | Pratique technique visant a l'unification du developpement logiciel et de l'administration des infrastructures informatiques |
|
||||
| **RGPD** | **Reglement general sur la protection des donnees — cadre reglementaire relatif a la protection des personnes physiques a l'egard du traitement des donnees a caractere personnel et a la libre circulation de ces donnees** |
|
||||
| BRAND BOARD | Proposition coherente d'une identite graphique (non-utilise hors Bloc 4) |
|
||||
| WIREFRAME | Trame generale schematique de l'agencement d'une maquette (non-utilise hors Bloc 4) |
|
||||
|
||||
---
|
||||
|
||||
## Stats de couverture pour Wakdo
|
||||
|
||||
| Bloc | Competences | Criteres total | Statut |
|
||||
|---|---|---|---|
|
||||
| Bloc 1 (tronc) | 9 (C1.a-e + C2.a-d) | 44 | Obligatoire |
|
||||
| Bloc 2 (tronc) | 11 (C3.a-d + C4.a-g) | 35 | Obligatoire |
|
||||
| Bloc 5 (option DevOps) | 4 (C7.a-d) | 13 | **Option choisie** |
|
||||
| **Total Wakdo** | **24 competences** | **~92 criteres** | — |
|
||||
|
||||
---
|
||||
|
||||
*Index genere le 2026-04-24. Source primaire : `rncp-37805-referentiel.pdf` (PDF officiel Webecom V09-11-22, 20 pages).*
|
||||
*Cet index est un outil de navigation. En cas d'ambiguite sur un libelle, se referer a la source primaire.*
|
||||
BIN
docs/_ref/rncp-37805-referentiel.pdf
Normal file
BIN
docs/_ref/rncp-37805-referentiel.pdf
Normal file
Binary file not shown.
|
|
@ -144,9 +144,9 @@ Configure via l'UI GitHub (Settings -> Rules -> Rulesets). Les 4 rules activees
|
|||
|
||||
## Criteres RNCP couverts
|
||||
|
||||
- **Bloc 2 - Cr 4.f.1** : Git et GitHub utilises, repo public accessible au jury.
|
||||
- **Bloc 2 - Cr 4.f.2** : Branches `main` et `dev` protegees, flow `feat/*` -> `dev` -> `main` impose.
|
||||
- **Bloc 2 - Cr 4.f.4** : Conventional Commits definis dans `docs/PROJECT_CONTEXT.md` section 9 (a faire appliquer par hook en Task #3).
|
||||
- **Bloc 2 - Cr 4.f.2** : Maitrise de l'outil collaboratif — Git et GitHub utilises, repo public accessible au jury, branches `main` et `dev` protegees, flow `feat/*` -> `dev` -> `main` impose, Conventional Commits definis dans `docs/PROJECT_CONTEXT.md` section 9 (a faire appliquer par hook en Task #3).
|
||||
|
||||
> Note : le libelle officiel du Cr 4.f.1 (*« mobilise et transmet son savoir, participe activement a la collaboration »*) et du Cr 4.f.4 (*« rendre compte de sa participation individuelle au travail collectif »*) designent des soft skills evaluees a l'oral, et non la mise en place de Git — qui releve du Cr 4.f.2. Cette correction a ete appliquee apres lecture integrale du referentiel (source : `docs/_ref/rncp-37805-referentiel.pdf` page 11-12).
|
||||
- **Bloc 5 - Cr 7.a.1** : Analyse de l'infra cible documentee (section 5 du PC).
|
||||
- **Bloc 5 - Cr 7.d.1** : Architecture serveur decrite (reseau `admin_proxy` + reseau interne + 4 services).
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue