Def'IUT

Dès les premières séances, j'ai naturellement pris une position de chef de projet, non pas parce qu'on me l'avait demandé, mais parce que c'est une posture que j'adopte instinctivement face à un projet ambitieux et mal défini. J'ai proposé un cadre de travail inspiré des méthodes agiles : une répartition claire des rôles, des tâches collectives définies ensemble, et des points d'avancement réguliers pour que chacun sache où en était l'équipe. Mes coéquipiers ont adhéré naturellement à cette organisation, ce qui m'a conforté dans l'idée que proposer un cadre est souvent plus efficace qu'attendre qu'il émerge collectivement.

J'ai également pris en charge la relation avec l'équipe de troisième année qui jouait le rôle de commanditaire. C'est moi qui lançais les échanges, reformulais les ambiguïtés du cahier des charges et remontais les questions techniques à clarifier. Ce rôle d'interlocuteur principal m'a appris que la communication avec un client demande autant de rigueur que le développement lui-même : mal comprendre une spécification en amont coûte beaucoup plus cher à corriger en aval.

Sur le plan technique, j'ai endossé un rôle de force de proposition pour les décisions d'architecture. C'est moi qui ai introduit React en présentant ses avantages et inconvénients à l'équipe, sans imposer le choix. Cette approche m'importait : une décision d'architecture partagée est mieux défendue et mieux implémentée qu'une décision unilatérale. Au développement, je me suis concentré sur les pages publiques et la partie administration du site. La décision la plus structurante du semestre a été d'anticiper le semestre suivant en livrant non seulement la maquette Figma et le front-end, mais aussi une structure d'API temporaire et une infrastructure Docker déjà en place. Cette anticipation n'était pas dans les consignes : c'était un choix personnel, motivé par la conviction que la continuité entre les deux semestres allait conditionner la réussite du projet. Le résultat a prouvé que c'était la bonne décision.

Mon expérience préalable en développement web full-stack a constitué le socle sur lequel j'ai pu m'appuyer tout au long de ce semestre. Je pratique le développement web depuis plusieurs années, ce qui m'a permis de ne pas repartir de zéro sur des notions fondamentales et de me concentrer sur la mise en oeuvre plutôt que sur l'apprentissage des bases. Les cours de développement web et de qualité de développement ont formalisé et structuré des pratiques que j'appliquais déjà de façon empirique, notamment sur les bonnes pratiques de structuration d'un projet React, la gestion de version avec Git ou encore l'écriture de code maintenable.

Les cours d'analyse ont été mobilisés directement dans la lecture et l'interprétation du cahier des charges fourni par le commanditaire. Identifier les cas d'usage, distinguer l'essentiel du secondaire, et reformuler les besoins en termes techniques sont des compétences que j'ai pu exercer concrètement grâce à ces enseignements. Le management des systèmes d'information a fourni un cadre conceptuel utile pour l'organisation de l'équipe et le suivi de projet, même si en pratique c'est aussi mon expérience personnelle de la gestion de projet qui a guidé mes décisions au quotidien. Les cours de communication ont été précieux pour la gestion de la relation client : comment présenter un avancement, comment formuler une question technique sans jargon excessif, comment faire remonter un problème sans alarmer inutilement.

Sur les parties que je maîtrisais moins, j'ai fait le choix délibéré de déléguer à des coéquipiers plus compétents sur ces sujets. Ce n'était pas une façon d'éviter le travail, mais une décision de bon sens : un projet bien réparti selon les compétences réelles de chacun avance plus vite et produit un meilleur résultat. Cette approche a demandé de prendre le temps de comprendre ce que chacun savait faire, ce qui s'est révélé être autant un exercice de management que de connaissance de soi.

Cette SAE est particulièrement riche en apprentissages critiques parce qu'elle touche à la quasi-totalité des compétences du BUT.

AC21.01 et AC21.03 (Réaliser, implémenter les spécifications et adopter de bonnes pratiques) : la maquette Figma livrée en fin de semestre constitue une trace directe de la capacité à traduire un cahier des charges en une conception fonctionnelle et ergonomique. Le front-end livré et accessible démontre quant à lui l'implémentation concrète de ces spécifications, avec une attention portée à la structuration du code React et à la cohérence avec la maquette.

AC21.02 (Réaliser, accessibilité et ergonomie) : la phase de design a mobilisé les notions d'ergonomie et de hiérarchie visuelle abordées en cours, avec l'objectif de produire une interface compréhensible pour les utilisateurs finaux, qui sont des étudiants et des enseignants aux profils très différents.

AC23.02 (Administrer, services réseaux virtualisés) : la mise en place d'une infrastructure Docker dès le S3 illustre une prise en compte anticipée de la dimension déploiement. Cette décision m'appartient et elle témoigne d'une capacité à penser le projet dans sa globalité, au-delà du périmètre strictement demandé pour ce semestre.

AC25.02 et AC25.04 (Conduire, formaliser les besoins et définir une démarche de suivi) : la gestion du contact avec le commanditaire et la mise en place d'un suivi agile de l'avancement répondent directement à ces apprentissages. J'ai formalisé les besoins en remontant les ambiguïtés du cahier des charges, et j'ai défini une démarche de suivi que l'équipe a adoptée collectivement.

AC26.02 et AC26.04 (Collaborer, cycle de développement et intégration dans une équipe) : le rôle transversal que j'ai occupé, à la fois développeur, chef de projet et interlocuteur client, m'a permis d'identifier concrètement les phases d'un cycle de développement et d'en organiser l'enchaînement au sein de l'équipe.

Avec le recul, le regret principal de ce semestre concerne notre rapport au cahier des charges. Nous l'avons abordé comme une consigne scolaire intangible, qu'il fallait réaliser telle quelle sous peine d'être en défaut. C'était une erreur de raisonnement. Dans un cadre professionnel, un cahier des charges n'est pas une contrainte imposée : c'est un point de départ à partir duquel une équipe de prestataire doit évaluer la faisabilité, prioriser les fonctionnalités et recadrer les attentes du client en fonction des ressources disponibles. Nous ne l'avons pas fait, ou trop tard et trop timidement.

L'équipe a donné beaucoup d'elle-même pour tenir des délais et un périmètre qui dépassaient ce qui était raisonnablement livrable dans le temps imparti. Le résultat final manquait de finition, non pas par manque d'investissement, mais parce que l'effort a été dilué sur trop de fonctionnalités à la fois. Cette expérience m'a appris quelque chose d'important : s'impliquer à fond sur un périmètre maîtrisé produit de meilleurs résultats qu'une mobilisation totale sur un périmètre trop large.

Si c'était à refaire, je porterais la discussion sur le périmètre dès la première réunion avec le commanditaire. Non pas pour réduire l'ambition du projet, mais pour établir une liste de priorités claires et des critères de livraison réalistes. C'est précisément ce qu'on attend d'une équipe de développement professionnelle, et c'est une compétence que ce projet m'a appris à reconnaître comme essentielle, même si je ne l'ai pas pleinement exercée cette année-là.

J'ai abordé ce semestre dans la continuité directe du S3, avec la même posture de chef de projet, et en m'appuyant sur la structure que j'avais anticipée : front-end livré, API temporaire en place, infrastructure Docker opérationnelle. Le S4 était entièrement dédié au backend, aux tests et au déploiement, ce qui nous a permis de démarrer sans temps mort.

La dynamique d'équipe était la meilleure que j'aie connue dans un projet de groupe au BUT. Mes coéquipiers s'impliquaient naturellement, sans que j'aie à relancer ou surveiller. Tant que je maintenais le cadre, le projet avançait. C'est quelque chose que j'ai apprécié à sa juste valeur, parce que ce n'est pas toujours le cas et que ça change radicalement la façon de vivre un projet collectif.

Cependant, une absence prolongée de ma part en mars a mis en évidence quelque chose d'important : sans ma présence pour impulser et cadrer, le rythme du projet ralentissait sensiblement. Ce n'était pas un manque d'investissement des autres, mais la confirmation que le rôle de chef de projet n'est pas simplement organisationnel, il est aussi moteur. J'ai repris les choses en main après cette période, mais nous avions perdu du temps.

Plus difficile encore : un quatrième membre de l'équipe a progressivement décroché en fin de semestre, sous la pression des examens, et n'a pas assisté à la soutenance. C'était frustrant, d'autant plus que la cohésion avait été réelle pendant la majorité du projet. Nous nous sommes retrouvés à trois pour absorber une charge de travail déjà trop importante pour quatre. Personnellement, j'ai pris une part significative de ce qui lui incombait pour éviter que le poids retombe entièrement sur mes coéquipiers. Le projet a été livré, fonctionnel et sans bug majeur, mais au prix d'une fin de semestre épuisante qui n'a laissé aucune place à la préparation de la soutenance. Ce qui a été présenté ce jour-là n'était pas à la hauteur du travail produit.

Le S4 étant centré sur le backend, les tests et le déploiement, les ressources mobilisées ont évolué par rapport au semestre précédent. Les cours d'architecture logicielle ont fourni le cadre conceptuel pour structurer l'API Express.js : organisation des routes, séparation des responsabilités, conception des endpoints. La qualité de développement a guidé l'écriture des tests unitaires sur l'API et l'intégration d'un outil de lint pour assurer la cohérence du code à l'échelle du projet.

La virtualisation a été directement mobilisée dans la gestion des environnements Docker, notamment pour la création du système de sandbox qui nécessitait des conteneurs d'exécution isolés et configurables selon le langage. Les cours de cryptographie et de cybersécurité ont alimenté la réflexion sur la sécurisation de ces environnements d'exécution : empêcher qu'un code soumis par un utilisateur ne consomme toutes les ressources du serveur ou n'accède à des zones mémoire non autorisées était un problème concret, pas un exercice théorique.

Mon alternance chez Crédit Agricole Technologies et Services a été une ressource à part entière. Travailler quotidiennement sur des API Java en production m'a donné une compréhension solide des patterns backend, du cycle de vie d'une requête, de la gestion des erreurs et des bonnes pratiques de structuration. Le langage était différent, mais les principes étaient directement transposables à Express.js. La CI/CD que j'ai mise en place sur GitLab s'est également inspirée de ce que j'observais en entreprise : des phases clairement séparées, des gates de qualité automatisés avant tout déploiement, une logique de validation progressive plutôt qu'un simple déploiement direct.

Ce semestre est celui où la maîtrise des apprentissages est la plus tangible, parce que les livrables sont concrets, mesurables et en production.

AC21.01 et AC21.04 (Réaliser, implémenter les spécifications et valider par les tests) : l'API livrée couvre l'ensemble des fonctionnalités spécifiées : gestion des comptes utilisateurs, administration, tickets et défis, chacun avec des opérations CRUD complètes. Les tests unitaires automatisés sur les défis, exécutés à chaque soumission pour valider les solutions, constituent une preuve directe de la capacité à vérifier et valider la qualité d'une application par les tests.

AC23.02 et AC23.03 (Administrer, services virtualisés et sécurisation) : la sandbox d'exécution de code est l'élément le plus complexe du projet. Elle permet d'exécuter du code interprété et compilé dans plusieurs langages, gère les imports de bibliothèques et sécurise l'exécution pour prévenir les abus tels que les boucles infinies qui avaient fait crasher le serveur lors des premiers tests. Les autres groupes validaient leurs défis en comparant une chaîne de caractères dans un fichier téléchargeable. Notre approche était d'un niveau de complexité incomparable, et le fait que nous ayons livré cela en production et sans bug en est la meilleure preuve. La gestion des deux environnements de production, VPS personnel pour la pré-production permanente et Azure pour la livraison finale, illustre également la capacité à déployer des services dans une architecture réseau réelle avec des contraintes concrètes.

AC25.04 (Conduire, démarche de suivi de projet) : la pipeline CI/CD mise en place sur GitLab, avec ses quatre phases distinctes (build, test, gate de qualité, déploiement), constitue une trace directe d'une démarche de suivi structurée et automatisée. Ce n'était pas une exigence du sujet : c'est une décision que j'ai prise en m'inspirant des pratiques professionnelles observées en alternance, et qui a apporté une réelle valeur au projet.

Ce semestre m'a laissé un sentiment ambivalent. D'un côté, une vraie fierté : nous avons livré un projet fonctionnel, complet et en production, avec un niveau de complexité technique que les commanditaires eux-mêmes n'avaient pas anticipé. Ils nous ont avoué avoir volontairement surchargé le cahier des charges, et ils ont été surpris que nous allions aussi loin. De l'autre côté, une frustration réelle face à une note qui ne reflète pas l'écart de travail et de complexité entre notre projet et ceux des autres groupes.

Sur le fond, le regret principal rejoint celui du S3 : nous n'avons jamais formellement renégocié le périmètre du CDC. Nous avions bien obtenu une concession importante, faire accepter Express.js à la place du PHP que les commanditaires imposaient initialement, et sans cette négociation le projet aurait été insurmontable. Mais il restait trop d'incohérences et de fonctionnalités sous-estimées que nous avons absorbées sans les remettre en question. Nous avions la tête sous l'eau et avancions par inertie. À refaire, je bloquerais du temps dès le démarrage du semestre pour reprendre le CDC ligne par ligne avec l'équipe et le commanditaire, identifier les points critiques, et formaliser un périmètre réaliste avant de commencer à coder.

Sur la forme, la soutenance mal préparée est un regret direct. Nous avions tellement donné pour finir le projet que nous n'avions plus d'énergie pour le présenter correctement. Or une démonstration convaincante du travail réalisé fait partie de la compétence. Livrer sans savoir défendre n'est pas suffisant.

Avec le recul de l'alternance, je pense qu'on aurait pu faire mieux sur l'organisation. J'avais essayé d'appliquer les pratiques agiles vues en cours, mais c'était un agile de surface : des points réguliers, une répartition des tâches, sans vraiment en maîtriser la logique profonde. C'est en retournant en entreprise après le projet que j'ai compris ce que la méthode implique réellement. Une gestion réellement agile, avec des sprints définis, une vélocité mesurée et un backlog priorisé selon la valeur livrable, aurait sans doute permis de mieux absorber les aléas et peut-être d'éviter que le quatrième membre décroche en fin de semestre.