Orchestrer quatre services en production pour une plateforme enterprise

Un éditeur de solutions de formation corporate nous a confié la construction d'une plateforme composée de quatre services indépendants — chacun avec sa propre technologie, sa propre base de données, et son propre rythme d'évolution. Le défi : que l'ensemble fonctionne comme un seul produit aux yeux de l'utilisateur.

Le contexte

Notre client développait une plateforme de formation pour les entreprises. Mais pas une plateforme monolithique classique. Le produit intégrait des briques très différentes par nature :

• Une application métier pour gérer les apprenants, les programmes et les organisations
• Une interface web pour les apprenants et les managers
• Un moteur d'intelligence artificielle conversationnel, avec ses propres modèles et sa propre mémoire
• Un tableau de bord pour superviser les conversations de l'IA

Chacune de ces briques avait ses propres contraintes techniques. Le moteur IA nécessitait un écosystème Python avec des librairies de traitement du langage naturel. L'application métier était construite en TypeScript. L'interface web avait besoin de réactivité et de rendu rapide. Et le tout devait tourner en production de façon fiable, avec des mises à jour indépendantes.

Le défi

1. Quatre technologies différentes qui doivent communiquer. L'application métier (TypeScript) devait envoyer le contexte de chaque apprenant au moteur IA (Python), récupérer les réponses, et les stocker. Les deux services avaient des bases de données distinctes. Les erreurs de communication ne devaient pas faire tomber l'ensemble.

2. Deux bases de données à maintenir en parallèle. La base principale stockait les utilisateurs, les organisations et les programmes. La base du moteur IA stockait les sessions conversationnelles et la mémoire de l'assistant. Les deux devaient être sauvegardées, migrées et monitorées indépendamment.

3. Chaque service devait évoluer sans bloquer les autres. On devait pouvoir mettre à jour le modèle d'IA sans toucher à l'application métier. On devait pouvoir refaire l'interface web sans impacter le moteur IA. Et on devait pouvoir tout déployer sans interruption de service.

4. La sécurité en production. Certificats SSL automatiques, headers de sécurité, isolation des services — rien de tout ça ne devait être géré manuellement.

Notre approche

Un service = une responsabilité

On a structuré l'architecture autour d'un principe simple : chaque service fait une seule chose, et la fait bien.

Le service métier gère tout ce qui concerne les utilisateurs, les organisations, les programmes de formation, les notifications et les intégrations (calendrier, email, messagerie d'entreprise). C'est le chef d'orchestre : il sait qui est connecté, où il en est dans son programme, et ce qu'il faut lui envoyer.

Le service IA ne connaît que les conversations. Il reçoit un contexte (qui est l'apprenant, quel est son programme, quelles sont ses missions en cours) et produit une réponse adaptée. Il gère sa propre mémoire conversationnelle dans sa propre base de données, et enrichit progressivement le profil de chaque apprenant au fil des échanges.

L'interface web consomme l'API du service métier et affiche les données. Elle ne sait rien de l'IA ni de la base de données — elle ne parle qu'à l'API.

Le tableau de bord IA donne une visibilité en temps réel sur les conversations : contenu des échanges, consommation de tokens, profils enrichis. C'est un outil interne pour l'équipe produit, pas pour les utilisateurs finaux.

Un point d'entrée unique

En production, tous les services sont accessibles via un point d'entrée unique qui s'occupe du routage. Une requête vers l'application web est dirigée vers le bon service. Une requête vers l'API va vers le service métier. L'utilisateur ne voit qu'un seul domaine — il n'a aucune idée que quatre services travaillent en coulisses.

Ce point d'entrée gère aussi les certificats SSL automatiquement : renouvellement, négociation, et headers de sécurité (protection contre le clickjacking, le sniffing de contenu, les connexions non sécurisées). Zéro intervention manuelle.

Des bases de données isolées

Chaque service qui a besoin de persister des données a sa propre base. La base métier contient 18 tables (utilisateurs, organisations, conversations, notifications, événements calendrier, logs...). La base IA contient les sessions et les états conversationnels du moteur de langage.

Cette isolation a un coût : on maintient deux bases au lieu d'une. Mais le bénéfice est concret : quand on a changé le moteur d'IA et restructuré sa base de données, l'application métier n'a pas été impactée. Aucun utilisateur n'a vu la différence.

Un déploiement reproductible

L'ensemble de l'infrastructure est décrit dans un seul fichier de configuration. En une commande, on déploie les sept composants : le routeur d'entrée, les deux bases de données, le service métier, l'interface web, le service IA, et le tableau de bord. Chaque service a ses propres vérifications de santé — si le service IA ne répond pas, le système le détecte automatiquement.

Les mises à jour se font service par service. On peut déployer une nouvelle version de l'interface web sans toucher au service IA. On peut mettre à jour le modèle de langage sans redémarrer l'application métier. Chaque équipe avance à son rythme.

Le résultat

Livré et en production :

• 4 services applicatifs indépendants, chacun avec sa propre technologie et son propre cycle de déploiement
• 2 bases de données isolées (métier + IA) avec sauvegardes indépendantes
• 1 point d'entrée unique avec SSL automatique et headers de sécurité
• 7 composants orchestrés et déployables en une commande
• Vérifications de santé automatiques sur chaque service
• Mises à jour indépendantes — changer le modèle d'IA ne nécessite pas de redéployer le reste
• 6 intégrations externes (OpenAI, Microsoft Teams, Outlook, Mailjet, Notion, Make.com) connectées au service métier sans impacter les autres services

Lire aussi : Intégrer un assistant IA dans une plateforme corporate — comment le service IA de cette plateforme booste l'engagement des apprenants.

Ce qu'il faut retenir :

• Découper en services indépendants n'est pas une question de mode technique — c'est une question de vitesse d'évolution. Chaque brique avance à son rythme sans bloquer les autres
• L'isolation des bases de données a un coût de maintenance, mais elle protège contre l'effet domino : un changement sur l'IA ne casse pas le métier
• Un fichier de configuration unique pour tout déployer garantit que l'environnement de production est toujours reproductible — pas de "ça marchait sur ma machine"

Technologies : NestJS, Next.js, Python FastAPI, LangChain, PostgreSQL, Traefik, Docker Compose