Otis est une application web interne destinée aux employés de l'entreprise VALECO, dont l'objectif est de simplifier la rédaction des comptes rendus de réunions de chantier. Concrètement, l'outil permet de structurer les informations d'un rapport, d'attribuer des droits d'écriture et de relecture, puis de générer automatiquement un export PDF mis en forme à partir des données saisies. Les différents comptes rendus sont enregistrés dans une base de données PostgreSQL et leur contenu peut ainsi être facilement retrouvé grâce à de multiples fonctions de recherche et de tri intégrées à l'outil. Lorsque j'ai initialement intégré le service informatique de Valeco dans le cadre de mon stage, l'équipe de développement travaillait déjà sur la seconde version d'Otis, et c'est tout naturellement que j'ai alors intégré ce projet.

Une première version de l'application existait déjà et était utilisée en interne. Malheureusement, cette première version faisait partie d'une multitude d'outils développés avant la création d'un véritable service de développement d'applications au sein de l'entreprise. Il s'agissait donc d'un outil développé directement par les équipes métier, sans supervision du service informatique (une pratique connue sous le nom de Shadow IT). Suite à la formation du service « Innovation numérique » deValeco, l'équipe a donc logiquement entrepris de développer une nouvelle version plus moderne et plus maintenable, basée sur React pour l'interface utilisateur, Next.js pour le routage et les routes d'API, Prisma pour l'accès aux données et utilisant TypeScript pour introduire un typage explicite dans le projet. C'est dans ce contexte que je suis arrivé, avec quatre mois devant moi pour monter en compétence sur une stack technique que je ne maîtrisais pas encore, et contribuer concrètement à l'avancement du produit, une mission plutôt ardue au vu du peu de temps qui m'était accordé.

L'enjeu de ce projet était double. Il s'agissait d'une part de produire des fonctionnalités utiles et conformes aux attentes des utilisateurs déjà forgées par la première version de l'application, sans introduire de régression fonctionnelle, et d'autre part de le faire dans un cadre professionnel exigeant, avec des standards de qualité, de maintenabilité et de cohérence architecturale imposés par le Tech Lead pour cette nouvelle version. La première version n'ayant pas été développée par des professionnels mais par des ingénieurs n'ayant pas l'ingénierie logicielle comme cœur de métier, il fallait donc revoir en profondeur l'application d'un point de vue technique, tout en conservant et améliorant ses différentes fonctionnalités pour justifier l'existence de cette nouvelle version.

Otis n'était donc pas un simple projet d'entraînement sur lequel me faire les dents. Il s'agissait au contraire d'un outil métier utilisé par des collaborateurs sur le terrain, ce qui impliquait une responsabilité réelle vis à vis de l'ensemble de mes livrables, et de leur cohérence avec la nouvelle architecture en cours de développement. Une mauvaise décision technique ne se traduirait pas uniquement par un bug isolé et quelques lignes à reprendre dans le projet, mais par une dégradation significative et réelle de l'expérience utilisateur, ou par une dette technique susceptible de ralentir les évolutions futures, ce qui peut se révéler comme étant encore plus handicapant sur le long terme.

Mon premier véritable livrable sur Otis fut le développement du composant gérant l'en-tête des comptes rendus. Cet en-tête se présentait comme un récapitulatif clair et attrayant devant afficher des informations essentielles telles que le projet concerné, l'intitulé de la réunion, la date de rédaction, ou encore le rédacteur ou le collaborateur en charge de la validation du compte rendu. Il devait également permettre l'édition conditionnelle de ces informations, certains champs devenant modifiables selon l'état du rapport. Les sélections du rédacteur et du relecteur s'appuyaient sur des composants Autocomplete de MUI, alimentés par les données récupérées via les Server Actions de Next.js.

Pris par l'envie de livrer rapidement et de prouver ma capacité à être opérationnel, je me suis lancé dans l'implémentation avec beaucoup d'enthousiasme et un peu de précipitation. Cette attitude m'a initialement amené à ne pas prendre suffisamment de recul sur l'architecture globale dans laquelle s'inscrivait cette fonctionnalité. Le composant était certes fonctionnel, avec des données qui remontaient correctement, et j'ai ouvert une pull request en étant relativement satisfait du résultat. C'est lors de la relecture avec le Tech Lead en charge du projet que j'ai véritablement compris ce qui distingue un code purement fonctionnel d'un code professionnel, bien structuré, et pensé pour optimiser son évolutivité sur le long terme.

Nous avons identifié ensemble un manque de granularité dans mes composants, une responsabilité trop large concentrée au même endroit, ainsi qu'un nombre excessif d'appels au back-end. Le problème ne venait pas de la complexité des requêtes, mais de leur multiplication inutile, un élément d'optimisation que j'avais, dans ma précipitation, oublié de prendre en compte. De façon générale, implémenter ce code aurait mené à une augmentation significative de la dette technique du projet, levant des enjeux que je n'avais pas anticipé, puisqu'il s'agissait de mon premier projet d'une telle envergure.

La refonte qui a suivi a été particulièrement formatrice. Nous avons découpé le composant en unités plus petites, introduit des composants dits « containers » responsables de la logique et de l'orchestration des données, et rationalisé les appels au back-end en regroupant certaines requêtes de façon plus intelligente et optimisée. Cette étape m'a obligé à revoir ma manière de penser le développement. J'ai compris qu'en environnement professionnel, l'architecture n'est pas un luxe que l'on ajoute après coup : elle conditionne la lisibilité, la maintenabilité et l'évolutivité du produit. Il est nécessaire de la réfléchir en amont, de penser en même temps que l'aspect fonctionnel la manière dont le code qui est produit s'intégrera dans le reste de la codebase déjà existante. C'était la première fois dans ma carrière que je rejoignais un projet sur lequel je n'étais pas présent dès le début, et il me fallait donc prendre le pli d'analyser et comprendre l'architecture déjà en place et les standards de code à respecter afin de minimiser les problèmes à venir et améliorer la vitesse de développement future avec des composants réutilisables.

Fort de cette première expérience, j'ai abordé les livrables suivants de manière plus méthodique. Avant de coder, je prenais désormais le temps d'analyser l'implémentation existante dans la première version d'Otis, de comprendre les choix effectués et d'identifier leurs limites. Pour un travail portant sur la gestion de listes, j'ai ainsi réfléchi en amont à une structure suffisamment générique pour être réutilisée dans d'autres contextes, notamment pour la gestion des plannings. Cette anticipation m'a permis de réduire la duplication de code et de proposer une solution plus élégante, tout en respectant la cohérence globale de l'application.

Le projet Otis se déroulait, comme les autres projets au sein de Valeco, dans un cadre Agile, structuré par la méthode SCRUM. Les sprints de trois semaines rythmaient notre travail, et chaque user story correspondait à une branche dédiée dans Git. L'équipe de développement et le nombre de projets en cours étant encore à cette époque assez restreints, j'ai eu la chance en tant que stagiaire d'avoir des pull requests donnant lieu à des échanges techniques approfondis, parfois exigeants, mais toujours constructifs. Cet accompagnement de mon tuteur m'a permis de rapidement monter en compétence, si bien qu'il ne m'aura fallu que peu de temps pour m'adapter à ses standards de code et produire du code à la hauteur de ses attentes. Les revues de sprint permettaient de présenter les fonctionnalités développées, tandis que les rétrospectives offraient un espace de discussion sur notre manière de travailler. Ce cadre m'a permis de découvrir ce que signifie réellement travailler en équipe sur un produit vivant, où chaque décision s'inscrit dans une continuité, et de pratiquer les méthodes agiles dans un cadre rigoureux et professionnel.

Pour l'entreprise, ma contribution s'est inscrite dans l'avancement progressif de la version 2 d'Otis, avec des composants restructurés, des appels API et back-end optimisés et une attention particulière portée à la maintenabilité du code. Pour moi, ce projet a représenté une étape décisive dans ma formation. J'y ai fortement consolidé mes compétences en React et en TypeScript, gagnant en rigueur et apprenant à structurer mes composants pour tirer le maximum du framework, mais surtout, j'y ai appris à penser en termes d'architecture et de responsabilité technique, et plus simplement en termes de fonctionnalités isolées. La différence entre ma première implémentation du compte rendu de réunions et les développements suivants illustre concrètement cette progression.

Avec le recul, je considère qu'Otis a marqué un tournant dans ma manière d'aborder le développement. Là où je cherchais auparavant avant tout à produire un code purement fonctionnel, considérant uniquement la réussite du projet au temps présent puisqu'il s'agissait de projets à court terme, j'ai appris à accorder autant d'importance à la structure invisible qui soutient la fonctionnalité en étant le véritable squelette de l'application. J'ai également pris conscience de mes axes d'amélioration, notamment ma tendance initiale à me précipiter dans le code sans formaliser suffisamment l'architecture et les prérequis. Cette prise de conscience, loin d'être un échec, constitue à mes yeux l'un des enseignements les plus précieux du projet, et m'a poussé à prendre davantage de temps dans la réalisation de mes tâches pour la conception préliminaire au code.

A mon départ de Valeco, Otis n'était pas un projet terminé, mais encore un produit en évolution constante. Les bases techniques posées par cette nouvelle version, avec une architecture plus maîtrisée, ont ouvert la voie à des évolutions futures plus sereines. Avoir participé à cette phase de construction m'a permis de mesurer l'importance des fondations dans un projet logiciel. Plus qu'une simple expérience de développement, Otis a été pour moi un apprentissage concret de la rigueur, de l'adaptabilité et de la responsabilité technique.

Aujourd'hui, l'application n'est plus en phase de développement actif, le service de développement ayant entrepris de nouveaux projets depuis mon départ et mon retour dans l'entreprise, et Otis est aujourd'hui en phase de maintenance à cause des ressources limitées à dispatcher entre les nombreux projets entrepris par le service. Des évolutions de l'outil sont cependant aujourd'hui en discussion, notamment une potentielle intégration à celui-ci de notre nouveau micro-service de publipostage que j'ai moi-même développé, mais n'étant actuellement qu'une équipe de cinq développeurs pour gérer trois projets très ambitieux et critiques pour l'entreprise, il est difficile de trouver le temps nécessaire pour faire évoluer d'anciens projets.