diff --git a/docs/PROJECT_CONTEXT.md b/docs/PROJECT_CONTEXT.md index b6285c1..7dfdb46 100644 --- a/docs/PROJECT_CONTEXT.md +++ b/docs/PROJECT_CONTEXT.md @@ -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 diff --git a/docs/_ref/rncp-37805-index.md b/docs/_ref/rncp-37805-index.md new file mode 100644 index 0000000..d73d36c --- /dev/null +++ b/docs/_ref/rncp-37805-index.md @@ -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.* diff --git a/docs/_ref/rncp-37805-referentiel.pdf b/docs/_ref/rncp-37805-referentiel.pdf new file mode 100644 index 0000000..1a6c848 Binary files /dev/null and b/docs/_ref/rncp-37805-referentiel.pdf differ diff --git a/docs/journal/2026-04-23--cadrage-projet.md b/docs/journal/2026-04-23--cadrage-projet.md index 1643c8e..81976b8 100644 --- a/docs/journal/2026-04-23--cadrage-projet.md +++ b/docs/journal/2026-04-23--cadrage-projet.md @@ -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).