Monolithe, microservices : décoder l'architecture qu'on te vend

Le contexte

Tu as un produit. Peut-être vibe codé, peut-être un premier MVP monté par un freelance. Il marche, il a ses premiers utilisateurs, et tu veux passer à l'étape suivante : le confier à des pros.

Tu demandes des devis. Trois prestataires, trois discours.

Le premier propose de "consolider l'existant et livrer vite". Le deuxième veut "refondre sur une architecture microservices avec Kubernetes pour garantir la scalabilité". Le troisième te parle d'event-driven, de message broker et de multi-cloud.

Et toi, tu n'as aucun moyen de juger. Le deuxième a l'air plus sérieux, il emploie plus de mots impressionnants. C'est peut-être justifié. C'est peut-être aussi le devis le plus cher, le plus lent, et celui qui t'enferme.

Cet article te donne la grille de lecture. Pas pour choisir l'architecture toi-même (c'est le travail de ton prestataire), mais pour comprendre ce qu'on te vend et poser les questions qui font la différence.

Une architecture, c'est un choix d'urbanisme

L'architecture, c'est la façon dont ton app est découpée : en un seul bloc ou en plusieurs morceaux, et comment ces morceaux se parlent. Il n'y a pas des dizaines de familles. Il y en a quatre à connaître, et l'analogie de la maison suffit.

Le monolithe : la maison. Tout sous le même toit. Une seule app, une seule base de données, une seule chose à déployer et à surveiller. C'est simple, rapide à construire, pas cher à faire tourner. La limite : pour agrandir, tu agrandis toute la maison d'un coup. Ce qu'on oublie de te dire : la quasi-totalité des SaaS que tu utilises tous les jours ont commencé comme ça, et beaucoup y sont restés très bien.

Le monolithe modulaire : la maison avec des pièces bien pensées. Toujours une seule maison, mais chaque pièce a un rôle clair, des murs propres, des portes qui ferment. Le jour où il faut pousser un mur, on pousse un mur, on ne rase pas la maison. C'est le bon choix par défaut pour la grande majorité des produits, y compris ambitieux.

Les microservices : le lotissement. Une petite maison par fonction : une pour les paiements, une pour les comptes, une pour les emails. Chacune peut être construite et rénovée par une équipe différente sans déranger les autres. Mais il faut construire les routes entre les maisons, tirer l'eau et l'électricité dans chacune, et quand un courrier se perd entre deux maisons, bonne chance pour retrouver où.

Le serverless : l'hôtel. Tu ne possèdes pas les murs, tu paies à la nuit. Zéro entretien, et si mille clients débarquent d'un coup, l'hôtel absorbe. Parfait pour des besoins ponctuels ou un trafic en dents de scie. Le piège : à trafic constant, la note d'hôtel finit par dépasser largement le prix d'une maison. Et déménager d'un hôtel dont tu as pris toutes les habitudes, c'est un vrai projet.

Retiens surtout ça : aucune de ces options n'est "moderne" ou "dépassée". Ce sont des réponses à des situations différentes.

Ce que les microservices coûtent vraiment

C'est le mot qui revient dans un devis sur deux, donc arrêtons-nous dessus.

Sur le papier, l'argument est vrai : chaque service évolue indépendamment, chaque service peut encaisser plus de charge de son côté. Ce qu'on te dit moins :

• Chaque service se déploie, se surveille et se met à jour séparément. Dix services, c'est dix fois la maintenance de base.
• Des morceaux qui se parlaient en direct se parlent maintenant par le réseau. Le réseau, ça rame parfois, ça tombe parfois. Ton app doit gérer tous ces cas.
• Il faut un chef d'orchestre pour faire tourner tout ça (c'est le rôle de Kubernetes), et quelqu'un qui sait s'en servir. Ce quelqu'un coûte cher.
• Un bug qui traverse trois services se cherche dans trois services. Le debugging devient un travail d'enquête.

La vraie raison d'être des microservices, c'est un problème d'organisation, pas de technique : quand quinze équipes travaillent sur le même produit et se marchent dessus, découper le produit permet à chaque équipe d'avancer sans bloquer les autres. Toi, avec un produit et un ou deux devs, ce problème n'existe pas.

Quelques repères pour fixer les idées. Shopify encaisse le Black Friday sur un monolithe (bien rangé). Stack Overflow a servi une bonne partie d'Internet avec une poignée de serveurs. Et l'équipe de Prime Video chez Amazon a raconté publiquement avoir refusionné des microservices en un seul bloc, pour une facture réduite de 90%. Si eux tiennent avec une maison bien construite, ton SaaS à 200 utilisateurs aussi.

Ça ne veut pas dire que les microservices, c'est mal. Ça veut dire que c'est un outil qui répond à un problème que tu n'as probablement pas encore.

Les 5 signaux d'over-engineering dans un devis

Quand tu relis tes devis, voilà ce qui doit te faire lever un sourcil.

1. Microservices dès le jour un. Pour un produit qui cherche encore ses utilisateurs, c'est construire le lotissement avant de savoir si quelqu'un veut habiter le quartier.
2. Kubernetes pour une seule app. C'est un outil conçu pour orchestrer des dizaines de services. Pour une app, c'est louer un orchestre symphonique pour jouer Au clair de la lune.
3. "Scalable" sans aucun chiffre. Demande : scalable jusqu'à combien d'utilisateurs ? Et on en a combien aujourd'hui ? Si la réponse reste floue, le mot est décoratif.
4. Plusieurs langages ou plusieurs bases de données dès le départ. Chaque techno en plus, c'est un profil en plus à trouver le jour où tu veux changer de prestataire.
5. La réécriture complète comme préalable. "On repart de zéro" est parfois justifié. C'est aussi l'option la plus confortable pour le prestataire et la plus chère pour toi. Un bon prestataire commence par regarder ce qui peut être gardé.

Et un bonus qui les résume tous : le devis parle plus de l'infrastructure que de ton produit. Trois pages sur les pipelines et dix lignes sur tes fonctionnalités, c'est un devis écrit pour le plaisir de l'ingénieur, pas pour ton business.

Les questions à poser (et les réponses qui rassurent)

Tu n'as pas besoin de devenir technique. Tu as besoin de cinq questions.

La botte secrète d'abord : "Pourquoi pas plus simple ?" C'est la question qui trie le mieux. Un bon prestataire a une réponse concrète, avec ton contexte et des chiffres dedans : "parce que tes clients importent des fichiers de 2 Go et que ça bloquerait tout le reste". Un mauvais répond par des généralités : "c'est les bonnes pratiques", "c'est ce que font les grosses boîtes".

Ensuite :

• "Ça tient combien d'utilisateurs avant de devoir changer quelque chose ?" Tu cherches un ordre de grandeur, pas une promesse. Celui qui n'a pas d'ordre de grandeur n'a pas réfléchi à ta charge réelle.
• "Ça coûte combien par mois à faire tourner ?" L'architecture impressionnante se paie tous les mois, en serveurs et en temps humain. Ce chiffre doit exister dans le devis.
• "Si je demande un petit changement, il se passe quoi ?" Un changement simple doit rester simple. Si modifier un texte de bouton implique de redéployer quatre services, quelque chose cloche.
• "Si on arrête de travailler ensemble, qui peut reprendre ?" Une stack standard, n'importe quel dev correct la reprend. Une cathédrale exotique, tu restes marié avec son architecte.

Là encore, tu n'as pas à juger le fond technique des réponses. Tu juges leur forme : est-ce qu'on te répond avec ton contexte et des chiffres, ou avec des slogans ?

Quand le complexe est justifié

Soyons honnêtes, il y a des cas où la grosse artillerie se défend.

• Des pics de charge violents et imprévisibles. Une billetterie le soir d'une mise en vente passe de 100 à 100 000 visiteurs en dix minutes. Là, le serverless ou une brique dédiée à l'encaissement du pic, c'est pertinent.
• Plusieurs équipes qui doivent avancer en parallèle. Si ton plan réaliste, financé, c'est trois équipes produit d'ici un an, préparer le découpage a du sens.
• Des contraintes réglementaires d'isolation. Des données de santé ou bancaires qui doivent vivre dans un environnement séparé, ce n'est pas de l'over-engineering, c'est la loi.
• Un goulot mesuré, chiffres à l'appui. "Ce traitement prend 40 secondes et bloque les autres utilisateurs, on l'isole" : voilà une justification saine.

Le point commun de ces quatre cas : la complexité répond à un problème que tu as déjà, mesuré, documenté. Pas à un problème que tu pourrais peut-être avoir un jour si tout va très bien.

La règle à retenir

Si tu ne gardes qu'une chose :

La bonne architecture n'est pas la plus impressionnante. C'est la plus simple qui tient ta charge d'aujourd'hui, avec de la marge, et qui ne bloque pas celle de demain.

Le prestataire qui te propose simple, avec un plan clair pour grandir le jour où les chiffres le demanderont, te respecte plus que celui qui te vend le grand jeu tout de suite. Le premier optimise pour ton produit. Le second optimise pour sa facture, ou pour son CV.

Et si tu veux voir ce que coûte une base mal choisie sur la durée, j'ai détaillé la facture réelle dans le coût caché du vibe coding.

Besoin d'un deuxième avis avant de signer ?

Si tu as reçu des propositions et que tu n'arrives pas à les départager, je peux te faire une deuxième lecture : je regarde ton produit et les devis, et je te dis ce qui est justifié et ce qui est superflu. Et si tu cherches quelqu'un pour développer ton produit, découvre mon offre de développement sur mesure : on commence simple, et on muscle l'architecture le jour où tes chiffres le demandent.

Pour d'autres grilles de lecture dans ce style, inscris-toi à la newsletter. Du concret, sans spam.