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 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.
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
Cette première expérience longue en entreprise a confronté à un environnement technique inédit et à une forte part d’autonomie. Elle a surtout permis de développer une méthode de travail plus rigoureuse : analyser un besoin, structurer une solution, documenter proprement, échanger clairement avec les interlocuteurs et contrôler la qualité avant la mise à disposition.
La collaboration avec un prestataire externe a été particulièrement formatrice, car elle a exigé de formuler des retours précis, de rédiger des points d’avancement exploitables et de s’adapter à des contraintes d’intégration réelles. Avec le recul, cette alternance a confirmé un intérêt marqué pour le développement backend, la cybersécurité et la conception de solutions robustes, lisibles et maintenables.
