Monolithe ou microservices à l'ère de l'IA : le vrai sujet, ce sont les frontières
L'IA ne signe pas le retour du monolithe. Elle signe le retour des bonnes frontières.
Depuis que les agents de code sont entrés dans nos workflows, une petite musique revient souvent: « À l'ère de l'IA, les monolithes sont plus adaptés que les microservices. » Je l'entends chez des clients, en mission, et dans la communauté.
Comme architecte, je pense que cette affirmation est à moitié vraie. Et c'est la moitié fausse qui coûte cher. Dans cet article, je sépare les deux, puis je partage l'approche que je recommande aujourd'hui.
Ce qui est vrai! L'IA travaille mieux dans un code centralisé
Un agent de code est redoutable quand tout le contexte est au même endroit. Dans un seul repo, typé de bout en bout, il voit à la fois l'appelant et l'appelé.
Concrètement, cela change trois choses au quotidien :
- Le refactoring transverse. Renommer un champ, changer une signature, déplacer une responsabilité : l'agent le fait en une passe et le compilateur vérifie le reste.
- La boucle de feedback. L'agent lance les tests en local, lit l'erreur et corrige. Pas besoin de cinq conteneurs, d'un broker et d'un environnement partagé.
- Les contrats explicites. Un appel de fonction typé est lisible par la machine. Un appel HTTP vers un service voisin repose souvent sur une doc approximative ou un contrat implicite.
Face à quinze microservices, l'agent bute sur ce qu'il ne voit pas : versions d'API, formats d'événements, services qu'il ne peut pas exécuter. Et le debug distribué, déjà pénible pour un humain, l'est encore plus pour une IA qui doit reconstituer une trace à travers le réseau.
Les microservices étaient d'abord une réponse organisationnelle
On l'oublie souvent mais les microservices ne sont pas nés pour écrire du meilleur code. Ils sont nés pour permettre à beaucoup d'équipes de livrer sans se marcher dessus.
C'est la loi de Conway appliquée à l'envers. Si vous avez vingt équipes, vous découpez le système en services pour que chacune déploie à son rythme.
Or l'IA change la taille des équipes. Une équipe de quatre développeurs assistés par des agents livre aujourd'hui ce qui en demandait dix hier. Moins d'équipes, c'est moins de frontières organisationnelles à matérialiser dans l'architecture. Pour une startup, une PME ou un projet client typique, le besoin de découpage recule nettement.
Ce qui est faux! Le monolithe n'est pas une solution magique
Là où la thèse dérape, c'est quand on en conclut qu'il suffit de tout mettre dans un seul bloc. Quatre raisons de nuancer.
1. Un monolithe spaghetti est pire pour l'IA. Le contexte d'un LLM reste fini. Dans une base de code où tout dépend de tout, l'agent doit charger la moitié du projet pour modifier une ligne. Il rate des effets de bord. Ce qui rend l'IA efficace, ce n'est pas l'unité de déploiement : ce sont des frontières claires.
2. L'IA réduit aussi le coût des microservices. Clients d'API, DTO, fichiers d'infra, pipelines : tout ce glue code qui freinait les microservices se génère désormais en quelques minutes. L'argument « c'est trop de boilerplate » s'affaiblit.
3. Les workloads IA poussent eux-mêmes à séparer. Une inférence sur GPU, un pipeline d'embeddings ou un job RAG de vingt minutes n'ont ni le même runtime ni le même profil de charge qu'une API métier. Mettre un modèle Python gourmand dans le même process que votre backend Node, c'est coupler leurs pannes et leur scaling.
4. Certains besoins n'ont rien à voir avec l'IA. Déploiement indépendant, isolation des pannes, scaling différencié, contraintes de conformité : ces raisons de découper restent intactes. L'IA ne les fait pas disparaître.
Ma recommandation c'est le monolithe modulaire par défaut
Le bon point de départ en 2026, c'est un monolithe modulaire : une seule unité de déploiement, découpée en modules aux frontières strictes.
Concrètement, j'applique trois règles sur mes projets:
- Des interfaces explicites entre modules. Chaque module expose une API interne publique. Le reste est privé.
- Pas d'accès croisé à la base de données. Un module ne lit jamais directement les tables d'un autre.
- Des frontières vérifiées par l'outillage. Règles de lint ou tests d'architecture en CI, pour qu'aucune dépendance interdite ne passe, qu'elle vienne d'un humain ou d'un agent.
Ces règles profitent directement à l'IA : l'agent peut travailler sur un module en chargeant peu de contexte, avec un contrat clair.
Ensuite, on extrait un service uniquement pour une raison concrète :
| Raison d'extraire | Exemple typique |
|---|---|
| Profil de charge différent | Inférence GPU, traitement d'images |
| Runtime différent | Pipeline ML en Python à côté d'un backend Node ou Java |
| Traitement long ou asynchrone | Ingestion RAG, génération d'embeddings |
| Équipe autonome | Une équipe dédiée qui doit déployer à son rythme |
| Conformité ou sécurité | Données de paiement ou de santé à isoler |
Si aucune de ces raisons ne s'applique, le module reste dans le monolithe. Et le jour où l'une d'elles apparaît, des frontières propres rendent l'extraction presque triviale.
Le vrai sujet, ce sont les frontières
Le débat monolithe contre microservices a toujours été un faux duel. L'IA le rend simplement plus visible.
Un code bien découpé rend les agents efficaces aujourd'hui. Il garde toutes les options ouvertes pour demain. Un code mal découpé les pénalise, qu'il tourne dans un seul process ou dans cinquante conteneurs.
Avant de choisir votre topologie de déploiement, posez-vous donc une seule question : mes frontières sont-elles claires, pour un humain comme pour une IA ?
Vous repensez l'architecture d'un produit ou vous hésitez à découper un monolithe existant ? Parlons-en sur tonuxcorp.com. Un audit d'architecture permet souvent de trancher en quelques jours.
TakkJokk,
