Le contexte
L'écosystème comptait déjà plusieurs applications métier développées séparément, avec des utilisateurs communs et des données qui devaient circuler entre elles. La plateforme U-App visait à unifier ce socle : une seule porte d'entrée pour les applications clientes, une seule source d'identité, et des domaines métier autonomes derrière.
Le découpage en services n'était pas motivé par la charge, mais par l'organisation : permettre à des développements parallèles d'avancer sans se bloquer mutuellement au moment de livrer.
Ce que j'ai construit
Passerelle d'API
point d'entrée unique routant vers les services internes, avec authentification centralisée et surveillance de santé.
Service back-office
gestion commerciale : prospects, contrats, équipes, suivi d'activité des télévendeurs.
Monnaie de fidélité
comptes, transactions, conversions et échanges auprès de partenaires.
Moteur de quiz gamifié
niveaux, quêtes à conditions, questionnaires et suivi des réponses.
Service de contenu
actualités ciblées, FAQ, politiques de confidentialité, traductions et données de référence.
Annuaire d'identité
référentiel centralisé des utilisateurs.
Serveur temps réel
diffusion d'événements aux applications clientes.
Architecture & choix techniques
La passerelle isole les applications clientes de la topologie interne : elles interrogent une seule adresse, sans connaître le découpage en services ni ses évolutions. Elle porte aussi l'authentification, ce qui évite de la réimplémenter dans chaque service.
Les services communiquent par un bus d'événements plutôt que par appels directs. C'est le choix qui structure tout le reste : chaque service publie ce qu'il fait et consomme ce qui l'intéresse, sans savoir qui écoute. Un service indisponible ne bloque pas les autres — il rattrape son retard à son redémarrage.
L'identité est centralisée dans un annuaire, choix classique en environnement multi-applications : un utilisateur, un référentiel, et une révocation d'accès qui s'applique partout instantanément.
Le temps réel passe par un service dédié avec authentification par clé applicative, plutôt que d'être intégré à chaque service — une seule connexion persistante côté client, quel que soit le nombre de domaines concernés.
Les défis techniques
Le coût réel des microservices. Cette architecture déplace la complexité plutôt qu'elle ne la supprime : ce qui était un appel de fonction devient un appel réseau faillible, à tracer et à réessayer.
La cohérence différée. Sans transaction globale, il faut accepter que les services soient temporairement désynchronisés et concevoir l'interface en conséquence.
L'observabilité. Suivre une action utilisateur qui traverse quatre services impose une journalisation corrélée, sans laquelle tout diagnostic devient une enquête.
Le versionnement des messages. Modifier la forme d'un événement publié affecte tous ses consommateurs : les évolutions doivent rester rétrocompatibles.
L'environnement de développement. Faire tourner neuf services plus leurs dépendances sur un poste demande une orchestration soignée pour rester utilisable au quotidien.