Comment une startup en pleine croissance a failli couler six mois après avoir adopté une MSA

J’ai récemment lu un article devenu viral sur un blog tech étranger, "Microservices Killed Our Startup. Monoliths Would’ve Saved Us", et son contenu était à la fois si douloureusement juste et si parlant que j’en partage ici un résumé.

Cela ressemble à une excellente « fiche d’erreurs à ne pas reproduire » sur les dangers d’adopter les dernières technologies de manière dogmatique.

---

1. Le point de départ : « Faisons comme Netflix, nous aussi »

• Contexte : levée seed de 2,5 M$, croissance mensuelle du chiffre d’affaires de 40 %, 50 000 utilisateurs. Une startup qui tournait très bien avec un monolithe Rails.
• Début du problème : un lead architect arrive et propose une transition vers une MSA au nom de la « scalabilité ».
• Logique : « Notre architecture actuelle est trop couplée. Regardez Netflix ou Uber. Si on veut devenir comme eux, il faut passer aux microservices. »
• Réalité : une équipe de 4 développeurs et 1 ingénieur DevOps décide d’adopter une architecture façon Netflix.

2. Six mois d’enfer (chronologie de l’adoption de la MSA)

[Mois 1 : lune de miel]

• La séparation du service de notifications est un succès. « Vous voyez ? Ça marche très bien ! » se félicite l’équipe.
• Mais les premiers signes avant-coureurs apparaissent : temps de déploiement plus longs, multiplication des dépôts, etc.

[Mois 2 à 3 : les premières fissures]

• Le service de facturation (Billing) est séparé. Or il est lié aux services utilisateurs, stock et commandes.
• Résultat : à cause de la latence réseau, le temps de réponse passe de 200 ms à 800 ms. Quand un service tombe, il entraîne des pannes en cascade sur l’ensemble du système.

[Mois 4 à 5 : le cauchemar des transactions distribuées]

• Là où une simple transaction DB suffisait dans le monolithe, l’environnement distribué impose même l’adoption du pattern Saga.
• Le stock diminue mais le paiement échoue, les rollbacks s’emmêlent... et l’incohérence des données déclenche une avalanche de tickets support.
• Ajouter une simple colonne oblige à toucher 6 services : ce qui prenait 2 heures demande désormais 3 jours.

[Mois 6 : l’effondrement de l’équipe]

• Les développeurs consacrent tout leur temps à gérer l’infrastructure au lieu de développer des fonctionnalités.
• Coût d’infrastructure : 3 000 $ → 12 000 $ (multiplié par 4).
• Départ d’un développeur clé (« Je suis venu pour construire un produit, pas pour passer mes journées à bricoler Kubernetes. »)

3. La décision : « Nous ne sommes pas Netflix »

L’architecte continue pourtant d’insister : « adoptons un Service Mesh et ajoutons plus d’outils de monitoring ». Mais l’auteur finit par exploser.

« Nous ne sommes pas Netflix ! Netflix a 500 ingénieurs, nous sommes 4 ! »

Finalement, l’architecte quitte l’entreprise et l’équipe décide de revenir au monolithe (rollback).

4. Retour au monolithe, puis renaissance

• Pendant 8 semaines, l’équipe réintègre le code dans un monolithe.
• Résultats :
• reprise de la vitesse de livraison des fonctionnalités (de 4 à 20 par mois)
• temps de réponse stabilisé à 220 ms
• baisse des coûts d’infrastructure
• et surtout, hausse du bonheur des développeurs

5. Leçons essentielles (la conclusion de l’article)

1. La MSA n’est pas un outil pour résoudre un “problème technique”, mais un “problème organisationnel”.

• On l’utilise quand il y a plus de 50 développeurs qui se marchent dessus, ou quand les cycles de déploiement divergent trop fortement.

2. Netflix/Google ne sont pas vos modèles.

• Eux aussi ont commencé avec un monolithe. Ils ont changé d’architecture à cause de leur échelle, pas dès le départ.

3. La complexité est une taxe.

• À mesure que les services se multiplient, le coût de gestion augmente de façon composée.

4. Les appels réseau ne sont pas gratuits.

• Un appel de fonction en mémoire (nanosecondes) et un appel réseau (millisecondes), ce n’est pas du tout le même ordre de grandeur.

---

Résumé en une phrase :
« Le monolithe n’est pas l’ennemi. Le vrai ennemi, c’est une mauvaise architecture. Pour une équipe de 4 personnes, par pitié, utilisez simplement un monolithe. »

[ahwjdekf]

Voilà. Les fanatiques de la MSA vont maintenant débarquer.

[mhj5730]

S’il s’agit d’un service créé par 4 personnes, il n’y a sans doute aucune raison de le découper en MSA.

[aer0700]

Les appels réseau ne sont pas gratuits : c’est effectivement vrai. Un appel de fonction et un appel d’API sont clairement deux choses différentes.

[moderato]

Pour faire du MSA, il faut aussi que l’organisation soit adaptée au MSA...

[ifmkl]

Je pense que le point 4 dans le résumé exprime sans doute bien l’idée principale. Et, globalement, je trouve que le contenu en lui-même parle assez juste.

[bungker]

« Je suis venu pour créer un produit, pas pour passer mes journées à bidouiller Kubernetes » —> C’est probablement la phrase la plus débile que j’aie jamais entendue.

[hohemian]

Pourquoi ? Ça me semble juste, si on est dans une situation où on fait du k8s avec k8s comme finalité.

[roxie]

J’aime bien les commentaires de bungker, donc je clique dessus un par un, mais sur celui-ci, je n’arrive pas vraiment à être d’accord, hmm. Pourriez-vous donner quelques explications supplémentaires ?

[passerby]

C’est un post sur l’IA sans aucun contenu ; c’est pour ça qu’en ce moment je ne regarde presque plus Medium.

[bsh998]

Euh... il y a quelque chose qui cloche, je trouve.
On dirait que cet article a été écrit par une IA.

[baeba]

Moi aussi, c’est quelque chose que je ressens souvent en ce moment..
Je me dis que beaucoup d’articles de blog sont probablement écrits à partir de l’expérience personnelle de leur auteur + avec l’aide de l’IA.
Les textes sont trop bien structurés et trop faciles à lire.

[bsh998]

Ce que je voulais dire, c’est que ce texte fait très IA et ne cite aucune référence, donc je préférerais qu’il ne soit pas partagé.

[baeba]

C’est un billet publié sur Hacker News. La plupart des articles que je publie viennent de Hacker News.

https://news.ycombinator.com/item?id=46469845

Comme vous l’avez dit... je devrais effectivement ajouter la référence Hacker News.

[baeba]

1) Doutes sur la crédibilité du texte : ça sent le marketing / le contenu généré par IA

En bref

• « C’est trop bien ficelé, presque comme une fable morale » → certains soupçonnent un texte optimisé pour le type de “morality play” que HN adore
• Le corps de l’article est truffé de liens vers des ressources payantes, d’où un fort courant d’opinion : « au fond, ce n’est pas juste un texte commercial ? »
• Le style avec avalanche de listes et emojis est aussi pointé comme un signal d’« AI slop » (contenu IA bâclé)

Citation qui démonte tout (traduite)

« On dirait que tout le texte est là juste pour vendre les ressources mises en lien. Et avec toutes ces listes, ça fait vraiment AI slop. »
(Original : Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Verdict en une ligne

• Avant même de savoir si le fond est juste ou faux, la première réaction a été : ça sent trop fort la vente + l’IA.

---

2) Critique du leadership / des architectes : le problème n’était pas la techno, mais la structure de décision

En bref

• Beaucoup ont réagi par : « un architecte pour une équipe de 4 personnes ? » — pour eux, ça partait déjà de travers
• En particulier, la figure de l’architecte qui ne code pas / du rôle DevOps séparé est souvent vue comme un goulot d’étranglement + une optimisation de CV
• Le ton général n’est pas “les microservices ont tout cassé”, mais plutôt : “c’est une organisation où personne n’assume vraiment le déploiement, l’exploitation ou la gestion de crise qui a coulé la boîte”

Citation qui pique (traduite)

« Des architectes dont le boulot est de définir des “règles” et des “patterns” sans rien implémenter eux-mêmes, c’est presque toujours une très mauvaise idée. Concentrez-vous juste sur la mise en production... Si quelqu’un qui n’écrira même pas 10 lignes de code monopolise les décisions, c’est la catastrophe. »
(Original : Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Verdict en une ligne

• Pour beaucoup, le vrai problème n’était pas le MSA, mais une conception des rôles où il y a du pouvoir de décision sans responsabilité réelle.

---

3) Angle business : est-ce que le MSA a vraiment causé l’échec de la startup ?

En bref

• Certains commentaires ne croient pas du tout au cadrage “l’architecture a tué la startup”
• Leur idée centrale : si le PMF / la demande / la rétention client sont faibles, n’importe quelle stack peut mener dans le mur
• En particulier, des détails comme « les clients partent immédiatement parce que le service est plus lent pendant deux jours ? » servent à sous-entendre que la valeur produit était peut-être faible dès le départ
• Ils pointent aussi une contradiction interne du texte : on te dit “le MSA a tué la startup”, puis la conclusion devient “mais elle a survécu ?” → d’où un soupçon d’exagération narrative

Citation qui démonte tout (traduite)

« Je suis à peu près sûr que ce qui a tué votre startup, c’est d’avoir construit un produit dont personne ne voulait. C’est aussi absurde que de dire que choisir Python plutôt que Go a tué votre startup. »
(Original : Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Verdict en une ligne

• Il y avait clairement ce point de vue : l’architecture peut servir d’excuse, alors que la vraie cause est peut-être le marché, le produit ou la trésorerie.

---

4) Enseignements techniques : conseils utiles issus de l’expérience monolithe vs MSA

En bref

• « Le MSA a une taxe de coûts fixes (complexité opérationnelle) » → beaucoup de retours d’expérience disent que cela peut être fatal pour une petite équipe
• Mots-clés récurrents : premature distribution (distribution trop précoce), monolithe modulaire / modulith, et l’idée de “gagner” ses frontières (boundaries)
• Les conditions dans lesquelles le MSA devient réellement nécessaire sont aussi formulées de manière réaliste : quand la taille de l’équipe augmente et que les conflits, les problèmes de déploiement ou les frictions organisationnelles apparaissent pour de vrai
• À l’inverse, sur les problèmes de performance ou de montée en charge, certains conseillent de regarder d’abord les algorithmes, les goulots d’étranglement, le sharding ou le partitionnement, plutôt que de dire immédiatement “passons aux microservices”

Citation qui pique (traduite)

« Ce ne sont pas les microservices qui ont tué la startup, c’est la distribution trop précoce. Vous avez découpé avant que de vraies frontières n’existent, et vous n’avez récolté que de la latence et des coûts de coordination. Commencez par un monolithe modulaire, gagnez vos frontières, puis extrayez. »
(Original : Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Verdict en une ligne

• La leçon qui a vraiment fait consensus dans la communauté, c’était :
  « Commencez par un monolithe, et ne séparez en services que lorsque les frontières apparaissent naturellement. »

---

Bilan global de la communauté en une phrase

La plupart étaient d’accord avec l’idée “nous ne sommes pas Netflix”, mais en même temps, la suspicion était forte que ce texte lui-même vende une narration de “maladie de Netflix” — autrement dit du marketing / du contenu IA.