Rapport d'avancement

Forma-Hiolle est une application intranet de gestion de la formation professionnelle, développée pour le Groupe HIOLLE INDUSTRIES, ETI (Entreprise de Taille Intermédiaire) industrielle d'environ 1 100 collaborateurs implantée à Prouvy, dans le Nord. Le projet couvre la centralisation du catalogue de modèles de formation, la planification des sessions, les plans de formation annuels par entité, les demandes individuelles et collectives, le suivi des certifications métier et la production des indicateurs RH. En V1, le périmètre est restreint à la France, les filiales étrangères du groupe seront adressées dans une version ultérieure.

Le commanditaire du projet est Julien CHAMAGNE, Directeur des ressources humaines du groupe. Mon maître de stage, Jérémy LOUVEAU, Directeur des systèmes d'information, supervise la conduite technique et valide les décisions d'architecture et de scope. Je suis le développeur principal, seul sur le code, intégré à l'équipe des systèmes d'information à Prouvy. Le stage se déroule du 23 mars au 19 juin 2026, soit 12 semaines effectives après retrait des 5 jours fériés.

La pile applicative a été validée par Jérémy LOUVEAU après une phase de veille technologique. Au 29 avril, la base installée est Laravel 13 sur PHP 8.4, avec Livewire 4 pour l'interactivité, Tailwind CSS 4 pour le style, MariaDB 11.8 pour les données, Spatie Permission pour les rôles fins, Spatie Activitylog pour la traçabilité, et le package Flysystem SFTP de la League pour récupérer le flux quotidien SILAE (le logiciel de paie et de gestion RH du groupe). Trois autres briques sont déjà choisies mais seront installées plus tard, LdapRecord pour la bascule sur l'Active Directory réel en semaine 9, DomPDF pour les exports documentaires en semaine 12, et un parser CSV plus structuré (League Csv ou un wrapper maison) si le besoin émerge sur des flux d'export plus complexes que l'unique flux SILAE livré à ce jour.

Le contexte détaillé, l'historique du groupe, l'organigramme, les filiales, l'état de l'existant et le macro-planning prévisionnel sont documentés dans le rapport de lancement publié le 6 avril, je m'y réfère ici sans les reprendre. Un point n'y avait pas été abordé, le positionnement concurrentiel du groupe, que je complète ici.

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 (la principale filiale opérationnelle du groupe) fait face à des concurrents nettement plus gros, en particulier sur le secteur aéronautique. Les deux noms qui reviennent le plus souvent sont Labinal, filiale câblage de Safran Electrical & Power, leader mondial sur ce marché, et Latécoère Interconnection Systems (anciennement LATelec), spécialisée elle aussi dans le câblage embarqué chez Latécoère. Le positionnement de HIOLLE est différent. C'est une ETI familiale qui couvre plusieurs secteurs en parallèle, jusqu'au motorsport et au naval, et qui s'appuie sur plus d'une centaine de certifications métier pour rester légitime sur des marchés exigeants.

Sur un projet solo, deux risques se posaient dès la première semaine. Le premier, traîner sur des décisions faute d'interlocuteur direct. Le second, ne plus se rappeler en juin pourquoi telle option avait été retenue en avril. J'ai donc combiné plusieurs canaux d'échange en parallèle, dont voici le détail.

Le daily avec le maître de stage est le canal central. Tous les matins à 9h30, je passe entre 5 et 15 minutes avec Jérémy LOUVEAU. On fait le tour de ce que j'ai avancé la veille, je remonte les questions en suspens, et il valide ou redirige avant que j'aille coder. Le rythme a été cadré au daily du 30 mars autour d'un principe simple qui sert de fil conducteur, mieux vaut rattraper un jour de décalage qu'une semaine entière. Dans la pratique, le cadre reste assez souple, à la fois parce que l'emploi du temps de Jérémy LOUVEAU est chargé et parce qu'il préfère parfois me laisser de l'autonomie sur un sujet avant qu'on en reparle.

Les ateliers techniques avec Jean-Christophe ROY, référent données du groupe, ne sont pas planifiés à l'avance. Je le sollicite à la demande, dès qu'un arbitrage de modélisation ou de flux de données s'impose. Deux ateliers ont été structurants, celui du 3 avril sur la simplification de la table documents et la mise hors scope de la GED (Gestion Électronique de Documents), puis celui du 10 avril sur le refactor du schéma, avec extraction d'une table lieux, ajout d'un historique polymorphe et renommage du champ commentaire_validation. Le second a été en partie défait peu après. La table lieux extraite le 10 avril a été réabsorbée en colonnes plates le 15, après qu'on s'est rendu compte avec Jean-Christophe et Jérémy que cette indirection coûtait plus qu'elle n'apportait. Revenir sur un choix quand l'usage le contredit, c'est un réflexe que j'ai pris pendant ce stage.

La présentation au commanditaire métier, Julien CHAMAGNE, est prévue en semaine 7, après le 8 mai. Je veux d'abord livrer les 15 actions priorité 1 actées au daily du 28 avril. Le cœur en est la chaîne de validation des demandes de formation, le cas d'usage le plus attendu côté RH.

Le carnet de bord personnel est tenu en deux fichiers Markdown versionnés. Le premier est un mémo quotidien, plus libre, où je note ce que j'ai fait et ce qui mérite d'être retenu. Le second est un journal des décisions, plus formel, où chaque arbitrage de daily ou d'atelier devient une entrée datée avec contexte, décision, raison et conséquence. Au 29 avril, ce journal compte une vingtaine d'entrées. 5 tournants techniques y figurent : la validation de la stack, le passage à GitLab interne, la migration vers Tailwind 4, la refonte des mandats SILAE et le branchement de Spatie Activitylog pour l'audit trail.

Date	Acteur	Type	Décisions prises
26 mars	JLO	Point CDC	Suppression du rôle Directeur, priorités MVP, auth placeholder, dimensionnement VM confirmé
30 mars	JLO	Daily	Stack Laravel 13 + MariaDB 11.8 + Livewire 4 validée, modèle de données validé, nom Forma-Hiolle officialisé
31 mars	JLO	Daily	Méthode sans wireframes, revue live, rapports académiques sur temps de travail
3 avril	JLO	Daily	Revue rapport de lancement, UI validée
3 avril	JC	Atelier	Noyau d'abord, planning en priorité absolue, table documents simplifiée
10 avril	JC	Atelier	Refactor schéma, table lieux, historique polymorphe, rename commentaire
10 avril	JLO	Mini-point	Flux SILAE en SFTP à 3h du matin
15 avril	JLO	Daily	Permission fine manager sur plans, combobox searchable, pattern dismiss vs close
17 avril	JLO	Daily	Pousse en production v0.4.7, anticipation page admin utilisateurs
20 avril	JLO	Daily	Restructuration sidebar par packages, isolation manager récursive, démo Julien CHAMAGNE planifiée
21 avril	JLO	Daily	Livraison SFTP SILAE anticipée, questions refonte mandats
24 avril	JLO	Daily	Validation refonte mandats v0.5.0, préparation pousse en production consolidée
27 avril	JLO	Daily	Démonstration en production des versions 0.5.0 à 0.5.3, import réel de 632 salariés réussi
28 avril	JLO	Daily de cadrage	11 sujets traités, 15 actions priorité 1 sur la chaîne formation, plan S6 à S13 révisé

Le tableau ci-dessus n'en retient que les plus structurants, d'autres points plus brefs se sont tenus en complément au fil des semaines. JLO désigne Jérémy LOUVEAU, JC désigne Jean-Christophe ROY.

Environnement de développement local. Mon poste fixe Windows 11 fourni par l'entreprise accueille toute la chaîne, Visual Studio Code pour l'édition, un terminal Bash, Git pour le versionnement, Composer et Artisan pour Laravel, Node et Vite pour la partie front. Le PHP local tourne en 8.4, aligné sur le serveur de production pour éviter les surprises au déploiement.

Infrastructure d'hébergement. Deux machines ont été mises à disposition ou déployées pendant les deux premières semaines. Le serveur applicatif Forma-Hiolle, VM Debian 13 dotée de 2 vCPU et 4 Go de RAM, héberge PHP 8.4, MariaDB 11.8, Nginx (serveur web) et le code de l'application. La seconde VM, dédiée à GitLab, a été montée en GitLab CE auto-hébergé. Elle joue à la fois le rôle de dépôt Git interne et de runner pour la CI/CD. Chaque push sur la branche main du dépôt Laravel déclenche un pipeline automatique qui enchaîne le pull distant, les migrations incrémentales (jamais de fresh en prod), la reconstruction des assets Vite et la purge des caches. La chaîne tourne depuis le 3 avril et a servi pour les déploiements successifs entre les semaines 2 et 6. Le plus gros lot de cette période, la pousse consolidée des versions 0.5.0 à 0.5.4, a été poussé le 27 avril après une régularisation du runner GitLab interne, dont je détaille les difficultés plus loin.

Outils de suivi et traçabilité. 5 fichiers Markdown se partagent ce rôle. Un fichier suivi-projet.md rassemble l'état d'avancement hebdomadaire. Un journal des décisions distinct trace les choix structurants avec leur contexte et leur impact. Deux backlogs séparés répertorient d'un côté les améliorations UX livrables dans le MVP, de l'autre les bonus envisagés après consolidation du socle. Enfin, un fichier highlights-techniques-rapport.md recense au fil de l'eau les moments techniques que je veux pouvoir réutiliser dans les rapports et la soutenance, sans les reconstituer de mémoire à la dernière minute. Au 29 avril, il compte 16 entrées.

Audit trail applicatif (exploratoire). Le 23 avril, j'ai branché le package Spatie Activitylog sur 10 modèles métier sensibles. Chaque création, modification ou suppression alimente désormais une table activity_log dédiée, et une route /audit-trail expose ces traces aux gestionnaires depuis leur menu profil, avec un diff avant et après pour chaque action. À ce stade, c'est uniquement un dispositif technique mis en place côté code. Les décisions métier autour, qui peut consulter ces traces, combien de temps les conserver, à quel cadre de conformité on souhaite les rattacher, restent à trancher avec Jérémy LOUVEAU et le commanditaire. Sur le plan technique, l'outil sert déjà comme deuxième ligne d'observabilité, utile pour déboguer en production en complément du journal humain des décisions.

Dépôts Git et sauvegarde. La stratégie repose sur deux dépôts distincts et complémentaires. Le dépôt stage-hfp26 sur GitHub, en visibilité privée, héberge uniquement les éléments d'accompagnement du stage : la documentation interne, les rapports académiques, les mémos quotidiens, les notes de veille et les comptes-rendus de réunion. Le code de l'application n'y figure pas. Celui-ci vit exclusivement sur le dépôt forma-hiolle du GitLab interne, qui n'est accessible que depuis le réseau du groupe. La séparation a un objectif clair, aucun code applicatif et aucune donnée métier interne ne sont jamais exposés sur un dépôt externe, et la documentation et les rapports bénéficient quand même d'une sauvegarde hors site, accessible depuis mon compte personnel.

Cahier des charges. Au démarrage, je disposais d'un cahier des charges (CDC) en version V3, rédigé par le service systèmes d'information avant mon arrivée. J'en ai produit dès la première semaine une version enrichie, le CDC V4, qui ajoute la priorisation MVP, une matrice rôles et permissions affinée, les définitions métier consolidées et les workflows de validation détaillés. Jérémy LOUVEAU l'a validé au point du 26 mars.

Cadre technique imposé par l'existant. Le projet s'inscrit dans un écosystème SI déjà constitué dont il faut respecter les points d'ancrage. L'authentification s'appuie sur l'Active Directory du groupe, référentiel unique des comptes utilisateurs, ce qui évite de créer un silo d'identités supplémentaire. Les flux d'échange avec les autres SI du groupe, à commencer par SILAE pour les salariés, sont normés en CSV avec point-virgule en séparateur, format standard de fait au sein de l'écosystème SI. L'application est hébergée sur une VM Debian dédiée, dimensionnée selon le standard interne et suffisante pour le profil de Forma-Hiolle. Côté outillage, le projet n'introduit aucune nouvelle licence ni service cloud managé, en cohérence avec la politique du pôle SI pour les développements internes. Dernière exigence, la pérennité au-delà du stage : le code doit rester maintenable par les futurs développeurs et mainteneurs du groupe.

Legacy 2024 analysé. Un ancien projet HFP, lancé l'année précédente par d'autres intervenants mais jamais mis en production, m'a été transmis avec l'ensemble du code source. Je l'ai analysé pendant la première semaine, environ 2 400 fichiers PHP. Les problèmes sont nombreux : un framework maison réinventé, aucun test, des vulnérabilités SQL par concaténation, pas de migrations versionnées, plusieurs vues inachevées. J'ai gardé chacun de ces points comme un repère inversé. À chaque fois, Forma-Hiolle prend le contre-pied : Laravel à la place d'un framework maison, des migrations versionnées dès le premier jour, des requêtes paramétrées via l'ORM Eloquent par défaut, et des tests PHPUnit ajoutés progressivement.

Décisions métier majeures consolidées depuis le lancement. Plusieurs points laissés ouverts dans le CDC V3 ont été tranchés en ateliers. Les salariés restent en lecture seule dans Forma-Hiolle, leur source de vérité étant SILAE via un import quotidien. La messagerie avec les organismes de formation a été sortie du scope et remplacée par des notifications email. Les entretiens individuels passent eux aussi hors scope du stage, ils seront repris dans une phase ultérieure. Enfin, le périmètre V1 reste limité à la France, comme indiqué dans le rapport de lancement et reconfirmé au point du 3 avril.

Plusieurs objectifs annoncés dans le rapport de lancement ont été précisés ou simplifiés au fil des points avec le maître de stage et le référent données.

Simplification de la matrice rôles. Le rôle Directeur figurait dans le CDC V3, il a été retiré au point CDC du 26 mars. Restent 3 rôles effectifs : gestionnaire (côté service formation), manager (chef d'équipe), salarié (qui consulte et demande). On y gagne deux fois : l'intégration Active Directory devient plus simple, et la matrice de permissions s'allège sans pour autant rogner sur le besoin métier exprimé.

Officialisation du nom du projet. Le 30 mars, le nom de code HFP26 a cédé la place au nom officiel Forma-Hiolle. Le choix associe la fonction (la formation) à l'identité du groupe. Les chemins techniques de dossiers conservent encore la mention HFP26 pour stabilité, mais tous les documents et l'interface utilisateur affichent désormais Forma-Hiolle.

Priorisation MVP consolidée en 9 CRUDs métier. Le CDC V3 listait des dizaines d'entités et de fonctionnalités sans priorisation claire. Le CDC V4 que j'ai rédigé, validé par Jérémy LOUVEAU le 26 mars, ramène le MVP à 9 CRUDs métier : Catégorie, Certification, Organisme, Modèle de formation, Formation, Inscription, Plan de formation, Demande de formation, et Salarié en lecture seule. Les modules autour (dashboards, notifications, documents PDF, questionnaires d'évaluation) sont déplacés en semaines 8 à 9, une fois le socle stable.

Les entités centrales du domaine ont été précisées avec Jérémy LOUVEAU et Jean-Christophe ROY.

Terme	Définition retenue
Formation	Événement unique daté, avec des apprenants affectés
Modèle de formation	Template réutilisable servant à générer des formations
Session	Formation passée, historisée pour le passeport
Plan de formation	Listing de formations prévues sur une année, pour une entité
Catalogue	Ensemble des modèles de formations connus dans le groupe
Demande de formation	Requête émise par un salarié ou son manager, à valider par un gestionnaire

Le CDC V4 définit 3 rôles utilisateurs. Leurs responsabilités ont été affinées au fil des dailys avec le maître de stage.

Rôle	Lecture	Écriture catalogue	Plans	Demandes
Gestionnaire	Complète	Oui	Oui	Valide
Manager	Équipe	Non par défaut	Conditionnelle	Valide son équipe
Salarié	Personnelle	Non	Non	Émet pour lui

Depuis le 17 avril, la permission de création d'un plan de formation est gérée finement. Un manager ne peut en créer que si un gestionnaire lui active le droit, au cas par cas. Le mécanisme prépare déjà la future page d'administration des utilisateurs.

Au-delà des choix techniques, le projet vise quatre bénéfices métier mesurables. Les cibles ci-dessous sont prévisionnelles, à confirmer avec le commanditaire Julien CHAMAGNE et à mesurer après la mise en service post-stage.

Indicateur	Bénéfice visé	Cible prévisionnelle
Délai moyen entre la demande de formation et sa validation	Réduction du temps de traitement RH	Sous 5 jours ouvrés
Taux de certifications réglementaires à jour	Conformité métier (CACES, HAB, SST, IRIS, EN 9100)	Plus de 95 % de certifications valides à toute date
Pourcentage de plans de formation validés avant clôture d'exercice	Pilotage du budget annuel	100 % avant clôture
Taux d'adoption par rôle	Remplacement effectif des tableurs Excel actuels	Plus de 80 % des actions métier passent par Forma-Hiolle après 3 mois

La pile applicative a été validée par Jérémy LOUVEAU au daily du 30 mars, après une veille comparative que je détaille plus bas.

Couche	Technologie retenue	Version	Statut au 29 avril
Langage serveur	PHP	8.4	Installé
Framework	Laravel	13.2	Installé
Base de données	MariaDB	11.8	Installé
Interface dynamique	Blade et Livewire	4.2	Installé
Styles	Tailwind CSS	4.2	Installé
Permissions fines	Spatie Permission	7.2	Installé
Audit trail applicatif	Spatie Activitylog	5.0	Installé (23 avril)
Récupération SFTP du flux SILAE	League Flysystem SFTP v3	3.33	Installé (21 avril)
Parsing CSV de l'unique flux entrant	str_getcsv natif PHP 8.4	natif	Installé, pas de package tiers à ce stade
Authentification Active Directory	LdapRecord-Laravel	3.x	Choisi, installation en semaine 9
Génération PDF (passeport, convocation, attestation)	DomPDF (barryvdh)	3.x	Choisi, installation en semaine 12

La sélection a été guidée par 6 critères objectifs.

• Adéquation fonctionnelle au besoin exprimé
• Intégration avec l'Active Directory et les flux CSV existants
• Facilité de déploiement sur la VM Debian dédiée
• Faisabilité par un développeur seul sur 12 semaines effectives
• Pérennité, maintenabilité par l'équipe interne
• Coût, zéro licence

Quatre familles de stack ont été étudiées avant de trancher. Le tableau ci-dessous synthétise les notes attribuées sur chaque critère, sur une échelle qualitative de 1 à 5.

Critère	Laravel 13	Symfony 7	Node.js	Django
CRUDs RH, workflows, permissions	5	5	3	4
Intégration LDAP et Active Directory	5	4	3	4
Génération PDF, gestion CSV	5	5	3	4
Productivité en solo sur 12 semaines	5	3	3	4
Déploiement sur Debian modeste	5	4	4	4
Maintenabilité post stage par l'équipe interne du groupe	5	4	2	2
Documentation officielle et communauté française	5	5	4	3
Score total sur 35	35	30	22	25

Laravel 13 sort en tête. Trois facteurs pèsent lourd, l'interactivité sans JavaScript dédié grâce à Livewire, la disponibilité de packages éprouvés pour les briques à venir (Spatie pour les permissions et l'audit trail déjà en place, LdapRecord et DomPDF planifiés en semaines 9 et 12), et l'alignement avec l'écosystème technique en place côté équipes internes. Symfony arrive second. Il est meilleur sur la rigueur d'architecture, mais sa courbe d'apprentissage est moins adaptée à un démarrage solo avec un délai contraint.

Les attentes non fonctionnelles ont été posées dès le point CDC du 26 mars et affinées lors de la veille technologique.

Critère	Cible
Volume utilisateurs attendu	Population groupe d'environ 1 100 collaborateurs, partiellement représentée dans l'Active Directory (les profils atelier sans mail pro restent à arbitrer). Cible de charge concurrente à formaliser après la bascule AD réelle en semaine 9
Volume salariés en base	632 salariés réels importés en production le 27 avril, dataset stable, ajustements quotidiens
Temps de réponse perçu sur interaction Livewire	Sous 300 millisecondes pour les CRUDs fréquents, cible perçue, mesures formalisées en semaine 10 lors de la phase tests fonctionnels par rôle
Temps d'import SILAE complet	Cible sous 3 minutes, mesuré à 2 min 20 s en production sur les 632 salariés avec cumuls de mandats
Empreinte RAM du serveur	4 Go maximum, marge confortable pour Nginx, PHP-FPM (gestionnaire de processus PHP) et MariaDB
Nombre de tests PHPUnit verts	Trente-six tests au 29 avril, dont les batches d'isolation manager récursive et d'audit trail livrés en semaine 5, objectif de couvrir les scénarios critiques de la chaîne de validation en semaine 10

Justification du choix Livewire sur faible RAM. Livewire s'exécute côté serveur en PHP, sans runtime Node permanent. On économise donc d'office la consommation mémoire qu'aurait pris un runtime Node permanent en arrière-plan. Le build des assets reste fait en local via Vite, et Nginx sert directement les fichiers compilés. Le serveur n'a rien à compiler ni à exécuter en JavaScript. Au final, l'empreinte mémoire reste largement en dessous des 4 Go alloués à la VM.

Capacité mesurée au 29 avril. Les 32 migrations s'appliquent en moins de 10 secondes sur SQLite en local et en moins de 20 secondes sur MariaDB. Les 36 tests PHPUnit s'exécutent en parallèle en moins de 6 secondes. L'import SILAE complet, soit 632 lignes avec cumuls de mandats et résolution récursive des managers, a tourné en production le 27 avril en 2 min 20 s. Il reste une marge confortable avant le seuil de 5 min que je m'étais fixé.

Ma veille s'est articulée autour de 4 axes, chacun motivé par une décision concrète à prendre pour le projet.

Choix du framework serveur. J'ai comparé Laravel 13, Symfony 7, Django 5 et plusieurs stacks Node.js modernes (Express, Fastify). Pour chaque candidat, je suis allé lire la documentation officielle, j'ai parcouru les benchmarks publiés sur TechEmpower et regardé plusieurs retours d'expérience publiés en français, notamment sur Grafikart et LaravelFrance. Le changelog officiel de Laravel 13 m'a aussi servi à m'assurer que les nouveautés récentes, dont la refonte du bootstrap et le passage de Livewire 4 en package officiel, étaient stables au moment de démarrer.

Intégration Active Directory. J'ai étudié 3 pistes côté Laravel, LdapRecord-Laravel, Ldap PHP natif, et un schéma Sanctum derrière un reverse proxy qui pré-authentifie. La documentation de LdapRecord, sa popularité sur GitHub et surtout les tutoriels qui détaillent un mode placeholder sans serveur AD réel m'ont convaincu. C'était la piste la plus adaptée à un développement où l'AD distant n'est pas disponible en local. Le package n'est pas encore installé au 29 avril, son intégration est planifiée pour la semaine 9 conformément au plan révisé au daily du 28 avril.

Patterns de permissions fines. J'ai comparé Spatie Permission et Bouncer. Spatie l'emporte sur 4 points : popularité, maintenance active, documentation claire, compatibilité immédiate avec Laravel 13. Je l'ai mis en pratique en phase 6 avec le droit creer_plan_formation, attribuable à un manager précis sans toucher au rôle global. Tout est centralisé dans un seul PermissionSeeder, donc ajouter une permission demain ne demandera qu'une ligne supplémentaire.

Tailwind CSS 4. La version 4 du framework CSS est sortie en janvier 2025 avec un moteur réécrit, une configuration en CSS-first et des container queries natives. Le projet avait démarré en 3.4 (valeur par défaut de Breeze), j'ai donc piloté la migration vers 4.2 le 8 avril, après avoir épluché le guide officiel de migration, le changelog détaillé et quelques retours d'expérience sur la migration d'un projet existant.

Le marché de la gestion de formation se découpe en plusieurs grandes familles de solutions. Je les ai parcourues pour positionner Forma-Hiolle par rapport à l'offre existante.

Solutions SaaS spécialisées françaises.

• Digiforma, à partir de 79 euros par mois pour une PME, cible les organismes de formation. Son point fort, c'est la conformité Qualiopi et la génération de documents réglementaires. Conçu pour l'externe, l'outil est peu adapté à un usage intranet groupe.
• Dendreo, tarification proche de Digiforma, joue sur le même créneau avec un meilleur outillage côté suivi commercial et relations avec les OPCO (Opérateurs de Compétences, organismes financeurs de la formation professionnelle en France). Même limite, l'outil est pensé pour des organismes qui vendent de la formation, pas pour un groupe industriel qui gère son propre catalogue interne.

LMS (Learning Management System) généralistes.

• Moodle, open-source et gratuit, domine dans l'enseignement supérieur et chez certains organismes. Très complet sur le e-learning, la création de contenus pédagogiques et les évaluations automatisées. Le paradigme est différent de celui de HIOLLE, qui ne cherche pas à diffuser du contenu en ligne mais à piloter le planning et la conformité des formations menées par des organismes externes ou internes.
• 360Learning, SaaS français, met l'accent sur l'apprentissage collaboratif et les parcours pédagogiques. Hors scope ici, on parle d'un besoin orienté planning et passeport de compétences.

Modules RH des ERP.

• SAP SuccessFactors, Workday, Cornerstone OnDemand. 3 solutions globales de gestion des talents, dont le module formation n'est qu'une brique parmi de nombreuses autres. Tarification à plusieurs dizaines de milliers d'euros par an, déploiement typiquement étalé sur 6 à 18 mois, et il faut idéalement déjà avoir un environnement SAP ou équivalent pour en tirer la pleine valeur. Ce n'est pas le contexte HIOLLE, et le coût total resterait incompatible avec ce que l'entreprise attend.

Conclusion du positionnement. Forma-Hiolle se distingue comme un outil sur mesure, intranet, léger, gratuit hors infrastructure interne, branché nativement sur l'Active Directory et les flux CSV SILAE. Le sur-mesure ne se justifie pas dans tous les cas, mais ici les conditions sont réunies. Les besoins métiers sont stables et bien circonscrits. Le volume d'utilisateurs reste contenu à 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 simple confort technique. Les solutions du marché embarqueraient trop de fonctionnalités hors scope, pour un coût récurrent qui ne se rentabiliserait pas.

La veille ne s'est pas arrêtée le 30 mars avec la validation de la stack, elle a continué au fil des problèmes rencontrés et des décisions à prendre.

Livewire 4 et patterns réactifs. La phase 3.3 du 13 avril m'a forcé à lire en détail la documentation Livewire sur l'hydratation des template x-for d'Alpine. Le piège : les checkboxes d'inscriptions ne se pré-cochaient pas. La solution est passée par un état local Alpine synchronisé au save, que j'ai documenté dans un mémo interne. Ce genre de découverte m'a poussé à tenir un carnet de pièges réactifs Livewire/Alpine, qui en compte 7 à ce jour.

Flysystem SFTP v3 pour le flux SILAE. La Phase S6, livrée le 21 avril, m'a fait choisir un adapter SFTP. J'ai comparé 3 options : league/flysystem-sftp-v3, phpseclib natif, et spatie/flysystem-dropbox réadapté. Le package League s'est imposé sur 2 critères, sa compatibilité native avec le système de disques de Laravel 13 et une maintenance active.

LdapRecord en mode placeholder. Le daily du 26 mars a acté que je n'aurais pas accès à l'Active Directory réel en développement. J'ai donc lu la documentation de LdapRecord-Laravel pour vérifier qu'il supporte un mode placeholder, avec bascule vers l'AD réel en production. Cette veille continue en vue de la bascule, désormais positionnée en semaine 9 selon le plan révisé du 28 avril. Je l'ai déjà complétée avec la livraison, le 23 avril, d'un service UtilisateurProvisionService qui prépare le provisioning massif des comptes en attendant le branchement effectif du LDAP.

• Laravel 13 et notes de version, laravel.com/docs/13.x
• Livewire 4, documentation et pièges réactifs, livewire.laravel.com
• Tailwind CSS 4, guide de migration 3 vers 4, tailwindcss.com/docs/upgrade-guide
• Alpine.js, directives et scopes, alpinejs.dev
• Spatie Laravel Permission, spatie.be/docs/laravel-permission
• LdapRecord Laravel, ldaprecord.com/docs/laravel/v3
• DomPDF (barryvdh/laravel-dompdf), github.com/barryvdh/laravel-dompdf
• League Flysystem v3 et adapter SFTP, flysystem.thephpleague.com
• League Csv 9, csv.thephpleague.com

• Benchmarks TechEmpower, techempower.com/benchmarks
• Grafikart, articles Laravel et Livewire, grafikart.fr
• LaravelFrance, communauté francophone
• Changelog officiel PHP 8.4, php.net/releases/8.4/fr.php

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

• Grille d'évaluation L305, Université de Limoges
• Guide d'auto-hébergement WordPress étudiant, hosting.unilim.fr

Au 29 avril, la base compte 32 migrations versionnées, pour à peu près 29 tables métier effectives. La structure principale est tenue à jour dans un fichier DBML versionné dans le dépôt. Les entités centrales suivent une logique métier qui n'a plus bougé depuis les points techniques du 3 et du 10 avril avec Jean-Christophe ROY.

J'ai introduit le 10 avril une relation polymorphe historique_statuts, un mécanisme Eloquent qui permet à une seule table d'être rattachée à plusieurs modèles parents, pour tracer le cycle de vie des formations, modèles et demandes sans avoir à dupliquer la même logique sur 3 tables.

Le 22 avril, dans le cadre de la refonte v0.5.0, j'ai ajouté 2 nouvelles tables dédiées. La première, salarie_mandats, sert à représenter les cumuls de postes d'un même salarié, qu'on observe vraiment dans le flux SILAE réel. La seconde, imports_silae_historique, garde une trace de chaque exécution de la commande d'import avec son statut et ses statistiques. Le 23 avril, le package Spatie Activitylog est venu ajouter une table activity_log qui journalise les créations, modifications et suppressions sur 10 modèles métier sensibles. Le détail de ces évolutions figure dans la sous-section 6.5 sur les problèmes rencontrés.

À la date du 29 avril, l'application Forma-Hiolle expose 10 composants Livewire couvrant chacun une partie du domaine métier.

Composant	Rôles concernés	Livré en version
CategorieTable	Gestionnaire	0.2
CertificationTable	Gestionnaire	0.2
OrganismeTable	Gestionnaire	0.2
ModeleFormationTable	Gestionnaire	0.2
FormationTable	Gestionnaire, manager, salarié	0.2, 0.3
SalarieTable	Gestionnaire, manager	0.3
PlanFormationTable	Gestionnaire, manager	0.4
DemandeFormationTable	Tous les rôles	0.4.1
MesFormationsTable	Tous les rôles	0.4.8
ActivityLogTable	Gestionnaire	0.5.1

Tous ces composants respectent le même pattern Livewire 4, avec une défense en profondeur appliquée à chaque méthode publique, via un couple de helpers authorizeAccess et authorizeWrite harmonisés le 17 avril. Cette base a été enrichie le 24 avril par un scope Eloquent réutilisable, Salarie::scopeVisibleBy, qui implémente l'isolation hiérarchique récursive des managers.

La progression versionnée suit un SemVer strict adapté à un MVP non livrable publiquement.

Version	Date	Livrable principal
0.2	7 avril	Socle, 5 CRUDs référentiel
0.3	8 au 10 avril	Inscriptions, refonte sidebar, refactor BDD avec Jean-Christophe ROY
0.4.0	14 avril	Plans de formation, navigation cross-CRUDs
0.4.1	14 avril	Demandes de formation, phase 2 MVP
0.4.2	15 avril	Rollback table lieux, simplification modèle
0.4.3	15 avril	Traitement du daily, phases 1 à 3
0.4.4 et 0.4.5	16 avril	Composant combobox searchable, polish UI
0.4.6	17 avril	Permission manager conditionnelle sur les plans
0.4.7	17 avril	Fix bug latent certifications, polish sidebar, pousse en production
0.4.8 à 0.4.153	20 avril	Refonte sidebar 3 packages, pré-lecture modèle, tooltip dernière utilisation, drawer filtres unifié sur 5 CRUDs, tri avancé sur compteurs
0.4.154 à 0.4.158	21 avril	Passe qualité, 7 correctifs ciblés, 9 tests PHPUnit verts, composant catalog-link réutilisable
0.4.159 à 0.4.163	21 avril soir	Phase A SILAE, schéma salariés aligné, 10 codes filiales SILAE réels, commande Artisan silae:import-salaries, scheduler nocturne
0.5.0	22 avril	Refonte des mandats SILAE, support des cumuls, table salarie_mandats dédiée, dénormalisation contrôlée, historique des imports, auth massive des utilisateurs
0.5.1	23 avril	Pack qualité professionnel, PHPStan niveau 5, Pint, healthcheck /health, journalisation structurée JSON, 2 ADR (Architecture Decision Records) au format MADR (Markdown ADR), audit trail Spatie Activitylog sur 10 modèles, batches de tests étendus
0.5.2	24 avril	Phase C isolation manager récursive, scope Eloquent Salarie::scopeVisibleBy, propagation sur quatre composants, doc Diátaxis (cadre de structuration de la documentation technique) dédiée, 6 nouveaux tests, total à 36 verts
0.5.3	27 avril	Auto-création des filiales SILAE inconnues, libellé court contextuel sur les divisions, idempotence du seeder Filiale
0.5.4	28 avril	Sprint UX issu du daily de cadrage, 5 actions atomiques, scheduler décalé à 4h30, blocage des dates passées sur les demandes, tableau salariés réorienté sur la division

Chaque version est poussée sur GitLab puis automatiquement déployée sur le serveur applicatif via le pipeline d'intégration continue, sans intervention manuelle. Les versions 0.5.0 à 0.5.3 ont été poussées en production sur le serveur applicatif le 27 avril en pousse consolidée, suivies de la 0.5.4 le 28 avril après le daily de cadrage.

Quasiment chaque daily comporte une démonstration en direct de ce qui a été livré la veille. Le but est de valider visuellement avant d'aller plus loin, ce qui réduit le risque de partir trop vite dans une mauvaise direction. Les démonstrations les plus structurantes sont listées ci-dessous.

Date	Public	Démonstration	Retour et suite
3 avril	JLO	Dashboard par rôle, sidebar repliable, fond blanc, barre bleu marine	Direction visuelle validée, dashboard reporté après fonctionnalités
14 avril	JLO	CRUDs Plans de formation et Demandes de formation, navigation cross-CRUDs	Validation du scope, anticipation d'une semaine sur le planning
15 avril	JLO	Combobox searchable sur 4 écrans, pattern dismiss vs close	Retour positif, demande d'étendre au filtre certifications
17 avril	JLO	Permission manager conditionnelle sur les plans, pousse en production v0.4.7	Validation, anticipation de la page d'administration des utilisateurs
20 avril	JLO	Refonte sidebar en 3 packages par rôle, drawer filtres unifié, tri avancé sur compteurs	Validation complète, demande de présenter la chaîne de validation au prochain daily
22 avril	JLO	Version 0.4.158 déployée en production, tour de l'UX remanié	Retour positif, déblocage de la démonstration commanditaire
22 avril	JLO (démo locale)	Refonte des mandats SILAE v0.5.0, cumuls de postes sur les dirigeants affichés en fiche salarié	Validation technique, questions métier portées au daily suivant
24 avril	JLO (daily)	Phase C isolation manager récursive en navigateur local, audit trail branché sur 10 modèles, 6 nouveaux tests verts	Validation, déclenchement de la pousse consolidée prévue le 27 avril
27 avril	JLO (daily)	Démonstration sur le serveur applicatif des versions 0.5.0 à 0.5.3 fraîchement déployées, import SILAE réel de 632 salariés en 2 minutes 20 secondes, garde anti-fermeture déclenchée sur la filiale AMODIAG absente du flux	Validation, ouverture de l'accès lecture seule à Jean-Christophe ROY pour stress-test côté données
28 avril	JLO (daily de cadrage)	Tour complet de l'application en production, parcours des 3 rôles, focus sur la chaîne de validation des demandes	11 sujets traités, 15 actions priorité 1 listées pour le 8 mai, 5 d'entre elles livrées dans la foulée en v0.5.4

À côté des dailys, 2 ateliers techniques avec Jean-Christophe ROY se sont tenus en mode démo interactive, l'un le 3 avril sur la table documents, l'autre le 10 avril sur le refactor du schéma avec la table lieux et l'historique polymorphe. Leurs conclusions ont nourri les décisions de refactor du 15 avril, dont le rollback de la table lieux que j'ai mentionné plus tôt.

J'ai rencontré et résolu plusieurs difficultés techniques non triviales depuis le démarrage du stage. Le détail complet figure dans le dépôt, je résume ici les plus marquantes.

Migration Tailwind CSS 3 vers 4, le 8 avril. Le projet avait démarré en version 3, héritage du scaffolding Breeze, alors que la pile technique validée annonçait la 4. La bascule a demandé de réécrire la configuration, de revoir la syntaxe des classes et de retirer 3 dépendances devenues obsolètes. Au final, aucune régression visuelle détectée.

Bug de production après migrate:fresh, le 9 avril. Un déploiement sur le serveur applicatif a fait remonter des erreurs 419 partout. La cause est venue du driver de sessions en base, qui se faisait wiper par la commande. J'ai documenté une procédure de redéploiement enchaînant 4 commandes de purge de caches, qui sert depuis de référence en interne.

Bug latent de permissions sur /certifications, identifié le 15 avril et corrigé le 17 avril. La route autorisait le rôle salarié, mais le composant faisait quand même un abort(403) au montage pour tout non-gestionnaire. Le fix s'est fait en 2 temps, j'ai d'abord restreint la route et retiré le lien de la sidebar, puis posé la spécification d'un composant dédié MesCertificationsTable à livrer en phase 7.

5 bugs non triviaux sur le composant combobox searchable, les 15 et 16 avril. J'ai voulu livrer un composant de recherche réutilisable <x-searchable-select>, piloté par Alpine avec filtrage côté client (zéro round-trip réseau). 5 bugs se sont enchaînés, que j'ai diagnostiqués un à un avec Playwright en mode headless. Les causes ont été instructives, parce qu'elles touchaient à plusieurs spécificités des frameworks réactifs modernes : un timing à l'initialisation d'Alpine quand on charge en module défer, qui s'est résolu en exposant la fonction sur window ; des proxies Alpine non identiques entre la closure et le dispatch, qui m'ont obligé à passer un identifiant string stable plutôt qu'une référence ; et plusieurs problèmes de portée et de fusion d'attributs Blade. Au bout du compte, le composant tourne sur quatre CRUDs critiques et a été validé en navigation.

Refonte des mandats SILAE v0.5.0, le 22 avril. Le tout premier test d'import sur un flux SFTP réel a fait surgir trois problèmes en même temps. D'abord, trois matricules portaient des cumuls de mandats légitimes, par exemple un même salarié à la fois Directeur général et Directeur général délégué d'une division. Ces cumuls, l'upsert initial par matricule les écrasait silencieusement. Ensuite, le CSV contenait du mojibake UTF-8 double-encodé, du genre Directeur Général au lieu de Directeur Général. Et pour finir, la filiale AMODIAG était passée de soixante salariés à zéro entre la veille et ce matin-là, conséquence d'un export SILAE défaillant côté source. J'ai préféré une refonte durable. J'ai créé une nouvelle table salarie_mandats qui supporte les cumuls, et une seconde table imports_silae_historique pour tracer chaque exécution. La colonne salaries.poste est conservée comme cache du mandat principal, ce qui évite de casser les vues existantes (stratégie de dénormalisation contrôlée). La détection du mojibake se fait avant correction, pour éviter de recorrompre un flux qui aurait été assaini un jour à la source. Une garde anti-fermeture massive bloque la mise hors ligne de tous les salariés d'une filiale si celle-ci disparaît brutalement du flux. Jérémy LOUVEAU a validé le tout au daily du 24 avril. La première exécution en production, le 27 avril, a importé les 632 salariés et a effectivement déclenché la garde sur AMODIAG, encore absente du flux ce matin-là.

Régularisation du pipeline GitLab, le 27 avril. La pousse consolidée des versions 0.5.0 à 0.5.3 a tâtonné sur quatre tentatives avant de réussir. La première cause, c'est deux commits créés sans le faire exprès avec un compte de messagerie personnel à la place du compte professionnel HIOLLE, faute de configuration Git conditionnelle entre dépôts. Une force-push contrôlée a purgé les deux commits, j'ai ré-aligné la branche main du dépôt interne sur la version stable précédente avant de re-pousser proprement. La deuxième cause, c'est le pack qualité v0.5.1 qui avait ajouté un stage quality au pipeline (Pint, PHPStan, PHPUnit), alors que le runner GitLab interne ne tourne pour l'instant qu'en environnement shell, sans PHP ni Composer installés. J'ai mis les jobs quality en when: manual avec allow_failure: true pour ne pas bloquer le déploiement, en attendant l'installation de PHP sur le runner ou un passage à un exécuteur Docker. La troisième cause était cosmétique, le healthcheck final cherchait à écrire sur /dev/stderr via tee, ce qui levait une permission refusée sur le runner shell. J'ai retiré la redirection. La quatrième tentative a abouti, et le healthcheck /health a confirmé la mise en ligne. L'incident a laissé deux notes internes, l'une pour configurer un gitconfig conditionnel côté poste de développement, l'autre pour préparer l'installation de Docker sur le runner GitLab interne en prévision d'un nouveau membre dans l'équipe SI.

Cette section donne à voir un aperçu visuel de l'application en fonctionnement, ainsi que deux extraits de code qui illustrent des patterns mis en place dans le projet.

Captures de l'application

Figure 3 : Sidebar repliable, vue gestionnaire

Cette courte animation illustre la décision JLO du 20 avril sur la restructuration de la sidebar en 3 packages par rôle (Administration, Groupe, Personnel), avec mini-titres clairs plutôt que des labels génériques. On y voit la sidebar dépliée au survol des onglets, puis repliée en mode pin fin. Le contenu central visible derrière est un placeholder hérité du scaffolding Breeze, les dashboards par rôle ne sont pas encore développés et viendront en fin de stage.

Figure 4 : Listing des salariés, vue manager et vue gestionnaire (Phase C)

Vue manager (mdupont)

Vue gestionnaire (jlouveau)

Le manager ne voit que sa hiérarchie descendante, le gestionnaire voit l'ensemble. L'isolation est appliquée par un scope Eloquent réutilisable (Salarie::scopeVisibleBy) propagé sur les quatre composants Livewire concernés. Le code correspondant est donné dans l'extrait 1 ci-après.

Figure 5 : Audit trail applicatif (dispositif exploratoire, livré le 23 avril)

Le package Spatie Activitylog est branché sur dix modèles métier sensibles. Chaque création, modification ou suppression alimente une table dédiée et apparaît sur la route /audit-trail réservée aux gestionnaires, avec un diff avant et après. La politique métier qui l'accompagnera (rétention, conformité) reste à arbitrer avec le commanditaire ; en attendant, l'outil sert comme deuxième ligne d'observabilité pour déboguer en production.

Extraits de code représentatifs

Extrait 1 : scope d'isolation manager récursive. Le scope Eloquent visibleBy filtre les salariés selon le rôle Spatie de l'utilisateur connecté. La méthode descendantIds parcourt l'arborescence manager_id en parcours en largeur (BFS) avec un visited set, garde de robustesse contre un éventuel cycle pathologique dans la hiérarchie remontée par l'AD.

// app/Models/Salarie.php (extrait condensé)

public function descendantIds(int $maxDepth = 10): array
{
    $collected = [];
    $frontier = [$this->id];
    $visited = [$this->id];
    $depth = 0;

    while ($depth < $maxDepth) {
        $next = static::query()
            ->whereIn('manager_id', $frontier)
            ->whereNotIn('id', $visited)
            ->pluck('id')->map(fn ($id) => (int) $id)->toArray();

        if (empty($next)) break;

        $collected = array_merge($collected, $next);
        $visited = array_merge($visited, $next);
        $frontier = $next;
        $depth++;
    }

    return $collected;
}

public function scopeVisibleBy(Builder $query, ?Utilisateur $user): Builder
{
    if (! $user) return $query->whereRaw('1 = 0');

    if ($user->hasRole('gestionnaire')) {
        return $query;
    }

    if ($user->hasRole('manager')) {
        $self = static::find($user->salarie_id);
        $ids = array_merge([$self->id], $self->descendantIds());
        return $query->whereIn('salaries.id', $ids);
    }

    if ($user->hasRole('salarie')) {
        return $query->where('salaries.id', $user->salarie_id);
    }

    return $query->whereRaw('1 = 0');
}

Le scope est ensuite appliqué de manière transversale sur 4 composants Livewire pour homogénéiser l'isolation, SalarieTable, DemandeFormationTable, FormationTable et PlanFormationTable. Six tests PHPUnit dédiés (Batch D) couvrent les scénarios critiques, notamment qu'un manager ne voit pas un orphelin alors qu'un gestionnaire le voit, et que descendantIds traverse correctement plusieurs niveaux récursifs.

Extrait 2 : pattern dismiss vs close pour modales imbriquées. Pour les CRUD Livewire dont la modale d'édition peut être ouverte depuis la modale détail (demande JLO du 15 avril : « si je suis sur la cinquième page de la liste, annuler doit me ramener à la modale détail, pas re-scroller toute la liste »), il faut deux méthodes distinctes de fermeture. Le bouton Annuler appelle closeEditModal qui rouvre la modale détail si on en venait. La croix, le clic sur l'overlay et la touche Échap appellent dismissEditModal qui éjecte tout via $this->reset(), méthode canonique Livewire pour réinitialiser un lot de propriétés en une fois.

// app/Livewire/FormationTable.php (extrait condensé)

// Bouton Annuler et enchaînement après save : retour au contexte parent
public function closeEditModal(): void
{
    $this->authorizeAccess();

    $fromDetail = $this->editedFromDetail;
    $formationIdToReopen = $this->viewingId;

    $this->showModal = false;
    $this->editedFromDetail = false;
    $this->resetForm();

    if ($fromDetail && $formationIdToReopen) {
        $this->view($formationIdToReopen);
    }
}

// Croix, clic sur overlay, touche Échap : éjection rapide vers le listing
public function dismissEditModal(): void
{
    $this->authorizeAccess();

    $this->reset([
        'showModal', 'showDetailModal', 'editedFromDetail',
        'viewingId', 'viewingData',
        'editingId', 'titre', 'modele_id', 'plan_id', 'organisme_id',
        'date_debut', 'date_fin', 'lieu', 'nb_places', 'cout_reel',
    ]);

    $this->statut = 'planifiee';
    $this->resetValidation();
}

Ce pattern est documenté plus en détail dans la note interne du 15 avril. Il a été propagé sur la modale Inscriptions du même composant. La propagation aux six autres CRUD Livewire est planifiée par lots, à chaque fois qu'une modification touche un CRUD donné.

Mon positionnement s'est nettement stabilisé depuis le rapport de lancement, et j'ai gagné en autonomie au quotidien. Les échanges avec Jérémy LOUVEAU sont devenus plus fluides à mesure que les semaines passaient. La plupart des décisions structurantes se prennent désormais en moins de 15 minutes, en fin de daily ou par message court. Les interactions avec Jean-Christophe ROY sur la modélisation de la base ont elles aussi évolué. Aux ateliers dédiés des deux premières semaines a succédé un mode à la demande, déclenché ponctuellement quand un doute technique surgit. Pour moi, c'est le signe que la confiance s'est installée sur les micro-décisions, sans que les choix structurants ne perdent leur passage par les bons interlocuteurs.

La présentation au DRH Julien CHAMAGNE, commanditaire du projet, est prévue en semaine 7, après le 8 mai. On a préféré viser ce moment pour avoir une chaîne de validation des demandes opérationnelle de bout en bout, plutôt que de présenter un socle CRUD encore désincarné. C'est un arbitrage que j'ai discuté avec Jérémy LOUVEAU, parce qu'on partage l'idée que montrer un produit au client n'a vraiment du sens qu'une fois qu'il couvre un scénario métier complet. Le daily de cadrage du 28 avril a confirmé ce positionnement et listé les 15 actions priorité 1 à livrer d'ici le 8 mai pour rendre la démonstration possible.

Autre changement par rapport au rapport de lancement, je suis amené à intervenir occasionnellement au-delà du périmètre strict de mon projet. Étant celui qui a déployé le GitLab interne en début de stage, je me suis retrouvé administrateur de fait de cet outil. L'équipe SI m'a sollicité pour résoudre une contrainte d'infrastructure réseau, la gestion centralisée de la configuration RADIUS NPS (Network Policy Server, le service Microsoft d'authentification réseau pour le WiFi et le VPN du groupe). J'ai livré un dépôt nps-config qui versionne sous Git la configuration des clients RADIUS (bornes WiFi, switches, équipements VPN) et la déploie automatiquement sur les deux serveurs NPS via un pipeline CI/CD avec runners redondants. Cette intervention transverse a réutilisé directement les patterns appris sur Forma-Hiolle, infrastructure as code et CI/CD.

Sur les six premières semaines, j'estime que ma charge se répartit entre six grandes activités. Le découpage ci-dessous repose sur ma relecture du carnet de bord journalier et du journal des décisions.

Activité	Part estimée
Développement applicatif	45 %
Documentation interne, mémo, rédaction des rapports académiques	22 %
Veille technologique et lecture de documentation	15 %
Échanges et dailys avec Jérémy LOUVEAU, Jean-Christophe ROY et l'équipe SI	10 %
Intervention transverse SI (déploiement GitLab, projet nps-config)	5 %
Administratif, publication WordPress, livrables académiques	3 %

Au 29 avril, je suis en avance d'environ 8 à 10 jours sur le planning initial. Les phases MVP qui devaient tomber en semaines 5 ou 6 ont été livrées dès la semaine 4, notamment le CRUD Plans et le CRUD Demandes. La Phase A SILAE, qui était positionnée en semaine 6 dans le macro-planning, a été anticipée le 21 avril avec la commande Artisan d'import SFTP, le scheduler nocturne et la documentation de déploiement associée. La refonte v0.5.0 des mandats, qui n'était pas prévue au lancement, a été livrée en local le 22 avril puis déployée en production le 27 avril, dans le cadre d'une pousse consolidée des versions 0.5.0 à 0.5.3.

Plutôt que d'augmenter le scope, j'ai choisi d'investir cette avance dans la qualité, polish UX, tests automatisés, documentation technique et préparation de la passation. Une partie a d'ailleurs déjà servi en semaine 5, sur trois chantiers initialement non prévus à cette échéance : la Phase C d'isolation manager récursive, le pack qualité professionnel et l'audit trail Activitylog. Le daily de cadrage du 28 avril a redessiné le calendrier des semaines 6 à 13. L'authentification Active Directory réelle est repoussée de la semaine 7 vers la semaine 9, et les exports PDF comme les dashboards par rôle reculent vers les deux dernières semaines. La priorité absolue jusqu'au 8 mai reste la chaîne de validation des demandes bout en bout, livrable pour la semaine 7.

Le diagramme ci-dessous reprend le macro-planning du rapport de lancement, avec barre pleine pour le réalisé au 29 avril et barre hachurée pour le reste à faire jusqu'à la semaine 13.

La deuxième moitié du stage commence avec une avance nette sur le planning prévisionnel. Plusieurs décisions, qui n'étaient pas anticipées dans le rapport de lancement, sont aussi devenues structurantes pour la suite.

Livraisons métier anticipées. Dix composants Livewire sont livrés au 29 avril, contre cinq qui étaient prévus à cette date dans le macro-planning initial. Les phases « Plans de formation » et « Demandes de formation », qui devaient tomber en semaines 6 et 10, ont été livrées en semaine 4. Cette avance me dégage du temps pour les phases les moins prédictibles, l'authentification Active Directory réelle (qui passe désormais en semaine 9) et les dashboards par rôle qui ont été repoussés vers la fin du stage.

Permissions fines Spatie, non prévues au lancement. Le daily du 15 avril a fait émerger un besoin métier qui n'était pas exprimé au démarrage. Un manager peut avoir le droit de créer des plans de formation, mais uniquement si un gestionnaire lui active ce droit au cas par cas. Avec un modèle de rôles codés en dur, ce serait impossible à exprimer. J'ai donc introduit Spatie Permission, et centralisé tout dans un PermissionSeeder. Le bénéfice annexe, c'est que toutes les futures permissions s'ajouteront en une ligne sans refactorisation, et qu'on prépare déjà la future page d'administration des utilisateurs.

Refonte SILAE v0.5.0, imprévue. La semaine 5 devait se limiter à un import CSV simple depuis un fichier local. Le test sur un flux SFTP réel a fait surgir des cas non couverts par le schéma initial, en particulier des salariés qui occupent plusieurs postes en même temps. Plutôt qu'un patch ponctuel et fragile, j'ai préféré reprendre le schéma à la racine. J'ai créé une table dédiée aux mandats et gardé l'ancienne colonne poste comme cache du mandat principal, ce qui évite de casser tout le code qui s'en servait déjà.

Automatisation de la chaîne GitLab vers le serveur applicatif. Au lancement, le déploiement était encore manuel et un remote Git restait à valider. J'ai monté la pile GitLab CE auto-hébergée, configuré le runner et branché un pipeline CI/CD complet, le tout dès le 3 avril. C'est un acquis qui dépasse le périmètre initial du stage et qui laisse à l'équipe SI une infrastructure réutilisable pour ses projets internes futurs.

Premiers tests automatisés étendus. Le rapport de lancement n'en parlait pas, c'était un point aveugle. Au 29 avril, j'ai 36 tests PHPUnit verts, dont 6 sur l'isolation manager récursive le 24 avril et 7 sur l'audit trail le 23 avril. Le réflexe « tests dès le début », pris en réaction au legacy 2024, a été tenu.

Phase C isolation manager récursive, ajout en cours de route. Le daily du 20 avril a fait remonter un besoin métier non couvert par le scope initial. Un manager ne doit voir que les salariés de sa hiérarchie descendante, sans limite de profondeur. Plutôt que de disséminer un filtre dans chaque composant, j'ai livré le 24 avril une solution centrale, un scope Eloquent réutilisable Salarie::scopeVisibleBy propagé sur les quatre composants concernés. Trois mécaniques d'application coexistent selon le contexte. J'ai accompagné le tout d'une documentation au format Diátaxis et de six tests d'intégration. Cette brique débloque directement la Phase F de chaîne de validation des demandes, prévue en semaine 7.

Vue calendrier des formations, reportée à la semaine 11. Le macro-planning initial positionnait la vue calendrier en semaine 5 et le drag and drop des affectations en semaine 7. La refonte des mandats SILAE en semaine 5 et le pivot vers la chaîne de validation des demandes en semaine 7 ont absorbé ces créneaux. La vue calendrier reste un livrable du MVP, repositionnée au tableau de la section 8 sur la semaine 11 en parallèle du module Plan de formation, qui en consomme les données.

Audit trail applicatif, dispositif exploratoire. Le 23 avril, j'ai branché Spatie Activitylog sur 10 modèles métier sensibles, et ajouté une route /audit-trail accessible aux gestionnaires depuis leur menu profil. À ce stade, c'est un dispositif technique en mode exploratoire. La politique métier qui l'accompagnera (rétention, public, cadre de conformité) reste à arbitrer avec Jérémy LOUVEAU et le commanditaire. En attendant, cet outil sert déjà comme deuxième ligne d'observabilité utile pour déboguer en production, dans un contexte multi-rôles où plusieurs actions peuvent toucher au même objet quasi simultanément.

Pack qualité professionnel, ajout du 23 avril. La version 0.5.1, livrée le 23 avril, a regroupé un ensemble de bonnes pratiques industrielles : fichiers LICENSE et CHANGELOG, README racine retaillé, 2 ADR au format MADR, journalisation structurée en JSON, healthcheck /health interrogeable par le pipeline, analyse statique PHPStan au niveau 5, formatage Pint, et stage quality étendu dans la chaîne d'intégration continue. L'objectif est clair, rendre le code directement reprenable par les équipes internes une fois le stage terminé.

Précision sur la stack effectivement installée. Le rapport de lancement annonçait Laravel 13.x. Au 29 avril, la version effectivement installée et déployée est Laravel 13.2 sur PHP 8.4. La pile installée à mi-parcours se résume aux briques Laravel 13.2, Livewire 4.2, Tailwind CSS 4.2, MariaDB 11.8, Spatie Permission 7.2, Spatie Activitylog 5.0 et League Flysystem SFTP 3.33. L'unique flux d'échange CSV en place à ce stade est l'import quotidien SILAE vers HFP, parsé en str_getcsv natif sans package tiers. Trois briques choisies au lancement n'ont pas encore été installées, LdapRecord-Laravel pour la bascule Active Directory en semaine 9, DomPDF pour les exports documentaires en semaine 12, et un éventuel parser CSV plus structuré si les flux d'export prévus au CDC se concrétisent. Aucune montée majeure de version n'est envisagée d'ici la fin du stage, pour ne pas introduire de risque de compatibilité sur les briques en place.

Globalement, le macro-planning du rapport de lancement tient toujours, avec une avance nette à mi-parcours. Quelques ajustements sont nécessaires pour intégrer les découvertes imprévues de la semaine 5 et bien préparer la restitution finale.

Semaine	Dates	Activités initiales	Réalisé ou ajustement
S5	20 au 24 avril	Workflows de statuts et planning drag and drop	Phase A SILAE, refonte des mandats v0.5.0, Phase B sidebar packages, Phase C isolation manager récursive, audit trail Activitylog, pack qualité professionnel, drawer filtres sur 5 CRUDs
S6	28 avril au 2 mai	Flux SFTP SILAE, rapport d'avancement	Pousse en production consolidée des versions 0.5.0 à 0.5.4, daily de cadrage 28 avril, sprint UX cinq actions, rédaction du rapport d'avancement, vendredi 1er mai férié
S7	5 au 9 mai	Auth AD réelle, notifications	Chaîne complète de validation des demandes bout en bout, onglet de gestion des rôles dans l'administration, démonstration à Julien CHAMAGNE, vendredi 8 mai férié
S8	12 au 16 mai	Documents, exports PDF	Fiabilisation post-démonstration commanditaire, corrections issues du retour métier, jeudi 14 et vendredi 15 mai fériés ou pontés
S9	19 au 23 mai	Dashboards par rôle	Bascule sur l'authentification Active Directory réelle via LdapRecord, notifications email et in-app si charge disponible
S10	26 au 30 mai	Tests fonctionnels	Tests fonctionnels par rôle, début du module Plan de formation, lundi 26 mai férié
S11	2 au 6 juin	Documentation technique et utilisateur, rédaction du rapport final	Plan de formation complet avec budget par filiale et workflow, vue calendrier des sessions avec drag and drop sur les affectations, documentation technique étoffée, rédaction du rapport final
S12	9 au 13 juin	Passation, publication, rapport final	Trois dashboards par rôle, polish UX et UI final, dépôt du rapport final le 15 juin
S13	15 au 19 juin	Buffer	Répétition soutenance, résumé 1000 mots, diaporama, ajustements finaux

Bilan mi-parcours. Arrivé à la moitié du stage, je constate que le plan initial validé au point CDC du 26 mars et au daily du 30 mars tient bien la route. La pile technique, Laravel 13 sur PHP 8.4, Livewire 4, Tailwind 4 et MariaDB 11.8, est restée stable depuis sa validation, et aucun choix d'architecture majeur n'a eu à être remis en cause. Au 29 avril, j'ai accumulé entre 8 et 10 jours d'avance sur le macro-planning initial, ce qui me donne de la marge pour investir la seconde moitié dans la qualité plutôt que dans l'augmentation du scope. Concrètement, ça veut dire améliorer l'UX, étoffer les tests automatisés, compléter la documentation technique et préparer la passation. Jérémy LOUVEAU a validé cette priorité le 20 avril, en m'autorisant à espacer les poussées en production, et je décide désormais moi-même du moment des livraisons.

Au-delà du projet, je me sens aussi mieux intégré à l'équipe SI qu'au démarrage. Les échanges sont plus directs, on s'entraide ponctuellement quand un sujet sort du périmètre de chacun, et c'est ce qui a rendu naturelle la sollicitation sur le projet nps-config, que j'aime appeler ma « side-quest ». Demander un coup de main ou proposer une idée passe mieux à mesure que les semaines avancent.

Zones de risque identifiées. Trois sujets demandent une vigilance particulière d'ici la mi-juin. Le premier, le plus immédiat, c'est la disponibilité de l'Active Directory pour les tests d'authentification réels désormais positionnés en semaine 9. La bascule dépend d'une coordination avec le responsable réseau du groupe que je n'ai pas encore calée formellement. Le deuxième, ce sont les décisions métier laissées ouvertes par Jean-Christophe ROY le 10 avril, politique de rétention RGPD et stratégie de gestion des salariés disparus du flux SILAE. Elles attendent un arbitrage commun avec le commanditaire Julien CHAMAGNE. Le troisième, c'est la chaîne de validation des demandes de formation. Elle est l'objectif principal de la semaine 7, et son périmètre est désormais cadré par les 15 actions priorité 1 listées au daily du 28 avril. Elle déterminera la pertinence de la démonstration commanditaire prévue après le 8 mai.

Prochaines étapes critiques. Plusieurs jalons s'enchaînent jusqu'à la soutenance. D'abord, faire valider ce rapport d'avancement par Jérémy LOUVEAU le 30 avril, puis le déposer sur le CMS de l'Université au plus tard le 4 mai. Ensuite, livrer les 15 actions priorité 1 du daily de cadrage du 28 avril d'ici le 8 mai. Présenter ensuite à Julien CHAMAGNE en semaine 7 un scénario métier complet de bout en bout. La semaine 8 servira à fiabiliser ce que la démonstration aura fait remonter. La semaine 9 sera celle de la bascule sur l'authentification Active Directory réelle. Le module Plan de formation tombera en semaine 11, accompagné de la vue calendrier des sessions avec drag and drop sur les affectations. Les dashboards par rôle et le polish UX final occuperont la semaine 12, en parallèle de la rédaction du rapport final. La semaine 13 servira de buffer pour la répétition de la soutenance et les ajustements de dernière minute.