Socle d'API et d'intégration entre onze systèmes

Contexte

Onze applications métier échangeaient des données par fichiers déposés sur des serveurs partagés et par appels directs entre bases. Trois partenaires externes consommaient également ces interfaces, sans contrat formalisé ni environnement de test dédié.

Problematique

Les incidents d'intégration se diagnostiquaient par recoupement de journaux hétérogènes, les doublons de traitement étaient détectés en comptabilité, et une modification de structure de fichier cassait silencieusement un consommateur identifié plusieurs jours plus tard.

Objectifs

• Formaliser et versionner les contrats d'échange avec les partenaires
• Garantir l'absence de doublon en cas de renvoi de message
• Rendre visible et rejouable tout message en erreur

Role tenu

Responsable de conception et développeur principal sur le socle d'intégration, en binôme avec un développeur interne sur les connecteurs métier.

Solution retenue

La première étape a été un recensement exhaustif des flux : cent quarante-deux échanges identifiés, dont vingt-trois réellement critiques et neuf non documentés ailleurs que dans le code. Chaque flux a été qualifié par volume, fréquence, criticité métier et tolérance à l'indisponibilité du partenaire. Les échanges synchrones ont été repris en API REST avec des contrats OpenAPI versionnés ; les notifications et traitements longs sont passés en événements Kafka. Chaque message porte une clé d'idempotence et un identifiant de corrélation, ce qui permet de rejouer un flux sans créer de doublon et de retrouver l'ensemble de son parcours. Les messages en erreur sont isolés dans une file dédiée, consultable depuis un tableau de bord d'exploitation. Le support de niveau un peut relancer un message après correction de la donnée, sans intervention d'un développeur.

Architecture

Un socle d'intégration central expose les API internes et partenaires, avec authentification OAuth 2.1 et autorisation par scope. Les connecteurs vers les systèmes historiques traduisent les formats anciens vers les contrats cibles, de sorte que ces systèmes restent inchangés. Kafka assure la diffusion des événements métier, avec des schémas versionnés et une validation à la publication. Redis porte le suivi des clés d'idempotence à court terme. Toutes les interactions sont tracées via OpenTelemetry, avec un identifiant propagé de l'appel initial jusqu'au traitement de bout en bout.

Resultats (exemples)

• Contrats d'API versionnés et publiés pour les partenaires
• File d'erreurs consultable et rejouable par le support de niveau un
• Suppression des échanges par fichiers déposés sur serveurs partagés
• Documentation d'intégration disponible pour les partenaires externes

Indicateurs (exemples)

• Flux d'intégration recensés

  142

  Chiffre issu d'un recensement simulé — exemple de démonstration

• Flux critiques documentés avant intervention

  9 sur 23

  Situation de départ simulée — exemple de démonstration

• Délai de diagnostic d'un incident d'échange

  quelques heures à 20 minutes

  Ordre de grandeur indicatif — exemple de démonstration

Technologies

• Java
• Spring Boot
• PostgreSQL
• Redis
• Apache Kafka
• Docker
• OpenTelemetry
• OAuth 2.1 et OpenID Connect

Services mobilises

• Développement back-end Java et Spring Boot

  Je conçois et développe des services métier robustes avec Java et Spring Boot, testés et observables dès le premier jour. Le code livré est lisible, documenté et repris sans difficulté par votre équipe.

• Sécurité applicative et protection des API

  Je sécurise vos applications sur les points qui comptent vraiment : identités, autorisations, secrets et validation des entrées. Les mesures sont vérifiables et intégrées à la chaîne de livraison.

• API et intégration entre systèmes

  Je conçois les échanges entre vos applications, vos partenaires et vos systèmes historiques, avec des contrats stables et une traçabilité complète. Les intégrations cessent d'être un point de fragilité permanent.

• Observabilité et performance applicative

  Je rends vos applications diagnostiquables : traces corrélées, métriques utiles et alertes qui signalent un problème réel. Vous passez de l'interprétation des symptômes à l'identification de la cause.