Symfony Live Paris 2026 : chiffrement Doctrine et sidekicks FrankenPHP, notre retour terrain

Chez Codein, l'engagement dans l'écosystème Open Source et la montée en compétence de nos développeurs sont des piliers de notre expertise. Comme chaque année, nous étions présents au Symfony Live Paris pour suivre les évolutions du framework. Marc et Cyril y ont représenté l'agence et nous livrent leur analyse sur les sujets qui leur ont le plus parlé lors de cette conférence.

×

Chiffrement des données en base de données 

Talk de Jérôme Tamarelle, Open-source Software Engineer at MongoDB

×

Comment chiffrer des données sensibles dans Symfony sans sacrifier la capacité de recherche ?

Les fuites de données représentent aujourd'hui un défi majeur. La question de la sécurité numérique revient sans cesse, comme l'illustrent les cas du ministère de l’Éducation nationale, de Bercy, de l’ANTS ou de la plateforme Parcoursup. La sécurité des données est un sujet qui revient régulièrement lors des conférences Symfony, et cette édition n'a pas fait exception.

Depuis février 2025, Doctrine simplifie l'injection de dépendances dans les types de données custom. Grâce à cela, Jérôme Tamarelle nous a présenté comment implémenter très simplement un type de donnée permettant le cryptage et le décryptage des données en base directement via Doctrine. 

Cette approche offre plusieurs avantages qui permettent de mettre en place cette sécurité essentielle : Fini les services maison pour crypter ou décrypter les données des données. C'est Doctrine qui fait le travail. 

La mise en place d'un type Doctrine permet de réutiliser le même code pour protéger l'ensemble des données sensibles de la base.

Grâce au type Doctrine, le mécanisme de cryptage est disponible à la persistance mais également à la requête. En cas d'utilisation d'un chiffrement déterministe, les données sont directement recherchables.

Point important : le cryptage des données nécessite la mise en place d'une solution de type KMS pour la gestion des clés de cryptage. L'idéal serait d'avoir une clé de chiffrement principale pour vos données (DEK, Data Encryption Key) et une master key pour chiffrer votre DEK, qui ira elle-même dans votre KMS.

Les plus grands du secteur acteurs proposent ce type de solutions. Qu'il s'agisse de OVHCloud pour une solution française, ou Amazon, Google et Microsoft pour une solution américaine. Cependant, la mise en place d'une telle solution peut être démarrée très facilement grâce à l'utilisation d'un fichier .key local. Pas besoin de débourser de l'argent tant que votre application n'est pas en production.

En complément, Jérôme nous a également présenté comment préserver la recherchabilité des données cryptées grâce à l'utilisation de tags multiniveau. 

Le principe est simple : Avant la persistance des données, on génère des plages de données, de plus en plus précises qu'on va stocker et crypter dans une colonne dédiée. La recherche ne se fait plus sur les valeurs réelles mais sur les tags calculés à partir de la valeur recherchée. Reste à définir pour les différentes valeurs, une granularité de génération des tags qui soit satisfaisante à la fois en termes de précision de recherche et en termes de confidentialité.

Il y a cependant un coût à cela : la nécessité de stocker vos clés de chiffrement dans un KMS (Key Management System). Les plus grands acteurs en proposent, comme OVHCloud pour une solution française, ou Amazon, Google et Microsoft pour une solution américaine.

Pour vos tests en local, un fichier .key fera l'affaire, pas besoin de débourser de l'argent tant que votre application n'est pas en production.

En réalité, l'idéal serait d'avoir une clé de chiffrement principale pour vos données (DEK, Data Encryption Key) et une master key pour chiffrer votre DEK, qui ira elle-même dans votre KMS.

Au niveau de l'impact sur les performances, ce dernier serait très léger.

Reconfigurer Symfony en temps réel avec des sidekicks applicatifs

Talk de Nicolas Grekas, Core Team Member Symfony

×

C'est quoi FrankenPHP, et pourquoi ça change tout pour Symfony ?

FrankenPHP est un serveur d'application PHP moderne, construit sur Go et Caddy, qui introduit notamment le concept de workers long-running : des processus PHP qui restent actifs entre les requêtes, permettant à une application de maintenir un état et de réagir à son environnement en temps réel. C'est ce mécanisme que Nicolas Grekas exploite avec les sidekicks.
 

Quel problème les sidekicks viennent-ils résoudre ?

Un des problèmes courants des applications PHP, c'est de traiter de façon linéaire des requêtes sans persistance de l'état de l'application entre elles. À chaque requête, la configuration est chargée, la requête est traitée, une réponse est retournée. En l'état, PHP ne sait que récupérer des états et des configurations. Il n'est pas possible de pousser de la donnée vers l'application.

Si on s'intéresse par exemple à l'utilisation d'un cluster Redis avec Redis Sentinel, cela implique que, pour chaque requête, l'application contacte Redis Sentinel pour qu'il lui indique le nœud du cluster à utiliser, puis elle appelle ce nœud pour y récupérer ou stocker des données. 

Pour résumer, une opération "Stocke moi cette valeur dans Redis" implique deux appels : un premier pour savoir quel master utiliser, un second pour envoyer la donnée à ce master.
 

Comment fonctionnent concrètement les sidekicks ?

Les "sidekicks" présentés par Nicolas Grekas, comme une fonctionnalité à venir, permettent de changer fondamentalement cette approche grâce à FrankenPHP.

Le principe est d'utiliser un thread comme un tableau blanc sur lequel les sidekicks vont écrire, et que les threads HTTP vont lire pour connaître l'état de l'application au moment où ils traitent la requête.

En reprenant l'exemple du cluster Redis, un sidekick dédié va écrire le master à utiliser sur le tableau blanc. L'application ne fait plus que lire cette information et ne contacte plus la Sentinel. À noter qu'il n'est pas nécessaire d'utiliser FrankenPHP en mode worker pour bénéficier de cette approche.

La mise en place de cette fonctionnalité ouvre de nouvelles perspectives pour les applications Symfony, notamment pour la mise en place de feature flags et en simplifiant le développement de fonctionnalités nécessitant de la configuration à chaud.

En conclusion

Le chiffrement des données applicatives avec Doctrine devient enfin accessible et pragmatique, et les sidekicks ouvrent une nouvelle dimension pour des applications PHP capables de s'adapter en temps réel à leur environnement. Nous vous recommandons de surveiller ces deux sujets : ils dessinent ce que sera le développement Symfony dans les prochains mois !