L'écureuil volant : quand le CMS Spip devient serverless

Au commencement..

Le Web français était informe et vide.. quelques sites (universitaires notamment), reliés aux autres par des liens et référencées par des annuaires.

1996 : les premiers services d'hébergement web, Mygale, puis Chez.com. « Il y eut un soir, il y eu un matin. Premier jour »

1999 : Adolescent, j'apprends alors PHP. « Il y eut un soir, il y eu un matin. Deuxième jour »

2000 : Les premiers CMS donnent aux non-développeurs la possibilité de devenir éditeurs. Drupal, puis Spip. Et les bases de données MySQL. Pas trop de contenu à publier de mon côté, mais je lis beaucoup. Je vois des sites (beaucoup militants de gauche comme uZine, rezo.net..) se saisir de l'outil. « Il y eut un soir, il y eu un matin. Troisième jour »

2003 : Wordpress et Dotclear. Tellement facile d'écrire sans développer ; je laisse de côté un temps le dev. « Il y eut un soir, il y eu un matin. Quatrième jour »

2016 : grâce à des précurseurs, je découvre le cloud. Je suis bluffé par la capacité d'AWS de mobiliser de l'infra à la demande, et la possibilité pour moi de proposer des applications hautement disponibles et scalables. « Il y eut un soir, il y eu un matin... »

Et soudain.

Mai 2026, un coup de fil. « Paul, je veux développer une app. Mais j'ai une exigence non-négociable : le backend doit s'appuyer sur SPIP. »

Comme souvent sur les projets que j'accompagne : pas de compétence infra disponible. Et l'ambition de proposer une application grand public (bientôt plus d'info là-dessus).

Le CMS étant imposé, comment

• le faire tourner sans payer 24h/24 (y compris à 3h du matin quand il n'y a pas un seul visiteur ?)
• sans maintenir de serveurs
• en suivant la charge quand notre appli va cartonner ?

Le serverless, bien sûr. Reste à savoir si ça allait marcher.

Le 6e jour, Paul créa SPIP-serverless

Je découvre SPIP, CMS libre français, écrit en PHP et maintenu par sa communauté depuis 26 ans. L'architecture du projet n'est pas moderne, moderne.. et surtout, il est conçu pour être simple d'administration, pour des non-tech, pour être déployé en mode mono-machine et non dans un environnement de calculé distribué pour de la haute dispo : pas de gestion de session dans un cache partagé, upgrade "in-place", etc.

Avec son besoin d'un disque local persistant et d'une base de données toujours allumée, ça n'en faisait pas le candidat naturel pour le serverless.

Et pourtant, je suis fier de vous annoncer aujourd'hui spip-serverless, un port de Spip sur une architecture 100% serverless. Vous pouvez ranger votre hébergement mutu :)

Le projet est disponible sur Github, en licence MIT. Et vous pouvez le voir en action sur ce site de démo. Il se passera sans doute de longs mois avant que ce site me coûte un seul euro en hébergement.

Spip-serverless, comment ça fonctionne ? Les principaux choix d'architecture

Voici quelques-uns des partis pris pour faire Spip-serverless :

• Le calcul est hébergé sur le service de Function-as-a-Service AWS Lambda. Faire tourner PHP là-dedans est possible grâce à Bref, qui donne à PHP un vrai runtime Lambda (FPM). (Pour comprendre en détail comment PHP s'intègre au serverless AWS, j'ai écrit une série qui commence ici : How to run PHP on AWS serverless).
• Les sessions ne vivent pas sur le disque local : elles vont dans DynamoDB (à la demande).
• Les médias uploadés ne vivent pas sur le disque local : ils vont sur S3 (upload présigné direct depuis le navigateur, stream wrapper, et un petit patch pour que SPIP lise et écrive ses médias sur S3).
• Un CDN CloudFront permet de mettre en cache les contenus pour les servir sans nécessairement que le code de Spip tourne pour chaque requête.
• Les clés secrètes sont générées une fois et rangées dans SSM Parameter Store, puis réinjectées au démarrage pour que chaque environnement partage les mêmes clés.

Mais la base de données ? Une base relationnelle, ça coûte un bras !

La brique qui rend le pay-as-you-go réel, c'est Aurora DSQL, un Postgres serverless facturé à l'usage.

Un CMS SQL impose normalement une base toujours allumée, donc un plancher de coût fixe ; DSQL fait disparaître ce plancher, et les connexions utilisent des jetons IAM éphémères (aucun mot de passe stocké).

Spip s'appuyant habituellement sur MySQL, mais avec une couche d'abstraction (j'appelle pas ça un ORM ^^), j'ai dû un peu bricoler pour qu'Aurora DSQL fonctionne. Heureusement, la communauté avait déjà fait un portage expérimental vers Postgresql.

Avec Lambda et API Gateway à la requête, DynamoDB à la demande, S3 et CloudFront pour la diffusion, un site au repos ne coûte quasiment rien et se réveille à la première requête.

Les compromis du serverless

Le compromis essentiel est dans l'administration de spip : en effet, le serverless repose sur un paradigme d'infra immuable (le conteneur qui exécute le code spip ne peut être modifié au runtime, et, quand bien même, sera détruit et remplacé par un autre quelques minutes après).

• Pour l'éditeur, rien ne change : le contenu s'édite en ligne (base et S3)
• mais les tâches de l'administrateur (édition de squelettes, déploiement de plugins, montées de version) se fait par le code et l'intégration continue.

Versionné, relu, reproductible : un vrai workflow de dev moderne :)

Et le 7e jour, Paul @ TerraCloud se reposa

Le code est open source (MIT) et générique : tu peux déployer ton propre SPIP de la même façon.

• Pour commencer, visitez le dépôt github.com/psantus/spip-serverless
• et parcourez mon site de démo

Quant à moi, je ne vais pas complètement me reposer :

• Déjà je vais compter vos étoiles sur le repo
• Ensuite, je compte maintenir et améliorer ce projet en fonction des besoins réels :
  • S'il manque quelque chose pour votre cas d'usage, ouvrez une issue et discutons-en.
  • Si vous souhaitez un coup de main pour développer, déployer votre propre projet à base de spip, contactez moi sur terracloud.fr ou via LinkedIn!