Jessim
Meguenni-Tani

Premier jour chez APICIL. Présentation de l'équipe et du tuteur. Découverte des outils de travail (GitLab, Jira, Confluence). Affectation à une équipe de développement logiciel travaillant sur un projet dans le domaine MDM (Master Data Management) pour la centralisation des référentiels de valeurs financières. Premier daily Scrum quotidien. Briefing détaillé du projet par le chef de projet lors d'un call d'une heure. Identification de la stack technique : Java Spring Boot, Oracle SQL, GitLab. Premiers échanges techniques avec les développeurs de l'équipe. Mise en place des premiers accès (GitLab obtenu en fin de semaine).

Obtention des accès Confluence et Jira en cours de semaine. Étude approfondie de la documentation du projet sur Confluence et exploration des tickets sur Jira. Toujours en attente de l'accès à la base de données du projet. En parallèle, réalisation d'un projet Spring Boot personnel (gestion-contrats) en autonomie pour me familiariser avec la stack utilisée chez APICIL : création d'une API REST complète avec entité JPA, repository, service et controller. Mise en pratique des concepts d'architecture en couches, de JPA/Hibernate, et de l'injection de dépendances Spring.

Affectation de mon premier ticket de production : exposer un endpoint REST GET permettant de consulter une nomenclature financière hiérarchique relevant du cadre Solvency II. Pour me guider, j'ai étudié un ticket similaire déjà livré portant sur une nomenclature plate AMF, ce qui m'a permis de comprendre la spécificité métier de mon cas : une structure hiérarchique reposant sur une relation auto-référencée entre parents et enfants. J'ai ensuite conçu l'intégralité de la chaîne applicative en architecture en couches multi-modules : entité JPA mappant la table source, repository en lecture seule exploitant les Specifications pour des filtres de recherche dynamiques, DTO de réponse intégrant un champ calculé, mapper MapStruct pour la transformation des objets, interface et implémentation de service, puis endpoint sécurisé côté controller et documentation Swagger bilingue. J'ai par ailleurs implémenté la logique métier de résolution du label parent à travers la relation auto-référencée. Ce ticket m'a permis de mener mon premier workflow Git complet en autonomie — branche de fonctionnalité, commits conventionnés, push et ouverture d'une Merge Request soumise à relecture — et de mesurer l'enchaînement réel des responsabilités dans une architecture professionnelle.

La première moitié de cette période a été consacrée au retour de code review d'un développeur senior sur ma Merge Request. J'ai appliqué ses remarques — conventions de code, champ d'entité et méthode de repository manquants — et surtout identifié un anti-pattern N+1 dans ma propre implémentation, qui déclenchait une requête par ligne pour résoudre les parents. J'ai refactoré cette logique en collectant les codes parents pour les charger via une unique requête, puis en construisant une Map en mémoire afin d'associer efficacement chaque élément à son parent. J'ai consolidé ce travail par l'écriture de cinq tests unitaires avec JUnit 5 et Mockito, couvrant le cas nominal, le repli sur la recherche par label, la résolution du label parent, l'absence de parent et la page vide, en m'appuyant sur le pattern Arrange-Act-Assert et le principe d'un test par branche conditionnelle ; le diagnostic de plusieurs erreurs par lecture de stack traces a renforcé mon autonomie. La seconde moitié m'a fait découvrir le stack frontend du projet — React, TypeScript, Vite, MUI et React Query — pour lequel j'ai produit la couche d'exposition de la nomenclature côté interface : modèle TypeScript, hook de requête personnalisé, page d'affichage hiérarchique, routage et internationalisation FR/EN, en gérant en autonomie quelques blocages d'environnement. Avoir livré seul le backend et le frontend d'une même fonctionnalité m'a donné une vision full-stack concrète de la chaîne de valeur logicielle.