Quand l'application qui a fait votre succès ralentit chaque nouvelle idée, il est temps de la repenser. Nous faisons passer des monolithes vers des architectures en services sans interrompre l'activité, avec des outils modernes et une infrastructure sur AWS.
Les signes qu'il faut migrer
Un monolithe n'est pas un défaut en soi. Il devient un frein quand une modification mineure oblige à tout retester, quand une mise en production se prépare comme une opération militaire, quand la page d'accueil s'écroule parce que le module de paiement est saturé.
Les mêmes symptômes reviennent presque toujours : les déploiements deviennent rares et risqués, la charge d'un seul module ralentit tout le reste, et les nouveaux développeurs mettent des semaines à oser toucher au code.
À l'inverse, découper trop tôt coûte cher : plus de services, c'est plus de réseau, plus de supervision, plus de choses à déployer. Nous commençons donc par mesurer, et nous ne séparons que ce qui le justifie.
Du monolithe aux services
À gauche, une application unique : catalogue, panier, paiement et recherche partagent le même code et la même base de données. À droite, la même application découpée. Une façade reçoit les requêtes et les distribue à des services indépendants, chacun avec sa propre base.
Un service peut alors être mis à jour, répliqué ou remplacé sans toucher aux autres.
Migrer sans arrêter le site
Poser une façade
Un point d'entrée unique reçoit tout le trafic. Au départ, il renvoie tout vers l'ancien système, ce qui ne change rien pour les visiteurs.
Extraire un domaine à la fois
Nous choisissons le morceau le plus utile à isoler, souvent la recherche ou le paiement, nous le reconstruisons en service, puis nous le branchons derrière la façade.
Doubler, comparer, basculer
L'ancien et le nouveau tournent côte à côte. Nous comparons les résultats, puis nous basculons le trafic par paliers, avec un retour en arrière possible à chaque étape.
Retirer l'ancien code
Quand un domaine est stable, son ancienne version disparaît. Le monolithe rétrécit jusqu'à ne plus avoir de raison d'exister.
Tenir la charge
Une architecture en services ne tient la charge que si elle est outillée pour cela : un cache devant les pages et les requêtes les plus demandées, des files de messages pour absorber les pics (une vente privée, un envoi massif) sans bloquer l'utilisateur, une supervision qui indique quel service souffre avant que les clients ne l'écrivent.
Nous mettons en place ces briques sur AWS, et nous dimensionnons l'infrastructure à partir de mesures plutôt que d'intuitions.
Technologies
Les technologies ne font pas le projet : elles servent un besoin. Nous partons de ce que l'application doit faire et supporter, puis nous retenons l'outil qui y répond au meilleur coût, en privilégiant des briques connues, documentées et faciles à recruter.
Voici notre boîte à outils, avec pour chaque outil la situation dans laquelle nous le choisissons.
Survolez ou touchez un nom pour lire le détail.
Cloud et architecture
Interfaces
Serveur
Données
Contenu et e-commerce
IA appliquée
Où l'IA a sa place
Nous intégrons de l'IA quand elle règle un problème précis : une recherche qui comprend la question plutôt que les mots, un assistant qui trie les demandes entrantes, une saisie répétitive qu'on automatise.
Nous la déconseillons quand une règle simple ferait mieux, ou quand une erreur coûterait cher et que personne ne relirait le résultat. Le test que nous appliquons : si on retire l'IA, qu'est-ce qui se dégrade, et de combien ?
Un exemple : 41watch
41watch vend des montres de collection suisses. Son site tournait sur PrestaShop. Nous l'avons fait passer vers un environnement en micro-services.
La boutique est restée ouverte pendant toute la migration. Le chantier a duré un an, sur Next.js, Strapi et AWS.
Votre application montre ses limites ?