Serverless ou serveur managé pour votre MVP : le choix d’infra qui décide de votre vitesse (et de votre facture)

Un fondateur technique me montre son architecture un vendredi soir : dix-sept fonctions Lambda, trois files de messages, une base DynamoDB et une passerelle API. Le produit a quatre utilisateurs actifs. Quand je lui demande combien de temps il met à ajouter une fonctionnalité, il hésite : « Ça dépend, il faut que je débogue le déploiement d’abord. » Le serverless devait le faire aller plus vite. Il l’a enfermé dans une architecture qu’il passe plus de temps à opérer qu’à faire évoluer.

Le choix entre serverless et serveur managé revient dans presque toutes les startups early-stage, et il est presque toujours tranché pour de mauvaises raisons : ce qu’on a vu dans un talk de conférence, ce qui semble « moderne », ou la peur diffuse de « ne pas scaler ». Or ce n’est pas une préférence de goût technique. C’est un pari sur votre vélocité de livraison, sur votre facture cloud et sur votre capacité à changer d’avis. À votre stade, ces trois choses valent plus cher que la scalabilité théorique.

Ce que la plupart des fondateurs se trompent à optimiser

L’erreur de fond, c’est de choisir son infrastructure en pensant à la charge qu’on n’a pas encore. On raisonne sur « et si demain on a un million d’utilisateurs », alors que la vraie question à pre-seed et seed est « comment je sors dix versions par semaine sans casser le produit et sans y passer mes nuits ».

Le serverless — au sens fonctions à la demande type AWS Lambda, Cloud Functions, ou même les edge functions — a un argument marketing imparable : vous ne payez que ce que vous consommez, et ça monte en charge tout seul. C’est vrai. Mais cette promesse répond à un problème que vous n’avez pas. Vous n’avez pas de problème de charge. Vous avez un problème de traction. Payer à la requête quand vous faites 3 000 requêtes par jour ne vous économise rien de significatif : votre facture serait de toute façon proche de zéro sur un petit serveur.

En échange de cette élasticité dont vous ne profiterez pas avant longtemps, vous payez immédiatement une taxe : la complexité opérationnelle. Chaque fonction devient une unité de déploiement, avec ses permissions, ses variables d’environnement, ses logs éparpillés. Le débogage local devient un cauchemar parce que rien ne tourne vraiment « sur votre machine ». Les cold starts ajoutent de la latence imprévisible. Et l’architecture vous pousse vers un découplage prématuré : des files, des événements, des services qui se parlent de façon asynchrone — de la complexité de startup série B que vous vous infligez avec quatre utilisateurs.

Le serveur managé, ou l’art de rester ennuyeux le plus longtemps possible

À l’opposé, il y a l’option qu’on ose à peine recommander parce qu’elle ne fait pas rêver : un backend monolithique classique déployé sur une plateforme managée (Render, Railway, Fly.io, Scaleway, ou un bon vieux conteneur sur un serveur unique). Un seul processus, une seule base de données Postgres managée, un déploiement qui prend une commande.

Ce qu’on gagne est précisément ce dont une startup early-stage a besoin : le produit tourne en entier sur votre laptop, exactement comme en production. Vous déboguez en posant un point d’arrêt. Vous ajoutez un endpoint en cinq minutes sans configurer une nouvelle fonction et ses droits IAM. Vous lisez tous vos logs au même endroit. La vélocité de livraison — votre vraie contrainte — reste maximale.

L’objection classique arrive tout de suite : « Et quand ça va scaler ? » Réponse honnête : un serveur managé encaisse plusieurs milliers de requêtes par seconde sur une machine modeste, largement de quoi couvrir vos deux ou trois premières années si votre produit décolle normalement. Le jour où vous saturez vraiment un serveur, vous avez un problème enviable — vous avez de la traction, probablement de l’argent levé, et une équipe pour extraire les parties chaudes de votre monolithe. C’est une décision que vous prendrez avec des données réelles, pas par anticipation angoissée.

Il faut néanmoins nommer le vrai risque du serveur managé : le point unique de défaillance. Si votre unique instance tombe, le produit tombe. À votre stade, ce n’est généralement pas dramatique — vous n’avez pas de SLA à cinq clients enterprise. Mais la parade est simple et ne coûte pas la complexité serverless : deux instances derrière un load balancer managé, une base répliquée. Vous obtenez une résilience raisonnable sans exploser votre modèle mental.

Où le serverless a réellement sa place à votre stade

Rejeter le serverless en bloc serait aussi caricatural que de tout y mettre. Il y a un usage où il est excellent, y compris pre-seed : les tâches ponctuelles et périphériques. Un webhook Stripe à traiter, un redimensionnement d’image, un cron qui envoie un rapport chaque matin, une intégration tierce isolée. Ces charges sont sporadiques, sans état, et n’ont pas besoin de partager votre logique métier. Les coller dans une fonction évite de faire tourner un worker en permanence pour rien.

Le bon pattern early-stage n’est donc pas « serverless OU serveur », c’est « un cœur monolithique sur serveur managé, entouré de quelques fonctions pour le périphérique ». Votre logique produit — celle qui change tout le temps, qu’il faut déboguer et faire évoluer vite — reste dans un endroit simple et cohérent. Ce qui est stable, isolé et intermittent part en fonction. Vous gardez la vélocité là où elle compte, et l’élasticité là où elle est gratuite.

Attention aussi à un piège de coût sous-estimé : le serverless ne facture pas que le compute. Une architecture full-serverless multiplie souvent les services managés annexes — passerelle API, base NoSQL facturée à la lecture/écriture, files, orchestration. Une startup qui « ne paye que ce qu’elle consomme » se retrouve parfois avec une facture cloud plus lourde et surtout beaucoup plus difficile à prévoir qu’un forfait mensuel fixe de serveur. Sur un runway compté en mois, la prévisibilité de la dépense vaut souvent mieux qu’une optimisation théorique.

Ce qu’il faut vraiment faire, selon votre stade

À pre-seed, tranchez pour l’ennui absolu : un monolithe sur une plateforme managée, une base Postgres, déploiement en une commande. Votre unique métrique d’infra est « combien de temps entre une idée et sa mise en production ». Tout ce qui allonge ce délai est votre ennemi, quelle que soit son élégance. Réservez le serverless aux webhooks et aux crons.

À seed, quand vous avez validé votre ICP et que le produit prend de la charge réelle, ne réécrivez rien. Ajoutez de la robustesse là où la donnée le justifie : une seconde instance, du monitoring qui vous réveille quand ça casse, une file pour les traitements qui ne doivent pas bloquer la requête utilisateur. Vous étoffez le socle, vous ne migrez pas de paradigme.

À l’approche de la série A, vous aurez peut-être une ou deux parties du système qui méritent d’être isolées — un composant très sollicité, une charge vraiment imprévisible, un besoin de scaler indépendamment. C’est là qu’extraire un service, éventuellement serverless, devient une décision fondée sur des faits. Vous le ferez chirurgicalement, sur la base de métriques, pas par principe. Et ce sera bien plus facile depuis un monolithe propre que depuis dix-sept fonctions entremêlées.

Le critère de décision n’est donc jamais « lequel est le plus scalable ». C’est : quelle architecture me permet de livrer le plus vite aujourd’hui, tout en me laissant la liberté de changer d’avis demain sans tout casser. À de rares exceptions près, pour une startup early-stage, c’est le serveur managé qui gagne — précisément parce qu’il est ennuyeux.

La vraie question à vous poser n’est pas technique : combien de vos décisions d’architecture avez-vous prises pour la startup que vous voulez devenir, plutôt que pour celle que vous êtes réellement aujourd’hui ? C’est souvent là, bien avant la ligne de code, que se joue votre runway.