Je n'avais aucune idée au début… 😅 Voici comment j'ai compris.

La configuration

J'avais un EventSubscriber qui vérifiait l'accès aux pages basé sur une liste blanche de routes. C'était du code legacy — le refactoriser n'était pas à l'ordre du jour à ce moment-là.

<?php

namespace App\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpKernel\KernelEvents;

class WhitelistRouteSubscriber implements EventSubscriberInterface
{
    private const WHITELISTED_ROUTES = [
        'app_login',
        'app_homepage',
        'app_healthcheck',
    ];

    public static function getSubscribedEvents(): array
    {
        return [
            KernelEvents::REQUEST => ['onKernelRequest', 0],
        ];
    }

    public function onKernelRequest(RequestEvent $event): void
    {
        $request = $event->getRequest();
        $route = $request->attributes->get('_route');

        // Allow whitelisted routes
        if (in_array($route, self::WHITELISTED_ROUTES, true)) {
            return;
        }

        // Deny access for non-whitelisted routes
        throw new AccessDeniedHttpException('Route not whitelisted');
    }
}

Objectif : Bloquer toutes les routes sauf la liste blanche. Simple, non ?

Le problème

Les logs montraient des AccessDeniedHttpException sur des routes que je savais être dans la liste blanche. Premier geste classique : mettre un dump() dans le subscriber pour voir ce qui arrivait.

public function onKernelRequest(RequestEvent $event): void
{
    $request = $event->getRequest();
    $route = $request->attributes->get('_route');

    dump($route); // 🔍 Voyons ce qui se passe
    // ...
}

Première découverte surprenante : le subscriber était appelé deux fois pour une seule requête. Le premier appel avait la route attendue, le second avait $route = null.

Question évidente : pourquoi _route est-il null ?

J'ai creusé plus loin avec dump($request->getPathInfo()) pour voir quelle URL était traitée lors du second appel :

// 1er appel
dump($request->getPathInfo()); // "/foo"

// 2e appel
dump($request->getPathInfo()); // "/foo" ← identique. Attends, quoi ?

Même URL, appelée deux fois. Cela n'avait aucun sens — si c'était la même requête, pourquoi _route était-il null la deuxième fois ? Je tournais en rond.

J'ai donc dumpé l'objet $event complet pour avoir plus de contexte, et j'ai réduit le champ à _controller dans les attributs de la requête :

dump($request->attributes->get('_controller'));
// "Symfony\Component\HttpKernel\Controller\ErrorController"

Voilà. _controller ne pointait pas vers mon code du tout. Symfony avait forgé une toute nouvelle requête vers son propre ErrorController, réutilisant l'URL d'origine — ce qui explique pourquoi getPathInfo() était si trompeur — mais en contournant complètement le routeur. C'est pourquoi _route était null.

Cause racine

Le flux réel était :

Requête → /foo
  └── WhitelistSubscriber (1er appel) → _route = 'app_foo' ✅ Accès accordé
      └── Controller → lève RealException 💥
          └── Symfony l'attrape
              └── Sous-requête → ErrorController (contourne le routeur, pas de _route)
                  └── WhitelistSubscriber (2e appel) → _route = null ❌ AccessDenied levé
                      └── RealException est maintenant silencieuse 🔇

Le piège : l'AccessDeniedHttpException du subscriber masquait complètement l'exception originale — celle qui contenait réellement les informations de débogage utiles.

Lorsqu'une exception est levée, le HttpKernel de Symfony distribue un événement KernelEvents::EXCEPTION, puis délègue le rendu de l'erreur à ErrorController via une sous-requête interne. Cette sous-requête réutilise l'URL d'origine — ce qui explique pourquoi getPathInfo() était trompeur — mais elle contourne complètement la couche de routage, laissant _route à null.

La solution

Vérifiez si la requête est la requête principale (pas une sous-requête) :

<?php

namespace App\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpKernel\KernelEvents;

class WhitelistRouteSubscriber implements EventSubscriberInterface
{
    private const WHITELISTED_ROUTES = [
        'app_login',
        'app_homepage',
        'app_healthcheck',
    ];

    public static function getSubscribedEvents(): array
    {
        return [
            KernelEvents::REQUEST => ['onKernelRequest', 0],
        ];
    }

    public function onKernelRequest(RequestEvent $event): void
    {
        // Skip sub-requests (like error handling)
        if (!$event->isMainRequest()) {
            return;
        }

        $request = $event->getRequest();
        $route = $request->attributes->get('_route');

        // Allow whitelisted routes
        if (in_array($route, self::WHITELISTED_ROUTES, true)) {
            return;
        }

        // Deny access for non-whitelisted routes
        throw new AccessDeniedHttpException('Route not whitelisted');
    }
}

isMainRequest() retourne false pour toute sous-requête interne — gestion d'erreurs, fragments ESI, hinclude — donc votre logique ne s'exécute que sur les vraies requêtes distribuées par le routeur.

Note : isMainRequest() a remplacé l'ancien isMasterRequest() dans Symfony 5.3. Si vous êtes sur une version plus ancienne, utilisez isMasterRequest() à la place.

Conclusion

Chaque fois que votre subscriber fait quelque chose de destructeur — lever une exception, rediriger, définir une réponse — demandez-vous : que se passe-t-il quand Symfony appelle ceci sur une sous-requête ?

Les sous-requêtes sont omniprésentes dans Symfony : gestion d'erreurs, ESI, fragments. Elles n'ont pas le même contexte qu'une requête principale, et votre subscriber ne connaît pas la différence à moins que vous ne lui disiez.

isMainRequest() est cette vérification. Faites-en un réflexe. 🎉

Table des matières :

Améliorez vos API Platform avec Go grâce à FrankenPHP (Kévin Dunglas)

Les slides de cette conférence sont disponibles : https://dunglas.dev/2025/09/the-best-of-both-worlds-go-powered-grpc-for-your-php-and-api-platform-apps/

API Platform fête ses 10 ans cette année, ayant été créé le 20 janvier 2015. À l'origine un bundle Symfony, il est désormais utilisable avec Laravel ou même sans framework. Avec plus de 14 000 étoiles sur GitHub et 921 contributeurs de code et de documentation, API Platform est devenu un outil essentiel pour la création d'API.

Kevin a souligné qu'il a également été le point de départ de nombreux projets connexes tels que Mercure et FrankenPHP, et que de nombreux composants Symfony ont d'abord été développés pour API Platform.

Il a également rendu hommage à Ryan Weaver, un contributeur clé, et a encouragé les participants à soutenir sa famille via le GoFundMe « In memory of Ryan Weaver: For his son Beckett ».

Un modèle, plusieurs architectures d'API

Avec API Platform, vous pouvez utiliser le même DTO, le même code et la même classe PHP pour générer différents formats de sortie avec seulement quelques changements de configuration.

Voici quelques-uns des formats pris en charge :

• Hydra
• OpenAPI
• HAL
• JSON:API
• GraphQL
• Mercure (support SSE)

Cette approche élimine la duplication de code entre les différents formats d'API.

Pourquoi gRPC est absent d'API Platform

Actuellement, gRPC n'est pas pris en charge par API Platform. Voici pourquoi :

• gRPC ne suit pas les principes REST.
• Il est différent de GraphQL.
• Il utilise Protobuf (un format binaire) au lieu de JSON pour le format de sortie.

La plupart du temps, dans l'architecture gRPC classique, PHP n'est pas un candidat.

Cependant, gRPC présente plusieurs avantages :

• Rapide et efficace
• Fortement typé
• Indépendant du langage : un générateur de code permet de générer des structures de données dans de nombreux langages.

Les cas d'utilisation de gRPC incluent :

• Microservices
• Internet des objets (IoT)
• Composants critiques où la performance est essentielle

Comment fonctionne gRPC

gRPC fonctionne sur HTTP/2 et utilise des fichiers .proto de Protocol Buffer pour définir les contrats de service. Ces définitions permettent la génération automatique de code dans plusieurs langages de programmation. Le format de sérialisation binaire offre une transmission de données plus efficace que JSON, tandis que le multiplexage d'HTTP/2 prend en charge les communications haute performance.

De plus, la documentation officielle de gRPC déconseille l'utilisation de PHP pour les serveurs gRPC en raison des limitations du cycle de vie des requêtes PHP-FPM.

gRPC avec FrankenPHP

Heureusement, FrankenPHP offre un moyen d'écrire des extensions en Go qui peuvent être exposées en PHP, rendant ainsi possible l'utilisation de gRPC avec API Platform. L'extension gRPC de FrankenPHP est disponible sur GitHub et est testable. Elle utilise le serveur gRPC Go et est conçue pour être utilisée avec ou sans API Platform.

Pour plus d'informations sur la configuration et l'utilisation de cette extension, veuillez vous référer à la documentation du dépôt GitHub.

Les tests peuvent être effectués avec gRPCui. Il est important de noter que cette solution est encore expérimentale.

Étendre le serveur Web Caddy avec votre langage préféré (Sylvain Combraque)

Caddy est un serveur Web moderne, rapide et facile à utiliser qui simplifie le processus de服务 des sites Web et des applications Web. Il est connu pour sa configuration HTTPS automatique et sa syntaxe simple. Matt Holt, le créateur de Caddy, a apporté des contributions significatives au paysage des serveurs Web avec les fonctionnalités uniques et la facilité d'utilisation de Caddy.

Étendre Caddy

Avec la construction xcaddy

L'extension de Caddy peut être réalisée à l'aide de l'outil de construction xcaddy, qui permet de personnaliser et d'étendre Caddy avec des plugins écrits en Go. Cet outil offre un moyen simple d'ajouter de nouvelles fonctionnalités à Caddy.

Avec l'interface Web du site Caddy

Caddy propose également une interface Web accessible depuis le site Web de Caddy. Cette interface offre un moyen simple de gérer et de configurer votre serveur Web Caddy.

Étendre Caddy avec Go

Pour des informations plus détaillées sur la façon d'étendre Caddy avec Go, vous pouvez consulter la documentation officielle.

Utilisation d'un interpréteur

L'utilisation d'interpréteurs pour étendre Caddy présente des avantages, mais aussi quelques inconvénients :

• Vous avez besoin d'un interpréteur par langage.
• Les nouvelles versions du langage nécessitent de nouveaux interpréteurs.
• Chaque interpréteur est maintenu séparément.
• Vous devrez peut-être réimplémenter des types.

WASM x WASI x darkweak/wazemmes pour une extension Caddy dans n'importe quel langage

WebAssembly (WASM) est un format d'instruction binaire qui promet de permettre aux programmes de s'exécuter à une vitesse proche du natif sur le Web. La promesse de « construire une fois, exécuter partout » fait de WASM une option attrayante pour étendre Caddy. Cependant, la documentation actuelle n'est pas conviviale et il existe quelques bogues à connaître.

WebAssembly System Interface (WASI) est une interface système conçue pour permettre aux modules WebAssembly d'interagir avec le système d'exploitation de manière sécurisée et portable. Cette combinaison de WASM et WASI permet aux développeurs d'écrire du code dans leur langage préféré et de le compiler en WASM pour une exécution dans un navigateur ou un environnement serveur.

Pour plus d'informations sur l'utilisation de WASM et WASI dans Caddy, vous pouvez consulter le dépôt darkweak/wazemmes sur GitHub.

Mercure, SSE, API Platform et un LLM pour améliorer un Chat(bot) (Mathieu Santostefano)

Les slides de cette conférence sont disponibles : https://welcomattic.github.io/slides-real-time-ai-chatbot-with-mercure/1

Origine du sujet

Le besoin initial du client était de créer des échanges de chat experts payants. La première version utilisait une API + React, mais manquait d'historique des messages. Mercure a été choisi pour la distribution sécurisée des messages aux clients via JWT.

Évolution des besoins :

• Assister les experts avec un assistant IA
• Permettre à l'IA de gérer la première partie de la conversation
• Permettre aux experts de prendre le relais si nécessaire

Boîte à outils

Mercure - Échanges en temps réel

Architecture :

• Serveur => Hub => Client
• Client => Hub => Client

SSE

Les Server-Sent Events (SSE) sont une technologie qui permet à un serveur d'envoyer des mises à jour en temps réel à un client via une connexion HTTP persistante. Le client écoute un flux d'événements envoyés par le serveur.

API Platform

LLM

Génération de données et réponses intelligentes

Symfony Messenger

Gestion des processus asynchrones

Symfony AI

Équivalent de Mailer/Notifier mais pour les fournisseurs d'IA :

• Platform : interface unifiée pour tous les fournisseurs d'IA
• Agent : création d'IA agentique
• Store : abstraction de stockage de données
• MCP SDK : désormais officiellement pris en charge par Anthropic
• AI Bundle : intégration complète avec Symfony
• MCP Bundle : composants supplémentaires

Implémentation

Flux technique : Utilisateur => message => Mercure (Stockage) <= Client SSE Symfony => Symfony Messenger => Mistral => Mercure => réponse IA => Utilisateur

Chat privé sécurisé via JWT (JSON Web Tokens) - une norme ouverte pour échanger des données en toute sécurité entre les parties.

Envoyer un message à Mercure

fetch(this.hubURL, {
    method: 'POST',
    credentials: 'include', // Send JWT cookie
    body: new URLSearchParams({
        topic: topic,
        data: JSON.stringify(
            new MercureUpdateData(
                conversationId,
                msg,
            ),
        ),
        private: 'on' // restrict message to subscribed clients
    })
});

Se connecter à Mercure

const eventSource = new EventSource('/sse-endpoint');
eventSource.onmessage = (event) => {
  console.log('New event received: ', event.data);
};

Client SSE Symfony

EventSourceHttpClient intégré :

use Symfony\Component\HttpClient\Chunk\ServerSentEvent;
use Symfony\Component\HttpClient\EventSourceHttpClient;
use Symfony\Component\HttpClient\HttpClient;

$eventSourceClient = new EventSourceHttpClient(HttpClient::create());

$connection = $eventSourceClient->connect("YOUR-MERCURE-URL");

while (true) {
    foreach ($eventSourceClient->stream($connection, 2) as $r => $chunk) {
        if ($chunk->isTimeout()) continue; // Keep the connection alive.
        if ($chunk->isLast()) return; // Connection closed by server.
        if ($chunk instanceof ServerSentEvent) $this->processSSE($chunk);
    }
}

Distribuer les messages avec Messenger

use Symfony\Component\HttpClient\Chunk\ServerSentEvent;

function processSSE(ServerSentEvent $event): void
{
    $data = $event->getArrayData();

    // do some checks before asking LLM
    if (!$this->shouldProcessWithAi($data)) {
        return;
    }

    // Dispacth message to ask LLM
    $this->messageBus->dispatch(
        new ProcessAiResponseMessage(
            conversationId: $data['conversationId'],
            userMessage: $data['message'],
            sseMessageId: $event->getId(),
            timestamp: $data['timestamp']
        ),
    );
}

Configuration Symfony AI

Configuration YAML du bundle AI avec Mistral

ai:
    platform:
        mistral:
            api_key: '%env(MISTRAL_API_KEY)%'

    agent:
        default:
            platform: 'symfony_ai.platform.mistral'
            model:
                class: 'Symfony\AI\Platform\Bridge\Mistral\Mistral'
                name: !php/const Symfony\AI\Platform\Bridge\Mistral\Mistral::MISTRAL_LARGE

Exemple de Handler

// Symfony AI Bundle code example
use Symfony\AI\Agent\AgentInterface;
use Symfony\AI\Agent\Chat;
use Symfony\AI\Platform\Message\Message;
use Symfony\AI\Platform\Message\MessageBag;
use Symfony\AI\Store\StoreInterface;

class MessageHandler
{
    public function __construct(
        private readonly AgentInterface $agent,
        private readonly StoreInterface $messageStore,
    ) {
    }

    public function __invoke(ProcessAiResponseMessage $message)
    {
        $chat = new Chat($this->agent, $this->messageStore, "UNIQUE_ID_TO_PROMPT");
        $messages = $this->messageStore->load("UNIQUE_ID_TO_PROMPT");

        if ($messages->count() === 0) {
            // retrieve system prompt from somewhere ...

            // Programmatic System prompt injection
            $chat->initiate(new MessageBag(
                Message::forSystem("SYSTEM_PROMPT_INJECTION"),
            ));
        }

        $llmAnswer = $chat->submit(Message::ofUser($message->userMessage));

        // do something with the answer
    }
}

Dans ses mots de la fin, Mathieu a dédié sa conférence à la mémoire de Ryan Weaver, dont les contributions continuent d'inspirer la communauté Symfony. Il a également remercié Christopher Hertel pour l'initiative Symfony AI.

Comment API Platform 4.2 redéfinit le développement d'API (Antoine Bluchet)

Les slides de cette conférence sont disponibles : https://soyuka.me/api-platform-4-2-redefining-api-development/

Retour sur la version 4.0 :

• 610 commits
• ~200 000 lignes de code
• 291 issues ouvertes
• 230 issues fermées

Quoi de neuf dans la 4.2

Fonctionnalités clés de cette version :

• Intégration FrankenPHP
• State Options
• Améliorations des paramètres de requête
• Améliorations des performances
• Compatibilité Laravel
• Métadonnées par fichiers PHP

Améliorations des métadonnées

Métadonnées depuis les fichiers PHP

Nouveau système de métadonnées permettant d'extraire la configuration API directement depuis les fichiers PHP. Ce n'est pas encore documenté (à ma connaissance) mais vous pouvez voir la PR associée de Loïc Frémont https://github.com/api-platform/core/pull/7017.

Metadata Mutator

Une nouvelle façon de modifier les métadonnées par programmation :

• Configuration plus flexible
• Ajustements à l'exécution
• Architecture plus propre

Du filtre API aux paramètres

Rétrospective sur ApiFilter

L'attribut #[ApiFilter] faisait beaucoup de choses en arrière-plan, telles que :

• Déclarer des services avec des tags de filtre
• Générer la documentation
• Appliquer des opérations sur la base de données
• Fonctionner avec plusieurs propriétés

C'était déroutant et ne respectait pas le principe de responsabilité unique. C'est pourquoi les mainteneurs d'API Platform ont décidé de retravailler cela en paramètres.

Améliorations de la documentation des filtres

Désormais, les documentations sont générées séparément. Cela peut être fait avec deux nouvelles interfaces :

• JsonSchemaFilterInterface
• OpenApiParameterFilter

Système de filtrage

Maintenant, les filtres sont indépendants via une nouvelle FilterInterface avec :

• Méthode apply() simplifiée
• Aucune exigence de constructeur
• Conception sans dépendance

Système de paramètres

L'attribut #[ApiFilter] laissera sa place à une nouvelle propriété des attributs d'opérations appelée parameters.

Nouveaux types de filtres

• Capacités de recherche en texte libre
• Fournisseur de variables URI

Améliorations du JSON Schema

Quelques améliorations ont été apportées à la génération du JSON Schema. Ces changements pourraient impliquer une rupture de compatibilité ascendante pour les outils utilisant l'ancien JSON Schema.

Améliorations :

• Mutualisation des schémas
• Fichiers de spécification OpenAPI 30% plus petits
• Opérations I/O réduites

Un nouvel outil est désormais recommandé : pb33f.io car il est plus riche en fonctionnalités et mieux maintenu que Swagger UI.

Performances

Benchmarks de performance comparant Nginx et FrankenPHP :

Plus de benchmarks disponibles sur soyuka.github.io/sylius-benchmarks/

Améliorations du JSON Streamer :

• ~32,4% de meilleure performance en requêtes/seconde
• Configurable via les paramètres

State Options

Nouvelles fonctionnalités pour l'interrogation des sous-ressources :

• Chargement de données plus efficace
• Entity class magic (RIP Ryan)

Data Mapping

Nouvelles capacités de mapping :

• Mapping de la base de données vers la représentation API
• Intégration Symfony ObjectMapper
• Meilleure transformation des données

Débogage

Les outils de profilage sont de retour !

Rétrocompatibilité

• De nombreuses nouvelles fonctionnalités ajoutées
• Aucune dépréciation dans cette version
• Le système de paramètres n'est plus expérimental

Perspectives pour API Platform 5.0

Changements prévus :

• Dépréciation de #[ApiFilter] (script de migration à venir)
• Utilisation accrue du JSON Streamer
• Demandes de fonctionnalités pour Object Mapper
• Améliorations pilotées par la communauté

Design pattern, le trésor est dans le vendor (Smaïne Milianni)

Les slides de cette conférence sont disponibles : https://ismail1432.github.io/conferences/2025/apip_con/index.html

Dans cette conférence, Smaïne a fait un tour des design patterns qui sont couramment utilisés sans que l'on sache qu'ils se trouvent dans les vendors que nous utilisons quotidiennement. Il a également présenté des extraits de code PHP petits et compréhensibles expliquant certains d'entre eux.

Parmi eux, on trouvait :

• Le Pattern Strategy
• Le Pattern Adapter
• Le Pattern Factory
• Le Pattern Builder
• Le Pattern Proxy
• Le Pattern Observer
• Le Pattern Event Dispatcher
• Le Pattern Decorator
• Le Pattern Facade
• Le Pattern Template
• Le Pattern Chain of Responsibility

Smaïne a également terminé par un clin d'œil à Ryan Weaver.

Et si on faisait de l'Event Storming dans nos projets API Platform ? (Gregory Planchat)

Event Storming

L'Event Storming est une technique d'atelier collaboratif qui réunit à la fois les utilisateurs et les développeurs dans la même pièce. Cette méthodologie met en lumière les incompréhensions qui existent souvent entre les parties prenantes métier et les équipes techniques.

La beauté de l'Event Storming réside dans sa simplicité : il utilise des post-it physiques pour encourager les différents membres de l'équipe à échanger des idées, se voir, partager leurs connaissances, se rencontrer en personne et confronter leur compréhension du domaine métier.

Préparation

Le processus d'Event Storming suit une approche structurée avec plusieurs étapes clés :

1. Lister les événements - Commencez par identifier tous les événements significatifs qui se produisent dans votre domaine métier
2. Organiser les événements - Disposez ces événements dans un ordre chronologique ou logique
3. Établir les commandes - Identifiez les actions qui déclenchent chaque événement
4. Identifier les acteurs - Déterminez qui ou quoi initie chaque commande
5. Post-it verts - Ajoutez les données nécessaires aux utilisateurs pour prendre des décisions
6. Ajouter les systèmes externes - Incluez les systèmes tiers qui interagissent avec votre domaine
7. Agrégats - Regroupez les événements et commandes connexes en concepts métier cohérents

L'équipe a mentionné avoir mené plusieurs sessions « jusqu'à ce que plus personne n'ait de questions, que ce soit de la part de l'équipe technique ou de l'équipe métier ». C'est un processus auto-documenté qui peut être répété à mesure que le métier évolue.

Avantages

L'Event Storming apporte plusieurs bénéfices concrets aux équipes de développement :

• Documentation des processus - L'atelier crée naturellement une documentation vivante de vos processus métier
• Intégration facilitée - Les nouveaux membres de l'équipe peuvent rapidement comprendre le domaine en regardant les artefacts de l'Event Storming
• Révélation des incertitudes - Les hypothèses cachées et les exigences floues émergent pendant les sessions collaboratives

Avec API Platform

Le problème du modèle anémique

La plupart des applications souffrent de ce qu'on appelle l'anti-patron du modèle anémique, où :

• La logique métier est dispersée dans de nombreux services
• Perte du suivi de l'intention de l'utilisateur
• Les entités deviennent de simples conteneurs de données avec des getters et setters

Typiquement, lorsque vous souhaitez modifier des informations dans votre entité, vous appelez une méthode setter. Cela se produit souvent dans plusieurs services et classes, d'où le problème de « logique métier disséminée dans de nombreux services ».

L'intention est essentielle pour que les systèmes tiers comprennent ce qui s'est réellement passé dans votre application.

Modèles riches

L'approche alternative utilise des modèles de domaine riches qui :

• Nécessitent un coût important - Plus complexes à implémenter initialement
• Nécessitent une compréhension détaillée de l'application - L'équipe a besoin d'une connaissance approfondie du domaine
• Garantissent la cohérence dans le temps - Les règles métier sont appliquées au niveau du modèle
• Appliquent les contraintes métier - La logique de validation vit là où elle doit être
• Centralisent la logique métier - Tout ce qui concerne un concept vit dans une ou deux classes
• Le modèle garantit l'intégrité - Les états invalides deviennent impossibles

Avec un modèle riche, toutes les modifications se produisent dans l'entité elle-même, gardant la logique métier centralisée et cohérente.

Le problème du CRUD

Les opérations CRUD traditionnelles sont :

• Limitées à 4 opérations (Create, Read, Update, Delete)
• Centrées sur la pensée SQL
• Des outils comme PostgREST génèrent des API REST automatiquement mais apportent peu de valeur métier

Pour faire mieux, nous pouvons tirer parti de la puissance des State Providers et State Processors d'API Platform.

Mais comment préserver l'intention dans notre application ?

La solution suit ce flux : Repository → EventBus → Event → Handler

Modification du modèle

L'équipe a implémenté un modèle avec trois méthodes clés dans leurs entités :

• recordThat() - Enregistre qu'un événement s'est produit (par exemple, « un déploiement a été lancé »)
• apply() - Applique les modifications liées à l'événement (par exemple, met à jour la date de déploiement)
• releaseEvents() - Une étape de nettoyage qui se produit pendant le processus de sauvegarde, juste avant le persist/flush, puis distribue les événements dans l'application

Cette approche garantit que chaque action métier est capturée comme un événement significatif, préservant l'intention de l'utilisateur et fournissant une piste d'audit claire de ce qui s'est passé dans le système.

Résultats

L'équipe a rapporté plusieurs améliorations concrètes après avoir implémenté cette approche :

• Une API et une base de code qui ressemblent davantage au domaine métier de l'entreprise
• L'intention de l'utilisateur a été préservée tout au long du cycle de vie de l'application
• Meilleure compréhension des actions effectuées dans l'application, à la fois pour les développeurs et les parties prenantes métier

Passage à l'échelle des bases de données (Tobias Petry)

Tobias Petry a partagé des informations sur les stratégies de passage à l'échelle des bases de données. Sa conférence a souligné pourquoi les problèmes de scalabilité proviennent généralement du niveau de la base de données et a passé en revue les solutions les plus courantes, leurs avantages et leurs pièges.

Solutions

Il n'y a pas de solution miracle : chaque application a ses propres contraintes. Néanmoins, plusieurs stratégies bien connues existent :

• Trouver et corriger les requêtes lentes Avant d'envisager l'infrastructure, vérifiez toujours les bases. Des outils comme mysqlexplain.com peuvent aider à détecter les requêtes inefficaces et suggérer des améliorations.

• Mettre en cache les résultats Servir des réponses mises en cache réduit considérablement la charge sur la base de données et évite de répéter des opérations coûteuses.

• Scaling vertical (machines plus puissantes) Parfois, l'option la plus simple est d'augmenter la puissance : déplacer la base de données vers un serveur plus performant. Cependant, cette approche atteint rapidement des limites physiques et financières.

• Réplication multi-maître Dans cette configuration, plusieurs serveurs acceptent à la fois les lectures et les écritures. Cela améliore la scalabilité des écritures mais crée un risque de conflits lors d'écritures parallèles. Des stratégies de résolution de conflits peuvent atténuer ce problème, mais la complexité augmente avec le nombre de nœuds.

• Réplication en lecture Ici, un nœud principal unique gère les écritures, tandis que les réplicas servent les requêtes de lecture.

  • La réplication synchrone garantit que les modifications sont propagées à tous les réplicas avant d'accuser réception de l'écriture. Cela garantit la cohérence mais ajoute de la latence, car chaque réplica doit confirmer.
  • La réplication asynchrone accuse réception de l'écriture immédiatement et met à jour les réplicas plus tard. Cela réduit la latence mais risque une incohérence temporaire entre les nœuds. En pratique, la plupart des applications tolèrent la cohérence éventuelle. Une couche de cache devant le primaire masque souvent le retard de réplication. Néanmoins, des études montrent que 90 à 98 % des applications rencontrent des problèmes de latence si elles ne comptent que sur les réplicas pour les lectures.

• Sharding Le sharding distribue les données sur plusieurs bases de données. Cela permet une scalabilité théoriquement infinie. Par exemple, les utilisateurs peuvent être répartis entre différents shards en fonction de leur ID. Le défi vient des requêtes cross-shard : si vous devez récupérer toutes les commandes d'un utilisateur dans plusieurs boutiques, et que les utilisateurs et les boutiques sont shardés différemment, vous devez interroger plusieurs shards et agréger les résultats manuellement. Certaines entreprises introduisent même des shards de shards, ajoutant une couche supplémentaire de complexité. En raison de cette complexité, le sharding est généralement réservé aux systèmes à très grande échelle. Pour la plupart des cas d'utilisation, la réplication en lecture est suffisante.

En général, ces stratégies sont conçues pour les workloads CRUD. Les requêtes analytiques (tableaux de bord, rapports) sont plus difficiles à scaler avec une base de données relationnelle standard. Les développeurs peuvent explorer des ressources comme sqlfordevs.com (cours gratuit pour accélérer l'analytique) ou des systèmes spécialisés comme TimescaleDB.

Ça semble compliqué

Tobias a souligné un point crucial : les décisions de mise à l'échelle doivent être prises avant d'atteindre les goulots d'étranglement de la base de données. Une fois les données structurées et les stratégies de scaling en place, revenir en arrière devient presque impossible. L'architecture de base de données est l'un de ces domaines où il est bien plus facile de prendre la bonne décision tôt que de corriger les erreurs plus tard.

API Platform, JsonStreamer et ESA pour des API fulgurantes (Mathias Arlaud)

Les slides de cette conférence sont disponibles : https://www.canva.com/design/DAGyYPxkygw/M1RzOiv8_cMp0Pa7Mh0u4g/view

Histoire : imaginez une librairie. Un client commande tous les livres liés à Symfony. Le libraire essaie de tous les rassembler, mais c'est lourd — ça prend du temps, beaucoup de livres. La deuxième fois, même demande, mais la pile est si grande que le libraire s'effondre sous le poids.

Dans le monde des API, JSON est roi.

Au cœur de notre stack se trouve API Platform, qui repose sur le Serializer de Symfony. Mais parfois, le Serializer est comme ce libraire : il fonctionne bien jusqu'à ce que la charge devienne trop lourde.

Sérialisation / Normalisation dans Symfony

La sérialisation dans Symfony (et dans API Platform) consiste à transformer des objets PHP en tableaux ou valeurs scalaires, puis à les encoder dans des formats comme JSON ou XML. La normalisation transforme le graphe d'objets interne en une structure de données neutre (tableaux, scalaires), en appliquant des métadonnées comme les groupes ou les attributs. L'encodage convertit ensuite cette structure en la chaîne JSON finale. Le processus inverse (dénormalisation) gère l'entrée JSON → tableaux → objets.

Quand les objets ou les collections sont petits, cela fonctionne bien. Mais avec des milliers d'éléments, de grands graphes, des associations profondes et des tableaux imbriqués, l'utilisation mémoire et le temps jusqu'au premier octet se dégradent. La sérialisation devient un goulot d'étranglement.

Le streaming comme solution

Au lieu de construire une énorme structure en mémoire, le streaming émet les morceaux JSON progressivement. Vous ne gardez en mémoire que ce qui est nécessaire à chaque instant.

Symfony 7.3 introduit le composant JsonStreamer à cet effet.

Quelques fonctionnalités clés :

• Fonctionne mieux avec les POPOs (Plain Old PHP Objects) ayant des propriétés publiques, sans constructeurs complexes.
• L'attribut #[JsonStreamable] peut être utilisé sur les classes pour les marquer comme streamables. Cela permet également la pré-génération de code pendant le warm-up du cache.
• Utilisez le composant TypeInfo (lien) pour décrire les types des collections et des objets (par exemple, Type::list(Type::object(MyDto::class))). Cela aide JsonStreamer à deviner la forme du JSON de sortie sans tout charger en mémoire.

Voici un extrait de code de la documentation Symfony montrant l'utilisation de base :

// Example class
namespace App\Dto;

use Symfony\Component\JsonStreamer\Attribute\JsonStreamable;

#[JsonStreamable]
class User
{
    public string $name;
    public int $age;
    public string $email;
}

// In controller
use Symfony\Component\JsonStreamer\StreamWriterInterface;
use Symfony\Component\TypeInfo\Type;
use Symfony\Component\HttpFoundation\StreamedResponse;

public function retrieveUsers(StreamWriterInterface $jsonStreamWriter, UserRepository $userRepository): StreamedResponse
{
    $users = $userRepository->findAll();
    $type = Type::list(Type::object(User::class));
    $json = $jsonStreamWriter->write($users, $type);
    return new StreamedResponse($json);
}

Benchmarks et comparaisons

Pour un jeu de données de 10 000 objets :

Défis avec les métadonnées, JSON-LD et comment API Platform s'adapte

API Platform ajoute des métadonnées, des contextes JSON-LD, des métadonnées de propriétés, etc. Cela ajoute de la surcharge à la sérialisation. Pour intégrer JsonStreamer tout en préservant les métadonnées riches :

Ils utilisent les points d'extension PropertyMetadataLoader pour fournir des métadonnées à JsonStreamer. Cela permet à JsonStreamer de connaître les noms des propriétés, si elles sont exposées, etc., sans parcourir l'arbre d'objets complet en mémoire.

API Platform

Utilisation de ValueTransformers qui peuvent transformer n'importe quelle valeur à l'exécution. Mais attention : une logique lourde dans les transformers peut dégrader les performances (ils s'exécutent par valeur).

Symfony +1

Utilisation d'ObjectMapper pour convertir les entités (par exemple, les objets Doctrine) en POPOs (DTOs) adaptés au streaming. Cela aide car les entités ont souvent des propriétés paresseuses, des proxies, des relations, etc., qui compliquent le streaming.

ESA (Edge Side APIs)

Les Edge Side APIs consistent à diviser de grandes charges utiles JSON en appels ou morceaux progressifs plus petits, souvent délivrés depuis la périphérie / le CDN pour améliorer les performances perçues, en particulier dans les réseaux à latence élevée/lente. Dans le contexte de cette conférence :

Au lieu d'envoyer une seule énorme structure JSON, partitionnez ou paginez pour que le client puisse commencer à recevoir des données rapidement.

Combinez avec le streaming pour que des parties de la réponse commencent à être livrées tôt (le TTFB s'améliore).

Bonne expérience utilisateur : l'utilisateur voit quelque chose rapidement plutôt que d'attendre le chargement complet.

Points à retenir

Le Serializer fonctionne, mais pour les grands ensembles de données, il devient inefficace.

JsonStreamer apporte des améliorations significatives à la fois en utilisation mémoire et en temps jusqu'au premier octet.

Lorsque vous avez des couches de métadonnées (API Platform, JSON-LD), utilisez les points d'extension fournis pour brancher le streaming sans perdre de fonctionnalités.

Évitez les calculs/transformations lourds dans les chemins chauds à l'exécution (par exemple, ValueTransformers).

Concevez votre API en connaissant ces options tôt, car une fois que le chemin de sérialisation principal est profondément intégré, le changer est difficile.

Benchmarks et comparaisons

Pour un jeu de données de 10 000 objets :

Défis avec les métadonnées, JSON-LD et comment API Platform s'adapte

API Platform ajoute des métadonnées, des contextes JSON-LD et des métadonnées de propriétés. Cette surcharge alourdit la sérialisation. Pour intégrer JsonStreamer tout en conservant ces fonctionnalités :

• Utilisez les points d'extension PropertyMetadataLoader pour fournir des métadonnées à JsonStreamer. Cela lui indique quelles propriétés exposer, sans parcourir l'arbre d'objets complet.
• Utilisez les ValueTransformers pour ajuster les valeurs à l'exécution. Mais attention : une logique lourde ici dégradera les performances, car les transformers s'exécutent pour chaque valeur.
• Utilisez ObjectMapper pour convertir les entités (par exemple, les objets Doctrine) en POPOs (DTOs) plus faciles à streamer.

Le pattern ESA (Edge Side APIs)

Les Edge Side APIs (ESA) consistent à diviser de grandes charges utiles JSON en morceaux progressifs plus petits, souvent délivrés depuis la périphérie ou un CDN pour améliorer les performances perçues, en particulier dans les réseaux à latence élevée ou lente.

En pratique :

• Au lieu d'envoyer une seule énorme structure JSON, partitionnez ou paginez pour que le client commence à recevoir les données plus tôt.
• Combinez avec le streaming pour que des parties de la réponse arrivent progressivement, améliorant le temps jusqu'au premier octet.
• L'expérience utilisateur est meilleure : les données apparaissent rapidement au lieu d'attendre que tout soit chargé.

Points à retenir

• Le Serializer de Symfony est satisfaisant pour les ensembles de données petits à moyens.
• JsonStreamer offre des améliorations significatives en utilisation mémoire et en TTFB.
• API Platform l'intègre via des points d'extension (PropertyMetadataLoader, ValueTransformers, ObjectMapper).
• Évitez les transformations lourdes à l'exécution pour de meilleures performances.
• Concevez votre API avec ces options à l'esprit dès le début — les décisions de sérialisation sont très difficiles à modifier par la suite.

Crédits

Image de couverture par Nicolas Detrez

Table des matières :

Comment les LLM changent la façon de construire des API (Fabien Potencier)

Les slides de cette conférence sont disponibles : https://speakerdeck.com/fabpot/how-ai-agents-are-changing-the-way-we-should-build-apis

Fabien Potencier a partagé des informations sur la façon dont les grands modèles de langage sont en train de changer fondamentalement la façon dont nous devons concevoir les API. Comme il l'a mentionné, c'est un monde qui change si vite que certaines affirmations pourraient déjà être obsolètes.

Les agents ?

Les LLM évoluent au-delà de la simple génération de texte pour devenir des agents autonomes. Selon la définition d'Anthropic, un agent est un LLM qui utilise des outils dans une boucle. Ces LLM sont auto-dirigés — ils peuvent raisonner sur les choses, ils peuvent planifier et ont une mémoire.

Un agent IA est en quelque sorte un mélange entre une machine et un humain, combinant la puissance de calcul des machines avec des capacités de raisonnement de type humain.

Qui peut consommer votre application ?

À l'époque, les consommateurs étaient clairement définis :

Site Web :

• Utilisateurs humains uniquement

Outils CLI :

• Réservés aux développeurs

API :

• Uniquement pour les machines
• Semi-privée (pour découpler le frontend) ou publique

De nos jours, les API sont principalement utilisées pour exposer des données, mais les agents IA ont complètement changé la donne. Ils sont capables d'interagir avec les trois interfaces :

• Les sites Web peuvent être scrappés par l'IA - les agents peuvent naviguer et extraire des informations des interfaces web
• Les outils CLI peuvent être utilisés via des serveurs MCP - fournissant un accès structuré aux outils
• Les API - les LLM (par exemple dans les chatbots) sont souvent des wrappers autour d'API. De plus, les LLM peuvent aussi écrire des appels API directement.

Mais ces trois types ont des attentes différentes, ce qui crée de nouveaux défis.

Le défi : API pour les humains vs. machines vs. agents IA

Les API sont optimisées pour les machines, mais quand quelque chose se casse, vous avez besoin d'un humain dans la boucle. Cependant, les agents IA sont autonomes mais, comme les humains, ils ont besoin d'aide et de conseils.

Prenons l'exemple des codes de statut HTTP. Ils fournissent des informations sur les problèmes, mais les agents IA ont besoin de plus de contexte. Les réponses HTTP peuvent fournir un contexte sur les erreurs, mais les réponses fournies par les API peuvent ne pas être à jour ou précises, ce qui fait que les LLM restent bloqués.

Voici un schéma de workflow courant suivi par les LLM : Pensée → Action → Observation. Sans conseils fournis via les prompts, ils peuvent boucler sur le même problème, rencontrant la même Observation après avoir effectué la même Action — potentiellement pour toujours. Les LLM vont essayer de deviner et de s'auto-corriger, ce qui est probablement mauvais pour deux raisons :

• Coûteux - plus d'appels API et de traitement
• Perte de temps - résolution inefficace du problème
• Gourmand en ressources - le temps GPU et l'électricité sont consommés sans résoudre le problème

Conseil : Moins vous faites d'allers-retours avec un LLM, plus il devient « déterministe », même si les LLM ne sont pas intrinsèquement déterministes.

Bonnes pratiques pour des API adaptées aux LLM

Tout ce qui est valable pour les LLM est également valable pour les humains.

Messages d'erreur

Soyez précis avec vos messages d'erreur : « Format de date incorrect. Utilisez 'YYYY-MM-DD'. » Avantages :

• Moins de tokens consommés
• Utilisation réduite de la fenêtre de contexte
• Résolution plus rapide

Nommage cohérent

Utilisez le même modèle de nommage partout. Par exemple, utilisez user_id de manière cohérente sur tous les points de terminaison. Avantages :

• Modèles prévisibles
• Les LLM aiment la cohérence
• Plus facile à comprendre et à utiliser

Documentation

• Corrigez les exemples et supprimez le contenu obsolète
• Moins de problèmes et d'hallucinations
• Envisagez d'utiliser des fichiers llms.txt - documentation spécifiquement formatée pour les LLM en Markdown

Considérations de performance

Les agents IA sont lents, donc réduire le nombre de requêtes offre un gain de performance significatif.

Conception d'API orientée intention

Concevez vos API pour capturer et préserver l'intention utilisateur plutôt que de simplement exposer des opérations CRUD.

Défis des tests

Tester les agents IA est extrêmement difficile car :

• Les LLM ne sont pas déterministes
• Vous devez régler la température à 0 pour des résultats plus cohérents
• Utilisez des prompts concis
• En fin de compte, vous avez besoin d'un humain pour juger la qualité des actions effectuées par le LLM, ce qui rend les tests automatisés complexes

Considérations techniques

Tokens vs. Texte

Comprendre la tokenisation est crucial. Des outils comme tiktokenizer.vercel.app aident à visualiser comment le texte est tokenisé :

• La langue a son importance : l'anglais coûte moins de tokens que le français ou le japonais par exemple
• Les identifiants uniques sont problématiques : les UUID sont mauvais pour les tokeniseurs, les ULID sont meilleurs
• Plus court n'est pas toujours mieux en termes d'efficacité des tokens
• Les formats de date ont un impact sur la consommation de tokens
• JSON n'est pas le meilleur format pour les LLM - Markdown est meilleur et utilise moins de tokens

Plus de tokens nécessitent plus d'argent et créent des fenêtres de contexte plus grandes, ce qui impacte négativement les temps de réponse et la pertinence des agents IA.

Sécurité et identifiants

Les agents IA sont mauvais pour gérer les identifiants. La solution est d'utiliser des serveurs MCP (Model Context Protocol) qui :

• Gèrent les identifiants de manière sécurisée
• Fournissent des outils aux agents IA
• Donnent des permissions à portée limitée aux actions MCP
• Agissent comme un intermédiaire sécurisé entre le LLM et vos API

Tout journaliser

Compte tenu de la complexité et de l'imprévisibilité des interactions des agents IA, une journalisation complète devient essentielle pour le débogage et l'amélioration du système.

La nouvelle expérience : AX (AI Experience)

Fabien a introduit le concept d'AX (AI Experience) aux côtés de l'UX (User Experience) et du DX (Developer Experience). Cela représente une nouvelle dimension de la conception d'API axée sur la façon dont votre API fonctionne avec les agents IA.

Les aspects clés d'une bonne AX incluent :

• Documentation et exemples à jour (éviter les exemples obsolètes qui pourraient induire le LLM en erreur)
• Utilisation de fichiers llms.txt avec toute la documentation utile pour le LLM au format Markdown
• Messages d'erreur clairs et cohérents
• Conception d'API préservant l'intention
• Utilisation efficace des tokens

L'aspect fascinant est que de nombreuses améliorations pour l'AX profitent également au DX traditionnel, rendant les API meilleures à la fois pour les développeurs humains et les agents IA.

Construire une application découplée avec API Platform et Vue.js (Nathan de Pachtere)

Nathan de Pachtere a partagé son expérience de construction d'applications découplées en utilisant API Platform pour le backend et Vue.js pour le frontend. Ses réflexions ont couvert les différences entre les approches headless et découplées, les stratégies d'implémentation pratiques et les avantages de l'architecture monorepo.

Headless

L'architecture headless consiste à créer une API orientée métier que tout le monde peut utiliser indépendamment. Pensez à l'API GitHub - elle est conçue comme un service autonome qui fournit toutes les fonctionnalités nécessaires pour interagir avec les fonctionnalités de GitHub, complètement indépendante de toute implémentation frontend spécifique.

L'objectif est de créer une logique métier et de fournir une API que chacun peut utiliser à ses propres fins.

Découplé

L'architecture découplée est similaire mais plus ciblée. Vous fournissez un frontend qui repose spécifiquement sur votre API, créant ainsi ce qu'on appelle un modèle backend-for-frontend. L'API ne semble pas conçue pour une utilisation indépendante en dehors de l'application spécifique - elle est adaptée pour répondre exactement aux besoins du frontend.

Pourquoi choisir cette approche ?

Avantages

• Séparation des responsabilités - Limites claires entre les préoccupations frontend et backend
• Gestion d'équipe - Permet aux équipes spécialisées de travailler indépendamment sur leurs domaines d'expertise
• Capitalisation - Composants et logique réutilisables entre différents projets
• Pérennisation - L'IA pourrait être l'interface utilisée à l'avenir, rendant une approche API-first précieuse

Inconvénients

• Complexité - Configuration plus complexe pour les projets existants qui doivent être refactorisés

Implémentation Headless

avec API Platform

Le processus suit une approche orientée métier :

1. Représenter l'API basée sur les besoins métier - Concentrez-vous sur ce que l'entreprise fait réellement
2. Traduire en entités et workflows - Convertissez les processus métier en implémentations techniques
3. Écrire uniquement le code nécessaire - Restez simple initialement
4. Puis optimiser et refactoriser - Améliorez les performances et la qualité du code
5. Itérer - Améliorez continuellement en fonction des retours
6. Aller au-delà du CRUD - Implémentez des opérations métier significatives, pas seulement la manipulation de données de base

Fourniture de clés API

Pour l'authentification machine-à-machine :

• Créez une interface simple pour créer/supprimer des clés configurables avec des permissions spécifiques
• Envisagez des fournisseurs d'identité externes comme Keycloak ou Zitadel pour des cas d'utilisation plus avancés
• Principe important : Ne mélangez pas les utilisateurs humains avec les utilisateurs machines - ils ont des besoins et des exigences de sécurité différents

Nathan a souligné l'importance de rendre les tests simples et faciles à implémenter, en les intégrant naturellement dans le workflow de développement plutôt que de les traiter comme une réflexion après coup.

Stratégie de dépréciation

Lors de l'évolution de votre API :

• Dépréciez les points de terminaison, ressources et propriétés progressivement
• Donnez aux consommateurs le temps de s'adapter aux changements
• Communiquez les changements clairement avant de supprimer une fonctionnalité

Cette approche maintient la rétrocompatibilité tout en permettant à l'API d'évoluer.

Implémentation Découplée

avec Vue.js

Nathan a choisi Vue.js pour plusieurs raisons :

• Indépendant et piloté par la communauté - Pas contrôlé par une seule entreprise
• Composition API (Vue 3) - Favorise la réutilisabilité du code et une meilleure organisation
• Excellente expérience développeur - Outillage et workflow de développement de qualité
• Meilleures performances - Rapide et efficace (jusqu'au prochain framework, comme il l'a plaisanté)

Connexion API

Pour connecter le frontend Vue.js au backend API Platform :

Génération de code

Utilisez openapi-ts.dev pour générer des types TypeScript et des composables à partir de votre spécification OpenAPI. Cela garantit la sécurité des types et réduit le travail manuel.

Principe important : N'utilisez pas directement les types générés comme objets de base dans votre frontend. Créez vos propres modèles pour maintenir un découplage approprié entre les représentations frontend et backend.

Client HTTP et gestion d'état

• Tanstack Query - Pour une récupération et un mise en cache efficaces des données
• TypeScript partout - Garantit la sécurité des types dans toute l'application
• VS Code pour le développement Vue.js - Meilleure intégration que les IDE JetBrains pour le travail Vue.js

SDK de haut niveau

Fournissez des SDK de haut niveau pour faciliter l'intégration API, rendant plus facile pour les développeurs de travailler avec votre API.

Gestion des versions

Polyrepo vs Monorepo

Monorepo ne signifie pas monolithe - c'est une distinction cruciale :

• Monorepo = Plusieurs projets séparés dans un seul dépôt
• Monolithe = Application unique gérant tout

Avantages du Monorepo

L'objectif est de simplifier le workflow :

• Façon unifiée de penser le code - Modèles cohérents entre les projets
• Cohérence - Outillage et configurations partagés
• Facilite le partage - Réutilisation facile du code et des composants
• Travail d'équipe plus efficace - Collaboration et gestion des dépendances simplifiées

Outillage

Nathan a recommandé moonrepo.dev comme outil open source pour gérer les monorepos. Vous pouvez trouver plus d'informations sur monorepo.tools.

Exemple concret

Nathan a partagé leur expérience avec des avantages considérables :

• Généralisation du code - Modèles et composants réutilisables
• Partage de fonctionnalités - Bibliothèques communes entre les projets
• Organisation par technologie - Les projets utilisent des bibliothèques partagées organisées par stack technologique

Vous pouvez voir un exemple pratique de cette approche dans le projet Lychen (lychen.fr), qui démontre un monorepo bien structuré avec une séparation claire entre le backend, le frontend et les outils partagés.

Le projet Lychen montre comment organiser un monorepo avec :

• Backend (API Platform/PHP)
• Frontend (Vue.js/TypeScript)
• Outillage partagé (Moonrepo, Docker, outils de test)
• Limites technologiques claires tout en maintenant un partage de code efficace

Jean-Beru présente : Fun with flags (Hubert Lenoir)

Les slides de cette conférence sont disponibles : https://jean-beru.github.io/2025_09_apiplatformcon_fun_with_flags

Jean-Beru (Hubert Lenoir) a présenté le monde fascinant des feature flags et leur implémentation pratique. Comme l'a dit Oncle Ben dans Spider-Man : « Un grand pouvoir implique de grandes responsabilités » - et les feature flags sont effectivement un outil puissant qui nécessite une réflexion approfondie.

Que sont les Feature Flags ?

Les feature flags (également appelés feature flipping ou feature toggles) sont une technique de développement logiciel qui permet d'activer ou de désactiver des fonctionnalités sans déployer de nouveau code. Ils agissent comme des instructions conditionnelles dans votre code qui déterminent si une fonctionnalité particulière doit être activée ou désactivée pour des utilisateurs, environnements ou conditions spécifiques.

Types de Feature Flags

Flags de Release

Principalement utilisés pour tester de nouvelles fonctionnalités en production en toute sécurité.

• Développement continu - Même si une fonctionnalité n'est pas prête, vous pouvez continuer à développer et déployer (non prêt = désactivé)
• Déploiement sécurisé - Déployez le code avec les fonctionnalités désactivées, puis activez-les quand elles sont prêtes
• Déploiement progressif - Activez les fonctionnalités pour de petits groupes avant le déploiement complet

Flags d'Expérimentation

Utilisés pour comparer différentes versions de votre application.

• Tests A/B - Comparez différentes implémentations ou expériences utilisateur
• Doivent être accompagnés de métriques - Suivez les performances et le comportement des utilisateurs
• Activation partielle - Activez pour des pourcentages spécifiques (par exemple, 20 % des utilisateurs)

Cette approche permet des décisions basées sur les données concernant les fonctionnalités ou implémentations qui fonctionnent le mieux pour vos utilisateurs.

Flags de Permission

Contrôlent l'accès aux fonctionnalités en fonction des permissions des utilisateurs ou des niveaux d'abonnement.

• Blocage d'accès basé sur les permissions - Par exemple, fonctionnalités payantes disponibles uniquement pour les abonnés premium
• Accès aux fonctionnalités basé sur les rôles - Différentes fonctionnalités pour différents types d'utilisateurs
• Niveaux d'abonnement - Activez des fonctionnalités avancées pour les clients de niveaux supérieurs

Flags Opérationnels

Ceinture de sécurité et fonction kill switch.

• Permettent de désactiver les fonctionnalités lourdes - Désactivez rapidement les fonctionnalités gourmandes en ressources en période de forte charge
• Réponse d'urgence - Désactivez les fonctionnalités problématiques sans déploiement
• Gestion des performances - Contrôlez la charge système en activant/désactivant les opérations coûteuses

Pour plus d'informations détaillées sur les modèles de feature flags, Martin Fowler a un excellent article sur https://martinfowler.com/articles/feature-toggles.html.

Implémentation

Il existe de nombreux fournisseurs de feature flags sur le marché, mais l'implémentation n'a pas nécessairement besoin d'utiliser le composant Security de Symfony.

Pourquoi pas le composant Security ?

• Restreint au contexte utilisateur actuel - Limitations lorsque les flags doivent fonctionner dans différents contextes utilisateur
• Problèmes de timing d'authentification - L'authentification a lieu après le routage, ce qui peut entraîner des codes d'erreur interdits indésirables
• Besoins de flexibilité - Les implémentations personnalisées peuvent mieux s'intégrer avec des fournisseurs existants comme Unleash

Exigences pour une bonne implémentation

Un système de feature flags solide devrait fournir :

• Simplicité - Facile à implémenter et à utiliser
• Débogage intégré - Visibilité claire sur les flags actifs
• Sources multiples - Capacité de basculer entre différents fournisseurs de flags
• Support de divers fournisseurs - Fonctionne avec différents services de feature flags
• Cacheable - Optimisation des performances via des mécanismes de cache

Intégration Symfony

Il existe un composant FeatureFlag en cours de développement pour Symfony (PR #53213). Ce composant vise à fournir un support natif des feature flags dans l'écosystème Symfony.

Avec API Platform

Les feature flags peuvent être facilement testés via un bundle séparé : ajgarlag/feature-flag-bundle.

Étapes d'implémentation

1. Décoration du provider API Platform - Utilisez le pattern decorator pour envelopper les providers existants avec la logique de feature flag
2. Utilisez l'interface du composant FeatureFlag WIP - Intégrez-vous avec le futur composant FeatureFlag de Symfony

Exemple avec le fournisseur GitLab

GitLab fournit un service de feature flags qui utilise Unleash en arrière-plan. Cette intégration vous permet de :

• Gérer les flags via l'interface GitLab - Interface familière pour les équipes utilisant déjà GitLab
• Tirer parti des capacités d'Unleash - Moteur de feature flags puissant sous le capot
• Intégrer avec les pipelines CI/CD - Gestion automatique des flags dans le cadre du processus de déploiement

Intégration du Profiler

L'implémentation inclut l'intégration du Symfony Profiler, fournissant :

• Informations de débogage - Voyez quels flags sont actifs pendant le développement
• Informations de performance - Surveillez l'impact des vérifications de feature flags
• Workflow de développement - Test et débogage faciles du comportement des flags

Avantages

L'implémentation des feature flags apporte plusieurs avantages significatifs :

Déploiement continu

• Découpler le déploiement de la release - Déployez le code en toute sécurité avec les fonctionnalités désactivées
• Réduire le risque de déploiement - Moins de chances de casser la production
• Cycles d'itération plus rapides - Déploiements plus fréquents et plus petits

Tests progressifs

• Capacités de tests A/B - Comparez différentes approches avec de vrais utilisateurs
• Déploiements progressifs - Commencez avec de petits groupes d'utilisateurs et étendez
• Décisions basées sur les données - Faites des choix basés sur des métriques d'utilisation réelles

Désactivation rapide

• Pas de redéploiement nécessaire - Désactivez instantanément les fonctionnalités problématiques
• Réponse d'urgence - Réaction rapide aux problèmes de production
• Continuité d'activité - Gardez les fonctionnalités principales opérationnelles pendant la résolution des problèmes

Séparer le code de la release de fonctionnalité

• Calendriers indépendants - Les plannings de développement et de release métier peuvent différer
• Coordination marketing - Alignez les releases de fonctionnalités avec les campagnes marketing
• Gestion des parties prenantes - Donnez aux équipes métier le contrôle sur le moment où les fonctionnalités sont mises en ligne

Les feature flags représentent un changement de paradigme puissant dans notre façon de concevoir le déploiement logiciel et la gestion des releases, permettant des pratiques de développement plus flexibles, plus sûres et basées sur les données.

PIE : La prochaine grande chose (Alexandre Daubois)

Les extensions ?

Les extensions sont comme des paquets Composer, mais écrites en C, C++, Rust, et maintenant Go. Elles vivent à un niveau plus bas, ce qui les rend beaucoup plus rapides que le code PHP pur.

Des frameworks comme Phalcon sont eux-mêmes distribués comme des extensions.

Installation d'une bibliothèque tierce

Traditionnellement, installer une extension est beaucoup plus pénible qu'un composer install. Cela implique généralement :

1. Télécharger le code source.
2. Le compiler avec phpize et make.
3. Ajouter une ligne dans php.ini pour l'activer.
4. Redémarrer PHP-FPM ou Apache pour la charger.

Ce workflow rend les extensions plus difficiles à distribuer et à standardiser par rapport aux paquets Composer.

PECL

• Lourd et obsolète.
• Lent à installer.
• Manque de sécurité appropriée (pas de signature de paquets).
• Pas officiellement soutenu par PHP, et certains dans la communauté veulent le supprimer progressivement.

docker-php-extension-installer

Un projet communautaire largement utilisé qui simplifie l'installation des extensions dans les images Docker. Au lieu d'écrire des commandes complexes apt-get + phpize + make, vous ajoutez simplement :

COPY --from=ghcr.io/mlocati/php-extension-installer /usr/bin/install-php-extensions /usr/local/bin/

RUN install-php-extensions xdebug redis

C'est excellent, mais pas encore parfait — cela reste spécifique à Docker et ne s'intègre pas avec Composer ou Packagist.

Projet pour remplacer PECL

Le dépôt pie-design définit les bases de PIE, une nouvelle façon d'installer les extensions aussi facilement que les paquets PHP.

• Lancé en mars 2024.
• Version 1 publiée en juin 2025.
• PIE est distribué sous forme d'un seul fichier phar : il suffit de le télécharger et de l'utiliser.
• Toutes les métadonnées des extensions sont stockées dans Packagist.

Options de commande

• pie install ext-xdebug → installe une extension et met à jour php.ini.
• pie uninstall ext-redis → supprime une extension.
• pie update → met à jour vers la dernière version disponible.
• pie search redis → recherche des extensions dans Packagist.
• Exécuter pie sans arguments lit les extensions depuis composer.json et les installe.

Autres fonctionnalités :

• Ajout de dépôts via Composer, VCS ou chemins locaux.
• Mise à jour automatique de php.ini.
• Support de GH_TOKEN pour installer depuis des dépôts privés.
• Restrictions de compatibilité OS.
• Intégration Symfony CLI : symfony pie install.

L'avenir des extensions

PIE est le remplacement théorique de PECL. Un vote RFC a eu lieu, clos le 20 septembre 2025. Presque tout le monde a voté oui, ce qui signifie que PIE est désormais le successeur officiel de PECL.

Rendez vos développeurs heureux en normalisant vos erreurs API (Clément Herreman)

Les erreurs ne sont pas seulement des bugs. Ce sont des opportunités de donner de l'autonomie aux utilisateurs grâce à des retours clairs.

Qu'est-ce qu'une erreur ?

Une erreur est tout comportement — intentionnel ou non — qui empêche l'utilisateur de terminer sa tâche.

Pourquoi normaliser les erreurs ?

1. Pour réagir correctement à un problème précis :

   • Réessayer un token.
   • Gérer les défaillances de systèmes distribués.
   • Corriger des problèmes de configuration.

2. Pour présenter les erreurs de manière cohérente :

   • Messages clairs et compréhensibles pour les utilisateurs finaux.
   • Identification précise pour faciliter le support.
   • Garder certains détails vagues pour des raisons de sécurité.

Comment ?

Les erreurs peuvent être classées en trois catégories :

1. Les erreurs qui appartiennent à votre domaine : vous les possédez, donc enrichissez-les avec du contexte.
2. Les erreurs qui n'appartiennent pas à votre domaine mais qui se produisent quand même : enveloppez-les avec un code et enrichissez-les.
3. Erreurs rares/imprévues : conservez la sortie JSON par défaut.

RFC 7807 : Détails du problème pour les API HTTP

Cette RFC définit une structure JSON standard pour les erreurs :

• type : code unique lisible par machine.
• title : résumé court et lisible par un humain.
• detail : explication contextuelle de cette erreur particulière.
• instance : URL du catalogue d'erreurs.
• ... : tous les champs personnalisés que vous souhaitez.

Exemple de réponse HTTP

HTTP/1.1 401 Unauthorized
Content-Type: application/problem+json

{
  "type": "https://example.com/errors/authentication_failed",
  "title": "Authentication failed",
  "detail": "Your token has expired. Please request a new one.",
  "instance": "/login"
}

API Platform

API Platform fournit une classe prête à l'emploi ApiPlatform\Problem\Error pour implémenter la RFC 7807.

Organisation des erreurs

• Gardez uniquement les exceptions métier dans la couche domaine.
• Enveloppez les erreurs d'infrastructure avant de les envoyer au client.

Documentation des erreurs

Les erreurs peuvent être déclarées comme des attributs sur les opérations, les rendant explicites dans la documentation API.

Améliorations : RFC 9457

La RFC 9457 est essentiellement la même que la RFC 7807, avec quelques ajouts :

• Un registre des erreurs via schema.org.
• Un mécanisme pour retourner plusieurs erreurs à la fois (bien que fortement déconseillé).

Comme l'a souligné Clément : la RFC 9457 n'apporte pas beaucoup de valeur pratique, et certaines de ses suggestions sont même déconseillées dans la spécification.

Symfony et l'injection de dépendances : Du passé au futur (Imen Ezzine)

L'injection de dépendances (DI) est le « D » de SOLID, et elle est une pierre angulaire de la conception de Symfony depuis près de deux décennies. Cette conférence a exploré son histoire, son évolution et ce qui nous attend.

Les débuts

2007 – Symfony 1

• Les services étaient instanciés directement, souvent via sfContext() (un singleton).
• Difficile à tester, rigide, fortement couplé.
• Pas de véritable conteneur.

Symfony 2 et le changement de paradigme

2011 – Symfony 2

• Introduction d'un conteneur central.
• Services configurés via YAML et paramètres.
• Dépendances injectées comme arguments du constructeur.
• L'autowiring introduit dans Symfony 2.8.

2015 – API Platform v1

• Forte dépendance à l'autowiring (alors expérimental).

2016 – API Platform v2

• La magie des annotations @ApiResource propulsée par le composant DI.
• Les data persisters et providers devaient être tagués manuellement.

2017 – Symfony 3.3 / API Platform 2.2

• Autowiring + autoconfigure.
• Le tagging manuel a été presque éliminé (providers/persisters automatiquement câblés).
• Symfony 3.4 : services privés par défaut.

Symfony 5 à Symfony 7

2021 – Symfony 5.3

• DI propulsée par les attributs → beaucoup moins de YAML.
• Attribut #[When] pour les services conditionnels.

Symfony 6.0 – 6.3

• Nouveaux attributs pour les cas particuliers.
• Attribut #[Autowire] pour l'injection de service précise.
• Support des variables d'environnement et paramètres via attributs.
• #[AsAlias] pour créer des alias de services.

2022 – API Platform 3.0

• Nouveaux state processors et providers remplacent l'ancien modèle persister/provider.

2023 – Symfony 7

• #[AutoconfigureTag] → tagging automatique (utilisé dans les filtres API Platform).
• TaggedIterator → injection de plusieurs services tagués.
• AutowireIterator → autowire de toutes les classes implémentant une interface.

Symfony 7.1 – 7.3

• #[AutowireMethodOf] pour autowirer une seule méthode.
• #[WhenNot] pour les services conditionnels.
• Paramètre when dans #[AsAlias].

Points à retenir

En 20 ans, la DI dans Symfony a évolué de :

• L'instanciation manuelle →
• La configuration manuelle →
• La configuration automatique via les attributs.

Ce parcours a rendu les projets Symfony plus testables, maintenables et conviviaux pour les développeurs tout en réduisant le code répétitif.

Crédits

Image de couverture par Nicolas Detrez

Voici comment j'ai procédé. J'espère que cela vous plaira !

Avertissement

Nous sommes le 10 juillet 2025 et cet article est obsolète en raison du merge de la Pull Request https://github.com/doctrine/migrations/issues/1406 ; désormais, l'exécution de bin/console doctrine:migrations:up-to-date prend en compte la configuration schema_filter.

Comment fonctionnent les migrations Doctrine

Lors de la génération de la migration, Doctrine calcule un delta entre son mapping et le schéma actuel de la base de données. Avec ce delta en mémoire, il génère un fichier de migration avec deux méthodes principales :

• up applique les commandes SQL pour combler l'écart entre le schéma actuel de la base de données et son mapping. Utilisé pour déployer les modifications du schéma de votre base de données.
• down permet d'annuler la migration avec les commandes SQL nécessaires pour « annuler » les modifications effectuées dans la méthode up. Utilisé pour revenir en arrière sur les modifications du schéma de votre base de données.

L'astuce magique

Il n'existe actuellement aucun moyen simple de vérifier si une migration n'a pas été générée. Si ce code était fusionné, le schéma de la base de données pourrait ne plus être synchronisé avec le mapping des entités, entraînant ainsi une erreur serveur.

Les mots-clés dans la description ci-dessus sont fichiers de migration. J'utilise le fait que l'exécution de la commande bin/console doctrine:migration:diff génère un nouveau fichier et échoue s'il n'y a aucun changement à appliquer.

Connaître la liste des fichiers existants avant l'exécution de cette commande, puis l'exécuter, permet de détecter qu'il y a des modifications qui n'ont pas été commitées dans un fichier de migration dans cette pull (ou merge) request.

Étapes à suivre

1. Créez votre base de données
2. Exécutez vos migrations existantes
3. Puis exécutez l'étape de vérification des modifications manquantes (voir ci-dessous)

Avantages

1. Tester que vos migrations ne échouent pas
2. Assurer la cohérence du schéma de base de données avec le mapping de Doctrine

Vous voulez l'extrait de code, n'est-ce pas ?

Voici le code bash :

#!/bin/bash

set -e
set -o pipefail

# run doctrine migration diff to check if there is a new migration file generated and check last exit code
if [[ -z $(bin/console doctrine:migrations:diff -n --quiet) ]]; then
    echo "Error ! bin/console doctrine:migration:diff found a new migration which must not be the case.";
    # cat last file (should be the newly generated one)
    cat $(ls -Art migrations/*.php | tail -n 1);
    # remove that file (just in case to comply with my paranoïac side)
    rm -f $(ls -Art migrations/*.php | tail -n 1);
    exit 1;
else
    exit 0;
fi

Et voilà ! Vous pouvez désormais vous assurer que chaque pull (ou merge) request contient des migrations fonctionnelles, sans modification en attente laissée de côté !

Ok, mais pourquoi ne pas utiliser bin/console doctrine:schema:validate ?

La raison est que le projet sur lequel nous travaillions utilisait la configuration schema_filter de Doctrine pour filtrer certaines tables dont nous ne voulions pas nous occuper (contrainte liée au projet).

Le problème avec bin/console doctrine:schema:validate est qu'il ne prenait pas en compte cette configuration, et signalait donc des modifications (tentant de supprimer toutes les tables normalement filtrées) sans rapport avec ce que nous voulions.

Un collègue m'a dit qu'il s'agit d'un problème connu qui pourrait être corrigé prochainement (https://github.com/doctrine/migrations/issues/1406).

Merci d'avoir lu cet article et n'hésitez pas à laisser vos commentaires si vous avez des questions !