Pourquoi ton projet Drupal ou Django plante sans cesse en environnement de test (et comment y remédier de manière structurelle)

Au-delà de l'hébergement : passer de la gestion des frameworks à la mise à disposition d'applications

Il y a un genre d’après-midi que la plupart des développeurs backend connaissent bien. Tu es en plein développement de fonctionnalités, quelque chose de vraiment intéressant, le genre de travail pour lequel tu as accepté ce poste, et là, tu reçois un message sur Slack. L’environnement de staging est en panne. La version PHP ne correspond pas à celle de production. L’installation de Composer de quelqu’un a récupéré une dépendance qui entre en conflit avec l’environnement partagé. Tu peux jeter un œil ?

Quatre heures plus tard, tu n’as pas touché à une seule chose de ce que tu avais prévu de faire ce jour-là et tu as passé tout ton temps à réparer ton pipeline CI/CD.

C’est la conséquence prévisible de traiter une plateforme comme un simple compte d’hébergement, pas de la malchance.

Ce que t’en coûte réellement le « simple hébergement »

Point clé : le coût de la dérive des environnements se mesure moins en heures par incident qu’en perte de concentration : ce travail en profondeur qui coûte cher à relancer à chaque fois qu’un message Slack vient t’en arracher.

La plupart des développeurs ne se considèrent pas comme des gestionnaires d’infrastructure, mais la configuration typique d’un projet open source leur demande de l’être quand même. Tu gères un environnement de préproduction partagé, tu spécifies manuellement les versions d’exécution dans les configurations de déploiement, tu connectes les services de base de données et tu gères régulièrement les conséquences quand quelque chose dérive d’un environnement à l’autre.

Rien de tout ça ne fait partie du boulot. C’est l’échafaudage autour du boulot.

Le problème de cette infrastructure s’aggrave à mesure que les stacks deviennent plus complexes. Un site Drupal avec Redis pour la mise en cache et MariaDB en arrière-plan n’est pas compliqué à faire tourner une fois configuré, mais parvenir à une configuration propre et reproductible demande un réel effort, et la synchroniser entre les environnements local, de préproduction et de production nécessite une vigilance constante. Ajoute un deuxième développeur et les choses se compliquent. Un troisième, et tu auras probablement des conflits d’environnement à l’ordre du jour de façon récurrente.

Le coût caché, c’est le rythme des interruptions, pas le temps que prend chaque incident en soi. Changer de contexte quand on est en plein travail concentré coûte disproportionnellement cher à cause de ce que ça perturbe : ce genre de travail en profondeur qui prend environ 20 minutes pour s’y replonger. Multiplie ça par toute une équipe sur un trimestre, et le coût ne se résume plus à une pile de tickets d’assistance, mais se traduit par des fonctionnalités qui sortent plus lentement, parce que les personnes qui les développent sont sans cesse interrompues.

La solution « infrastructure as code » que la plupart des équipes n’osent pas aller jusqu’au bout

Point clé : la plupart des implémentations d’IaC s’arrêtent au provisionnement. Tu obtiens un environnement reproductible, mais les correctifs du système d’exploitation, la rotation des certificats et les mises à jour des services restent à la charge de l’équipe. La version complète de cette idée, c’est une plateforme qui prend en charge tout ce qui se trouve en dessous de la couche applicative, pas seulement lors de la configuration, mais de manière continue.

Le conseil classique ici, c’est « l’infrastructure en tant que code » : définis ton environnement de manière déclarative, enregistre-le dans un système de contrôle de version, et ne laisse plus la configuration dériver. C’est vrai, dans une certaine mesure. Le problème, c’est que la plupart des implémentations s’arrêtent au provisionnement. Tu obtiens un environnement reproductible, mais tu restes responsable des services sous-jacents : appliquer les correctifs au système d’exploitation, faire tourner les certificats, gérer les versions des bases de données.

Tu as réduit les dérives. Tu n’as pas réduit la maintenance.

La version plus complète de cette idée, c’est un fichier de configuration qui décrit ce dont ton application a besoin, et une plateforme qui prend en charge tout ce qui se trouve en dessous de cette ligne, pas seulement au moment de la mise en place, mais de manière continue.

L’approche d’Upsun consiste en un fichier de configuration unique disponible sur .upsun/config.yaml. Pour un projet Drupal avec Redis et MariaDB, ça ressemble à peu près à ça :

applications:
  drupal:
    type: php:8.3                  # exact runtime version, consistent across every environment
    relationships:
      database: "db:mysql"         # wires the app to the database service below
      cache: "redis:redis"         # wires the app to the Redis service below
    mounts:
      "/web/sites/default/files":
        source: local
        source_path: files

services:
  db:
    type: mariadb:10.11            # platform manages patching within this version
  redis:
    type: redis:7.2                # same: version pinned, maintenance handled

C’est toute la stack. La version d’exécution, les services, les relations entre eux. La plateforme gère les correctifs du système d’exploitation, la rotation des certificats SSL, les mises à jour des services dans les limites des versions définies, ainsi que la communication réseau entre les conteneurs. Tu n’as rien à faire de tout ça, ni lors de la configuration, ni par la suite.

La version de PHP indiquée dans la configuration est la version de PHP utilisée en production. Pas « à peu près ». Pas « on pense que c’est ça ». Exactement.

La même structure de fichier s’applique à un projet Django sous Python. Runtime différent, base de données différente, structure identique :

applications:
  django:
    type: python:3.12              # exact runtime version, consistent across every environment
    relationships:
      database: "db:postgresql"    # wires the app to the PostgreSQL service below
      cache: "redis:redis"         # wires the app to the Redis service below
    mounts:
      "/app/media":
        source: local
        source_path: media

services:
  db:
    type: postgresql:16            # platform manages patching within this version
  redis:
    type: redis:7.2                # same: version pinned, maintenance handled

même fichier unique, même répartition des tâches. Le runtime et les services changent en fonction du stack ; ce que la plateforme te décharge de faire, ça ne change pas.

Pourquoi c’est encore plus important pour les frameworks open source

Point clé : les frameworks open source sont flexibles par conception, ce qui signifie que les décisions de déploiement incombent par défaut à l’équipe. Un fichier de configuration sous contrôle de version rend ces décisions explicites et traçables, de sorte que la question « qu’est-ce qui tourne en production ? » trouve une réponse sans qu’il soit nécessaire de se connecter via SSH à quoi que ce soit.

Les produits SaaS propriétaires ont tendance à imposer leur propre mode de déploiement. Les frameworks open source sont, par nature, flexibles, ce qui signifie que les décisions de déploiement t’incombent.

Cette flexibilité est avant tout une fonctionnalité. C’est pourquoi Drupal fonctionne aussi bien sur un hébergement mutualisé que dans des infrastructures gouvernementales hautement sécurisées. C’est pourquoi Django alimente à la fois des start-ups et de grandes institutions financières. Mais ça signifie aussi qu’il n’y a pas de réponse toute faite à la question « comment ça doit être déployé ? », ce qui veut dire que chaque équipe prend ces décisions à partir de zéro et en assume ensuite les conséquences.

Le problème le plus courant ici, c’est le pragmatisme accumulé, pas l’incompétence. Tu prends une décision raisonnable au début : un serveur de préproduction mutualisé, un script de déploiement manuel, une tâche cron qui fonctionne, puis tu te retrouves coincé avec ça pour toujours. Cette décision avait du sens quand il n’y avait qu’un développeur et un site. Mais quand on en est à cinq développeurs et six sites, ça devient une dette technique sans date de remboursement en vue.

Un fichier de configuration sous contrôle de version n’élimine pas ces décisions, mais il les met en évidence. De quel runtime as-tu réellement besoin ? Quels services ? Quand ces éléments sont explicites et enregistrés dans le contrôle de version, la question « qu’est-ce qui tourne en production ? » trouve une réponse sans qu’il soit nécessaire de se connecter via SSH à quoi que ce soit.

Rendre la couche d’infrastructure « ennuyeuse »

Point clé : l’objectif ici, c’est une infrastructure qui ne demande plus d’attention, pas des outils plus puissants. Quand la plateforme gère le travail de routine, il ne reste plus que l’application.

Le but ici, c’est d’avoir une infrastructure qui ne demande plus d’attention.

Beaucoup d’outils de développement visent à rendre l’infrastructure plus puissante ou plus configurable. C’est parfois ce dont tu as besoin. Mais le plus souvent, tu as besoin de quelque chose qui gère le travail de routine sans que tu aies à y penser, et qui se fait discret quand tu débogues quelque chose au niveau de la couche applicative, et non de la couche plateforme.

Quand l’environnement est défini dans le code, reproductible d’une branche à l’autre, et géré par la plateforme plutôt que par l’équipe, les problèmes du genre « le staging ne marche plus » disparaissent presque tous. Il ne reste plus que l’application. Et c’est bien ça, après tout, ce que tu es là pour créer.

Tu as déjà une configuration en place ?

Le fichier de configuration décrit un état cible, pas un chemin de migration. Si tu fais tourner Drupal sur un serveur géré avec un script de déploiement que tu entretiens depuis trois ans, passer à une configuration de plateforme revient simplement à noter ce que tu fais déjà tourner : la version de PHP, les services, les relations entre eux. La configuration devient alors la source de vérité pour une configuration qui, pour l’instant, n’existe que dans ta tête et dans un README obsolète depuis six mois.

Foire aux questions (FAQ)

Est-ce que je contrôle toujours ma version de PHP ou de Python ?

Oui. Tu précises la version exacte dans `.upsun/config.yaml`. La plateforme garantit la cohérence de cette version sur toutes les branches et tous les environnements, et gère les correctifs de sécurité en son sein. Tu ne cèdes pas le contrôle ; tu prends la décision une seule fois et elle est appliquée partout.

Qu’en est-il du système d’exploitation sous-jacent et des certificats ?

La plateforme gère automatiquement le renforcement de la sécurité du système d’exploitation, l’application des correctifs du noyau et la rotation des certificats SSL. Ce ne sont pas des éléments que tu configures ; ils sont gérés en aval de la ligne définie dans ton fichier de configuration.

Est-ce que ça fonctionne avec des stacks découplées ou « headless » ?

Oui. Tu peux définir plusieurs applications dans un seul fichier de configuration (un frontend Next.js et un backend Drupal, par exemple) et la plateforme gère la mise en réseau et l’isolation entre elles. Pas besoin de comptes cloud séparés ni de configuration réseau manuelle.

Pourquoi mon script de déploiement actuel ne couvre-t-il pas ça ?

Les scripts gèrent ce que tu as déjà prévu. Le vide de maintenance qu’ils laissent concerne tout le reste : les dérives de version lors de l’exécution, l’expiration des certificats, la compatibilité des services entre les environnements. Un fichier de configuration géré par la plateforme couvre le travail continu, pas seulement la configuration initiale.

Qu’est-ce que « la plateforme s’en charge » signifie concrètement au quotidien ?

En pratique : tu mets à jour le fichier de configuration quand tu veux changer quelque chose. La plateforme applique ce changement de manière cohérente. Entre deux modifications, elle gère les correctifs et les mises à jour sans que l’équipe ait à intervenir. La surface opérationnelle se réduit à l’application elle-même.