Rapport final

Cette partie renvoie de façon synthétique au rapport de lancement.

HIOLLE INDUSTRIES est un groupe industriel familial, une ETI de 961 collaborateurs (effectif 2025), implantée à Prouvy près de Valenciennes. Né en 1976 dans la maintenance industrielle, le groupe s'est diversifié au fil des acquisitions et couvre aujourd'hui plusieurs pôles, l'industrie électronique, ferroviaire et aéronautique, la métallurgie, la logistique, l'immobilier et l'énergie photovoltaïque. Son cœur de métier, le câblage embarqué et l'intégration de systèmes électriques, le positionne comme sous-traitant de donneurs d'ordre exigeants, au premier rang desquels Alstom. Jusqu'ici, la gestion de la formation reposait sur des fichiers Excel et des échanges de courriels, sans vision consolidée des compétences ni des échéances de certifications. C'est ce constat qui a motivé le projet. La présentation détaillée de la structure, de l'organigramme et des pôles figure dans le rapport de lancement.

Le stage porte sur le développement de Forma-Hiolle, une application intranet de gestion de la formation professionnelle interne, destinée aux gestionnaires, aux managers et aux salariés du groupe. L'objectif est de centraliser le catalogue des modèles de formation, les plans annuels par entité, les demandes individuelles et le suivi des certifications, puis de produire les indicateurs de pilotage associés. En version 1, le périmètre se limite à la France. Les objectifs détaillés et les résultats attendus sont présentés dans le rapport de lancement.

Cette partie renvoie de façon synthétique au rapport d'avancement.

Le besoin a été porté par plusieurs acteurs aux rôles distincts. Julien CHAMAGNE, directeur des ressources humaines, est le commanditaire du projet, il exprime le besoin métier et valide les grandes orientations fonctionnelles. Jérémy LOUVEAU, mon maître de stage et directeur des systèmes d'information, arbitre le périmètre et les choix d'architecture au fil des points quotidiens. Antonietta, responsable des ressources humaines, a apporté un retour utilisateur concret lors d'une démonstration à la mi-mai. Jean-Christophe ROY, référent données, a cadré les flux et la modélisation de la base. Le besoin de départ était formalisé dans un cahier des charges fonctionnel rédigé avant mon arrivée, dont j'ai produit une version enrichie dès la première semaine.

L'analyse a confirmé trois rôles utilisateurs, gestionnaire, manager et salarié, des workflows de validation à plusieurs niveaux, et une contrainte forte d'intégration au système d'information existant, en particulier l'annuaire Active Directory pour l'authentification et le flux SILAE pour les salariés. Elle a aussi conduit à simplifier la matrice initiale, par exemple en retirant le rôle de directeur, redondant avec celui de gestionnaire. Le détail de l'expression et de l'analyse des besoins, ainsi que le cahier des charges fonctionnel enrichi, sont présentés dans le rapport d'avancement.

La pile a été validée par le maître de stage le 30 mars, après une veille comparative détaillée dans la partie 8. Elle privilégie un écosystème PHP intégré, léger sur le serveur et maintenable par l'équipe interne.

Couche	Technologie	Version
Langage serveur	PHP	8.4
Framework	Laravel	13.2
Base de données	MariaDB	11.8
Interface dynamique	Blade et Livewire	4
Styles	Tailwind CSS	4
Permissions fines	Spatie Permission	7
Audit applicatif	Spatie Activitylog	5
Récupération du flux SILAE	League Flysystem SFTP	3
Génération PDF	DomPDF	3
Authentification Active Directory	LdapRecord-Laravel	3 (prévu, non installé à ce jour)

Le code vit sur un GitLab CE auto-hébergé en interne, qui sert aussi de moteur d'intégration et de déploiement continu vers le serveur applicatif. Un second dépôt, sur GitHub en visibilité privée, héberge uniquement l'accompagnement du stage, la documentation, les rapports et les mémos, sans aucun code applicatif. Je développe sous Visual Studio Code. L'environnement local s'appuie sur SQLite pour la rapidité, alors que la production tourne sur MariaDB, une différence dont j'ai appris à surveiller les effets de bord. Le détail figure dans la partie Code et dans la veille technologique.

Forma-Hiolle s'organise autour de trois rôles et de quatre modules métier, alimentés par des flux venus du système d'information du groupe. Les trois rôles, gestionnaire, manager et salarié, accèdent chacun à un périmètre différent. Les quatre modules centraux sont le catalogue des modèles de formation, les plans de formation annuels par entité, les demandes individuelles, et les formations planifiées avec leurs inscrits. En entrée, le flux quotidien SILAE alimente la base des salariés. En sortie, des échanges sont prévus vers d'autres outils du groupe, dont FormaWay pour l'organisme de formation. L'authentification s'appuiera sur l'annuaire Active Directory.

Au terme du stage, l'application couvre l'essentiel du cycle de la formation interne. Les grands blocs livrés sont les suivants.

• Référentiel : catalogue des modèles de formation, catégories, organismes et certifications, gérés en création, modification et consultation.
• Formations et inscriptions : planification de sessions datées, affectation des apprenants, suivi des effectifs et des places disponibles.
• Plans de formation : cycle complet, création par entité, affectation des collaborateurs aux modèles, soumission, validation totale ou partielle par le gestionnaire, puis génération automatique des formations et des inscriptions. La planification est souple : un même modèle peut être réparti sur plusieurs sessions lorsque les inscrits dépassent le nombre de places, et plusieurs plans peuvent se regrouper sur une même session pour mutualiser une formation entre entités, chaque plan ne portant que le coût de ses propres collaborateurs.
• Demandes de formation : demande individuelle par le salarié ou son manager, validation à plusieurs niveaux, suivi des statuts.
• Salariés : fiche en lecture seule alimentée par SILAE, avec cumuls de postes, isolation hiérarchique récursive des managers, et passeport de formation.
• Notifications : par email et dans l'application, à chaque étape sensible des workflows.
• Documents : exports PDF du passeport, de l'attestation et de la convocation, et pièces jointes sur les certifications.
• Pilotage : tableaux de bord adaptés aux trois rôles, avec leurs actions attendues, et un audit applicatif des opérations sensibles.
• Intégration : import quotidien SILAE par SFTP, déployé et opérationnel.

Quelques briques du périmètre cible restent à finaliser, l'authentification sur l'annuaire réel, les évaluations à chaud et à quatre mois, et les exports vers les outils de reporting, comme détaillé en partie 9.

Avant de retenir Laravel, j'ai comparé quatre familles de stack sur les critères du projet. Le tableau ci-dessous reprend l'évaluation, sur une échelle de 1 à 5.

Critère	Laravel 13	Symfony 7	Node.js (Express, Fastify)	Django
Adéquation CRUDs, workflows, permissions	5	5	3	4
Intégration LDAP et Active Directory	5	4	3	4
Génération PDF et gestion CSV	5	5	3	4
Productivité pour un développeur seul sur 12 semaines	5	3	3	4
Déploiement sur Debian à ressources limitées	5	4	4	4
Maintenabilité par l'équipe interne	5	4	2	2
Documentation et communauté francophone	5	5	4	3
Total sur 35	35	30	22	25

Laravel est sorti en tête grâce à l'interactivité sans JavaScript dédié via Livewire, à la disponibilité de packages éprouvés pour les briques à venir, et à l'alignement avec l'écosystème interne. Symfony arrive deuxième, solide sur l'architecture mais avec une courbe d'apprentissage moins adaptée à un démarrage en autonomie contraint dans le temps. Côté interface, j'ai écarté une architecture séparée en Vue derrière une API, qui aurait réintroduit une couche JavaScript et un runtime supplémentaire sur le serveur. Le bilan d'usage de ces choix, avec le recul, est en partie 8.

Le projet a suivi quatre grandes phases sur les treize semaines de la période. L'étude amont et la veille ont occupé les deux premières semaines, du 23 mars au 4 avril. Le socle technique et les premiers CRUDs ont été montés du 7 au 18 avril. Le gros du développement métier, des plans aux notifications en passant par l'import SILAE et les documents, s'est étalé du 21 avril au 12 juin, avec en dernier lieu la planification multi-sessions et la mutualisation des plans, puis un pack qualité. La dernière phase, jusqu'au 19 juin, est consacrée à la finalisation, à la documentation et à la préparation de la soutenance. L'analyse détaillée des délais, avec l'estimation du temps par tâche et les écarts au plan initial, figure en partie 9.1.

Le projet est conçu pour vivre au-delà du stage. Le chantier le plus immédiat est l'activation de l'authentification sur l'Active Directory : l'intégration est préparée côté application, seul reste à ouvrir l'accès à l'annuaire, attendu dès que possible. Viennent ensuite la validation partielle des plans à affiner avec le commanditaire, puis le module d'évaluations et l'interconnexion avec FormaWay. Les exports vers les outils de reporting et l'exposition en extranet viennent plus loin. Le détail de ces recommandations, avec leur justification, est en partie 9.4.

La reprise est prévue en interne, par l'équipe Systèmes d'Information du groupe, autour de mon maître de stage, des administrateurs systèmes et réseaux et du référent données. Le code et la documentation ont été pensés pour cette passation. Aucun prestataire externe n'est envisagé en version 1, le projet étant interne par construction. Un cahier des charges de continuation reste à formaliser avec le commanditaire pour cadrer les phases postérieures au MVP, et les chantiers restants peuvent être estimés en jours-homme afin de planifier la charge de l'équipe, par exemple quelques jours pour l'interconnexion FormaWay. La question d'un devis ne se pose pas ici, puisqu'il n'y a pas de prestation externe facturée.

Dans cette logique de continuité interne, mon maître de stage a évoqué une poursuite possible en alternance au sein de l'équipe à l'issue du stage. Cette piste, encore à l'étude et conditionnée au choix d'une formation compatible, présenterait l'avantage d'une reprise du projet par son concepteur, donc d'une passation sans perte de connaissance.

Le cahier des charges est présenté ici dans une forme standardisée, séparé en un volet fonctionnel et un volet technique, comme le suggérait le retour du rapport d'avancement.

Ce volet est le cahier des charges fonctionnel. Il décrit ce que l'application doit faire, indépendamment des choix techniques.

Contexte et objectif. Centraliser la gestion de la formation interne du groupe HIOLLE INDUSTRIES, aujourd'hui dispersée dans des fichiers Excel, et l'intégrer au système d'information existant. Le périmètre de la version 1 est limité à la France.

Acteurs. Trois rôles. Le gestionnaire, côté service formation, dispose d'un accès complet. Le manager suit et valide pour son équipe. Le salarié consulte ses informations et émet ses demandes.

Besoins fonctionnels.

Réf.	Besoin
F1	Gérer un catalogue de modèles de formation réutilisables
F2	Planifier des formations datées et y affecter des apprenants
F3	Construire des plans de formation annuels par entité, avec affectation des collaborateurs et workflow de validation
F4	Gérer les demandes de formation individuelles avec validation à plusieurs niveaux
F5	Suivre les certifications des salariés, avec leurs dates de validité et des alertes avant échéance
F6	Fournir un passeport de formation par collaborateur
F7	Produire des tableaux de bord et des indicateurs par rôle
F8	Notifier les acteurs aux étapes clés, par email et dans l'application

Contraintes fonctionnelles. Données salariés en lecture seule, alimentées par SILAE. Authentification sur l'annuaire du groupe. Échanges par fichiers CSV. Vocabulaire et ergonomie adaptés à des utilisateurs RH, pas à des informaticiens.

Livrables. Application déployée sur le serveur interne, documentation technique et utilisateur, jeu de données de démonstration.

Jalons. Rapport de lancement le 6 avril, rapport d'avancement le 4 mai, rapport final le 15 juin, soutenance fin juin.

Ce volet est le cahier des charges technique. Il fixe les moyens de réalisation.

Architecture. Application web monolithique Laravel, interface rendue côté serveur avec Livewire et Alpine.js, sans application front séparée.

Pile logicielle. PHP 8.4, Laravel 13, MariaDB 11.8, Blade et Livewire 4, Tailwind CSS 4, Spatie Permission, Spatie Activitylog et DomPDF. L'authentification sur l'annuaire via LdapRecord est prévue mais non encore installée, sa bascule restant à finaliser. Le détail des versions figure en partie 3.1.

Infrastructure. VM Debian dédiée sur le réseau interne, 2 vCPU et 4 Go de mémoire, servie par Nginx et PHP-FPM. Déploiement automatisé par un pipeline d'intégration continue depuis le dépôt GitLab interne.

Intégrations. Import quotidien des salariés depuis SILAE par SFTP. Échanges prévus avec FormaWay et les outils de reporting. Authentification sur l'Active Directory du groupe.

Sécurité. Requêtes paramétrées via l'ORM, validation des entrées côté serveur, échappement des sorties, gestion des rôles et permissions avec défense en profondeur, en-têtes de sécurité HTTP.

Qualité. Style PSR-12 appliqué par Pint, analyse statique PHPStan, tests automatisés PHPUnit, documentation au format Diátaxis. Le détail figure dans la partie Code.

La formation professionnelle en France est un domaine très encadré, et j'ai pris le temps d'en comprendre le cadre parce qu'il pèse directement sur ce que Forma-Hiolle doit savoir tracer.

Depuis la loi du 5 septembre 2018 pour la liberté de choisir son avenir professionnel, le secteur a été profondément réorganisé. Le Compte Personnel de Formation (CPF) est passé en euros et est devenu accessible directement par le salarié, les anciens organismes collecteurs ont laissé place aux OPCO (Opérateurs de Compétences, qui financent et accompagnent la formation par branche professionnelle), et un régulateur national, France Compétences, a été créé. Surtout, depuis le 1er janvier 2022, tout organisme de formation qui veut accéder à des fonds publics ou mutualisés doit être certifié Qualiopi.

Le groupe est concerné par ce cadre, mais il faut bien distinguer deux versants pour ne pas se tromper sur le rôle de Forma-Hiolle. D'un côté, HIOLLE possède une filiale organisme de formation, PRO FORMATION, un centre certifié Qualiopi qui dispense des formations dans l'industrie, le ferroviaire, l'aéronautique ou le bâtiment, et qui gère sa propre activité avec son outil dédié, FormaWay. De l'autre, en tant qu'employeur, le groupe doit assurer l'adaptation de ses salariés à leur poste et le maintien de leurs habilitations réglementaires. C'est uniquement sur ce second versant que se place Forma-Hiolle. Mon outil ne gère pas l'activité d'un organisme de formation, il sert à piloter en interne le développement des compétences des salariés du groupe, à suivre leurs certifications et à garder la trace de qui a suivi quoi. La distinction compte, Forma-Hiolle et FormaWay se trouvent à deux bouts différents de la chaîne, l'un du côté de l'employeur qui forme ses équipes, l'autre du côté de l'organisme qui dispense les sessions.

Côté tendances, le marché de la formation s'est largement digitalisé. Les plateformes de type LMS (Learning Management System, les logiciels qui hébergent et diffusent des contenus pédagogiques en ligne) se sont généralisées, le présentiel et le distanciel se combinent de plus en plus dans ce qu'on appelle le blended learning, et la loi de 2018 a officialisé l'AFEST (Action de Formation En Situation de Travail), qui reconnaît la formation directement sur le poste de travail. Plus récemment, l'IA générative a commencé à toucher la création de contenus et l'accompagnement des apprenants. Forma-Hiolle ne se place pas sur ce terrain du contenu pédagogique, son rôle est en amont, sur le pilotage, le planning et la conformité.

Le contexte industriel propre à HIOLLE ajoute une couche d'exigence. Le groupe suit plus de cent certifications métier, dont beaucoup sont réglementaires et à durée de validité limitée, par exemple le CACES pour la conduite d'engins, les habilitations électriques, le SST (Sauveteur Secouriste du Travail), ou les référentiels qualité sectoriels comme l'EN 9100 en aéronautique et l'IRIS en ferroviaire. Ces habilitations ne servent pas qu'en interne. Les donneurs d'ordre comme Alstom, la SNCF ou les acteurs de l'aéronautique auditent les habilitations des sous-traitants avant de leur confier un chantier, et une certification périmée chez un opérateur peut bloquer une affaire. C'est cette réalité qui justifie le cœur de Forma-Hiolle, le suivi des certifications avec leur date de validité et l'alerte avant échéance.

Il faut distinguer deux niveaux de concurrence, qu'on a tendance à confondre. Le premier est celui de l'entreprise HIOLLE sur son marché de sous-traitance industrielle. Le second est celui de l'outil Forma-Hiolle face aux logiciels de gestion de la formation. Les deux comptent pour ce projet, mais pas pour les mêmes raisons.

Concurrents de l'entreprise HIOLLE. Le rapport de lancement citait les clients du groupe sans parler des concurrents, c'est un point que le retour de correction avait relevé et que j'avais commencé à traiter dans le rapport d'avancement. Sur son cœur de métier, le câblage embarqué et l'intégration de systèmes électriques pour le ferroviaire, l'aéronautique et la défense, HIOLLE Technologies affronte des acteurs nettement plus gros. Les deux noms qui reviennent le plus sont Labinal, la filiale câblage de Safran Electrical & Power et numéro un mondial du segment, et Latécoère Interconnection Systems, spécialisée elle aussi dans le câblage embarqué. Face à eux, HIOLLE joue la carte d'une ETI familiale diversifiée, présente sur plusieurs secteurs en parallèle, et appuyée sur plus de cent certifications métier qui lui ouvrent les marchés les plus exigeants. Ce point a une conséquence directe sur Forma-Hiolle, car la maîtrise et la traçabilité de ces certifications sont un avantage commercial autant qu'une obligation réglementaire. C'est aussi pour ça que l'outil a un sens stratégique pour le groupe.

Concurrents de l'outil Forma-Hiolle. Le marché des logiciels de gestion de la formation se découpe en trois grandes familles, que j'ai parcourues pour situer notre outil.

Les SaaS spécialisés français d'abord. Digiforma, à partir d'environ 79 euros par mois pour une PME, et Dendreo, sur un positionnement proche, ciblent les organismes de formation. Leur point fort est la conformité Qualiopi et la génération de documents réglementaires, avec chez Dendreo un meilleur outillage côté suivi commercial et relations OPCO. Leur limite pour nous est la même dans les deux cas, ils sont pensés pour des organismes qui vendent de la formation à des clients externes, pas pour un groupe industriel qui pilote son catalogue interne et la conformité de ses propres salariés.

Les LMS généralistes ensuite. Moodle, open source et gratuit, domine l'enseignement supérieur et reste très complet sur le e-learning, la création de contenus et les évaluations automatisées. 360Learning, SaaS français, mise sur l'apprentissage collaboratif et les parcours pédagogiques. Le paradigme n'est pas celui de HIOLLE, qui ne cherche pas à diffuser du contenu en ligne mais à planifier des sessions menées par des organismes internes ou externes et à suivre des habilitations.

Les modules formation des grands ERP RH enfin. SAP SuccessFactors, Workday, Cornerstone OnDemand sont des suites globales de gestion des talents, dont la formation n'est qu'une brique. Leur tarification se compte en dizaines de milliers d'euros par an, leur déploiement s'étale souvent sur six à dix-huit mois, et ils tirent leur pleine valeur dans un environnement déjà équipé de la suite correspondante. Ce n'est pas le contexte de HIOLLE, et le coût total serait sans rapport avec le besoin.

Les outils déjà en place dans le groupe. Forma-Hiolle ne remplace pas l'existant, il s'y articule. SILAE, le logiciel de paie et de gestion RH, reste la source de vérité des salariés, que Forma-Hiolle consomme en lecture seule via l'import quotidien. FormaWay, l'outil de la filiale PRO FORMATION, gère de son côté l'activité de l'organisme de formation, et Forma-Hiolle est pensé pour s'y connecter en lui transmettant les formations et leurs inscrits, plutôt que pour le remplacer. Là encore, mon outil se place du côté de l'employeur qui pilote la montée en compétences de ses équipes, pas du côté de l'organisme qui dispense les sessions.

Tableau de positionnement.

Critère	SaaS spécialisés (Digiforma, Dendreo)	LMS (Moodle, 360Learning)	Modules ERP RH (SuccessFactors, Workday)	Forma-Hiolle
Cible	Organismes de formation	Diffusion de contenu pédagogique	Grands groupes équipés de la suite	Groupe industriel, usage interne
Coût annuel	Abonnement par utilisateur	Gratuit (Moodle) à payant	Dizaines de milliers d'euros	Coût interne (hébergement seul)
Intégration Active Directory et SILAE	Limitée	Variable	Forte mais lourde	Native, sur mesure
Suivi multi-certifications réglementaires	Partiel	Faible	Oui	Cœur du besoin
Hébergement interne maîtrisé	Non	Possible (Moodle)	Non	Oui
Adéquation au besoin précis HIOLLE	Faible	Faible	Surdimensionné	Forte

Conclusion du positionnement. Le développement sur mesure ne se justifie pas dans tous les cas, mais ici les conditions sont réunies. Les besoins métier sont stables et bien circonscrits, le volume d'utilisateurs reste à l'échelle d'un groupe industriel français, et la maîtrise du code en interne par le service SI a un poids stratégique qui dépasse le confort technique. Les solutions du marché embarqueraient trop de fonctions hors scope, pour un coût récurrent qui ne se rentabiliserait pas, et aucune n'offrirait l'intégration native à l'Active Directory et au flux SILAE qui fait la valeur de l'outil.

Ma veille technologique a démarré pendant les deux premières semaines pour choisir la pile, puis elle s'est poursuivie tout au long du stage à chaque décision technique. Le comparatif initial des frameworks figure dans la partie 4 sur les alternatives écartées. Je fais ici le bilan avec le recul de douze semaines d'usage, brique par brique, en distinguant ce qui s'est confirmé et ce qui m'a posé problème.

Framework back, Laravel 13. Le choix s'est confirmé sans réserve. Avoir l'ORM, le planificateur de tâches, les permissions et les notifications intégrés au framework m'a évité d'assembler des briques disparates, ce qui aurait été risqué pour un développeur seul sur douze semaines. Les alternatives étudiées au départ, Symfony 7, Django 5 et plusieurs stacks Node, restent valables dans l'absolu mais auraient demandé davantage d'assemblage et de configuration manuelle, ou une courbe d'apprentissage moins compatible avec le délai.

Interface, Blade et Livewire 4. C'est le pari le plus intéressant à analyser après coup. Livewire permet de construire des interfaces réactives en PHP, sans application front séparée en JavaScript, ce qui correspond au contexte d'un développeur seul et à une VM à mémoire limitée. Le pari est tenu, mais il a un coût d'apprentissage que je n'avais pas pleinement anticipé. J'ai rencontré plusieurs pièges réactifs à la frontière entre Livewire et Alpine.js, par exemple des cases à cocher générées dans une boucle qui ne se pré-cochaient pas, ou des objets réactifs Alpine mal transmis au serveur. Chaque piège a fini documenté dans un carnet interne pour ne pas retomber dessus. J'avais aussi regardé Inertia avec Vue, écarté parce qu'il réintroduisait justement la couche JavaScript que Livewire permet d'éviter.

CSS, Tailwind 4. Le projet avait démarré par erreur en Tailwind 3, héritage du gabarit de départ, et j'ai piloté la migration vers la version 4 le 8 avril. Cette version apporte un moteur de compilation nettement plus rapide, une configuration directement en CSS et des container queries natives. Avec le recul, la migration valait le coup tant que le projet était jeune, elle aurait été bien plus coûteuse en fin de stage. Je n'ai pas retenu Bootstrap, trop marqué visuellement, ni de surcouche comme DaisyUI, inutile une fois qu'on maîtrise les classes de base.

Permissions, Spatie Permission. Comparé à Bouncer, Spatie l'emporte sur la popularité, la maintenance et la documentation. À l'usage, le besoin d'une permission fine attribuable à un manager précis, sans toucher à son rôle global, a confirmé le choix. Tout est centralisé dans un seul fichier de configuration, donc en ajouter une nouvelle ne coûte qu'une ligne.

Génération de documents, DomPDF. Choisi au départ et installé en cours de stage pour produire les trois documents PDF du projet, le passeport de formation, l'attestation et la convocation. DomPDF reste du PHP pur, sans dépendance à un navigateur sans interface comme l'aurait imposé une solution de type Browsershot, ce qui le rend léger à déployer sur la VM. Pour des mises en page simples, il fait le travail.

Authentification Active Directory, LdapRecord. C'est la brique encore en attente au moment où j'écris ces lignes. Pendant tout le développement, l'authentification tourne sur un mode de remplacement avec des comptes de test, parce que je n'avais pas accès à l'annuaire réel depuis le poste de développement. LdapRecord a été retenu pour sa documentation et son mode placeholder, qui permet de basculer vers l'annuaire réel sans réécrire le code applicatif. La bascule effective reste à mener et dépend d'une coordination avec le responsable réseau. J'avais écarté une approche par proxy d'authentification en amont, moins souple pour gérer finement les rôles côté application.

Récupération du flux SILAE, Flysystem SFTP. L'adaptateur SFTP de la League s'est imposé pour sa compatibilité native avec le système de fichiers de Laravel et sa maintenance active, face à un usage direct de la librairie phpseclib, plus bas niveau.

Audit applicatif, Spatie Activitylog. Branché en cours de route sur les modèles sensibles, il journalise les créations, modifications et suppressions. Je l'ai gardé en dispositif exploratoire, parce que la politique métier qui doit l'accompagner, la durée de conservation et le périmètre de consultation, n'a pas encore été arbitrée avec le commanditaire.

Veille continue et divergences d'environnement. Au-delà des choix de départ, la veille a continué sur les problèmes du quotidien. Le plus marquant est la divergence entre l'environnement local, qui tourne sur SQLite, et la production sur MariaDB. Les deux ne réagissent pas toujours pareil, par exemple sur le fuseau horaire des dates ou sur la tolérance face à une colonne absente d'une requête. Quelques bugs ne sont apparus qu'en production, ce qui m'a appris à tester les points sensibles directement contre une base proche de la cible.

Cette bibliographie reprend les sources mobilisées depuis le début du stage et les complète avec celles consultées sur la deuxième moitié, notamment pour la veille environnementale et les briques installées en mai.

• Laravel 13, documentation et notes de version, laravel.com/docs
• Livewire 4, documentation et pièges réactifs, livewire.laravel.com
• Alpine.js, directives et portées, alpinejs.dev
• Tailwind CSS 4, guide de migration de la version 3 vers la 4, tailwindcss.com/docs/upgrade-guide
• Spatie Laravel Permission, spatie.be/docs/laravel-permission
• Spatie Laravel Activitylog, spatie.be/docs/laravel-activitylog
• LdapRecord-Laravel, ldaprecord.com/docs/laravel/v3
• DomPDF (barryvdh/laravel-dompdf), github.com/barryvdh/laravel-dompdf
• League Flysystem et adaptateur SFTP, flysystem.thephpleague.com
• Diátaxis, cadre de structuration de la documentation technique, diataxis.fr

• Benchmarks TechEmpower, techempower.com/benchmarks
• Grafikart, articles Laravel et Livewire, grafikart.fr
• Communauté LaravelFrance
• Notes de version de PHP 8.4, php.net/releases/8.4/fr.php

• Digiforma, tarification et cas d'usage, digiforma.com
• Dendreo, positionnement et relations OPCO, dendreo.com
• Moodle, modèle pédagogique LMS, moodle.org
• 360Learning, plateforme collaborative, 360learning.com
• SAP SuccessFactors, Workday et Cornerstone OnDemand, sites éditeurs

• Loi n° 2018-771 du 5 septembre 2018 pour la liberté de choisir son avenir professionnel, Légifrance
• Référentiel national qualité Qualiopi, Ministère du Travail, travail-emploi.gouv.fr
• France Compétences, régulateur de la formation professionnelle, francecompetences.fr

• Grille d'évaluation et consignes des rapports, UE L305, Université de Limoges
• Aide à l'hébergement WordPress étudiant, hosting.unilim.fr/aide

Avec le recul de la fin de stage, le planning prévisionnel du rapport de lancement a globalement tenu, mais pas de la façon que j'avais imaginée. J'ai pris une avance nette sur la première moitié, que j'ai ensuite réinvestie dans la qualité et dans des chantiers non prévus, plutôt que dans le suivi strict du séquencement initial. Quelques jalons ont par ailleurs glissé, et je l'assume.

Ce qui a été tenu ou livré en avance. Le socle technique et les cinq premiers CRUDs de référentiel, prévus sur les semaines 3 et 4, ont été bouclés dès la semaine 3. Surtout, les deux gros modules Plans de formation et Demandes de formation, que le planning initial positionnait en semaines 6 et 10, ont été livrés dès la semaine 4. Cette avance, estimée entre huit et dix jours à mi-parcours, m'a servi de matelas pour absorber les imprévus.

Ce qui a dérivé du plan, en mieux. Le premier test d'import sur le flux SILAE réel, en semaine 5, a révélé des cas que le schéma initial ne couvrait pas, en particulier des salariés cumulant plusieurs postes. J'ai préféré une refonte durable du modèle de données plutôt qu'un correctif fragile, ce qui a consommé du temps non prévu mais évité une dette. Dans la même logique, j'ai investi l'avance dans des chantiers absents du planning de lancement, l'isolation récursive des managers, un pack qualité, l'audit trail, et une refonte assez large de l'UX des modales en fin de parcours.

Ce qui a glissé. L'authentification sur l'Active Directory réel est le jalon le plus en retard. Prévue en semaine 8 dans le plan initial, repoussée en semaine 9 au daily de cadrage du 28 avril, elle n'est toujours pas finalisée à l'approche de la fin du stage. La raison est en partie hors de mon contrôle, la bascule dépend d'une coordination avec le responsable réseau et d'un accès à l'annuaire que je n'avais pas en développement. Enfin, le module d'évaluations à chaud et à J+120, les questionnaires de satisfaction et d'efficacité envisagés au départ, a été volontairement laissé de côté : j'ai préféré concentrer l'effort sur le cœur métier, bien plus structurant pour un premier MVP.

Pour répondre à la demande de précision du retour d'avancement, le tableau ci-dessous estime le temps passé par grand module, reconstitué à partir de mon carnet de bord tenu au fil de l'eau pendant tout le stage. Cette prise de notes quotidienne a permis d'étaler la rédaction des rapports sans empiéter sur le développement, en partie en dehors des heures ouvrées.

Module ou tâche	Période réelle	Charge estimée	Écart au plan initial
Étude amont, veille, proposition technique, modèle de données	23 mars au 4 avril	environ 2 semaines	conforme
Mise en place serveur et pipeline CI/CD GitLab	1er au 3 avril	environ 2 jours	conforme
5 CRUDs de référentiel	7 au 9 avril	environ 3 jours	livré en avance
Plans et Demandes de formation	14 au 18 avril	environ 5 jours	très en avance (prévu en semaines 6 et 10)
Import SILAE et refonte des mandats	21 au 27 avril	environ 5 jours	anticipé, refonte non prévue
Isolation manager et permissions fines	24 avril	environ 1 jour et demi	ajout en cours de route
Workflow de validation des plans et génération des formations	5 au 9 mai	environ 4 jours	conforme
Notifications par email et in-app	5 au 16 mai	environ 3 jours	conforme
Trois exports PDF (passeport, attestation, convocation)	12 au 16 mai	environ 3 jours	anticipé (initialement en semaine 12)
Refonte UX des modales et polish général	19 au 29 mai	environ 6 jours	investissement qualité non prévu
Planification multi-sessions, mutualisation des plans et pack qualité	2 au 12 juin	environ 6 jours	enrichissement non prévu au plan initial
Authentification Active Directory réelle	semaines 11 à 13	à finaliser	jalon en retard
Dashboards par rôle	étalé jusqu'à la fin	réparti sur la fin	livré, à affiner après retours
Rapports académiques (lancement, avancement, final)	jalonné sur tout le stage	environ 10 jours cumulés, nourris par un carnet de bord tenu en continu	conforme aux échéances

Sur les bénéfices, et leur mesurabilité. Il faut rester honnête sur le statut de l'outil, c'est un MVP qui n'est pas encore en service auprès des utilisateurs réels. Les indicateurs métier visés, comme la réduction du délai entre une demande de formation et sa validation, le taux d'adoption par les managers, ou la baisse du nombre de certifications laissées expirer, ne sont donc pas mesurables aujourd'hui. Je les assume comme des cibles, dont la mesure deviendra possible une fois l'application déployée et nourrie par l'usage réel. Ce qui est déjà chiffrable est d'ordre technique et donne une première idée de la solidité de la base, l'import quotidien SILAE traite l'ensemble des salariés en environ deux minutes vingt, la suite compte 234 tests automatisés verts sans régression durable sur douze semaines, et le déploiement est entièrement automatisé par le pipeline d'intégration continue. La valeur métier, elle, se jugera à l'usage, et c'est précisément pour la rendre mesurable que les tableaux de bord et l'audit applicatif ont été posés dès maintenant.

Pour répondre à la question posée dans le retour du rapport d'avancement, je qualifierais mon statut de stagiaire développeur unique sur le projet, intégré à l'équipe Systèmes d'Information du groupe. Concrètement, je suis seul sur le code de Forma-Hiolle, avec une vraie autonomie sur la réalisation, mais encadré de près par mon maître de stage qui arbitre le périmètre et valide les orientations. Ce double statut, autonome mais suivi, est sans doute ce qui résume le mieux ma place dans l'équipe.

Le moment relationnel le plus marquant a été la démonstration faite à Antonietta, la responsable des ressources humaines. Pouvoir vraiment échanger avec elle a été inspirant. J'ai recueilli sa vision de l'outil, compris comment elle procédait avant avec ses tableurs et ses habitudes, et la démonstration a déclenché beaucoup de questions de sa part. Ce sont justement ces questions qui m'ont permis de cerner les vrais besoins, les attentes et les points qui comptent pour elle au quotidien. C'est très différent de lire un cahier des charges, on touche au concret et on ajuste tout de suite.

L'ambiance dans le bureau du service a beaucoup compté. Elle est franchement excellente, chaleureuse, on rigole, on parle de tout, et il y a une vraie écoute entre nous. Dès mon premier jour, on est venu me chercher pour aller manger au réfectoire avec l'équipe, et cet accueil m'a tout de suite mis à l'aise. Au fil des semaines, j'ai pris l'habitude de parler facilement avec les uns et les autres, de demander un coup de main ou d'en donner. C'est le genre de cadre qui rend le travail plus simple.

Avec mon maître de stage, le directeur des systèmes d'information, la relation est un peu différente. Je suis resté assez intimidé, je le dis franchement, mais il est gentil et compréhensif. Il a énormément de travail, ça se voit, et malgré ça il a toujours su se rendre disponible quand j'en avais besoin. C'est lui qui m'a laissé de l'autonomie sur certains aspects du projet tout en assurant un suivi régulier, juste ce qu'il faut pour ne pas partir dans une mauvaise direction.

Tout n'a pas été parfait pour autant, et le travail en solitaire a un revers que j'ai bien senti. À force de construire l'application bloc par bloc, on en développe une vision très particulière, on connaît chaque partie par cœur, et on finit par avoir du mal à se mettre à la place de quelqu'un qui la découvre. On voit le détail de chaque mécanisme, mais on ne pense pas toujours à tester les cas improbables, ceux qu'un utilisateur finira pourtant par provoquer sans le vouloir. Deux cerveaux réfléchissent mieux qu'un, c'est tout l'intérêt des points quotidiens avec mon maître de stage, qui m'ont souvent fait voir un angle auquel je n'avais pas pensé. Mais lui-même n'est pas l'utilisateur final, et c'est précisément ce qui a rendu la démonstration à Antonietta aussi précieuse, son regard neuf d'utilisatrice a fait remonter des besoins et des réflexes que, seul devant mon code, je ne pouvais pas deviner. J'ai essayé de compenser ce manque de regard extérieur par une discipline de tests et de filets automatiques, pour être mon propre relecteur autant que possible.

Côté travail pur, mon activité de développeur ne m'amenait pas à échanger en permanence avec tout le monde sur ce que je codais, c'est la nature d'un projet solo. Mais j'ai eu des interactions régulières et utiles sur des sujets précis. Avec Jean-Christophe ROY, le référent données, dès qu'il s'agissait de la donnée et des flux, et il a aussi pris le temps de tester l'outil pour en éprouver la solidité. Avec Thomas et Nicolas, les administrateurs systèmes et réseaux, pour mettre en place la machine de production et celle du GitLab, installer mes outils en début de stage, puis régler quelques demandes techniques ponctuelles ensuite.

J'ai aussi eu une petite incursion hors du projet, une side-quest comme je l'appelle, sur un sujet d'infrastructure réseau. Elle n'est pas encore testée ni déployée, mais c'était l'occasion de rendre service à l'équipe et de toucher à autre chose. Au bout du compte, ce qui ressort de ces trois mois, c'est une intégration vraiment réussie dans une équipe soudée, où j'ai gagné en aisance à mesure que les semaines passaient.

Ce stage a été une vraie montée en compétences, parce que j'ai touché à des briques que je ne maîtrisais pas en arrivant, et que j'ai dû les apprendre en produisant.

Laravel 13 et Livewire 4. C'est le socle, et c'est là que j'ai le plus progressé. J'avais des bases en PHP, mais pas sur un framework de cette ampleur. J'ai appris à structurer une application autour de l'ORM Eloquent, des composants Livewire, des migrations versionnées et du planificateur de tâches. Livewire m'a demandé un effort particulier, parce que sa réactivité à la frontière avec Alpine.js réserve des pièges qui ne sautent pas aux yeux. J'ai fini par tenir un carnet de ces pièges pour ne pas les refaire, ce qui m'a appris autant sur le débogage que sur le framework lui-même.

Tailwind 4 et l'interface. J'ai mené une migration de version en cours de projet, ce qui m'a obligé à comprendre en profondeur le fonctionnement du moteur et de la configuration. Plus largement, j'ai gagné en autonomie sur la construction d'interfaces cohérentes, la gestion des transitions, des modales et du responsive, des sujets que je sous-estimais avant ce stage. Sur l'identité visuelle, je suis volontairement sorti de mon cœur de métier : faute de charte graphique officielle, j'ai établi une proposition en reprenant les codes couleurs du groupe et en dessinant un logo simple. Ce n'est pas un travail de graphiste et la proposition reste soumise à validation.

Les pièges de l'interface réactive, et les filets construits en réaction. L'interface réactive en Livewire et Alpine a été ma plus grosse source de difficultés, parce que ses pièges ne se voient ni à la compilation ni dans les tests classiques. J'ai rencontré des cas variés : des cases à cocher générées dans une boucle qui ne se pré-cochaient pas, des objets réactifs mal transmis au serveur, et plus récemment deux écrans d'une même fenêtre qui se superposaient une fraction de seconde pendant leur transition, donnant une impression de clignotement. Ce dernier cas résume bien ma méthode : pour comprendre un défaut fugace, j'ai volontairement ralenti les animations afin de figer le mouvement, ce qui a révélé que l'écran sortant restait affiché le temps de son fondu de sortie ; la correction a consisté à le faire disparaître d'un coup plutôt qu'en fondu.

Concrètement, transmettre tel quel un objet réactif au serveur échouait silencieusement ; je le convertis donc en objet simple avant l'envoi :

this.allModeles = JSON.parse(JSON.stringify(this.$wire.modelesOptions || []));

Le plus instructif a été de constater que certains de ces défauts passent à travers les tests habituels : un guillemet mal placé dans un attribut, ou une instruction d'affichage collée à un mot, cassent la page dans le navigateur alors que le code compile et que les tests automatisés restent au vert. En réaction, j'ai construit deux filets dédiés : un contrôle statique qui parcourt toutes les vues pour repérer précisément ces pièges, et des tests de bout en bout qui chargent réellement les pages dans un navigateur sans interface et vérifient qu'aucune erreur JavaScript ne survient. Chaque difficulté rencontrée a ainsi donné naissance au garde-fou qui l'aurait attrapée.

Active Directory, flux et données. Même si la bascule sur l'annuaire réel n'est pas encore faite, j'ai étudié l'intégration LDAP et préparé le terrain avec un mode de remplacement. J'ai surtout beaucoup appris sur l'intégration d'un flux de données réel. Le flux SILAE m'a confronté à la vraie vie d'une donnée d'entreprise, des cumuls de postes, des encodages douteux, des exports partiels un matin donné. J'ai appris à coder défensivement, avec des gardes contre les fermetures massives et une trace de chaque import. Par exemple, le flux arrivait parfois avec des accents mal encodés ; plutôt que de corriger à l'aveugle, je détecte d'abord l'anomalie avant de la réparer :

private function detectMojibake(string $content): bool
{
    return (bool) preg_match('/Ã[©¨ªêàçÉ]/u', $content);
}

private function fixMojibake(string $content): string
{
    return mb_convert_encoding($content, 'ISO-8859-1', 'UTF-8');
}

Architecture et code réutilisable. J'ai pris le réflexe d'extraire ce qui se répète. L'isolation hiérarchique des managers, par exemple, est centralisée dans un scope de requête unique qui parcourt l'arborescence des équipes niveau par niveau, avec une garde contre les éventuels cycles. Plutôt que de répéter ce filtre dans chaque écran, je l'ai écrit une fois et propagé. C'est une façon de penser que je n'avais pas vraiment avant, et qui change la maintenabilité du code.

Outils de production. J'ai monté de bout en bout une chaîne d'intégration et de déploiement continu, du dépôt Git interne jusqu'au serveur, avec un déploiement automatique à chaque livraison. J'ai aussi appris à gérer une topologie à deux dépôts, l'un interne pour le code, l'autre externe et privé pour l'accompagnement du stage, avec les configurations Git que cela suppose. La régularisation du pipeline, après quelques tâtonnements, m'a appris à lire des journaux d'exécution et à isoler une cause racine.

Les pièges qui n'arrivent qu'en production. L'enseignement le plus concret est sans doute la divergence entre l'environnement local et la production. Développer sur un moteur de base de données en local et déployer sur un autre en production m'a coûté quelques bugs qui n'apparaissaient que côté serveur. J'en ai tiré une règle simple, tester les points sensibles dans des conditions aussi proches que possible de la cible, et ne jamais supposer que deux moteurs de base de données se comportent à l'identique.

Sécurité. Enfin, en réaction directe au legacy 2024 et à ses injections SQL, j'ai gardé une discipline de sécurité constante, requêtes systématiquement paramétrées via l'ORM, validation des entrées côté serveur, échappement des sorties, et une défense en profondeur sur les permissions, vérifiées à la fois à l'affichage et dans chaque action sensible.

La place des outils d'IA, et ce que j'ai vraiment appris. Autant être transparent : comme beaucoup aujourd'hui, je me suis aidé d'outils d'IA pendant ce stage. Je connaissais déjà Laravel par mes cours, et sur le code, l'IA m'a surtout fait gagner du temps sur ce qui est connu et répétitif, un peu comme une documentation ou un bout de code trouvé sur un forum. Mais résumer ce stage à ça serait faux. L'essentiel de ce que j'ai appris s'est joué ailleurs, justement là où aucun outil ne fait le travail à ma place. J'ai appris à mener un projet seul de bout en bout, à le découper et à le prioriser au fil des points quotidiens avec mon maître de stage. J'ai monté une chaîne Git interne et un déploiement continu, et appris à lire un pipeline quand il casse. Je me suis intégré dans une équipe SI, j'ai appris à demander de l'aide et à en donner, à avancer au rythme des dailies et des démonstrations. J'ai surtout appris à comprendre un besoin RH exprimé par des gens qui ne parlent pas informatique, à le confronter au réel lors d'une démo, puis à ajuster. Et à décider, à justifier mes choix, et à en assumer les conséquences une fois en production. C'est là que j'ai le plus progressé, et l'IA n'y change rien.

À l'approche de la fin du stage, l'outil couvre le cœur du besoin, mais plusieurs chantiers méritent d'être poursuivis. Je les classe en trois familles.

Développements à terminer en priorité. Le plus important est la bascule sur l'Active Directory réel, préparée mais pas encore branchée, qui conditionne la mise en service auprès des vrais utilisateurs. Vient ensuite l'affinage du workflow de validation des plans avec le commanditaire : la validation partielle est livrée, mais ses règles fines, comme le circuit à une ou deux étapes, restent à caler avec Julien CHAMAGNE. Le module d'évaluations, à chaud après la formation puis à quatre mois, faisait partie des idées de départ ; il a été écarté du MVP au profit de fonctionnalités plus structurantes, et reste une évolution possible. Enfin, l'interconnexion avec FormaWay, pour transmettre automatiquement à l'organisme les formations et leurs inscrits, remplacerait avantageusement la transmission manuelle.

Améliorations envisageables. Plusieurs pistes sont identifiées et tracées dans un backlog dédié. La refonte des modales de détail, qui pourraient s'ouvrir en surimpression de la page courante plutôt que par navigation, est un chantier d'architecture à arbitrer. Les tableaux de bord par rôle peuvent encore gagner en richesse. Les trois sont en place, actions attendues, synthèse d'équipe et graphiques de pilotage compris, mais ils ont été construits avant la mise en service réelle : c'est l'usage quotidien des gestionnaires et des managers qui dira quels indicateurs affiner ou ajouter. Ce sont des améliorations de confort, pas des manques bloquants.

Devenir de l'application. Forma-Hiolle a été conçu pour être repris par l'équipe Systèmes d'Information du groupe une fois le stage terminé. C'est la raison pour laquelle j'ai investi dans la documentation, les tests et la lisibilité du code. À plus long terme, l'extension à un accès extranet, via la DMZ déjà en place, évoquée dès le départ mais hors périmètre de la version 1, permettrait d'élargir l'usage au-delà du réseau interne, par exemple aux intérimaires ou aux filiales étrangères. La base de données a été pensée pour ne pas fermer cette porte.

Pour finir, une note plus personnelle. Ce stage tombe à un moment particulier pour le métier. Les outils d'IA avancent vite, et je ne vais pas faire comme si je ne me posais pas de questions sur ce que sera le travail de développeur dans quelques années.

Plusieurs signes montrent à quel point l'IA prend de l'ampleur, partout. La course aux puces et à la puissance de calcul en est un. Un autre, qui m'a marqué, c'est ce qui s'est passé le 12 juin 2026 : sur ordre du Department of Commerce américain et pour des raisons de sécurité nationale, Anthropic a dû couper l'accès à ses deux modèles les plus puissants, Fable 5 et Mythos 5, pour les ressortissants étrangers, après le signalement d'un contournement de ses garde-fous. L'entreprise n'avait aucun moyen de filtrer ses utilisateurs par nationalité, elle a donc tout coupé au niveau mondial (sources : TIME, TechRadar, L'Usine Digitale).

Je précise tout de suite que je ne cherche pas à prendre position sur un terrain politique, je me contente de rapporter des faits et de dire ce qu'ils m'inspirent. Cet épisode se lit dans deux sens, et les deux m'interpellent. D'un côté, qu'un État juge nécessaire de restreindre l'accès à un modèle laisse penser qu'on a atteint un niveau de puissance pris très au sérieux. De l'autre, le déclencheur est un contournement des garde-fous, donc des personnes cherchent activement à faire sortir ces outils du cadre prévu, et pas toujours avec de bonnes intentions.

C'est ce qui me pousse à rester curieux et à élargir mes centres d'intérêt au-delà du seul code. Je n'ai pas de certitude sur la suite, mais je crois qu'un développeur a tout intérêt à se placer là où le jugement humain reste nécessaire, pour encadrer ces outils et leur donner du sens, plutôt que de chercher à lutter contre eux.

La qualité du code a été une préoccupation constante, en réaction directe au legacy 2024 où l'absence de tests et de structure avait fini par bloquer le projet. Plusieurs garde-fous tournent en continu.

Le style est uniformisé par Laravel Pint, qui applique les conventions PSR-12 à chaque passage. Par choix de robustesse d'encodage, les commentaires du code sont rédigés sans accents, alors que tout le contenu visible par l'utilisateur reste pleinement accentué. L'analyse statique est assurée par PHPStan configuré au niveau 5, qui repère les erreurs de typage et les accès à des propriétés ou méthodes inexistantes avant même l'exécution. Côté tests, la suite PHPUnit compte 234 tests verts au moment où j'écris, répartis sur 32 fichiers, sans régression durable sur les douze semaines. Ils couvrent les scénarios sensibles, l'isolation des managers, les workflows de validation, les permissions par rôle et l'import SILAE. À cette suite s'ajoutent deux garde-fous nés des pièges du développement réactif : un lint statique qui parcourt les vues pour détecter les erreurs de gabarit invisibles à la compilation, et des tests de bout en bout qui chargent les pages dans un navigateur sans interface et signalent toute erreur JavaScript.

La documentation technique suit le cadre Diátaxis, qui sépare les guides pratiques, les explications et les références. Une quinzaine de fichiers Markdown sont versionnés dans le dossier docs du dépôt, complétés par une documentation utilisateur en cours de rédaction. Un point de contrôle, la route /health, permet au pipeline de vérifier après chaque mise en ligne que l'application répond et que la base est joignable.

La portabilité ne repose pas sur Docker, qui n'a pas été retenu ici, mais sur le caractère standard d'une application Laravel. Le déploiement est entièrement scripté par le pipeline GitLab, qui réinstalle les dépendances, applique les migrations et reconstruit les ressources front. Reprendre le projet sur une nouvelle machine revient à cloner le dépôt, installer les dépendances et lancer les migrations.

L'organisation suit la structure standard de Laravel, choix volontaire pour qu'un développeur qui connaît le framework s'y retrouve immédiatement. Le code métier est porté par 15 composants Livewire, en somme un par domaine fonctionnel, qui jouent à la fois le rôle de contrôleur et de vue réactive. Les données s'appuient sur 27 modèles Eloquent et 45 migrations versionnées, qui décrivent le schéma de bout en bout et le rendent reproductible.

Pour ne pas répéter le même code dans plusieurs écrans, j'ai regroupé les comportements communs dans des traits PHP partagés, rangés dans un dossier Concerns. Quatre traits structurent ce socle, HasBackContext pour la flèche de retour entre les écrans, OpensDetailFromQueryParam pour l'ouverture d'une fiche détail depuis un lien, HandlesDocumentAttachments pour les pièces jointes, et HandlesRecursivityToggle pour l'affichage récursif des équipes. La logique de création des comptes, plus lourde, est isolée dans un service dédié, UtilisateurProvisionService. Les 21 seeders sont écrits pour être idempotents, c'est-à-dire rejouables sans créer de doublons, ce qui permet de reconstruire un jeu de données de démonstration à tout moment. Cinq commandes Artisan complètent l'ensemble, dont l'import quotidien SILAE.

Pour donner un aperçu concret, le cœur du workflow de validation d'un plan tient en peu de code : seuls les collaborateurs explicitement validés sont retenus pour générer les inscriptions.

foreach ($plan->planModeles as $pm) {
    foreach ($pm->salariesPrevus as $pms) {
        // Seuls les collaborateurs coches passent "valide" ; les autres restent en attente.
        if ($pms->statut === 'inclus' && ($this->validatePlanSelection[(string) $pms->id] ?? false)) {
            $pms->update(['statut' => 'valide', 'commentaire' => null]);
        }
    }
}

L'intégralité du code vit dans le dépôt GitLab interne du groupe, avec son historique de commits, où le découpage en composants, modèles et migrations se lit directement dans l'arborescence. Un accès en lecture à une version rebrandée est mis à la disposition du correcteur, décrit dans la section Accès à l'application.

Forma-Hiolle est déployé sur une VM interne au réseau du groupe, ce qui pose une vraie difficulté pour l'évaluation, car l'application n'est pas joignable depuis l'extérieur. Pour lever cet obstacle, une version de démonstration est déployée sur un hébergement public, à partir d'un dépôt personnel distinct du dépôt interne du groupe. Cette version est volontairement rebrandée, avec un logo, des couleurs et une identité visuelle différents de ceux de HIOLLE, et elle ne contient que des données entièrement fictives. Cette version a été spécifiquement reprise et retravaillée, surtout sur l'habillage, pour être présentable hors de l'entreprise. Comme elle est exposée publiquement, elle est protégée contre les usages abusifs, avec un volume de données borné, des entrées validées et des requêtes paramétrées contre les injections. Un rappel visible précise que toutes les données affichées sont fictives. Elle préserve ainsi la confidentialité des données industrielles tout en permettant au correcteur de manipuler réellement l'application en suivant le tutoriel. Cette version de démonstration, baptisée Formadeck, est accessible à l'adresse formadeck.nathansaccol.fr.

Au-delà de la manipulation de l'application, le code source peut être consulté. Il est hébergé sur une instance Git privée, accessible en lecture seule via un compte dédié dont les identifiants figurent en annexe. Cet accès porte sur la version rebrandée, placée sous une licence qui en réserve l'usage à l'évaluation et en interdit la réutilisation ; le compte est révocable à l'issue de la correction.

Pour donner à voir un parcours complet, trois comptes de démonstration couvrent les trois rôles, avec le mot de passe commun demo2026 : mdurand (gestionnaire) ouvre l'accès complet, sbernard (manager) illustre l'isolation à son équipe, et pmartin (salarié) montre l'espace personnel. Le tutoriel associé reprend, pour chaque rôle, un parcours représentatif. Côté salarié, consulter son passeport, déposer une demande de formation et suivre son avancement. Côté gestionnaire, créer un plan, y affecter des collaborateurs, le soumettre puis le valider, et générer les formations correspondantes.

Pour donner à voir le résultat, voici quelques écrans de Forma-Hiolle (données fictives de démonstration), couvrant les trois rôles et la planification des plans.

Note sur les illustrations. Les schémas de ce rapport (fonctionnement, planning, architecture, modèle de données) sont des illustrations dont j'ai défini le contenu et la structure, mises en forme en vectoriel avec l'aide d'outils d'IA. J'ai préféré cette approche à un éditeur comme draw.io, parce que le rendu est net, léger, directement intégrable au format web du rapport et facile à mettre à jour. Les captures d'écran, elles, viennent de l'application, et le schéma complet de la base (annexe H) est généré par dbdiagram.io à partir du modèle que j'ai écrit.

Les annexes sont regroupées sur une page dédiée du CMS, distincte de ce rapport.

• A. Macro-planning détaillé (dates absolues)
• B. Accès au code source : instance Git privée, compte en lecture seule dédié, identifiants fournis sur la page annexes (version rebrandée, licence d'évaluation, non réutilisable)
• C. Cahier des charges fonctionnel (version enrichie)
• D. Cahier des charges technique
• E. Captures d'écran des trois rôles
• F. Documentation technique (extraits, format Diátaxis)
• G. Tutoriel utilisateur par rôle
• H. Modèle de données : schéma relationnel complet des 41 tables, en visionneuse interactive zoomable (format vectoriel) · télécharger le schéma (SVG)