Scaling SaaS : 5 patterns d’infrastructure qui sont des freins à la croissance

Docker Swarm, Docker Compose, 100 % Serverless sans garde-fous, monolithe ou infrastructure artisanale : ces cinq patterns sont des freins au scaling de votre SaaS.

En 2026, entre l’intégration de l’IA agentique, les enjeux de souveraineté et les nouvelles exigences de conformité, les règles du jeu se redéfinissent.

Pour rester compétitif, tout commence par le socle ultime de votre logiciel : son infrastructure. Nous détaillons ici les limites de chaque modèle et les pistes techniques pour s’appuyer sur un moteur de croissance scalable. Place à la magie.

Télécharger le REX migration Kubernetes de Semji

« L’IA va t-elle tuer mon produit ? Comment rendre autonome l’agentique sans ruiner la sécurité ? Mon infrastructure va-t-elle passer le prochain audit de conformité ? »

Sans vouloir verser dans le mélodrame, ce sont à coup sûr des questions qui animent les Comex des éditeurs de logiciel. En 2026, le confort du « Business as usual » a été balayé d’un revers de main.

Pour comprendre ce qui se cache derrière ces mutations, tantôt pleines de promesses, tantôt effrayantes, voici quelques chiffres :

• Une croissance qui ne fléchit pas : le marché français du numérique affiche une santé de fer avec une hausse de +4,3 % attendue en 2026, portée majoritairement par le segment de l’édition SaaS. Le gâteau grossit, mais les parts sont plus dures à avoir.
• L’agentique contre attaque : d’ici la fin de l’année,près de 80 % des applications d’entreprise intégreront des agents IA capables de prendre des décisions autonomes. On ne parle plus d’assistants, mais de collaborateurs digitaux.
• La « Seat Apocalypse » : ce n’est pas le tout dernier dossier Warren, mais bien un phénomène qui bouscule le secteur. Gartner prédit que 70 % des entreprises vont désormais privilégier des modèles de tarification basés sur l’usage ou la valeur. Le sacro-saint « prix par utilisateur » semble promis à disparaître.
• French Is The New Black : la souveraineté redore son blason et les alternatives aux GAFAM sont de plus en plus plébiscitées par les clients et les organisations. 82 % des entreprises de la zone EMEA réévaluent leur stratégie pour répondre aux évolutions géopolitiques. Preuve que le sujet est sur la table, la France a même lancé son Observatoire de la souveraineté numérique.
  

Un beau tableau qui promet du mouvement et de la croissance pour les éditeurs. Pour les équipes dirigeantes, cela signifie revoir ses fondamentaux, du pricing aux obligations réglementaire. Le tout, en parallèle d’une roadmap bien chargée pour atteindre l’objectif de toute plateforme en ligne : du MRR, de l’ARR, de la croissance, de la pérennité.

Sans conteste, les SaaS qui prévoient de scaler ont tout intérêt à prendre le taureau par les cornes dès maintenant. Car vous pouvez recruter les meilleurs commerciaux de la place et concevoir les agents IA les plus brillants, si votre infrastructure informatique ne suit pas le rythme, vous risquez de vous heurter à un plafond de verre.

Mais à quoi ressemble une infrastructure qui freine le scaling SaaS ? Continuez la lecture, nous vous en donnons 5 exemples.

Avant de plonger dans le détail des architectures, rapide disclaimer.
Toutes les solutions que nous allons vous présenter ci-dessous reposent sur deux pré-requis :

• Un minimum de conteneurisation : sans forcément basculer dans une architecture microservices complexe, l’idée est d’avoir une infrastructure suffisamment découpée pour permettre un scaling horizontal. Pour absorber une charge fluctuante, vous devez être capable d’ajouter de la puissance sur une brique spécifique (votre API ou vos workers, par exemple) sans avoir à cloner l’intégralité de votre système.
• L’adoption de l’orchestration : c’est l’intelligence logicielle qui s’assure que vos conteneurs tournent toujours au bon endroit, gère leur santé et répartit le trafic de manière fluide.

💡Pourquoi ça ? Parce qu’en phase de croissance, la souplesse et la flexibilité sont primordiales. Sans ces fondations, vous risquez d’investir dans des solutions rigides qui ne donneront pas les résultats escomptés et qui, à terme, vous décevront.

Pour celles et ceux qui veulent gagner du temps :
Infrastructure 1 : le monolithe
Infrastructure 2 : Docker Compose
Infrastructure 3 : Docker Swarm
Infrastructure 4 : Serveless sans garde fous
Infrastructure 5 : l’infra artisanale

Infrastructure n°1 : le monolithe (VM + DB sur une seule machine)

Loin de nous l’idée de condamner le monolithe. Contrairement aux idées reçues, ce n’est pas un gros mot technique. Des géants comme Doctolib ont bâti leur succès sur des monolithes dits « modulaires » : un code massif, certes, mais structuré, découpé logiquement et capable de supporter une forte charge grâce à une infrastructure distribuée.

Ici, nous parlons du monolithe monolithe : celui où le code, la base de données, les caches et les fichiers cohabitent sur une seule et même machine.

Pourquoi beaucoup d’entreprises font ce choix ?

C’est simple et c’est rapide, surtout quand on cherche son Product-Market Fit avec un budget serré. On privilégie la vitesse d’exécution à la structure.

La stack type :

• Provisioning : 1 VM (ou 1 gros serveur) : Nginx + app monolithique (Node/Rails/Django/Java) + Postgres/MySQL + Redis sur la même instance.
• Déploiement : par SSH + git pull.
• Maintenance : backups “maison” (cron + dump), firewall minimal, peu ou pas de séparation réseau.
• Observabilité : monitoring basique (ou absent), logs perdus dans des fichiers locaux.
  

Les limites du monolithe :

Côté charge : ce n’est pas seulement que le CPU sature, c’est qu’il est partagé. Votre base de données et votre application se battent pour les mêmes cycles de calcul et les mêmes accès disque (IOPS). Conséquence : une requête SQL lourde ralentit instantanément l’expérience utilisateur. Vous atteignez une limite physique : celle du serveur et dans ce cas précis, celle du disque.

Côté disponibilité : c’est le SPOF (Single Point of Failure) absolu. Puisque tout est au même endroit, le moindre incident (un disque plein, une mise à jour kernel qui dérape ou un redémarrage nécessaire) coupe l’accès à l’intégralité du produit.

Côté coût : vous ne pouvez agir que sur le scaling vertical. Pour gagner 10 % de performance, vous devez souvent passer au forfait de VM supérieur (ce qui peut parfois doubler la facture d’un coup). C’est un modèle de croissance par paliers brutaux.

Côté sécurité : puisque la séparation réseau est inexistante, la machine est une cible unique. Les secrets (clés API, accès DB) sont souvent stockés localement. Si un attaquant compromet l’application, il accède instantanément à la base de données et à tout le système.

Les impacts sur le delivery :

• Fear-driven delivery : on évite de déployer le vendredi (pour sauver le week-end) et on batch les features par peur de redémarrer le monolithe.
• Explosion du MTTR : en l’absence de corrélation de logs, il est difficile d’identifier la cause racine d’un incident. Le temps moyen de rétablissement (MTTR) s’envole car vous cherchez une aiguille dans une botte de foin.
• Perte de focus des équipes : vos développeurs passent une bonne partie de leur temps à s’improviser sysadmins. Ils s’épuisent sur des tâches qui ne sont pas les leurs, au lieu de créer de la valeur.
  

Infrastructure n°2 : Docker Compose

Si Docker est le moteur de l’unité (le conteneur), Docker Compose en est la surcouche de coordination : un plan de montage en YAML qui permet de piloter l’ensemble de vos services (App, DB, Cache) comme un seul bloc cohérent. En local, c’est une merveille de productivité qui évite de lancer chaque brique à la main. En production, c’est une autre histoire.

Pourquoi beaucoup d’entreprises font ce choix ?

Docker Compose est un choix pragmatique car il permet de documenter et de versionner toute son infrastructure dans un seul fichier YAML. C’est une bonne manière d’introduire l’orchestration car on bénéficie de l’isolation des composants et de la portabilité des images sans payer la « taxe » de complexité liée à un orchestrateur lourd. Mais évidemment, cela implique quelques limites.

La stack type :

• Provisioning : Docker Compose utilisé tel quel en production (souvent issu du docker-compose.yml local).
• Services : web, worker, cron, redis, parfois db, nginx/traefik.
• Déploiement : docker compose pull & docker compose up -d (ou script shell).
• Maintenance : gestion artisanale des données via des volumes locaux (bind mounts) ou un système NFS bricolé.
• Observabilité : flux stdout non centralisés et réseau Docker interne qui rend le debugging opaque dès que les services se multiplient.
  

Les limites de Docker Compose :

Côté disponibilité : Docker Compose n’est pas un orchestrateur de haute disponibilité (HA). Il vit et meurt avec la machine qui l’héberge. Si le serveur flanche ou si le démon Docker crash, rien ne redémarre automatiquement ailleurs.

Côté scalabilité : Docker Compose ne sait pas gérer plusieurs serveurs. Pour multiplier les instances d’une API sur la même machine, c’est un enfer de gestion de ports (chaque instance réclame son propre numéro de port : 8080, 8081…). De plus, les volumes et la base de données sont « cloués » au disque dur local : impossible de rajouter une deuxième machine, car elle n’aurait pas accès aux données de la première.

Côté opérations : Compose ne gère pas nativement les rolling updates intelligents. Chaque mise à jour peut entraîner des micro-coupures ou une désynchronisation : c’est le risque de voir votre frontend parler à une version de l’API qui n’est pas encore prête.

Côté sécurité : bien que les conteneurs soient isolés, la gestion des secrets repose souvent sur des fichiers .env stockés en clair sur le disque. Sans orchestrateur pour injecter dynamiquement les configurations, la surface d’attaque reste concentrée sur un seul point d’entrée.

Les impacts sur le delivery :

• Déploiements « touchy » : l’ordre de redémarrage des conteneurs est crucial. Une mauvaise séquence restart peut casser des dépendances.
• Debug difficile : le réseau interne de Docker est assez opaque. Sans métriques ni logs corrélés, comprendre pourquoi deux services ne se parlent plus relève de la divination.
• QA dégradée : paradoxalement, il est difficile de recréer à la volée des environnements de test strictement identiques à cette « prod » Compose. La fiabilité des tests en pâtit.

Infrastructure n°3 : Docker Swarm

Ah, Docker Swarm… celui-ci, on le connaît bien, faute de l’avoir croisé dans de nombreux cas de migration vers Kubernetes. Pour s’y retrouver, clarifions rapidement :

• Docker est l’environnement d’exécution (le runtime) qui gère le cycle de vie d’un conteneur isolé sur un hôte.
• Docker Compose est l’outil de définition qui permet de configurer et de lancer plusieurs conteneurs sur une seule instance.
• Docker Swarm est l’orchestrateur natif qui permet de déployer et de coordonner ces conteneurs sur un cluster (un groupe de serveurs).

En tant qu’orchestrateur, Swarm est une solution robuste qui apporte une vraie logique de gestion de flotte. Il convient d’ailleurs très bien aux environnements où tout est prévisible. Toutefois, il n’en reste pas moins un système rigide qui excelle dans le statique, mais qui n’est plus du tout adapté dès qu’il faut gérer une croissance imprévisible ou une automatisation complexe. Swarm tient généralement bien la charge jusqu’à 5 nœuds, au-delà, les comportements deviennent moins prédictibles. C’est pour cette raison qu’il figure dans cette liste.

Pourquoi beaucoup d’entreprises font ce choix ?

C’est le choix du pragmatisme. Swarm promet une transition transparente depuis le développement : si vous avez un fichier docker-compose.yml, vous pouvez techniquement le déployer sur un cluster en quelques minutes. Pour beaucoup de structures, c’est un compromis pour horizontaliser une architecture sans avoir à former les équipes à une logique d’orchestration plus complexe (mais aussi plus précise).

La stack type :

• Provisioning : un cluster Swarm composé généralement de 3 nœuds Managers (pour le plan de contrôle et le consensus Raft) et de 2 à 5 nœuds Workers (pour l’exécution des charges).
• Services : Web, API, Workers, Redis, et parfois des bases de données ou ElasticSearch déployés directement en services Swarm (une pratique risquée pour la donnée).
• Réseau & Routing : utilisation de l’Overlay network natif pour la communication inter-conteneurs et du load balancing interne (VIP). En frontal, on retrouve souvent Traefik ou NGINX pour gérer le trafic entrant.
• Déploiement : commande docker stack deploy pour la structure globale ou docker service update pour les mises à jour rapides, pilotées par une pipeline CI simple.
• Maintenance & Données : dépendance forte à des volumes locaux ou à un système NFS partagé pour que les données restent accessibles quand Swarm déplace un conteneur d’un nœud à l’autre.
• Secrets : utilisation des secrets Swarm natifs, souvent pratiques mais rarement couplés à une véritable logique de rotation ou de gestion dynamique.
• Observabilité : logs stdout collectés partiellement via des agents (Fluentd, Logspout).
  

Les limites de Docker Swarm :

Côté disponibilité : si Swarm promet une haute disponibilité théorique, elle est fragile en pratique car presque tout finit par être géré à la main. Contrairement aux orchestrateurs plus modernes, le système manque d’autonomie pour s’auto-réparer sans intervention humaine.

Côté stabilité : Swarm repose sur un algorithme de consensus entre les Managers. Si vous perdez ce quorum, le cluster se fige totalement et vous basculez dans une gestion manuelle pour maintenir vos services en ligne.

Côté maintenance : en cas de corruption de la base de données interne Raft, la récupération du cluster est très complexe. Il n’existe pas de procédure simple pour restaurer l’état sain du cluster sans une expertise pointue.

Côté réseau : le networking overlay, qui permet aux conteneurs de communiquer entre les serveurs, devient instable dès que l’on passe à grande échelle. Compliqué alors de diagnostiquer les pertes de paquets et les latences.

Côté pérennité : en 2026, l’écosystème a massivement convergé vers Kubernetes. Swarm est devenu une technologie de niche que les solutions de sécurité et de monitoring moderne ne supportent plus en priorité.

Les impacts sur le delivery :

• Charge mentale et opérationnelle : sans autoscaling natif, chaque pic de charge force l’équipe à intervenir manuellement pour ajouter des ressources ou des réplicas. C’est du temps de développement perdu.
  
• Instabilités imprévisibles : la gestion floue des ressources (absence de requests/limits strictes) signifie qu’un service peut saturer un serveur sans prévenir et causer des bugs « fantômes » ou des crashs en cascade qui mobilisent l’équipe sur du debugging d’infrastructure.
  
• Dette d’écosystème : l’isolement technologique de Swarm oblige l’équipe à bricoler des solutions maison pour le monitoring ou la sécurité, là où les standards du marché offrent des outils prêts à l’emploi.
  

Infrastructure n°4 : le 100 % Serverless sans garde-fous

Quand on voit tous les défis qu’amènent la gestion de clusters, on comprend que certains choisissent l’option la plus radicale : ne pas gérer de serveurs du tout. Ce qu’on appelle communément le serverless.

Quand on parle de Serverless ou FaaS (Function as a Service), on ne parle plus d’application qui tourne en continu, mais de code qui « se réveille » à la demande. Le code s’exécute uniquement lorsqu’un événement survient (une requête HTTP, un upload de fichier). Si personne n’utilise le service, rien ne tourne et vous ne payez rien.

Ce que nous appelons ici le « 100 % serverless sans garde-fous », c’est une infrastructure exploitée sans rigueur DevOps et sans stratégie FinOps.

Pourquoi beaucoup d’entreprises font ce choix ?

C’est le choix de la vitesse de mise sur le marché (Time-to-Market) et de l’efficience budgétaire au démarrage. Vous ne payez que ce que vous consommez réellement, à la milliseconde près. C’est idéal pour les startups qui veulent valider un produit sans gérer d’infrastructure ni payer pour des serveurs qui tournent à vide la nuit.

La stack type :

• Compute : exécution de fonctions isolées déclenchées par des événements (AWS Lambda, Google Cloud Serveless, Azure Functions, Scaleway Serverless Functions). Le fournisseur gère l’allocation dynamique des ressources.
• Services managés : utilisation de bases de données et de systèmes de cache en mode « on-demand », soumis à des quotas stricts (limites de connexions simultanées, IOPS, débit).
• Réseau & sécurité : contrôlés « à la marge » par le fournisseur. L’isolement est garanti, mais les capacités de routage complexe (réseaux privés, contrôle précis des flux sortants) sont limitées.
• Observabilité : partielle et souvent propriétaire, ce qui rend le traçage des requêtes à travers plusieurs fonctions parfois complexe.
  

Les limites du serverless :

Côté coût : le passage à l’échelle déclenche une facture en escalier. À partir d’un certain volume de requêtes permanentes, le coût à l’exécution devient nettement supérieur à celui d’une ressource provisionnée.

Côté performance : vous subissez les Cold Starts (latence au réveil de la fonction) et les limites de connexions aux bases de données.

Côté architecture : les besoins « sérieux » (réseaux privés, isolation, conformité stricte) sont difficiles à mettre en œuvre et imposent des contournements techniques complexes.

Risque de Lock-in : plus la migration vers une infrastructure standard est tardive, plus le coût de sortie de l’écosystème propriétaire est élevé.

Les impacts sur le delivery :

• Arbitrages constants : très fluide au début, le quotidien finit par être rythmé par des arbitrages entre les quotas techniques et le coût des plans supérieurs.
• Gel de roadmap : une migration totale vers un orchestrateur (type Kubernetes) une fois le plafond atteint risque de paralyser les développements produits pendant plusieurs mois.

Infrastructure n°5 : SSH + scripts + infra à la main

C’est osé, on l’admet, car on ne croise plus vraiment ce genre d’infrastructure aujourd’hui. Et pourtant, le récent leak de YggTorrent (yggleak.top) prouve que l’infra « artisanale » survit encore dans certains recoins du web. Soyons clair : ce n’est pas du tout une bonne pratique.

Ici, on parle de l’infrastructure « artisanale », faite avec amour et beaucoup de clics. Une infrastructure où on ne commande pas ses serveurs par code, on les « fait » à la main dans la console Cloud avec du SSH, du copier-coller de secrets et du fameux : « Touche pas à cette VM, Pascal est le seul à savoir comment elle est configurée »

Pourquoi beaucoup d’entreprises font ce choix ?

C’était la façon de faire il y a dix ou quinze ans. À l’époque, les outils d’automatisation étaient complexes, réservés à des experts pointus, ou tout simplement inexistants pour les petites structures. On ouvrait la console du fournisseur Cloud comme on ouvrait un tiroir. Beaucoup d’entreprises ont grandi avec cette culture du « faire soi-même » parce les standards d’aujourd’hui qui permettent de déployer un cluster complet en trois lignes de commande, n’existaient pas. Il est aussi courant de croiser encore ce type d’infrastructures dans les petites équipes, où il y a peu de développeurs et donc peu de concurrence de déploiement

La stack type :

• Provisioning : entièrement manuel via la console cloud (VM, Load Balancers, DNS, buckets).
• Déploiement : scripts Bash ad-hoc lancés depuis un terminal local et runbooks (plus ou moins à jour) sur un Wiki.
• Configuration : pas d’IaC. Config drift permanent.
• Sécurité : accès prod trop larges, secrets stockés en clair ou copiés-collés, audit quasi inexistant.

Les limites de l’infra à la main :

Côté équipe : au-delà de 5-10 développeurs, le bus factor est critique. Si l’expert système s’en va, la connaissance part avec lui. Au-delà de ça, l’absence de file d’attente automatisée crée une concurrence sur les déploiements : lorsque plusieurs développeurs interviennent simultanément, leurs modifications s’entrechoquent et finissent par provoquer de la casse en production. 

Côté fiabilité : incidents particulièrement difficiles à reproduire à cause des changements manuels non tracés et des patchs « en prod » oubliés.

Côté Time-to-Env : créer un staging miroir ou un environnement client est une mission longue, risquée et souvent bâclée.

Côté Compliance : absence totale de traçabilité, ce qui bloque toute vente à des clients « Enterprise » exigeants.

Les impacts sur le delivery :

• Déploiements stressants : les mises à jour sont longues, angoissantes et dépendent d’une personne clé.
• Staging ≠ Prod : bugs fréquents en production car les environnements ne sont jamais identiques
• Ralentissement : Les développeurs finissent par contourner les process par peur de casser un équilibre fragile. Et donc, toujours plus de dette technique.

Sur le papier, ça semble « facile » mais dans la réalité, l’exercice est plus complexe : c’est un mélange de vision stratégique, de rigueur opérationnelle et de méthode, où le défi majeur reste de transformer l’existant sans paralyser les cycles de livraison.

Or, personne ne s’attend à ce que vous changiez tout du jour au lendemain. La transition vers une infrastructure taillée pour le scaling peut s’opérer par étapes. En commençant par sécuriser vos briques les plus critiques ou en levant les verrous techniques qui brident vos équipes aujourd’hui, vous vous rapprochez, palier après palier, de l’état de l’art du SaaS.

Vous avez besoin d’un conseil ? Vous avez un blocage technique ? Une urgence en prod ? Nos DevOps mettent leur expérience du terrain à votre service. Rendez-vous sur cette page pour nous le décrire et nous vous recontactons sous 48h avec des pistes de solutions.

DévOpsément vôtre.

Méfait accompli.