API d’interfaçage entre deux logiciels métiers

Cette réalisation a été menée durant un stage de dix semaines chez CEGI Alfa, au sein de l’équipe AgileS, dans un contexte d’édition de logiciels métiers pour les secteurs social, médico-social et sanitaire. Le projet répondait à une problématique d’interopérabilité entre deux applications du groupe, développées dans des environnements techniques différents, avec l’objectif de fluidifier les échanges de données sans redévelopper des fonctionnalités déjà existantes.

Cette réalisation porte sur le développement d’une API REST en Java / Spring destinée à faire le lien entre deux logiciels métiers du groupe CEGI Alfa : AgileS, développé en Java, et VivaLity, développé en .NET, chacun reposant sur sa propre base de données. L’objectif était de permettre à VivaLity de s’appuyer sur certaines fonctionnalités déjà présentes dans AgileS, notamment autour de la gestion des dossiers usagers, sans dupliquer inutilement la logique métier déjà en place.

Le périmètre fonctionnel initial portait sur la création et la mise à jour d’un dossier usager, la gestion d’informations liées aux personnes et aux ménages, ainsi que la création et la mise à jour de demandes de prise en charge via des échanges JSON exposés par des endpoints dédiés. Cette réalisation a constitué une première expérience complète de développement backend dans un environnement métier dense, avec un existant important, une architecture déjà structurée et un besoin encore partiellement mouvant au démarrage.

Le projet répondait à un besoin concret de l’entreprise : éviter les doubles saisies, limiter les développements redondants entre deux logiciels majeurs du groupe et améliorer la circulation des données entre outils complémentaires. Sans cette API, deux options restaient possibles : redévelopper dans VivaLity des fonctionnalités déjà matures dans AgileS, ou maintenir des traitements plus manuels, avec un risque accru d’erreurs, d’incohérences de données et de perte de temps pour les équipes.

Les enjeux étaient à la fois techniques et fonctionnels. Il fallait rendre deux applications interopérables malgré des technologies différentes, garantir la cohérence des données échangées, rester compatible avec l’architecture existante et poser une base suffisamment robuste pour être prolongée ensuite. Le principal risque venait toutefois du cadrage initial, encore partiel au début du stage, qui obligeait à faire évoluer la compréhension du besoin au fil des échanges, de l’analyse de l’existant et des contraintes découvertes en cours de route.

La première phase a été consacrée à la prise en main de l’environnement technique et à la recherche. Plusieurs technologies du projet m’étaient encore peu familières ; j’ai donc approfondi le fonctionnement d’une API REST, l’architecture MVC utilisée dans AgileS, le rôle des DAO et des DTO, le fonctionnement d’Hibernate ainsi que différentes solutions techniques envisageables pour mettre en place l’interface attendue.

Dans ce cadre, j’ai réalisé une preuve de concept avec Spring Boot afin d’explorer rapidement les principes de développement d’une API REST, de configurer mon poste de travail et de proposer une première base de réflexion à l’équipe. Cette phase a accéléré ma montée en compétence, même si le prototype n’a pas été conservé tel quel dans la version finale, l’équipe ayant choisi de rester alignée avec l’environnement déjà utilisé dans AgileS, basé sur Spring avec une configuration plus manuelle.

J’ai ensuite analysé l’existant en m’appuyant sur le web service GDC/AgileS déjà présent dans l’écosystème de l’entreprise. Cela m’a permis d’identifier des méthodes métier réutilisables et de mieux comprendre les ressources à manipuler. En parallèle, j’ai étudié une copie de la base de données AgileS afin de modéliser les liens entre les principales tables utiles au projet, notamment autour des personnes, des ménages et des demandes de prise en charge.

Cette phase d’analyse m’a conduit à produire plusieurs schémas et diagrammes, notamment un MLD, un diagramme de cas d’utilisation et un diagramme de séquence. Ces livrables ont servi à clarifier le périmètre avant le développement, à anticiper certaines difficultés de conception et à limiter les retours en arrière sur des choix structurants.

Même si j’ai porté une grande partie de cette réalisation en autonomie, le projet s’inscrivait dans un cadre collectif au sein de l’équipe AgileS. Mon principal interlocuteur était Djamel Massaid, maître de stage et chef de projet AgileS, qui validait les grandes orientations du travail, tandis que plusieurs échanges avec les développeurs de l’équipe m’ont aidé à mieux comprendre certaines méthodes métier et certains mécanismes techniques déjà en place.

Les discussions autour du web service GDC/AgileS ont été particulièrement utiles, car elles m’ont permis d’identifier les briques de logique métier réutilisables et de mieux cerner ce qu’il fallait réellement exposer dans la future API REST. Dans les faits, cette réalisation m’a demandé un niveau d’autonomie important : l’équipe était mobilisée par ses propres échéances, certains membres travaillaient à distance et l’accompagnement n’était pas détaillé sur chaque étape.

Cette configuration m’a obligé à structurer davantage mes recherches, à consulter le code existant, la documentation interne et la base de données, puis à formuler des questions plus précises au bon moment. C’est aussi ce qui a renforcé ma capacité à progresser dans un environnement complexe sans attendre un cadrage exhaustif dès le départ.

À la fin du stage, j’avais livré un socle fonctionnel d’API REST permettant de créer et de mettre à jour des personnes, de gérer certaines informations associées aux ménages, ainsi que de créer et de modifier des demandes de prise en charge. Les contrôleurs, les DTO, les services, la logique de validation, la structure des réponses et la documentation Swagger formaient un ensemble cohérent, testable et suffisamment avancé pour démontrer la faisabilité technique du projet dans l’environnement AgileS.

L’API pouvait être démontrée dans un environnement proche du réel à partir d’une copie de la base AgileS, et les scénarios principaux montraient bien la création et la mise à jour des ressources attendues. La documentation Swagger UI représentait également un résultat important, car elle rendait l’API plus lisible, plus simple à tester et plus facile à comprendre pour les autres intervenants du projet.

Pour l’entreprise, ce travail a permis de poser une base technique concrète pour l’interfaçage entre AgileS et VivaLity, en montrant qu’il était possible de réutiliser intelligemment des services métier existants plutôt que de redévelopper les mêmes fonctionnalités dans une autre application. Pour moi, cette réalisation a renforcé mes compétences en développement backend Java/Spring, en conception d’API REST, en modélisation des échanges, en tests unitaires, en documentation technique et en adaptation à un environnement logiciel complexe.

À la fin du stage, le projet n’était pas totalement finalisé, mais un périmètre clair et déjà exploitable avait été mis en place. Il restait notamment à compléter certaines parties métier plus avancées, en particulier autour de la gestion complète des affectations logement et de plusieurs cas fonctionnels liés aux dossiers usagers.

Des travaux complémentaires étaient également à prévoir sur les tests d’intégration, sur l’amélioration continue de la documentation technique et sur la consolidation du comportement global de l’API dans un cadre de déploiement plus complet. La sécurisation de l’API constituait aussi un prolongement important, car l’authentification faisait partie des objectifs envisagés mais n’avait pas encore été implémentée durant le stage.

Même sans disposer d’un retour complet sur la suite donnée au projet après mon départ, les bases techniques produites, les choix de conception réalisés et la documentation générée pouvaient clairement servir de point d’appui à une reprise ou à une évolution future.

Avec du recul, cette réalisation a été particulièrement formatrice. Elle m’a confronté en même temps à un besoin encore flou au départ, à un environnement technique nouveau, à une architecture existante dense et à la nécessité de produire quelque chose de cohérent dans un temps limité. Le point le plus réussi me semble être la montée en autonomie, combinée à une bonne capacité d’adaptation et à une intégration progressive du travail dans un existant métier complexe.

Si ce projet devait être repris aujourd’hui, je formaliserais plus tôt les besoins réels avec des échanges plus fréquents et plus cadrés, afin d’éviter de perdre du temps sur des zones encore imprécises au début. Je renforcerais également les tests d’intégration, je pousserais davantage le découplage de certains composants et j’orienterais la sécurisation de l’API vers une approche plus moderne, par exemple avec JWT ou OAuth2 selon le contexte d’intégration.

Cette réalisation m’a surtout appris qu’un projet backend réussi ne repose pas uniquement sur le code produit. Il dépend aussi de la capacité à comprendre progressivement le besoin, à s’adapter à l’existant, à documenter clairement son travail et à maintenir un dialogue utile avec les acteurs techniques et métier.