Le pendule s'est lassé de se balancer

Deux groupes, un WhatsApp et aucun gagnant clair

Il n'est pas nécessaire d'inventer une anecdote : quiconque dirige une équipe d'ingénierie en 2026 a vécu cette scène. Un groupe jure que briser le monolite était la meilleure décision de sa carrière. L'autre groupe, dans le même chat, envoie des captures d'écran de factures Kubernetes qui ne descendent pas à cinq chiffres par mois. Aucun ne ment. C'est justement le problème : l'architecture logicielle a cessé d'être une discussion technique et est devenue une discussion d'identité tribale, avec des données réelles des deux côtés soutenant des positions opposées.

Avant de me joindre à un groupe, j'ai décidé de faire ce que je n'avais pas fait en un an et demi de participation à ce débat sur Slack : poursuivre chaque chiffre jusqu'à son origine. Ce que j'ai trouvé n'est pas un gagnant. C'est une carte de qui fait quoi, pourquoi, et — c'est ce qui est intéressant — à quel point le discours public est distinct du comportement réel derrière les portes.

Le chiffre que tout le monde cite et que personne ne peut désigner du doigt

Je commence par la découverte la plus inconfortable de cette enquête, car c'est celle qui explique le mieux comment le consensus est fabriqué dans l'industrie du logiciel.

J'ai recherché le chiffre « 42 % d'organisations qui ont adopté des microservices sont en train de consolider des services en unités plus grandes » dans des dizaines d'articles de 2025 et 2026. Tous l'attribuent à « une enquête de la CNCF de 2025 ». L'un de ces articles — qui cite également le chiffre — confesse dans ses propres notes de production qu'il a été rédigé par un pipeline automatisé avec IA « vérifié contre le rapport CNCF x SlashData 2026 » (ManoIT / DEV Community, 2026). Je suis allé directement sur cncf.io, j'ai examiné le rapport de l'enquête annuelle 2024 (CNCF, 2025), l'annonce de novembre 2025 sur l'étude avec SlashData (CNCF, 2025) et le rapport d'enquête le plus récent publié par la fondation, et dans aucun des documents que j'ai pu ouvrir, ce 42 % avec cet énoncé exact n'apparaît. Ce qui apparaît, de manière cohérente, c'est que 46 % des développeurs backend travaillent avec des microservices et que l'utilisation de conteneurs et de Kubernetes continue de croître (CNCF/SlashData, 2025) — ce chiffre spécifique, je l'ai confirmé directement contre le communiqué original de la fondation.

Est-ce que cela signifie que 42 % est faux ? Pas nécessairement - c'est exactement le type de chiffre qu'une fondation rapporte dans un webinar ou un side-panel qui n'est pas toujours indexé de la même manière que le PDF principal, et qui apparaît cité de manière presque identique dans au moins huit sources indépendantes avec un niveau de détail cohérent (y compris la chute de l'adoption de service mesh de 18 % à 8 %) (SoftwareSeni, 2026 ; ThirdEyeData, 2026 ; ByteIota, 2026). Mais pour un article qui se vante de vérifier chaque donnée, l'honnêteté oblige à dire ceci : 42 % est le chiffre le plus cité de tout le débat architectural de 2026, et je n'ai pas réussi à le confirmer contre un document primaire lisible. Traitez-le comme « largement répété, non vérifié de manière indépendante », et non comme un fait acquis. C'est un exemple parfait de la manière dont le « consensus » en technologie est parfois simplement du contenu généré par IA qui se cite lui-même en cercle.

Ce qui est solide, avec une source primaire confirmée - et qui manquait dans la bibliographie du brouillon original de cet article, donc je suis allé chercher le post réel - : la migration d'Amazon Prime Video. L'équipe d'ingénieurs a documenté sur son propre blog comment elle a consolidé un service de surveillance de la qualité de la vidéo d'une architecture distribuée à un monolithe, avec une réduction de 90 % des coûts d'infrastructure (Amazon Prime Video Engineering, 2023).

Le cas le plus cité contre les microservices

Réduction des coûts d'infrastructure d'Amazon Prime Video après consolidation de son service de surveillance vidéo en monolithe.

90%

Réduction des coûts d'infrastructure (2023)

Ver los datos

Le cas le plus cité contre les microservices

Indicador	Valor
Réduction des coûts d'infrastructure (2023)	90%

Ce cas - déjà vieux de trois ans - est toujours la référence obligée de tous ceux qui argumentent contre les microservices, et à juste titre : il vient de la même entreprise qui a enseigné les microservices au monde.

Shopify : la preuve que « monolithe » n'est pas synonyme de « petit »

Si l'argument en faveur du microservice a toujours été « vous ne pourrez pas scaler sans eux », Shopify le contredit avec des chiffres concrets et vérifiables sur son propre blog d'ingénierie. La plateforme fonctionne ce que ses propres employés appellent un « monolithe majestueux » : une seule application Ruby on Rails, organisée internement en composants avec des frontières strictes imposées par un outil qu'ils ont développé à cet effet, Packwerk (Shopify Engineering, s.f.). Pendant les pics de trafic de Black Friday, l'infrastructure supporte des dizaines de terabytes de données par minute, avec la couche de bases de données partitionnée par magasin (shop_id) au lieu de fragmenter le code d'application en services indépendants (Kovyrin, en TechWorld with Milan, 2025).

La distinction est importante : Shopify n'a pas évité la modularité, mais la distribution. Ses composants sont séparés par des frontières de code (bounded contexts, dans le langage de Domain-Driven Design), mais s'exécutent dans le même processus, sans appels réseau entre eux. C'est exactement la définition de « monolithe modulaire » que presque toute la littérature de 2025-2026 identifie comme la troisième voie réelle, non binaire, entre monolithe classique et microservices (Al-Qora'n & Al-Said Ahmad, 2025) - la première revue systématique de la littérature académique sur le sujet, publiée dans la revue Future Internet, a trouvé à peine 15 études primaires examinées par des pairs entre 2020 et mai 2025, ce qui dit quelque chose d'important : la pratique de l'industrie est en avance de plusieurs années sur la recherche formelle qui la soutient.

Radar 1 - Ce que font (vraiment) les grandes maisons de logiciels

Radar 1 — Ce que font (vraiment) les grandes maisons de logiciels

Notes éditoriales de 0 à 10 attribuées à partir des déclarations citées dans le corps du texte pour chaque entreprise, et non une enquête formelle. Chaque axe est orienté de sorte qu'une valeur plus élevée soit toujours « meilleure » sur cet axe.

Indépendance du legacyVitesse de déploiementSimplicité opérationnelleIntégration native d'IA/agentsEfficacité coûts/caractéristiquesMaturité de la gouvernance des frontières

• SAP (ERP hérité en transition)
• Shopify (monolithe modulaire natif)
• Oracle (SOA hybride)
• Anthropic / OpenAI (IA native)

Ver los datos

Radar 1 — Ce que font (vraiment) les grandes maisons de logiciels

Eje	SAP (ERP hérité en transition)	Shopify (monolithe modulaire natif)	Oracle (SOA hybride)	Anthropic / OpenAI (IA native)
Indépendance du legacy	2	8	4	9
Vitesse de déploiement	3	7	4	9
Simplicité opérationnelle	4	7	3	8
Intégration native d'IA/agents	3	5	3	10
Efficacité coûts/caractéristiques	3	8	4	7
Maturité de la gouvernance des frontières	6	9	5	8

Avec cela sur la table, regardons les six entreprises qui ont posé cette question - SAP, Oracle, Microsoft, Apple, Anthropic et OpenAI - et une dizaine d'autres qui apparaissent citées de manière récurrente dans la littérature technique de 2025-2026.

<strong>SAP</strong> est peut-être le cas le plus honnête du lot : sa propre communauté technique décrit le noyau de S/4HANA comme un « monolithe modulaire massif » qui traverse une décomposition progressive vers des architectures natives de cloud, sans date de financement promise (SAP Community, 2025). Ce n'est pas du marketing de transformation digitale : c'est une entreprise de 50 ans qui admet que briser un monolithe d'ERP prend plus d'une décennie.

<strong>Oracle</strong> court en parallèle deux discours. Fusion Applications est né en 2011 sur une architecture orientée services (SOA) classique (Oracle, Wikipedia, s.f.), et depuis lors, le « Projet Spectra » déplace des fonctionnalités vers des microservices dans des conteneurs sur Kubernetes géré (OKE), en utilisant le framework Helidon (Oracle Cloud Blog, 2023) - mais le propre blog d'Oracle décrit le processus comme quelque chose qui se passe « derrière les coulisses », sans que le client le perçoive, précisément parce qu'une réécriture totale est inviable pour un logiciel qui gère les salaires et les bilans comptables de milliers d'entreprises.

<strong>Microsoft</strong> n'a pas de communiqué unique sur le sujet, mais son comportement peut être lu dans la littérature technique de tiers : le modèle dominant en 2025-2026 pour .NET entreprise est exactement le même que dans le reste de l'industrie — commencer avec un monolithe modulaire, extraire des microservices uniquement avec des preuves réelles de nécessité — (Murmu Software, 2026), et sa propre pratique interne d'IA (l'"orchestrateur avec des sous-agents isolés" que je décris plus bas) confirme la même philosophie.

<strong>Apple</strong> ne publie pas d'architecture de backend, mais à l'intérieur de son propre écosystème de développeurs, le modèle dominant pour les applications iOS grandes est le "monolithe modulaire" via Swift Package Manager, et non les microservices : séparer en frameworks internes sans fragmenter le processus de compilation et de déploiement (Tariq, 2025). C'est le même modèle que Shopify utilise dans son backend, appliqué au client.

<strong>Anthropic et OpenAI</strong> sont le cas le plus intéressant de ce radar, car ils ne concurrencent pas dans les ERP ou le e-commerce : ils concurrencent sur la façon dont les agents d'IA sont orchestrés, et là, leur architecture <em>est</em> le produit. Anthropic documente sur son propre blog d'ingénierie que ses agents fonctionnent comme une boucle unique avec des outils et des sous-agents délimités sous un orchestrateur central, et non comme une toile de microservices peer-to-peer (Anthropic Engineering). OpenAI a abandonné son framework expérimental Swarm (2024) pour le SDK d'Agents (2025), mais a maintenu le même principe de conception minimaliste : un agent qui décide quand transférer le contrôle à un autre, sans coordonnateur central complexe ni communication en toile (OpenAI Swarm repo ; Tao An, 2026). Je reviendrai sur cela dans la section sur l'IA, car c'est pour moi la découverte la plus révélatrice de toute la recherche.

Pour ce radar, j'ai choisi six axes que la propre recherche a identifiés comme les plus révélateurs : <strong>l'indépendance architecturale du legacy</strong>, <strong>la vitesse de déploiement</strong>, <strong>la complexité opérationnelle assumée</strong>, <strong>l'intégration native d'IA/agents</strong>, <strong>le coût de maintenance par fonctionnalité</strong> et <strong>la maturité de la gouvernance des frontières</strong> (à quel point on prend au sérieux la loi de Conway). J'ai comparé quatre profils représentatifs — SAP (ERP hérité en transition), Shopify (monolithe modulaire natif), Oracle (SOA hybride) et Anthropic/OpenAI (IA native, orchestrateur + sous-agents) — car essayer de graphiquer 24 entreprises dans un seul radar aurait été illisible ; le reste du paysage corporatif — Microsoft, Apple, Amazon, Google, Meta, Netflix, IBM, Salesforce, Stripe et d'autres qui apparaissent dans la littérature de 2025-2026 — est discuté dans le corps du texte et dans la méthodologie, et non dans les axes du graphique.

Radar 2 — L'autre camp : qui maintient l'open source

Radar 2 — L'autre camp : qui maintient le open source

Notes éditoriales de 0 à 10 dérivées des déclarations citées sur chaque projet, et non une enquête formelle.

Philosophie monolithique déclaréeÉquipe de maintenance réduiteModularité interne sans réseauÉchelle d'adoptionIndépendance d'une fondation

• Linux (noyau)
• PostgreSQL
• Kubernetes
• Proxmox

Ver los datos

Radar 2 — L'autre camp : qui maintient le open source

Eje	Linux (noyau)	PostgreSQL	Kubernetes	Proxmox
Philosophie monolithique déclarée	10	8	1	9
Équipe de maintenance réduite	3	5	1	9
Modularité interne sans réseau	8	7	2	7
Échelle d'adoption	10	8	9	5
Indépendance d'une fondation	6	7	2	9

Ici, la question de l'utilisateur qui a originé cette pièce était exacte : qu'est-ce que font ceux qui maintiennent Linux Foundation, MySQL, MariaDB, PostgreSQL, Proxmox et 30 autres projets à haut impact ? La réponse courte : le monde de l'open source a <em>décennies</em> de discussion sur ce sujet, bien avant que "microservices" soit un mot à la mode corporatif.

Le cas fondateur est le <strong>noyau de Linux</strong>. En 1992, Andrew Tanenbaum a écrit publiquement à Linus Torvalds que créer un noyau monolithique à cette date était "un énorme pas en arrière vers les années 70" et que les micro-noyaux avaient déjà gagné le débat académique (Tanenbaum-Torvalds debate, Wikipedia, 1992). Torvalds a répondu, avec le ton qui le caractérise, que les micro-noyaux "déplacent le problème dans l'espace de la communication, qui est un problème plus grand que celui qu'ils prétendent résoudre" (Torvalds, sobre el debate micro vs. monolítico). Trente-quatre ans plus tard, Linux — monolithique — fonctionne sur la grande majorité des serveurs de la planète, et GNU Hurd — micro-noyau — est toujours un projet académique. L'ironie est évidente : l'infrastructure qui permet de faire fonctionner les microservices (conteneurs, Kubernetes, le cloud entier) est construite sur un noyau qui a gagné sa propre guerre en étant monolithique.

<strong>PostgreSQL, MySQL et MariaDB</strong> vivent la même logique dans la couche de données : ce sont des processus monolithiques (ou presque) par conception, et la propre communauté discute activement si "décomposer" une base de données en microservices de données a du sens ou si c'est simplement réintroduire la complexité du réseau où il y avait auparavant un appel de fonction (Reintech, 2026). La réponse dominante en 2025-2026 : maintenir la base de données monolithique et mettre des microservices d'application autour, et non à l'intérieur.

<strong>Proxmox</strong> est l'exemple le plus évident de l'"autre style" de logiciel open source : une petite entreprise autrichienne, sans le soutien d'une fondation comme CNCF ni de gouvernement multi-vendeur, qui maintient une plateforme tout-en-un (hyperviseur + conteneurs LXC + stockage + réseau) délibérément simple face à l'alternative native de Kubernetes, KubeVirt (Kubermatic, 2026). C'est, dans les logiciels d'infrastructure, le même modèle que André Staltz a décrit il y a des années comme l'"école monolithique" de l'open source : des projets comme WordPress, Django ou Linux lui-même qui résolvent un grand problème comme un bloc cohésif, contre l'"école modulaire" qui publie une utilité par paquet (Staltz, 2018). Onze ans plus tard, c'est toujours le cadre mental le plus utile que j'ai trouvé pour expliquer pourquoi Gogs (un seul binaire, un seul mainteneur) et Kubernetes (des centaines de pièces coordonnées) représentent des philosophies opposées du même mouvement open source (Laoutaris, 2025).

Pour ce radar, j'ai utilisé cinq axes : <strong>philosophie monolithique déclarée</strong>, <strong>taille de l'équipe de maintenance</strong>, <strong>modularité interne sans réseau</strong>, <strong>échelle d'adoption</strong> et <strong>dépendance de la gouvernance de la fondation</strong>. J'ai comparé Linux (noyau), PostgreSQL, Kubernetes et Proxmox — les quatre points de référence les plus cités dans la littérature technique que j'ai examinée, dans le paysage plus large de 20+ projets (y compris MySQL, MariaDB, Caddy, SigNoz, Gogs, Nginx, Envoy, Terraform, Ansible, Jenkins, Prometheus, Grafana, Elasticsearch, Redis, Kafka, Django, WordPress, GitLab, Nextcloud et Home Assistant, entre autres) qui sont documentés dans la méthodologie.

Radar 3 — Les gouvernements : quatre philosophies, un même problème d'échelle

Radar 3 — Les gouvernements : quatre philosophies, un même problème d'échelle

Notes éditoriales de 0 à 10 dérivées des déclarations citées sur chaque bloc de gouvernement, et non une enquête formelle.

Maturité de l'infrastructure cloudModularité/interopérabilité déclaréeÉchelle de transactions prouvéeSouveraineté sur les fournisseurs privésMaturité des systèmes internes

• États-Unis
• Union européenne
• Chine
• Inde

Ver los datos

Radar 3 — Les gouvernements : quatre philosophies, un même problème d'échelle

Eje	États-Unis	Union européenne	Chine	Inde
Maturité de l'infrastructure cloud	5	7	8	7
Modularité/interopérabilité déclarée	3	10	4	8
Échelle de transactions prouvée	6	5	7	10
Souveraineté sur les fournisseurs privés	4	8	10	6
Maturité des systèmes internes	3	6	7	8

C'est ici que la question originale devient plus intéressante, car les gouvernements ne concourent pas pour la vitesse du marché : ils concourent pour la souveraineté, l'interopérabilité et pour ne pas s'effondrer sous leur propre échelle.

Les <strong>États-Unis</strong> vivent le pire des deux mondes : selon les chiffres de la Bureau de Rendición de Cuentas du Gouvernement (GAO), le gouvernement fédéral dépense plus de 100 milliards de dollars par an en technologie, et environ 80% de ce montant est destiné à maintenir les systèmes hérités en fonctionnement, et non à construire quelque chose de nouveau (GAO, 2025). C'est la version étatique, à une échelle démesurée, du même problème que tout CTO rencontre avec son monolithe de dix ans : la dette technique se paie en budget, et non en élégance architecturale.

L'<strong>Union européenne</strong> a pris la position contraire de manière explicite et documentée : GovStack — l'initiative fondée par l'ITU, l'Estonie, l'Allemagne et DIAL, avec un financement du Global Gateway de l'UE — a une session de formation officielle littéralement intitulée <em>"Éviter le Monolithe : Intégrer des Microservices pour une Transformation Numérique sans Frottements"</em> (ITU Academy / GovStack, 2025). Sa spécification technique définit des "building blocks" (identité numérique, échange de données, orchestration de flux) comme des modules interoperables qui peuvent être composés de microservices de domaine (GovStack Specification, s.f.). C'est, dans le vocabulaire de cet article, un pari institutionnel explicite pour le côté microservices du débat, avec l'argument de souveraineté numérique européenne (EuroStack) qui pousse dans la même direction (Bertelsmann Stiftung, 2026).

L'<strong>Inde</strong> a construit, sans utiliser le mot "microservices" dans son discours public, l'exemple d'architecture par couches le plus grand du monde : India Stack. Aadhaar (identité biométrique, 1,4 milliard de personnes inscrites), UPI (paiements instantanés, 22,35 milliards de transactions en un seul mois d'avril 2026 — plus que ce que Visa traite à l'échelle mondiale en un jour —) et DigiLocker opèrent comme des couches indépendantes connectées par des API ouvertes, et non comme un système monolithique unique de gouvernement (Policy Circle, 2026 ; corroboré de manière indépendante par un comunicado del gobierno de India). La recherche académique sur l'infrastructure publique numérique confirme que ces architectures utilisent explicitement des microservices avec des API standardisées comme modèle technique dominant (arXiv 2503.08725, 2025). C'est le cas de plus grande échelle prouvé au monde pour le côté "microservices" du débat — avec la nuance que la Cour suprême de l'Inde, en 2018, a limité l'utilisation privée d'Aadhaar pour des raisons de confidentialité, ce qui montre que l'architecture modulaire a également été, en partie, une réponse à un problème juridique, et non seulement technique.

La <strong>Chine</strong> mise sur une infrastructure de "nuage gouvernemental" (政务云) centralisée avec une couverture de 100 % dans les administrations au niveau de comté ou supérieur, dans le cadre de la stratégie de "Chine numérique" (National Data Administration / Digital China Wins the Future, 2026). Contrairement au modèle européen de blocs de construction interopérables entre pays souverains, ici la centralisation est explicitement l'objectif stratégique — le marché du gouvernement numérique chinois est projeté à plus de 200 milliards de yuans pour 2026, avec 73 % destinés à l'infrastructure de nuage gouvernemental (IDC, vía Huawei Cloud, 2026). C'est, sur le plan architectural, le pôle opposé au modèle européen, bien qu'il partage avec lui l'utilisation de microservices comme modèle de mise en œuvre technique interne.

Combien du budget technologique est consacré à maintenir ce qui existe déjà

Pourcentage des dépenses technologiques consacrées à maintenir les systèmes/infrastructures existants plutôt que de construire quelque chose de nouveau.

États-Unis — % de 100 000 M+ par an pour maintenir les systèmes hérités

80%

Chine — % de ~200 000 M de yuans prévus pour l'infrastructure cloud gouvernementale

73%

Ver los datos

Combien du budget technologique est consacré à maintenir ce qui existe déjà

Concepto	Valor (%)
États-Unis — % de 100 000 M+ par an pour maintenir les systèmes hérités	80%
Chine — % de ~200 000 M de yuans prévus pour l'infrastructure cloud gouvernementale	73%

Quatre gouvernements, quatre postures architecturales

Résumé de la posture et de la métrique clé citée pour chaque bloc de gouvernement.

Gouvernement	Posture architecturale	Métrique clé citée
États-Unis	Fragmenté / hérité	~80% de 100 000 M+ par an pour maintenir les systèmes hérités
Union européenne	Microservices / blocs de construction explicites	GovStack + EuroStack, souveraineté numérique
Inde	Architecture en couches (India Stack)	22 350 M de transactions UPI en avril 2026
Chine	Nuage gouvernemental centralisé	100% de couverture dans les comtés+, ~200 000 M de yuans prévus

Ver los datos

Quatre gouvernements, quatre postures architecturales

Gouvernement	Posture architecturale	Métrique clé citée
États-Unis	Fragmenté / hérité	~80% de 100 000 M+ par an pour maintenir les systèmes hérités
Union européenne	Microservices / blocs de construction explicites	GovStack + EuroStack, souveraineté numérique
Inde	Architecture en couches (India Stack)	22 350 M de transactions UPI en avril 2026
Chine	Nuage gouvernemental centralisé	100% de couverture dans les comtés+, ~200 000 M de yuans prévus

Le Japon et la Corée du Sud n'ont pas, dans la littérature que j'ai examinée, une position architecturale aussi documentée ou distinctive que ces quatre blocs — les deux suivent en général le modèle de modernisation progressive vers le nuage qui domine le reste des économies développées de l'OCDE, sans un manifeste propre équivalent à celui de GovStack ou India Stack.

Les cinq axes de ce radar : <strong>maturité de l'infrastructure dans le nuage</strong>, <strong>modularité/interopérabilité déclarée</strong>, <strong>échelle de transactions prouvée</strong>, <strong>souveraineté et contrôle étatique sur les fournisseurs privés</strong>, et <strong>complexité et maturité des systèmes internes</strong> (l'axe que vous avez spécifiquement demandé de prioriser). J'ai comparé les États-Unis, l'Union européenne, la Chine et l'Inde avec un poids égal, tel que nous l'avons défini dans la portée.

Ce que disent les universités (et ce qu'elles ne savent pas encore)

J'ai recherché des recherches universitaires récentes dans des universités des États-Unis, de l'Union européenne, de Chine, d'Inde, du Japon et de Corée, et la découverte la plus honnête est celle-ci : l'académie est en retard sur l'industrie, et non en avance. La première revue de littérature systématique formelle sur les monolithes modulaires dans le nuage — publiée en octobre 2025 dans la revue <em>Future Internet</em> — n'a trouvé que 15 études primaires examinées par des pairs entre 2020 et mai 2025, et sa conclusion principale est que même une définition claire du terme n'existe pas (Al-Qora'n & Al-Said Ahmad, 2025). Une deuxième étude de 2026, avec une revue de littérature multivocale de 67 sources entre 2022 et 2026, aboutit à une conclusion similaire sur le manque de bases empiriques solides pour les décisions que l'industrie prend déjà pour des millions de dollars (ResearchGate, 2026).

La revue <em>Tsinghua Science and Technology</em> a publié en 2026 des recherches sur les architectures de microservices pour l'automatisation industrielle avec des exigences de temps réel (Martínez et al., 2026) — un angle technique spécifique (industrie 4.0), et non une position institutionnelle chinoise sur le débat général. Dans la littérature des institutions indiennes, européennes et américaines, le modèle se répète : des dizaines de documents sur <em>comment</em> migrer d'un monolithe à des microservices (identification automatique des frontières avec l'IA, graphes de dépendance, apprentissage automatique), mais très peu de recherches qui répondent à <em>quand</em> il convient de le faire, et presque aucune comparaison rigoureuse et reproductible des coûts réels à l'échelle de l'entreprise. Un document de 2025 sur arXiv intitulé <em>"Microservices Are Dying"</em> propose d'abandonner l'unité de "microservice" en faveur d'interfaces universelles de module — un signe que même au sein de la communauté technique la plus enthousiaste à l'égard de la distribution, le vocabulaire lui-même commence à se sentir insuffisant (arXiv 2511.04548, 2025).

Le tournant que personne n'a vu venir : l'IA qui orchestre l'IA a choisi le monolithe modulaire

Ceci est, pour moi, la découverte la plus intéressante de toute la recherche, et répond directement à la question que je me suis posée au début : l'IA générative pousse-t-elle vers plus de distribution ou vers plus de consolidation ?

En 2025, l'industrie des agents d'IA a eu son propre débat binaire : architectures de maille (plusieurs agents communiquant entre eux sans coordinateur central) contre un seul agent avec des outils. Cognition — l'entreprise derrière Devin — a publié en juin 2025 une position forte : "Ne construisez pas de systèmes multi-agents" (Cognition, 2025, vía FlowHunt, 2026). Pour 2026, ce débat polarisé s'est effondré en un modèle unique que Anthropic, OpenAI et la propre Cognition ont adopté de manière indépendante : un agent orchestrateur qui possède le contexte complet et dépêche des sous-agents éphémères pour des tâches isolées, chacun avec sa propre fenêtre de contexte fraîche, sans canal point à point entre eux et sans état mutable partagé (FlowHunt, 2026).

Relisez cela : <strong>pas de canal point à point entre eux</strong>. Ce n'est pas une architecture de microservices en mesh - c'est, presque à la lettre, la définition d'un monolithe modulaire : un processus central avec une autorité totale, des modules invoqués à la demande, des frontières claires et une communication qui ne sort jamais du contrôle de l'orchestrateur. Anthropic documente elle-même que ses agents de code fonctionnent exactement de cette manière : une boucle d'agent unique avec un catalogue étendu d'outils, et non une mesh de services indépendants (Anthropic Engineering). OpenAI a emprunté le même chemin depuis Swarm (abandonné) jusqu'à son SDK actuel de <em>handoffs</em> explicites, sans coordonnateur de mesh.

En décembre 2025, le protocole Agent2Agent (A2A) a rejoint MCP sous une nouvelle fondation du Linux Foundation consacrée à l'IA et aux agents (AAIF) (Linux Foundation, dic. 2025) - l'infrastructure de coordination est en train de devenir un standard, mais le modèle qui est standardisé est hiérarchique, et non une mesh plane. Si la question est "L'IA pousse-t-elle vers le monolithe ou vers les microservices ?", la réponse que donne le comportement réel de ceux qui construisent l'IA - et non leur discours marketing - est : vers une forme de monolithe modulaire avec des sous-agents jetables, et non vers une mesh distribuée de microservices autonomes.

Comment nous sommes arrivés au monolithe modulaire avec des sous-agents

Chronologie des jalons cités dans cette étude sur l'architecture des agents d'IA.

1. 1992Tanenbaum dit à Torvalds qu'un noyau monolithique est un pas en arrière — Torvalds répond que les micro-noyaux ne déplacent que le problème vers la communication.
2. 2023Amazon Prime Video consolide son service de surveillance en un monolithe et réduit les coûts d'infrastructure de 90%.
3. 2025Cognition (Devin) publie « Ne construisez pas de systèmes multi-agents ».
4. 2025La AAIF est fondée sous Linux Foundation, avec MCP et Agent2Agent comme projets phares.
5. 2026CNCF et SlashData rapportent que 46% des développeurs backend utilisent des microservices, au milieu du débat sur la consolidation.

Ver los datos

Comment nous sommes arrivés au monolithe modulaire avec des sous-agents

Año	Hecho
1992	Tanenbaum dit à Torvalds qu'un noyau monolithique est un pas en arrière — Torvalds répond que les micro-noyaux ne déplacent que le problème vers la communication.
2023	Amazon Prime Video consolide son service de surveillance en un monolithe et réduit les coûts d'infrastructure de 90%.
2025	Cognition (Devin) publie « Ne construisez pas de systèmes multi-agents ».
2025	La AAIF est fondée sous Linux Foundation, avec MCP et Agent2Agent comme projets phares.
2026	CNCF et SlashData rapportent que 46% des développeurs backend utilisent des microservices, au milieu du débat sur la consolidation.

Si vous allez lancer un projet en 2026, voici ce que je ferais

Il n'y a pas de réponse universelle, mais il y a un modèle cohérent dans chaque source sérieuse que j'ai examinée, depuis le cas d'Amazon Prime Video jusqu'à la <em>revue systématique de la littérature</em> académique :

1. <strong>Commencez avec un monolithe modulaire, et non avec un monolithe plat ou des microservices.</strong> Définissez des frontières de domaine claires (Domain-Driven Design) dès le premier commit, même si tout fonctionne dans un seul processus. Extraire un module bien délimité vers un service indépendant après coup est peu coûteux ; défaire une mesh de microservices mal délimitée est extrêmement coûteux.

2. <strong>Extraiez un service uniquement lorsque vous avez des preuves réelles</strong>, et non de l'intuition : besoin de mise à l'échelle vraiment indépendante, exigences réglementaires d'isolement physique (comme PCI pour les paiements), ou un stack technologique réellement incompatible (Python pour le ML, Go pour le core).

3. <strong>La taille de l'équipe compte plus que la taille du produit.</strong> Le seuil qui se répète dans la littérature de 2025-2026 - des équipes de 50 ingénieurs ou plus avec des frontières organisationnelles claires - est le point où les microservices commencent à justifier leur coût de coordination (Loi de Conway appliquée dans le sens inverse).

4. <strong>Si vous allez intégrer des agents d'IA dans votre architecture</strong>, le modèle que Anthropic et OpenAI ont validé en production - un orchestrateur central avec des sous-agents éphémères et isolés - est aujourd'hui l'option avec la plus grande preuve réelle derrière, et non la mesh d'agents peer-to-peer qui était discutée en 2024.

Le feu de circulation final de cette étude

Distribution de confiance des 39 citations ponctuelles du corps du texte.

39 citations

• Vert — primaire ou corrobora — 56%
• Jaune — une seule source secondaire — 41%
• Rouge — non vérifiable, visible par transparence — 3%

Ver los datos

Le feu de circulation final de cette étude

Segmento	Valor
Vert — primaire ou corrobora	22
Jaune — une seule source secondaire	16
Rouge — non vérifiable, visible par transparence	1

La réponse change-t-elle si la décision n'est plus prise par un humain ?

Voici ma vraie question, celle qui m'a mené à cette enquête complète : dans deux ou trois ans, lorsque un agent d'IA proposera l'architecture initiale de votre prochain projet - et il le fait déjà, avec des outils qui suggèrent des structures de dossiers et des frontières de module - suivra-t-il toujours la recommandation "commencez simple, distribuez uniquement avec des preuves" ? Ou la facilité avec laquelle l'IA génère et maintient du code distribué (plus de services, plus de YAML, plus de configuration) va-t-elle incliner la balance vers la complexité, simplement parce qu'il ne s'agit plus d'un humain fatigué qui doit la maintenir ?

Qu'avez-vous vu : vos copilotes de code vous poussent-ils vers plus de simplicité ou vers plus de pièces mobiles ?

Esteban Rey
X: @Kilowatto
LinkedIn: https://www.linkedin.com/in/kilowatto
Wikidata: https://www.wikidata.org/wiki/Q140672978