correction

Author: CodeWithFrenchy

_drafts/2025-09-08-quand-utiliser-architecture-microservices.md

@@ -164,7 +164,7 @@ Pour récapituler avec un petit guide __quand ou ne pas utiliser une architectur
   - __Équipe réduite/inexpérimentée en devops__ : pas d’expertise conteneurs/Cloud, pas d’équipe dédiée à l’infrastructure… Mieux vaut ne pas se compliquer la vie tout de suite. Comme on dit, *"il ne faut pas plusieurs chefs pour faire bouillir la marmite"* – une petite brigade de développeurs fonctionne mieux autour d’un seul chaudron (le monolithe).
   - __Domaines très interconnectés__ : si vos fonctionnalités sont toutes fortement liées, les séparer en services entraînera beaucoup d’appels réseau entre eux (le syndrome du [distributed monolith](https://medium.com/@dmosyan/doing-microservices-completely-wrong-distributed-monoliths-cede5c44d8a7)). Vous n’y gagnerez rien, si ce n’est d’échanger un couplage interne contre un couplage réseau tout aussi contraignant.
   - __Contraintes de performance temps réel strictes__ : une application _low-latency_ (ex : transactions boursières automatisées ultra-rapides, calcul scientifique synchronisé) peut difficilement tolérer la latence ajoutée des microservices. Un monolithe optimisé en C# (ou en Rust natif 😉) sera plus efficace.
-  - __Budget serré__ : si chaque dollar compte, sachez que la complexité microservices peut impliquer plus de dépenses (machines, temps de devéveloppeur, consultants spécialisés…). Assurez-vous que votre responsable budgétaire soit d’accord avant de multiplier les déploiements comme des lapins.
+  - __Budget serré__ : si chaque dollar compte, sachez que la complexité microservices peut impliquer plus de dépenses (machines, temps de développeur, consultants spécialisés…). Assurez-vous que votre responsable budgétaire soit d’accord avant de multiplier les déploiements comme des lapins.
   - En bref, si __les bénéfices ne sont pas clairs et immédiats__, ou si votre contexte n’est pas prêt, il est parfaitement raisonnable de __rester sur un monolithe__ ou d’adopter une approche intermédiaire (par ex. un monolithe modulaire, bien découpé en couches ou en *modules internes* – parfois appelé "modulithe" ou "monolithique modulable"). On peut très bien concevoir son code *comme* des microservices (avec de bonnes séparations logiques), tout en déployant une seule application. C’est souvent un excellent compromis pour démarrer.
 
 En guise de clôture, rappelons-nous que __l’architecture sert les objectifs du logiciel, pas l’inverse__. Ne choisissez pas microservices ou monolithe pour suivre la mode, mais en fonction de ce qui apporte le plus de valeur à *votre* produit et *vos* utilisateurs. La prochaine fois qu’on vous dira *"Il faut absolument des microservices, c’est plus __scalable__ et __hype__"*, vous pourrez rétorquer : *"Peut-être, mais encore faut-il que ce soit justifié – parlons concret ! "*.