{ "id": 36986, "slug": "2020-03-03_architecture-logicielle-monolithique-ou-microservices", "url": "https://agents.willem.com/fr/posts/2020-03-03_architecture-logicielle-monolithique-ou-microservices/", "source_url": "https://willem.com/fr/2020-03-03_architecture-logicielle-monolithique-ou-microservices/", "language": "fr", "date": "2020-03-03", "published": "2020-03-03T00:00:00+01:00", "created": "2025-06-26T22:10:03.931000+02:00", "updated": "2026-10-20T09:24:06.103000+02:00", "title": "Architecture logicielle monolithique ou microservices", "subtitle": "Choisir la bonne conception pour le développement de ton appli", "summary": "Cette semaine, j'ai pris l'avion pour Göteborg afin de rencontrer les gens d'une grande compagnie maritime internationale et de parler du développement de logiciels d'entreprise. Pendant la réunion, plusieurs experts étaient dans la salle, et l'un d'eux m'a demandé comment choisir la bonne architecture logicielle (pour des applis grandes, complexes, de niveau entreprise). Très bonne question, qui mérite largement un article de blog.", "topics": [ "cloud", "data", "design", "programming", "server", "work" ], "author": { "name": "Willem L. Middelkoop", "url": "https://willem.com" }, "provenance": { "kind": "model", "method": "Claude Sonnet, two passes (translation, then proofreading) against a glossary and hunspell", "date": "2026-10-20", "reviewed_by_native_reader": false, "language": "fr", "source_language": "en" }, "translations": [ { "language": "en", "title": "Monolithic vs Microservices software architecture", "url": "https://agents.willem.com/en/posts/2020-03-03_monolithic-vs-microservices-software-architecture/", "source_url": "https://willem.com/en/2020-03-03_monolithic-vs-microservices-software-architecture/" }, { "language": "nl", "title": "Monolithische versus Microservices softwarearchitectuur", "url": "https://agents.willem.com/nl/posts/2020-03-03_monolithische-versus-microservices-softwarearchitectuur/", "source_url": "https://willem.com/nl/2020-03-03_monolithische-versus-microservices-softwarearchitectuur/" }, { "language": "de", "title": "Monolithische vs. Microservices-Softwarearchitektur", "url": "https://agents.willem.com/de/posts/2020-03-03_monolithische-vs-microservices-softwarearchitektur/", "source_url": "https://willem.com/de/2020-03-03_monolithische-vs-microservices-softwarearchitektur/" }, { "language": "es", "title": "Arquitectura de software monolítica vs. microservicios", "url": "https://agents.willem.com/es/posts/2020-03-03_arquitectura-de-software-monolitica-vs-microservicios/", "source_url": "https://willem.com/es/2020-03-03_arquitectura-de-software-monolitica-vs-microservicios/" }, { "language": "it", "title": "Architettura software monolitica contro microservizi", "url": "https://agents.willem.com/it/posts/2020-03-03_architettura-software-monolitica-contro-microservizi/", "source_url": "https://willem.com/it/2020-03-03_architettura-software-monolitica-contro-microservizi/" }, { "language": "pt", "title": "Arquitetura de software monolítica vs microsserviços", "url": "https://agents.willem.com/pt/posts/2020-03-03_arquitetura-de-software-monolitica-vs-microsservicos/", "source_url": "https://willem.com/pt/2020-03-03_arquitetura-de-software-monolitica-vs-microsservicos/" }, { "language": "pap", "title": "Arkitektura di software monolítiko versus microservices", "url": "https://agents.willem.com/pap/posts/2020-03-03_arkitektura-di-software-monolitiko-versus-microservices/", "source_url": "https://willem.com/pap/2020-03-03_arkitektura-di-software-monolitiko-versus-microservices/" }, { "language": "fy", "title": "Monolityske tsjin microservices-softwarearsjitektuer", "url": "https://agents.willem.com/fy/posts/2020-03-03_monolityske-tsjin-microservices-softwarearsjitektuer/", "source_url": "https://willem.com/fy/2020-03-03_monolityske-tsjin-microservices-softwarearsjitektuer/" } ], "image": "https://willem.com/global/images/ac25803922f6.webp", "image_width": 2560, "images": [ { "url": "https://willem.com/global/images/189c28c69d02.webp", "description": "Visite d'une grande compagnie maritime internationale pour parler de logiciels d'entreprise", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36986_images-1.jpg" }, { "url": "https://willem.com/global/images/b73d8bf569bc.webp", "description": "Exemple simple d'architecture logicielle : différentes structures composent un système, avec différentes relations entre elles", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36986_images-2.png" }, { "url": "https://willem.com/global/images/df6c62e25d7d.webp", "description": "La complexité augmente avec le nombre de structures (et de relations entre elles)", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36986_images-3.png" }, { "url": "https://willem.com/global/images/875d62aa72f8.webp", "description": "Architecture logicielle monolithique", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36986_images-4.png" }, { "url": "https://willem.com/global/images/2705ce2c332c.webp", "description": "Architecture logicielle microservices", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36986_images-5.png" }, { "url": "https://willem.com/global/images/e50e134c3fb7.webp", "description": "« Le ciel est la limite » si tu maîtrises l'architecture que tu as choisie (mais ne la change surtout pas en plein vol !)", "manager_file": "148-bf2d6faf6057f115dc72e82d984e71359f16b48d8c42b4b41c2ee918cf46b556_ContentAsPost_36986_images-6.jpg" } ], "text": "L'architecture logicielle\nQuand tu conçois des applis, tu ne dois pas penser seulement à l'apparence et au ressenti : une bonne conception englobe aussi la façon dont tout fonctionne ensemble. L'architecture logicielle désigne les structures fondamentales d'un système logiciel. Chaque structure comprend des éléments, des relations entre eux, et des propriétés des éléments comme des relations.\nC'est comparable à l'architecture d'un bâtiment. Une fois l'architecture définie et mise en œuvre, la modifier coûte cher. C'est donc une bonne idée de choisir la bonne architecture logicielle avant de commencer à construire.\nPour une appli simple, l'architecture peut être évidente, mais quand ton application grandit en taille et en fonctionnalités, le nombre de structures du système peut croître très vite. Ça peut arriver avec le temps, à mesure que les besoins de ton client augmentent. Plus il y a de structures, plus il y a de relations entre elles, et plus ça se complique.\nMaîtriser la complexité d'un logiciel\nSi tu t'attends à ce que ton logiciel gère beaucoup de choses différentes, tu vas probablement devoir affronter la complexité. D'un point de vue architectural, il existe plusieurs approches pour gérer cette complexité logicielle.\nArchitecture monolithique\nL'architecture monolithique se décrit au mieux comme « un gros bloc ». Ici, tout ce que fait ton appli fait partie de la même base de code.\nDans une « architecture monolithique », le logiciel est souvent organisé en couches, chaque couche étant composée de types de composants différents :\n- couche de présentation : responsable de l'interface utilisateur et/ou de l'interface de programmation (UI / API).\n- logique métier : c'est là que se définissent les vraies règles métier. C'est le cœur de l'application, très proche des processus métier réels.\n- couche d'accès aux données : fournit une interface commune entre l'application en cours d'exécution et les stockages persistants du backend.\n- base de données et système de fichiers : c'est là que sont stockées toutes les données et les ressources statiques (fichiers, images, etc.).\nPlus l'application grossit, plus chaque couche grossit. Il devient donc plus difficile de faire évoluer une architecture monolithique : à un certain point, tout devient simplement trop gros et trop complexe.\nÀ chaque modification de l'application, c'est toute la base de code qui est touchée. Pour de (très) grosses applications, il est donc plus difficile de maintenir le logiciel, car il faut comprendre l'application dans son ensemble.\nComme toute l'application est interdépendante, un problème dans une partie touche souvent fortement tout le système. La communication entre les différentes parties du système se fait en interne, au niveau du code. Les différentes parties doivent donc être programmées dans le même langage (ou dans des langages compatibles). C'est un frein pour adopter de nouvelles technologies (à l'avenir), puisqu'on ne peut pas facilement changer le langage de programmation d'une seule partie du système.\nArchitecture microservices\nAu lieu de construire une grosse application monolithique, tu peux découper ton application en services plus petits, reliés entre eux. Chaque microservice est une petite application à part entière, avec sa propre architecture (plus petite et plus simple), sa logique métier et ses couches de données.\nLes différents services communiquent entre eux via des API définies indépendamment de la technologie utilisée, souvent dans une « structure d'API » courante comme REST, JSON, Redis et XML. C'est ce qui permet à la combinaison des microservices de fonctionner comme « un seul système ».\nEn décomposant l'application « gros bloc » en services plus petits, il devient plus facile de comprendre les différentes parties du système. La maintenance est plus simple, car chaque microservice peut être développé indépendamment. Cela abaisse aussi le frein à l'adoption de nouvelles technologies, puisque tu es libre de choisir la technologie la mieux adaptée à chaque service. Une partie du système peut être programmée dans un autre langage que les autres. Des équipes différentes (aux compétences différentes) peuvent ainsi travailler ensemble.\nL'art et le savoir-faire pour réussir une architecture microservices viennent de la capacité à bien définir un microservice. Trop large ou trop fin, et l'architecture est fichue. Tu peux t'appuyer sur les processus métier, sur une séparation hiérarchique ou par domaine pour définir chaque microservice.\nLe défi de l'architecture microservices, c'est qu'elle ajoute de la complexité à l'ensemble du système, puisqu'il faut un mécanisme de communication distribué. Les différentes API qui se connectent entre elles peuvent être délicates à tester et à déboguer. Il devient plus difficile de mettre en œuvre des changements qui touchent plusieurs services.\nDéfinir, concevoir et mettre en œuvre les différentes API entre services demande un accord sur les données échangées. Ce n'est pas simple à obtenir quand tu veux partager des structures de données étendues et non universelles.\nSurveiller et déployer une architecture microservices peut être complexe quand les services se multiplient. Il y a simplement plus de choses à gérer, ce qui demande plus de planification et de coordination pour chaque service.\nChoisir la bonne architecture\nMon défunt père m'a dit un jour qu'on « gagne le plus avec les choses qu'on ne fait pas ». Construire des applications complexes est difficile par nature : le mieux que tu puisses faire, c'est d'essayer de simplifier en ne faisant tout simplement pas tout. Concentre-toi sur ce qui compte vraiment, et fais-le bien.\nSi ton application est simple et légère, une architecture monolithique est la voie à suivre. Le développement, le déploiement, la maintenance : tout est plus facile quand les choses sont petites.\nSi tu ne peux pas échapper à la complexité, tu dois sérieusement envisager l'architecture microservices. Pose-toi les questions suivantes :\n- Es-tu capable de définir un « langage commun » entre tes microservices ?\n- Y a-t-il des processus métier clairement distincts ?\n- Dans quelle mesure ces processus métier sont-ils interdépendants ?\n- Comment penses-tu que ton application va évoluer avec le temps : va-t-elle grandir ou rétrécir ?\n- Combien de technologies de programmation différentes comptes-tu utiliser ? Penses-tu que ça va changer à l'avenir ?\n- Qui va construire et maintenir le logiciel, et a-t-il l'expérience de la gestion d'une telle architecture ?\nConclusion\nIl n'existe pas de réponse « miracle » à la question de savoir quelle architecture logicielle est la bonne. Les deux approches ont leurs avantages et leurs inconvénients.\nLe mieux que tu puisses faire, c'est de prendre une décision consciente, mûrement réfléchie, et de t'y tenir à fond !", "word_count": 1059, "markdown_url": "https://agents.willem.com/fr/posts/2020-03-03_architecture-logicielle-monolithique-ou-microservices/post.md" }