Ludovic M, étudiant en parcours M2 Web & Mobile Development à l'ÉSTIAM, revient sur une expérience marquante vécue en alternance : la migration d'un logiciel de gestion interne, et le moment où un responsable d'exploitation a mis le doigt sur un problème que personne, côté technique, n'avait vu venir.
À l'ÉSTIAM, l'alternance permet de confronter ce qu'on apprend en cours à des situations réelles, avec de vraies conséquences. C'est dans ce cadre que j'ai participé à la migration d'un logiciel de gestion interne, utilisé quotidiennement par plusieurs sites d'exploitation de l'entreprise. Ce chantier devait être avant tout technique : passer d'une version de framework à une autre, moderniser le code, alléger une application devenue lourde. Il a fini par m'apprendre quelque chose de bien plus large sur la conception d'une application métier.
Un logiciel interne devenu trop lourd
Le logiciel en question accompagne l'entreprise depuis plusieurs années. Il a grossi au rythme des besoins : une fonctionnalité ajoutée ici, un écran là, une exception métier intégrée en urgence. Avec le temps, il est devenu lourd à faire évoluer et coûteux à maintenir. La migration visait plusieurs objectifs en même temps : passer à une version majeure supérieure du framework, faire évoluer la couche d'accès aux données, convertir les anciennes annotations en attributs, remplacer l'interface d'administration historique par une solution plus adaptée, corriger des régressions fonctionnelles silencieuses, et repenser la hiérarchie des rôles ainsi que la gestion des permissions. Sur le papier, une liste de chantiers techniques. Dans les faits, un projet qui touchait au fonctionnement quotidien de plusieurs équipes.
Arriver junior dans une équipe expérimentée
J'ai travaillé sur ce projet aux côtés d'un développeur back-end avec une vingtaine d'années d'expérience et d'un ingénieur DevOps avec six ans de métier. En tant qu'alternant, j'intervenais sur la partie full-stack. La première chose que cette configuration m'a apprise n'était pas technique. C'était qu'aucun système n'est parfait. Je m'attendais à découvrir, en entrant dans une vraie entreprise, une application propre, pensée de bout en bout, et à me contenter d'y ajouter des briques. J'ai trouvé un logiciel vivant, avec son histoire, ses compromis assumés et ses zones que personne n'avait eu le temps de reprendre. Il a fallu monter en compétences vite. Non pas parce qu'on me le demandait explicitement, mais parce qu'on ne peut pas contribuer utilement à un chantier de cette taille en restant spectateur. Poser des questions précises, lire beaucoup de code écrit par d'autres, comprendre pourquoi une décision avait été prise dix ans plus tôt avant de proposer de la défaire.
Le signalement est venu du terrain, pas de l'informatique
C'est pendant cette période qu'un responsable en charge des collectes sur l'un des sites nous a fait remonter une observation. Des informations relevant de son périmètre étaient visibles par des équipes rattachées à d'autres sites, ce qui créait des interférences dans la planification et de la confusion dans l'organisation des tournées. Ce n'était pas un bug au sens habituel. Rien ne plantait, aucune erreur ne s'affichait, aucun test ne remontait quoi que ce soit. L'application faisait exactement ce pour quoi elle avait été programmée. Simplement, ce pour quoi elle avait été programmée ne correspondait plus à la réalité de l'organisation. Mon premier réflexe a été de chercher la faute dans le code. C'est le réflexe naturel quand on est développeur : quelque chose ne va pas, donc quelque chose est mal écrit. Il m'a fallu un peu de temps, et l'aide de mon collègue senior, pour comprendre que le code était conforme à ce qu'on lui avait demandé, et que le problème se situait un cran au-dessus.
Ce que ce signalement révélait vraiment
Le contrôle d'accès reposait sur une hiérarchie de rôles héritée d'une époque où l'organisation était plus simple. On raisonnait en termes de fonction : tel type d'utilisateur a accès à tel écran, telle catégorie d'information. Or l'entreprise est organisée en plusieurs sites d'exploitation. La bonne question n'était donc pas seulement « quel est le rôle de cet utilisateur ? », mais « sur quel périmètre ce rôle s'exerce-t-il ? ». Un rôle identique n'ouvre pas les mêmes droits selon le site auquel la personne est rattachée et selon la donnée consultée. Tant qu'on raisonnait uniquement par rôles globaux, aucune réorganisation des rôles ne pouvait résoudre le problème correctement. Il fallait changer de modèle : porter la décision d'accès au niveau de la ressource consultée, et non plus seulement au niveau du profil de l'utilisateur. C'est ce que permettent les voters, un mécanisme qui délègue à une logique dédiée la décision d'autoriser ou non un accès, en tenant compte à la fois de l'utilisateur et de l'objet concerné.
Figer d'abord, restructurer ensuite
Restait à décider quoi faire dans l'immédiat, sachant que la nouvelle version n'arriverait en production que plusieurs mois plus tard. Nous avons écarté l'idée de restructurer les droits en urgence sur la version existante. Toucher au modèle de permissions d'un logiciel dont dépendent des équipes entières, sans le temps de tester correctement, c'était prendre le risque de bloquer des personnes dans leur travail quotidien — un remède potentiellement pire que le mal. La décision, prise collectivement entre les développeurs et la direction après plusieurs séances d'échange, a donc été de figer la version existante et d'en limiter les évolutions, notamment la création de nouveaux comptes, le temps de préparer proprement la suite. Puis de ne pas se contenter d'une rustine : partir sur une migration complète, l'occasion de corriger l'ensemble des problèmes identifiés et de découper le projet en modules pour qu'il redevienne compréhensible et maintenable. Ce qui m'a le plus marqué dans cette phase, ce n'est pas la technique. C'est le sang-froid et la communication qu'elle a demandés — entre nous, et avec une direction à qui il fallait expliquer clairement pourquoi la bonne réponse était plus lente que la réponse rapide.
Ce que ça a changé dans ma vision du métier
Avant, je concevais la sécurité applicative comme une couche : on protège les accès, on vérifie les droits, l'affaire est réglée. Aujourd'hui, je la vois comme une traduction. Une application ne fait qu'exprimer une organisation ; si le modèle de données et le modèle de droits ne reflètent pas fidèlement cette organisation, l'écart finit toujours par se voir, souvent par un chemin qu'on n'avait pas anticipé. J'ai aussi appris à me méfier de ce qui ne casse pas. Une erreur qui plante est une erreur facile : elle se signale. Les problèmes les plus coûteux sont ceux qui n'émettent aucun signal technique et qui ne remontent que par les utilisateurs, parfois longtemps après. C'est aussi pour ça qu'un développeur a tout intérêt à comprendre le métier de ceux pour qui il code. Enfin, ce projet m'a montré la valeur d'un signalement venu du terrain. Le problème n'a été identifié ni par un test, ni par un outil, ni par un développeur, mais par quelqu'un qui connaissait son activité mieux que nous.
Pourquoi l'alternance rend ce type d'expérience possible
À l'école, on apprend les concepts, les méthodes et les bonnes pratiques. En entreprise, on découvre ce qu'ils deviennent au contact de l'existant : un logiciel avec dix ans d'histoire, des utilisateurs qui en dépendent, un calendrier, un budget, et des décisions à prendre avec une information incomplète. Travailler aux côtés de profils bien plus expérimentés que moi a accéléré ma progression comme aucun cours n'aurait pu le faire. Non pas parce qu'ils m'ont tout expliqué, mais parce qu'ils m'ont montré comment on raisonne avant d'écrire du code.
Avec le recul, cette migration reste l'expérience la plus formatrice de mon parcours. Elle m'a appris qu'un projet technique est rarement seulement technique, qu'une bonne décision est parfois la plus lente, et qu'un développeur qui écoute les utilisateurs voit des choses qu'aucun outil ne lui remontera. C'est exactement ce que je suis venu chercher en choisissant l'alternance à l'ÉSTIAM : la confrontation directe avec la réalité du terrain, et la montée en compétences qui en découle.
