À propos du projet
Une plateforme web complète développée en Symfony conçue pour dématérialiser intégralement la gestion des conventions de stage. De la saisie des informations par l'étudiant jusqu'à la signature électronique certifiée par l'entreprise, tout est automatisé.
Conventio
09/2025
136 commits
Une convention complètement dématérialisée !
Technologies utilisées
PHP
JavaScript
Twig
Symfony
Bootstrap
MySQL
Docker
API Yousign
API Gotenberg
Connexion intelligente
Ce que ça fait : Un portail d'accès centralisé qui s'adapte automatiquement au type d'utilisateur (Étudiant, Professeur, Admin). Le parcours d'inscription est cloisonné : les étudiants sont autonomes, tandis que les professeurs attendent une validation manuelle. Sécurité critique : tant que l'administrateur n'a pas configuré les informations de l'établissement (indispensables aux conventions), l'accès à l'application est verrouillé pour tous les utilisateurs, à l'exception de l'administrateur lui-même. Une fois connecté, un système de routage intelligent dirige chaque profil vers son espace de travail dédié.
L'atout technique : Utilisation avancée du composant Security de Symfony avec l'implémentation d'un "Smart Routing" via un Authenticator personnalisé. La restriction d'accès liée à la configuration repose sur un Event Subscriber (CheckAdminSettingsSubscriber) qui intercepte chaque requête : il vérifie l'état des paramètres en base de données et redirige les utilisateurs non-admins vers une page d'attente si l'application n'est pas prête. L'architecture est blindée : hachage Argon2, protection anti-brute force (Rate Limiting), jetons CSRF et vérification d'e-mail par token.
L'atout technique : Utilisation avancée du composant Security de Symfony avec l'implémentation d'un "Smart Routing" via un Authenticator personnalisé. La restriction d'accès liée à la configuration repose sur un Event Subscriber (CheckAdminSettingsSubscriber) qui intercepte chaque requête : il vérifie l'état des paramètres en base de données et redirige les utilisateurs non-admins vers une page d'attente si l'application n'est pas prête. L'architecture est blindée : hachage Argon2, protection anti-brute force (Rate Limiting), jetons CSRF et vérification d'e-mail par token.
Le tableau de bord administrateur
Ce que ça fait : L'espace de travail d'un superviseur offre une vue d'ensemble immédiate sur les dossiers des étudiants. Un code couleur clair permet d'identifier instantanément le statut de chaque convention (En attente, Validé, Refusé, Signé). Depuis cet écran central, le professeur peut examiner en détail le sujet de stage et le valider ou le refuser en un seul clic, ce qui déclenche la suite du processus.
L'atout technique : Séparation stricte des données selon les droits d'accès (RBAC). Les requêtes Doctrine ORM sont finement optimisées pour ne remonter que les étudiants rattachés à la classe spécifique du professeur connecté. L'interface s'appuie sur Symfony UX (Turbo/Stimulus) pour offrir des interactions fluides et réactives, évitant les rechargements complets de page.
L'atout technique : Séparation stricte des données selon les droits d'accès (RBAC). Les requêtes Doctrine ORM sont finement optimisées pour ne remonter que les étudiants rattachés à la classe spécifique du professeur connecté. L'interface s'appuie sur Symfony UX (Turbo/Stimulus) pour offrir des interactions fluides et réactives, évitant les rechargements complets de page.
Tableau de bord de l'étudiant
Ce que ça fait : C'est l'espace central où l'élève suit l'avancement de son dossier de stage en temps réel. Il offre une vue claire et rassurante sur le statut exact de sa convention (en brouillon, en attente de validation par le professeur, en attente des informations de l'entreprise, ou en cours de signature). C'est depuis cet écran intuitif qu'il peut soumettre un nouveau sujet ou consulter les actions requises de sa part.
L'atout technique : L'interface repose sur des requêtes Doctrine ORM strictement filtrées par l'ID de l'utilisateur connecté pour garantir une isolation totale des données (Data Privacy). L'affichage dynamique des statuts exploite la puissance de Twig, couplé à une machine à états robuste (State Machine) en PHP pour sécuriser les transitions du cycle de vie de la convention, empêchant ainsi toute action illogique (comme signer une convention non validée).
L'atout technique : L'interface repose sur des requêtes Doctrine ORM strictement filtrées par l'ID de l'utilisateur connecté pour garantir une isolation totale des données (Data Privacy). L'affichage dynamique des statuts exploite la puissance de Twig, couplé à une machine à états robuste (State Machine) en PHP pour sécuriser les transitions du cycle de vie de la convention, empêchant ainsi toute action illogique (comme signer une convention non validée).
Tableau de bord professeur
Ce que ça fait : C'est le centre de contrôle dédié aux enseignants pour superviser leurs classes. D'un seul coup d'œil, grâce à un système visuel de badges de couleur, le professeur identifie le statut d'avancement des conventions de ses élèves (Sujet soumis, Validé, Refusé, En attente de signature). C'est depuis cette interface centralisée qu'il peut examiner les détails d'un sujet de stage et l'approuver ou le rejeter en un clic, ce qui déclenche automatiquement la suite du processus administratif.
L'atout technique : L'architecture repose sur un cloisonnement strict des données (RBAC - Role-Based Access Control). Les requêtes Doctrine ORM sont finement optimisées pour s'assurer qu'un professeur ne remonte depuis la base de données que les étudiants officiellement rattachés à ses propres classes. De plus, l'interface exploite Symfony UX pour offrir des interactions rapides (comme la validation d'un sujet) sans nécessiter de rechargement complet de la page.
L'atout technique : L'architecture repose sur un cloisonnement strict des données (RBAC - Role-Based Access Control). Les requêtes Doctrine ORM sont finement optimisées pour s'assurer qu'un professeur ne remonte depuis la base de données que les étudiants officiellement rattachés à ses propres classes. De plus, l'interface exploite Symfony UX pour offrir des interactions rapides (comme la validation d'un sujet) sans nécessiter de rechargement complet de la page.
Fonctionnement
Local
Ce que ça fait : Pour garantir des tests fiables et une démonstration fluide, l'application est exécutée dans un environnement local strict qui simule les conditions de la production. Pour éviter d'installer des logiciels lourds directement sur la machine, j'utilise Docker afin de virtualiser et démarrer instantanément les deux services annexes indispensables au projet : Gotenberg (le moteur de génération PDF) et un Serveur Mail local pour intercepter les e-mails.
L'atout technique :
- Le micro-service Gotenberg : L'application Symfony n'alourdit pas son propre code avec de la conversion complexe. Elle délègue cette tâche en envoyant une requête HTTP au conteneur Docker Gotenberg, qui agit comme une API distante dédiée à la conversion de fichiers Word (.docx) en PDF sécurisés.
- Le "Mail Catcher" sécurisé : Un conteneur Docker attrape tous les e-mails transactionnels générés par l'application (validation de compte, liens d'entreprises, notifications). Cela permet de tester toute la logique d'envoi et le design des templates e-mails de manière sécurisée, avec la garantie absolue de ne jamais "spammer" de vraies adresses e-mails par erreur lors des phases de tests.
L'atout technique :
- Le micro-service Gotenberg : L'application Symfony n'alourdit pas son propre code avec de la conversion complexe. Elle délègue cette tâche en envoyant une requête HTTP au conteneur Docker Gotenberg, qui agit comme une API distante dédiée à la conversion de fichiers Word (.docx) en PDF sécurisés.
- Le "Mail Catcher" sécurisé : Un conteneur Docker attrape tous les e-mails transactionnels générés par l'application (validation de compte, liens d'entreprises, notifications). Cela permet de tester toute la logique d'envoi et le design des templates e-mails de manière sécurisée, avec la garantie absolue de ne jamais "spammer" de vraies adresses e-mails par erreur lors des phases de tests.
Prérequis
Ce que ça fait : L'application intègre un système de prérequis stricts pour garantir la cohérence des documents générés. L'accès global reste verrouillé tant que l'administrateur n'a pas configuré les paramètres officiels de l'établissement. Ensuite, la logique métier impose deux conditions pour qu'un étudiant puisse initier une démarche : l'administration doit avoir défini les dates de stage de sa classe, et l'élève doit avoir complété son profil lors de sa première connexion. Ce n'est qu'une fois ces feux au vert que la collecte d'informations est débloquée.
Etablissement de la collecte
Ce que ça fait : Le processus est pensé pour être le plus simple possible. L'étudiant démarre sa démarche en entrant juste l'adresse e-mail de son tuteur, puis garde un œil sur l'avancement grâce aux statistiques de son tableau de bord. Du côté de l'entreprise, le tuteur reçoit un lien sécurisé par e-mail. Il accède ainsi à une interface épurée pour renseigner les données légales (SIRET, adresse...), le tout sans avoir besoin de se créer un compte sur l'application.
L'atout technique : Toute cette logique s'appuie sur la Machine à États (Workflow) de Symfony, qui orchestre et verrouille rigoureusement chaque étape de la convention. Le "Magic Link" envoyé à l'entreprise est sécurisé via la génération de tokens cryptographiques uniques. Lors de la saisie, l'intégrité des données est assurée par Symfony Validator. Enfin, les graphiques du tableau de bord étudiant sont alimentés par des requêtes Doctrine sur-mesure, garantissant un cloisonnement strict des données.
L'atout technique : Toute cette logique s'appuie sur la Machine à États (Workflow) de Symfony, qui orchestre et verrouille rigoureusement chaque étape de la convention. Le "Magic Link" envoyé à l'entreprise est sécurisé via la génération de tokens cryptographiques uniques. Lors de la saisie, l'intégrité des données est assurée par Symfony Validator. Enfin, les graphiques du tableau de bord étudiant sont alimentés par des requêtes Doctrine sur-mesure, garantissant un cloisonnement strict des données.
Espace professeur
Ce que ça fait : Le professeur dispose d'un tableau de bord optimisé pour identifier instantanément les requêtes en attente. En consultant un dossier, il accède à une synthèse structurée du stage (missions, horaires, informations légales) afin de prendre une décision éclairée : valider ou demander des corrections. L'interface offre ensuite un retour visuel immédiat confirmant la validation.
L'atout technique : L'architecture de cette section repose sur un cloisonnement rigoureux des données. Des requêtes Doctrine optimisées, couplées à une gestion des permissions (RBAC), filtrent les affichages par classe. La logique métier est quant à elle pilotée par la Machine à États de Symfony : ce composant sécurise le cycle de vie de la convention en empêchant toute action ou transition illogique.
L'atout technique : L'architecture de cette section repose sur un cloisonnement rigoureux des données. Des requêtes Doctrine optimisées, couplées à une gestion des permissions (RBAC), filtrent les affichages par classe. La logique métier est quant à elle pilotée par la Machine à États de Symfony : ce composant sécurise le cycle de vie de la convention en empêchant toute action ou transition illogique.
Espace DDF
Ce que ça fait : C'est la toute dernière étape du parcours de la convention. Un tableau de bord spécifique permet à la Direction (le DDF) de superviser les dossiers pré-validés par les professeurs et d'effectuer de derniers ajustements. Là où l'application prend tout son sens, c'est lors du clic sur le bouton "Valider et générer" : le dossier est définitivement figé, la convention officielle est générée en PDF, et le fichier est instantanément poussé vers Yousign. Le processus de signature électronique est alors lancé automatiquement pour l'élève, l'entreprise et l'école.
L'atout technique : C'est la partie de l'application qui a demandé le plus de logique backend. L'action de validation est le point d'orgue de la Machine à États (Workflow Symfony). Au clic, le code déclenche une vraie réaction en chaîne : un service complexe rassemble toutes les données de la base, communique avec le micro-service Gotenberg via des requêtes HTTP pour remplir le template Word et créer le PDF, puis utilise le Client HTTP de Symfony pour dialoguer avec l'API REST de Yousign.
L'atout technique : C'est la partie de l'application qui a demandé le plus de logique backend. L'action de validation est le point d'orgue de la Machine à États (Workflow Symfony). Au clic, le code déclenche une vraie réaction en chaîne : un service complexe rassemble toutes les données de la base, communique avec le micro-service Gotenberg via des requêtes HTTP pour remplir le template Word et créer le PDF, puis utilise le Client HTTP de Symfony pour dialoguer avec l'API REST de Yousign.
×
![Image en grand]()