Pourquoi l’IA renforce l’intérêt des monolithes modulaires

L’IA peut faciliter le maintien d’une application en croissance dans un ensemble unifié, ce qui modifie une décision d’architecture que de nombreux développeurs ont appris à prendre presque automatiquement. Si vous avez appris à coder avec l’IA au cours des deux dernières années, votre application est peut-être passée d’une structure initiale générée par l’IA à une application Next.js conséquente adossée à Postgres avant même que vous n’ayez réfléchi consciemment à son architecture. Lorsque cette application devient lente, fragile ou difficile à faire évoluer, Kubernetes n’est pas automatiquement l’étape suivante. En 2026, les arguments en faveur d’un logiciel plus unifié se sont renforcés.

Cet argumentaire renforcé a une limite claire, car l’IA a davantage modifié certains coûts logiciels que d’autres. Les microservices sont devenus attractifs en partie parce que les grandes bases de code et les déploiements coordonnés imposaient de lourdes contraintes cognitives et organisationnelles aux humains. L’IA réduit une partie de ces contraintes en naviguant dans le code, en effectuant des modifications mécaniques et en aidant à créer des tests. Les contraintes physiques et de processus continuent toutefois de rendre utiles la mise à l’échelle indépendante et l’isolation des pannes ; les services restent donc pertinents lorsque ces exigences existent.

L’IA modifie la décision d’architecture par défaut

Pour un développeur assisté par l’IA, le changement important concerne le moment où la distribution justifie son coût. Une application enchevêtrée peut souvent être améliorée à l’intérieur de sa frontière de déploiement existante avant d’être divisée en systèmes exploités séparément. L’IA peut rendre cette base de code unifiée plus facile à comprendre et à modifier, prolongeant la durée de vie utile d’une architecture qui devenait auparavant inconfortable plus tôt pour les développeurs et les équipes humaines.

Cet allongement de la durée de vie utile modifie le choix par défaut tout en préservant des raisons claires de scinder un système. Un composant ayant de véritables exigences de mise à l’échelle différentes peut avoir sa place dans son propre service, tandis qu’un composant dont la défaillance doit être isolée du reste de l’application peut justifier un processus distinct. Ces exceptions dépendent de propriétés d’exécution que l’IA ne peut pas supprimer. Leur importance apparaît plus clairement une fois que l’argumentaire technique et organisationnel initial en faveur des microservices est dissocié des contraintes humaines qui l’accompagnaient.

Pourquoi les microservices sont devenus la réponse à la croissance des logiciels

Cet argumentaire initial commence par la frontière de déploiement d’un monolithe : une application avec une base de code, un build et un déploiement. Les comptes utilisateurs, la facturation, la logique produit et l’administration peuvent tous s’exécuter dans le même processus, en communiquant par de simples appels de fonction. Cette organisation maintient les interactions à l’intérieur de l’application et donne généralement aux développeurs un seul système à construire et à exploiter. À mesure que l’application grandit, cependant, chaque partie reste dans la même frontière de déploiement.

Les microservices modifient cette frontière en séparant les fonctions en services isolés et déployables indépendamment. Un service de facturation et un service utilisateur peuvent s’exécuter séparément et communiquer sur un réseau via des API ou des files de messages. Chaque service peut avoir sa propre base de données et son propre langage de programmation, et une équipe distincte peut en être responsable. Cette séparation crée une indépendance technique et organisationnelle, mais la communication réseau et la multiplicité des systèmes en fonctionnement deviennent alors partie intégrante de l’architecture de l’application.

Ce compromis a gagné en influence à travers des exemples comme Netflix. À mesure que sa plateforme et son organisation d’ingénierie se développaient, son monolithe est devenu un goulot d’étranglement : même une petite modification pouvait impliquer de reconstruire, retester et redéployer l’ensemble de la plateforme. Netflix a commencé à scinder le système autour de 2009, et sa migration est devenue un modèle suivi par de nombreuses autres entreprises. Entre 2015 et 2020 environ, les microservices étaient devenus une recommandation courante pour les logiciels appelés à croître.

Le modèle Netflix soutenait aussi un argument organisationnel, car les grandes équipes d’ingénierie doivent apporter des changements en parallèle. Diviser un système en services attribués peut permettre, par exemple, à trente équipes de travailler en même temps avec moins d’interférences entre leurs mises en production et leurs choix technologiques. Ce cas illustratif de trente équipes révèle une hypothèse sous-jacente à une grande partie des recommandations conventionnelles : une entreprise doit avoir suffisamment de travail indépendant simultané pour que l’autonomie au niveau des services compense le coût d’exploitation supplémentaire.

Cette hypothèse s’applique de manière inégale, car les petites équipes peuvent hériter d’une machinerie conçue pour coordonner de nombreux groupes indépendants sans en retirer le même bénéfice. Les objections traditionnelles aux monolithes restent pertinentes, mais elles découlent de causes différentes. L’IA modifie bien davantage les objections enracinées dans l’effort humain que celles liées au comportement à l’exécution.

L’IA affaiblit certaines objections aux monolithes bien plus que d’autres

La première objection, « Vitesse de développement plus lente. », découle d’une propriété évidente d’un monolithe en croissance : plus il y a de code, plus il y a de relations qu’un développeur doit comprendre, de sorte que les changements peuvent devenir plus lents et plus risqués. À un extrême illustratif d’un million de lignes, aucun humain ne peut garder l’ensemble de l’application en mémoire de travail. Séparer l’application peut limiter la quantité de code qu’une équipe individuelle doit comprendre à un instant donné.

C’est sur cette limite cognitive que l’IA modifie substantiellement le problème. Un agent d’IA ne ressent pas la fatigue humaine liée à la lecture d’un grand dépôt et peut naviguer dans une vaste base de code tout en rédigeant ou en examinant des modifications. Le code sous-jacent peut toujours être compliqué, et une mauvaise structure interne crée toujours des dépendances qu’il faut comprendre. La taille du dépôt, à elle seule, devient une raison moins forte d’introduire des frontières réseau et de déploiement lorsqu’un assistant IA peut inspecter le code pertinent à travers toute l’application.

La deuxième objection, « Verrouillage technologique » et « manque de flexibilité. », dépend elle aussi en partie de la quantité de travail que les humains doivent fournir. Dans un monolithe, un framework et un langage partagés peuvent rendre une mise à niveau globale coûteuse, et un sous-système ne peut pas simplement adopter un autre langage comme le pourrait un service indépendant. Historiquement, les équipes évitaient certaines migrations parce qu’appliquer un grand volume de changements mécaniques à une seule base de code consommait trop de temps d’ingénierie.

Cette charge de migration diminue lorsque l’IA peut effectuer une grande partie de la transformation mécanique avant que les humains n’examinent le résultat. Une décision de framework ou de langage continue d’affecter largement une application unifiée, de sorte que la contrainte architecturale demeure. Mais le coût pour sortir d’un choix technique vieillissant a changé : des migrations qui exigeaient autrefois de longues modifications humaines répétitives peuvent transférer une plus grande part de ce travail à l’IA, les ingénieurs se concentrant sur la revue et sur les parties qui exigent du jugement.

La troisième objection, « Fiabilité. », se comporte différemment parce qu’elle dépend de l’isolation des processus. Si le module de paiement d’un monolithe déclenche une exception non gérée qui fait planter son processus, le reste de l’application tombe avec lui. Un meilleur code généré par l’IA peut réduire la probabilité de certains défauts, mais deux modules exécutés dans un même processus partagent toujours un domaine de défaillance. Les exigences de fiabilité peuvent donc fournir une raison technique concrète de scinder un système.

La quatrième objection, « Scalabilité. », atteint une limite physique similaire. Un processus monolithique ne peut pas ajouter indépendamment de la capacité à un composant interne, de sorte qu’une charge de travail intensive peut obliger l’entreprise à exécuter davantage de copies de l’application entière. Un encodeur vidéo en est un exemple clair : si la demande d’encodage augmente indépendamment du reste du produit, faire évoluer cette charge comme un service distinct peut éviter de faire évoluer en même temps des fonctions applicatives sans rapport.

L’importance de cette limite dépend du fait qu’une application l’atteigne réellement ou non. La plupart des applications n’atteignent jamais le point où la mise à l’échelle de composants individuels devient préférable à l’exécution de copies supplémentaires du monolithe. Les problèmes de scalabilité au niveau de Netflix restent de véritables problèmes d’ingénierie pour Netflix, mais les applications ayant d’autres contraintes doivent prendre leur décision à partir de leur propre charge de travail. La mise à l’échelle indépendante mérite sa complexité lorsqu’une charge de travail lui donne une justification concrète.

La cinquième objection, « Déploiement. », se situe entre ces contraintes humaines et physiques. Un « correctif d’une ligne » dans un monolithe exige toujours de déployer l’application entière, et historiquement ce couplage pouvait décourager les mises en production fréquentes. Des déploiements moins fréquents pouvaient alors devenir des déploiements plus volumineux, augmentant la quantité de changements exposés d’un coup et élevant le risque de déploiement.

Les outils modernes réduisent une partie de cette charge, car les pipelines CI et les suites de tests générées par l’IA peuvent accélérer la construction et la validation d’une application complète. Une comparaison illustrative situe un déploiement monolithique à « 2 heures » il y a dix ans et à « quelques minutes » aujourd’hui. Cette comparaison illustre l’effet d’outils plus rapides : déployer l’application entière peut demander moins de temps et moins d’effort manuel. Les modules partagent toutefois toujours un seul cycle de mise en production.

Ces cinq objections se répartissent selon ce qui crée leur coût. L’IA a l’effet le plus important là où les développeurs doivent absorber de grandes quantités de code, effectuer un travail de migration mécanique ou gérer certaines parties des tests et de la coordination des déploiements. Les propriétés d’exécution demeurent : les processus partagent des domaines de défaillance, les ressources de calcul doivent être allouées quelque part, et un artefact déployable reste un artefact déployable. Les décisions d’architecture en 2026 doivent distinguer ces catégories, car chacune réagit différemment à l’assistance de l’IA.

Les microservices peuvent transformer la complexité du code en complexité opérationnelle

Une fois qu’une équipe franchit cette frontière de déploiement, un code qui était local devient un problème de système distribué. Un appel de fonction à l’intérieur d’un monolithe devient une interaction réseau entre services, où l’un ou l’autre côté, ou la connexion entre eux, peut échouer. Suivre une requête peut alors nécessiter du distributed tracing, qui enregistre son parcours à travers plusieurs services, au lieu de suivre une stack trace classique dans un seul processus. Un défaut qui produisait auparavant une stack trace peut devenir « un après-midi à corréler des logs sur cinq tableaux de bord ».

Ces défaillances réseau créent des états supplémentaires que le code applicatif et les opérations doivent gérer. Une requête peut réussir partiellement lorsqu’un service termine son travail et qu’un autre échoue, ce qui crée un besoin de comportements de retry et d’une gestion rigoureuse des opérations en double. Les données peuvent devenir en cohérence éventuelle, ce qui signifie que des parties distinctes du système atteignent le même état après un délai plutôt qu’au moyen d’une transaction immédiate unique. Les services peuvent aussi développer un décalage de version lorsque différentes versions s’exécutent ou interagissent en même temps, ajoutant des préoccupations de compatibilité aux changements applicatifs ordinaires.

Ces états supplémentaires entraînent des coûts d’infrastructure en plus du travail d’ingénierie, car chaque service indépendant doit être déployé, observé, interconnecté et géré selon son rôle dans le système global. Pour une organisation qui a besoin d’une responsabilité et de mises en production indépendantes, ces coûts peuvent acheter une autonomie utile. Une équipe qui n’a pas cette exigence peut au contraire se retrouver à exploiter une infrastructure distribuée parce que sa base de code est devenue difficile à parcourir.

Ce décalage atteint sa pire forme dans un monolithe distribué : plusieurs artefacts déployables qui restent si étroitement couplés qu’ils doivent évoluer ensemble. Un système illustratif avec cinquante artefacts déployables gagne peu en indépendance si un changement produit significatif exige toujours des mises en production coordonnées entre eux. L’organisation paie alors les appels réseau, le débogage distribué et les déploiements séparés tout en conservant la pression de coordination d’une application unifiée. Les frontières de service n’apportent leur bénéfice central que lorsqu’elles créent une indépendance significative.

Le coût de frontières inutiles a conduit certaines organisations à consolider des charges de travail spécifiques. En 2023, l’équipe Prime Video d’Amazon a publié une étude de cas dans laquelle elle a déplacé une charge de travail particulière des microservices vers un monolithe et a indiqué avoir réduit les coûts d’infrastructure d’environ 90 %. Le résultat montre que la consolidation peut produire un gain économique important sur une charge de travail réelle en production. Sa portée se limite à cette charge de travail particulière ; il n’établit pas de règle générale pour Amazon ni pour d’autres systèmes de production.

Des éléments plus larges montrent que les équipes réexaminent aussi certaines frontières plutôt que de considérer chaque service existant comme permanent. Une enquête CNCF de 2025 a indiqué que 42 % des organisations ayant initialement adopté les microservices avaient consolidé au moins certains services en unités déployables plus larges. Comme ce chiffre décrit une consolidation partielle, il ne signifie pas que 42 % ont rejeté les microservices comme architecture. Il montre que les équipes sont prêtes à revoir les frontières de service lorsque l’indépendance qu’elles procurent ne compense plus leur coût opérationnel.

Le meilleur choix par défaut est un monolithe modulaire

Reconsidérer une frontière de service exige toujours une structure interne, car la consolidation doit préserver des responsabilités claires. Un monolithe modulaire conserve un seul processus et un seul déploiement tout en divisant l’application en interne en modules dotés d’interfaces fortes. La facturation et les utilisateurs peuvent, par exemple, rester des modules distincts, avec des interfaces publiques explicites par lesquelles ils interagissent. Le code de facturation ne devrait pas aller puiser librement dans les tables de base de données du module utilisateur simplement parce que les deux modules vivent dans la même application.

Cette structure interne commence par un dépôt, un processus de déploiement et une base de données uniques. Cette organisation donne à un assistant IA une large visibilité sur l’ensemble de l’application, l’aidant à retracer les dépendances et à comprendre comment un changement demandé interagit avec le code environnant. Pour une application qui n’a pas d’exigence de mise à l’échelle indépendante ou d’isolation, cette même organisation évite de créer du travail de système distribué avant qu’il n’existe une raison technique de l’assumer.

À l’intérieur de ce déploiement unifié, la deuxième étape consiste à imposer des frontières modulaires avant d’ajouter des frontières réseau. La facturation et les utilisateurs peuvent chacun exposer une interface publique claire, en gardant derrière elle le code interne et l’accès aux données. Un assistant IA peut aider à vérifier ces règles lors de la revue de code en signalant les changements qui franchissent de manière inappropriée une frontière de module. Des interfaces internes claires préservent une grande partie de la discipline de frontière associée aux microservices, tout en maintenant les interactions sous forme d’appels ordinaires dans le processus.

Ces frontières internes préservent aussi la possibilité d’extraire un module plus tard. Si un module finit par développer une exigence d’exploitation indépendante, son interface établie peut devenir le point de départ d’un contrat de service. L’extraction est nettement plus claire lorsque les appelants dépendent déjà d’une frontière définie que lorsqu’ils accèdent directement aux éléments internes d’un autre module. La modularité prépare donc à une future scission sans en imposer à l’avance le coût d’exploitation.

Une fois cette préparation en place, la troisième étape consiste à extraire un service lorsque l’équipe peut nommer l’exigence qui l’impose. Le traitement vidéo est l’exemple récurrent, car ses besoins de calcul peuvent différer assez fortement du travail applicatif ordinaire pour justifier une mise à l’échelle et une isolation indépendantes. Une fois cette exigence présente, le coût opérationnel d’un service supplémentaire achète une propriété spécifique que le monolithe ne peut pas fournir. Jusque-là, garder le composant à l’intérieur de l’application modulaire évite un comportement réseau dont le produit n’a pas besoin.

La quatrième étape consiste à conserver les concepts de conception développés autour des microservices même lorsque le déploiement reste unifié. Les bounded contexts définissent des zones d’un système avec des responsabilités métier claires ; les contrats d’API rendent explicites les interactions autorisées entre ces zones ; l’isolation des défaillances oblige les ingénieurs à réfléchir à la manière dont les problèmes d’un composant affectent un autre. Ces concepts améliorent la structure d’un monolithe parce qu’ils établissent des frontières et des responsabilités avant qu’une équipe ne choisisse une technologie de déploiement.

Cette discipline des frontières est une contribution durable de la période des microservices. Les équipes d’ingénierie ont appris à définir soigneusement les responsabilités, à attribuer la propriété et à rendre les interactions explicites. Un réseau peut imposer ces décisions entre processus, tandis qu’une application bien conçue peut les imposer en interne jusqu’à ce que la séparation apporte un bénéfice opérationnel concret.

Sachez ce qui doit encore vous conduire à scinder le système

Les limites d’un monolithe modulaire découlent des contraintes d’exécution que l’IA laisse intactes. L’isolation des processus reste précieuse lorsqu’un sous-système doit être empêché de faire tomber un autre, et la mise à l’échelle spécifique à un composant reste précieuse lorsqu’une charge de travail nécessite une capacité sensiblement différente. Le déploiement de l’application entière reste aussi une véritable contrainte, même lorsque la CI et les tests assistés par l’IA rendent ce déploiement moins coûteux et plus rapide.

Ces limites font de « quels problèmes exigent une séparation réseau/processus ? » la bonne question d’architecture. Une exigence technique concrète peut y répondre : mise à l’échelle indépendante, isolation des pannes ou autre besoin dépendant d’une exécution et d’un déploiement séparés. Une véritable exigence organisationnelle peut aussi y répondre lorsque les équipes ont besoin d’une indépendance au niveau des services afin de pouvoir posséder et mettre en production séparément des parties d’un système suffisamment vaste.

Comme ces exigences varient selon l’organisation et la charge de travail, aucun seuil utile de taille d’équipe ne peut s’y substituer. Les petites et moyennes équipes peuvent sinon adopter des pratiques opérationnelles développées pour des organisations suffisamment grandes pour bénéficier de nombreux services indépendants, alors que la plupart des applications n’atteignent jamais l’échelle où la mise à l’échelle au niveau des composants devient décisive. La structure des équipes, la charge de travail, les besoins de fiabilité et la pression de déploiement déterminent si l’indépendance compense son coût ; c’est donc l’exigence elle-même qui constitue le déclencheur pertinent.

Les microservices restent une réponse valable aux problèmes qui exigent de la distribution. En 2026, l’IA peut prendre en charge une plus grande part de la charge cognitive et mécanique d’une base de code unifiée, tandis qu’une conception modulaire peut fournir des frontières solides avant que des processus séparés ne deviennent nécessaires. La distribution doit commencer lorsqu’une exigence technique ou organisationnelle clairement identifiée rend l’indépendance suffisamment précieuse pour en assumer l’exploitation.

Points clés à retenir pour les décideurs

• Faites des monolithes modulaires le choix par défaut : l’IA facilite la navigation, la modification, le test et la migration de grandes bases de code, prolongeant la durée de vie utile d’une application unifiée. Les responsables de l’architecture peuvent maintenir des frontières de module claires et retarder la distribution jusqu’à ce qu’une exigence spécifique la justifie.
• Distinguez les coûts humains des contraintes d’exécution : l’IA réduit le travail cognitif et mécanique qui renforçait historiquement l’argumentaire en faveur des microservices. Les CTO qui évaluent une scission doivent se concentrer sur des exigences telles que la mise à l’échelle indépendante, l’isolation des pannes et le déploiement autonome que l’IA ne peut pas supprimer.
• Tenez compte des coûts des systèmes distribués : les microservices introduisent des défaillances réseau, des retries, la cohérence éventuelle, le distributed tracing, la compatibilité des versions et une infrastructure supplémentaire. Les organisations d’ingénierie tirent de la valeur de ces coûts lorsque les frontières de service créent une indépendance opérationnelle ou organisationnelle significative.
• Concevez les modules pour une extraction future : des interfaces claires, des responsabilités délimitées et un accès contrôlé aux données préservent la discipline architecturale à l’intérieur d’un monolithe. Les équipes plateforme et applicatives peuvent utiliser ces frontières pour simplifier une extraction ultérieure en service lorsque des exigences d’exécution apparaissent.
• Scindez les services lorsque l’indépendance a une valeur mesurable : les charges de travail ayant des besoins distincts en matière de scalabilité, de fiabilité ou de déploiement restent de solides candidates à des services séparés. Les décisions d’architecture doivent rattacher chaque frontière de service proposée à une exigence technique ou organisationnelle concrète plutôt qu’à la seule anticipation de la croissance.