Développement d’une API REST Java / Spring pour interfacer deux applications internes.
Avant-propos
Cette expérience s’est déroulée dans le cadre d’un stage de 10 semaines, du 11 avril au 17 juin 2023, au sein de CEGI Alfa à Clermont-Ferrand. Le projet portait sur la conception et l’implémentation d’une API REST en Java / Spring, avec une attention particulière portée à la documentation, aux tests unitaires et à la sécurisation des échanges.
L’entreprise
CEGI Alfa est une société fondée en 1980 à Clermont-Ferrand, initialement orientée vers l’industrie puis spécialisée dans l’édition de progiciels pour les secteurs social, médico-social et sanitaire. Elle s’inscrit dans un groupe plus large présent sur plusieurs sites en France, avec une organisation structurée autour du développement, du support et de l’accompagnement client.
Le site CEGI Alfa de Clermont-Ferrand, où s’est déroulé le stage.
Le stage s’est déroulé au sein de l’équipe AgileS, une solution métier web développée en Java EE pour la gestion de dossiers dans le secteur social. L’environnement de travail associait des profils variés (directeur de projet, chef de projet, développeurs et testeurs), avec une logique de production déjà très cadrée, proche de ce que l’on rencontre dans un contexte industriel réel.
CEGI Alfa dispose de 9 sites répartis sur toute la France.
Le sujet du stage
La mission confiée consistait à développer une API REST capable d’assurer l’interface entre deux applications internes du groupe, AgileS et VivaLity, qui reposaient sur des technologies différentes et des bases de données distinctes. L’objectif était de permettre l’utilisation de certaines fonctionnalités d’AgileS depuis un dossier usager créé dans VivaLity, sans dupliquer la logique métier d’un système à l’autre.
Le périmètre fonctionnel couvrait principalement la création et la mise à jour d’un dossier usager, ainsi que la gestion d’une demande de prise en charge. En complément, le stage intégrait un enjeu de sécurisation de l’API, avec une réflexion sur l’authentification et les bons réflexes de protection des accès.
Le projet mené
Le cœur du stage a consisté à développer les endpoints permettant de créer et mettre à jour une ressource, en particulier la gestion d’une personne et d’une demande via des méthodes HTTP adaptées. Le contrôleur validait les données reçues, appelait les services métiers, puis renvoyait une réponse structurée au format ApiReponse, avec un message explicite selon le scénario rencontré.
Une autre partie importante du travail a porté sur la documentation automatique de l’API avec Swagger, afin de rendre les endpoints compréhensibles et testables directement depuis une interface web. L’intégration des annotations dans les contrôleurs et les DTO a permis de produire une documentation exploitable, utile à la fois pour les développeurs et pour les tests fonctionnels.
Le stage a aussi inclus un travail de qualité logicielle avec JUnit et Mockito, pour vérifier le comportement des composants isolés et simuler les dépendances comme la base de données. En parallèle, une attention particulière a été portée à la sécurité, notamment via l’usage de paramètres nommés dans les requêtes HQL pour limiter les risques d’injection SQL, ainsi qu’à la journalisation avec Logback pour faciliter le diagnostic.
La démarche
Le travail a commencé par une phase de documentation et de prise en main de l’existant, avec une preuve de concept menée en autonomie pour tester les technologies envisagées et configurer correctement l’environnement de développement. Cette étape a été utile pour mieux comprendre les contraintes du projet et formuler une première approche technique argumentée.
Ensuite, une phase d’analyse a permis de formaliser le besoin au moyen de diagrammes de cas d’utilisation, de classes et de séquence, ainsi qu’un MLD simplifié pour identifier les tables les plus utiles. Cette préparation a servi de base à la conception de l’API, en particulier pour structurer les ressources, les échanges de données et les dépendances entre les objets métier.
L’architecture retenue s’appuyait sur un découpage en couches avec contrôleurs, services, DAO et DTO, afin de séparer la réception des requêtes, la logique métier et l’accès aux données. Cette organisation a rendu le code plus lisible, plus maintenable et plus facile à tester, tout en facilitant l’intégration de Swagger, des logs et des tests unitaires.
Le bilan
Ce stage de dix semaines a constitué ma première expérience au sein d’une entreprise d’édition de logiciels. Il m’a permis de découvrir l’organisation nécessaire à la production d’applications de qualité, en particulier au sein d’une équipe déjà structurée où la rigueur du développement est indispensable pour que chacun puisse comprendre le travail des autres. Être intégré à des réunions d’équipe régulières et devoir collaborer avec plusieurs profils a renforcé ma capacité à travailler en groupe dans un cadre professionnel réel.
Sur le plan technique, ce stage m’a beaucoup apporté : il a consolidé mes compétences en Java et Spring Boot, déjà abordées à l’IUT, et m’a fait découvrir de nouvelles technologies comme Swagger, ainsi que l’usage du patron d’architecture MVC dans un contexte de progiciel structuré. Le calendrier prévisionnel n’a pas été tenu intégralement : la phase de preuve de concept a pris plus de temps que prévu, notamment à cause d’un changement de technologies en cours de route, ce qui a retardé le développement de la mission principale. Avec le recul, cette expérience a surtout confirmé l’intérêt d’une architecture structurée pour la maintenabilité d’un logiciel, avec un prolongement identifié pour la suite : l’implémentation de l’authentification à l’API, envisagée mais non réalisée durant le stage.
