« WordPress en serverless » revient régulièrement dans les discussions d’architecture, porté par la promesse de ne payer que pour les requêtes réellement traitées, sans serveur à maintenir en permanence. La réalité, testée sur un projet pilote chez un client dont le trafic était très irrégulier, se révèle nettement plus contraignante que l’idée de départ. Ce bref recense les points qui ont vraiment posé problème.
Le principe technique repose sur un adaptateur, le plus connu étant projet communautaire d’exécution PHP sur Lambda combiné à une couche comme Bref, qui embarque un runtime PHP dans une fonction AWS Lambda et route les requêtes HTTP via API Gateway ou une Function URL. WordPress s’exécute alors comme n’importe quelle application PHP, à ceci près que l’environnement d’exécution disparaît entre deux requêtes.
Le système de fichiers, premier obstacle
WordPress a été conçu pour un système de fichiers persistant et modifiable : le noyau écrit des fichiers de configuration, les extensions déposent des caches sur disque, les médias uploadés atterrissent dans wp-content/uploads. Sur Lambda, le système de fichiers de la fonction est en lecture seule, à l’exception du répertoire /tmp, limité en taille et vidé entre deux invocations froides.
Concrètement, cela impose de rediriger systématiquement toute écriture : les médias doivent partir directement vers un bucket S3 via une extension comme WP Offload Media, les caches d’objets doivent viser un service externe comme ElastiCache plutôt qu’un cache disque, et toute extension qui écrit en dur dans wp-content, par exemple pour générer des miniatures ou des fichiers de traduction compilés, doit être auditée une par une avant d’être acceptée sur ce type d’hébergement.
Le cold start, une latence qu’on ne maîtrise pas totalement
Une fonction Lambda qui n’a pas été invoquée récemment doit être réamorcée : le runtime PHP démarre, WordPress charge son cœur et ses extensions, avant de traiter la première requête. Sur les tests réalisés avec une fonction dimensionnée à 512 Mo de mémoire, ce cold start a ajouté environ 800 millisecondes de latence au premier appel, contre quelques dizaines de millisecondes pour les appels suivants tant que la fonction reste « chaude ».
Ce comportement pose un vrai problème pour un site à trafic irrégulier avec de longues périodes creuses : chaque pic de visite après une accalmie déclenche potentiellement plusieurs cold starts simultanés, le temps qu’AWS provisionne suffisamment d’instances de la fonction pour absorber la charge. Une option de « provisioned concurrency » permet de garder un nombre minimal d’instances toujours chaudes, au prix d’un coût fixe qui annule une partie de l’intérêt économique du serverless.
La base de données, un problème à part entière
Une fonction Lambda ne peut pas héberger MySQL ou MariaDB localement de façon persistante. La base de données doit résider ailleurs, typiquement sur Amazon RDS ou Aurora Serverless. Cette dernière option, qui met elle aussi la base en pause en l’absence de trafic, ajoute son propre temps de réamorçage, qui peut se cumuler avec le cold start de la fonction PHP elle-même dans le pire des cas.
Le nombre de connexions simultanées pose également question : chaque instance Lambda ouvre potentiellement sa propre connexion à la base, et un pic de trafic peut multiplier les instances plus vite que la base ne peut absorber de connexions. Un proxy comme Amazon RDS Proxy devient alors nécessaire pour mutualiser les connexions, une brique supplémentaire à surveiller et à budgétiser.
Ce qui fonctionne malgré tout
Sur le projet pilote, un site vitrine à faible trafic avec des pics ponctuels liés à des campagnes publicitaires, l’architecture a tenu la charge une fois le cache d’objets externalisé et les médias déportés sur S3. Le coût mensuel est resté inférieur à celui d’un VPS équivalent, principalement parce que le site restait inactif la majeure partie du mois.
Tableau des contraintes observées
| Contrainte | Impact | Contournement |
|---|---|---|
| Système de fichiers en lecture seule | Élevé | Offload Media vers S3, cache objet externe |
| Cold start | Moyen à élevé selon le trafic | Concurrence provisionnée (coût fixe) |
| Connexions base de données | Élevé sous forte charge | RDS Proxy |
| Extensions non auditées | Variable, parfois bloquant | Test unitaire avant adoption |
Pour quel profil de site cela a-t-il un sens
Un site institutionnel à trafic très faible et irrégulier, où le coût d’un VPS permanent semble disproportionné par rapport à l’usage réel, reste le candidat le plus crédible. Un site e-commerce à trafic soutenu, ou un site avec des extensions écrivant abondamment sur disque, n’est simplement pas adapté à cette architecture sans un travail d’adaptation conséquent.
Le serverless ne rend pas WordPress plus simple à exploiter, il déplace la complexité vers des couches que l’équipe ne maîtrisait pas forcément avant : stockage objet, proxy de connexions, gestion fine du cold start.
Notre verdict
WordPress sur AWS Lambda fonctionne, mais seulement pour un profil de site précis, et au prix d’une architecture nettement plus complexe qu’un hébergement traditionnel. Cette solution ne concurrence pas les VPS classiques ni les orchestrateurs de conteneurs pour un usage général : elle répond à un besoin de niche, celui d’un trafic extrêmement irrégulier où payer pour un serveur qui dort la majeure partie du temps n’a pas de sens économique.
