Refondre les monolithes pour encaisser trois fois plus de trafic
Le cas en 30 secondes
- Problème
- La plateforme derrière un portefeuille de 1 Md€ avait grandi en monolithe construit projet par projet. Le traitement synchrone verrouillait la base de données lors des pics de charge, et l’architecture ne pouvait pas absorber la croissance de volume projetée.
- Ce que j’ai fait
- J’ai construit le dossier pour le CEO, le CIO et le CTO. J’ai obtenu des ventes une capacité d’équipe dédiée au remboursement de la dette technique. J’ai découpé le domaine en services temps réel et asynchrones, puis conçu et fait valider l’architecture cible. Je mène la migration par phases vers le cloud du groupe.
- Impact
- La migration est en cours, adossée à une architecture validée pour une capacité 3x. Les applications sont dans Allianz Cloud (jalon de janvier) et les dépôts sur le GitHub du groupe. Le trafic est routé par la passerelle API du groupe.
Le déroulé
- 2025 — Le point de départ
La contrainte était invisible tant qu’elle n’était pas nommée. J’ai construit le dossier d’alerte : risques opérationnels, de sécurité et commerciaux sur une page. Puis je l’ai porté au CEO, au CIO et au CTO pour obtenir le mandat.
- Obtenir la capacité
L’alignement des dirigeants a précédé l’architecture : mandat et capacité d’équipe d’abord, face à la pression commerciale pour continuer à livrer des fonctionnalités. Les sponsors exécutifs ont porté le mandat ; les ventes ont protégé la capacité de livraison consacrée au remboursement de la dette.
- La décision d’architecture
Découper par exigence de latence, puis par domaine. Les contrôles de couverture et la valorisation restent synchrones, sur une voie rapide. Le traitement documentaire passe sur une voie lourde asynchrone, derrière un orchestrateur de flux de travail. Les frontières de domaine ont été définies avant la migration : les services bougent un par un. Cloud groupe, ingénierie sécurité et architectes d’entreprise ont validé la conception.
- La migration
Des jalons, pas un big bang. L’infrastructure cloud d’abord, puis les dépôts, puis la passerelle API — chaque étape forçant une vraie décomposition plutôt qu’un simple portage à l’identique. Le raccordement à la passerelle a joué le rôle de contrainte structurante. Router le trafic exigeait de découper les applications selon les frontières de domaine. La décomposition est ainsi devenue réelle avant la reconstruction.
- En cours
L’architecture cible sépare une voie rapide synchrone d’une voie documentaire asynchrone, dimensionnée pour trois fois le trafic actuel.
3xla capacité de trafic dans l’architecture cible validéeVoie rapide synchrone, voie documentaire asynchrone1 Md€de portefeuille porté par la plateformeArchitecture et stratégie IA/data portées de bout en bout
Ce que j’en retiens
Une refonte d’architecture justifie son coût quand elle lève un goulot d’étranglement que quelqu’un sait nommer. Elle n’est financée que lorsque la direction générale sait le nommer aussi.