Comprendre les architectures modernes : containers vs serverless
En 2026, la plupart des projets d’hébergement d’applications web se posent la même question : faut-il choisir une architecture basée sur des containers (type Docker, Kubernetes) ou sur le serverless (type AWS Lambda, Azure Functions, Google Cloud Functions) ? Ces deux approches de l’hébergement web moderne et du cloud computing répondent à des besoins différents en termes de performance, de coûts, de conformité réglementaire et de flexibilité.
Avant de choisir un fournisseur ou une plateforme d’hébergement (AWS, Azure, Google Cloud, OVHcloud, Scaleway, Clever Cloud, etc.), il est indispensable de comprendre les forces et les limites de chaque modèle. En 2026, la pression réglementaire européenne (RGPD, Data Act, NIS2) vient également peser dans la balance, en particulier pour les entreprises manipulant des données personnelles ou sensibles.
Qu’est-ce qu’un container pour héberger une application web ?
Un container est une unité logicielle légère qui contient tout le nécessaire pour exécuter une application : code, dépendances, bibliothèques, configuration système minimale. Les technologies les plus répandues sont :
- Docker pour le packaging des applications
- Kubernetes, Docker Swarm, Nomad pour l’orchestration
- Rancher, OpenShift, K3s, etc. pour la gestion avancée des clusters
Dans un contexte d’hébergement cloud, les containers offrent :
- Une isolation plus légère que les machines virtuelles
- Une portabilité élevée entre différents fournisseurs (multi-cloud, hybrid cloud)
- Un contrôle précis sur l’environnement d’exécution
Les containers sont particulièrement adaptés aux applications web complexes : microservices, API REST, applications temps réel, plateformes e-commerce avec de nombreux composants (front-end, back-end, bases de données, workers, etc.).
Qu’est-ce que le serverless en 2026 ?
Le serverless (computing sans serveur, même si des serveurs existent réellement en arrière-plan) désigne un modèle où le fournisseur cloud gère automatiquement l’infrastructure. L’utilisateur ne provisionne pas de serveur ou de container longuement actif, mais déploie des fonctions ou des services exécutés à la demande.
Les principaux services serverless en 2026 incluent :
- AWS Lambda, AWS Fargate (mode serverless pour containers), AWS API Gateway
- Azure Functions, Azure Container Apps
- Google Cloud Functions, Cloud Run (mode serverless pour containers)
- Offres serverless européennes comme OVHcloud Functions, Scaleway Functions, Clever Cloud Functions
Le modèle économique du serverless repose sur la facturation à l’usage : temps d’exécution, nombre de requêtes, mémoire consommée. Cela permet une montée en charge automatique, sans gestion de serveur, et un paiement ajusté à la consommation réelle.
Performance et latence : ce que containers et serverless changent
Sur le plan purement technique, containers et serverless se distinguent par :
- Temps de démarrage : les containers démarrent généralement plus vite qu’une machine virtuelle, mais plus lentement que des fonctions serverless déjà “chaudes”. En revanche, les fonctions serverless peuvent souffrir de “cold starts” (temps de réveil) pour les requêtes peu fréquentes.
- Latence : pour des API critiques et très sollicitées, un cluster de containers bien dimensionné offre une latence plus prévisible que certaines plateformes serverless avec cold start.
- Optimisation des ressources : en containers, vous pouvez affiner le CPU, la RAM, les limites de ressources et le placement des pods (sur Kubernetes par exemple). En serverless, c’est le fournisseur qui ajuste ces paramètres, souvent avec moins de granularité mais plus de simplicité.
Pour une application web à fort trafic et nécessitant une performance constante (ex. SaaS B2B, trading, application temps réel), les containers orchestrés sur Kubernetes ou équivalent restent très souvent le choix privilégié. Pour des workloads sporadiques, des tâches de fond, des API peu sollicitées ou des prototypes, le serverless est particulièrement pertinent.
Coûts et modèle économique : bien lire la facture cloud
Le coût est un critère majeur pour le choix d’un hébergement cloud. En 2026, les principaux modèles économiques sont :
- Containers : facturation basée sur les ressources provisionnées (CPU, RAM, stockage, trafic réseau). Même si l’application n’utilise pas 100 % des ressources, elles sont généralement facturées en continu.
- Serverless : facturation à l’usage (par ex. nombre d’invocations, durée d’exécution en millisecondes, mémoire allouée). Pas de coût ou très peu en dehors des périodes d’utilisation.
En pratique :
- Pour une application web à trafic constant et prévisible, les containers sur un cluster bien optimisé peuvent être plus économiques.
- Pour une application à trafic irrégulier ou imprévisible (pics ponctuels, saisonnalité), le serverless permet d’éviter le surprovisionnement.
- Les coûts cachés (logs, monitoring, transfert de données, bases de données managées) doivent être intégrés, quel que soit le modèle.
Il est recommandé de réaliser un capacity planning et un test de charge (benchmark) sur un environnement de préproduction pour comparer le coût réel d’une architecture containers vs serverless chez un même fournisseur.
Conformité, RGPD et réglementation européenne
En Europe, l’hébergement de données et d’applications web doit prendre en compte plusieurs textes réglementaires, en particulier pour les données personnelles :
- Règlement (UE) 2016/679 – RGPD (Règlement Général sur la Protection des Données), applicable depuis le 25 mai 2018.
- Directive (UE) 2016/680 pour le traitement des données par les autorités compétentes.
- Règlement (UE) 2022/868 – Data Governance Act, applicable depuis 2023, encadrant le partage des données.
- Règlement (UE) 2023/2854 – Data Act, entré en vigueur en 2024 et progressivement applicable, qui impose notamment des règles sur la portabilité des données et la limitation du verrouillage (vendor lock-in) dans le cloud.
- Directive (UE) 2022/2555 – NIS2, concernant la cybersécurité des entités importantes et essentielles, en cours de transposition dans les États membres.
Ces textes ne distinguent pas directement containers et serverless, mais ils impactent le choix de l’infrastructure :
- Localisation des données : vérifier que le fournisseur propose une zone d’hébergement dans l’Union européenne, voire dans un pays spécifique (France, Allemagne, etc.).
- Transferts hors UE : conformément au RGPD (articles 44 à 50), l’hébergement sur des plateformes serverless ou des clusters de containers opérés par des fournisseurs soumis au droit d’un pays tiers (par ex. Cloud Act américain) nécessite des garanties supplémentaires (clauses contractuelles types, analyse de risques, chiffrement fort).
- Réversibilité et portabilité : le Data Act met l’accent sur la capacité de changer de fournisseur cloud. L’utilisation de technologies standardisées comme Docker, Kubernetes ou des runtimes serverless open source (OpenFaaS, Knative, Apache OpenWhisk) peut faciliter cette portabilité.
Quel que soit le modèle choisi, il est essentiel de formaliser les responsabilités dans un contrat de sous-traitance conforme à l’article 28 du RGPD lorsqu’un fournisseur cloud traite des données personnelles pour le compte d’un responsable de traitement.
Scalabilité et résilience : quelles garanties pour 2026 ?
La capacité à absorber la charge et à rester disponible en cas de panne est centrale pour tout projet d’hébergement web.
Avec des containers :
- Kubernetes permet l’autoscaling horizontal (ajout de pods) et vertical (ajustement des ressources) en fonction de métriques (CPU, RAM, requêtes).
- Les déploiements peuvent être gérés en rolling update, canary release, blue/green déploiement.
- La résilience dépend du design du cluster (zones de disponibilité, multi-région, multi-cloud).
Avec le serverless :
- La montée en charge est automatique, gérée par le fournisseur cloud sans intervention.
- Les fonctions sont répliquées sur plusieurs instances en fonction du nombre de requêtes entrantes.
- La résilience s’appuie sur l’infrastructure globale du fournisseur, avec souvent des SLA élevés, mais une moindre maîtrise de la configuration fine.
En 2026, pour des architectures distribuées exigeant des garanties élevées de disponibilité (SLA contractualisé, exigences NIS2), beaucoup d’organisations optent pour un modèle hybride : noyau applicatif en containers (cluster maîtrisé), fonctions serverless pour des tâches ponctuelles (webhooks, traitements asynchrones, batch).
Complexité opérationnelle et compétences nécessaires
Le choix entre containers et serverless dépend également des compétences de votre équipe et de votre stratégie de gestion de l’infrastructure.
Les containers impliquent :
- Des compétences en DevOps, en CI/CD, en sécurité des images Docker et des registres.
- La gestion de l’orchestrateur (Kubernetes ou autre) : mises à jour, monitoring, observabilité (Prometheus, Grafana, OpenTelemetry), réseau (CNI), stockage persistant.
- Une responsabilité accrue sur la sécurité du cluster, en particulier pour se conformer aux bonnes pratiques de l’ENISA (Agence de l’Union européenne pour la cybersécurité) et aux exigences NIS2.
Le serverless offre :
- Une réduction de la charge opérationnelle : pas de serveur ni de cluster à administrer.
- Une approche “code centric” : focus sur le développement des fonctions et des API.
- Des risques de dépendance forte à un fournisseur (vendor lock-in) via des services propriétaires (événements, IAM, bases de données managées spécifiques).
Pour des équipes réduites ou des projets en phase de démarrage, le serverless peut accélérer fortement la mise sur le marché. Pour des organisations matures, avec une équipe d’infrastructure dédiée, les containers offrent une maîtrise et une standardisation plus grandes, notamment dans une logique multi-cloud ou cloud souverain.
Cas d’usage : dans quels scénarios choisir containers ou serverless ?
Voici quelques scénarios typiques pour orienter votre choix en 2026 :
- Application SaaS B2B avec SLA strict : stack microservices en containers sur un cluster Kubernetes, base de données managée, éventuellement complétée par des fonctions serverless pour le traitement asynchrone (envoi d’e-mails, génération de rapports).
- Site web événementiel ou campagne marketing : front-end statique hébergé sur un stockage objet + CDN, back-end API en serverless pour limiter les coûts hors période de campagne.
- Plateforme e-commerce avec pics de charge : cœur applicatif en containers pour maîtriser les performances, certaines tâches spécifiques en serverless (traitement d’images, notifications, intégration avec des services tiers).
- Prototype, MVP ou projet innovant : architecture majoritairement serverless pour réduire le coût initial et le temps de mise en production, avec la possibilité de migrer vers des containers si la charge augmente.
- Environnement fortement régulé et souveraineté : containers sur un cloud européen conforme au RGPD, complétés éventuellement par un serverless open source auto-hébergé (OpenFaaS, Knative) pour garder un contrôle maximal.
Comment choisir un fournisseur en 2026 : critères clés
Pour trancher entre containers et serverless, et sélectionner un fournisseur d’hébergement web adapté, plusieurs critères doivent être étudiés :
- Localisation et juridiction : data centers en Union européenne, conformité aux textes européens cités (RGPD, Data Governance Act, Data Act, NIS2).
- Technologies supportées : support natif de Docker, Kubernetes managé, fonctions serverless, runtimes supportés (Node.js, Python, PHP, Java, .NET, Go, etc.).
- Portabilité : possibilité d’exporter vos images, vos configurations YAML, vos fonctions, existence d’API standardisées, respect des obligations de portabilité du Data Act.
- Transparence des coûts : simulateurs de coût, détail de la facturation, limites gratuites éventuelles (free tier), politique sur les coûts de sortie (egress).
- Sécurité et certifications : ISO 27001, ISO 27701, rapports d’audit, certifications de cybersécurité nationales ou européennes (ex. SecNumCloud pour la France).
En combinant ces critères avec l’analyse de votre usage réel (trafic, saisonnalité, criticité, exigences légales), vous pourrez déterminer si une architecture orientée containers, orientée serverless ou hybride est la plus adaptée à vos besoins d’hébergement d’applications web en 2026.