PaaS
PaaS (Platform as a Service) : modèle de cloud dans lequel le fournisseur gère l'infrastructure, le système d'exploitation et le runtime — le développeur fournit uniquement son code et sa configuration applicative, déployée à partir d'un dépôt Git.
Le PaaS (Platform as a Service) est un modèle de service cloud dans lequel le fournisseur prend en charge non seulement l'infrastructure matérielle (serveurs, réseau, stockage) mais aussi la plateforme logicielle d'exécution : système d'exploitation, runtime du langage (PHP, Node, Python, Go), serveurs web, outils de déploiement. Le client apporte uniquement son code source et un fichier de configuration applicative — typiquement versionné dans un dépôt Git — et la plateforme se charge de tout le reste : build, déploiement, certificats TLS, mise à l'échelle, sauvegardes, rollbacks.
Définition technique
Ce que le PaaS gère, et ce qu'il ne gère pas
Sur un PaaS, le périmètre de responsabilité du provider couvre : le provisionnement des machines, le renouvellement des certificats TLS, les patchs système, la configuration du serveur web, le runtime PHP ou Node, les services managés (base de données, cache Redis, moteur de recherche), la mise à l'échelle automatique, les sauvegardes, et le monitoring d'infrastructure. Le client reste responsable de : la logique applicative, les tests, la sécurité applicative, les requêtes métier vers la base de données, la gestion de ses utilisateurs. C'est le compromis central : plus de productivité, moins de contrôle fin.
Le rôle central du fichier de configuration
Chaque PaaS moderne repose sur un fichier de configuration versionné qui décrit l'application : ses services, ses variables d'environnement, ses routes, ses hooks de build et de déploiement. Sur Upsun c'est .upsun/config.yaml. Sur Fly.io c'est fly.toml. Sur Heroku c'est app.json et le Procfile. Sur Vercel c'est vercel.json. Ces fichiers sont le contrat entre le code et la plateforme : ils décrivent l'état cible de l'application, et la plateforme converge vers cet état à chaque push.
Ce modèle est une application directe de l'Infrastructure as Code : la configuration infrastructure est versionnée avec le code applicatif, reviewée en pull request, et rejouable à l'identique sur n'importe quel environnement.
Enjeux actuels
Le bénéfice principal : l'effet levier d'une petite équipe
Le PaaS est particulièrement adapté aux petites équipes ou aux projets qui ne peuvent pas s'offrir un ingénieur DevOps à plein temps. Une seule personne peut déployer une application en production, gérer plusieurs environnements, mettre en place des pipelines CI/CD, et monitorer ses services — choses qui demanderaient plusieurs jours de setup sur une stack IaaS classique. Le time to market est drastiquement réduit.
Les limites : coût à l'échelle et lock-in
Le PaaS a deux limites structurelles. D'abord le coût : à capacité équivalente, un PaaS est 2 à 5 fois plus cher qu'un serveur dédié ou qu'une stack IaaS gérée en interne. Pour une application à fort trafic, le calcul économique finit par pencher vers l'auto-gestion. Ensuite le lock-in : chaque PaaS a sa propre configuration, ses propres services managés, ses propres idiosyncrasies. Migrer d'un PaaS à un autre demande un travail de reconfiguration non trivial, et certaines fonctionnalités avancées (CDN intégré, build hooks propriétaires) ne sont pas portables.
PaaS et sécurité
L'un des bénéfices moins souvent cités du PaaS, c'est son impact sur la posture de sécurité. Les patchs système sont appliqués automatiquement par le provider, les certificats TLS sont renouvelés sans intervention, le filesystem immuable supprime des vecteurs d'attaque entiers (upload de webshell, modification de code par un attaquant), et la configuration d'infrastructure est versionnée dans Git — donc auditable et reviewable. Une équipe qui ne peut pas se payer un SOC gagne énormément de sécurité "gratuite" en passant sur un PaaS moderne.
Applications pratiques
J'utilise un PaaS (Upsun, l'ancien Platform.sh) comme terrain d'expérimentation pour sécuriser un WordPress sans plugins, en m'appuyant sur les capacités natives de la plateforme : filesystem immuable, configuration YAML versionnée, hooks de build et de post-deploy, gestion des variables sensibles, routage intelligent. Le détail est dans mon article sur la sécurisation de WordPress via Infrastructure as Code.
Questions fréquentes
Quelle différence entre IaaS, PaaS et SaaS ?
IaaS (Infrastructure as a Service) : le provider fournit des machines virtuelles, du stockage et du réseau ; le client gère tout le reste (OS, patchs, runtime, app). Exemples : AWS EC2, Google Compute Engine, OVH VPS. PaaS (Platform as a Service) : le provider gère aussi l'OS et le runtime (PHP, Node, Python) ; le client fournit uniquement son code et sa configuration. Exemples : Heroku, Upsun, Fly.io, Vercel, Render. SaaS (Software as a Service) : le provider fournit une application finie utilisable par abonnement ; le client ne gère rien. Exemples : Gmail, Salesforce, Notion.
Pourquoi choisir un PaaS plutôt qu'un hébergement traditionnel ?
Le PaaS élimine une grande partie du travail d'opérations : pas de patch système à appliquer, pas de configuration Nginx à maintenir manuellement, pas de certificat TLS à renouveler, pas de mise à l'échelle manuelle. Le déploiement se fait par git push, les rollbacks en une commande, les environnements de staging sont provisionnés automatiquement sur chaque branche. Le contre-coût, c'est une tarification plus élevée qu'un serveur dédié à capacité équivalente, et une dépendance à l'écosystème du provider (lock-in).
Qu'est-ce qu'un filesystem immuable et pourquoi la plupart des PaaS l'imposent ?
Sur un PaaS moderne, le code applicatif est figé dans une image (souvent un container Docker) construite au moment du déploiement. Cette image est ensuite démarrée sur une ou plusieurs machines, mais son contenu ne peut plus être modifié. On dit que le filesystem est immuable. Toute donnée qui doit persister (uploads, cache, sessions) doit aller dans un volume monté séparément, dans une base de données ou dans un service externe (Redis, S3). Cette contrainte rend les déploiements reproductibles, les rollbacks fiables et supprime toute une catégorie d'attaques (upload de webshell, modification de code en production).