Sur un de nos projets, nous avions déjà des tests Behat pour le fonctionnel, et des tests PHPUnit pour le métier. Mais aucun de ces tests ne disait « la page d’accueil ne ressemble plus à la page d’accueil ». C’est exactement ce que font les tests de non-régression visuelle, et Playwright le fait très bien nativement.

Dans cet article, nous allons voir la stack que nous avons mise en place sur ce projet : les tests eux-mêmes, les tasks Castor pour les piloter, le passage par Docker pour avoir un rendu stable entre les machines de l’équipe, et enfin comment nous postons les images de diff directement dans un commentaire de la pull request.

Le principe : toHaveScreenshot()

Playwright, la solution que nous utilisons déjà pour nos tests E2E, propose une assertion faite pour ça : toHaveScreenshot(). Elle prend une capture de la page, la compare avec l’image de référence commitée dans le dépôt, et échoue si les deux diffèrent trop. En l'occurrence, Playwright vérifie si le nombre de pixels différents entre les 2 images est inférieur à un seuil configuré.

Notre fichier application/e2e/screenshots.spec.ts couvre les pages structurantes du site : la home, la page de résultats de recherche, une page de détail, etc. Plusieurs pages, autant d'images de référence, et de quoi attraper l’immense majorité des régressions CSS.

Un test ressemble à ça :

test('homepage screenshot', async ({ page }) => {
    await page.goto(homeUrl);
    // The search form is a React component that mounts client-side;
    // wait for it so the layout below does not shift.
    await page.locator('#tab-search').waitFor({ state: 'visible' });
    await stabilize(page);

    await expect(page).toHaveScreenshot('homepage.png', {
        fullPage: true,
        animations: 'disabled',
        maxDiffPixels: 100,
        // The header image is picked at random server-side, so mask it.
        mask: [page.getByTestId('homepage-header-image')],
    });
});

Écrire le test en lui-même est donc assez trivial. Toute la difficulté de l’exercice est ailleurs : il faut que la page soit déterministe. Un test visuel qui échoue une fois sur trois ne sert à rien, car au bout de deux semaines toute l’équipe relance le job sans même regarder. Nous avons donc passé pas mal de temps, non pas à écrire les tests, mais à supprimer une par une toutes les sources de variation.

Attendre que la page soit vraiment stable

Le piège classique : la capture est prise pendant que la page finit de se construire. Images en lazy loading, blocs asynchrones, polices web qui provoquent un reflow au moment où elles arrivent… La capture est techniquement valide, mais elle ne correspond à rien de reproductible.

D’où ce petit helper, appelé dans tous les tests :

// Wait for the page to be visually stable before taking a full-page screenshot:
// network idle (lazy images / async blocks) + web fonts loaded (avoids reflow).
async function stabilize(page: Page): Promise<void> {
    await page.waitForLoadState('networkidle');
    await page.evaluate(() => document.fonts.ready);
}

Et quand ça ne suffit pas, on attend explicitement l’élément qui pose problème. Sur la home, c’est le formulaire de recherche (un composant React monté côté client) ; sur une autre page, c’est un Swiper qui se réorganise après le networkidle :

await page.locator('.js-swiper-expertises.c-swiperinitialized').first().waitFor({ state: 'visible' });

La classe c-swiperinitialized n’est ajoutée qu’une fois le carrousel initialisé : c’est donc un bon signal pour savoir que le rendu final est atteint.

Masquer ce qui est volontairement aléatoire

Certaines zones ne seront jamais stables, et c’est normal : c’est le produit qui le veut. L’image d’en-tête de la home est tirée au sort côté serveur. Sur la page d'un point de vente, le bloc FAQ s’affiche aléatoirement, et les horaires d’ouverture mettent en avant le jour courant… qui change tous les jours.

Plutôt que de chercher à contourner le problème, on peut simplement demander à Playwright de masquer ces zones : elles seront recouvertes d’un aplat avant la comparaison.

Pour parvenir à cela, il faut lister les éléments à masquer directement dans la config de Playwright :

mask: [
    page.getByTestId('faq-block'), // display randomly
    page.getByTestId('store-timetable'), // current day open by default (changes daily)
],

Nous utilisons ici des data-testid plutôt que des classes CSS : cela donne un point d’accroche stable, qui ne bougera pas à la prochaine refonte du style.

Fixer le viewport et tolérer une poignée de pixels

Deux derniers réglages, dans playwright.config.ts et dans les tests :

use: {
    ignoreHTTPSErrors: true,
    /* Fixed viewport to keep screenshot dimensions deterministic across machines. */
    viewport: { width: 1280, height: 900 },
    trace: 'on-first-retry',
},

Un viewport fixe garantit que les dimensions de la capture ne dépendent pas de la machine. Quant au maxDiffPixels (50 sur la plupart des pages, 100 sur la home qui est plus chargée), il laisse passer les micro-variations d’antialiasing sans laisser passer un vrai décalage de bloc. C’est un curseur à régler : trop bas, les tests deviennent flaky ; trop haut, on rate des régressions. Ces valeurs se sont stabilisées à l’usage.

Un rendu stable grâce à Docker

Il reste malgré tout une source de variation, et c’est probablement la plus importante : une capture d’écran n’est pas seulement le résultat de votre HTML et de votre CSS, c’est aussi le résultat du moteur de rendu de la machine qui a pris la capture. Rendu des polices, antialiasing, sous-pixels : macOS et Linux ne produisent tout simplement pas les mêmes pixels.

Playwright en est d’ailleurs conscient, puisqu’il suffixe les images de référence par plateforme. Voici le contenu de notre dossier de snapshots :

application/e2e/screenshots.spec.ts-snapshots/
├── detail-page-chromium-linux.png
├── homepage-chromium-linux.png
├── list-page-chromium-linux.png
├── pro-homepage-chromium-linux.png
├── store-homepage-chromium-linux.png
└── store-page-chromium-linux.png

Notez bien le suffixe -chromium-linux. Or, notre équipe est mixte : certains développent sur macOS, d’autres sur Linux. Si chacun lance Playwright sur son hôte, il faut soit commiter deux jeux d’images (-darwin et -linux) et les maintenir en double, soit accepter que les collègues sur Mac échouent systématiquement sur des tests pourtant verts en CI. Aucune des deux options n’est satisfaisante.

Heureusement, la solution est celle que nous appliquons déjà à tout le reste sur ce projet : tout tourne dans Docker. Les navigateurs Playwright sont installés dans un conteneur dédié à tout le tooling du projet (Composer, nodejs, etc.), jamais sur l’hôte, et les tests sont exécutés dedans. Ainsi, que ce soit les développeurs sous Mac ou Linux, ou bien depuis le runner de CI, c'est toujours le même environnement de rendu qui est exécuté. Les images de référence sont générées une fois, dans le conteneur sous Linux, et valent pour tout le monde.

Quant aux binaires des navigateurs, ils atterrissent dans le cache par défaut de Playwright ($HOME/.cache/ms-playwright). Sur notre projet, ce dossier est un volume monté : ils survivent ainsi aux reconstructions de conteneur et ne sont pas re-téléchargés à chaque lancement.

projects: [
        {
            name: 'chromium',
            use: { ...devices['Desktop Chrome'] },
        },
    ],

Puis on demande à Playwright d'installer uniquement Chromium :

yarn playwright install chromium'

Grâce au cache natif et à l'utilisation d'un seul navigateur, nous gagnons une quinzaine de secondes de temps d'exécution du job E2E dans notre CI.

Piloter les tests avec Castor

Comme souvent quand nos projets nécessitent de lancer des commandes, nous avons mis en place une task Castor pour simplifier la DX. Le but est que personne n’ait jamais besoin de savoir dans quel conteneur, ni avec quelles variables d’environnement, Playwright doit tourner :

#[AsTask(description: 'E2E Playwright Tests')]
function e2e(?string $filter = null, bool $updateScreenshots = false): void
{
    io()->section('Running E2E Playwright Tests...');

    // Browsers are downloaded in the default cache directory ($HOME/.cache/ms-playwright), which
    // is a mounted volume: the download only happens once. Only chromium is needed by the tests.
    io()->comment('Installing Playwright browsers...');
    docker_compose_run('yarn playwright install chromium');

    $command = 'yarn playwright test';

    // Optionally filtered to a single spec
    if (null !== $filter) {
        $command .= ' ' . escapeshellarg($filter);
    }

    if ($updateScreenshots) {
        io()->comment('Running tests and updating screenshots...');
        $command .= ' --update-snapshots';
    }

    docker_compose_run($command);
}

Pour résumer, cette task va :

1. s’assurer que le navigateur utilisé par les tests est installé ;
2. lancer les tests, éventuellement filtrés sur un seul fichier de spec ;
3. et, si on le lui demande, régénérer les images de référence plutôt que de les comparer.

Le workflow au quotidien tient alors en trois commandes :

# Lancer les comparaisons
castor qa:e2e --filter screen

# En cas d’échec : ouvrir les images de diff (les différences ressortent en rouge)
castor qa:e2e-diff

# Si les différences sont légitimes (modification CSS, ajout de contenu…) :
# régénérer les images de référence
castor qa:e2e --update-screenshots

La task qa:e2e-diff ne fait pas grand-chose, mais elle évite d’avoir à fouiller dans test-results/ pour trouver le bon PNG :

#[AsTask(description: 'Open the diff images of the last failing screenshots')]
function e2e_diff(): void
{
    $diffs = glob(\dirname(__DIR__) . '/application/test-results/*/*-diff.png') ?: [];

    if ([] === $diffs) {
        io()->success('No screenshot diff found. All screenshots match.');

        return;
    }

    foreach ($diffs as $diff) {
        io()->writeln('Opening ' . basename($diff));
        open($diff);
    }
}

Notez que Playwright n’écrit ces fichiers -diff.png que pour les captures ayant réellement échoué. Il n’y a donc rien à filtrer : ce qui se trouve dans le dossier est exactement ce qui est cassé.

Poster les diffs dans la pull request

Tout ceci fonctionne très bien en local. En CI, en revanche, l’expérience était nettement moins agréable : un job rouge, un message « expected 50 pixels, got 3400 », et il fallait ensuite aller récupérer les images à la main pour comprendre ce qui avait changé.

Nous avons donc ajouté une étape supplémentaire à la CI : quand un screenshot échoue, les images sont postées dans un commentaire de la pull request, avec l’attendu, l’obtenu et le diff côte à côte dans un tableau Markdown. La personne qui relit voit le problème directement en ouvrant la PR, sans avoir à cliquer sur « Détails ».

Le job GitHub Actions reste très simple, puisque toute la logique est déportée dans des tasks Castor :

- name: E2E Playwright Tests
  run: castor qa:e2e

- name: Report E2E screenshot failures on the PR
  if: ${{ failure() && github.event_name == 'pull_request' }}
  run: castor qa:e2e-report-failures
  env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      E2E_PR_NUMBER: ${{ github.event.pull_request.number }}
      E2E_RUN_ID: ${{ github.run_id }}
      GITHUB_REPOSITORY: ${{ github.repository }}
      GITHUB_SERVER_URL: ${{ github.server_url }}

- name: Clear E2E screenshot report on the PR
  if: ${{ success() && github.event_name == 'pull_request' }}
  run: castor qa:e2e-clear-report
  env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      E2E_PR_NUMBER: ${{ github.event.pull_request.number }}
      GITHUB_REPOSITORY: ${{ github.repository }}

Il reste une contrainte à contourner : on ne peut pas afficher une image dans un commentaire GitHub sans que celle-ci soit accessible via une URL publique. Nous hébergeons donc les images sur notre préproduction, en réutilisant l’accès SSH dont on se sert déjà pour le déploiement :

$remoteUser = 'deploy';
$remoteHost = 'preprod-web01';
$remoteDir = '/var/www/sites/www.example.com/current/web/images/_e2e';
// Careful: pick a host that is NOT behind a Basic auth, or GitHub cannot fetch the images.
$publicBaseUrl = 'https://static-preprod.example.com/images/_e2e';
$retentionDays = 30;

Castor fournit justement tout ce qu’il faut pour piloter une machine distante, avec ssh_run(), ssh_upload() et ssh_download(). Une fois les images rangées dans un dossier de staging local, l’envoi tient en deux appels :

// Upload the whole staging directory. ssh_upload() always runs scp with "-r", and copying a
// source directory onto a non-existing destination creates it: remove any leftover from a
// previous attempt on the same run first, otherwise scp would nest it inside itself.
$remoteRunDir = $remoteDir . '/' . $runKey;
ssh_run(
    \sprintf('rm -rf %s && mkdir -p %s', escapeshellarg($remoteRunDir), escapeshellarg($remoteDir)),
    host: $remoteHost,
    user: $remoteUser,
);
ssh_upload($staging, $remoteRunDir, host: $remoteHost, user: $remoteUser);

Le commentaire est ensuite construit à la main en Markdown :

$body .= "## ❌ Régression visuelle E2E\n\n";
$body .= \sprintf("Des screenshots ont changé sur ce run ([logs](%s)).\n\n", $runUrl);

foreach ($screenshots as $screenshot) {
    $base = \sprintf('%s/%s/%s/%s', $publicBaseUrl, $runKey, $screenshot['testDir'], $screenshot['name']);
    $body .= \sprintf("### `%s`\n\n", $screenshot['name']);
    $body .= "| Attendu | Obtenu | Diff |\n| --- | --- | --- |\n";
    $body .= \sprintf(
            "| %s | %s | %s |\n\n",
            null !== $screenshot['expected'] ? \sprintf('![attendu](%s-expected.png)', $base) : '—',
            null !== $screenshot['actual'] ? \sprintf('![obtenu](%s-actual.png)', $base) : '—',
            \sprintf('![diff](%s-diff.png)', $base),
        );
}

Quelques détails supplémentaires méritent d’être mentionnés.

Un commentaire « sticky » plutôt qu’un nouveau à chaque run

Une PR avec plusieurs allers-retours finirait vite avec une dizaine de commentaires de robot. Pour éviter ça, nous plaçons un marqueur HTML invisible en tête du corps du message :

// Hidden marker used to identify the sticky E2E screenshots report comment on a PR.
const E2E_REPORT_MARKER = '<!-- e2e-screenshots-report -->';

Il suffit ensuite de parcourir les commentaires de la PR à la recherche de ce marqueur :

const E2E_GITHUB_API_BASE = 'https://api.github.com';

function e2e_find_report_comment(array $options, string $repo, string $pr): ?int
{
    $page = 1;
    do {
        $listUrl = \sprintf('%s/repos/%s/issues/%s/comments?per_page=100&page=%d', E2E_GITHUB_API_BASE, $repo, $pr, $page);
        $comments = http_request('GET', $listUrl, $options)->toArray();
        foreach ($comments as $comment) {
            if (str_contains($comment['body'] ?? '', E2E_REPORT_MARKER)) {
                return $comment['id'];
            }
        }
        ++$page;
    } while (100 === \count($comments));

    return null;
}

Les $options sont communes à tous les appels, et regroupent l’authentification et les en-têtes attendus par l’API :

function e2e_github_options(string $token): array
{
    return [
        'auth_bearer' => $token,
        'headers' => [
            'Accept' => 'application/vnd.github+json',
            'X-GitHub-Api-Version' => '2022-11-28',
        ],
    ];
}

Et selon qu’on a trouvé un commentaire existant ou non, on fait un PATCH sur celui-ci ou un POST d’un nouveau :

$options = e2e_github_options($token);
$existingId = e2e_find_report_comment($options, $repo, $pr);

if (null !== $existingId) {
    $url = \sprintf('%s/repos/%s/issues/comments/%d', E2E_GITHUB_API_BASE, $repo, $existingId);
    http_request('PATCH', $url, [...$options, 'json' => ['body' => $body]])->getContent();
    io()->success(\sprintf('Updated PR #%s comment with %d screenshot(s).', $pr, \count($screenshots)));
} else {
    $url = \sprintf('%s/repos/%s/issues/%s/comments', E2E_GITHUB_API_BASE, $repo, $pr);
    http_request('POST', $url, [...$options, 'json' => ['body' => $body]])->getContent();
    io()->success(\sprintf('Posted a comment on PR #%s with %d screenshot(s).', $pr, \count($screenshots)));
}

La même fonction de recherche est réutilisée par la task qa:e2e-clear-report : quand les tests repassent au vert, on retrouve le commentaire par son marqueur et on le supprime (DELETE), pour que la PR ne garde pas la trace d’un problème déjà corrigé.

Dédoublonner les retries

En CI, Playwright réessaie deux fois (retries: process.env.CI ? 2 : 0) et écrit les résultats de chaque tentative dans des dossiers frères <test>-retryN. Sans traitement, la même régression apparaîtrait donc trois fois dans le commentaire. Nous regroupons les images par test et par capture, en ne gardant que la tentative la plus élevée :

// Retries live in sibling "<test>-retryN" directories; strip the suffix for a stable key.
$testDir = basename($dir);
$retry = 0;
if (preg_match('/^(.*)-retry(\d+)$/', $testDir, $matches)) {
    $testDir = $matches[1];
    $retry = (int) $matches[2];
}

$key = $testDir . '/' . $name;
if (isset($screenshots[$key]) && $screenshots[$key]['retry'] >= $retry) {
    continue;
}

Purger les vieilles images

Enfin, comme nous poussons des images sur un serveur partagé à chaque échec, il faut éviter que le dossier ne grossisse indéfiniment. Un find sur les dossiers de run trop anciens fait l’affaire. Notez le allowFailure : le ménage ne doit pas faire échouer le rapport s’il se passe mal.

// Prune old run directories so the shared folder does not grow forever.
ssh_run(
    \sprintf(
        'find %s -mindepth 1 -maxdepth 1 -type d -mtime +%d -exec rm -rf {} +',
        escapeshellarg($remoteDir),
        $retentionDays,
    ),
    host: $remoteHost,
    user: $remoteUser,
    allowFailure: true,
);

Au bout du compte, toute la logique pour poster les régressions visuelles en commentaire dans GitHub représente environ 200 lignes de PHP, mais cette amélioration nous fait gagner du confort au quotidien : on passe d’un « le job E2E est rouge » à un « ah oui, le footer a pris 4px » sans quitter la page de la PR.

Le cas des fixtures aléatoires

Il reste une dernière source de variation, et c’est celle qui nous a demandé le plus de tâtonnements.

Nos fixtures utilisent nelmio/alice, et donc Faker, ce qui implique de l’aléatoire : des titres, des prix, des descriptions, des noms générés à la volée. Or une page de détail ne peut évidemment pas produire une capture stable si le prix affiché change à chaque chargement des fixtures.

Nous avions déjà fait en sorte d'éviter les soucis d'aléatoire dès le début du projet car les tests Behat avaient le même besoin d'avoir des contenus stables dans le temps, et la solution tient en une ligne de configuration :

# application/config/packages/nelmio_alice.yaml
when@dev: &dev
    nelmio_alice:
        locale: 'fr_FR' # Default locale for the Faker Generator
        seed: 42

when@test: *dev

Avec un seed fixe, Faker devient déterministe : les mêmes fixtures rechargées produisent exactement les mêmes données, et donc exactement les mêmes pixels. Problème réglé, en apparence.

Sauf que le déterminisme d’un générateur pseudo-aléatoire est positionnel. Le seed garantit une séquence de valeurs, mais pas l’affectation d’une valeur donnée à un objet donné. Si vous ajoutez une entité au milieu d’un fichier de fixtures, par exemple pour un test Behat qui n’a rien à voir avec le visuel, vous consommez un tirage supplémentaire, et tout ce qui vient après décale d’un cran dans la séquence. Les prix changent, les titres changent, et les captures d’écran deviennent rouges à cause d’un test fonctionnel sans aucun rapport.

Le symptôme est assez déroutant la première fois qu’on le rencontre : la PR ne touche pas une ligne de CSS, et pourtant les tests visuels échouent.

La règle que nous nous sommes donnée est simple : quand une capture change à cause d’un décalage de fixtures, on change la fixture impactée puis on régénère l’image. Concrètement, on identifie la donnée qui a bougé sur la page (un prix, un titre, un nom) et on lui donne une valeur en dur au lieu de la laisser à Faker :

# Avant : la valeur dépend de la position du tirage dans la séquence.
title: '<sentence()>'
price: '<numberBetween(100000, 900000)>'

# Après : la valeur est figée, et ne bougera plus jamais.
title: 'Une valeur figée pour les tests de screenshots'
price: 245000

Le commentaire de PR est précieux pour ça : il montre immédiatement quelle donnée a changé. Constater qu’un prix est passé de 245 000 € à 312 000 € prend deux secondes, là où le déduire d’un compteur de pixels est impossible.

L’intérêt de procéder ainsi, c’est que la correction est définitive et que l’effort est réparti dans le temps. Nous ne figeons pas toutes les fixtures d’un coup - ce serait un gros chantier, et une bonne partie n’apparaît de toute façon dans aucune capture. Nous figeons uniquement celles qui nous ont réellement posé problème, au moment où elles nous le posent. Au fil des PR, les données visibles sur les pages sous test deviennent progressivement déterministes, et ce type d’échec se raréfie de lui-même.

En résumé

Grâce à Playwright, Docker et Castor, nous avons pu mettre en place une détection des régressions visuelles qui reste simple à l’usage :

• toHaveScreenshot() fait tout le travail de comparaison, sans outil externe ni service tiers à payer ;
• le passage par Docker garantit un rendu identique sur les postes de l’équipe et en CI, quel que soit l’OS ;
• les tasks Castor masquent la plomberie et installent leurs dépendances toutes seules ;
• le déterminisme est obtenu par un ensemble de petits réglages : viewport fixe, attente explicite de stabilisation, masques sur les zones volontairement aléatoires et seed sur les fixtures ;
• les diffs postés directement dans la pull request rendent chaque échec compréhensible en un coup d’œil.

Quelques captures d’écran seulement, et quelques centaines de lignes de configuration : ce n’est évidemment pas une couverture exhaustive du site, et ce n’est pas le but. Mais depuis leur mise en place, les régressions de mise en page sur les pages structurantes sont détectées avant la mise en production, et non plus après.

Si Sylius s’est imposé dans l’écosystème e-commerce, c’est notamment grâce à sa capacité à s’adapter à des besoins métier très variés sans imposer une architecture rigide. Son système d’extensions permet de faire évoluer progressivement les fonctionnalités tout en conservant les mécanismes du cœur du framework.

Fin d'année dernière, nous avons lancé le JoliMediaBundle, un bundle Symfony dédié à la gestion de bibliothèques de medias.

Il était déjà accompagné de deux bridges pour SonataAdmin et EasyAdmin.

La Genèse du bridge

Récemment arrivé chez JoliCode et expert Sylius, j’ai rapidement engagé des discussions autour de l’intégration du MediaBundle dans cet écosystème. C’est ainsi qu’est née l’idée de ce nouveau bridge, visant à connecter harmonieusement la gestion des médias avec Sylius.

La gestion des médias dans Sylius

Avant d’introduire ce nouveau bridge, il est utile de faire un état des lieux de la gestion des médias dans Sylius aujourd’hui.

Par défaut, Sylius propose un système simple mais efficace pour associer des images aux principales ressources du catalogue, comme les produits ou les taxons. Cette gestion repose sur des entités d’images directement liées aux ressources, avec quelques métadonnées basiques (type, position, etc.).

Cette approche répond parfaitement aux besoins classiques d’un site e-commerce : illustrer un produit, afficher des visuels de catégories, ou encore gérer des galeries simples.

En revanche, certaines limites apparaissent dès que les besoins deviennent plus transverses. Notamment :

• la difficulté à réutiliser facilement un même média à plusieurs endroits sans duplication ;
• l’absence d’une organisation centralisée des fichiers (dossiers, tags, recherche…) ;
• une gestion éclatée des médias, propre à chaque ressource.

En pratique, chaque entité embarque ses propres fichiers, ce qui fonctionne bien à petite échelle mais devient rapidement contraignant dès que le volume de médias augmente ou que plusieurs équipes interviennent.

Le bridge Sylius et JoliMediaBundle

C’est précisément ce constat qui a motivé la réflexion autour d’une gestion des médias plus centralisée et réutilisable au sein de l’écosystème Sylius, en s’appuyant sur le JoliMediaBundle développé chez JoliCode. Pour répondre à ces limites, nous avons développé le bridge Sylius pour ce bundle. L’objectif n’est pas de modifier le fonctionnement de Sylius ni de réécrire sa gestion des médias, mais d’y ajouter une couche d’intégration propre, basée sur ses mécanismes d’extension.

Dans un projet Sylius, les médias sont utilisés dans les images produit, les images de taxons et les avatars administrateurs. Ces usages sont bien intégrés au modèle natif mais restent isolés les uns des autres. Le bridge vient enrichir ce fonctionnement en introduisant une médiathèque centralisée.

Il est également pensé pour être compatible avec la Sylius Stack au sens large, et pas uniquement avec un contexte e-commerce. Il peut ainsi s’intégrer dans des back-offices Sylius utilisés comme base d’application, où la gestion de médias est un besoin transverse à plusieurs domaines fonctionnels. Cela permet d’utiliser la même approche de médiathèque centralisée dans des projets plus généraux construits avec Sylius.

Concrètement, l’approche repose sur des extensions simples et ciblées :

• extension des entités Sylius concernées lorsque cela est nécessaire ;
• remplacement des champs de formulaire dans le back-office pour utiliser le sélecteur de médias du JoliMediaBundle ;
• intégration progressive via les points d’extension fournis par Sylius.

Cette stratégie permet de conserver les usages métier actuels tout en introduisant une gestion plus cohérente et réutilisable des médias. Chaque image (produit, taxon, administrateur) garde son rôle, mais s’inscrit désormais dans une logique commune de médiathèque.

L’intégration reste volontairement discrète : le bridge agit comme une surcouche qui s’insère dans l’écosystème Sylius sans en modifier les fondations.

C’est cette approche progressive qui rend l’adoption possible dans un projet existant, sans refonte du modèle de données ni rupture fonctionnelle.

La question devient alors plus concrète : comment ce bridge s’insère-t-il techniquement dans Sylius, et quels sont les mécanismes utilisés pour relier proprement la médiathèque au modèle existant ?

Une intégration simple dans Sylius

Lorsque vous avez installé le Media bundle, il faut activer le bridge Sylius :

// filepath: config/bundles.php
return [
    // ...
    JoliCode\MediaBundle\Bridge\Sylius\JoliMediaSyliusBundle::class => ['all' => true],
];

Ensuite, on active les routes pour le back-office :

# filepath: config/routes/joli_media.yaml
_joli_media_sylius:
    resource: "@JoliMediaSyliusBundle/src/Admin/Controller/"
    prefix: /admin/media

Et enfin, on importe la configuration du package :

# filepath: config/packages/joli_media_sylius.yaml
imports:
    - { resource: "@JoliMediaSyliusBundle/config/app.php" }

L’idée est de s’appuyer sur les mécanismes d’extension classiques de Symfony et Sylius, afin de rester le moins intrusif possible.

Un trait réutilisable pour les médias

La première brique consiste à utiliser un trait permettant d’ajouter une gestion de média à n’importe quelle entité métier :

Vous pouvez associer un média à une entité Doctrine Sylius, tout en conservant une logique simple côté domaine. Cela synchronisera le champ path existant dans Sylius.

Extension des entités Sylius

Cette approche s’intègre naturellement aux entités existantes. Par exemple, pour les images produit :

namespace App\Entity\Product;

use Doctrine\ORM\Mapping as ORM;
+use JoliCode\MediaBundle\Bridge\Sylius\Doctrine\ORM\EntityWithMediaImageTrait;
use Sylius\Component\Core\Model\ProductImage as BaseProductImage;

#[ORM\Entity]
#[ORM\Table(name: 'sylius_product_image')]
class ProductImage extends BaseProductImage
{
   +use EntityWithMediaImageTrait;
}

On étend ainsi une entité Sylius sans en modifier le cœur, en ajoutant uniquement la capacité de manipuler un média via le bundle.

Intégration dans le back-office

Enfin, côté administration, l’intégration passe par une extension de formulaire Sylius. Le champ fichier natif est remplacé par un composant dédié au JoliMediaBundle :

class ProductImageTypeExtension extends AbstractTypeExtension
{
   public function buildForm(FormBuilderInterface $builder, array $options): void
   {
       $builder->add('file', MediaChoiceType::class, [
           'property_path' => 'media',
       ]);
   }

   public static function getExtendedTypes(): iterable
   {
       yield ProductImageType::class;
   }
}

Cela permet de brancher directement la médiathèque dans l’interface d’administration Sylius, sans casser les formulaires existants.

Ces Forms extensions sont directement fournies par le bridge, il vous suffit de les déclarer dans Symfony:

# config/services.yaml
services:
   JoliCode\MediaBundle\Bridge\Sylius\Admin\Form\Extension\AvatarImageTypeExtension: null
   JoliCode\MediaBundle\Bridge\Sylius\Admin\Form\Extension\ProductImageTypeExtension: null
   JoliCode\MediaBundle\Bridge\Sylius\Admin\Form\Extension\TaxonImageTypeExtension: null

Le File input est remplacé par celui du Media bundle.

Pour les plus observateurs, vous pouvez remarquer que nous avons modifié le template pour retirer l’aperçu fourni par Sylius nativement.

La Médiathèque est le point fort du Media bundle. Elle permet de visualiser mais également d’organiser votre arborescence.

Une vue « Grid » est également disponible pour afficher les images en plus grand format.

Une page détails du media permet d’obtenir davantage d’informations ainsi que les options d’intégration.

Un onglet « Variations » est disponible afin de consulter les différentes variantes de vos médias, avec leurs tailles, formats et dimensions respectifs.

Il est ainsi possible d’utiliser le système de compression du JoliMediaBundle au lieu du système natif de Sylius (utilisant LiipImagine).

Remplaçons les images dans la liste des produits :

<?php

namespace App\Grid\Mutator;

use Sylius\Bundle\AdminBundle\Grid\ProductGridInterface;
use Sylius\Bundle\GridBundle\Builder\Field\TwigField;
use Sylius\Component\Grid\Builder\GridBuilderInterface;
use Sylius\Component\Grid\Attribute\AsGridMutator;
use Sylius\Component\Grid\Mutator\GridMutatorInterface;

#[AsGridMutator(
    grid: 'sylius_admin_product', 
    // ou
    grid: ProductGridInterface::NAME // constante ajoutée sur Sylius 2.3
)]
class ReplaceImageFromProductGridMutator implements GridMutatorInterface
{
    public function __invoke(GridBuilderInterface $gridBuilder): void
    {
        $gridBuilder
            ->withFields(
                TwigField::create('image', template: 'admin/product/grid/field/image.html.twig'),
            )
        ;
    }
}

Ainsi on remplace le field image en utilisant notre propre template Twig.

<!-- templates/admin/product/grid/field/image.html.twig ->
{% from '@JoliMediaSylius/admin/shared/helper/product_image.html.twig' import image %}


<div class="thumbnail-box-image">
   {{ image(data) }}
</div>

Le résultat est identique en apparence, mais on peut voir que l’image a été traitée par le JoliMediaBundle en y regardant de plus près :

Utilisation dans le shop

Le mécanisme cœur de Sylius n’étant pas modifié, les images continuent de fonctionner comme auparavant côté front. Elles peuvent donc être traitées directement par LiipImagine par défaut, sans nécessiter d’adaptation spécifique. Il n’est pas obligatoire, dans un premier temps, d’aller plus loin que cette intégration côté administration. Il est ensuite possible d’améliorer progressivement la qualité du rendu des images en effectuant les ajustements nécessaires côté front, comme décrit dans la documentation du bundle.

Réorganiser votre médiathèque

Un mécanisme de propagation des changements dans vos entités permet de déplacer ou renommer vos médias librement, sans casser les références existantes dans votre application. Cette approche facilite non seulement la recherche et l’identification des médias dans le back-office, mais également la réorganisation progressive de la médiathèque au fil du temps, que ce soit pour restructurer une arborescence, harmoniser des noms de fichiers ou regrouper certains médias par domaine fonctionnel.

Conclusion

Sylius propose déjà une base solide pour la gestion des médias dans un contexte e-commerce. Le JoliMediaBundle apporte une vision plus transversale et structurée de la gestion des fichiers. Le bridge entre les deux ne cherche pas à opposer ces approches, mais à les faire coexister proprement. En pratique, cette combinaison permet de conserver la simplicité du modèle Sylius tout en introduisant une médiathèque centralisée, réutilisable et plus adaptée à des projets qui grandissent ou se complexifient. C’est aussi une manière de prolonger la philosophie même de Sylius : rester extensible, sans imposer de rigidité, tout en laissant la liberté d’adapter l’architecture aux besoins réels du projet.

Il y a peu, je me suis mis à rejouer à Magic: The Gathering avec des amis. C’est un jeu de cartes à collectionner dans lequel on construit des decks pour affronter ses adversaires à travers divers modes de jeux possibles. Le jeu existe depuis 1993 et n’a cessé d’évoluer depuis. Résultat : même les joueurs et joueuses les plus expérimenté·es se font parfois surprendre par certaines règles ou interactions de cartes. Alors pour moi, qui n’avait pas joué depuis 20 ans , autant vous dire qu’à chaque partie, je passe un bon moment sur Internet à chercher telle ou telle règle pour éviter de faire n’importe quoi. C’est là que je me suis dit que ce serait sympa d’avoir à portée de main un petit assistant à qui poser directement mes questions. Pourquoi ne pas simplement ouvrir ChatGPT ou un autre agent conversationnel, me direz-vous ? Déjà parce que je souhaitais éviter au maximum les hallucinations, comme une réponse qui viendrait d’un fil Reddit d’il y a dix ans et ne correspondrait pas ou plus à la réalité. Ensuite, et surtout, parce que c’était l’occasion parfaite de coder un petit truc et d’apprendre en même temps !  C’est comme ça que j’ai décidé de me lancer dans la création d’une application mobile basée sur des LLM et du RAG. Si vous souhaitez jeter un œil au code (encore un peu en chantier, ne jugez pas), il se trouve sur GitHub.

RAG : qu’est-ce que c’est, et pourquoi ?

Pour nos lecteurs et lectrices francophones, mon collègue Clément a fait un chouette article sur l’architecture RAG ainsi qu’un talk au dernier Forum PHP. C’est d’ailleurs cela qui m’a poussé vers ce choix : je préférais guider le modèle en basant ses réponses sur les règles à jour et la liste des cartes existantes plutôt que de risquer une hallucination. Un chatbot classique aurait aussi potentiellement plus de difficultés, avec de simples recherches web par exemple à déterminer l’interaction entre plusieurs cartes.

J’ai donc choisi le corpus suivant, qui en soit devrait permettre de couvrir la majeure partie des cas d’usage classiques :

• la liste complète des règles de Magic à jour, disponible sur le site web du jeu.
• la liste complète des cartes, téléchargeable via l’API de Scryfall en JSON.

Comme ça, désormais, avec un peu de manipulation de prompt, je peux m’assurer que le chatbot ne répondra qu’en basant ses réponses sur les règles et les cartes, en les citant précisément, et qu’il me répondra “Je ne sais pas” plutôt que d’inventer une réponse.

“Attends, tu fournis l’ensemble des règles et des cartes au contexte du LLM à chaque question que tu poses ?”

Fort heureusement non ! C’est là que la partie RAG intervient. On va tout d’abord préparer un pipeline d’ingestion et d’embedding des données :

Pour les règles, l’idée va être de : 

• Télécharger la liste des règles au format .txt
• Parser et séparer le texte en chunks, qui correspondront chacun à une section (ou sous-section) des règles. À noter que ces chunks n’ont pas de taille fixe : ils s’adaptent au paragraphe de la règle, car il est nécessaire d’avoir l’intégralité de celui-ci pour conserver un maximum de sens.
• Insérer ces chunks en base de données.

Pour base de données, j’ai choisi PostgreSQL. Grâce à son extension pgvector, elle nous permettra par la suite de stocker des versions vectorisées de ces règles, et surtout de les requêter pour faire remonter celles qui ressemblent le plus à la question posée !

Une fois insérée, une ligne de règles va pouvoir ressembler à ça en base : 

On voit qu’elles y sont bien découpées par sous-section.

Pour les plus attentifs·ves, vous avez pu remarquer la colonne “embedding” dans la capture d’écran d’au-dessus, c’est l’étape suivante.

L’embedding, c’est le moment où l’on va transformer le corps du texte de la règle en un vecteur qui portera au mieux la sémantique de cette règle, et qu’on pourra plus facilement comparer aux vecteurs des questions posées, pour trouver les règles qui s’approchent le plus desdites questions. Pour réaliser cela, j’ai choisi de faire au plus simple. Pas besoin de créer son propre modèle d’embedding, nous allons appeler l’API d’OpenAI (choix arbitraire ici, il est aussi tout à fait possible de choisir un modèle de Voyage, ou Qwen3 par exemple) avec comme modèle text-embedding-3-small, qui est peu coûteux, et fait largement l’affaire pour nos besoins. Le flux est très simple : récupérer chaque ligne de la table de règles, envoyer le contenu à l’API d’embedding, recevoir un vecteur et l’insérer dans la ligne correspondante.

Concernant les cartes, même principe au départ :

• Récupérer toutes les cartes au format JSON depuis l’API de Scryfall.
• Décoder le body de la réponse, puis effectuer quelques manipulations pour gérer les cas spécifiques (comme les cartes à double face).
• Insérer le tout dans notre table en base de données.

On a finalement une table qui ressemble à ça : 

Par contre ici, on va spécifiquement choisir de ne PAS embedder les cartes en vecteurs ! 

En effet, lorsque des questions concernant des cartes seront posées, on ne veut pas qu’il y ait une tentative de comparaison sémantique sur les titres des cartes. Une question à propos de la carte “Lightning bolt” ne doit pas essayer de remonter plusieurs cartes dont le titre aurait un sens similaire, au risque de suggérer de mauvaises informations au LLM derrière.

Néanmoins, avoir une tolérance au “fuzzy typing” est tout de même important, et ajouter un index Trigram (grâce à l’extension pg_trgm) sur le nom des cartes nous donne cette flexibilité. 

Et le LLM dans tout ça ?

A ce stade, toutes les données sont prêtes. C’était une étape quasi-offline qui nous a permis d’avoir une base de données remplies pour que le LLM ne puisse piocher que dans ces informations. Elle est potentiellement à répéter tous les quelques mois pour avoir les dernières versions des règles et des cartes.

Voici un schéma explicatif du flux final : 

L’application mobile est une petite app React Native / Expo façon chatbot, avec une zone de saisie utilisateur et un espace pour afficher la réponse finale. Je ne rentrerai pas forcément dans les détails ici, mais le code est disponible sur le dépôt pour les curieux·ses !

Lorsque l’utilisateur envoie son message, celui-ci est réceptionné par un simple serveur HTTP en Go avec quelques routes d’API disponibles, dont la principale : POST /chat est un passe-plat classique qui va prendre la question, la passer à un service, et renvoyer la réponse formatée de ce service.

Regardons donc plutôt le service en question :

func (e *Engine) Answer(ctx context.Context, question string) (*Result, error) {
    p, err := e.prepare(ctx, question)
    if err != nil {
        return nil, err
    }
    answer, err := e.llm.Generate(ctx, p.analysis.AnswerLanguage, p.context)
    if err != nil {
        return nil, err
    }
    return &Result{
        Answer:   answer,
        Analysis: p.analysis,
        Rules:    p.rules,
        Glossary: p.glossary,
        Cards:    p.cards,
    }, nil
}

func (e *Engine) prepare(ctx context.Context, question string) (*prepared, error) {
    analysis, err := e.llm.Preprocess(ctx, question)
    if err != nil {
        return nil, err
    }

    vecs, err := e.embed.Embed(ctx, []string{analysis.QuestionEN})
    if err != nil {
        return nil, err
    }
    query := vecs[0]

    rules, err := retrieval.SearchRules(ctx, e.conn, query, e.k)
    if err != nil {
        return nil, err
    }
    glossary, err := retrieval.SearchGlossary(ctx, e.conn, query, e.k)
    if err != nil {
        return nil, err
    }

    var cards []CardContext
    seen := make(map[string]bool)
    for _, name := range analysis.Cards {
        c, err := retrieval.ResolveCard(ctx, e.conn, name)
        if err != nil {
            return nil, err
        }
        if c == nil || seen[c.OracleID] {
            continue // no confident match, or already added
        }
        seen[c.OracleID] = true
        rulings, err := retrieval.Rulings(ctx, e.conn, c.OracleID)
        if err != nil {
            return nil, err
        }
        cards = append(cards, CardContext{Card: *c, Rulings: rulings})
    }

    return &prepared{
        analysis: analysis,
        rules:    rules,
        glossary: glossary,
        cards:    cards,
        context:  buildContext(question, rules, glossary, cards),
    }, nil
}

const q = `
        SELECT rule_number, section_title, body, embedding <=> $1::vector AS dist
        FROM rules
        WHERE embedding IS NOT NULL
        ORDER BY embedding <=> $1::vector
        LIMIT $2`

const q = `
        SELECT oracle_id, name, mana_cost, type_line, oracle_text, similarity(name, $1) AS sim
        FROM cards
        WHERE name % $1
        ORDER BY sim DESC, length(name)
        LIMIT 1`

Une fois toutes ces infos remontées, il ne nous reste plus qu’à appeler un LLM (ici Sonnet 5, pour de meilleures capacités de raisonnement et de synthèse qu’Haïku, et toujours un prix raisonnable) avec elles pour renvoyer une réponse construite uniquement sur ces résultats !
Voici le prompt :

You are a Magic: The Gathering rules assistant for a casual playgroup.

Answer the question using ONLY the provided context (Comprehensive Rules excerpts, glossary entries, and card data). Follow these rules strictly:

– Ground every claim in the context. Do NOT use outside knowledge of the rules, even if you are confident — the context is the single source of truth.

– Cite the specific rule numbers you rely on, in parentheses, e.g. (601.2a). Every rule claim needs a citation.

– If the provided context does not contain enough to answer correctly, say so plainly (« Je ne suis pas sûr d’après les règles récupérées … ») rather than guessing.

– Be concise and concrete. Walk through the interaction step by step when it is subtle.

– Card data is from Scryfall.

– Write in plain text — no Markdown (no #, *, backticks or tables). Use short paragraphs, and simple « –  » bullets only if a list genuinely helps. The answer is shown in a mobile chat bubble.

– Write your entire answer in the language identified by this ISO code: %s.

La réponse du LLM est alors streamée à l’application mobile, et l’utilisateur la voit s’afficher sur son écran

Voici quelques petits exemples :

Mais si je lui demande des infos qui ne matchent pas :

La conclusion du MJ

En partant d’un simple débat de table sur une obscure règle de Magic datant de 1995, on a fini par mettre sur pied un pipeline RAG complet, robuste et résolument moderne.

De l’ingestion des données au requêtage sémantique dans PostgreSQL avec pgvector, en passant par un double niveau de LLM, notre assistant est désormais paré à toute épreuve. Le tout est propulsé par un serveur en Go et une application mobile React Native / Expo.

Ce petit side project de passionné·e démontre aussi que, bien architecturée, l’IA dépasse le stade de gadget sujet aux hallucinations pour devenir un outil de précision redoutable. Vous souhaitez échanger sur vos problématiques de RAG ? Discutons-en !

Cet article, Un RAG Magique !, est paru en premier sur Les-Tilleuls.coop.

L’idée est séduisante, mais sous sa forme la plus simple (un dump statique, versionné, régénéré à la main) elle a un défaut rédhibitoire : il faut penser à le régénérer dès qu’une migration ou une fixture change. En pratique, un tel dump finit toujours par diverger de la réalité. Soit on oublie de le mettre à jour et les tests tournent sur des données périmées, soit on le régénère « au cas où » à chaque fois, et on perd tout le bénéfice.

J’ai eu l’occasion de mettre tout ça en place sur un projet client, une application Symfony dont la CI commençait à traîner en longueur. C’est ce contexte réel qui sert de fil rouge à cet article : nous allons voir comment transformer cette astuce en un vrai cache, automatique, adressé par son contenu, et qui s’invalide tout seul.

Petites précision avant de commencer :

• Sur ce projet, toute l’automatisation (installation, fixtures, build, tests…) passe par des tâches Castor. Les extraits de code de cet article sont donc des tâches Castor, écrites en PHP, que la CI appelle comme n’importe quelle commande.
• Nous utilisons des runners Github Action self-hosted sur un même serveur. Nous pouvons donc jouer avec le cache en partageant directement des dossiers entre les jobs. Mais il reste possible de faire la même chose avec les runners cloud fournis par Github en jouant avec les actions de cache natives.

Le coût qu’on veut éviter

Préparer la base de données de test de notre application n’est pas anodin. À chaque build, il faut :

• Créer le schéma de la base principale en rejouant les migrations Doctrine (118 migrations, 542 requêtes SQL, ~10 s rien que pour ça) ;
• Provisionner une seconde base, « géographique » : nos entités reproduisent le schéma d’un référentiel fourni par un prestataire tiers, mais on n’importe pas sa base complète, bien trop volumineuse. On fait donc un doctrine:schema:create, puis on charge nos propres fixtures pour cette base, dont un jeu de fichiers SQL d’environ 57 Mo ;
• Charger les fixtures métier (avec Alice) ;
• Générer les localisations à partir de ces données géo, puis recalculer les entités qui en dépendent ;
• Réindexer le tout dans Elasticsearch.

Bout à bout, la seule construction de la base tourne autour de 50 secondes. Et comme chaque suite de tests tourne dans son propre job (PHPUnit, Behat, e2e…), on ne veut surtout pas payer ce coût plusieurs fois. Dans notre CI, un unique job prepare-application construit l’application et la base une fois, et tous les autres jobs en repartent.

Mais même une seule fois par build, c’est déjà trop. La grande majorité des pull requests ne touche ni aux migrations, ni aux fixtures, ni aux modèles. Reconstruire la base à l’identique à chaque push, c’est du gâchis.

L’idée : un snapshot adressé par son contenu

Le raisonnement est simple. L’état final de la base est déterministe : à migrations, fixtures et code de chargement identiques, on obtient exactement la même base. Si on sait résumer « tout ce qui détermine la base » en une empreinte, alors on peut :

1. calculer cette empreinte au début de la préparation ;
2. si un dump correspondant existe déjà, le restaurer et s’arrêter là ;
3. sinon, tout reconstruire comme avant, puis sauvegarder le dump sous cette empreinte pour la prochaine fois.

C’est le principe du cache adressé par le contenu (content-addressed), exactement comme Docker le fait avec ses layers. Mais toute la difficulté tient dans une seule question : comment savoir si le dump en cache est encore valable ?

La clé de cache, le cœur du système

C’est la partie la plus intéressante. La clé est un hash SHA-256 du contenu de tout ce qui influence les données. Voici la fonction qui la calcule :

function fixtures_snapshot_key(): string
{
    $root = PathHelper::getRoot();


    $hash = hash_init('sha256');
    hash_update($hash, SNAPSHOT_VERSION);       // bust manuel global
    hash_update($hash, date('Y-m-d'));          // bucket journalier

    // Les dossiers dont le contenu change le jeu de données
    $dirs = [
        $root . '/application/migrations',
        $root . '/application/fixtures',
        $root . '/application/src/Model',
        $root . '/application/src/Location',
        $root . '/application/src/Command/Debug',
        $root . '/application/src/Command/Location',
    ];

    foreach (finder()->files()->in($dirs)->sortByName() as $file) {
        hash_update($hash, substr($file->getPathname(), \strlen($root) + 1)); // le chemin…
        hash_update_file($hash, $file->getPathname()); // …et le contenu
    }

    // La config Doctrine et le lock des dépendances comptent aussi
    $extraFiles = finder()->files()->in($root . '/application/config/packages')->name('doctrine*.yaml')->sortByName();
    foreach ($extraFiles as $file) {
        hash_update($hash, substr($file->getPathname(), \strlen($root) + 1));
        hash_update_file($hash, $file->getPathname());
    }
    hash_update_file($hash, $root . '/application/composer.lock');

    return hash_final($hash);
}

Trois décisions méritent qu’on s’y arrête.

On hashe le contenu, pas un timestamp ni un hash de commit. C’est ce qui rend le cache correct. Le jour où quelqu’un ajoute une migration ou modifie une fixture, le contenu change, donc la clé change, donc on reconstruit, automatiquement, sans que personne n’ait à y penser. À l’inverse, une pull request qui ne touche qu’un template ou une feuille de style retombe sur la même clé et restaure le dump en quelques secondes. Cerise sur le gâteau : ça marche aussi avec des modifications non commitées, puisqu’on lit les fichiers directement sur le disque.

On inclut le chemin des fichiers dans le hash, pas seulement leur contenu. Sans ça, renommer ou déplacer un fichier sans en changer le contenu passerait inaperçu.

Un bucket journalier (date('Y-m-d')) entre dans la clé. Beaucoup de pages et de requêtes dépendent d’une notion de récence : « les articles publiés ces 7 derniers jours », « les annonces qui expirent bientôt »… Les fixtures qui les alimentent sont donc datées relativement à aujourd’hui. Si on figeait le même dump indéfiniment, ces dates vieilliraient : au bout de quelques jours, une entité « publiée il y a 2 jours » se retrouverait datée d’il y a une semaine, sortirait du périmètre testé, et casserait un test qui vérifie un affichage « récent ». En intégrant la date du jour dans la clé, on force au minimum une reconstruction quotidienne, ce qui garde ces données fraîches sans surcoût notable.

Enfin, une constante SNAPSHOT_VERSION permet d’invalider tous les snapshots d’un coup, à la main, si on modifie la logique de génération elle-même. La ceinture et les bretelles.

Restaurer ou reconstruire

Maintenant que la clé est calculée, le reste est mécanique. Le dump vit dans un dossier persistant, partagé entre les jobs et les builds successifs du runner (le même volume qui sert déjà de cache Composer/Yarn) :

$snapshotFile = "$HOME/fixtures-snapshots/{$key}.sql.gz";

if (file_exists($snapshotFile)) {
    // Hit : on restaure et on repart
    run("gunzip -c {$snapshotFile} | mariadb -h mysql -u root -p***");

    return;
}

// Miss : toute la reconstruction habituelle…
// …puis on sauvegarde pour la prochaine fois :
run("mariadb-dump --single-transaction --databases geo_fixtures app_fixtures \
     | gzip > {$snapshotFile}.tmp.$$ && mv {$snapshotFile}.tmp.$$ {$snapshotFile}");

Deux remarques sur ce bout de code.

Redis et Elasticsearch sont exclus du dump. Redis et Elasticsearch sont des datastores à part. J'ai préféré gardé leur fonctionnement actuel, c'est à dire que nous continuons à les recharger systématiquement, aussi bien sur un hit que sur un miss. Ce n’est pas gênant : ces deux étapes ne représentent que quelques secondes dans la CI. Le gros du temps à gagner était ailleurs.

L’écriture du dump est atomique, et ce détail-là fait toute la différence entre un cache qui marche et un cache qui vous cause plus de soucis qu’autre chose. On écrit dans un fichier temporaire unique (.tmp.$$, avec le PID du process), puis on le renomme (mv). Sur nos runners self-hosted partagés, deux pull requests peuvent très bien construire la même clé au même moment, ou un build peut être annulé en plein mariadb-dump. Sans cette précaution, un autre build restaurerait un dump tronqué et échouerait de façon aléatoire, le pire type de bug de CI. Le mv étant atomique sur un même système de fichiers, un fichier final n’existe que s’il est complet.

Le résultat

Voici les chiffres, mesurés sur deux runs réels de notre CI (même machine, avant et après) :

Le provisionnement de la base (la partie qui reconstruisait les schémas, chargeait les fixtures géo et rejouait les fixtures métier) tombe de ~53 s à ~6 s : un gunzip piped dans mariadb, et c’est tout. Le reste de la tâche (rechargement Redis, réindexation Elasticsearch) tourne dans les deux cas, d’où les ~14 s résiduelles.

Pour la grande majorité des pull requests, celles qui ne touchent pas au modèle de données, la préparation de la base passe donc d’une minute à quelques secondes. Et le jour où l’on touche vraiment aux migrations ou aux fixtures, le cache se reconstruit tout seul, sans qu’on ait à y penser, parce que sa clé a changé.

Si vous ne deviez retenir qu’une chose, ce serait celle-ci : ce qui fait la valeur de ce cache, ce n’est ni la compression ni le mariadb-dump, c’est la clé. Un cache n’est utile que s’il est à la fois agressif (il évite un maximum de travail) et correct (il ne sert jamais de données périmées). En dérivant la clé du contenu exact qui produit la base, on obtient les deux d’un coup, et plus personne n’a à se demander « faut-il régénérer le dump ? ». La réponse est dans le hash.

Sylius E-commerce fournit un grand nombre de grilles prêtes à l'emploi, qu'il est possible de personnaliser pour répondre aux besoins de votre projet.

Jusqu'à présent, cette personnalisation reposait principalement sur des surcharges de configuration YAML ou sur les Grid events. Ces approches fonctionnent toujours, mais elles atteignent rapidement leurs limites dès que l'on souhaite introduire de la logique métier ou bénéficier d'une API plus moderne et plus agréable à utiliser.

Avec la sortie du GridBundle 1.16, qui sera intégré à Sylius 2.3, une nouvelle approche devient la solution officielle : les Grid mutators. Les anciennes méthodes sont désormais dépréciées et disparaîtront progressivement.

Un Grid mutator est une classe PHP chargée de modifier une grille existante avant sa construction. Il s'appuie sur le même GridBuilder que les grilles PHP, offrant ainsi une API typée, facilement testable et familière pour les développeurs Symfony.

Dans cet article, nous verrons pourquoi cette évolution était nécessaire, quels sont les avantages des Grid mutators et comment commencer à les utiliser dès aujourd'hui afin d'anticiper les futures migrations de Sylius.

Un peu d'histoire

Historiquement, les grilles de Sylius sont déclarées dans la configuration du GridBundle.

Sylius fournit des fichiers de configuration pour toutes ses grilles dont vous pouvez voir l'un des fichiers de configuration dans cet exemple.

Bien qu'elles soient encore très puissantes, on ne peut pas appliquer d'intelligence à ces grids, comme retreindre les données selon le profil de l'utilisateur.

Les grilles PHP

Mais depuis de nombreuses années, le composant Grid propose de configurer les grilles en utilisant le Grid builder.

<?php

namespace App\Grid;

use App\Entity\Book;
use Sylius\Bundle\GridBundle\Builder\Field\StringField;
use Sylius\Component\Grid\Attribute\AsGrid;
use Sylius\Component\Grid\Builder\GridBuilderInterface;

#[AsGrid(
    name: 'app_book',
    resourceClass: Book::class
)]
final class UserGrid
{
    public function __invoke(GridBuilderInterface $gridBuilder): void
    {
        $gridBuilder
            ->orderBy('title', 'asc')
            ->withFields(
                StringField::create('title')
                    ->setLabel('Titre'),
                StringField::create('author')
                    ->setLabel('Auteur'),
            )
        ;
    }
}

Comme vous pouvez le voir, la DX est très proche d'un Doctrine QueryBuilder ou d'un Symfony FormBuilder.

Les avantages :

• rapprocher les grilles des FormBuilder et QueryBuilder ;
• bénéficier d'une API typée ;
• améliorer l'autocomplétion ;
• simplifier les tests ;
• éviter les manipulations de tableaux YAML.

De plus, nous sommes maintenant capables d'ajouter de la logique métier.

Exemples :

if (!$this->authorizationChecker->isGranted('ROLE_SUPER_ADMIN')) {
    $gridBuilder->removeField('internalNotes');
}

ou encore

if ($this->featureFlag->isEnabled('new_catalog')) {
    $gridBuilder->addField(...);
}

Customiser une grille

Reprenons pour exemple la grille des produits fournie par Sylius.

Je vous propose, à titre d'exemple, de retirer le champ image en voyant d'abord les anciennes méthodes, puis la nouvelle façon officielle.

En modifiant dans la config du package

Comme les grilles de Sylius E-commerce sont actuellement définies dans la configuration Symfony, nous pouvons utiliser un fichier de configuration pour customiser celle-ci.

Nous pouvons ainsi utiliser ce fichier YAML fourni par Sylius Standard et ajouter la configuration suivante :

# config/packages/_sylius.yaml
sylius_grid:
    grids:
        sylius_admin_product:
            fields:
                image:
                    enabled: false

C'est relativement simple dans ce cas basique, mais, je le rappelle cette façon est dépréciée sur le GridBundle 1.16.

Pour introduire la nouvelle façon, commençons d'abord en utilisant également un fichier de configuration Symfony mais cette fois avec un fichier PHP.

<?php
// config/packages/sylius_grid.php

$gridBuilder = GridBuilder::create('sylius_admin_product')
    ->removeField('image')

return App::config(['sylius_grid' => (new GridConfig())->addGrid($gridBuilder)->toArray()]);

Nous utilisons ici la classe App fournie par Symfony 7.4 (ou 8.x) pour modifier la configuration du GridBundle. Il y a de la fioriture dans ce fichier, mais nous voyons déjà l'usage de la méthode removeField du GridBuilder que nous allons pouvoir utiliser dans le Grid mutator.

Cette API de GridBuilder n'est pas réservée aux fichiers de configuration PHP. C'est justement elle qui est exploitée par les Grid mutators.

En utilisant les Grid mutators

<?php

namespace App\Grid\Mutator;

use Sylius\Bundle\AdminBundle\Grid\ProductGridInterface;
use Sylius\Component\Grid\Attribute\AsGridMutator;
use Sylius\Component\Grid\Builder\GridBuilderInterface;
use Sylius\Component\Grid\Mutator\GridMutatorInterface;

#[AsGridMutator(
    grid: 'sylius_admin_product', 
    // ou
    grid: ProductGridInterface::NAME // constante ajoutée sur Sylius 2.3
)]
class RemoveImageFromProductGridMutator implements GridMutatorInterface
{
    public function __invoke(GridBuilderInterface $gridBuilder): void
    {
        $gridBuilder->removeField('image');
    }
}

Comme vous pouvez le voir, nous utilisons simplement un attribut PHP fourni par le GridBundle qui nous injecte directement le GridBuilder.

Sylius 2.3 nous permettra de basculer entre sa configuration de grilles dans la config (dépréciée) et celle en PHP. Vous pouvez utiliser les mutators dans les deux cas, ce qui facilite la transition. Nous allons donc probablement devoir migrer nos surcharges de configuration de grilles vers des Grid mutators, ce qui nous amène au chapitre suivant.

Convertir les grilles

Si vous utilisez des grilles customs, c'est-à-dire des grilles qui ne sont pas fournies par Sylius directement, vous devez créer un nouveau service qui comportera l'attribut AsGrid. Afin de vous faciliter cette conversion, il existe un outil officiel : le Sylius Grid Converter.

Et pour les surcharges de grilles Sylius ? A l'heure où j'écris ces lignes, l'option mutator n'existe pas encore, mais elle va arriver très prochainement !

Et les Grid events ?

Les Grid events sont l'ancienne solution pour customiser vos grilles si vous souhaitez utiliser du PHP plutôt que de surcharger la config en YAML. Il faut dans ce cas écouter l'évènement GridDefinitionConverterEvent.

namespace App\Grid;

use Sylius\Component\Grid\Event\GridDefinitionConverterEvent;
use Sylius\Component\Grid\Definition\Field;
use Symfony\Component\EventDispatcher\Attribute\AsEventListener;

#[AsEventListener(event: 'sylius.grid.admin_product', method: 'editFields')]
final class RemoveImageFromProductGridListener
{
    public function editFields(GridDefinitionConverterEvent $event): void
    {
        $grid = $event->getGrid();

        $grid->removeField('image');
    }
}

Cela ressemble beaucoup aux grids mutators, mais vous attaquez directement l'objet Grid definition et non le GridBuilder. Le builder fournit davantage de helpers pour vous aider à construire cette définition. Un autre inconvénient de cet event listener est qu'il faut deviner le nom de l'event.

Comme nous le disions plus haut, ces Grid events sont dépréciées dans Sylius GridBundle 1.16, alors débarrassez-vous en.

Conclusion

Les Grid mutators apportent enfin une manière claire, typée et testable de personnaliser les grilles Sylius. En s'appuyant sur le GridBuilder, ils offrent une API moderne, familière aux développeurs Symfony et bien plus adaptée aux besoins actuels que les anciennes surcharges YAML ou les Grid events.

Avec l'arrivée de GridBundle 1.16 et de Sylius 2.3, ils deviennent la nouvelle approche officielle pour faire évoluer les grilles. L'adoption peut se faire progressivement, puisqu'ils sont compatibles aussi bien avec les grilles déclarées en YAML qu'avec les nouvelles grilles PHP.

Si vous commencez dès aujourd'hui à migrer vos surcharges de configuration et vos Grid events vers des Grid mutators, la transition vers les prochaines versions de Sylius sera largement simplifiée. Vous profiterez également d'une API plus agréable à utiliser, plus facile à maintenir et à déboguer au quotidien.

La sécurité des applications ne dépend pas uniquement du code spécifique développé pour un projet, mais également de la robustesse des briques technologiques fondamentales sur lesquelles il repose. Dans cette optique de sécurisation globale des infrastructures, notre coopérative Les-Tilleuls.coop est heureuse d’annoncer la nomination d’Alexandre Daubois au sein de la PHP Foundation en tant que développeur spécialisé en sécurité. L’annonce officielle est disponible directement sur le site web de la fondation.

La gestion des signalements de sécurité à l’ère de l’intelligence artificielle

Ces derniers mois, la PHP Foundation a constaté une augmentation significative du nombre de rapports de sécurité soumis sur le dépôt officiel php-src. Cette hausse est directement liée à l’utilisation croissante des outils d’intelligence artificielle, qui facilitent la génération automatisée de signalements.

Quelque soit la nature de ces rapports, l’équipe restreinte de la fondation doit obligatoirement traiter et valider chaque soumission. Une fois validée, chaque faille potentielle nécessite d’être classifiée, corrigée, revue puis intégrée au code source. Face à ce flux constant, le besoin de renforcer l’équipe s’est avéré nécessaire pour maintenir le rythme des corrections et traiter les problématiques existantes.

Une expertise technique au service de l’écosystème open source

Alexandre consacrera plusieurs heures par semaine au triage et à la résolution de ces rapports de sécurité entrants. Il s’appuiera pour cela sur son expérience technique de l’écosystème (notamment en tant que membre de la Core Team Symfony et contributeur à FrankenPHP et à PHP core) ainsi que sur sa collaboration préalable avec l’Ecosystem Security Team de la fondation.

Cette intégration s’inscrit dans la continuité de la démarche de Les-Tilleuls.coop, dont les interventions vont de la couche applicative jusqu’au cœur même de. En contribuant directement à la maintenance de PHP, la coopérative participe activement à la pérennité et au durcissement de l’outil technique principal de ses clients et partenaires. Sur ce dernier point, l’implication de la coopérative est structurelle : FrankenPHP, le serveur d’application moderne qu’édite la coopérative, a officiellement rejoint l’organisation GitHub de PHP en 2025 sous le parrainage de la PHP Foundation.

L’ensemble des équipes félicite Alexandre Daubois pour cette nomination qui vient valider son expertise et son engagement en faveur d’un web open source sécurisé. Face à la recrudescence des failles de sécurité exposées dans le monde entier, notre équipe reste à vos côtés pour auditer, sécuriser et fiabiliser vos applications au quotidien.

Cet article, Sécurité PHP : Alexandre Daubois rejoint la PHP Foundation pour renforcer le cœur du langage, est paru en premier sur Les-Tilleuls.coop.

Le problème

Un consumer PHP ressemble souvent à ça :

while (true) {
    $message = $queue->consume();

    if (!$message) {
        sleep(1);
        continue;
    }

    $this->process($message);
}

Il tourne en permanence. On ne contrôle pas quand l'itération commence ni quand elle finit. Déclencher Blackfire depuis l'extérieur sans interrompre le traitement en cours, c'est précisément le défi.

La solution : envoyer un signal UNIX au processus pour lui dire "commence à profiler" puis un second signal pour lui dire "arrête-toi et envoie le profil".

Installation de Blackfire

L'installation de Blackfire se fait via Composer :

composer require blackfire/php-sdk

SignalableCommandInterface : gérer les signaux dans une commande Symfony

Depuis Symfony 5.2, le composant Console expose l'interface SignalableCommandInterface. Elle permet à une commande de s'abonner à des signaux POSIX et de réagir proprement sans passer par pcntl_signal() manuellement. L'interface oblige à implémenter deux méthodes :

use Symfony\Component\Console\Command\SignalableCommandInterface;

class MyWorkerCommand extends Command implements SignalableCommandInterface
{
    public function getSubscribedSignals(): array
    {
        return [\SIGTERM, \SIGINT, \SIGUSR2];
    }

    public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false
    {
        // ...
        return false;
    }
}

getSubscribedSignals()

Cette méthode retourne la liste des signaux que la commande veut intercepter. Les signaux sont des constantes entières définies par le système (voir kill -l pour la liste complète). Les plus courants :

handleSignal() : décrypter la signature

public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false

Trois éléments méritent attention :

• int $signal : Le numéro du signal reçu. C'est lui qu'on inspecte avec match ou in_array pour savoir quoi faire ;
• int|false $previousExitCode = 0 : Code de sortie renvoyé par le signal handler précédent, ou false si c'est le premier signal traité dans cette invocation. Utile si plusieurs signal handlers s'accumulent ;
• Valeur de retour int|false : C'est là que ça devient intéressant :
  • retourner false signifie "je ne veux pas quitter, laisse le process continuer" ;
  • retourner un entier (typiquement 0 ou un code d'erreur) signifie "termine le process avec ce code de sortie".

Autrement dit, pour un consumer qui doit continuer à tourner après avoir traité le signal (comme démarrer ou stopper un profil Blackfire), on retourne false. Pour un signal d'arrêt (SIGTERM, SIGINT), on peut soit retourner un code de sortie, soit armer un flag shouldStop et retourner false pour finir proprement l'itération en cours.

Intégrer Blackfire via SIGUSR2

L'idée : on utilise SIGUSR2 comme interrupteur. Premier signal → on démarre la probe Blackfire. Second signal → on l'arrête et on affiche le profil.

use Blackfire\Client;
use Blackfire\ClientConfiguration;
use Blackfire\Probe;

class ResourceAnalyserCommand extends Command implements SignalableCommandInterface
{
    private bool $shouldStop = false;

    public function getSubscribedSignals(): array
    {
        $signals = [\SIGTERM, \SIGINT];

        // On n'ajoute SIGUSR2 que si la lib Blackfire est disponible
        if (class_exists(Client::class)) {
            $signals[] = \SIGUSR2;
        }

        return $signals;
    }

    public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false
    {
        if (\in_array($signal, [\SIGTERM, \SIGINT])) {
            $signalName = SignalMap::getSignalName($signal);
            $this->stop("Signal {$signalName} received.");
        }

        if (\SIGUSR2 === $signal) {
            $client = new Client(new ClientConfiguration(
                $_SERVER['BLACKFIRE_CLIENT_ID'],
                $_SERVER['BLACKFIRE_CLIENT_TOKEN'],
            ));

            static $probe = null;

            if (null === $probe) {
                $this->logger->notice('Blackfire profile started.');
                $probe = $client->createProbe();
            } else {
                $profile = $client->endProbe($probe);
                $this->logger->notice('Blackfire profile finished.', [
                    'url' => $profile->getUrl(),
                ]);
                $probe = null;
            }
        }

        return false;
    }
}

Quelques points notables :

• La variable $probe est static : elle survit entre les appels à handleSignal(). Sans ça, le probe serait perdu entre le premier et le second signal ;
• class_exists(Client::class) : le package blackfire/php-sdk n'est pas forcément installé en production. Cette garde permet d'utiliser SIGUSR2 uniquement quand Blackfire est disponible, sans planter si ce n'est pas le cas ;
• On retourne false : le worker ne doit pas s'arrêter après un signal SIGUSR2. On continue la boucle normalement pendant que Blackfire collecte les données.

Utilisation concrète

# Trouver le PID du worker
ps aux | grep redirectionio:crawler:analyze-resources

# Premier signal : démarrer le profiling
kill -USR2 <pid>

# Laisser tourner quelques itérations...

# Second signal : arrêter le profiling et envoyer le profil
kill -USR2 <pid>

L'URL du profil apparaît dans les logs du worker. On peut ensuite l'ouvrir dans l'interface Blackfire pour analyser les flamegraphs, les appels de fonctions, la mémoire, etc. Exactement comme pour une requête HTTP classique.

Si on ne veut pas ouvrir un deuxième terminal, nous pouvons passer le worker courant en mode "background" avec Ctrl+Z puis bg, et envoyer les signaux depuis le même terminal.

$ bin/console redirection:crawler:analyze-resources -vv
15:00:28 NOTICE    [crawler] Crawl analyzer started.

^Z      #### CTRL+Z au clavier
[1]+  Stopped bin/console redirection:crawler:analyze-resources -vv

$ bg    #### On passe le process en background
[1]+ bin/console redirection:crawler:analyze-resources -vv &

$ kill -SIGUSR2 %1      #### On envoi le signal SIGUSR2 au premier processus en arrière-plan
15:00:50 NOTICE    [crawler] Profile Blackfire started.

$ kill -SIGUSR2 %1      #### On envoi le signal SIGUSR2 au premier processus en arrière-plan
15:01:00 NOTICE    [crawler] Profile Blackfire finished. ["url" => "https://blackfire.io/XXXXXXXX/graph"]

$ fg    #### On repasse le process en avant-plan
[1]+ bin/console redirection:crawler:analyze-resources -vv
### ....

Aparté : gérer l'arrêt proprement avec shouldStop

Un consumer ne peut pas s'arrêter n'importe quand. Si un message est en cours de traitement au moment où SIGTERM arrive (déploiement, restart Kubernetes...), couper brutalement le process risque de laisser des données dans un état incohérent.

Le pattern classique : un flag booléen qu'on arme à la réception du signal, qu'on consulte entre chaque itération.

class ResourceAnalyserCommand extends Command implements SignalableCommandInterface
{
    private bool $shouldStop = false;

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        while (true) {
            // On vérifie le flag en début d'itération, pas pendant
            if ($this->shouldStop) {
                return Command::SUCCESS;
            }

            $message = $this->queue->consume();
            if (!$message) {
                sleep(1);
                continue;
            }

            // Traitement atomique : on ne sera pas interrompu ici
            $this->process($message);
        }
    }

    public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false
    {
        if (\in_array($signal, [\SIGTERM, \SIGINT])) {
            $this->stop('Signal received.');
        }

        return false;  // On ne quitte pas immédiatement !
    }

    private function stop(string $reason): void
    {
        $this->logger->notice("Worker will stop after current task. {$reason}");
        $this->shouldStop = true;
    }
}

L'astuce est dans le return false de handleSignal() : on ne quitte pas immédiatement. On arme juste le flag, et on laisse l'itération en cours se terminer normalement. Le check if ($this->shouldStop) en tête de boucle assure qu'on sort proprement entre deux tâches.

Cette approche est particulièrement importante dans des contextes où le traitement a des effets de bord (écriture en base, appel à une API externe, mise à jour d'un état distribué) et où une interruption au milieu laisserait des données incohérentes.

Conclusion

Profiler un consumer avec Blackfire se résume à trois ingrédients :

1. Implémenter SignalableCommandInterface pour intercepter SIGUSR2 proprement ;
2. Utiliser une variable static dans handleSignal() pour alterner entre "start probe" et "end probe" d'un signal à l'autre ;
3. Retourner false pour que le worker continue à tourner pendant et après le profiling.

Le résultat : on peut déclencher un profil Blackfire sur un consumer en production (ou en staging) sans le redémarrer, sans modifier le code, et sans interrompre le traitement en cours. Un kill -USR2 <pid> suffit.

Le SDK Blackfire fournit ensuite l'URL du profil, qu'on peut analyser dans l'interface Blackfire comme pour n'importe quelle requête HTTP.

Enfin, le SDK propose d'autres fonctionnalités avancées, comme la possibilité de créer des probes avec des paramètres spécifiques, de gérer des scénarios complexes, ou d'intégrer le profiling dans des pipelines CI/CD. Pour plus de détails, consultez la documentation officielle de Blackfire.

Atteindre un bon niveau d’accessibilité demande généralement un travail de fond sur la conception, le contenu et les développements du site. Cependant, certaines améliorations simples, peu coûteuses et rapides à mettre en œuvre permettent déjà d'offrir une expérience plus inclusive à l'ensemble de vos visiteurs.

Dans cet article, je partage les premières actions que j’ai mises en place sur le site de JoliCode. Ces améliorations ont permis de corriger plusieurs problèmes courants et constituent une première étape vers une expérience plus accessible pour toutes et tous.

L’état des lieux

La première étape consiste à réaliser ce qu’on appelle un audit d’accessibilité. Il permet de tester l’ensemble des 106 critères constitutifs du RGAA. Pour cela, l’outil ARA développé par la direction interministérielle du numérique (DINUM) propose une interface en ligne et la génération de rapport et de déclaration de conformité.

Pour ma part, armée de la liste des critères, j’ai passé en revue un échantillon de pages représentatif : la page d’accueil, la page contact, la page blog et une page article. L'objectif était également de mieux connaître les critères du RGAA et les différentes méthodes permettant de les évaluer. La navigation au clavier, l'utilisation d'un lecteur d'écran et quelques extensions de navigateur m'ont permis d'identifier rapidement plusieurs problèmes d'accessibilité. Même si l’accessibilité est prise en compte dès le début de nos projets, les mises à jour et maintenances successives, ainsi que les diverses contributions, ont introduit au fil du temps des erreurs fréquentes et faciles à corriger.

Pour structurer les corrections issues de cet audit, j’ai commencé par regrouper les problèmes identifiés dans un tableau de suivi. L’objectif était de relier chaque point à son critère RGAA et de pouvoir suivre facilement les corrections à mettre en place sur le site. Le format du tableau était le suivant :

Améliorer la lisibilité des contenus

Parmi les erreurs les plus fréquentes, on retrouve souvent des problèmes de contrastes insuffisants. C’est l’un des éléments qui doit être anticipé dès la phase de conception d’un site. Il existe pourtant des outils simples en ligne (et même des plugins Figma) permettant de vérifier le contraste entre une couleur d’arrière-plan et d’avant-plan. Sur le site de JoliCode la couleur rose ainsi qu’un niveau de gris, avaient un contraste insuffisant (sur fond blanc et noir pour le rose, sur fond blanc pour le gris). J’ai utilisé l’outil de Tanaguru permettant de trouver des couleurs similaires respectant les critères de contraste. L’usage du rose a été limité au fond blanc, les liens sur section sombres s’affichant désormais en jaune. Cette modification n'a pas eu d’impact sur l'identité visuelle du site tout en améliorant la lisibilité des contenus.

Faciliter la navigation

Corriger la navigation principale

Le menu de navigation principal comportait plusieurs problèmes :

• Il n’utilisait pas les bons attributs ARIA
• Il n’était pas totalement utilisable au clavier
• Le menu actif était indiqué uniquement par un changement de couleur

Pour corriger la structure du menu, je me suis basée sur le pattern “Disclosure Navigation Menu” du guide de la Web Accessibility Initiative (WAI). Pour ne pas toucher au design mais permettre l’utilisation des sous-menus au clavier, un bouton s’affiche désormais lors de la tabulation et permet d’y accéder. La barre jaune initialement affichée uniquement au survol permet désormais d'indiquer le menu actif, permettant une meilleure visibilité aux personnes qui distinguent difficilement certaines couleurs.

Ajouter un lien d’évitement

S’il est important que le menu de navigation soit accessible, il faut également permettre à l’utilisateur d’accéder facilement au contenu du site, sans forcément avoir à parcourir tout le menu. Ainsi, j’ai ajouté un lien d’accès rapide accessible via la touche tabulation dès l’arrivée sur le site. Il permet aux utilisateurs naviguant au clavier ou avec un lecteur d'écran d’accéder directement au contenu du site.

Structurer l’information

L’utilisation de titres au sein d’une page web est essentielle pour structurer l’information. Elle rend la lecture plus agréable, permet de mettre des mots clés en avant d’un point de vue SEO et certains utilisateurs et utilisatrices s’en servent pour naviguer. Sur ce dernier point il est donc important d’avoir une hiérarchie de titres cohérente : éviter les sauts de titre (passer d’un h2 à un h4 par exemple) et surtout un ordre incohérent (passer d’un h1 à un h3 puis un h2). Pour cela je vous conseille l’extension headings map qui permet de visualiser simplement une erreur dans la hiérarchie de vos titres.

Sur le site de JoliCode, un titre avait été balisé de manière à prendre un certain style mais l’ordre n’était plus cohérent. Le balisage a été changé et le style géré via une classe CSS.

Donner du sens aux images

Vient le sujet majeur de l’accessibilité des images et son fameux attribut alt. On en a tellement entendu parler que certains contributeurs se mettent désormais à le remplir, même quand ce n’est pas nécessaire.

Voici ce qu’il faut retenir :

• une image qui n’apporte pas d’information supplémentaire doit avoir un attribut alt vide. Cela signifie que même si l’image est porteuse d’information, si cette information est présente dans le texte à côté de l’image, il est inutile de l’indiquer dans l’attribut alt. Le lecteur d’écran risquerait de lire deux fois la même information, générant du bruit inutile. Le mieux est l’ennemi du bien.
• En revanche, si l'image est essentielle à la compréhension, il faut remplir l’attribut alt pour la décrire.

Demandez-vous simplement : si on retire l’image, est-ce que l’information reste compréhensible dans son entièreté ? Ou au contraire est-ce que l’on perd de l’information ? Si retirer l’image ne change rien alors elle n’est pas porteuse de sens et l’attribut alt doit être présent, mais vide.

En partant de ce constat, plusieurs attributs alt ont été corrigés, même si, nombre d’entre eux étant contribués dans les pages article, il en reste sûrement à améliorer.

Les SVG méritent également une attention particulière. Pour les SVG en ligne, il faut là aussi, dissocier ceux qui sont porteurs d’information et ceux qui ne le sont pas. Dans le premier cas, il est nécessaire de fournir une alternative textuelle directement dans le SVG, par exemple à l'aide d'un élément <title>.

<svg role="img">
  <title>texte de description</title>
  ...
</svg>

Dans le deuxième cas, l’attribut aria-hidden="true" doit être ajouté à la balise.

<svg aria-hidden="true">
…
</svg>

Rendre les formulaires plus explicites

Lier un champ de formulaire à un libellé est globalement maîtrisé. Mais sur le site de JoliCode, il y a un cas que nous n’avions pas forcément anticipé. Sur la page blog, le formulaire de recherche possède un champ avec un libellé non visible.

Si un label est bien présent dans le code et accessible aux technologies d’assistance grâce à une classe sr-only, il ne satisfait pas le critère 11.1.3 du RGAA :

Même si le champ possède un placeholder, celui-ci disparaissant au focus, le référentiel demande qu’un autre texte visible indique la fonction du champ de formulaire. Afin d’éviter un changement graphique, j’ai ajouté un attribut title pour répondre au critère.

Enseignements et perspectives

Ces différentes corrections représentent finalement peu d’efforts et de lignes de code pour un gain non négligeable pour de nombreuses personnes. Elles correspondent à des erreurs parmi les plus fréquemment rencontrées :

• le respect des contrastes de couleurs,
• la bonne gestion des alternatives textuelles des images et des SVG,
• une navigation entièrement utilisable au clavier,
• l’ajout d’un lien d’évitement,
• et une meilleure explicitation des formulaires.

Pour autant, ce travail ne suffit pas à rendre un site conforme au RGAA. L’accessibilité reste un sujet transversal qui concerne aussi bien la conception, le design, le développement que la production de contenu. Ces premières améliorations constituent donc moins une finalité qu’un point de départ vers une démarche d’amélioration continue.

Keynote d'ouverture avec Pablo Ruiz-Múzquiz : L'avenir du design UX est-il l’open source ?

La matinée s'est ouverte avec Pablo Ruiz-Múzquiz, cofondateur et CEO de Penpot, une plateforme de design UX open source. Physicien de formation, il cofonde en 2011 Kaleidos, une entreprise avec une équipe de designers et développeurs. Pablo porte une conviction forte : les outils que nous utilisons ne sont pas neutres.

Il part d'un constat simple : quand on parle de "l'avenir du design UX", on ne parle pas tous de la même chose. Certains pensent à qui va concevoir, d'autres aux outils utilisés, et d'autres encore à pour qui on conçoit. Pour lui, c'est avant tout une question de capacité à résoudre de vrais problèmes avec les contraintes du réel.

Si le matériel reste la contrainte principale de nos usages, il n'évoluera pas de sitôt (smartphones, laptops, claviers, souris, sans évolution imminente à l'horizon). C'est donc du côté du software que viendra le changement, notamment via les LLM. Deux conséquences concrètes : des expériences de plus en plus personnalisées pour chaque utilisateur, et l'émergence d'agents IA qui utilisent nos interfaces exactement comme nous le ferions. Ce dernier point soulève une question nouvelle pour les designers : comment concevoir une interface qui fonctionne bien à la fois pour un humain et pour un agent IA ? C'est ce que Pablo appelle la frontière entre UX et AX et cette frontière va progressivement devenir flou.

Avant de parler de Penpot, Pablo s'arrête sur ce qu'est vraiment l'open source. Ce n'est pas une collection de logiciels gratuits, c'est un mécanisme juridique qui redistribue des libertés. Il produit trois choses concrètes : de la confiance car le code est auditable, une collaboration distribuée à l'échelle mondiale, et une souveraineté numérique difficile à abandonner une fois acquise.

Pour illustrer ces convictions, Pablo détaille les cinq choix structurants de Penpot :

1. Être open source pour ne pas laisser le marché aux seuls acteurs dominants, même si cela implique une gouvernance plus complexe des communautés ;
2. Adopter un design basé sur les standards CSS (Flexbox, Grid, tokens natifs) pour créer une correspondance directe avec le code ;
3. Proposer une interface familière aux outils existants pour réduire la courbe d'apprentissage ;
4. Parier sur les standards ouverts, même quand ça coûte des mois de refonte ;
5. Faire de Penpot un outil autant pour les designers que pour les développeurs, ces derniers y sont aujourd'hui deux fois plus nombreux.

Sa question de clôture est simple : quels seront vos choix de design ?

Chez JoliCode, l'open source est au cœur de notre travail et des outils que nous mettons en place. Pablo n'a fait que nous donner de bons arguments pour continuer.

Matthieu Froidure : Comment l'IA peut compléter (sans remplacer) une démarche d'accessibilité numérique ?

Matthieu Froidure est aveugle depuis quinze ans et expert en accessibilité chez Urbilog. Il arrive sur scène et avant tout, il veut mettre la salle dans sa peau.

Il demande au public de se lever, de fermer les yeux, et de serrer la main du voisin le plus proche. "Vous venez de perdre 70% de votre information quotidienne." L'expérience est assez troublante.

Avant d'aborder l'IA, Matthieu pose le cadre légal sur l’accessibilité. En France, l'accessibilité numérique est une obligation depuis 2005 pour le secteur public, étendue aux grandes entreprises en 2016. Mais c'est en juin 2025 que tout change avec l'European Accessibility Act : toute entreprise avec plus de 2 millions d'euros de chiffre d'affaires ou 10 salariés ayant une relation directe avec des clients est désormais concernée. C’est un enjeu important.

Ce cadre posé, il entre dans le vif du sujet : respecter les 106 critères du RGAA ne garantit pas qu'une interface soit utilisable. Il diffuse deux versions sonores d'un même tableau INSEE, une d'abord inaccessible, puis une version conforme. Dans les deux cas, comprendre les données demande un effort cognitif considérable. Un site peut être accessible sur le papier mais incompréhensible en conditions réelles.

C'est là que l'IA entre en jeu et Matthieu en dresse un portrait nuancé. L’IA peut être utile pour réexprimer une information complexe, la délivrer à l'oral et répondre à des questions précises (par exemple pour lire un tableau de garanties mutuelles, adapter le contenu en Facile à Lire et à Comprendre pour les personnes déficientes intellectuelles). Il en a lui-même fait l'expérience avec Claude pour installer un logiciel via son lecteur d'écran NVDA, et globalement ça a marché.

Mais l'IA a trois biais qu'il faut garder en tête :

• Le biais d'information : elle peut donner des réponses fausses avec la même conviction que des réponses exactes ;
• La peur du silence : elle préfère inventer plutôt que se taire ;
• Le biais de complaisance : elle ne contredira jamais l'utilisateur même s'il a tort.

Matthieu en a fait les frais lui-même en demandant à une IA un itinéraire de transport à Paris et il s'est retrouvé à errer une demi-heure dans la mauvaise direction.

Matthieu appuie donc sur l’importance de tester nos interfaces avec des extreme users. L'IA n'a pas les données pour couvrir ces cas extrêmes mais ce sont précisément ces cas qui une fois résolus bénéficient à tous. La télécommande a été conçue pour les personnes à mobilité réduite. Le SMS pour les sourds.

Sa conclusion est simple : concevoir pour les extrêmes, c'est concevoir mieux pour tout le monde.

Antoine Pezé, Les choix qu’on ne faisait pas : quand un designer reprend le pouvoir sur le code

Antoine Pezé est UX designer et entrepreneur depuis une quinzaine d'années, ancien coach UX chez Leroy Merlin. En octobre 2025, il se lance seul dans le développement d'une application mobile autour du jeu de cartes Riftbound, sans savoir coder et avec Claude Code comme seul partenaire.

Il en tire quatre enseignements qu'il n'aurait jamais vus sans avoir été confronté au code.

Premier enseignement : tester en conditions réelles révèle des choix de design invisibles. En voulant afficher 50 000 tournois d'un coup, l'application plantait. La solution n'était pas technique, c'était un choix de design qu'il n'avait pas fait au préalable. Airbnb n'affiche que 270 résultats par recherche, pas plus. La performance est une dimension UX qu'on délègue habituellement au développeur et en travaillant seul directement dans le code, Antoine a dû se confronter à de nouvelles problématiques.

Deuxième enseignement : réduire la boucle de feedback rend les maquettes facultatives. Après quelques semaines, Antoine réalise qu'il n'utilise plus Figma depuis six mois. Il décrit son intention, Claude propose un design, et il itère directement depuis le code. Le code est devenu un support d'itération qui remplace le sketch et ça change tout à sa manière de concevoir.

Troisième enseignement : discuter avec une IA pousse à beaucoup mieux spécifier. En lui demandant de designer une page et de remonter les cas limites, Antoine se retrouve face à une dizaine de questions précises sur la densité de navigation, l'intégration dans l'onboarding, ou encore la terminologie. Des questions qu'il n'aurait pas forcément formulées seul.

Quatrième enseignement : mettre du code en production efface les frontières entre design et développement. Antoine avoue lui-même avoir du mal à définir son activité car il ne sait pas lire une ligne de code, mais ce qu'il fait se rapproche davantage d'un job de développeur. Il a réussi à mettre une application en production sur iPhone et Android, intégrer de l'OCR pour scanner des cartes, récupérer et analyser des données satellites pour détecter des coupes sauvages en France. Des choses qu'il pensait impossibles il y a encore six mois. Et il pose la question symétrique : qu'est-ce qui empêche un développeur de designer, maintenant que les maquettes peuvent être générées par l'IA ?

Antoine conclut sur une note réaliste. Claude Code fonctionne très bien sur des projets jeunes, des prototypes et des contextes où l'enjeu est d'explorer. Ce qu'il retient surtout, c'est le sentiment de pouvoir enfin explorer sans limite et seul. Mais cette liberté a ses limites dès qu'on entre dans le monde de l'entreprise. Sur des projets legacy avec des années de règles métier, c'est une autre affaire. Antoine affirme que la vraie barrière qui résiste n'est pas la production, c'est la prise de décision. Selon une étude du MIT, 95% des projets IA en entreprise en 2025 n'ont pas généré de valeur, non pas parce que les modèles étaient mauvais, mais parce que les organisations ne savaient pas se mettre d'accord sur ce qu'il fallait construire. L'IA peut produire plus vite, encore faut-il savoir quoi lui demander.

Anna E. Cook : L'accessibilité comme infrastructure à l'ère de l'IA

Anna E. Cook, product et systems designer spécialisée en accessibilité et design inclusif, ouvre l'après-midi avec un message clair : l'IA ne rendra pas vos interfaces accessibles à votre place. Elle le démontre en déconstruisant quatre mythes.

Premier mythe : l'IA rendrait enfin nos interfaces vraiment adaptatives. Faux. Les utilisateurs ont toujours zoomé, changé la taille de leur texte, modifié leurs paramètres. La variabilité était déjà là avant l’IA.

Deuxième mythe : le diagnostic médical comme stratégie de design. Nielsen, figure incontournable de l'UX, a proposé de personnaliser une interface en fonction du diagnostic d'un utilisateur. Anna s'y oppose car le diagnostic arrive souvent longtemps après que le besoin s'est manifesté. Elle en sait quelque chose car pendant des mois sa vision s'est dégradée sans qu'elle ait encore de diagnostic. Ce dont elle avait besoin : zoomer et agrandir le texte, cela ne nécessitait donc aucun étiquetage médical. Deux personnes avec le même diagnostic peuvent avoir des besoins très différents et inversement. Ce qui compte c'est la variabilité des besoins, pas le diagnostic.

Troisième mythe : plus une interface est personnalisée, meilleure elle est. Anna nuance. Une interface qui change constamment pour s'adapter à vous fragilise vos repères, pourtant essentiels. Imaginez vous connecter à votre application bancaire et ne plus reconnaître rien : les menus ont bougé, les couleurs ont changé. Vous êtes perdu. La bonne approche est celle de GitHub : tous les liens sont soulignés par défaut pour ceux qui en ont besoin, mais chacun peut désactiver cette option. En résumé, d'abord garantir les besoins essentiels et ensuite laisser la liberté d'adapter.

Quatrième mythe : l'IA peut réparer une structure d'accessibilité cassée. C’est faux. Les modèles ont été entraînés sur un web massivement inaccessible et reproduisent ce qu'ils ont appris. Un collègue d'Anna chez Microsoft évalue quotidiennement les LLM sur leur capacité à produire du code conforme WCAG. Résultat : au mieux 30% de réussite par défaut. Les données WebAIM 2026 confirment cette tendance : 95,9% des pages d'accueil présentent des erreurs d'accessibilité de base, avec une hausse de 10% des erreurs par page. Une tendance attribuée en partie à la généralisation de l'IA dans la production de code.

En réponse à ses mythes, Anna propose six questions à se poser avant d'intégrer l'IA dans un système : quels sont nos biais de design ? Quels éléments ne doivent jamais changer ? Qui est responsable des sorties de l'IA ? Quelle est l'expérience par défaut sans IA ? Quels signaux les utilisateurs envoient-ils déjà via leurs paramètres OS et navigateur ? Et surtout, est-ce que l'IA résout réellement un problème ici ?

Anna n'est pas contre l’IA, elle est pour l’utiliser avec intention. Elle le rappelle clairement : l'IA a des coûts réels, financiers, opérationnels, environnementaux et n'est pas la bonne réponse à chaque problème.

Elle termine sur un message clair pour les designers : "Tous les produits n'ont pas besoin de l'IA. Mais chaque produit a besoin de systèmes accessibles et bien conçus.”

Bastien Hughes : Designer, l’IA va nous rendre idiots… ou meilleurs

Bastien Hughes, Head of Design chez Bouygues Telecom, pose d'emblée une question volontairement provocatrice : l'IA va-t-elle nous rendre idiots ou meilleurs ? Sa réponse : les deux, cela dépend de comment on l'utilise.

Pour introduire son propos, Bastien remonte soixante-treize ans en arrière. En 1953, Albert Ducrocq, ingénieur français et créateur du premier robot français, publiait L'Ère des robots. Sa mise en garde est étonnamment actuelle : "Il doit y avoir un juste équilibre entre la part humaine et la vie artificielle." D’autres penseurs feront écho à cette inquiétude dans les décennies suivantes.

Ces mises en garde sont aujourd'hui confirmées par la science. Pourquoi avons-nous cette tendance naturelle à déléguer ? Parce que le cerveau, qui représente 2% de notre poids mais consomme 20% de notre énergie, cherche naturellement à économiser ses ressources. Le GPS a affaibli notre sens de l'orientation. Le correcteur orthographique a baissé notre vigilance. Aujourd'hui, un quart des utilisateurs français d'IA déclarent déjà ne plus être capables d'effectuer certaines tâches sans elle.

Trois facteurs aggravent cette tendance. D'abord, le design des IA elles-mêmes est conçu pour capter notre attention et contourner notre esprit critique. Ensuite, la pression des entreprises à mettre de l'IA partout, souvent sans se demander si elle résout un vrai problème. Enfin, l'argument économique : réduire les coûts, augmenter la productivité. Résultat, comme le résume Maslow : "Quand le seul outil dont vous disposez est un marteau, tout ressemble à un clou."

Pourtant, quand l'IA répond à un vrai besoin, Bastien le confirme : ça fonctionne. Le Bon Coin en est un bon exemple. En générant automatiquement les descriptions d'annonces à partir d'une photo et d'un titre, ils ont résolu un vrai problème : rédiger dix annonces, c'est long et fastidieux pour beaucoup d'utilisateurs.

C'est dans cet esprit que Bastien propose un cadre : le Nutri-Score de l'IA. En bas de l'échelle (E), l'usage le plus néfaste : je demande, l'IA exécute et je valide sans réfléchir. En haut (A), l'usage le plus bénéfique : je structure ma pensée et je sollicite l'IA pour me challenger, elle me pose des questions qui m'obligent à raisonner. C'est ce qu'il appelle le "ping-pong de la pensée”.

L'IA permet aussi de tester ses idées plus tôt dans le processus. Prototyper rapidement, itérer avec des personas IA, tester avant de présenter.

Bastien conclut : l'IA nous rendra idiots ou meilleurs selon l'usage qu'on en fait.

Marine Lochet : Fiction et design : concevoir depuis ce qui dérange

Marine Lochet, designer et auteure, est la dernière conférencière que nous souhaitons vous présenter et son intervention mérite qu'on s'y attarde. Elle démarre par trois récits, deux fictifs et un réel, apportant une atmosphère particulière dans la salle.

Le premier, Never Let Me Go de Kazuo Ishiguro : des enfants élevés dans un pensionnat idyllique, destinés à donner leurs organes. Tout a été si bien lissé qu'ils acceptent leur propre fin comme une formalité.

Le deuxième, BioShock : un personnage qui n'a jamais pris une seule décision, sa liberté n'était qu'un scénario écrit par quelqu'un d'autre.

Le troisième, réel celui-là : le scroll infini, inventé par Aza Raskin pour fluidifier la navigation. Quelques années plus tard, il réalise qu'il a créé un mécanisme de capture de l'attention humaine.

Trois récits avec une même mécanique : le design comme machine à lisser le réel jusqu'à rendre la résistance impossible. Ce mécanisme, Marine le retrouve au cœur même de notre pratique, dans un principe que tous les designers connaissent : "Don't Make Me Think" de Steve Krug. L'idée : une interface doit être si intuitive que l'utilisateur n'a jamais à réfléchir pour l'utiliser. On l'applique désormais aux formulaires de résiliation, aux paramètres de consentement, aux confirmations de paiement, là où la friction peut protéger l’utilisateur. Car face à une décision importante, un moment de résistance force la délibération consciente.

On a supprimé la charge cognitive inutile, mais on a supprimé avec elle la capacité à vraiment choisir.

Marine applique ce même regard à notre vocabulaire de designer. Dire "utilisateur" plutôt que "personne", ces mots décrivent les humains du point de vue du système et rendent certaines questions morales impossibles à formuler. Optimiser un tunnel de conversion, c'est une compétence technique. Décider ce qu'on est prêt à faire subir à une personne pour l'atteindre, c'est une responsabilité.

Pour illustrer concrètement cela, elle distingue deux types de friction. Les frictions négatives qui manipulent ou épuisent l'utilisateur contre son intérêt :

• Dark pattern : trompe activement (écrire "renoncer à vos avantages" plutôt que "se désabonner").
• Sludge : épuise délibérément (un formulaire de résiliation en douze étapes).

Et les frictions positives qui orientent ou éclairent dans son intérêt :

• Nudge : oriente sans contraindre (arrondir automatiquement ses achats pour alimenter un livret d'épargne).
• Boost : force la conscience (demander à l'utilisateur de taper le mot "supprimer" plutôt que de simplement cliquer sur valider).

L'enjeu, Marine le formule simplement : remplacer la fluidité anesthésiante par une friction émancipatrice.

Ce que nous retenons de cette journée

Six conférences avec une conviction partagée : l'IA est un outil et non une solution. Ce qui fait la valeur du designer aujourd'hui est sa capacité à concevoir avec intention avec une vraie conscience de l'impact de ses choix.

C’est un grand classique lorsque l'on utilise le composant Process de Symfony. Pour comprendre l'origine de ce comportement (et surtout comment y remédier), il faut plonger un instant dans la façon dont Linux gère les flux et les terminaux. Rassurez-vous, c'est plus simple qu'il n'y paraît.

Retour aux bases : les flux standards

Sous Linux, chaque processus dispose par défaut de trois flux standards, identifiés par des descripteurs de fichiers (file descriptors) :

• 0 : STDIN (l'entrée standard)
• 1 : STDOUT (la sortie standard)
• 2 : STDERR (la sortie d'erreur standard)

Ce qu'il faut retenir, c'est que ces flux se comportent comme de simples tuyaux. Ce qui se trouve au bout du tuyau détermine le comportement du programme. Généralement, on rencontre trois scénarios :

1. Un fichier : Par exemple, lorsque vous redirigez une sortie avec ls > file.txt ;
2. Un PTY / TTY (Terminal) : Lorsque vous exécutez la commande directement devant votre écran ;
3. Un pipe (tube) : Lorsque vous enchaînez des commandes (ls | grep php) ou que vous lancez un sous-processus de manière programmatique.

Le "problème" de l'exécution programmatique

Par défaut, quand vous utilisez le composant Process pour lancer une commande, Symfony utilise des pipes (notre troisième scénario).

Le programme exécuté (prenons Composer) est intelligent : il analyse ce qui se trouve au bout du tuyau de sa sortie standard (STDOUT). S'il détecte un pipe au lieu d'un terminal, il en déduit qu'il est exécuté par une machine ou un script. Pour éviter de polluer d'éventuels fichiers de logs avec des caractères invisibles (les fameux codes ANSI qui génèrent les couleurs) ou des barres de progression illisibles, il bascule automatiquement en mode "texte brut".

C'est pour cette raison exacte que vos couleurs disparaissent.

La méthode setTty(true) : le lien direct

Le composant Process propose une première solution avec la méthode setTty(true).

En l'activant, vous branchez directement les flux de votre sous-processus sur le vrai terminal de votre système (celui depuis lequel vous avez lancé votre script PHP).

La conséquence : Les couleurs et les animations sont de retour. La commande s'affiche exactement comme si vous l'aviez tapée vous-même. La limite : Puisque le flux est branché directement sur votre écran, votre script PHP n'y a plus accès. La synchronisation automatique fait que l'affichage est immédiat, mais il devient impossible de capturer la sortie avec un $process->getOutput() pour l'inspecter.

La magie de setPty(true) : l'illusion parfaite

C'est ici qu'interviennent les Pseudo-Terminaux (PTY).

Lorsque vous utilisez setPty(true), vous demandez au système de créer un terminal émulé de toutes pièces. Un PTY fonctionne comme un duo composé d'un contrôleur et d'un terminal virtuel :

1. Le script PHP (via Symfony Process) agit comme le contrôleur.
2. Le processus enfant (votre commande) est branché sur le terminal virtuel émulé (qui prend la forme d’un fichier dynamique, souvent /dev/pts/X).

Pour le processus enfant, l'illusion est totale. Il détecte bien un terminal au bout de son tuyau et génère donc ses couleurs et ses barres de progression interactives.

Côté PHP, en tant que "contrôleur" du PTY, la donne change : l'envoi vers l'écran n'est plus automatique (il agit comme un buffer). C'est à vous de lire ce qui sort du terminal virtuel. Vous retrouvez ainsi le meilleur des deux mondes : vous forcez le programme à conserver son affichage riche, tout en gardant la capacité d'intercepter et de manipuler le flux sortant directement dans votre code PHP.

Démo time !

On commence avec une commande Symfony qui affiche, si l'exécuteur le permet, des choses en couleur :

#!/usr/bin/env php
<?php
require __DIR__.'/vendor/autoload.php';

use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\SingleCommandApplication;

new SingleCommandApplication()
    ->setCode(function (OutputInterface $output): int {
        $output->writeln('<info>Hello World!</info>');
        $output->writeln('<comment>This is a single command application.</comment>');
        $output->writeln('<error>Goodbye!</error>');

        return 0;
    })
    ->run();

Ensuite, nous exécutons cette commande Symfony, avec le composant Process. En fonction des arguments, nous activons ou non PTY ou TTY :

<?php

require __DIR__.'/vendor/autoload.php';

$process = new Symfony\Component\Process\Process([__DIR__ . '/console.php']);

$process->setTty(($argv[1] ?? '') === 'tty');
$process->setPty(($argv[1] ?? '') === 'pty');

$process->mustRun();

echo "\nOutput captured:\n";

dump($process->getOutput());

Et voici le résultat :

En résumé

Si vous construisez des outils en ligne de commande ou des workers asynchrones en PHP :

• Par défaut (Pipes) : À privilégier pour les tâches de fond où la sortie doit être parsée ou logguée proprement, sans caractères d'échappement ;
• setTty(true) : Idéal si vous voulez simplement déléguer l'affichage et l'interactivité à l'utilisateur, sans avoir besoin d'analyser la sortie côté PHP ;
• setPty(true) : La solution de choix pour forcer un affichage riche (couleurs, animations) tout en conservant le contrôle du flux sortant dans votre script.

Symfony a très vite adopté cette nouveauté. On les utilise aujourd'hui partout : pour configurer les routes, ajouter des contraintes de validation ou déclarer des listeners.

Dans cet article, nous allons voir comment créer et ajouter un attribut PHP personnalisé sur un contrôleur pour lui injecter un comportement automatique, comme du logging.

1. Créer un attribut

La première étape consiste à créer une classe PHP classique. Pour indiquer qu'elle servira d'attribut, on lui ajoute elle-même l'attribut natif #[\Attribute] :

namespace App\AuditLog;

use Psr\Log\LogLevel;

#[\Attribute(\Attribute::TARGET_METHOD | \Attribute::TARGET_CLASS)]
class Loggable
{
    public function __construct(
        public string $level = LogLevel::INFO,
    ) {
    }
}

Les paramètres du constructeur sont optionnels. Ils permettent de passer des options au moment où on utilise l'attribut. Ici, notre propriété $level sert à définir le niveau de log souhaité.

2. Utiliser l'attribut sur un contrôleur

Une fois notre classe créée, nous pouvons l'appliquer directement sur un contrôleur, soit sur la classe entière, soit sur une méthode (action) spécifique :

namespace App\Controller;

use App\AuditLog\Loggable;
use Psr\Log\LogLevel;
use Symfony\Bridge\Twig\Attribute\Template;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Attribute\Route;

#[Loggable()]
final class HomepageController extends AbstractController
{
    #[Loggable(LogLevel::CRITICAL)]
    #[Route('/', name: 'app_homepage')]
    #[Template('homepage/index.html.twig')]
    public function index(): void
    {
    }
}

Ici, la méthode index hérite de la configuration par défaut de la classe, et ajoute un nouveau niveau de log plus critique (CRITICAL).

3. Créer le listener pour activer le comportement

Pour que notre attribut serve à quelque chose, il faut intercepter l'appel du contrôleur. Symfony déclenche l'événement ControllerEvent juste avant d'exécuter l'action d'un contrôleur. C'est le moment idéal pour vérifier la présence de notre attribut.

Selon votre version de Symfony, l'implémentation est devenue de plus en plus simple.

Avec Symfony 6.2+

On utilise la méthode getAttributes() de l'événement pour récupérer notre attribut et appliquer notre logique :

namespace App\AuditLog;

use Psr\Log\LoggerInterface;
use Psr\Log\NullLogger;
use Symfony\Component\EventDispatcher\Attribute\AsEventListener;
use Symfony\Component\HttpKernel\Event\ControllerEvent;

class LoggerListener
{
    public function __construct(
        private readonly LoggerInterface $logger = new NullLogger(),
    ) {
    }

    #[AsEventListener(priority: -100)]
    public function logSymfony62(ControllerEvent $event): void
    {
        foreach ($event->getAttributes()[Loggable::class] ?? [] as $attribute) {
            $this->logger->log($attribute->level, 'Controller is loggable', [
                'controller' => $event->getController(),
            ]);
        }
    }
}

Avec Symfony 8.1+

Symfony 8.1 a introduit des événements spécifiques aux attributs. Plus besoin de boucler manuellement, l'événement contient directement l'attribut ciblé :

use Symfony\Component\HttpKernel\Event\ControllerAttributeEvent;
use Symfony\Component\HttpKernel\KernelEvents;

class LoggerListener
{
    #[AsEventListener(KernelEvents::CONTROLLER . '.' . Loggable::class, priority: -100)]
    public function logSymfony81(ControllerAttributeEvent $event): void
    {
        $this->logger->log($event->attribute->level, 'Controller is loggable', [
            'controller' => $event->kernelEvent->getController(),
        ]);
    }
}

Avec Symfony 8.2+

La version 8.2 simplifira encore la syntaxe grâce à un attribut dédié (AsControllerAttributeListener) qui cible directement notre classe :

use Symfony\Component\HttpKernel\Attribute\AsControllerAttributeListener;
use Symfony\Component\HttpKernel\Event\ControllerAttributeEvent;
use Symfony\Component\HttpKernel\Event\ControllerEvent;

class LoggerListener
{
    #[AsControllerAttributeListener(ControllerEvent::class, Loggable::class)]
    public function logSymfony82(ControllerAttributeEvent $event): void
    {
        $this->logger->log($event->attribute->level, 'Controller is loggable', [
            'controller' => $event->kernelEvent->getController(),
        ]);
    }
}

Conclusion

Les attributs apportent une grande souplesse à l'écosystème PHP, et Symfony propose des outils parfaits pour les exploiter.

Grâce à eux, vous pouvez ajouter des comportements à vos contrôleurs de manière propre et déclarative, sans polluer vos méthodes avec du code répétitif.

Bien sûr, Symfony intègre déjà nativement des attributs puissants pour gérer la sécurité (#[IsGranted]), le cache (#[Cache]), ou encore le rate limiting (#[RateLimit]). Mais créer vos propres attributs ouvre la porte à des cas d'usage métiers très intéressants :

• Le Feature Flipping (#[FeatureFlag('new-dashboard')]) : pour activer ou désactiver l'accès à une route selon le déploiement progressif d'une fonctionnalité ;
• La télémétrie et l'observabilité (#[TrackActivity('checkout')]) : pour envoyer des statistiques précises à des outils tiers comme OpenTelemetry ou Plausible dès qu'un utilisateur visite une page clé ;
• La transformation de réponse (#[Serialize]) : pour intercepter le retour de vos contrôleurs et le formater automatiquement selon un standard précis (comme le format JSON d'une API spécifique).

Les possibilités n'ont de limite que votre imagination !

Le projet open source qui nous importe aujourd'hui est Castor 🦫, que nous vous invitons à découvrir.

Pour nous aider dans cette tâche, nous avons choisi zizmor. C'est un outil d'analyse statique de code. Il détecte les vulnérabilités dans vos fichiers de configuration de CI et propose souvent des correctifs. Pour faire simple, c'est l'équivalent de PHPStan, mais pour vos workflows.

Une fois installé, une simple exécution (zizmor .) permet de détecter les erreurs de configuration et de les corriger rapidement. Nous avons ainsi amélioré notre sécurité et facilité la maintenance à long terme.

Voici un exemple de rapport généré par l'outil :

error[unpinned-uses]: unpinned action reference
  --> ./.github/actions/cache/action.yaml:48:13
   |
48 |       uses: actions/cache@v5
   |             ^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High
   = note: this finding has an auto-fix
   = help: audit documentation → https://docs.zizmor.sh/audits/#unpinned-uses

help[artipacked]: credential persistence through GitHub Actions artifacts
  --> ./.github/workflows/artifacts.yml:16:9
   |
16 |         - name: Checkout
   |  _________^
17 | |         uses: actions/checkout@v6
   | |_________________________________^ does not set persist-credentials: false
   |
   = note: audit confidence → Low
   = note: this finding has an auto-fix
   = help: audit documentation → https://docs.zizmor.sh/audits/#artipacked

error[github-env]: dangerous use of environment file
  --> ./.github/actions/cache/action.yaml:14:7
   |
14 | /       run: |
15 | |         set -e
16 | |
17 | |         # Should be the same command as the one in tools/static/castor.php
...  |
44 | |         echo cache_dirname_test=$cache_dirname_test >> $GITHUB_ENV
45 | |         echo cache_key_test=$cache_key_test >> $GITHUB_ENV
   | |__________________________________________________________^ write to GITHUB_ENV may allow code execution
   |
   = note: audit confidence → Low
   = help: audit documentation → https://docs.zizmor.sh/audits/#github-env

error[template-injection]: code injection via template expansion
  --> ./.github/actions/install/action.yaml:28:108
   |
28 |       run: composer install --prefer-dist --no-progress --optimize-autoloader --classmap-authoritative ${{ inputs.composer-flags }}
   |       --- this run block                                                                                   ^^^^^^^^^^^^^^^^^^^^^ may expand into attacker-controllable code
   |
   = note: audit confidence → High
   = note: this finding has an auto-fix
   = help: audit documentation → https://docs.zizmor.sh/audits/#template-injection

Un grand nombre d'erreurs peuvent être corrigées automatiquement :

zizmor . --fix=all

Cependant, pour trouver le hash de commit correspondant à un tag, l'outil a besoin d'un token GitHub avec les bonnes permissions. Il convient donc de le relancer avec la variable configurée :

GITHUB_TOKEN=ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX zizmor --fix=all

Ou, si vous utilisez la CLI gh au quotidien :

GITHUB_TOKEN=`gh auth token` zizmor --fix=all

En revanche, zizmor ne gère pas les montées de version majeures des actions. Pour cela, nous utilisons deux autres méthodes.

En local, nous exécutons actions-up. Cet outil détecte les actions utilisées et propose des mises à jour. C'est le composer update de vos workflows.

En CI, nous faisons confiance à Dependabot. Il vérifie régulièrement vos dépendances et ouvre des Pull Requests automatiquement. Voici notre configuration :

version: 2
updates:
    - package-ecosystem: 'github-actions'
      directory: '/'
      target-branch: 'main'
      schedule:
          interval: 'monthly'
      groups:
          github-actions:
              patterns:
                  - '*'
      cooldown:
          default-days: 7

En conclusion, nous vous recommandons vivement d'adopter zizmor. C'est un outil puissant, rapide à prendre en main, qui sécurise vos pipelines et vous fait gagner un temps précieux au quotidien.

Tout savoir sur les satellites

Vous êtes-vous déjà demandé comment Internet arrivait jusqu’à vos téléphones ? Comment, même en pleine montagne, vous pouvez regarder vos vidéos préférées ? La réponse est simple ; les satellites.

Mais savez-vous comment fonctionne un satellite ? Quels en sont les types, et quels sont les grands acteurs qui envoient chaque année des petits vaisseaux tourner au-dessus de nos têtes ?
Beaucoup de questions auxquelles cet article de buttondown.com répond ce mois-ci.

Composé avec l’aide de Tom Nico, de l’ARCEP* et du chercheur Irénée Régnauld, cet article s’exprime dans un discours extrêmement simple à comprendre et très plaisant à lire. Les informations mises en avant, comme les différents impacts de ces appareils et le fait que l’on a envoyé autant de satellites dans l’espace ces trois dernières années que depuis 1957, sont réellement enrichissantes.

Une bonne morale sur l’exploration spatiale, ses promesses de partage et une réalité bien plus contrastée…

* Autorité indépendante française en charge de la régulation des réseaux télécoms

Quand l’air donne l’heure

Depuis plusieurs décennies, l’électronique s’est emparée d’une part très importante de la vie moderne. Quand l’on regarde les outils précurseurs à nos horloges, nos appareils électroménagers, etc., on les juge d’archaïque, historique, même.

Mais s’il existait des alternatives à l’électronique ? C’est la question à laquelle répond cette vidéo de soiboi soft, qui nous présente ce mois-ci une horloge à quatre chiffres et qui fonctionne… à l’air.

Avec l’aide de la logique microfluidique, de membranes en silicone et de la pression de l’air, le créateur nous démontre une véritable ingénierie et une exploration fascinante des formes alternatives de calcul.

Ce qui rend cette vidéo particulièrement intéressante, au-delà du fait que le système est très satisfaisant à regarder, c’est qu’elle montre comment les concepts fondamentaux de l’informatique – comme la logique, la mémoire et le stockage des données – peuvent exister sans électronique.

Choisir l’enseignement à la haine

Perdre son travail, ce n’est pas une mince affaire. Dans une situation pareille, il est compréhensible de laisser exploser sa colère, d’avoir un discours amer et de critiquer ses anciens employeurs.

Et si nous transformions cette colère en quelque chose de plus concret… de plus utile ? Voici l’histoire du licenciement de Vasilios Syrakis, racontée ce mois-ci dans cet article du financianexpress.

Après son licenciement, Syrakis a choisi de publier une vidéo de 38 minutes pour expliquer les systèmes d’infrastructure qu’il a conçus pendant huit ans ; routage réseau, équilibrage de charge, plateformes cloud et outils permettant à des milliers de développeurs de déployer leurs services à grande échelle. L’objectif est simple ; documenter son travail et partager son expérience avec d’autres ingénieurs. Plutôt que de se concentrer sur la perte de son emploi, Syrakis a choisi de transformer son histoire de licenciement en une démonstration de savoir-faire et de transmission de connaissances.

“Vous gaspillez 90% de vos tokens sans le savoir”

Si vous utilisez des IAs de manière quotidienne et gratuite, vous avez sans doute été confronté au blocage journalier imposé par ces dernières.

Avec cette vidéo de Shubham SHARMA, vous serez désormais incollable sur l’utilisation des IAs et la compréhension de leur limite.

En bon instructeur, Shubham commence d’abord ses explications par la définition de ce que sont des « tokens » d’IA, pour ensuite faire la différence entre la limite de message et de token, et expliquer pourquoi les IA deviennent plus lentes, voire même moins intelligentes à l’utilisation.

Shubham surligne ensuite 9 pièges communs classés parmi 3 grandes catégories. Parmi ces pièges, on retiendra surtout que :

– Plus la conversation est longue, plus chaque message coûte cher (car l’IA relit tout l’historique),

– Les réponses verbeuses coûtent plus cher, et qu’il existe des outils, comme Caveman, qui permettent de réduire ces longues réponses,

– Le choix du modèle est important (ne pas utiliser une Ferrari pour aller chercher du pain).

– L’utilisation de fichiers lourds, comme des images ou des PDFs, fait exploser le quota de token. Il est donc préférable d’utiliser du texte.

Et vous, connaissiez-vous ces pièges ?

Le cimetière des IA

Vibe Graveyard est un site qui recense des incidents, des échecs et des « oopsies » liés à l’utilisation excessive, voire imprudence, des intelligences artificielles dans le développement logiciel, les produits numériques, les médias, la santé et même le droit. Il se présente comme un cimetière de projets développés en grande partie par l’IA et avec peu de compréhension ou de validation humaine.

De la petite bourde aux erreurs catastrophiques, vous pourrez y lire des cas réels d’utilisation d’IA ayant parfois entraîné des erreurs juridiques, voire médicales. Un des cas récents concerne par exemple un problème de gestion de stock au sein des enseignes Starbucks, dont l’IA comptait et étiquetait souvent de manière erronée des boissons de base, notamment des types de lait similaires, et omettait parfois complètement certains produits.

L’objectif d’un tel site n’est pas d’offrir une analyse neutre de l’IA, mais de rappeler que l’automatisation ne remplace pas l’expertise technique, la validation et la maintenance logicielle. Une riche archive et un contrepoids très concret au discours enthousiaste entourant l’IA générative.

Pour aller plus loin

Voici les autres liens que vous avez partagés ce mois-ci, bonne lecture !

• Pourquoi il faut donner son sang juste avant les ponts du mois de mai 
• https://wiki.php.net/rfc/bound_erased_generic_types 
• Windows Zero-Days Expose BitLocker Bypasses And CTFMON Privilege Escalation 
• GrimLink.com Finally Live! 
• Microsoft PowerToys – Windows Utilities for Power Users 
• Trafic divisé par trois, agents qui ne cliquent plus : la Google I/O 2026 sonne la fin d’une époque 
• Google I/O 2026 : Google veut reconstruire Internet autour de l’IA 
• La guerre affecte 62% des PME-TPE | LinkedIn 
• https://www.europesays.com/ai/28009/ 

Cet article Satellites, Horloge à air et cimetière des IA est apparu en premier sur Synolia, agence e-commerce, CRM, Data, PIM/DAM, OMS.