JoliCode blog - les derniers articles

Profiler un consumer avec Blackfire

2026-07-02T11:42:00+02:00

Quand on parle de profiling PHP avec Blackfire, on pense généralement à une requête HTTP : un clic sur l'extension navigateur, et hop, le profil apparaît. Mais que faire quand le code à profiler tourne dans un consumer ou un worker ; une commande Symfony qui boucle indéfiniment, consommant une queue ou traitant des tâches en background ? La bonne nouvelle : Blackfire peut fonctionner dans ce contexte. La moins bonne : on ne peut pas déclencher le profiling au moment où ça nous arrange... sauf si on utilise les signaux POSIX.

Info

Cet article s'appuie sur les signaux POSIX. Si vous n'êtes pas familier avec ce concept, je vous invite à lire d'abord Les signaux POSIX et PHP qui pose les bases nécessaires.

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 :

Signal	Valeur	Usage habituel
`SIGTERM`	15	Arrêt demandé (e.g. `kill <pid>`)
`SIGINT`	2	Interruption clavier (`Ctrl+C`)
`SIGUSR1`	10	Signal utilisateur libre n°1
`SIGUSR2`	12	Signal utilisateur libre n°2

`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 :

Implémenter SignalableCommandInterface pour intercepter SIGUSR2 proprement ;
Utiliser une variable static dans handleSignal() pour alterner entre "start probe" et "end probe" d'un signal à l'autre ;
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.

Améliorer l’accessibilité d’un site existant : retour d’expérience chez JoliCode

2026-07-01T09:42:00+02:00

Malgré des avancées réglementaires importantes, l’accessibilité numérique reste largement sous-estimée dans de nombreux projets web. Depuis le 28 juin 2025, l’European Accessibility Act (EAA) étend les obligations d’accessibilité à de nombreux services numériques privés. Pourtant, la réalité est encore loin des objectifs fixés : selon l’Observatoire du respect des obligations d’accessibilité numérique, seuls 44 sites sur 7 560 contrôlés déclarent être totalement conformes au référentiel général d’amélioration de l’accessibilité (RGAA), soit 0,58 % de l’échantillon analysé.

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 :

Type	Correction à faire	Critère correspondant	Statut	Images
"Navigation" ou "Contrastes"	Description de la correction à appliquer	Lien vers le critère RGAA correspondant	✅, 🔜 ou ❌ avec un lien vers la pull request si elle existe	Capture d'écran du problème constaté

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.

Info

Critère 3.2 : Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé ?

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.

Info

Critère 3.1 : Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?

Critère 10.14 : Dans chaque page web, les contenus additionnels apparaissant via les styles CSS uniquement peuvent-ils être rendus visibles au clavier et par tout dispositif de pointage ?

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.

Info

Critère 12.7 : Dans chaque page web, un lien d’évitement ou d’accès rapide à la zone de contenu principal est-il présent ?

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.

Info

Critère 9.1 : Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ?

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>

Astuce

L’attribut focusable="false" n’est plus nécessaire sur les SVG inline non porteurs de sens à moins que vous ne souhaitiez supporter les navigateurs Internet Explorer et Edge avant 2020 (avant le passage à Chromium).

Info

Critère 4.8 : Chaque média non temporel a-t-il, si nécessaire, une alternative ?

Critère 4.9 : Pour chaque média non temporel ayant une alternative, cette alternative est-elle pertinente ?

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 :

Info

Chaque champ de formulaire ayant une étiquette dont le contenu n’est pas visible ou à proximité (masqué, aria-label) ou qui n’est pas accolé au champ (aria-labelledby), vérifie-t-il une de ses conditions ?

Le champ de formulaire possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue ;
Le champ de formulaire est accompagné d’un passage de texte accolé au champ qui devient visible à la prise de focus permettant de comprendre la nature de la saisie attendue ;
Le champ de formulaire est accompagné d’un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue.

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.

UX Days 2026 : Design, IA et conscience, ce que cette journée nous a appris sur notre métier

2026-06-24T11:42:00+02:00

L'intelligence artificielle redessine nos métiers. C'est le constat que partagent aujourd'hui designers, développeurs et product managers. Les UX Days 2026 n'ont pas échappé à cette réalité. Parmi les nombreuses conférences de la journée, six nous ont particulièrement marqués et partageaient un fil rouge : comment concevoir avec conscience à l'ère de l'IA ?

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 :

Ê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 ;
Adopter un design basé sur les standards CSS (Flexbox, Grid, tokens natifs) pour créer une correspondance directe avec le code ;
Proposer une interface familière aux outils existants pour réduire la courbe d'apprentissage ;
Parier sur les standards ouverts, même quand ça coûte des mois de refonte ;
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.

Comprendre (enfin) les TTY et PTY avec le composant Process de Symfony

2026-06-15T10:42:00+02:00

Vous est-il déjà arrivé de lancer une commande (composer, rsync ou une commande Symfony) directement dans votre terminal pour y admirer de jolies barres de progression colorées, mais de constater que cette même commande, une fois exécutée via un script PHP, perdait soudainement tout son formatage ?

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 :

Un fichier : Par exemple, lorsque vous redirigez une sortie avec ls > file.txt ;
Un PTY / TTY (Terminal) : Lorsque vous exécutez la commande directement devant votre écran ;
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 :

Le script PHP (via Symfony Process) agit comme le contrôleur.
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.

Comment utiliser les attributs PHP sur un contrôleur Symfony ?

2026-06-10T14:42:00+02:00

PHP 8.0 a introduit les attributs, et c'est une excellente fonctionnalité ! Le code devient plus lisible, plus simple à écrire, et bénéficie pleinement de la coloration syntaxique et du linting de notre IDE.

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.

Info

Nous avions déjà parlé des attributs en 2021 pour limiter le débit de vos API (Rate Limit). Cependant, Symfony a bien évolué depuis, et leur utilisation est devenue encore plus simple.

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 !

Améliorer la maintenance de vos workflows GitHub

2026-06-09T11:42:00+02:00

Les failles de sécurité liées à la supply chain sont de plus en plus courantes. En tant que mainteneur d'un projet open source populaire, l'enjeu est de taille. Votre code est déployé sur de nombreux serveurs de production et postes de développeurs. Il est donc crucial de garder vos pipelines CI à jour et sécurisés.

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.

AFUP Day 2026 Paris, retour sur une journée dans l'écosystème PHP

2026-05-26T15:30:00+02:00

Ce vendredi 22 mai 2026, l'équipe JoliCode était présente à l'AFUP Day 2026 Paris à l'ESGI Paris pour une journée de conférences. L'ambiance était conviviale et studieuse, avec un programme axé sur l'IA, l'architecture et la productivité.

Nous avons eu l'honneur de présenter deux sujets, Loïck Piera sur Castor 🦫 et Grégoire Pineau sur Symfony IA.

Les temps forts techniques

Le programme a couvert des thématiques essentielles qui font évoluer nos pratiques au quotidien, et a aussi rappelé quelques bases que nous connaissons bien.

Intelligence Artificielle et Innovation dans Symfony

L'IA a été au cœur de plusieurs échanges, montrant son intégration progressive dans nos outils quotidiens :

Symfony AI et Embeddings : Grégoire Pineau a présenté son retour sur l'utilisation des embeddings dans Symfony pour des recherches et rapprochements sémantiques poussés - nous vous invitons à retrouver notre récapitulatif de Symfony Live où nous en parlions déjà.

Assistance Générative : Florence Cauchy a partagé un guide pratique sur l'intégration de GitHub Copilot et Claude dans nos workflows. Nous partageons ses conseils :

Mise en place de skills ;
Définition de guidelines pour les agents ;
Exploiter aussi bien le CLI que les agents cloud.

Si vous n'avez pas encore d'assistance par LLM pour coder, c'était une bonne introduction !

Outillage, Productivité et Modernisation

Nous avons exploré de nouveaux outils pour optimiser notre productivité :

Castor : Loïck Piera nous a fait découvrir les coulisses de ce task runner open source indispensable 😉 (oui c'est nous qui le développons). L'occasion de parler des outils sur lesquels repose Castor comme symfony/console, et de parler de fonctionnalités peu connues comme :

Les events pour étendre le fonctionnement ;
Les imports distants pour utiliser des tasks extérieures ;
Les remote exécutions, pour lancer des outils sans les installer.

Nous vous invitons à lire les slides qui sont pleines d'informations !

Sidekicks applicatifs : Nicolas Grekas a présenté comment tirer partie de Caddy/FrankenPHP pour faciliter la configuration de nos applications HTTP. Grâce à ces sidekicks, l'application peut continuer à tourner en mode worker (donc sans avoir à redémarrer de 0 à chaque requête, comme c'est le cas avec PHP-FPM) mais en ayant sa configuration à jour :

côté application, on récupère une valeur de configuration, qui est locale et toujours à jour, grâce à un simple appel à une fonction ;
un thread tourne à côté pour mettre à jour cette valeur dès qu'il y a un changement (ce thread est setup très simplement dans Caddy / FrankenPHP).

Il aimerait voir cette nouvelle manière de faire devenir un standard dans l'écosystème PHP, à la place du traditionnel php-fpm, afin d'être égaux avec les technos alternatives à PHP comme node, qui proposent des comportement similaires.

Architecture et Qualité du Code

La durabilité logicielle et les bonnes pratiques restent fondamentales :

Qualité avec PHPStan : Vincent Langlet & Étienne Dhennin nous font la présentation de leur mise en place d'un écosystème de qualité chez Weglot. Ils nous ont présenté les différents fixers, linters et outils de tests disponibles et qu'ils ont utilisés, pour répondre à leur définition de la qualité : la capacité d'un système à remplir son rôle aujourd'hui comme demain, au travers de trois dimensions : fonctionnelle, temporelle et humaine. La direction de l'entreprise avait besoin de justifications pour le temps passé à faire de la qualité, et ils ont donc introduit un métrique original : le taux de hotfix en production (et donc oui il a baissé).

Parmi leurs retours d’expérience sur PHPStan en particulier :

Ne pas générer de baseline sur les projets legacy, prioriser les niveaux "bas" (jusqu’au niveau 5) - nous sommes partagés sur ce point car la baseline permet justement de pouvoir contribuer à des projets legacy avec une analyse statique élevé sur nos nouveaux développements ;
Privilégier les extensions spécifiques à votre projet (phpstan-doctrine par exemple) aux niveaux 9 et 10, souvent superflus.

API Design Pragmatique : Amaury Bouchard a exploré des alternatives au design d'APIs. Il critique pas mal JWT car ça ne gère pas l'expiration par exemple. Un des points que nous partageons est que HTTP Basic aujourd'hui c'est tout à fait valide et sécurisé (car en HTTPS il n'y a pas de "fuite" des identifiants). Le take-away du talk concerne le choix entre RPC et REST. Vouloir utiliser absolument du REST alors que notre API ne gère pas des états mais des actions est un mauvais choix de design. En résumé :

RPC pour les API qui font des actions (envoyer un mail, publier des redirections...) ;
REST pour les API qui modifient des états, le CRUD, etc.

En bref, un appel à la simplicité, quitte à remettre en questions des dogmes acquis depuis très longtemps, de très bons sujets de réflexion lors de votre prochaine conception d’API.

Tests sans Mocks : Imen Ezzine a présenté une solution intéressante pour tester efficacement des APIs externes sans recourir aux mocks - et surtout pour pallier à l'imcompatibilité de PHP-VCR avec le client HTTP de Symfony.

En utilisant le format HAR, un nouveau decorator RecorderHttpClient, et un simple attribut #[UseRecord] sur les fonctions de test (via le bridge phpunit), nous pouvons enregistrer une réponse API, de sorte à pouvoir utiliser plus tard cet enregistrement pour simuler des appels à une API externe. Ainsi, pas besoin de créer un mock ! L’appel est joué réellement une seule fois, puis réutilisé directement au moment de lancer les tests. Un mécanisme permet de configurer son mode d’enregistrement, pour rafraîchir périodiquement, rejouer l’appel à chaque fois ou au contraire le verrouiller.

L’ensemble apparaît comme une solution efficace et très élégante pour s’affranchir d’une problématique que nous avons tous déjà rencontrée. Une PR est soumise sur Symfony 8.2.

Gestion des Exceptions : Smaïne Milianni a récapitulé les meilleures pratiques pour gérer et logguer les exceptions proprement. De bons rappels et peut être même des guidelines à coller dans nos AGENTS.md !

Relancer systématiquement les exceptions attrapées dans les couches “profondes” de l’application (métier, infra…), pour les gérer uniquement dans les couches d’interface.
Ne pas catcher la terre entière (catch \Exception) ;
Ne pas catcher Throwable si on est bas niveau ;
Ne jamais "rien faire" dans le "catch" (il faut au moins un log) ;
Utiliser une exception pour faire du contrôle de flow classique (nous sommes un peu partagé à ce sujet aussi - c'est parfois élégant) ;
Catcher et relancer une exception sans n'avoir rien changé / rien fait : autant de rien catcher ;
ne jamais oublier l'argument $previous quand on rethrow / mute une exception ;
créer des exceptions custom, utiliser des constructeurs statiques... pour nos exceptions métier.

Sujets intemporels

Passkeys et WebAuthn : Sylvain Combraque nous a fait un rapide cours historique sur les manières de stocker les mots de passe utilisateurs, du très sécurisé plaintext jusqu'au hashage, sans oublier l'OICD pour nous montrer comment avec le temps, nous avons pu répondre aux questions de sécurité liées à nos systèmes d'authentification. Il nous a finalement expliqué qu'au final, la manière la plus simple de sécuriser nos mots de passe, c'est de ne pas en avoir ! Chose possible aujourd'hui et depuis 2015 grâce aux Passkeys, une solution d'authentification locale, unique par compte, et impossible à faire fuiter. Cela fait 10 ans que nous en entendons parler et que les briques techniques existent, et pourtant, ce n'est toujours pas "grand public" ! Les mots de passe ont encore de beaux jours devant eux... À nous de faire bouger les lignes !

Gotchas PHP : Frédéric Bouchery a animé une session interactive sur les comportements inattendus et les subtilités du langage. Par exemple, saviez-vous que new daTeTimE(); fonctionne aussi bien que new DateTime(); mais que vos constantes elles, sont sensibles à la casse ? C'était une façon très ludique de nous expliquer des principes du langage comme la compilation, les changements de syntaxes...

Conclusion

Au-delà de la technique, l'AFUP Day a été un moment de partage plein d'échanges et riche en apprentissages. Nous sommes vraiment ravis de retrouver un événement à Paris.

Les perspectives ouvertes par l'IA et la modernisation des outils promettent des projets passionnants pour JoliCode. Un grand merci à l'AFUP Paris et à tous les bénévoles pour cette organisation impeccable 👏 Comptez sur nous l'année prochaine !

Comment intégrer l'IA dans son workflow UX/UI

2026-05-12T12:42:00+02:00

"On a déjà deux agents IA qui tournent en interne."

Ce n'est pas en réunion que j'ai entendu ça. C'est en mission chez un client, dans leurs bureaux. Ce genre de phrase, je l'entends de plus en plus souvent maintenant, entre deux écrans, dans les couloirs, pendant la pause déjeuner. L'IA fait désormais partie du quotidien.

Quelques semaines plus tard, un autre client nous présente deux pages de maquettes générées par Claude, structure de page et premières intentions de contenu, pour expliquer ce qu'il voulait avant même d’ouvrir Figma.

C'est ce constat qui nous a poussés à écrire cet article, pour poser ce que ça change dans notre façon de travailler, et ce qu'on peut en tirer concrètement pour nos projets et nos clients.

Ce que j'ai trouvé en explorant, c'est que l'IA ne remplace pas le designer, elle redistribue son temps et son attention. Certaines tâches s'accélèrent, d'autres disparaissent, et de nouvelles compétences deviennent importantes. La principale d'entre elles, j'y reviendrai, est la capacité à formuler des demandes précises. Savoir parler à une IA, ça s'apprend et ça change tout à la qualité des résultats.

Le prompt : la compétence clé

Avant de parler workflow et processus, un point essentiel, la qualité des résultats dépend de la qualité de la demande. C'est le cœur du sujet.

Un bon prompt, c'est un bon brief. Précis, contextualisé, avec une intention claire et des contraintes définies. L'erreur la plus fréquente, celle que j'ai faite moi-même au début, c'est de rester trop vague en espérant que l'IA devine l'intention derrière la demande.

ex : Prompt trop vague
"Génère un UX flow pour un site e-commerce."

ex : Prompt structuré
"Génère un UX flow pour la page produit d'un site e-commerce de mode féminine, destiné à des femmes de 25–40 ans sur mobile. Inclure : découverte produit, sélection de taille, ajout au panier, paiement, et edge cases (taille indisponible, rupture de stock, code promo invalide). Format en étapes claires avec états d'erreur et micro-interactions.".

La différence se joue sur la précision de la demande. Un prompt efficace s'articule autour de cinq dimensions. Elles font la différence entre un résultat générique et une base vraiment exploitable :

La tâche : Ce que l’IA doit faire concrètement, générer un écran, proposer un flow, décliner un composant.
Le contexte : Où s'intègre cet écran ou ce parcours dans l'expérience globale ? Quel est l'état précédent ?
Les éléments clés du design : Les caractéristiques visuelles ou fonctionnelles importantes que l'IA doit intégrer dans sa proposition.
Les comportements attendus : Comment réagissent ces éléments lors de l'interaction (hover, tap, scroll, états vides, erreurs…)
Les contraintes : Le support, la mise en page, le style visuel, les guidelines de marque. Plus ces contraintes sont précises, plus le résultat est pertinent.

J'aime les métaphores, alors en voici une : l'IA ressemble à un nouveau collaborateur. Il ne connaît pas encore le contexte, les clients, les process. Sans brief précis, il produit quelque chose de générique. Bien briefé, il va vite et produit une base exploitable.

Apprendre à prompter, c'est apprendre à collaborer avec l'IA, formuler ce qu'on veut, donner le bon niveau de contexte, et itérer ensemble.

Intégrer l'IA à chaque étape

Maintenant qu'on a posé ce cadre, voyons comment ça se traduit dans le travail. J'ai organisé cette exploration en trois phases : explorer, concevoir et produire. L'IA n'y joue pas le même rôle à chaque étape.

Une précision importante avant de commencer : "plus vite" ne veut pas dire "sans effort". Une partie du temps gagné en génération est réinvestie en correction, ajustement et validation. L'IA produit une base et non un livrable.

Explorer plus vite et plus largement

Un brief flou est l'une des principales sources de perte de temps en début de projet. Avant, cela voulait dire plusieurs allers-retours avant même de commencer à concevoir. Aujourd'hui, on peut envoyer le brief tel quel à un agent conversationnel, demander une structure claire avec l'utilisateur cible, le problème, les objectifs attendus et les questions de clarification manquantes, et avoir une base de travail en quelques minutes.

Sur les UX flows, même constat. L'IA est capable de générer rapidement plusieurs scénarios, explorer des alternatives et identifier des états qu'on aurait pu oublier (erreurs, compte vide, connexion perdue..). La décision reste entièrement humaine : simplifier, prioriser, arbitrer.

Concevoir et itérer sans blocage

Pour cette phase de conception, j'ai testé spécifiquement deux outils : Figma Make et Claude Design.

Figma Make permet de générer plusieurs propositions d'écrans à partir d'une description ou de frames, de tester des patterns qu'on n'aurait pas spontanément tentés, et d'explorer des déclinaisons visuelles rapidement. C'est un véritable moteur d'expérimentation. Par défaut, il génère des écrans génériques, sans personnalité, sans cohérence graphique. Cette limite se réduit selon ce qu'on lui fournit un prompt détaillé ou en faisant plusieurs itérations.

Claude Design va plus loin dans l'aboutissement. La richesse de l'interface et la finesse des ajustements possibles sont intéressantes. C'est à ce jour la solution qui produit les prototypes les plus aboutis parmi celles que j'ai testées. Si le prompt semble insuffisant, Claude Design propose automatiquement un questionnaire pour affiner la demande avant de générer.

Autre détail qui a son importance, Claude Design propose deux modes d'itération complémentaires : le chat pour les changements globaux, et les commentaires inline pour les ajustements précis sur un élément spécifique. En pratique, ça permet de générer rapidement des visuels utiles pour aligner une équipe, transformer une idée produit en prototype testable.

Dans les deux cas, ce que ces outils produisent est une base de travail, pas un livrable finalisé. Le designer reste celui qui la transforme en proposition exploitable.

Au-delà des écrans, l'IA change aussi la façon de rédiger les interfaces. Sur le microcopy, ces petits textes qui guident l'utilisateur à chaque étape, c'est une aide précieuse. En définissant le ton et le style de communication de la marque dans le prompt, on peut générer rapidement des textes cohérents pour tous les états d'interface : succès, erreur, chargement, état vide.

Produire et livrer plus efficacement

Le handoff, ce moment où le designer passe le relais au développeur, est souvent un moment de friction. L'IA ne le supprime pas, mais elle le fluidifie. En connectant Figma à Claude via le protocole MCP (Model Context Protocol), Claude peut lire directement la structure du fichier (composants, calques, propriétés…) et produire une base de documentation de specs. C'est une piste que je n'ai pas encore testée personnellement, mais qui mérite d'être mentionnée. La qualité du résultat dépendrait directement de la structure du fichier Figma : un fichier bien nommé avec des composants propres donnerait un résultat exploitable.

C'est d'ailleurs une règle qui vaut pour tout l'article : l'IA amplifie que ce qui est déjà structuré. Un design system solide n'est plus seulement un outil de cohérence visuelle, c'est ce qui rend le travail exploitable par l'IA.

Et côté client, qu’est-ce que ça change vraiment ?

Les deux anecdotes d'introduction ne sont pas des cas isolés, elles disent quelque chose d'important : le niveau de préparation et d'attente des clients change. Quand un client arrive avec des maquettes générées par IA pour illustrer son idée, il ne cherche pas à faire le travail du designer. Il cherche à être compris plus vite, à aligner plus tôt, à éviter les allers-retours.

Pour le designer, ça change la nature de la conversation. On ne part plus d'une page blanche commune, on part d'idées déjà mises en forme, parfois précises, parfois approximatives mais toujours révélatrices de ce que le client a en tête. Le client montre une direction, une intention mais pas une solution. C'est au designer de définir ce qu'il y a derrière.

La prochaine étape naturelle, que j'imagine, c'est l'atelier client en live : générer des variantes d'écrans directement en réunion pour itérer en temps réel sur une direction. L'enjeu est simple : aligner plus vite.

Pour conclure

L'IA transforme réellement la pratique du design. Elle accélère certaines étapes, structure des réflexions qui prenaient du temps, et ouvre des possibilités d'exploration.

Elle ne connaît pas les utilisateurs, leurs habitudes, leurs frustrations, ce qui les fait décrocher. La créativité graphique, la sensibilité visuelle, la cohérence d'une marque, tout cela reste entièrement humain. Mais elle propose des directions qu'un designer seul n'aurait pas explorées, pas parce qu'elles sont meilleures, mais parce qu'elle n'a pas nos biais.

Sur un prochain sujet, nous pourrons approfondir un aspect particulier : comment configurer Claude avec des instructions personnalisées (system prompts, custom instructions) pour lui donner un contexte permanent et des compétences adaptées à la pratique du designer.

Claude Code, Cursor, Symfony/AI, Vercel AI SDK : 3 formations pour garder la main

2026-04-28T15:42:00+02:00

Trois formations IA sont disponibles dès maintenant sur JoliCampus, avec des sessions ouvertes à l'inscription. Elles sont construites sur ce qu'on pratique chez JoliCode et Premier Octet : des projets clients qui tournent en production avec des agents de code IA, des outils qu'on utilise tous les jours, des patterns qu'on a éprouvés, testés et parfois jetés !

Voici ce qu'elles contiennent :

Maîtriser les agents IA pour le développement

La porte d'entrée ! Une journée pour sortir de l'autocomplete et entrer dans le travail avec des agents. Au programme : fonctionnement réel d'un agent (mémoire, contexte, permissions), standardisation des conventions d'équipe via le fichier AGENTS.md (agnostique, fonctionne avec Claude Code, Codex, Cursor), utilisation de l'agent comme QA automatisée avec génération de tests, lecture des logs et boucle d'auto-réparation sous supervision, puis création de commandes personnalisées pour industrialiser chez vous les revues de code, la détection de N+1, de failles XSS, et les patterns propres à votre équipe.

Voir la formation

L'IA pour développeurs frontend, avec Cursor et le Vercel AI SDK

Les deux faces du sujet. Jour 1 côté workflow : Cursor dans ses trois modes (Ask, Plan, Agent), commandes custom, intégration d'outils via MCP, .cursorrules pour que l'agent respecte l'architecture du projet, gestion du contexte sur les sessions longues.

Jour 2 côté produit : construire un vrai assistant avec le Vercel AI SDK (streaming, tool calling, architecture RAG sur vos contenus, typage strict avec Zod), déploiement et les questions qui vont avec (coûts API, monitoring, stratégies de cache).

Voir la formation

Maîtriser l'IA avec Symfony

Pour intégrer l'IA générative dans vos applications Symfony avec la même rigueur que le reste de votre code. On s'appuie sur Symfony/AI, le composant officiel de l'écosystème, auquel on contribue directement.

Socle de 2 jours : fondamentaux des LLM, ChatInterface, typage fort des sorties en objets PHP, RAG complet sur vos documents avec pgvector. Puis deux modules optionnels : le premier transforme votre application en orchestrateur d'agents capables d'appeler votre code PHP et vos APIs internes, le second aborde MCP, le McpBundle, les stratégies de test, le monitoring en production et la maîtrise des coûts.

Voir la formation

Et si vous ne codez pas ?

POs, chefs de projets, dirigeantes et dirigeants de boîte tech : l'IA change aussi la façon dont vos équipes travaillent, à quelle cadence, sur quelle échelle de temps. Notre formation Culture Engineering a un module dédié pour comprendre ce qui bouge pour mieux collaborer avec vos équipes tech.

Pourquoi chez nous ?

On forme sur ce qu'on pratique. Nos projets tournent en production avec ces outils, on contribue directement à Symfony/AI, et on publie sur notre blog ce qu'on apprend. Ces formations vont évoluer avec l'écosystème. Certains modules seront réécrits dans six mois. Un participant d'aujourd'hui peut revenir dans un an sur une session mise à jour, et ce sera la suite logique, pas une répétition 🙂

Toutes nos formations sont certifiées Qualiopi, finançables via les OPCO, et modulables en intra-entreprise. Un doute sur la formation qui correspond à votre équipe ? Écrivez-nous !.

Plan de migration vers Tailwind CSS v4 🚀 : la méthode (presque) sans douleur

2026-04-27T10:20:00+02:00

Ça y est, le grand jour est arrivé ! Vous avez enfin décidé de vous attaquer à cette fameuse dette technique qui vous fait faire des cauchemars la nuit. 😅

Beaucoup de nos projets (et sans doute les vôtres) reposent encore sur d’anciens frameworks CSS basés sur Sass, comme Bootstrap v4 ou d'autres solutions maison (coucou Atomic Builder 👋). Et soyons honnêtes : maintenir et mettre à jour ces projets relève souvent du parcours du combattant. On fait face à un manque cruel de flexibilité, la dette technique s’accumule, et les dépendances commencent à poser plus de soucis qu'elles n'en résolvent.

Sans oublier que Sass, bien qu’ayant été notre fidèle compagnon pendant de très (très) nombreuses années, devient de moins en moins indispensable avec l'évolution fulgurante du CSS natif. Nous avons d’ailleurs eu l’occasion d’en parler dans notre article expliquant pourquoi passer à PostCSS.

Le choix s'est donc naturellement porté vers Tailwind CSS v4. C'est une solution qui a fait ses preuves chez JoliCode (J'ai testé Tailwind CSS) et, cerise sur le gâteau, cette nouvelle version ne nécessite aucune dépendance liée à Sass.

L’année dernière, nous avons amorcé des phases de migration pour plusieurs de nos projets clients. Aujourd’hui, j’ai envie de partager avec vous quelques retours d’expérience et une méthodologie (testée et approuvée ✅) pour que ces migrations se passent le mieux possible !

Phase 1 : Migration des feuilles de styles CSS 🎨

L’objectif de cette première phase est simple : utiliser du CSS natif et dire officiellement au revoir à notre bon vieux Sass. 👋

La toute première étape consiste à migrer la configuration globale de votre projet (généralement définie dans des fichiers tels que variables.scss ou global.scss) vers un système basé sur des custom properties (variables CSS), en ciblant la racine du document HTML via la pseudo-classe :root.

Avant (Sass) :

$color-primary: #f7d325;
$color-secondary: #ff2951;
$font-family-sans-serif: "Source Sans Pro", sans-serif;

Après (CSS natif) :

:root {
  --color-primary: #f7d325;
  --color-secondary: #ff2951;
  --font-sans: "Source Sans Pro", sans-serif;
}

Info

Utilisez dès maintenant la nomenclature de Tailwind CSS v4 pour nommer vos variables CSS. Ça vous fera gagner un temps précieux pour la suite. 👌

Cas n°1 : Les variables et fonctions

Une fois votre thème mis en place, votre première mission sera de remplacer tous vos $ par des var(--). C'est aussi l'occasion de traduire vos fonctions Sass en CSS moderne. 👀

Avant (Sass) :

.button {
  width: math.div(100%, 3);
  background-color: $color-primary;
  
  &:hover,
  &:focus-visible,
  &:active {
    background-color: darken($color-primary, 15%);
  }
}

Après (CSS natif) :

.button {
  /* Le CSS natif s'occupe des calculs dynamiquement ! */
  width: calc(100% / 3);
  background-color: var(--color-primary);
  
  &:hover,
  &:focus-visible,
  &:active {
    /* Magie ! Les couleurs relatives en CSS natif */
    background-color: hsl(from var(--color-primary) h s calc(l - 15)); 
  }
}

Aujourd'hui, le CSS natif est devenu suffisamment mature pour remplacer la quasi-totalité des fonctions Sass. C’est particulièrement vrai pour les manipulations de couleurs, qui s’écrivent désormais très simplement grâce aux couleurs relatives en CSS. 🎨

Cas n°2 : Le piège du sélecteur d’imbrication `&` et du BEM

La bonne nouvelle, c'est que le CSS natif gère désormais très bien le nesting (l'imbrication). L'esperluette (&) pour cibler des états comme &:hover ou &:focus fonctionne parfaitement sans Sass.

La mauvaise nouvelle ? Si vous utilisiez le & pour concaténer des classes, typiquement avec la méthodologie BEM (&__element ou &--modifier), le CSS natif ne comprendra pas cette syntaxe. Il va falloir « désimbriquer » ces éléments.

Avant (Sass) :

.link {
  color: $color-primary;
  
  &:hover,
  &:focus-visible,
  &:active {
    color: $color-secondary;
  }

  /* Sass va compiler ce code en ".link--secondary" */
  &--secondary {
    color: $color-secondary;
  }
}

Après (CSS natif) :

.link {
  color: var(--color-primary);
  
  /* Ce code fonctionne toujours en CSS natif ! */
  &:hover,
  &:focus-visible,
  &:active {
    color: var(--color-secondary);
  }
}

/* Il faut sortir la classe enfant de l'imbrication */
.link--secondary {
  color: var(--color-secondary);
}

Cas n°3 : Les media queries

Pour les media queries générées via des mixins ou des fonctions Sass (du type @include media-breakpoint-up(md)), passez simplement les valeurs en dur pour le moment (@media (min-width: 768px)). Nous nous en occuperons plus tard, lors de l'intégration de Tailwind.

Cas n°4 : Les mixins, boucles et règles complexes

Pour les cas très spécifiques (boucles @for, mixins complexes), la solution la plus pragmatique est de récupérer la version déjà compilée et de la coller dans votre fichier CSS.

Avant (Sass) :

@for $i from 1 through 3 {
  .button--size-#{$i} {
    padding: #{$i}rem;
  }
}

Après (CSS natif) :

.button--size-1 { padding: 1rem; }
.button--size-2 { padding: 2rem; }
.button--size-3 { padding: 3rem; }

À la fin de cette phase, le code CSS de votre projet n'utilise techniquement plus aucune fonctionnalité propre à Sass. 👏

Phase 2 : Migration (provisoire) des classes utilitaires 🧰

C'est l'étape de la « prise de masse » avant la sèche. 💪

L'idée est de récupérer le CSS compilé de toutes les classes utilitaires de votre ancien framework et de les stocker dans un nouveau dossier, par exemple utilities/. Pour garder l'esprit clair, séparez-les par thématique : utilities/typography.css, utilities/spacing.css, etc.

Exemple d'un fichier utilities/spacing.css (récupéré depuis Bootstrap v4) :

.mt-1 { margin-top: 0.25rem !important; }
.mt-2 { margin-top: 0.5rem !important; }
.mb-3 { margin-bottom: 1rem !important; }
/* ... */

Votre CSS global va grossir temporairement. C'est normal, ne paniquez pas ! Ces fichiers agiront comme un filet de sécurité visuel en attendant que Tailwind prenne le relais. 😮‍💨

Phase 3 : On débranche l’ancien framework CSS 💔

Si les phases 1 et 2 ont été faites minutieusement, vous pouvez supprimer l'ancien framework CSS de vos dépendances. Visuellement, rien ne devrait bouger. 🤞

Avertissement

Attention aux comportements JS ! Si votre ancien framework (comme Bootstrap) gérait des modales, des info-bulles ou des menus déroulants, la suppression de son CSS (et de ses scripts associés) risque de casser les animations ou le positionnement. Prévoyez un peu de temps de développement pour vérifier les interactions JavaScript et réécrire ces quelques composants. Profitez-en pour utiliser du JS vanilla ou du CSS moderne (l'API Popover native est parfaite pour ça, par exemple !).

Phase 4 : L'adieu à Sass 🫡

C'est l'heure de désinstaller une fois pour toutes sass (ou node-sass). N’oubliez pas de renommer tous vos fichiers .scss en .css.

Lors de cette étape, il est très probable que le compilateur échoue lors de son premier lancement. Si la console se remplit d'erreurs, pas de panique, c'est un grand classique ! Cela s'explique généralement par l'une de ces trois raisons :

L'import fantôme : Votre bundler (comme Webpack) ou votre point d'entrée JavaScript (le fameux app.js) pointe toujours vers un fichier portant l’extension .scss. Pensez à bien mettre à jour vos chemins d'importation.
Le reliquat de Sass : Il reste quelques $, @use, etc. qui traînent dans vos fichiers CSS. Pensez à les supprimer.
Les commentaires : Les commentaires d'une seule ligne écrits avec // étaient valides avec Sass, mais pas avec votre CSS natif.

L'erreur classique à corriger :

// Ce commentaire était valide en Sass, mais fera planter votre CSS natif !
.element { color: var(--color-primary); }

/* Remplacez-le par la syntaxe standard ! */
.element { color: var(--color-primary); }

Une fois ces petits ajustements faits, respirez un grand coup. Le plus dur techniquement est derrière vous. 🎉

Phase 5 : L'entrée en scène de Tailwind CSS v4 🤩

Il est enfin temps d'installer Tailwind CSS v4 et PostCSS (indispensable dans nos projets Symfony avec Webpack Encore). Je vous conseille de suivre la documentation officielle pour le setup initial.

Le piège de l'import global (et du Preflight)

La documentation officielle vous recommandera d’importer Tailwind de cette façon :

@import "tailwindcss";

En utilisant cet import global, Tailwind embarque par défaut plusieurs layers CSS (theme, base, components et utilities), injectant par la même occasion son propre reset CSS (Preflight). Si votre projet possédait déjà un fichier de reset (comme normalize.css), vous risquez d’avoir des conflits.

Info

Désactivez Preflight dans un premier temps, ainsi que l'ensemble des layers CSS importés pour limiter les régressions et les problématiques liées à la cascade CSS.

Pour cela, privilégiez des imports ciblés (sans les layers CSS) :

@import "tailwindcss/theme.css";
@import "tailwindcss/utilities.css";

La magie de la directive `@theme`

La révolution de la v4, c'est qu'elle est CSS-first. Fini l'énorme fichier tailwind.config.js à la racine de votre projet ! Le thème que vous aviez anticipé lors de la phase 1 s'intègre désormais presque nativement grâce à la nouvelle directive @theme.

Avant :

:root {
  --color-primary: #f7d325;
  --color-secondary: #ff2951;
  --font-sans: "Source Sans Pro", sans-serif;
}

Après :

@theme static {
  --color-primary: #f7d325;
  --color-secondary: #ff2951;
  --font-sans: "Source Sans Pro", sans-serif;
}

Info

Gardez vos variables CSS accessibles partout ! Pensez à générer vos variables CSS avec le comportement static, comme indiqué dans la documentation Tailwind. Ainsi, elles ne seront pas limitées aux classes utilitaires de Tailwind, mais resteront utilisables partout dans vos propres composants CSS personnalisés.

C'est aussi le moment parfait pour utiliser la directive @variant afin d'uniformiser ces fameuses media queries que nous avions mises en dur plus tôt !

Avant :

@media (min-width: 768px) {
  .card {
    color: var(--color-primary);
  }
}

Après :

@variant md {
  .card {
    color: var(--color-primary);
  }
}

Ce petit changement vous garantit que tout votre CSS sur-mesure restera parfaitement synchronisé avec le comportement natif des classes utilitaires de Tailwind.

Phase 6 : Le nettoyage de printemps 🧹

Je préfère être honnête : cette étape demande de la patience. 🙃

L'objectif est de supprimer le dossier utilities/ créé à la phase 2. Pour ce faire, vous allez devoir remplacer dans tous vos templates HTML/Twig les anciennes classes par les nouvelles générées par Tailwind.

Vos meilleurs alliés ici seront l'outil de recherche de votre IDE, les expressions régulières (Regex), et bien sûr votre LLM (Large Language Model) favori (ChatGPT, Claude, GitHub Copilot, etc.) pour automatiser un maximum le processus.

Avant (Bootstrap v4) :

<div class="d-flex flex-column flex-md-row">...</div>

Après (Tailwind CSS v4) :

<div class="flex flex-col md:flex-row">...</div>

Le boss final : Les grilles 😎

Il n'y a pas de solution magique ici. Les vieux frameworks utilisaient généralement Flexbox pour simuler un comportement de grille. Tailwind, lui, utilise le module natif CSS Grid Layout (modèle de disposition en grille).

Il va falloir repasser sur vos grilles manuellement. 😬

L'ancienne approche (Flexbox) :

<div class="row">
  <div class="col-12 col-md-6">...</div>
  <div class="col-12 col-md-6">...</div>
</div>

La nouvelle approche (Grid) :

<div class="grid grid-cols-1 md:grid-cols-2">
  <div>...</div>
  <div>...</div>
</div>

C'est fastidieux, mais le DOM en ressort considérablement allégé et plus lisible. 🥳

Conclusion : Tout ça pour ça ? 🤔

Oui, mille fois oui. Migrer vers Tailwind CSS v4 n'est pas un parcours de santé pour un projet existant. Mais les avantages sont colossaux.

Vous dites adieu à l'usine à gaz qu'était devenu Sass au fil des années. Le poids final de votre CSS sera drastiquement réduit puisque Tailwind ne compile que ce que vous utilisez réellement. Sans parler des performances pures : avec son nouveau moteur écrit en Rust, les temps de compilation sont si rapides qu’on les remarque à peine.

Enfin, la Developer Experience (DX) de vos équipes s'en trouvera transformée. C'est un investissement en temps conséquent, mais c'est un cadeau inestimable que vous faites au futur de votre projet. 🎁

Et concrètement, comment on vend ça à sa direction ?

C'est souvent la question qui fâche. On sait que le chantier est nécessaire, mais il est difficile d'estimer le temps que cela va prendre sans y laisser des plumes, d'où l'effet tunnel qui effraie les équipes produit.

Pour débloquer la situation, nous avons l'habitude chez JoliCode de commencer par un audit flash (1 à 2 jours). L'objectif est de poser les choses à plat pour vous fournir un plan de bataille concret à défendre en interne :

Un état des lieux clair de la dette front actuelle (dépendances, risques, obsolescence).
Une estimation chiffrée de la migration, découpée par phase.
Un plan de déploiement progressif qui ne bloque pas votre roadmap produit.
Les bénéfices attendus (gains de performance, vélocité des équipes, etc.).

Si vous avez besoin d'aide pour cadrer votre propre migration, n'hésitez pas à nous faire signe !

J’espère que ce retour d’expérience vous sera utile et vous donnera le courage de sauter le pas. N'hésitez pas à partager vos propres astuces ou vos galères de migration dans les commentaires ! 🙂

JoliCode blog - les derniers articles

Profiler un consumer avec Blackfire

Le problème

Installation de Blackfire

SignalableCommandInterface : gérer les signaux dans une commande Symfony

getSubscribedSignals()

handleSignal() : décrypter la signature

Intégrer Blackfire via SIGUSR2

Utilisation concrète

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

Conclusion

Améliorer l’accessibilité d’un site existant : retour d’expérience chez JoliCode

L’état des lieux

Améliorer la lisibilité des contenus

Faciliter la navigation

Corriger la navigation principale

Ajouter un lien d’évitement

Structurer l’information

Donner du sens aux images

Rendre les formulaires plus explicites

Enseignements et perspectives

UX Days 2026 : Design, IA et conscience, ce que cette journée nous a appris sur notre métier

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

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

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

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

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

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

Ce que nous retenons de cette journée

Comprendre (enfin) les TTY et PTY avec le composant Process de Symfony

Retour aux bases : les flux standards

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

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

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

Démo time !

En résumé

Comment utiliser les attributs PHP sur un contrôleur Symfony ?

1. Créer un attribut

2. Utiliser l'attribut sur un contrôleur

3. Créer le listener pour activer le comportement

Avec Symfony 6.2+

Avec Symfony 8.1+

Avec Symfony 8.2+

Conclusion

Améliorer la maintenance de vos workflows GitHub

AFUP Day 2026 Paris, retour sur une journée dans l'écosystème PHP

Les temps forts techniques

Intelligence Artificielle et Innovation dans Symfony

Outillage, Productivité et Modernisation

Architecture et Qualité du Code

Sujets intemporels

Conclusion

Comment intégrer l'IA dans son workflow UX/UI

Le prompt : la compétence clé

Intégrer l'IA à chaque étape

Et côté client, qu’est-ce que ça change vraiment ?

Pour conclure

Claude Code, Cursor, Symfony/AI, Vercel AI SDK : 3 formations pour garder la main

Maîtriser les agents IA pour le développement

L'IA pour développeurs frontend, avec Cursor et le Vercel AI SDK

Maîtriser l'IA avec Symfony

Et si vous ne codez pas ?

Pourquoi chez nous ?

Plan de migration vers Tailwind CSS v4 🚀 : la méthode (presque) sans douleur

Phase 1 : Migration des feuilles de styles CSS 🎨

Cas n°1 : Les variables et fonctions

Cas n°2 : Le piège du sélecteur d’imbrication & et du BEM

Cas n°3 : Les media queries

Cas n°4 : Les mixins, boucles et règles complexes

Phase 2 : Migration (provisoire) des classes utilitaires 🧰

Phase 3 : On débranche l’ancien framework CSS 💔

Phase 4 : L'adieu à Sass 🫡

Phase 5 : L'entrée en scène de Tailwind CSS v4 🤩

Le piège de l'import global (et du Preflight)

La magie de la directive @theme

Phase 6 : Le nettoyage de printemps 🧹

Le boss final : Les grilles 😎

Conclusion : Tout ça pour ça ? 🤔

Et concrètement, comment on vend ça à sa direction ?

`SignalableCommandInterface` : gérer les signaux dans une commande Symfony

`getSubscribedSignals()`

`handleSignal()` : décrypter la signature

Intégrer Blackfire via `SIGUSR2`

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

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

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

Cas n°2 : Le piège du sélecteur d’imbrication `&` et du BEM

La magie de la directive `@theme`