Choisir tes deux réalisations professionnelles

Une réalisation professionnelle, à l'E6, est une application ou une partie d'application que tu as conçue et développée pendant ta formation : en atelier de professionnalisation, en stage ou en projet. Tu en présentes deux, et la commission en choisit une pour écrire ton sujet. Ce chapitre explique les règles qu'elles doivent respecter, comment les choisir pour qu'elles couvrent tout le bloc 2, et comment les construire pour qu'elles se prêtent à une évolution le jour de l'épreuve.

Les quatre règles officielles

Les candidats qui se présentent au titre de leur expérience professionnelle construisent leurs situations à partir de leur activité en entreprise.

Seul ou en équipe

La fiche descriptive prévoit les deux modalités : « seul(e) » ou « en équipe ». Une réalisation d'équipe est acceptée. Mais l'heure de réalisation est individuelle, et la commission peut écrire un besoin qui touche n'importe quelle partie de l'application. Si ton binôme a codé le front, tu dois être capable de le lire, de le lancer et de le modifier. Sur la fiche, décris précisément ta part.

L'environnement technologique exigé

L'annexe II.E du référentiel décrit l'environnement dans lequel tes réalisations doivent être construites. Sa partie commune (service d'authentification, SGBD, sauvegarde, deux serveurs dont un libre, deux types de terminaux dont un mobile, outils de sécurité) dépend surtout de ton établissement. Sa partie SLAM dépend de tes choix :

• un ou deux environnements de développement avec des outils de gestion de tests, un framework et au moins deux langages ;
• une bibliothèque de composants logiciels ;
• un SGBD avec un langage de programmation associé (procédures stockées, triggers) ;
• un logiciel de gestion de versions et de suivi des problèmes (Git et les tickets d'une forge) ;
• une solution pour tester les comportements anormaux d'une application ;
• au moins deux solutions applicatives opérationnelles qui offrent un accès sécurisé à des données hébergées sur un site distant ;
• dans leurs architectures, des appels à des services applicatifs distants et au moins trois de ces quatre situations : du code exécuté sur un poste fixe (client lourd), dans un navigateur, sur un terminal mobile, sur un serveur.

Vérifie le dernier point dès ta 1re année. Deux applications Web en PHP rendu côté serveur ne font que deux situations : navigateur et serveur. Ajoute un client lourd (C# et Windows Forms), une application mobile (Développement mobile), ou un front (React) qui appelle une API (Node.js et Express). Une application PHP rendue côté serveur, avec PDO (PHP et MySQL), reste un très bon premier projet : il lui faut seulement un compagnon d'une autre situation.

Choisir les deux bonnes réalisations

Une bonne réalisation d'E6 n'est pas la plus impressionnante. C'est celle sur laquelle tu peux réussir une évolution en une heure. Passe chaque candidate à ces six questions.

Construire une réalisation qui se prête à une évolution

Tu ne sais pas ce que la commission demandera, mais tu peux rendre ton application facile à faire évoluer.

• Une architecture en couches lisible. Routes, contrôleurs, accès aux données, vues : chaque chose à sa place. Le jour J, tu dois trouver le bon fichier en dix secondes. Le cours Architecture MVC t'aide à choisir la tienne.
• Des requêtes préparées partout. C'est la condition pour ajouter un filtre sans ouvrir une faille (cours SQL).
• Au moins un test automatisé qui tourne, et la commande pour le lancer dans le README. Ajouter un test pendant l'épreuve prend cinq minutes quand l'outillage existe, trente quand il n'existe pas (cours Tests).
• Un script de création de la base et un jeu d'essai réaliste : des comptes de chaque rôle, des données dans chaque état, des cas limites (une note vide, un logiciel libre sans licence).
• Un README qui dit comment lancer le projet de zéro, en moins de dix lignes.
• Un historique Git propre, avec un message par étape (cours Git et GitHub).

La matrice de couverture

La matrice de couverture croise les 20 sous-compétences du bloc 2 avec tes deux réalisations. Elle te dit ce qui manque pendant qu'il est encore temps de l'ajouter, et elle prépare tes fiches descriptives. Recopie ce modèle et remplis-le dès que ta première réalisation existe.

Dans chaque case, écris une preuve précise, pas une croix : « ParcDao.cs, requêtes paramétrées » vaut mieux que « oui ». Une case que tu ne sais pas justifier est une case vide.

Exercice corrigé : la matrice de Lina

Exercice Remplir la matrice et trouver les trous Réussi À revoir

Lina, étudiante en 2e année SLAM, présentera ces deux réalisations, faites pour l'entreprise fictive Sorbier Logistique.

Réalisation 1, GestParc (1re année, atelier de professionnalisation, d'avril à juin, seule). Application de bureau C# WinForms (.NET 10) pour le service informatique. Elle gère les postes, les logiciels et leurs installations. Base MySQL 8.4 de 7 tables, modélisée en MCD puis en MLD. Accès aux données par MySqlConnector, avec des requêtes paramétrées dans des classes DAO. Une procédure stockée affecte un poste à un employé. Un écran de recherche filtre les postes. Tests : un cahier de recette manuel de 15 cas. Un guide utilisateur de 6 pages. Dépôt Git de 48 commits.

Réalisation 2, Sorbier Frais (2e année, ateliers de professionnalisation, d'octobre à février, en binôme : Lina a fait l'API et la base, son binôme le front). Application web de notes de frais : API REST Node.js 24 et Express 5, front React, base MySQL 8.4. Authentification par jeton JWT, deux rôles (salarié, comptable). 31 tests Vitest et supertest lancés par GitHub Actions à chaque push. README technique et documentation de l'API. Version 1.1 : correction d'un bug de filtre par date signalé dans le ticket n° 12, notée dans le CHANGELOG. Un compte MySQL applicatif limité à SELECT, INSERT et UPDATE. Une sauvegarde mysqldump chaque nuit.

1. Remplis la matrice de couverture de Lina.
2. Trouve les sous-compétences mal couvertes et propose, pour chacune, un ajout réaliste d'ici le dépôt du dossier.
3. Ses deux réalisations respectent-elles le point 3.2 de l'annexe II.E (trois situations, appel de service distant) ?
4. Quel risque crée le travail en binôme, et comment le réduire ?

Voir la réponseMasquer la réponse de l'exercice

1. La matrice. R1 = GestParc, R2 = Sorbier Frais.

Sous-compétence	R1	R2	Preuve
Analyser un besoin et son contexte juridique	oui	partiel	cahiers des charges ; rien n'est écrit sur les données personnelles de R2
Participer à la conception de l'architecture	oui	oui	schéma 3 tiers de R2
Modéliser une solution applicative	oui	oui	MCD et MLD de R1, MLD de R2
Exploiter les ressources du framework	oui	oui	WinForms ; Express et React
Identifier, développer, utiliser ou adapter des composants	oui	oui	classes DAO ; middleware d'authentification, bibliothèques bcrypt et jsonwebtoken
Échanges entre applications par les technologies Web	non	oui	API REST JSON appelée par le front
Utiliser des composants d'accès aux données	oui	oui	MySqlConnector ; mysql2
Intégrer en continu les versions	partiel	oui	GitHub Actions lance les tests à chaque push
Réaliser les tests de validation	oui	oui	cahier de recette ; 31 tests automatisés
Rédiger des documentations	oui	oui	guide utilisateur ; README et doc de l'API
Exploiter un environnement de développement et de tests	oui	oui	Visual Studio ; VS Code, Vitest
Recueillir et mettre à jour les informations sur une version	non	oui	ticket n° 12, CHANGELOG 1.1
Évaluer la qualité	non	non	aucune trace
Analyser et corriger un dysfonctionnement	non	oui	correction du ticket n° 12
Mettre à jour des documentations	non	partiel	CHANGELOG oui, README pas mis à jour
Tester les éléments mis à jour	non	à vérifier	un test de non-régression a-t-il accompagné la correction ?
Exploiter des données avec un langage de requêtes	oui	oui	requêtes de recherche, jointures
Développer des fonctionnalités au sein d'un SGBD	oui	non	procédure stockée d'affectation
Concevoir ou adapter une base	oui	oui	base parc ; base frais
Administrer et déployer une base	non	partiel	compte limité et sauvegarde, mais aucun test de restauration

2. Les trous et les ajouts.

• Évaluer la qualité : rien. Ajouter ESLint à R2, corriger ses alertes et noter dans le CHANGELOG ce que la refactorisation a changé (une fonction de calcul dupliquée dans deux contrôleurs, regroupée dans un module testé).
• Administrer et déployer une base : la sauvegarde existe, sa restauration n'a jamais été testée. Restaurer le dump de la nuit sur une base frais_test, compter les lignes des tables, écrire la procédure dans la documentation.
• Contexte juridique : ajouter à R2 une page sur les données personnelles (qui voit quelle note, durée de conservation des justificatifs, comptes supprimés au départ du salarié). Le cours Droit et RGPD donne les règles.
• Tester les éléments mis à jour : si la correction du ticket n° 12 n'a pas de test, en écrire un qui échoue avec l'ancien code et passe avec le nouveau, et mettre le README à jour.

Après ces ajouts, chaque sous-compétence a au moins une preuve.

3. L'annexe II.E. Oui. GestParc est un client lourd, Sorbier Frais a du code dans le navigateur (React) et sur un serveur (l'API) : trois situations sur quatre. L'appel du front à l'API REST est un appel à un service applicatif distant. Les deux applications accèdent à des données hébergées sur un serveur, avec des comptes et des droits. La procédure stockée de GestParc montre un SGBD avec langage de programmation.

4. Le binôme. La commission peut demander une évolution qui touche le front React, que Lina n'a pas écrit. Elle doit lire tout le code du front, savoir le lancer, et refaire seule une petite évolution d'écran avant l'épreuve, par exemple un filtre sur la liste des notes. Sur la fiche, elle coche « en équipe » et précise sa part.

Tu avais trouvé ?

Oui, j'avais bonPas encore