docker run --rm <image> php -r "var_dump(require '.env.local.php');"

La sortie montrait tout ce que composer dump-env prod avait compilé dans l’image au moment du build. Ce qui voulait dire tout ce qui se trouvait dans le fichier .env quand l’image avait été construite. Ce qui voulait dire, entre autres, ça :

INFLUXDB_INIT_ADMIN_TOKEN=<influxdb-admin-token>
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=admin123
BLACKFIRE_CLIENT_ID=<blackfire-client-id>
BLACKFIRE_CLIENT_TOKEN=<blackfire-client-token>
BLACKFIRE_SERVER_ID=<blackfire-server-id>
BLACKFIRE_SERVER_TOKEN=<blackfire-server-token>
NGROK_AUTHTOKEN=replace-me-optionnal

Vingt-cinq variables au total. Chaque credential accumulé dans le .env racine sur trois ans, désormais permanent dans un layer d’image.

Comment dump-env fonctionne

composer dump-env prod est une optimisation Symfony légitime. Au lieu de parser les fichiers .env à chaque requête, le runtime charge un tableau PHP pré-compilé depuis .env.local.php. Plus rapide et plus simple.

Le problème, c’est ce qu’il lit. Le Dockerfile copie le dépôt dans l’image avec COPY . ./, .env inclus. Ensuite dump-env prod lit ce fichier et compile chaque variable dans .env.local.php. L’image est livrée avec une capture figée des credentials qui se trouvaient dans .env au moment du build.

Les layers Docker sont des archives immuables. Même si une étape ultérieure supprimait .env du système de fichiers du container, le layer qui le contient existerait toujours dans l’image. docker save <image> produit une archive tar de chaque layer ; extraire un fichier spécifique de n’importe quel point de l’historique de build est une opération simple. Les credentials sont invisibles à l’exécution. Ils ne sont pas partis.

Le Facteur V est explicite là-dessus : un artefact de build doit être agnostique à l’environnement, la config arrivant à l’étape de release depuis l’extérieur. Dès que des credentials sont compilés dedans, l’image n’est plus portable. On ne peut plus la promouvoir entre environnements. On builde deux fois en espérant que le deuxième se comporte comme le premier.

Comment vingt-cinq variables s’accumulent

Avant de voir comment on a réparé ça, il vaut la peine de comprendre comment on en est arrivé là.

Les tokens BLACKFIRE_* sont le cas facile à comprendre. Un membre de l’équipe configure le profiling, a besoin de partager la configuration, et le dépôt est déjà ouvert à tout le monde. Une ligne dans .env est la voie de moindre résistance. Les credentials InfluxDB et Grafana suivent la même logique — outillage partagé, dépôt partagé, un commit.

Puis il y a les variables qui révèlent une autre dérive. Dans certains .env de services :

APP__RATINGS__SERIALS='{"marque1":{"fr":"12345"},...}'  # ~40 lignes de JSON
APP__YOUTUBE__CREDENTIALS='{"marque1":{"client_id":"xxx","refresh_token":"yyy"},...}'

Des numéros de série pour la mesure d’audience. Des refresh tokens YouTube par marque. Ce ne sont pas des secrets au sens des tokens Blackfire. Ce sont des données métier — le genre de valeurs qui varient entre marques et environnements, que quelqu’un a décidé de versionner dans .env parce qu’elles se comportaient comme de la configuration et que .env était l’endroit où vivait la configuration.

Vingt-cinq variables, c’est la somme de décisions incrémentales, dont aucune ne semblait fausse isolément. Le problème est structurel : quand .env est la seule réponse disponible, tout finit par y ressembler.

Où les choses appartiennent vraiment

Vider le fichier exigeait de répondre à une question pour chaque variable : où est-ce que ça appartient vraiment ?

Les réponses ont révélé trois catégories que l’équipe n’avait jamais explicitement nommées :

La config statique vit dans le code. Règles métier, logique de routing, fichiers de paramètres Symfony — tout ce qui ne varie pas entre les déploiements. Un changement exige un rebuild. Les blocs JSON de numéros de série se sont révélés ne pas être de la config statique du tout : ils étaient interrogés depuis un service Config dédié à l’exécution. Ils n’avaient rien à faire dans un fichier.

La config environnementale varie entre les déploiements : hostnames, chaînes de connexion, credentials de services tiers. C’est ce que le Facteur III désigne par “config dans les variables d’environnement” — de vraies variables au niveau OS, injectées à l’exécution, jamais des fichiers qui voyagent avec le code. Dans Kubernetes, c’est un ConfigMap pour les valeurs non sensibles et un Kubernetes Secret pour les credentials. Le choix retenu pour les secrets a été SOPS — les credentials sont chiffrés et committés dans git, plutôt que stockés dans un coffre-fort externe comme Azure Key Vault ou HashiCorp Vault. Un coffre-fort échange la simplicité contre l’auditabilité : rotation automatique, logs d’audit centralisés, accès via workload identity sans clé à protéger. SOPS échange ces capacités contre un modèle opérationnel plus simple — pas de service externe à interroger au déploiement, les secrets transitent par le processus de review normal du code, l’historique git fait office de piste d’audit. Les contreparties acceptées sont la rotation manuelle et la responsabilité de protéger la clé de déchiffrement elle-même. Pour la taille de l’équipe, le compromis était délibéré.

La config dynamique change sans déploiement : paramètres éditoriaux, seuils par marque, configuration de modération de contenu. Elle appartient à une base de données, gérée via le service Config de l’application. Une partie de ce qui s’était accumulé dans les .env de services était cette catégorie depuis le début, passant pour des valeurs par défaut statiques parce qu’elle changeait assez rarement pour que personne ne le remarque.

Une fois les catégories nommées, les variables se sont triées. Le .env racine est arrivé à quatre lignes :

DOMAIN=platform.127.0.0.1.sslip.io
XDEBUG_MODE=off
SERVER_NAME=:80
APP_ENV=dev

Des valeurs par défaut sûres. Rien de sensible. dump-env prod compile maintenant des chaînes vides ; les vraies valeurs arrivent à l’exécution depuis Kubernetes.

L’image PostgreSQL

L’image PostgreSQL utilisée en CI a un mot de passe codé en dur :

FROM postgres:15
ENV POSTGRES_PASSWORD=admin123

Ça ressemble au même problème. Ce n’en est pas un, parce que le modèle de menace est différent. La base CI est éphémère — elle existe le temps d’un run de pipeline, ne contient pas de vraies données, tourne dans un réseau isolé. Un mot de passe codé en dur sur une base de test jetable est un risque acceptable, pas une entorse à la règle.

En production, la question ne se pose pas : la plateforme utilise Azure Flexible Server, un service PostgreSQL managé. Il n’y a pas d’image Docker. Les credentials arrivent via injection dans les charts Helm, sans jamais toucher un layer.

Ce qui survit au build maintenant

L’image qui part en production contient maintenant une garantie : var_dump(require '.env.local.php') ne retourne que des chaînes vides et des valeurs par défaut sûres. Les credentials ne sont pas là parce qu’ils n’y ont jamais été mis — ils arrivent à l’exécution, depuis l’extérieur.

C’est la frontière de responsabilité que dump-env avait silencieusement effacée : l’image est l’application, le runtime est l’environnement. Ils ne devraient pas connaître les secrets de l’autre.

Le composant String

La gestion des chaînes en PHP est notoirement éparpillée : des fonctions avec préfixe par-ci (str_), avec suffixe par-là (strpos), un support d’encodage incohérent, et rien d’orienté objet en vue. Le composant String enveloppe tout ça dans une API fluide orientée objet avec support Unicode :

use Symfony\Component\String\UnicodeString;

$str = new UnicodeString('  Hello World  ');
echo $str->trim()->lower()->replace(' ', '-'); // hello-world

L’ajout pratique, c’est le Slugger, un générateur de slug locale-aware qui gère vraiment correctement les caractères accentués :

$slug = $slugger->slug('L\'été à Montréal'); // l-ete-a-montreal

Avant, il fallait intégrer une bibliothèque tierce ou en écrire une soi-même. Maintenant ça ship avec FrameworkBundle, disponible par défaut.

Notifier

Le courrier électronique est géré par Mailer. SMS, notifications push, messages de chat : pas de solution first-party, jusqu’à maintenant. Le composant Notifier en ajoute une : une interface unifiée sur des dizaines de canaux et fournisseurs.

La même notification peut atterrir sur Slack, déclencher un SMS via Twilio, ou finir comme notification push, tout configuré via des DSN. Ajouter un nouveau canal, c’est un changement de config, pas un changement de code.

Le coffre-fort de secrets

Stocker des secrets dans des fichiers .env fonctionne, mais les valeurs sont en clair, les environnements partagés sont une galère, et il n’y a aucun moyen natif de chiffrer quoi que ce soit au repos.

Symfony 5.0 ajoute une famille de commandes secrets: et un mécanisme de coffre-fort. Les secrets sont chiffrés avec une paire de clés stockée hors du dépôt. Les fichiers chiffrés sont commités ; la clé de déchiffrement ne l’est pas. En production, la clé arrive comme variable d’environnement ou est injectée depuis un gestionnaire de secrets.

php bin/console secrets:set DATABASE_PASSWORD
php bin/console secrets:decrypt-to-local --force

Pas une solution de gestion de secrets à part entière, mais un vrai pas en avant par rapport à un fichier .env en clair qui traîne non chiffré dans le dépôt.

Mailer reçoit une couche de notification

Le composant Mailer est arrivé en 4.4. Ce que la 5.0 ajoute par-dessus, c’est la NotificationEmail : un email pré-stylisé et responsive construit sur Foundation for Emails, avec une API explicite pour les niveaux d’importance et les boutons d’appel à l’action :

use Symfony\Bridge\Twig\Mime\NotificationEmail;

$email = (new NotificationEmail())
    ->from('alerts@example.com')
    ->to('admin@example.com')
    ->subject('Disk usage critical')
    ->markdown('The disk on **prod-01** is at 94%. Check it now.')
    ->action('Open dashboard', 'https://example.com/servers')
    ->importance(NotificationEmail::IMPORTANCE_URGENT);

Pas de template à écrire, pas de CSS inline à dompter. Pour les alertes transactionnelles, les notifications de facturation et les emails système, ça couvre 80 % de ce dont on a besoin sans toucher à quoi que ce soit.

Les firewalls paresseux et le problème de cache

Chaque firewall stateful dans Symfony charge l’utilisateur depuis la session à chaque requête, que l’action en ait besoin ou non. Ce qui signifie que toute réponse est non-cacheable par défaut, même pour des pages qui ne touchent jamais à $this->getUser().

La 5.0 ajoute le mode lazy pour les firewalls, qui diffère l’accès à la session jusqu’à ce que le code appelle réellement is_granted() ou accède au token utilisateur :

# config/packages/security.yaml
security:
    firewalls:
        main:
            pattern: ^/
            anonymous: lazy

Les pages qui n’ont pas besoin de l’utilisateur redeviennent cacheables. Les nouveaux projets obtiennent ça par défaut via la recette Flex ; les existants ont besoin d’un changement de config en une ligne.

Les migrations de mots de passe sans grand soir

Migrer une app en production de bcrypt vers argon2id impliquait jusqu’ici de forcer une réinitialisation du mot de passe pour chaque utilisateur. Le PasswordUpgraderInterface rend ça progressif : à la connexion, Symfony vérifie si le hash stocké correspond à l’algorithme courant. Sinon, il le re-hash sur place et appelle votre upgrader pour le sauvegarder :

// src/Repository/UserRepository.php
class UserRepository extends ServiceEntityRepository implements PasswordUpgraderInterface
{
    public function upgradePassword(UserInterface $user, string $newHashedPassword): void
    {
        $user->setPassword($newHashedPassword);
        $this->getEntityManager()->flush();
    }
}

Associez ça à algorithm: auto dans la config de l’encodeur, et les anciens hashs migrent silencieusement à mesure que les utilisateurs se connectent. Pas de script de migration, pas de downtime, pas de friction pour l’utilisateur.

ErrorHandler remplace Debug

Le composant Debug est parti. Son remplaçant, ErrorHandler, fait le même travail (convertir les erreurs PHP en exceptions, afficher de belles pages d’erreur) mais sans nécessiter Twig. Pour les apps API qui ne rendent jamais de HTML, ça compte : ErrorHandler génère les erreurs dans le format de la requête (JSON, XML, texte) en suivant RFC 7807 :

{
    "title": "Not Found",
    "status": 404,
    "detail": "Sorry, the page you are looking for could not be found"
}

La config de routing passe de TwigBundle à FrameworkBundle, et c’est la seule étape de migration pour la plupart des projets. Une ligne, c’est fait.

Les listeners d’événements, enfin moins verbeux

Enregistrer un listener d’événement kernel impliquait auparavant de nommer explicitement l’événement dans le tag de service. Symfony 5.0 l’infère depuis la signature de méthode :

// Pas de configuration de tag au-delà de kernel.event_listener
final class SecurityListener
{
    public function onKernelRequest(RequestEvent $event): void
    {
        // Symfony lit le type hint et détermine l'événement
    }
}

# config/services.yaml
App\EventListener\SecurityListener:
    tags: [kernel.event_listener]

Utilisez __invoke() et ça fonctionne de la même façon. Enregistrez en masse tout un répertoire de listeners avec un seul bloc resource, et Symfony détermine quel événement chacun gère.

HttpClient grandit

Le composant HttpClient est arrivé en 4.4 comme stable. La 5.0 ajoute quelques choses utiles par-dessus :

L’authentification NTLM pour les environnements d’entreprise, le buffering conditionnel via un callback (bufferiser les grandes réponses seulement quand le content-type correspond), une option max_duration qui plafonne le temps total de requête indépendamment des conditions réseau, et toStream() pour transformer n’importe quelle réponse en un flux PHP standard pour le code qui attend du fread() :

$response = $client->request('GET', 'https://api.example.com/large-export', [
    'max_duration' => 30.0,
    'buffer' => fn(array $headers): bool => str_contains($headers['content-type'][0] ?? '', 'json'),
]);

// Le streamer plutôt que de tout charger en mémoire
$stream = $response->toStream();

Le client a aussi obtenu une interopérabilité complète avec PSR-18 et HTTPlug v1/v2, donc toute bibliothèque qui dépend de ces abstractions fonctionne directement avec lui.

Ce que la 5.0 supprime

La 5.0 abandonne tout ce qui était déprécié en 4.4. Les plus notables :

• WebServerBundle (utilisez symfony server:start depuis l’outil CLI à la place)
• L’AnonymousToken de l’ancien système de sécurité (remplacé par NullToken)
• Les anciens noms d’événements de formulaire
• Le ClassLoader interne de Symfony
• Le composant Debug (remplacé par ErrorHandler)

Si vous avez fait tourner votre app 4.4 avec les notices de dépréciation actives et corrigé les avertissements, la mise à niveau vers la 5.0 ne nécessite aucun changement de code.