Kubernetes avant d’avoir un produit : le piège de l’infrastructure que vous montez pour une startup que vous n’êtes pas encore

Un fondateur technique me montre fièrement son architecture : cluster Kubernetes multi-zones, service mesh, pipeline GitOps, monitoring Prometheus/Grafana, autoscaling horizontal configuré au cordeau. Le produit ? Trois cents utilisateurs, dont une quarantaine d’actifs. La question qui fâche : combien de ces briques répondent à un problème que vous avez réellement aujourd’hui, et combien à un problème que vous imaginez avoir dans dix-huit mois ?

Le silence qui suit est le vrai sujet de cet article.

Le problème : on architecture pour la startup fantasmée, pas pour la startup réelle

L’infrastructure prématurée est l’une des formes les plus insidieuses de dette technique, précisément parce qu’elle ne ressemble pas à de la dette. Elle ressemble à du sérieux. Un cluster Kubernetes bien configuré, ça rassure — le fondateur, les premiers investisseurs, le développeur qui l’a monté et qui a mis “K8s” sur son LinkedIn. Personne ne vous reproche jamais d’avoir trop préparé l’échelle.

Sauf que l’échelle, à ce stade, n’est pas votre problème. Votre problème, c’est de savoir si quelqu’un veut vraiment payer pour ce que vous construisez. Et chaque heure passée à débugger un ingress controller ou à comprendre pourquoi votre pod reste en CrashLoopBackOff est une heure que vous ne passez pas à parler à des clients, à itérer sur votre onboarding, ou à corriger le bug qui fait fuir vos premiers utilisateurs.

Le pattern est archi-reconnaissable : la startup qui scale son infra avant d’avoir validé son ICP. Elle optimise la robustesse d’un système qui devrait encore être jetable. Elle traite comme acquis un produit qui n’a pas encore trouvé son marché. C’est une inversion de priorités déguisée en rigueur d’ingénierie.

Pourquoi Kubernetes coûte plus cher que sa facture cloud

Quand on évalue le coût d’une infrastructure, on regarde la ligne AWS ou GCP. C’est l’erreur. Le vrai coût de Kubernetes en early-stage n’est pas sur votre facture cloud — il est sur votre facture de temps humain, et cette facture-là est bien plus salée.

Un cluster Kubernetes en production, ce n’est pas “un serveur, en plus scalable”. C’est un système distribué avec sa propre courbe d’apprentissage, ses propres modes de panne, sa propre surface de sécurité. Vous héritez de la gestion des mises à jour du control plane, des CNI, des RBAC, des secrets, des certificats, des volumes persistants. Chacune de ces couches peut casser d’une manière que votre équipe de deux personnes n’a jamais vue et mettra une demi-journée à diagnostiquer.

Il y a un coût encore plus sournois : le coût de recrutement. Une stack complexe rétrécit le vivier de gens capables de la maintenir. Sur le marché français, un profil vraiment à l’aise avec Kubernetes en production se paie cher et se recrute lentement. En vous liant à une infrastructure exigeante trop tôt, vous transformez chaque futur recrutement tech en négociation sur une compétence rare — alors que vous auriez pu embaucher un développeur produit généraliste qui livre de la valeur dès la première semaine. Votre choix d’infra vient de restreindre votre choix de talents. C’est une décision business déguisée en décision technique.

La bonne question n’est pas “managed ou self-hosted”, c’est “quel problème je résous maintenant”

L’arbitrage managed vs self-hosted se joue rarement sur la technique pure. Il se joue sur ce que vous pouvez vous permettre d’ignorer.

Le principe directeur en early-stage : externalisez tout ce qui n’est pas votre différenciation. Votre base de données ne vous différencie pas — prenez un Postgres managé (RDS, Cloud SQL, Supabase, Neon) et n’y pensez plus. Votre file de messages ne vous différencie pas. Votre hébergement d’application ne vous différencie pas non plus tant que vous n’avez pas de contrainte d’échelle prouvée par des métriques, pas par une intuition.

Concrètement, pour la grande majorité des startups pre-seed et seed, la réponse n’est même pas Kubernetes. C’est une Platform-as-a-Service : Render, Railway, Fly.io, Scaleway Serverless, ou une bonne vieille app conteneurisée sur un service managé type Cloud Run ou App Runner. Vous poussez votre code, la plateforme gère le déploiement, le scaling de base, les certificats TLS, les rollbacks. Vous récupérez 90 % des bénéfices opérationnels de Kubernetes pour 10 % de la complexité. Le delta que vous “perdez” — contrôle fin, portabilité maximale, orchestration multi-service sophistiquée — correspond exactement à des besoins que vous n’avez pas encore.

Cette approche a un autre mérite, souvent négligé : la vélocité de déploiement. Une PaaS vous donne du déploiement continu quasi gratuit dès le premier jour. Or votre contrainte réelle en early-stage n’est pas la capacité de calcul, c’est votre capacité à livrer vite et à corriger vite. Une infra simple qui vous permet de déployer dix fois par jour bat une infra sophistiquée qui vous fait déployer une fois par semaine parce que le pipeline est fragile.

Quand la complexité devient légitime — et comment le savoir

Il ne s’agit pas de diaboliser Kubernetes. C’est un excellent outil pour le problème qu’il résout. Le point, c’est de reconnaître le moment où ce problème devient le vôtre — et de ne pas payer avant.

Les signaux honnêtes qui justifient de monter en complexité sont concrets, pas hypothétiques. Vous avez plusieurs services qui ont des profils de charge différents et que le scaling monolithique de votre PaaS ne sait plus gérer efficacement. Vous atteignez les limites de configuration ou de coût de votre plateforme managée à volume élevé — au-delà d’un certain trafic, une PaaS devient plus chère qu’un cluster que vous gérez. Vous avez une contrainte de conformité ou de souveraineté (un client grand compte, un cadre RGPD strict, un besoin d’hébergement en France) qui exige un contrôle d’infrastructure que le managed ne vous donne pas. Vous avez recruté quelqu’un dont c’est le métier et qui ne va pas devenir le goulot d’étranglement.

Ces signaux apparaissent typiquement autour de la série A, quand la traction est prouvée et que l’échelle devient un problème mesurable plutôt qu’une projection. À ce moment-là, migrer vers une infrastructure plus contrôlée est un investissement rationnel. Fait avant, c’est un pari sur une startup que vous n’êtes pas encore devenu.

Le corollaire important : construire simple d’abord ne vous condamne pas. Une application bien conteneurisée, avec ses variables d’environnement propres et sa configuration externalisée, se déplace d’une PaaS vers Kubernetes sans réécriture. La portabilité vient de vos bonnes pratiques applicatives, pas de votre choix d’orchestrateur. Vous ne vous enfermez pas en commençant simple — vous vous enfermez en vous croyant obligé de commencer compliqué.

Ce qu’il faut vraiment faire

Auditez votre infrastructure actuelle avec une seule question par brique : quel problème réel, mesuré, résout-elle aujourd’hui ? Si la réponse est “aucun, mais on en aura besoin plus tard”, c’est un candidat au démantèlement, pas à l’optimisation.

Par ordre de priorité selon votre stade :

En pre-seed et seed, visez le déploiement le plus paresseux possible. Une PaaS, une base de données managée, un pipeline de déploiement continu qui marche tout seul. Objectif : que votre équipe ne pense jamais à l’infra et passe tout son temps sur le produit et les clients. Zéro Kubernetes.

En approche de série A, instrumentez avant de complexifier. Mettez en place l’observabilité (latence, taux d’erreur, coût par service) pour que la décision de migrer soit déclenchée par des données, pas par une envie. Identifiez la ou les briques qui commencent réellement à coincer.

En série A confirmée, si les signaux sont là et que vous avez la compétence en interne, migrez de façon incrémentale — service par service, pas en big bang. Et gardez managé tout ce qui reste hors de votre différenciation.

La discipline ici n’est pas de refuser la complexité. C’est de la mériter. Chaque couche d’infrastructure devrait être une réponse à une douleur que vous ressentez, jamais à une douleur que vous anticipez pour vous rassurer.

La vraie question à vous poser n’est donc pas “est-ce que mon infra tiendra à l’échelle ?” Elle est : si je supprimais la moitié de ma stack demain, est-ce que mes clients le remarqueraient — ou est-ce que seul mon ego d’ingénieur en souffrirait ?