Microservices en early-stage : l’architecture qui vous fait croire que vous scalez alors que vous ralentissez
Une équipe de quatre développeurs, un produit qui n’a pas encore trouvé son marché, et déjà sept services déployés séparément, chacun avec sa base de données, son pipeline CI, son dashboard de monitoring. La réunion technique du lundi parle de latence réseau entre services et de contrats d’API internes. Personne, ce lundi-là, ne parle du client.
C’est un pattern que je vois revenir chez les startups qui ont recruté des ingénieurs venus de grandes structures, ou qui ont pris trop au sérieux les articles d’ingénierie de Netflix et d’Uber. L’intention est bonne : « on construit pour scaler ». Le résultat est presque toujours le même : on scale la complexité opérationnelle bien avant de scaler les revenus.
Ce que la plupart des startups confondent
Les microservices résolvent un problème d’organisation avant d’être un problème de technique. Ils existent pour permettre à des dizaines, voire des centaines d’ingénieurs de travailler en parallèle sans se marcher dessus, en découpant le système selon les frontières des équipes. C’est la loi de Conway retournée à votre avantage : l’architecture reflète l’organisation.
Sauf qu’une startup pre-seed ou seed n’a pas d’équipes multiples. Elle a une poignée de développeurs qui, idéalement, connaissent l’ensemble du produit. Adopter une architecture conçue pour découpler des équipes qui n’existent pas revient à payer un coût — coût réel, en heures et en runway — pour résoudre un problème que vous n’avez pas encore.
Et ce coût est massivement sous-estimé. Un monolithe qui plante, vous le déboguez en lisant une stack trace. Un système distribué qui plante, vous le déboguez en corrélant des logs entre cinq services, en soupçonnant un timeout réseau, en vous demandant si c’est un problème de cohérence de données entre deux bases. La transaction qui était une simple ligne de code SQL devient une saga distribuée avec compensation en cas d’échec. Vous n’avez pas gagné en scalabilité : vous avez transformé chaque bug en enquête.
Le vrai coût se mesure en vélocité, pas en serveurs
Le piège, c’est que le surcoût des microservices ne se voit pas sur la facture cloud du premier mois. Il se voit sur la courbe de vélocité, six mois plus tard, quand chaque nouvelle fonctionnalité demande de toucher trois services, de synchroniser trois déploiements, de gérer la rétrocompatibilité des API internes.
Prenez un exemple concret. Vous voulez ajouter un champ « secteur d’activité » sur le profil client, visible à la fois dans le tableau de bord et dans le module de facturation. Dans un monolithe, c’est une migration de schéma et deux templates modifiés — une demi-journée. Dans une architecture découpée, il faut modifier le service « comptes », publier un événement, faire consommer cet événement par le service « facturation », gérer le cas où l’événement arrive avant que le client existe côté facturation, versionner le contrat. Vous venez de transformer une demi-journée en une semaine, pour une fonctionnalité qui, à ce stade, sert surtout à valider une hypothèse produit que vous jetterez peut-être dans trois semaines.
Or, en early-stage, la vélocité d’apprentissage est l’avantage compétitif. Vous n’êtes pas en concurrence sur la robustesse de votre infrastructure. Vous êtes en course contre votre runway pour trouver ce qui marche avant d’être à court de cash. Toute architecture qui ralentit votre boucle « idée → déploiement → mesure » vous coûte l’unique ressource que vous ne pouvez pas racheter : le temps d’apprentissage.
Le monolithe modulaire : le vrai choix par défaut
La bonne nouvelle, c’est que le débat « monolithe contre microservices » est largement un faux débat. Ce que vous voulez, ce n’est pas un monolithe spaghetti où tout dépend de tout — c’est un monolithe modulaire : un seul déployable, une seule base de données, mais un code organisé en modules aux frontières claires, avec des interfaces explicites entre eux.
Concrètement, cela veut dire que votre module « paiement » n’accède pas directement aux tables du module « utilisateur » : il passe par une interface. Vous gardez la discipline des frontières logiques sans payer le prix de la distribution physique. Vous déployez tout d’un coup, vous déboguez en local, vous gardez vos transactions transactionnelles — et le jour où un module doit vraiment être extrait (parce qu’il a des besoins de scaling ou de fiabilité spécifiques, ou parce qu’une équipe dédiée se forme autour), les frontières sont déjà tracées. L’extraction devient un chantier planifiable, pas une réécriture.
C’est la stratégie que Shopify, Basecamp ou GitHub ont défendue publiquement : rester monolithique très longtemps, en soignant la modularité interne, plutôt que de se distribuer par principe. Ce sont des entreprises à des ordres de grandeur au-dessus de votre stade actuel.
À quels signaux découper — pour de vrai
Extraire un service devient légitime quand un problème concret l’impose, pas quand un diagramme d’architecture le suggère. Trois signaux méritent qu’on y réponde par un découpage.
Le premier est un besoin de scaling asymétrique. Une partie de votre système consomme des ressources dans un rapport sans commune mesure avec le reste — typiquement un module de traitement d’images, de calcul, ou d’ingestion de données à fort volume. L’extraire permet de le dimensionner indépendamment, au lieu de surdimensionner tout le monolithe pour un seul goulot.
Le deuxième est une frontière organisationnelle réelle. Vous passez de six à vingt ingénieurs, des équipes se spécialisent, et la coordination sur un même codebase devient le frein. Là, découper selon les équipes redevient ce pour quoi les microservices ont été inventés.
Le troisième est une exigence de fiabilité différenciée. Un module doit rester debout quand le reste tombe — par exemple un webhook de paiement qui ne peut pas se permettre d’être indisponible parce qu’une feature secondaire fait planter le monolithe. L’isolation devient alors une décision de résilience justifiée.
En dehors de ces cas, découper relève souvent du confort d’ingénierie ou du mimétisme. Ce sont des raisons humaines compréhensibles, mais ce ne sont pas des raisons business.
Ce qu’il faut vraiment faire selon votre stade
En pre-seed et seed, restez sur un monolithe modulaire, une base de données relationnelle unique, un déploiement simple. Investissez votre énergie d’ingénierie dans la propreté des frontières internes, pas dans l’orchestration. Votre objectif est d’itérer vite pour trouver le product-market fit ; toute complexité qui ne sert pas cet objectif est une dette prise à crédit sur votre runway.
En approche de série A, commencez à identifier les modules candidats à l’extraction — non pas pour les extraire tout de suite, mais pour vérifier que vos frontières internes tiennent. Si vous n’arrivez pas à imaginer extraire proprement un module, c’est le signe que votre modularité interne s’est dégradée : c’est ça qu’il faut réparer, pas la topologie de déploiement.
Et si vous héritez déjà d’une architecture prématurément distribuée — ce qui arrive quand un prestataire ou un premier CTO a « bien fait » sans se poser la question du coût — la bonne réponse est rarement d’ajouter encore des services. C’est souvent de reconsolider : refusionner les services qui n’auraient jamais dû être séparés, pour retrouver de la vélocité. Recoller est moins glorieux que découper, mais c’est parfois la décision la plus courageuse.
Pour conclure
Le choix d’architecture n’est pas une question de pureté technique, c’est une décision d’allocation de ressources. Chaque service que vous déployez séparément est un pari : celui que le coût opérationnel qu’il ajoute aujourd’hui sera compensé par la scalabilité qu’il apportera demain. En early-stage, ce pari est presque toujours perdant, parce que le « demain » qui le justifierait n’est pas encore garanti — vous cherchez encore à savoir s’il existera.
La vraie sophistication, à votre stade, ce n’est pas de construire comme une scale-up. C’est de construire juste assez pour apprendre vite, en gardant la porte ouverte pour découper le jour où un problème réel vous y obligera.
La question à vous poser n’est donc pas « comment scaler notre architecture ? » mais « qu’est-ce qui nous ralentit réellement aujourd’hui, et est-ce un problème d’échelle ou d’apprentissage ? » Les deux ne se résolvent pas avec la même architecture.