Planète PHP

Utiliser PHP avec Airflow

Je travaille actuellement sur un projet orienté BI pour lequel des scripts d’analyse et de visualisation de données sont écrits en Python et sont orchestrés par Apache Airflow. Airflow est un outil Python, initialement conçu et pensé pour l’écosystème Python. Mais travaillant essentiellement en PHP, je me suis demandé s’il était possible d’y faire tourner des scripts PHP.

🇻🇬 This blog post is also available in English.

En parcourant la documentation d’Airflow, on peut se rendre compte que l’outil permet bien plus que d’exécuter des scripts Python. Si Python y est fortement intégré, en réalité, Airflow est capable d’exécuter n’importe quelle commande d’un terminal. Il est donc possible d’orchestrer tout type de script, et donc du PHP.

Les tâches (appelées DAG pour Directed Acyclic Graph) Airflow sont lancées au travers d’opérateur. Parmi ceux disponibles, l’opérateur BashOperator permet d’exécuter une commande dans un worker Airflow sur lequel serait présent PHP et le script à lancer.

Prenons par exemple le script PHP suivant:



La création d’un DAG passe par l’écriture du script Python (c’est le seul moment où ce denier est nécessaire). La mise en place de notre tâche PHP pourrait se faire ainsi:

from airflow import DAG
from airflow.providers.standard.operators.bash import BashOperator
from datetime import datetime

with DAG(
    dag_id="run_php_script",
    description="A DAG that runs a PHP script",
    schedule=None,
    start_date=datetime(2024, 1, 1),
    catchup=False,
    tags=["php"],
) as dag:

    run_php_script = BashOperator(
        task_id="run_php_script",
        bash_command="php /path/to/scripts/hello.php",
    )

Avec ce simple code Python, Airflow déclenche notre script PHP (qui lui peut être bien plus complexe). Les sorties standard et d’erreur sont automatiquement capturées dans les logs Airflow. On peut également bénéficier de toute la mécanique de retry, de monitoring et d’alerting Airflow.

Si vous désirez tester par vous même, vous trouverez tout le nécessaire dans ce dépôt pour démarrer un environnement Airflow avec tout le nécessaire.



Comment intégrer l'IA dans son workflow UX/UI
JoliCode Team
"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.


Dernière semaine de billetterie pour l'AFUP Day 2026
Un événement qualitatif où que vous choisissiez d'aller
Tech pure, arrivée fracassante de l'IA dans notre quotidien, bonnes pratiques, outils qui facilitent le quotidien, sujets plus sociaux ou managériaux... Une chose est sûre : quelle que soit la destination que vous choisirez, comptez sur une programmation de qualité, proposée par des expert·e·s trié·e·s sur le volet, qui vous permettront de voir vos projets sous un nouvel angle. 

Alors que notre secteur est en pleine mutation, échanger, partager et réfléchir collectivement n'a jamais été aussi précieux. C'est ensemble qu'on avance le mieux ! 
La place au tarif de soutien
La billetterie propose actuellement les billets à 110€HT, quelle que soit l'édition à laquelle vous souhaitez participer. Une journée de conférences techniques et actuelles, qui soufflera un vent d'inspiration et de fraîcheur pour aborder vos projets avec un nouvel oeil ! 

Prendre votre place a aussi un impact particulier pour l'AFUP. Nous vous parlons depuis quelques semaines de nos inquiétudes pour l'avenir de l'AFUP. En prenant vos places pour l'AFUP Day 2026, non seulement vous profitez du partage de connaissances, mais vous apportez également un soutien significatif à l'association. Nos conférences sont des parenthèses précieuses pour que la diffusion des connaissances en PHP continue : chaque action compte ! 
Alors prenez vos places d'ici vendredi 15 mai, 23h59, et rejoignez-nous lors de ce grand rassemblement de la communauté PHP !


Faire des requêtes CTE avec Doctrine ORM en PHP
J’ai déjà évoqué sur ce blog que le développement “moderne” avec les ORM masque les fonctionnalités avancées des SGBD au point que dorénavant les développeurs ne maitrisent et ne connaissent guère plus que le classique SELECT ... FROM ... WHERE ....

Dans les mécanismes méconnus et qui pourtant, pourrait permettre de soulager certains traitements applicatifs, on retrouve les CTE (Common Table Expressions). Voyons comment les utiliser avec Doctrine ORM en PHP.



Commençons par expliquer ce qu’est une CTE. Il s’agit d’une sous-requête utilisable comme une table temporaire. C’est une technique utile pour décomposer des requêtes complexes, éviter la duplication de sous-sélections ou écrire des requêtes récursives.

En presque 20 ans d’expérience professionnelle, j’ai très rarement eu l’occasion d’en voir dans le code que je peux être amené à parcourir quotidiennement. Prenons par exemple, un blog où les articles sont rattachés à des catégories, ces dernières organisées sous forme arborescente sous la forme Category(id, label, parent_id). Je suis certain que, si l’on demande à un développeur de récupérer toutes les catégories parentes d’une catégorie précise, ce dernier fera le traitement en PHP avec un code ressemblant au suivant:

// src/Repository/CategoryRepository.php
class CategoryRepository extends ServiceEntityRepository
{
    // ...

    /**
     * @return list
     */
    function getCatagoriesWithParents(int $categoryId): array
    {
        $category = $this->categoryRepository->find($categoryId);

        $categories = [
            $category,
        ];

        while ($parent = $category->getParent()) {
            $categories[] = $parent;
        }

        return $categories;
    }
}

L’inconvénient majeur ici est qu’en interne, Doctrine va faire une requête à chaque tour de boucle. C’est ce que l’on appelle le problème N+1. Pour résoudre ce problème, via une requête SQL, il n’est pas possible de faire un simple SELECT ... FROM ... WHERE, c’est exactement dans ce cas qu’une CTE récursive est utile. Cette dernière peut être écrite de la manière suivante:

WITH RECURSIVE cte_category AS (
    -- point de départ
    SELECT id, label, parent_id, 0 AS depth
    FROM category
    WHERE id = :id

    UNION ALL

    -- récursivité
    SELECT c.id, c.label, c.parent_id, cp.depth + 1
    FROM category c
    INNER JOIN cte_category cp ON c.id = cp.parent_id
)
SELECT id, label, parent_id FROM cte_category
ORDER BY depth DESC

La requête commence par récupérer la catégorie identifiée par :id, puis se joint récursivement à elle-même en remontant via parent_id jusqu’à ce qu’il n’y ait plus de parent. La colonne depth permet ensuite de trier du plus ancien ancêtre jusqu’à la catégorie cible.

Le problème pour faire cette requête avec un ORM tel que Doctrine, c’est que ce dernier ne permet pas de gérer les CTE nativement au travers de son QueryBuilder ni même en DQL. Il est alors nécessaire de passer par une requête native où le résultat final sera mappé sur un objet.

// src/Repository/CategoryRepository.php
class CategoryRepository extends ServiceEntityRepository
{
    // ...

    public function findAllWithParents(int $categoryId)
    {
        $rsm = new ResultSetMappingBuilder($this->getEntityManager());
        $rsm->addRootEntityFromClassMetadata(Category::class, 'c');

        $sql = <<getEntityManager()
            ->createNativeQuery($sql, $rsm)
            ->setParameter('id', $categoryId)
            ->getResult();
    }
}

Dans le code précédent, le ResultSetMappingBuilder se charge de faire correspondre les colonnes retournées avec les propriétés de l’entité Category. On obtient alors en sortie une liste d’instances de Category ordonnés de la racine jusqu’à la catégorie demandée.

Avec ce type de requête, on peut faire énormément de choses, il est par exemple, possible de récupérer tous les articles appartenant à une catégorie enfant en réutilisant la requête précédente:

WITH RECURSIVE category_path AS (
    SELECT id, label, parent_id
    FROM category
    WHERE id = :id

    UNION ALL

    SELECT c.id, c.label, c.parent_id
    FROM category c
    INNER JOIN category_path cp ON c.id = cp.parent_id
)
SELECT a.id, a.title, a.category_id
FROM article a
INNER JOIN category_path cp ON a.category_id = cp.id
ORDER BY a.published_date DESC

En une seule requête, on récupère tous les articles liés à la catégorie cible ou à n’importe lequel de ses ancêtres. Sans CTE récursive, il faudrait soit faire plusieurs requêtes successives pour parcourir la hiérarchie une approche bien moins efficace. Un point d’attention néanmoins, étant donné que l’on exécute une requête SQL native, il faudra faire attention à la portabilité de cette dernière, les CTE pouvant ne pas être disponible sur toutes les bases de données supportées par Doctrine.

De plus, l’utilisation du ResultSetMappingBuilder nécessite que le SELECT de la requête contienne l’ensemble des colonnes nécessaire à l’alimentation de l’objet. À défaut, l’entité sera hydratée de manière incomplète sans qu’aucune erreur explicite ne soit levée.



Claude Code, Cursor, Symfony/AI, Vercel AI SDK : 3 formations pour garder la main
JoliCode Team
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
JoliCode Team
Ç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 ! 🙂


Vibrations, livraison par Pokémon Go et la complexité du temps
Estelle M.
Découvrez notre veille technique du mois de mars entre Web Haptics, rumeurs sur Windows 12, livraisons de pizzas avec Pokémon Go et une valorisation de PHP !
1, Donner de la vie à vos applications mobiles
Votre téléphone ne se contente pas d’afficher ou de sonner ; il vit. À chaque notification, message ou appel, une vibration plus ou moins subtile vient accompagner ce que vous voyez sur l’écran.
Ce retour haptique, popularisé notamment par Apple, fait aujourd’hui partie intégrante de l’expérience mobile, en ajoutant une dimension tactile à nos interfaces.
Depuis longtemps, cette fonctionnalité était réservée aux applications natives. Mais aujourd’hui, grâce à des solutions comme Web Haptics, on peut désormais intégrer des vibrations directement dans les navigateurs.
Au-delà de son aspect technique, l’intérêt de Web Haptics réside dans sa capacité à démocratiser une pratique UX jusqu’ici réservée aux applications mobiles. Grâce à son API simple et ses modèles prêts à l’emploi, les développeurs peuvent intégrer rapidement des retours haptiques adaptés à leurs besoins, et plonger leurs utilisateurs dans des interfaces plus immersives, et intuitives.
2. Les utilisateurs en colère contre Windows.
L’expansion de l’IA fait polémique, de nos jours, c’est un fait. Et vous, que diriez-vous si demain, votre système d’exploitation annonçait vouloir utiliser de l’IA pour gérer vos dossiers, vos photos et vos vidéos stockés sur votre ordinateur ?
Selon une rumeur largement relayée, Windows 12 serait sur le point de sortir avec une approche radicalement différente de ses prédécesseurs, avec un système module fortement centré sur l’intelligence artificielle, et potentiellement accessible via un abonnement. Et si l’on en croit cet article de Patrick Ruiz, cette idée est loin de plaire à tout le monde…
Même si l’article revient en réalité sur des informations incertaines, basées sur des rumeurs et des interprétations de projets internes, il démontre malgré tout l’inquiétude fondée des utilisateurs. Selon ces derniers, ces évolutions comme une véritable dérive vers un système plus intrusif, plus dépendant des services en ligne et potentiellement moins maîtrisable. C’est une approche assez polémique qui soulève une question primordiale ; à partir de quel moment notre ordinateur passera d’outil personnel à service ?
3. Pokémon Go aide aux livraisons de pizza
Pokémon Go a été un succès mondial ; à sa sortie en 2016, il a comptabilisé plus de 500 millions de téléchargements en l’espace de 2 mois. Premier grand succès de la réalité augmentée, il a fait parcourir des milliards de kilomètres à ses utilisateurs prêts à tout pour attraper leur Pokémon préféré, via la caméra de leur téléphone.
Mais cette mine de données, récoltées par ces chasseurs de Pokémons, qu’est-elle devenue, aujourd’hui ? Cet article de la MIT Technology Review nous répond ; ils ont modélisé le monde… pour livrer des pizzas.
Cette réutilisation de données pose évidemment des questions. D’un point de vue industriel, on comprend leur immense valeur. Mais d’un point de vue utilisateur, on peut se demander à quel point chacune de nos interactions numériques alimente des systèmes bien au-delà de leur usage initial ?
Pokémon Go n’était donc pas seulement un jeu en réalité augmentée ; c’était, sans le dire explicitement, une gigantesque opération de cartographie collective dont les bénéficiaires ne sont plus seulement les joueurs.
4. Les fausses idées sur le temps.
En informatique, la notion de temps, globalement universelle, n’est pas seulement une suite de secondes ou de dates ; c’est un calcul plein d’exceptions, de subtilités, et de pièges invisibles. En outre, à chaque fois que l’on peut penser maîtriser une règle simple, une situation concrète vient la remettre en question.
Le site YourCalendricalFallacyIs illustre parfaitement cela, en confrontant nos idées reçues sur le calcul du temps. À travers une série d’énoncés expliqués et corrigés, il met en évidence les nombreux cas où nos intuitions échouent face à la complexité réelle des calendriers.
Un outil pédagogique et presque ludique, qui rappelle aux développeurs que le temps n’est jamais une donnée « simple ».
5. Réaliser des maquettes en un seul clic.
Dans nos articles de veille, nous avons souvent parlé d’applications web pour créer plein de choses avec un seul clic. Aujourd’hui, dans cette même idée, nous vous présentons Stitch.
Concevoir une interface est un vrai métier, qui est très souvent composé d’allers-retours incessants entre idées, envies, et faisabilité.
Stitch, de Google, s’inscrit dans une volonté de simplifier radicalement la réalisation de maquettes. Avec l’utilisation d’un prompt classique des IA, il permet de générer des interfaces complètes à partir de croquis ou d’une simple description, tout en produisant du code exploitable. L’outil ne se limite donc pas à la création visuelle ; il relie directement l’idée au développement.
Néanmoins, si l’application semble innovante et efficace, il faut toujours s’interroger sur la place de la conception traditionnelle face à ce type d’automatisation. Car, après tout, ne vaut-il pas mieux privilégier la qualité au détriment de la vitesse ?
6. Voyez le bon côté de PHP
Le langage PHP est souvent associé à des anciennes limites et à certaines critiques historiques, au point d’être parfois perçu comme un langage dépassé, malgré sa place centrale dans le développement web. Heureusement, le site HaPHPiness est là pour nous aider à voir ses bons côtés !
Organisé par thématique, ce site met en lumière les évolutions récentes de PHP ; typage renforcé, fonctions plus cohérentes, meilleures pratiques de sécurité… Chaque point est accompagné d’exemples concrets, montrant comment ses améliorations simplifient le développement et rendent le langage plus fiable, et plus accessible.
Au-delà de son ton volontairement positif, HaPHPiness joue aussi un rôle pédagogique intéressant : il permet de prendre du recul sur l’image souvent datée de PHP et de découvrir un langage qui continue d’évoluer activement. Et c’est aussi un très bon outil pour les développeurs qui souhaitent se (re)mettre à jour, alors allez-y jeter un œil !
Pour aller plus loin…
Voici les autres liens que vous avez partagés ce mois-ci, bonne lecture !

YGGLeak
Why use static closures? | F2R Articles
Anthropic’s AI tool Claude central to U.S. campaign in Iran, amid a bitter feud
LinkedIn : ChatGPT is abandoning agentic commerce.
SaaSpocalypse : l’effondrement des logiciels SaaS – Numerama
SYSTÈMES AGENTIQUES REDONNER LE POUVOIR AUX MÉTIERS
“C’est probablement fini” : Nvidia arrête les frais avec OpenAI, tout le secteur de l’IA retient son souffle – Les Numériques
Working with stacked branches in Git is easier with –update-refs
The Beginning Of History
Labor market impacts of AI: A new measure and early evidence \ Anthropic
font-optimizer pour réduire de 90% le poids de vos polices dans vos projets PHP
Temporal: The 9-Year Journey to Fix Time in JavaScript | Bloomberg JS Blog
Anthropic dresse un classement des métiers les plus menacés par l’IA
image-set() – CSS | MDN
LinkedIn : Les devs de mon équipe tapent de moins en moins de code.
Google Just Patented The End Of Your Website
Turn your PHP app into a standalone binary
SaaSpocalypse Survival Scanner — Death Report
Pretext Demos
GitHub – chenglou/pretext: Fast, accurate & comprehensive text measurement & layout
Anthropic : une fuite révèle les risques de la future IA « Claude Mythos » pour la cybersécurité – L’Express
Beating every possible game of Pokemon Platinum at the same time
Wind Waker JS

Cet article Vibrations, livraison par Pokémon Go et la complexité du temps est apparu en premier sur Synolia, agence e-commerce, CRM, Data, PIM/DAM, OMS.



Notre retour sur le SymfonyLive Paris 2026
JoliCode Team
Les années passent, mais certaines traditions restent immuables. Il y a quelques jours, la communauté s'est de nouveau réunie à la Cité Universitaire pour l'édition 2026 du Symfony Live Paris.
Si le monde de la tech avance à toute vitesse, le cru 2026 conserve la recette qui a fait son succès. Nous étions, comme à notre habitude, présents au rendez-vous. Voici notre retour sur une édition qui prouve que Symfony reste à la pointe des évolutions.
Keynote de Fabien Potencier

Fabien Potencier nous a présenté un composant Symfony que beaucoup de gens attendaient impatiemment depuis sa première annonce datant de la SymfonyCon 2023 : Symfony TUI (pour Terminal User Interface) !
Avec l'arrivée récente et massive de l’IA dans les habitudes de travail de beaucoup de développeurs, Fabien a trouvé une raison parfaite de relancer son travail sur le composant TUI pour permettre une utilisation plus ergonomique et avancée des LLMs directement depuis un terminal.
On a d’ailleurs eu le droit à une démonstration de son propre coding agent pour voir en direct ce à quoi on pourrait s’attendre avec l'adoption de ce composant pour discuter avec des LLMs. Et le rendu rivalise avec ce qui peut aujourd’hui être proposé directement dans nos IDEs.
Mais au-delà de l’intégration évidente avec l’IA, le composant TUI, c’est aussi une évolution du composant Symfony Console que l’on utilise tous (pour rappel, il s’agit de l’un des  premiers composants de l’écosystème Symfony, sorti il y a 15 ans maintenant). L’objectif ici, c’est de laisser Console s’occuper des parties commandes/arguments/output, pour concentrer toute la partie affichage, interaction et interactivité dans TUI.
Lors de ce talk assez orienté technique, Fabien a expliqué comment TUI fonctionne sous le capot. Sans entrer dans les détails ici, on pourra retenir :

Il existe trois manières de gérer le style: à la manière stylesheet avec des sélecteurs semblables au CSS ; avec des classes utilitaires, comme on le ferait en Tailwind ; ou directement in-line, pour prendre la main de manière ponctuelle comme c'est possible en HTML. Les breakpoints sont aussi gérés avec des media-queries, pour un rendu nativement responsive ;
Beaucoup de Widgets sont disponibles nativement pour gérer la majorité des cas d’usages (ex: TextWidget pour affichage de texte et ASCII, InputWidget pour les entrées textuelles, SelectListWidget pour des listes scrollables, etc.) mais il est évidemment possible de créer nos propres widgets pour des cas particuliers ;
TUI utilise PHP Fibers et Revolt pour assurer un affichage et des animations complètement asynchrones et une gestion parallèle de l’affichage et de l’interactivité avec le développeur.

La liste s’allonge évidemment, et toutes les informations sont disponibles sur le Blog Post dédié à l’arrivée de Symfony TUI.
Pour conclure cette première conférence, Fabien s'est montré particulièrement enthousiaste. Ce nouveau composant Symfony ouvre des portes immenses, aussi bien pour l'affichage dans la console que pour l'intégration de l'intelligence artificielle.
Pour prouver la puissance de son outil, il a même fait une démonstration impressionnante : un jeu de Tetris tournant en direct dans son terminal ! Le rendu est fluide et visuellement bluffant, montrant que l'on peut désormais créer de véritables interfaces graphiques (TUI) modernes, directement en PHP.
Pour terminer, Fabien a lancé une idée très originale pour le futur des contributions sur ce composant : plutôt que d'envoyer une solution toute prête, les développeurs pourraient simplement partager un prompt (une instruction pour l'IA).
Fabien utiliserait alors son propre assistant et ses propres ressources pour transformer ces instructions en code réel et donner vie aux futures améliorations du projet !
La communauté au rythme de l’IA
On se souvient du SymfonyLive 2024, où l’IA générative d'images s'invitait déjà dans de nombreuses présentations. À l'époque, c’était encore une nouveauté impressionnante, bien que limitée.
Cette année, le changement est radical : les agents IA étaient omniprésents dans bon nombre de sujets. Cela reflète parfaitement l'évolution de notre quotidien de développeur, qui s'accélère de plus en plus dans cette direction.
Aujourd'hui, l'IA n'est plus juste un gadget visuel, elle est au cœur du développement de Symfony :

Les nouvelles versions de Twig (le moteur de templates de Symfony) sont désormais gérées de manière quasi automatique par un agent ;
Une grande partie du code source est également générée par des assistants intelligents.

Cependant, un point reste essentiel : l'IA aide à produire, mais elle ne remplace pas l'humain. La responsabilité finale appartient toujours à la personne qui valide le code. C'est le développeur qui vérifie et garantit la qualité de ce qui est produit avant de l'envoyer en production.
L’IA au service des devs : Anatomie d'un assistant de Code Review - Thomas Boileau
La volonté de Thomas est de normaliser l’utilisation de l’IA au sein de sa société. Son constat est qu’il est difficile d’intervenir dans le cycle de développement logiciel, au niveau individuel, car l’usage de l’IA est encore très inégal selon les développeurs. C’est pour ça qu’il a préféré intervenir sur la CI.
Lors de sa présentation, il nous expose donc un cas pratique. Son but : construire un assistant IA qui intervient au moment des code reviews.
Techniquement, dès qu'une PR est labellisé Ready For Review (RFR) alors un webhook est lancé, et l’assistant IA est déclenché.
Ici, ce que l'on apprend n’est pas réellement comment utiliser l’IA, mais plutôt un rappel bienvenu sur l’adoption d’une fonctionnalité par des utilisateurs. Il nous a bien expliqué qu’après sa première itération, quasiment personne n'interagissait avec son agent de revue de code.
En effet, comme toutes les nouveautés, l’essentiel, c'est de construire avec les utilisateurs finaux et d’éviter au maximum la friction. C’est donc après avoir mesuré l’usage de son bot et consulté les développeurs (utilisateurs) qu’il a proposé une nouvelle version, cette fois-ci plus utile pour tout le monde.
Évidement, Thomas nous rappelle qu’il aurait pu utiliser une solution sur étagère, mais il souligne les contraintes réglementaires qui s'appliquent à son domaine.
Sa conclusion est que le plus important dans ce projet reste la DX pour avoir une bonne adoption, et surtout que ce bot IA ne remplace pas l'humain, il est créé dans le but d’être seulement un plus dans la boucle.
Développer un Coding Agent en PHP : dans les coulisses du "Harness" - Fabien Potencier

Tout a commencé par un défi sur Twitter. Un utilisateur affirmait qu'il était impossible de créer un coding agent (un assistant capable de coder de façon autonome) performant en utilisant le langage PHP. Piqué au vif, Fabien Potencier, le créateur de Symfony, a décidé de prouver le contraire en développant son propre assistant.
Plutôt que d'utiliser des outils tout prêts comme GitHub Copilot ou Claude Code, fabriquer son propre agent permet de comprendre les coulisses de l’intelligence artificielle. On découvre alors comment se déroule réellement une "discussion" entre un développeur et un modèle de langage (LLM).
Pour rendre l'outil agréable à utiliser, il a utilisé le composant TUI de Symfony. Cela permet d'avoir une interface textuelle interactive directement dans sa console.
Pour que l'agent soit intelligent, il doit communiquer avec un modèle (comme Claude Opus, Claude Sonnet, GPT 5). Mais les modèles évoluent sans cesse. Fabien a donc créé un petit outil, symfony/models-dev, qui répertorie de manière automatique tous les modèles disponibles afin de toujours utiliser la version la plus récente.
Discuter avec un chat, c'est facile. Mais pour qu'un agent soit utile, il doit pouvoir agir sur votre ordinateur. C'est là qu'interviennent les Tools (outils). De manière surprenante, Fabien n'a eu besoin que de 4 outils de base :

Read : pour lire le contenu d'un fichier.
Write : pour créer un nouveau fichier.
Update : pour modifier un fichier existant sans gaspiller de token.
Bash : pour exécuter n'importe quelle commande (lancer des tests, installer un package, etc.).

Un agent classique oublie tout dès que la session se ferme. Pour corriger cela, chaque échange est enregistré dans une base de données.
L’astuce géniale ? Cette mémoire est stockée sous forme d'arbre. Cela permet à l'agent de revenir en arrière à un point précis pour tester une autre solution si la première n'a pas fonctionné.
Plus on discute avec l'IA, plus le "contexte" (le nombre de mots envoyés) devient important. Si on dépasse la limite du modèle, il sature. Fabien a donc mis en place un système de compression intelligent :

Il garde toujours le tout premier message (les instructions de base).
Il garde les derniers messages récents.
Il résume tout ce qui se trouve entre les deux.

Les conseils de Fabien
Durant sa démonstration, il a partagé quelques astuces précieuses :

Les Skills : Dès qu'il réalise qu'il répète une tâche, ou une instruction, il crée un "skill" (une compétence) pour son agent. C'est comme écrire des tests : on a l'impression de perdre du temps au début, mais on en gagne énormément sur le long terme ;
Le regard neuf : Parfois, l'IA s'embrouille. Fabien conseille de lui demander d'analyser la situation avec "un regard neuf" (fresh eyes). Cela donne souvent des résultats spectaculaires pour débloquer un bug complexe.

Bien qu'il n'ait pas eu le temps de tout montrer, notamment son système d'orchestration dans le cloud, la preuve est faite : le PHP est un langage de choix pour l'intelligence artificielle !
Embeddings en PHP : Symfony AI en pratique - Grégoire Pineau

Le talk de Grégoire nous met tout de suite dans la pratique avec une vraie mise en situation autour des embeddings et de la similarité de contenu.
Il part sur un cas d’usage qui parle à tout le monde : faire correspondre des URLs entre un ancien et un nouveau site. Là où on pourrait partir sur des règles compliquées ou du matching approximatif, les embeddings offrent une solution plus robuste : on compare directement le sens sémantique des pages.
Ce qui marche particulièrement bien, c’est le fil rouge visuel de la conférence. Un schéma du processus est affiché, puis réutilisé à chaque étape. Ce qui rend la progression assez claire : on comprend où on en est, ce qu’on fait, et pourquoi on le fait.
La conférence prend le temps de poser les bases :

ce qu’est un embedding (une représentation vectorielle d’un contenu) ;
à quoi ça sert (mesurer de la similarité sémantique) ;
et surtout dans quels cas ça devient utile.

Ensuite, on rentre dans le concret :

comment choisir un modèle selon son besoin ;
comment vectoriser ses données depuis Symfony ;
où stocker ces vecteurs (PostgreSQL, Redis, etc.) ;
et comment les requêter efficacement.

L'intérêt de cette présentation, c'est que Grégoire nous a montré que tout se fait sans quitter l’écosystème Symfony, grâce à Symfony AI. Cette initiative fournit ainsi toutes les abstractions nécessaires pour manipuler modèles, stores, agents et bien plus encore. N'hésitez pas à consulter le site dédié à Symfony AI pour découvrir tout ça.
Vous pouvez retrouver ses slides en ligne.
Retours d’expériences et présentations techniques
Tous ces nouveaux outils basés sur l'IA ne doivent pas éclipser l'importance de la technicité en dehors de l'intelligence artificielle ! Au contraire, nous apprécions également les outils éprouvés et bien établis, et les retours d'expériences de manière générale.
Chiffrez vos données avec Doctrine, en restant recherchable - Jérôme Tamarelle
Lors de cette conférence, Jérôme Tamarelle a rappelé un point essentiel : la sécurité des données ne concerne pas uniquement les informations directement identifiantes (comme un email ou un nom), mais aussi les données indirectes. Croisées entre elles, ces dernières peuvent suffire à identifier une personne.
Il est important de distinguer deux approches souvent confondues :

Le chiffrement : les données sont transformées de manière réversible. On peut les déchiffrer à l’aide d’une clé ;
Le hashage : il s’agit d’une empreinte unique et fixe d’une donnée. Cette opération est irréversible.
Plusieurs types de chiffrement existent, dont le chiffrement aléatoire et le chiffrement déterministe.

Avec le chiffrement aléatoire, chaque valeur est chiffrée différemment, même si elle est identique à une autre.
Par exemple, une même adresse email enregistrée deux fois en base produira deux valeurs chiffrées différentes.
Avec le chiffrement déterministe, une même donnée produira toujours le même résultat chiffré.
Avec Doctrine, on encapsule le chiffrement directement dans Doctrine via des types personnalisés.
Un champ devient "chiffré" simplement par sa définition.
Mais du coup, on ne peut plus faire de recherche sur ces champs sans passer par Doctrine.
Sécuriser ses données, c’est accepter de complexifier son application. Et surtout, le faire dès la conception.
Doctrine inheritance - Rémi JANOT
Rémi commence par présenter la différence entre héritage (mapper une hiérarchie de classe) et polymorphisme (une clef étrangère qui pointe vers une autre classe) car le vocabulaire utilisé par les différents ORM et framework peuvent parfois prêter à confusion.
S'ensuit un rappel bienvenu de l’héritage implémenté directement au niveau de Doctrine ; avec des exemples concrets, il passe en revue toutes les combinaisons possibles : soit avec des MappedSuperClass, soit des DiscriminatorMap.
Fort de son expérience, il nous explique aussi qu’il est possible d’assez facilement passer d’une architecture Single Table Inheritance (STI) vers Class Table Inheritance (CTI). Donc les choix techniques ne sont pas forcément figés, les projets évoluent, et des solutions sont toujours possibles. Il nous rappelle aussi que lorsqu’on utilise les CTI, il est important de bien vérifier les index pour gagner en performance.
JSON + SQL : hérésie ou élégance ? Retour d'expérience - Rémy Bonfils, Olivier FOURNY
On reste ici dans le thème de la modélisation de nos bases de données avec un retour d’expérience sur l’utilisation de JSON dans nos tables SQL, via l’exemple d’une application mobile offline permettant de configurer des maisons imprimées en 3D (oui oui).
Étant donné la nature très flexible des paramètres d’impression (80000 configurations possibles, importées depuis un CSV), la question de comment les stocker se pose dès le départ.
Rémy et Olivier nous expliquent vouloir tout d’abord se diriger vers une modélisation de type Entity-Attribute-Valeur, où les paramètres ne sont pas représentés par des colonnes dans nos tables, mais par des lignes (ça doit parler aux personnes devant travailler sur des projets Magento ou Drupal) : beaucoup de flexibilité évidemment, mais aussi l’impossibilité d’avoir un minimum de structure dans nos données (tout est varchar). Et surtout des requêtes beaucoup plus complexes et donc des performances catastrophiques.
L’équipe se penche donc sur une autre solution : le stockage des paramètres dans des colonnes de la base de données en format JSON.
Et la surprise, les performances sont à peine inférieures à une modélisation classique de base de données (avec des tables liées par des clés étrangères), mais en gardant la flexibilité voulue ! Et grâce aux fonctions SQL permettant de manipuler du JSON, les requêtes restent simples et lisibles.
Pour notre part, à JoliCode, nous avons l’habitude de profiter du type JSON dans nos bases de données relationnelles (PostgreSQL ou MySQL), et nous vous le recommandons lorsque le besoin s’en fait ressentir.
ClickHouse pour les développeurs Symfony - Romain Neutron

Dans cette session, Romain Neutron a abordé la problématique de la gestion des données analytiques et des logs à grande échelle, des domaines où les bases relationnelles classiques comme MySQL ou PostgreSQL atteignent souvent leurs limites. Il a présenté ClickHouse, une base de données orientée colonnes ultra-performante, comme la solution idéale pour traiter des volumes massifs de données en temps réel. L'idée centrale n'est pas de remplacer votre base de données habituelle, mais de l'épauler pour des besoins spécifiques d'agrégation et de dashboards instantanés.
Côté technique, la conférence a mis en lumière la simplicité d'intégration de ClickHouse dans l'écosystème Symfony. Il a également partagé des benchmarks impressionnants comparant les temps de réponse sur des agrégations de plusieurs millions de lignes, montrant que ClickHouse peut transformer des requêtes de plusieurs secondes en résultats quasi instantanés.
Enfin, Romain a insisté sur les bonnes pratiques et les pièges à éviter, notamment sur la structure des données et le choix des moteurs de table (comme MergeTree). C'est un talk indispensable pour les développeurs cherchant à scaler leur stack analytique tout en restant dans un environnement PHP familier. De notre côté, on utilise ClickHouse dans plusieurs projets, surtout dans redirection.io pour les parties logs, analytics et crawler. On ne peut donc que vous recommander de vous y intéresser.
Ses slides sont disponibles en ligne pour retrouver toutes les informations importantes.
Symfony UX et la suite Hotwired
Cette année, on continue de parler de Symfony UX, et en particulier, deux retours d’expériences spécifiquement axés sur hotwired.dev.
Du web au mobile avec Symfony & Hotwire Native - Imad ZAIRIG
Imad nous a préparé une conférence sur le nouveau bundle Symfony UX Native qui utilise Hotwire Native. Basé sur un exemple, on peut voir comment l’application est architecturée.
On a eu l'exemple d'un bouton, rendu avec un composant bouton mobile, mais dont l'événement click est écouté par stimulus du côté de l’application Symfony
Cela fonctionne avec des webview pour que ce soit toujours Symfony qui gère le back-end et le front, mais avec des comportements mobiles gérés nativement (ex : la navigation et les transitions). On note qu’il y a quand même encore quelques fois ou il faut lancer le projet mobile avec Xcode par exemple pour iOS.
Pour utiliser les capacités natives des applications mobiles (type appareil photo) il faut passer par des "Bridges Component", ça demande malgré tout du code côté mobile.
Selon la complexité de l’application et la taille de l’équipe, Symfony UX Native est une piste à explorer.
Édition simultanée : facile avec Symfony UX - David Buchmann
Au travers d’un exemple concret David nous a fait voir comment intégrer toute la suite d’outils de hotwired.dev. Il commence avec Turbo (et un peu de Turbo Frames aussi) et nous fait voir à quel point c’est bien intégré à Symfony UX. Puis sa conférence continue avec la mise en place de Mercure (grâce à son intégration dans FrankenPHP), et finalement le tout s’intègre parfaitement via des contrôleurs Stimulus qui écoutent les messages Mercure.
Il résume les avantages de Hotwire comme ceci : la logique reste dans le backend, la sécurité est intégrée. La complexité du frontend s’en trouve réduite.
Conclusion
Si cette édition du SymfonyLive Paris 2026 nous a offert un aperçu saisissant de l'intégration massive de l'Intelligence Artificielle au cœur de l'écosystème Symfony, elle prouve une chose essentielle : l'importance des conférences n'a jamais été aussi grande. Notre métier de développeur est en pleine mutation, et nous avons fort à faire pour rester à jour.
Le fil conducteur de cette année reste cependant une évidence : quelle que soit la puissance des outils, l'humain reste au centre de la boucle. L'IA est un assistant extraordinaire pour la production de code et les tâches répétitives, mais c'est bien la communauté, la validation humaine et le partage de connaissances qui garantissent la qualité et la progression de notre écosystème.
Merci aux organisateurs, aux conférenciers, et à la communauté d'avoir fait de cette édition 2026 un moment marquant, et rendez-vous l'année prochaine pour continuer à naviguer ensemble dans le futur du développement web !


Symfony Live 2026 – retours
Yohann Nizon
Récemment, j’ai eu la chance de participer au Symfony Live 2026, l’occasion pour moi de rencontrer mes collègues de Smile, et de voir les dernières tendances du développement PHP. Je vous propose ici un petit retour de cette sympathique expérience. Text User interface: L’ouverture de la conférence a été faite par Fabien Potencier – l’auteur ... Lire la suite
Cet article Symfony Live 2026 – retours est apparu en premier sur Game And Me.



Jane supporte maintenant JSON Schema 2020-12 et OpenAPI 3.1
JoliCode Team
La version v7.11.0 de Jane PHP, le générateur de client d'API et de Normalizer, est désormais disponible. Cette mise à jour majeure du moteur de génération se concentre sur l'alignement avec les derniers standards de l'industrie via le support de JSON Schema 2020-12 et d'OpenAPI 3.1.
🚀 Évolutions majeures
Support de JSON Schema 2020-12
L'un des changements les plus importants introduits dans cette version est l'intégration du support pour JSON Schema 2020-12 (PR #918). Cette mise à jour permet à Jane de traiter des schémas de données beaucoup plus modernes et complexes, offrant ainsi une sémantique plus riche pour la description de vos structures.
Il est important de noter que cette évolution a été pensée pour être totalement transparente : Jane conserve une rétrocompatibilité avec la draft 2019-09. Vous pouvez donc bénéficier des dernières avancées sans craindre pour vos schémas existants.
Cette double compatibilité permet à l'outil d'offrir une précision accrue dans deux domaines :

La génération des modèles PHP : Les classes générées reflètent plus fidèlement les contraintes et relations définies dans vos schémas, réduisant ainsi le besoin d'ajustements manuels.
La validation des données : Le support de ces spécifications garantit que la logique de validation intégrée est en parfaite adéquation avec les exigences modernes des API.

Support d'OpenAPI 3.1
L'autre pilier de cette version est le support de la spécification OpenAPI 3.1 (PR #904). Cette mise à jour est structurante car elle aligne enfin le standard OpenAPI sur JSON Schema, simplifiant ainsi la gestion des modèles de données.
Grâce à ce support, Jane exploite nativement les nouvelles capacités du standard :

Convergence avec JSON Schema : OpenAPI 3.1 devient un "superset" de JSON Schema, permettant à Jane d'interpréter des définitions complexes sans perte d'information.
Typage natif et nullable : Jane utilise la nouvelle syntaxe pour générer des propriétés PHP au typage exact (ex ?string), assurant une cohérence entre votre contrat d'API et votre code.

📖 Nouvelle documentation officielle
Parallèlement à ces évolutions techniques, la documentation du projet a reçu un coup de neuf pour offrir une meilleure expérience aux utilisateurs. Elle centralise les guides d'installation, de configuration et d'utilisation pour l'ensemble des composants.
Elle est disponible ici: jane.jolicode.com
🛠️ Améliorations continues et maintenance
Au-delà de ces évolutions majeures, cette version est aussi l'occasion d'un grand nettoyage de printemps pour le projet. Nous avons consolidé la base de code avec une série de correctifs de stabilité, notamment sur la gestion des types numériques dans les query strings, et une mise à jour globale des outils de maintenance. Ces ajustements, bien que plus discrets, garantissent une meilleure fiabilité du générateur et simplifient l'installation des dépendances pour vos projets.
📦 Lancez-vous !
Toutes ces améliorations sont disponibles dès maintenant via le tag v7.11.0. Que vous souhaitiez profiter des dernières spécifications OpenAPI ou simplement bénéficier d'un moteur de génération plus robuste, nous vous encourageons vivement à mettre à jour vos projets :
composer update jane-php/* -W
N'hésitez pas à tester ces nouveautés, à explorer la nouvelle documentation et à nous faire part de vos retours sur GitHub. Jane continue de grandir grâce à vos usages et vos contributions, alors profitez-en bien !

📚 Documentation officielle : jane.jolicode.com
💻 Dépôt GitHub : janephp/janephp
🚀 Release v7.11.0 : Consulter le changelog



Déploiement On-Premise - Partie 2 - Castor à la rescousse
JoliCode Team
Dans le précédent article, nous avons vu toutes les étapes nécessaires pour préparer les images Docker qui seront utilisées en production. Mais nous allons maintenant aller plus loin pour automatiser et simplifier encore un peu plus cette étape grâce à Castor et les runners GitLab, le but étant de
faciliter la procédure de déploiement de nouvelles versions de l'application afin que le client puisse
être autonome.
Création et publication des images
Comme souvent quand nos projets nécessitent de lancer des commandes, nous mettons en place des tâches Castor pour simplifier la DX. Nous avons donc créé une task production:build qui applique tout ce que nous avons vu dans l'article précédent :
<?php

use Castor\Attribute\AsOption;
use Castor\Attribute\AsTask;
use Castor\Exception\ProblemException;
use Symfony\Component\Console\Input\InputOption;

use function Castor\capture;
use function Castor\check;
use function Castor\context;
use function Castor\fs;
use function Castor\io;
use function Castor\run;
use function Castor\variable;

const REGISTRY = '<url du registre>:4567/plancq/arsol/';
const DEFAULT_BRANCH = 'main';
const BAKE_FILE = __DIR__ . '/../infrastructure/production/bake.hcl';
const IMAGES_TO_TAG = [
    'postgres:16' => 'postgres',
    'getmeili/meilisearch:v1.16' => 'meilisearch',
];

#[AsTask(description: 'Build production docker images', namespace: 'production:docker')]
function build(
    #[AsArgument(description: 'Version of the images')]
    ?string $tagVersion = null,
    #[AsOption(description: 'Force the build whatever the current branch state')]
    bool $force = false,
    #[AsOption(description: 'Push the images to the registry', mode: InputOption::VALUE_NEGATABLE)]
    ?bool $push = null,
    #[AsOption(description: 'Update docker-compose.yml with current tag', mode: InputOption::VALUE_NEGATABLE)]
    ?bool $updateDockerCompose = null,
): void {
    $currentBranch = capture(['git', 'branch', '--show-current']);
    check('Checking current branch:', 'You must be on the main branch to build the production images. Change the current branch or use --force to bypass this check.', static fn () => DEFAULT_BRANCH === $currentBranch || $force);

    $currentChanges = capture(['git', 'status', '--porcelain']);
    check('Checking git working tree:', 'You have uncommitted changes. Git stash everything before building image or use --force to bypass this check.', static fn () => !$currentChanges || $force);

    if (!$force) {
        run(['git', 'pull', 'origin', DEFAULT_BRANCH]);
    }

    $validateVersion = static function (string $tagVersion): string {
        if (!$tagVersion) {
            throw new \RuntimeException('Version is required');
        }

        if (!preg_match('/^20\d{2}\.\d{2}\.\d{2}+(-\d+)?$/', $tagVersion)) {
            throw new \RuntimeException('Version must be in the format YYYY.MM.DD (eventually with a revision like YYYY.MM.DD-1), got: ' . $tagVersion);
        }

        return $tagVersion;
    };

    if ($tagVersion) {
        $tagVersion = $validateVersion($tagVersion);
    } else {
        $tagVersion = io()->ask('Please provide the version of the production images to build:', date('Y.m.d'), $validateVersion);
    }

    $tags = [$tagVersion, 'lastest'];

    io()->section('Building the local development images...');
    \docker\build();

    if (fs()->exists(context()->workingDirectory . '/.dockerignore')) {
        fs()->rename(context()->workingDirectory . '/.dockerignore', context()->workingDirectory . '/.dockerignore.tmp', true);
    }

    try {
        $command = [
            'docker', 'buildx', 'bake',
            '--file', BAKE_FILE,
            '--load',
        ];

        foreach (getImagesToBuild() as $targetName => $config) {
            foreach ($tags as $tag) {
                $command[] = '--set';
                $command[] = $targetName . '.tags+=' . REGISTRY . $targetName . ':' . $tag;
            }

            $command[] = '--set';
            $command[] = $targetName . '.args.PROJECT_NAME=' . variable('project_name');
        }

        run($command);
    } finally {
        if (file_exists(context()->workingDirectory . '/.dockerignore.tmp')) {
            fs()->rename(context()->workingDirectory . '/.dockerignore.tmp', context()->workingDirectory . '/.dockerignore', true);
        }
    }

    foreach (IMAGES_TO_TAG as $sourceImage => $image) {
        foreach ($tags as $tag) {
            run(['docker', 'image', 'pull', $sourceImage]);
            run(['docker', 'image', 'tag', $sourceImage, REGISTRY . $image . ':' . $tag]);
        }
    }

    io()->success('Production images are now built.');

    if ($updateDockerCompose || (null === $updateDockerCompose && io()->confirm('Do you want to update the docker-compose with the current version?', false))) {
        updateDockerCompose($tagVersion);
    } else {
        io()->info('You can update the production docker-compose.yml file by running the following command:');
        io()->info('castor production:docker:update-docker-compose ' . $tagVersion);
    }

    if ($push || (null === $push && io()->confirm('Do you want to push the images to the registry (you may want to play with the images before pushing)?', false))) {
        push($tagVersion);
    } else {
        io()->info('You can push the images to the registry by running the following command:');
        io()->info('castor production:docker:push');
    }

    io()->success('Great job! Everything is now done.');
}

#[AsTask(description: 'Push production docker images', namespace: 'production:docker')]
function push(?string $tag = null): void
{
    io()->info('Pushing image to the registry...');

    foreach ([...array_keys(getImagesToBuild()), ...IMAGES_TO_TAG] as $image) {
        io()->write(\sprintf('Pushing %s image...', $image));
        if ($tag) {
            run(['docker', 'image', 'push', '--disable-content-trust', REGISTRY . $image . ':' . $tag]);
        } else {
            run(['docker', 'image', 'push', '--disable-content-trust', '--all-tags', REGISTRY . $image]);
        }
    }

    io()->success(\sprintf('Production images have been pushed to the registry %s', REGISTRY));
}

function getImagesToBuild(): array
{
    $bakeConfigOutput = capture([
        'docker', 'buildx', 'bake',
        '--file', BAKE_FILE,
        '--print',
    ]);

    $bakeConfig = json_decode($bakeConfigOutput, true);

    if (null === $bakeConfig) {
        throw new ProblemException('Failed to parse bake.hcl output as JSON.');
    }

    if (!\is_array($bakeConfig) || !isset($bakeConfig['target']) || !\is_array($bakeConfig['target'])) {
        throw new ProblemException('Invalid bake.hcl structure or missing targets.');
    }

    return $bakeConfig['target'];
}


    
                    
                
            
                        Info
    
    
                
Nous recommandons généralement de placer les tâches et fonctions du projets dans des fichiers .php dans le dossier .castor/ à la racine du dépôt.
        


Pour résumer, cette task tout-en-un va :

s'assurer que vous êtes sur la branche main, à jour et sans modification locale ;
demander la version des tags à créer en prenant par défaut la date du jour ;
construire la stack Docker de dev si nécessaire (pour avoir les images de base utilisées) ;
exécuter la commande Bake pour construire/taguer les images PHP ;
exécuter les commandes Docker pour construire/taguer les images publiques (Postgres et Meilisearch) ;
demander si vous voulez mettre à jour la version des images dans le docker-compose.yml final (si jamais vous voulez tester l'application en local avant de publier la version) ;
demander si vous voulez publier les images sur le registry.

Chaque paramètre de cette task (la version à taguer, la confirmation de push ou de mise à jour du docker-compose.yml) est optionnel. S'ils ne sont pas spécifiés, la task les demandera de manière intéractive.
Il est maintenant très facile de publier une nouvelle version du projet pour n'importe quel intervenant du projet (tant qu'il a accès au registre Docker évidemment). Mais on peut aller encore un peu plus loin pour faciliter, cette fois, l'exploitation de l'infrastructure de production.
Pilotage de l'infrastructure
Pour démarrer le projet (que ce soit en production, en pré-production ou sur du on-premise), nous avons besoin de 3 choses :

créer le fichier docker-compose.yml avec tous les services définis ;
créer un fichier .env pour configurer l'application Symfony ;
lancer la commande docker compose up -d.

Nous allons tout d'abord créer un nouvel ensemble de task Castor qui vont permettre de tout de piloter l'infrastructure docker :
<?php

namespace production;

use Castor\Attribute\AsTask;
use Castor\Context;
use Castor\Event\BeforeExecuteTaskEvent;
use Castor\Exception\ProblemException;
use Symfony\Component\Process\Exception\ProcessFailedException;

use function Castor\context;
use function Castor\fs;
use function Castor\io;
use function Castor\load_dot_env;
use function Castor\run;
use function Castor\wait_for_docker_container;

#[AsTask(description: 'Start production infrastructure')]
function start(): void
{
    try {
        production_docker_compose(['up', '-d']);
    } catch (ProcessFailedException $e) {
        if (preg_match(
            '/Bind for (.*):(?<port>\d+) failed: port is already allocated/mi',
            $e->getProcess()->getErrorOutput(),
            $matches
        )) {
            throw new ProblemException(\sprintf('It seems that port %s is already used on your machine. Please free this port and try again.', $matches['port']), previous: $e);
        }

        throw $e;
    }

    io()->success('Production infrastructure has been started. It should be available in a few seconds.');

    $url = 'https://' . $_ENV['SERVER_NAME'];

    wait_for_docker_container('arsol-' . $_ENV['ARSOL_INSTANCE'] . '-frontend-1', timeout: 60, intervalMs: 1000);

    io()->success(\sprintf('Production infrastructure is now ready at %s. Enjoy!', $url));
}

#[AsTask(description: 'Stop production infrastructure')]
function stop(): void
{
    io()->title('Stopping production infrastructure');

    production_docker_compose(['stop']);

    io()->success('Production infrastructure has been stopped.');
}

function production_docker_compose(array $arguments): void
{
    load_dot_env(context()->workingDirectory . '/.env');

    run(['docker', 'compose', '-f', 'docker-compose.yml', '-p', 'arsol-' . $_ENV['ARSOL_INSTANCE'], ...$arguments]);
}


    
                    
                
            
                        Info
    
    
                
Cette fois, nous plaçons les tasks et fonctions destinées à être utilisées en production dans un dossier tools/production/castor.php. Nous expliquerons l'intérêt de séparer ces tasks dans un dossier à part dans le chapitre suivant.
        


Avec ces deux tasks, on peut maintenant lancer castor production:start et castor production:stop. Mais pour une meilleure DX, on va également créer automatiquement le fichier .env de base ainsi que le fichier docker-compose.yml s'ils n'existent pas encore. Cela se fait facilement avec le système de Listener intégré dans Castor :
use Castor\Attribute\AsListener;
use Castor\Event\BeforeExecuteTaskEvent;

use function Castor\context;
use function Castor\fs;
use function Castor\io;

const DOT_ENV_GENERABLES = [
    'APP_SECRET',
    'POSTGRES_PASSWORD',
    'MEILI_MASTER_KEY',
];

#[AsListener(BeforeExecuteTaskEvent::class)]
function configure(BeforeExecuteTaskEvent $event): void
{
    $context = context();

    $taskName = (string) $event->task->getName();
    if (!str_starts_with($taskName, 'production:')
        || str_starts_with($taskName, 'production:docker:')
        || 'production:repack' === $taskName) {
        return;
    }

    if (!fs()->exists($context->workingDirectory . '/docker-compose.yml')) {
        io()->info('No docker-compose.yml file found in the current directory. Creating one from the default template.');
        fs()->copy(__DIR__ . '/docker-compose.yml', $context->workingDirectory . '/docker-compose.yml');
    }

    if (!fs()->exists($context->workingDirectory . '/.env')) {
        io()->info('No .env file found in the current directory. Creating one from the default template.');
        fs()->copy(__DIR__ . '/.env.production', $context->workingDirectory . '/.env');
    }

    foreach (DOT_ENV_GENERABLES as $envVar) {
        $dotEnvContent = file_get_contents($context->workingDirectory . '/.env');

        if (preg_match('/^' . preg_quote($envVar, '/') . '=.+$/m', $dotEnvContent)) {
            continue;
        }

        $value = bin2hex(random_bytes(16));
        $dotEnvContent = preg_replace('/^' . preg_quote($envVar, '/') . '=.*/m', $envVar . '=' . $value, $dotEnvContent);

        file_put_contents($context->workingDirectory . '/.env', $dotEnvContent);
    }
}
Nous avons également ajouté quelques tasks supplémentaires pour afficher les logs du projet Docker compose, pour afficher l'état des conteneurs ou encore pour détruire complètement toute trace du projet (pratique quand on veut juste tester la stack).
Création d'un exécutable
Castor propose une fonctionnalité de repack qui permet de packager un projet Castor avec ses tasks dans un Phar autonome, ce qui permet de le partager et l'utiliser sans avoir besoin d'avoir le code du projet, ni même d'avoir Castor installé. C'est parfait pour notre environnement de production / On-Premise car hormis PHP, nous avons rien à installer à l'avance pour pouvoir démarrer l'application.
Dans le dossier tools/production/, nous allons donc placer plusieurs fichiers qui seront inclus dans le phar :

un fichier .env.production avec les vars d'env à définir obligatoirement ;
le fichier docker-compose.yml vu dans le précédent article ;
le fichier castor.php du chapitre précédent qui contient les tasks pour piloter la stack.

Nous allons donc maintenant pouvoir repacker le projet Castor situé dans ce dossier tools/production/. La commande à lancer en dev pour repacker notre projet sera évidemment encapsulée dans une task Castor (donc placée dans le dossier habituel .castor/) :
const PRODUCTION_DIRECTORY = __DIR__ . '/../tools/production/';

#[AsTask(description: 'Repack production application in a new phar')]
function repack(): void
{
    io()->title('Repacking production application.');

    // Castorception \o/
    run('castor repack --app-name=arsol --no-logo', context: context()->withWorkingDirectory(PRODUCTION_DIRECTORY));

    fs()->mkdir(PRODUCTION_DIRECTORY . '/build');
    fs()->remove(finder()->in(PRODUCTION_DIRECTORY . '/build')->ignoreDotFiles(false));
    fs()->rename(PRODUCTION_DIRECTORY . '/arsol.linux.phar', PRODUCTION_DIRECTORY . '/build/arsol.phar', true);
}
Il ne reste qu'à installer le fichier tools/production/build/arsol.phar sur le serveur, par exemple dans /usr/bin/local/arsol. On peut dès maintenant lancer la commande arsol production:start (notez le nom de l'exécutable 😎) pour initialiser et démarrer complètement l'infrastructure.


    
                    
                
            
                        Info
    
    
                
Si nous le voulions, nous pourrions également compiler ce phar dans un binaire statique contenant PHP, ce qui aurait éliminé le besoin d'avoir PHP installé sur le serveur pour pouvoir utiliser le projet repacké. N'hésitez pas à jeter un œil à la documentation Castor qui explique comment compiler son projet.
        



Automatiser le build depuis Gitlab
Dernière étape pour simplifier la vie du client, nous allons automatiser plusieurs choses directement depuis Gitlab :

Le build des images Docker de prod et le push sur le registre Docker ;
Le repack du projet tools/production dans un phar autonome ;
Ajout de ce phar dans les artefacts associés du job pour le rendre facilement accessible.

Voici un extrait du fichier .gitlab-ci.yml qui permet de faire cela :
stages:
  # ...
  - release

variables:
  CASTOR_CONTEXT: ci
  CASTOR_WORKING_DIR: /tmp/castor/${CI_PIPELINE_ID}

# ...

release:
  stage: release
  script:
    - export TAG=$(date +%Y.%m.%d)
    - export RELEASE_DIRECTORY=/tmp/castor-release/${TAG}
    - rm -rf ${RELEASE_DIRECTORY}
    - git clone . ${RELEASE_DIRECTORY}
    - cd $RELEASE_DIRECTORY
    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
    - castor production:docker:build --push --update-docker-compose "$TAG" --force
    - castor production:repack
    # On déplace le phar à la racine, pour qu'il soit exposé en tant qu'artefact du job
    - cp tools/production/build/arsol.phar "$CI_PROJECT_DIR/"
    # On est sur un self-hosted runner donc on fait le ménage avant de terminer
    - castor docker:destroy --force
    - rm -rf $RELEASE_DIRECTORY

  # Cet artefact sera associé au job, et donc facilement récupérable depuis GitLab
  artifacts:
    paths:
      - arsol.phar
    expire_in: 1 week

  # Ce job est à lancer manuellement et n'est disponible que sur la branche main
  when: manual
  allow_failure: true
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
    - when: never
Avant de finir cet article, je voudrais revenir sur un point vu précédemment. Vous vous souvenez de la variable PROJECT_NAME qui était employée pour préfixer le nom de l'image de la stack de dev ? C'était nécessaire justement quand la stack de prod est construite dans la CI GitLab.
En effet, comme nous utilisons un runner self-hosté, les jobs ne sont pas isolés et tournent sur la même machine en parallèle. Pour ne pas avoir de conflits dans les noms et avoir une stack Docker indépendante entre chaque build de la CI, nous avons donc besoin que les projets Docker compose utilisent un nom unique pour chaque build. Notre template docker-starter est parfaitement compatible avec ce use-case et expose une variable dans le contexte qui permet d'adapter le nom du projet Docker compose à notre guise :
// castor.php à la racine du projet

function create_default_variables(): array
{
    return [
        // Nom du projet docker compose par défaut en local
        'project_name' => 'arsol',
        // ...
    ];
}
// .castor/context.php


#[AsContext(name: 'ci')]
function create_ci_context(): Context
{
    $pipelineId = $_SERVER['CI_PIPELINE_ID'] ?? throw new \RuntimeException('CI_PIPELINE_ID is not set. This context should only be used in a CI environment.');

    $c = create_test_context();

    return $c
        ->withData([
            'project_name' => 'arsol-ci-' . $pipelineId,
            'docker_compose_files' => [
                'docker-compose.yml',
                'docker-compose.ci.yml',
            ],
        ], recursive: false)
    ;
}
Comme nous forçons le context CASTOR_CONTEXT=ci dans GitLab, toutes les stacks construites dans cet environnement sont automatiquement nommées avec un suffixe qui reprend l'id de la pipeline actuelle.
Au passage, on rajoute un docker-compose.ci.yml au projet qui va rajouter quelques configurations spécifiques à la CI (comme des variables d'environnement ou un routeur adaptés)
Conclusion
Pour conclure, grâce au template docker-starter et à Castor, nous avons pu mettre en place un déploiement d'ArSol qui convient à la fois pour la production et le On-Premise mais qui reste simple à l'usage :

Les images Docker pré-construites garantissent des déploiements fiables et déterministes ;
Les images sont optimisées pour ne contenir que ce qui est nécessaire, sans les outils de build ;
Tout passe par Castor, la complexité Docker/CI est masquée ;
Le repack Castor génère un seul exécutable (arsol.phar) pour tout gérer (démarrer, arrêter, mettre à jour) sur site, même sans être un expert système.

L'automatisation complète via Castor et GitLab CI permet au client d'être autonome pour préparer et déployer une mise à jour pour tous les environnements. Une preuve que Docker et Castor sont la bonne formule pour transformer des contraintes de terrain en solutions d'infrastructure efficaces et élégantes.


Déploiement On-Premise - Partie 1 - Le socle Docker
JoliCode Team
Dans cet article, nous vous expliquons notre approche de déploiement hybride pour une application Symfony conteneurisée avec Docker. Ce système permet un déploiement à la fois sur des serveurs connectés à Internet et en mode local (on-premise) pour les zones de travail sans connectivité réseau.
Le contexte
Nous avons récemment entrepris la refonte complète de l'application ArSol pour l'équipe archéologique de l'université de Tours. Le logiciel original, une application desktop, était obsolète. Nous l'avons entièrement modernisé en développant une application web sur mesure... avec une interface utilisateur considérablement rajeunie de plusieurs décennies propulsée avec Symfony 7.4, PHP 8.4 et FrankenPHP.
Une des particularités du projet, c'est que l'application peut être utilisée sur des lieux de fouilles archéologiques ne disposant pas de réseau. Pour plusieurs raisons, l'idée d'une PWA a été écartée assez rapidement. Nous avons plutôt opté pour un mode de déploiement On-Premise : chaque site de fouille pourra ainsi faire tourner l'infrastructure complète (serveur web, bases de données et application Symfony) sur une machine locale. Les contraintes métiers nous ont permis de développer, sans trop de complexité, un système de verrouillage partiel de l'application (pour éviter tout conflit) et une synchronisation des données entre le SaaS (c'est-à-dire la production, le serveur central) et les instances On-Premise.

Je vais vous montrer aujourd'hui comment nous avons mis en place ce déploiement On-Premise (que j'abrégerai OP dans la suite de cet article). D'abord, nous verrons comment se présente la stack Docker, puis comment nous avons automatisé la création des images et le déploiement.
La base Docker
Pour ce projet, nous avons choisi de déployer l'application via des images Docker, aussi bien pour la production que pour les instances OP. Ainsi, ce sont les mêmes images Docker qui seront utilisées dans le mode SaaS et dans le mode OP. L’activation des différentes options et feature flags repose exclusivement sur des variables d’environnement.
La stack de dev
Sur tous nos projets, nous utilisons docker-starter et ArSol n'y a pas fait exception. Ce squelette fournit une stack Docker complète, avec tout ce qu'il faut dedans pour que chaque intervenant du projet puisse le faire tourner en local facilement.
Docker-starter s'est amélioré au fil des années pour offrir une excellente DX à tous nos développeurs, qu'ils soient développeurs PHP ou intégrateurs, qu'ils soient à l'aise avec le fonctionnement de Docker ou pas du tout.
Pour cela, toute la stack est pilotée par des tasks Castor 🦫 :

castor start : construit les images si nécessaire, les démarre, installe les dépendances Composer/Yarn/npm, build les assets front, etc. Bref, cette seule commande suffit pour rendre le projet complètement fonctionnel en local, que ce soit au premier lancement ou aux lancements suivants ;
castor migrate : joue les migrations Doctrine ;
castor stop : stoppe toute la stack ;
et plein d'autres tasks pour les power users ou pour ceux qui veulent lancer une tâche particulière, par exemple ré-installer les dépendances, exécuter les tests, etc.

Cette infrastructure dockerisée est parfaite pour le développement :

Les tâches castor fournies couvrent une bonne partie des besoins du quotidien ;
Le code du projet n'est pas copié/collé dans les conteneurs, mais "monté" dans des volumes pour chaque conteneur. Ainsi, les modifications dans le code sont directement disponibles dans les conteneurs, pas de build/restart à faire à chaque modification.

Comment passer en production ?
Si Docker-starter est parfait pour l'environnement de développement, il ne doit toutefois pas être utilisé tel quel en production.
En production, la priorité est la fiabilité, la sécurité, la rapidité de déploiement et la reproductibilité de l'environnement. Contrairement à l'environnement de développement où le montage de volume permet l'itération rapide du code, en production, on cherche à minimiser les étapes au moment du déploiement.
Avoir des images pré-construites garantit que l'image qui a été testée et validée contient exactement le code, les dépendances (Composer, Yarn/npm) et les assets frontend nécessaires et compilées. Cela élimine le besoin d'exécuter des commandes de build ou d'installation au moment du lancement des conteneurs (sur les serveurs de production ou sur les instances On-Premise). Cela réduit ainsi le risque d'erreurs dues à des dépendances externes ou des configurations de l'environnement hôte. C'est la garantie d'un déploiement "figé" et déterministe.
D'ailleurs, comme les assets sont buildées en amont, nous n'avons pas besoin de NodeJS dans le conteneur final, ce qui permet également d'avoir des images plus légères in-fine.
L'objectif est d'avoir des images Docker prêtes pour la production, mais aussi utilisables pour la pré-production et le déploiement on-premise.
L'important, c'est la santé
Dans l'idéal, nous souhaitons également que chaque service définisse son propre healthcheck. Un healthcheck est une commande que Docker pourra exécuter pour déterminer si le conteneur est toujours en bon état. Si ce n'est pas le cas, Docker tentera de redémarrer le conteneur. Voilà un exemple de healthcheck permettant de vérifier si un serveur MySQL est toujours opérationnel dans un conteneur :
mysqladmin ping -h localhost
Il se configure de cette manière dans un docker-compose.yml classique:
services:
  mysql:
    image: "mysql"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]
      timeout: 20s
      retries: 10
En général, je préfère que les images "applicatives" déclarent elles-mêmes leur healthcheck plutôt que de laisser l'utilisateur le définir lui-même dans son docker-compose.yml. Cela offre, selon moi, deux avantages :

l'image garde la responsabilité de tout configurer comme il faut : l'utilisateur n'a pas besoin de savoir ce qui tourne dans l'image, comment vérifier que tout fonctionne (faut-il utiliser wget, curl ou un autre outil pour avoir l'état du service), etc ;
le docker-compose.yml reste le plus simple possible pour l'utilisateur.

Cela se fait grâce à l'instruction HEALTHCHECK directement dans le dockerfile de l'image en question. Voici un exemple d'un healthcheck qu'on pourrait définir dans le Dockerfile pour un conteneur faisant tourner un serveur web :
HEALTHCHECK --interval=5m --timeout=3s CMD curl -f http://localhost/ || exit 1



    
                    
                
            
                        Info
    
    
                
Certaines images publiques ne fournissent volontairement pas de healthcheck. Il faudra donc le configurer nous-même, soit dans une image à vous, soit dans le docker-compose.yml.
        


Publication et utilisation des images finales
Une fois les images construites, il faut les publier sur un registre Docker pour les mettre à disposition des différents environnements cibles (que ce soit votre serveur de production, dans un Kubernetes, etc). Docker fournit un registre par défaut qui s'appelle Docker Hub. C'est sur ce service que Docker va chercher les images qu'il ne connaît pas encore localement (par exemple depuis un FROM xxx dans un Dockerfile ou depuis un docker-compose.yml). La plupart des systèmes de gestion de code comme GitHub ou GitLab fournissent également un registre de conteneur pour stocker de manière privée vos images Docker. Ces images, dans le cadre d'ArSol, sont stockées dans le registre GitLab du client.
Une fois que tout est prêt, nous obtenons le docker-compose.yml suivant (simplifié dans le cadre de cet article) :
volumes:
  postgres-data: {}
  caddy_data: {}
  caddy_config: {}

services:
  frontend:
    image: "<url du registre>/arsol/frontend:2025.10.23"
    restart: unless-stopped
    env_file: .env
    depends_on:
      postgres:
        condition: service_healthy
      meilisearch:
        condition: service_healthy
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: "<url du registre>/arsol/postgres:2025.10.23"
    restart: unless-stopped
    env_file: .env
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      timeout: 5s
      retries: 5

  worker-messenger:
    image: "<url du registre>/arsol/worker-messenger:2025.10.23"
    restart: unless-stopped
    env_file: .env
    depends_on:
      frontend:
          condition: service_healthy
      postgres:
        condition: service_healthy


    
                    
                
            
                        Info
    
    
                
Les volumes pour caddy sont importants pour permettre la génération automatique des certificats SSL.
        


Vous noterez que nous avons spécifié, pour chaque image, un tag basé sur une date (en l'occurrence 2025.10.23). En effet, quand Docker a déjà récupéré un tag pour une image donnée, il ne cherchera pas à la mettre à jour à moins de nettoyer les images locales (ou à moins de forcer le pull avec l'option docker run --pull=always). Si on utilisait un tag fixe (comme latest par exemple), les images ne seraient jamais mises à jour sur la machine, quand bien même le tag en question aurait changé sur le registre pour cibler une nouvelle version.
Une fois le docker-compose.yml configuré, et le fichier .env créé, nous pouvons lancer docker compose -f docker-compose.yml up -d, et voilà 🎉 : l'infrastructure de production est opérationnelle en HTTP et HTTPS.
La seule différence pour mettre en place une instance OP sera le contenu du .env pour activer/désactiver certaines fonctionnalités spécifiques à ce mode (comme les écrans pour déclencher la synchronisation avec le SaaS, ou la désactivation des données des autres sites archéologiques). Et pour déployer une nouvelle version, il nous faut construire et taguer une nouvelle version de nos images, mettre à jour le docker-compose.yml pour utiliser la bonne version des images et relancer la commande docker compose.
Maintenant que l'objectif est clair, voyons en détails comment y parvenir.
Construction des images
Ici, nous voulons construire toutes les images Docker nécessaires pour faire tourner le projet. À cette étape, nous devons considérer deux cas, suivant si nous utilisons des images publiques telles quelles ou s'il s'agit de nos propres images spécifiques à ArSol.
Images publiques
Dans un premier temps, parlons des images publiques que nous utilisons telles quelles (comme pour Postgres ou Meilisearch). Nous pourrions réutiliser ces images présentes sur le Docker Hub. Mais à la place, nous allons plutôt taguer ces images avec notre système de tag et les pousser sur notre propre registre Docker. Cela apporte plusieurs avantages :

toutes les images du projet utilisent le même tag (plus simple pour s'y retrouver) ;
le projet n'est dépendant que d'un seul registre Docker, celui du client.

Pour celles-ci, nous allons simplement créer un nouveau tag sur les images en question et les publier sur notre registre Docker privé :
# Tag de l'image
docker image tag <le nom de l'image>:<la version de l'image> <url du registre>/arsol/<le nom de l'image chez nous>:<la version de l'applicatif>

# Publication de l'image sur le registre
docker image push --disable-content-trust <url du registre>/arsol/<le nom de l'image chez nous>:<la version de l'applicatif>


    
                    
                
            
                        Info
    
    
                
Ici, nous n'allons pas utiliser le système de signature des images, donc nous désactivons la validation des images côté registre en utilisant l'option --disable-content-trust.
        


Par exemple, pour meilisearch, cela nous donnerait quelque comme cela pour publier le tag "daté" ainsi que le tag latest :
docker image tag getmeili/meilisearch:v1.16 <url du registre>:4567/plancq/arsol/meilisearch:2025.10.23
docker image tag getmeili/meilisearch:v1.16 <url du registre>:4567/plancq/arsol/meilisearch:latest
docker image push --disable-content-trust <url du registre>:4567/plancq/arsol/meilisearch:2025.10.23
docker image push --disable-content-trust <url du registre>:4567/plancq/arsol/meilisearch:latest
Nous pouvons maintenant utiliser cette image directement dans notre docker-compose.yml.
Images applicatives
En revanche, pour les images avec PHP (frontend et worker) contenant le code de l'application, les dépendances & cie, c'est un peu plus compliqué comme nous allons le voir.
La stack de dev comme base
Nous allons nous servir des images de la stack de dev comme base pour nos images de production. En effet, dans Docker-starter, nos images customs suivent déjà plusieurs bonnes pratiques, notamment pour optimiser leur poids :

les instructions RUN sont regroupées le plus possible pour réduire le nombre de couches de l'image (layer squashing) ;
un nettoyage immédiat du cache et des fichiers temporaires est fait pour chaque commande afin de diminuer la taille de chaque layer, et donc le poids final de l'image ;
le build "multi-stage" est utilisé pour ne pas inclure les outils de dev dans l'image finale (composer, nodejs, yarn, etc) mais uniquement dans une image builder utilisée quand il y a besoin de ces outils.

Pour la production, nous allons appliquer la même logique. Nous créerons donc un Dockerfile unique avec plusieurs stages qui nous donnera les différentes images finales à construire, mais en partant des différentes images de dev pour éviter d'avoir à dupliquer et maintenir une autre installation de PHP dans la bonne version, avec les bonnes extensions, configurer FrankenPHP et caddy, etc.
Voyons à quoi ressemble ce Dockerfile dans les grandes lignes.
Le builder et la préparation de l'application
En premier, nous définissons un stage "builder", qui se base sur notre builder de dev et va faire toutes les étapes nécessaires pour installer le projet (installations composer et yarn, construction des assets, etc) :
ARG PROJECT_NAME
FROM ${PROJECT_NAME}-builder AS production-builder

ENV APP_ENV=prod
ENV COMPOSER_MIRROR_PATH_REPOS=1
ENV NODE_ENV=production

# C'est dans ce dossier que nous allons travailler
WORKDIR /var/www

# On récupère les fichiers composer.json et composer.lock et on lance Composer
COPY composer.* /var/www/

RUN composer install \
    --no-dev \
    --prefer-dist \
    --no-scripts \
    --no-interaction \
    && composer clear-cache

# Pareil pour Yarn
COPY package.json yarn.lock .yarnrc.yml /var/www/

RUN yarn install --immutable

# On récupère le reste des fichiers
COPY . /var/www/

# Et enfin, on lance toutes les tasks nécessaires pour avoir l'application opérationnelle 
RUN composer dump-autoload --optimize \
    && yarn run build \
    && bin/console cache:warmup \
    && bin/console assets:install public --relative \
    && rm -rf node_modules
Plusieurs choses sont à noter ici. Déjà, vous remarquez que nous mentionnons un argument de build PROJECT_NAME pour préfixer le nom de l'image de base. Nous verrons dans le prochain article pourquoi c'est nécessaire. Dites vous dans un premier temps que la variable a comme valeur arsol, ce qui correspond au nom du projet Docker compose de la stack de dev en local.


    
                    
                
            
                        Info
    
    
                
J'ai voulu dissocier le Dockerfile de la stack de dev du Dockerfile de la stack de prod, d'où la nécessité de pouvoir référencer l'image de la stack de dev. Si nous avions mergé les deux Dockerfile, nous n'aurions pas eu besoin de cette variable PROJECT_NAME.
        


Ensuite, vous vous demandez peut-être la raison pour laquelle nous effectuons l'installation de Composer et Yarn avant de COPY le code et l'ensemble des fichiers de l'application. Cette approche permet de tirer parti du cache de couches : Docker commence la construction en vérifiant le cache pour la première instruction et, en cas de correspondance, il réutilise la couche et passe à l'instruction suivante. Mais si une instruction invalide le cache (par exemple, un COPY avec un fichier modifié), toutes les instructions suivantes seront exécutées sans utiliser le cache, ce qui ralentit la construction. Étant donné que les dépendances sont moins sujettes à changement que le code, il est plus probable que les étapes d'installation de Composer et Yarn soient réutilisées depuis le cache, car elles précèdent l'opération de COPY du code.
On peut maintenant préparer le stage docker qui contiendra uniquement php et les outils nécessaires pour le runtime (FrankenPHP, Caddy, etc), en se basant sur l'image du conteneur frontend :
ARG PROJECT_NAME
FROM ${PROJECT_NAME}-frontend AS production-php-base

WORKDIR /var/www

# Symfony tournera dans son env prod
ENV APP_ENV=prod

# On récupère le code de l'application, ses dépendances et assets depuis le stage builder vu précédemment
COPY --from=production-builder /var/www /var/www
Il faut bien faire attention à ce qui est inclus dans les conteneurs. C'est pour cette raison que nous allons créer un Dockerfile.gitignore au même niveau que le Dockerfile du projet. On retire tout ce qui n'est pas nécessaire, comme les dépendances ou les assets qui auraient été installées/construites dans votre stack de dev :
.castor/
.castor.stub.php
.env.local
.env.ci
*.cache
.git/
.idea/
.home/
.yarn/
doc/
infrastructure/
!infrastructure/docker/services/php-production/
tests/
tools/
node_modules/
var/
vendor/
public/assets/
public/build/
public/bundles/
public/media/
!public/media/.gitkeep



    
                    
                
            
                        Info
    
    
                
Après réflexion, on aurait peut-être mieux fait de tout bloquer par défaut et ne lister que ce qu'il fallait garder (src, config, public, etc). 😝
        


Frontend et worker
Maintenant que nous avons un stage avec l'application opérationnelle, nous allons pouvoir construire les images finales pour notre projet. Voilà l'image qui se base sur le stage construit ci-dessus :
FROM production-php-base AS production-frontend

# Mise en place d'un entrypoint qui s'occupera d'initialiser l'application
COPY infrastructure/docker/services/php-production/entrypoint-frontend.sh /entrypoint.sh

# Configuration de Caddy
COPY infrastructure/docker/services/php-production/etc/. /etc/

RUN ["chmod", "+x", "/entrypoint.sh"]
ENTRYPOINT ["/entrypoint.sh"]

# Indique les ports utilisés par ce conteneur 
EXPOSE 80
EXPOSE 443

# Commande qui sera exécutée dans le conteneur
CMD [ "frankenphp", "run", "--config", "/etc/caddy/Caddyfile", "--adapter", "caddyfile"]
Nous avons défini un entrypoint pour ce conteneur. Lors du démarrage de ce dernier, il permet d'initialiser toute la partie data (schéma SQL, migrations Doctrine à jouer, configuration du transport pour Messenger, indexation des données dans Meilisearch). Cela est rendu possible car nous n'aurons toujours qu'une seule instance de ce conteneur en production (aucun pic de trafic à gérer). Si ce n'est pas votre cas, il faudra peut-être adapter cette technique.
Voilà à quoi ressemble cet entrypoint :
#!/bin/bash
set -e

echo "Updating all databases..."

php bin/console doctrine:database:create --if-not-exists --env=prod --no-interaction
php bin/console doctrine:migrations:sync-metadata-storage --env=prod --no-interaction
php bin/console doctrine:migrations:migrate --env=prod --no-interaction
php bin/console messenger:setup-transports --env=prod --no-interaction
php bin/console app:meilisearch:index --env=prod

echo "Ready to start the frontend service."

exec "$@"
Enfin, il ne nous manque plus que le stage qui permettra de construire l'image faisant tourner le conteneur pour le worker Messenger :
FROM production-php-base AS production-worker-messenger

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        procps \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*

CMD ["php", "-d", "memory_limit=-1", "bin/console", "messenger:consume", "-vv", "async"]
Ici, on note l'installation de procps qui fournit le binaire pgrep, utile pour vérifier si le processus qui fait tourner le worker est toujours actif. Il sera employé dans le healthcheck de ce service :
services:
  worker-messenger:
    # ...
    healthcheck:
      test: ["CMD-SHELL", "pgrep -f \"messenger:consume\" || exit 1"]
      interval: 5s
      timeout: 5s
      retries: 5
Grâce au multi-stage de Docker, nous avons ainsi pu construire toutes nos images utilisant PHP dans un même Dockerfile.
A table !
Maintenant que nos images peuvent être construites, il va nous falloir les taguer puis les envoyer sur le registre. On pourrait lancer les mêmes commandes docker image tag|push vues précédemment. Mais à la place, on va simplifier et automatiser le processus grâce à Bake.
Cet outil permet de définir l'ensemble des cibles de build dans un fichier de configuration (bake.hcl par exemple) et de les construire/pousser en une seule commande. Voici un extrait de ce à quoi ressemble notre fichier bake :
group "default" {
  targets = [
    "frontend",
    "worker-messenger",
  ]
}

target "frontend" {
  context    = "."
  dockerfile = "./infrastructure/docker/services/php-production/Dockerfile"
  target     = "production-frontend"
}

target "worker-messenger" {
  context    = "."
  dockerfile = "./infrastructure/docker/services/php-production/Dockerfile"
  target     = "production-worker-messenger"
}
Avec ce fichier, il ne nous reste qu'à lancer la commande suivant pour construire les images, les tagger et les envoyer au registre docker :
docker buildx bake --file bake.hcl --push


    
                    
                
            
                        Info
    
    
                
Malheureusement, Bake n'a pas l'air de permettre de juste taguer des images existantes, donc nous ne pourrons pas l'utiliser pour remplacer les docker image tag|push des images publiques.
        


Nos images sont maintenant disponibles sur le registre du client :

Conclusion
Nous avons vu dans cet article une bonne partie des étapes qui nous permettent de construire les images Docker dont nous aurons besoin pour faire tourner l'application dans tous nos environnements.
Je n'en ai pas parlé jusque-là mais il reste quelques points de sécurité à garder en tête avant de mettre en production cette infrastructure (comme les capabilities Docker ou encore les logs générés par Docker Compose qui peuvent vite remplir le disque par défaut en cas de fort trafic).
Le client devant être autonome pour déployer les prochaines évolutions de l'application, nous ne nous sommes pas arrêtés là. Nous avons donc mis en place tout un ensemble de task Castor permettant d'automatiser la création et la publication des images, ainsi que de simplifier le pilotage de la stack dans les différents environnements. Mais nous verrons tout cela dans le prochain article.


Le signal d'alarme est tiré à l'AFUP
Plusieurs signaux nous alarment
Ce sont plusieurs sonnettes d’alarme qui ont déclenché une vague d’inquiétude au sein de l’équipe. Tout d’abord, depuis janvier, plusieurs de nos sponsors historiques nous ont annoncé l'impossibilité de débloquer des budgets cette année. Nous avons perdu 40% de nos financements pour l’AFUP Day 2026 par rapport à 2025. D'autres événements techniques annoncent également leurs difficultés.
Du côté des billetteries de l'AFUP Day 2026, elles affichent un retard de 50% par rapport à la même période en 2025. Et ce ne sont pas que les événements qui sont touchés ! Même la participation à l’enquête 2026 du baromètre des salaires PHP, un outil construit pour et par la communauté, accuse un net recul par rapport à la même période en 2025.
Quel impact pour l’AFUP ?
Le sponsoring et la billetterie sont nos seules sources de financement pour l’organisation de nos événements. Sans le soutien de l’écosystème, c’est l’existence même de nos événements sous le format que vous connaissez qui est en péril. Qu'est-ce que ça veut dire concrètement ? Soyons clairs : sans soutien significatif dans les prochaines semaines, nous serons contraints de revoir sérieusement le budget du Forum PHP 2026, en particulier les conditions d’accueil et la variété du programme.
Pourquoi nous aider ?
Nos conférences sont des parenthèses précieuses : celles où vous retrouvez vos pair·e·s, où vous progressez grâce à d'autres devs qui partagent la même passion. Celles où vous croisez un futur membre de votre équipe, où vous ressentez cet esprit communautaire bienveillant et convivial qui nous est si cher. Ne laissons pas disparaître ces occasions d'être ensemble, de s'émerveiller, d'échanger et de grandir collectivement. La diffusion des savoirs PHP, la valorisation de nos métiers, les espaces d'échange et de montée en compétences : tout cela repose sur votre engagement. 
Comment nous aider ?
L'AFUP, c'est une poignée de bénévoles passionné·e·s. Ce qui nous fait tenir ? Vous. La communauté. Le sens de ce qu'on construit ensemble. Sans cet écosystème, porté par les devs, les entreprises PHP, les partenaires, il n'y a plus d'AFUP.
Alors si vous pensiez prendre vos places pour l'AFUP Day 2026, inscrivez-vous maintenant ! Vous envisagiez de sponsoriser l'AFUP Day ou le Forum PHP ? Parlons-en aujourd'hui. Votre adhésion est à renouveler ? Faites-le ! Chaque action est importante, et nous montre votre soutien à l’association.
Merci à celles et ceux qui sont déjà là. Et à tous les autres qui vont se manifester : on compte sur vous. Pour que la diffusion des savoirs en PHP continue, et ce encore longtemps.


Installer et configurer Caddy 2 avec certificat SSL pour tous vos sous-domaines
Suite aux offres OVH VPS 2026 j'ai décidé de migrer mon vieux Digital Ocean toujours bloqué sur une debian 12.
J'aime héberger mes différents services en utilisant des containers et en mettant un reverse proxy devant.
Sur mon ancienne configuration j'utilisais Traefik, pour changer un peu j'ai décidé que c'était l'occasion de tester Caddy.
J'ai cherché un peu de doc afin de le configurer correctement (notamment la partie wildcard avec dns challenge) et je n'ai pas trouvé d'article récent parlant de ce sujet, du coup je vous partage mon expérience en espérant pouvoir vous aider :)
Attention, j'utilise la version Docker de Caddy, mais vous pouvez tout de même suivre cet article si vous l'avez installé directement sur votre système !
Prérequis :

Avoir installé Caddy version 2 (>2.10.0 pour ne pas avoir à ajouter l'option auto_https prefer_wildcard plus de détails ici) via Docker ou directement.
Au niveau de votre provider dns avoir déjà redirigé vos domaines sur votre serveur, cela inclut votre domain de base + le wildcard de votre domain, donc par exemple avoir un enregistrement du type *.example.com IN A 1.1.1.1 (où 1.1.1.1 correspond à l'ip de votre serveur) si vous utilisez ovh vous pouvez vous référer à cette doc

Trouver le bon plugin
La première étape est de trouver son provider DNS dans le repository suivant : https://github.com/caddy-dns
J'utilise personnellement ovh. Pour la suite de l'article ce sera donc : https://github.com/caddy-dns/ovh
Installer le plugin
Il faut maintenant ajouter le plugin à Caddy :
Installation direct : xcaddy build --with github.com/caddy-dns/ovh
Pour Docker on va créer un dossier par exemple dans notre home : mkdir -p ~/caddy/config (le dossier config vous sera utile juste après)
Ensuite créer un Dockerfile avec le contenu suivant dans notre dossier ~/caddy :
FROM caddy:builder AS builder

RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    xcaddy build \
    --with github.com/caddy-dns/ovh

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Préparer le Caddyfile
Exemple de Caddyfile à utiliser (pour une installation via Docker le placer dans le path suivant : ~/caddy/config/Caddyfile il sera utilisé par le compose.yaml plus tard) :
{
    debug
}

*.example.com, example.com {
    tls {
        dns ovh {
            endpoint {$OVH_ENDPOINT}
            application_key {$OVH_APPLICATION_KEY}
            application_secret {$OVH_APPLICATION_SECRET}
            consumer_key {$OVH_CONSUMER_KEY}
        }
    }
    # default handle
    handle {
      respond "it works !"
    }
}

(n'oubliez pas de remplacer example.com par votre nom de domaine)
Les variables d'environnement nécessaires à la configuration d'OVH seront renseignées dans les chapitres suivants.
Attention, ici j'ai pris l'exemple de configurations pour ovh, veillez à la remplacer par celle de votre provider que vous trouverez dans le README du repository https://github.com/caddy-dns de votre provider.
Trouver les identifiants du provider OVH
Afin de trouver les informations requises par Let's Encrypt pour communiquer et gérer nos enregistrements DNS OVH le README nous indique qu'il va falloir aller créer une application (avec accès API) à notre compte OVH.
La documentation Caddy nous redirige vers ce lien : https://github.com/libdns/ovh#authenticating
Qui ensuite nous mène ici : https://github.com/ovh/go-ovh#supported-apis
L'idée est de trouver quelle est notre OVH région afin de suivre le lien "Create script credentials (all keys at once)".
La mienne étant Europe, je vais donc suivre https://eu.api.ovh.com/createToken/
Authentifiez-vous à votre compte OVH et vous devriez arriver sur cette page :

Vous allez remplir le formulaire de la manière suivante :

Si vous avez un doute référez vous à la page que j'ai indiqué précédemment : https://github.com/libdns/ovh#authenticating . Je vous conseille de suivre la configuration pour un simple domaine, mais si vous avez vocation à laisser votre Caddy gérer plusieurs domaines différents, alors vous devriez suivre la configuration pour multiple domaines !
Une fois enregistré, n'oubliez pas de sauvegarder les informations suivantes (Attention, vous ne pourrez plus accéder à ces informations par la suite) :

application key
application secret
consumer key

Nous allons les utiliser dès maintenant !
Ajouter les identifiants du provider OVH
Si vous avez installé Caddy directement alors modifiez les info dans votre Caddyfile.
Si vous avez utilisé Docker je vous conseille de fournir ces infos via un compose.yaml :
services:
  caddy:
    build: .
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./conf:/etc/caddy
      - ./site:/srv
      - caddy_data:/data
      - caddy_config:/config
    environment:
      OVH_ENDPOINT: "ovh-eu"
      OVH_APPLICATION_KEY: "votre-application-key"
      OVH_APPLICATION_SECRET: "votre-application-secret"
      OVH_CONSUMER_KEY: "votre-consumer-key"

volumes:
  caddy_data:
  caddy_config:

Conclusion
Le moment de vérité est arrivé !
Relancez Caddy pour qu'il prenne en compte votre nouvelle configuration
Sans Docker :
sudo systemctl restart caddy
Avec Docker :
sudo docker compose up -d && sudo docker compose logs -f
Rendez-vous sur votre nom de domaine et vous devriez voir la phrase "it works !" ainsi qu'un certificat tls !
Si vous voulez tester un sous domain, rien de plus simple.
Ajoutez le bloc suivant à votre Caddyfile (en modifiant bien subdomain.example.com par votre nom de domaine et le sous domain désiré)
@subdomain host subdomain.example.com
handle @subdomain: {
  respond "subdomain works !"
}

Dans le bloc précédemment ajouté, entre le bloc tls et l'instruction handle
Relancez Caddy via les commandes suivantes :
Sans Docker :
sudo systemctl reload caddy
Avec Docker :
sudo docker compose exec -w /etc/caddy caddy caddy reload
Si vous avez une erreur sur le formattage de votre fichier Caddy vous pouvez utiliser la commande suivante :
sudo docker compose exec -w /etc/caddy caddy caddy fmt --override
Puis reload Caddy.
Et allez tester votre sous-domaine :)
Have fun !
Liens utiles

https://caddyserver.com/docs/automatic-https#wildcard-certificates
https://caddyserver.com/docs/caddyfile/patterns#wildcard-certificates
https://caddyserver.com/docs/automatic-https#dns-challenge
https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148
https://github.com/caddy-dns/ovh
https://github.com/libdns/ovh#authenticating
https://github.com/ovh/go-ovh#supported-apis



Les plannings de l'AFUP Day 2026 sont sortis
Les 4 plannings sont disponibles
Ce matin du 3 mars 2026 ont été publiés les déroulés du vendredi 22 mai à Bordeaux, Lille, Lyon et Paris. Découvrez comment s'enchaineront les conférences dans chaque ville, et ainsi prévoyez votre venue, que vous viviez à proximité de la salle ou que vous deviez réserver un train. Retrouvez les plannings de l'AFUP Day 2026 Bordeaux, de l'AFUP Day 2026 Lille, de l'AFUP Day 2026 Lyon et de l'AFUP Day 2026 Paris !
Prenez votre place et profitez du weekend de 3 jours.
Les 4 éditions ont dévoilé des programmes de qualité, techniques et variés, portés par des expert·e·s dans leur domaine : la communauté répond à l'appel ! L'édition parisienne est d'ailleurs déjà complète. Prenez vite vos places à Bordeaux, Lille et Lyon avant qu'il ne soit trop tard.
Pour info, l'AFUP Day 2026 est suivi du lundi de Pentecôte : l'occasion de prolonger votre séjour et de profiter d'un weekend de tourisme.
Pas de place pour l'édition parisienne ? Nous avons quelques tickets réservés pour nos sponsors, contactez-nous pour en savoir plus. Une liste d'attente est également disponible, au cas où des billets viendraient à se libérer.


L'enquête 2026 du baromètre des salaires en PHP 2026 est lancée !
Appel à toutes et tous : faites entendre votre voix
Développeuses et développeurs PHP, responsables d’équipe ou de projet, architectes, dirigeant·e·s, juniors comme seniors, salarié·e·s ou freelances, autodidactes ou issu·e·s de formation : votre expérience compte. Partagez des informations sur votre parcours, votre entreprise, votre quotidien professionnel et votre rémunération afin d’éclairer l’évolution des salaires et des conditions de travail dans un secteur aujourd’hui sous tension.
Dans un contexte où le marché de l'emploi des devs en France traverse une période agitée, recueillir des données fiables et actuelles est plus essentiel que jamais. L’édition 2025 avait déjà mobilisé 721 participant·e·s ; poursuivons cet effort collectif pour disposer d’un panorama précis et utile à toute la profession.
Comme chaque année, les résultats publiés en fin d’année offriront une photographie détaillée du secteur. Les devs pourront s’appuyer sur cette analyse pour valoriser leurs compétences, tandis que les entreprises disposeront d’un référentiel objectif pour mieux accompagner les carrières de leurs équipes.
Des repères solides et un focus renforcé sur l’IA générative
Les questions historiques qui ont fait la réputation du baromètre sont bien entendu reconduites : niveau de rémunération, satisfaction professionnelle, localisation et taille de l’entreprise, technologies utilisées, frameworks, versions de PHP, formation, management… Autant d’indicateurs essentiels pour suivre l’évolution du secteur dans la durée.
Mais fidèle à sa vocation d’observatoire des tendances, l’enquête 2026 approfondit également l’un des sujets majeurs du moment : l’intelligence artificielle générative. De nouvelles questions viennent compléter celles introduites l’an dernier afin de mieux comprendre ses usages concrets, son impact sur les pratiques de développement et la manière dont les équipes PHP s’en emparent.
À propos du baromètre des salaires en PHP
Chaque année, plusieurs centaines de professionnelles et professionnels contribuent anonymement à cette étude en quelques minutes. L’objectif est de recueillir un maximum de réponses d’ici au 2 juin 2026, date de clôture de l’enquête, afin d’établir un état des lieux précis qui bénéficiera à toute la communauté lors de sa publication en fin d’année , un rendez-vous devenu incontournable notamment à l’approche des entretiens annuels.
Répondez à l’enquête, anonymement et en quelques minutes, avant le 2 juin 2026 : votre participation est essentielle pour comprendre et défendre l’avenir de notre écosystème. Et si vous souhaitez mieux comprendre la situation actuelle du marché, consultez les résultats de l’édition 2025 pour situer votre profil et mesurer les évolutions récentes.


Rejoignez la communauté pour le Super Apéro PHP 2026
Notez la date : le Super Apéro PHP 2026 se tiendra le soir du mercredi 11 mars.  Dès 18h30, dans les antennes AFUP participantes, la communauté PHP est conviée à une soirée mêlant conférences courtes, discussions, rencontres et, bien sûr, un apéro convivial. Quel que soit le programme imaginé par votre antenne locale, attendez-vous à un moment bienveillant avec les devs de votre région : une belle occasion de se retrouver, d’échanger, d’apprendre et de célébrer ensemble le langage qui nous rassemble.
Découvrez ce que vous réservent les antennes AFUP participantes sur la page du Super Apéro PHP 2026 et inscrivez-vous sans tarder : certains lieux ont une capacité limitée !
Votre antenne AFUP n’a pas encore communiqué d’informations ? Pas d’inquiétude, certaines finalisent encore leur programme. Revenez consulter la page dans les prochains jours ! Et si votre antenne semble en sommeil depuis quelque temps, pourquoi ne pas saisir l’occasion pour la relancer ? Faites-nous signe si l’aventure vous tente.


Boring technology: les bases de données relationnelles
La semaine dernière, j’évoquais les « boring technologies » et le fait qu’elles soient sous-cotées dans l’esprit collectif. Les bases de données relationnelles et le langage SQL en sont probablement l’exemple le plus courant. Très largement utilisées dans les projets nécessitant de stocker des informations, elles sont pourtant régulièrement boudées par les développeurs au premier problème.




    Ce billet a été initialement publié sur LinkedIn

    Voir la publication originale

    Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.


C’est le constat que je fais depuis plusieurs années et la cause est que de moins en moins de développeurs en maîtrisent le fonctionnement ou ne connaissent réellement le langage SQL. Je ne pense pas que cela soit réellement dû à un manque d’intérêt, je pense surtout que les frameworks et les ORM que nous utilisons au quotidien ont leur part de responsabilité.

De nombreuses couches d’abstraction sont conçues de manière générique pour permettre d’interchanger rapidement et simplement le système relationnel. Cela se fait au détriment des fonctionnalités avancées, des optimisations spécifiques ou des mécanismes évolués permettant d’améliorer drastiquement les performances de nos applications (colonnes générées, gestion des vues, index partiels, CTE, requêtes récursives, partitionnement, …).

Cela ne se remarque pas à charge ou volumétrie réduite. Mais dès que l’on change un peu d’échelle, c’est là que les problèmes commencent. Les temps de réponse se dégradent, les performances chutent et si l’on ne s’intéresse pas à ce qu’il se passe sous le capot du SGBD, cela devient très compliqué de s’en sortir.

Les ORM ne sont pas le problème. Ce sont des outils très pratiques qui permettent de gagner du temps. Mais eux aussi, il convient de les maîtriser pour optimiser les requêtes générées et savoir comment tirer parti des fonctionnalités avancées des bases de données. La plupart d’entre eux ont des couches « bas niveau » et permettent généralement de faire des requêtes SQL directement et éventuellement de « mapper » la réponse dans des objets.

Comme je le dis régulièrement, il est essentiel, voire indispensable, de s’attacher aux fondamentaux, de comprendre et maîtriser les outils que l’on utilise. Le langage SQL et le fonctionnement des bases de données en font partie. C’est ainsi que l’on peut se donner les moyens de construire des applications qui tiennent la charge sur le long terme sans multiplier les technologies.



L'AFUP Day 2026 Paris annonce complet
Un événement très attendu par la communauté
La communauté parisienne a répondu à l'appel de l'AFUP Paris, elle qui attendait avec impatience le retour d'un cycle de conférences AFUP dans Paris intra-muros depuis que le Forum PHP s'est installé à Disneyland Paris. L'annonce du sold-out plus de 3 mois avant le jour J ne nous a donc pas surpris, mais elle déçoit certainement quelques devs qui espéraient bien rejoindre la communauté le vendredi 22 mai prochain. Que faire si vous n'avez pas eu de place ? 
Option 1 : l'inscription sur liste d'attente
Une liste d'attente est disponible. Indiquez vos nom, prénom et adresse email : si certaines places venaient à se libérer (par exemple, si une personne inscrite nous informe qu'elle ne pourra finalement pas être présente à l'événement), nous contacterons les personnes sur liste d'attente, dans l'ordre chronologique d'inscription. Et si cela peut sembler comme un coup de poker, il est fréquent que nous redistribuions des places par ce biais !
Option 2 : devenez sponsor de l'événement
Nous avons de côté un petit quota de places réservé aux sponsors de l'événement : si vous souhaitez soutenir l'AFUP Day 2026, sachez qu'il vous sera également possible de profiter de quelques billets en complément de votre sponsoring. Vous pourrez ainsi convier vos équipes à la journée de partage de connaissances que vous soutenez. Avec des offres de sponsoring démarrant à 900€HT pour les entreprises et 250€HT pour les devs et freelances, c'est une option qui peut se révéler intéressante ! Téléchargez le dossier de sponsoring et contactez-nous pour en savoir plus. 
Option 3 : nous rejoindre à Lille, Lyon et Bordeaux
Certes, le programme de l'édition parisienne est alléchant : mais avez-vous regardé ce qui vous attend le 22 mai à Lille, Lyon ou Bordeaux ? Ce sont des sélections tout aussi intéressantes et prestigieuses qui vous attendent. Et profitez-en pour passer un weekend de 3 jours dans l'une de ces villes, le lundi suivant étant ferié.
Bravo à l'équipe de l'AFUP Paris, qui prépare dans l'ombre ce rassemblement pour la communauté PHP, et rendez-vous le vendredi 22 mai à l'ESGI pour la communauté parisienne !


Simplifier vos objets immuables avec PHP 8.5
PHP 8.5 a été publié le 20 novembre 2025 et, dans les nouvelles fonctionnalités proposées par cette version, on trouve notamment la possibilité de mettre à jour des propriétés lors du clonage d’objets. Une amélioration qui va permettre de simplifier nos objets immuables.



En programmation orientée objet, un objet immuable est un objet dont l’état ne peut pas être modifié après sa création. Ainsi, toute “modification” visant à changer l’état de ce dernier conduit à la création d’une nouvelle instance avec les valeurs mises à jour. Cela représente un réel avantage, car leur état ne changeant jamais, les effets de bord et bugs liés à des modifications inattendues de l’objet sont ainsi limités.

Avant PHP 8.5, la modification d’un objet immuable pouvait s’avérer fastidieuse, car il était nécessaire de créer une nouvelle instance avec les nouvelles valeurs. Cela pouvait être d’autant plus contraignant si l’objet avait de nombreuses propriétés.

Par exemple:

readonly class GPSLocation
{
    public function __construct(
        public float $latitude,
        public float $longitude,
        public float $altitude,
        public DateTimeImmutable $timestamp,
    ) {
    }

    public function withCoordinates(float $latitude, float $longitude): GPSLocation
    {
        return new GPSLocation(
            $latitude,
            $longitude,
            $this->altitude,
            $this->timestamp,
        );
    }

    public function withAltitude(float $altitude): GPSLocation
    {
        return new GPSLocation(
            $this->latitude,
            $this->longitude,
            $altitude,
            $this->timestamp,
        );
    }
}

PHP 8.5 nous permet de simplifier cette opération en permettant de cloner l’objet tout en autorisant de mettre à jour certaines propriétés lors du clonage. Seules les propriétés devant être modifiées doivent être précisées:

readonly class GPSLocation
{
    public function __construct(
        public float $latitude,
        public float $longitude,
        public float $altitude,
        public DateTimeImmutable $timestamp,
    ) {
    }

    public function withCoordinates(float $latitude, float $longitude): GPSLocation
    {
        return clone($this, [
            'latitude' => $latitude,
            'longitude' => $longitude,
        ]);
    }

    public function withAltitude(float $altitude): GPSLocation
    {
        return clone($this, [
            'altitude' => $altitude,
        ]);
    }
}