DEV Community: Mathieu Ledru

⬆️ Nouveautés de Symfony 8.1

Mathieu Ledru — Fri, 29 May 2026 10:20:38 +0000

Symfony 8.1 continue d'étendre progressivement la portée du framework bien au-delà du développement web traditionnel.

Cette nouvelle version apporte de nombreuses améliorations à :

expérience de développeur,
architectures asynchrones,
Outils CLI,
sérialisation,
Traitement JSON,
Messager,
et les applications orientées travailleurs ou basées sur l'orchestration.

Pour cet article, j'ai passé en revue toutes les nouvelles fonctionnalités publiées dans les articles « Vivre à la limite » afin de produire un aperçu technique complet des changements les plus importants de Symfony 8.1.

L’objectif n’est pas de recenser chaque détail, mais plutôt de comprendre la direction prise par l’écosystème Symfony et ses implications concrètes pour les développeurs backend modernes.

Résolveurs d'arguments de console

Bref résumé

Symfony 8.1 introduit le modèle de résolution d'arguments de contrôleur dans les commandes de la console. Les arguments et options bruts de l'interface de ligne de commande peuvent être automatiquement associés à des objets de domaine, des types valeur et des services dans les méthodes __invoke(), à l'instar de la couche HTTP. Les résolveurs intégrés prennent en charge les entités Doctrine, les dates, les énumérations, les UUID et les ULID ; des implémentations personnalisées de ValueResolverInterface permettent d'étendre davantage ce mécanisme.

Principaux changements techniques

Les commandes de console utilisant #[Argument] et #[Option] peuvent s'appuyer sur des résolveurs de valeurs au lieu d'une analyse et d'un chargement manuels.
Les résolveurs intégrés incluent #[MapEntity] (mappage de clé primaire ou de champ personnalisé) et #[MapDateTime] (analyse de date prenant en compte le format).
Les services peuvent être injectés directement dans les paramètres de __invoke(), et pas seulement via le constructeur.
Prise en charge complète des attributs DI dans les méthodes de commande : #[Autowire], #[Target], variables d'environnement et services nommés (par exemple messenger.bus.async).
Les résolveurs personnalisés implémentent ValueResolverInterface, le même modèle d'extensibilité que les contrôleurs HTTP.

Pourquoi c'est important

Les commandes sont plus concises et déclaratives. L'infrastructure de résolution commune à HTTP réduit la duplication entre les points d'entrée web et en ligne de commande. Les processus de longue durée et les outils opérationnels bénéficient d'une injection et d'une conversion de type cohérentes, sans code répétitif.

Cas d'utilisation potentiels dans le monde réel

Outils CLI d'administration qui acceptent les ID d'entité et résolvent les entités Doctrine complètes avant l'exécution.
Commandes d'audit ou par lots injectant un bus Messenger ou un enregistreur spécifique via #[Autowire] / #[Target].
Commandes de migration de données avec options de date typées et résolveurs personnalisés pour les chemins de fichiers ou les objets de configuration.
Pipelines d'IA/opérations où les commandes CLI répartissent des tâches asynchrones avec un contexte de domaine pré-résolu.

Extraits de code importants

public function __invoke(
    #[Argument, MapEntity] User $user,
    #[Option, MapDateTime(format: 'Y-m-d')] \DateTimeInterface $date,
    #[Autowire(service: 'messenger.bus.async')] MessageBusInterface $bus,
): int {
    // ...
}

Composants/packages Symfony associés

symfony/console
symfony/http-kernel (modèle ValueResolverInterface)
symfony/doctrine-bridge (MapEntity)
symfony/dependency-injection (Autowire, Target)
symfony/messenger (injection de bus dans l'interface de ligne de commande)

Cloneur en profondeur

Bref résumé

Symfony 8.1 introduit DeepCloner dans le composant VarExporter, une alternative plus rapide et plus économe en mémoire à unserialize(serialize($value)) pour le clonage en profondeur des graphes d'objets PHP. Il préserve la sémantique de copie à l'écriture pour les chaînes de caractères et les tableaux, et prend en charge les instances de cloneur réutilisables, la substitution de classes et les charges utiles de cloneur sérialisables pour la mise en cache ou le transport interprocessus. Les composants principaux de Symfony l'utilisent désormais en interne lors de la compilation des conteneurs, des instantanés de formulaires et des opérations de cache en mémoire.

Principaux changements techniques

DeepCloner::deepClone($object) pour les clones profonds ponctuels.
Les instances réutilisables de DeepCloner analysent le graphe une seule fois ; les appels répétés à clone() sont moins coûteux.
cloneAs(ChildClass::class) clone dans une sous-classe compatible.
toArray() / fromArray() exportent l'état du cloneur pour la mise en cache, MessagePack, APCu ou les fichiers PHP préchauffés ; les charges utiles sont environ 30 à 40 % plus petites que serialize().
Les classes Hydrator et Instantiator sont obsolètes et remplacées par deepclone_hydrate().
L'extension optionnelle symfony/php-ext-deepclone fournit des implémentations natives avec un repli transparent.

Pourquoi c'est important

Le clonage en profondeur est une opération fondamentale de la compilation par injection de dépendances, de la gestion des formulaires et de la mise en cache. L'utilisation de DeepCloner permet des gains mesurables en termes de temps de compilation et d'exécution (jusqu'à 4 fois plus rapide sur les graphes classiques et jusqu'à 15 fois plus rapide sur les graphes riches en propriétés) sans modification au niveau de l'application. Les charges utiles de clonage exportables permettent des caches chauds efficaces et le transport de graphes d'objets entre processus.

Cas d'utilisation potentiels dans le monde réel

Des nœuds de calcul à haut débit qui clonent les objets de configuration ou de modèle par tâche sans état mutable partagé.
Mise en cache des graphes d'objets compilés (par exemple, modèles d'invites d'IA, définitions de flux de travail) via des charges utiles toArray().
Formulaires d'application nécessitant des instantanés de données de requête à requête sans fuites de références.
Compilation de conteneurs dans les pipelines CI/CD où des builds plus rapides réduisent les boucles de rétroaction.

Extraits de code importants

$cloner = new DeepCloner($prototype);
$clone1 = $cloner->clone();

$payload = (new DeepCloner($graph))->toArray();
$clone = DeepCloner::fromArray(json_decode($json, true))->clone();

$user = deepclone_hydrate(User::class, ['name' => 'Alice']);

Composants/packages Symfony associés

symfony/var-exporter (DeepCloner, deepclone_hydrate)
symfony/dependency-injection (clonage de définitions de services)
symfony/framework-bundle (vidages de conteneurs compilés)
symfony/form (instantanés de données de formulaire)
symfony/cache (ArrayAdapter)
symfony/php-ext-deepclone (extension PHP optionnelle)

Améliorations de l'injection de dépendances

Bref résumé

Symfony 8.1 apporte de nombreuses améliorations à l'injection de dépendances, notamment pour les processus de longue durée, la composition de décorateurs et un ciblage de services plus clair. Les variables d'environnement peuvent être injectées sous forme de valeurs Closure ou Stringable paresseuses pour une actualisation à l'exécution ; les piles et les services étiquetés bénéficient d'une décoration déclarative ; et #[Target] / #[AsTaggedItem] deviennent les modèles explicites et recommandés. Plusieurs conventions héritées (correspondance d'alias basée sur le nom, méthodes d'index/priorité magiques) sont dépréciées et supprimées dans Symfony 9.0.

Principaux changements techniques

Variables d'environnement en tant que Closure/Stringable : #[Autowire(env: 'DB_URL')] \Closure $dbUrl et balise YAML !env_closure ; les valeurs sont actualisées via Container::resetEnvCache().
Piles de services en tant que décorateurs : les définitions stack prennent en charge decorates et decorates_tag ; la couche la plus interne enveloppe le service cible.
decorates_tag / #[AsTagDecorator]: enveloppe automatiquement chaque service portant une étiquette donnée (journalisation, traçage, mise en cache).
Fabriques/configurateurs de définition en ligne : setFactory() et setConfigurator() acceptent directement les instances Definition.
Exclusions d'importation : ContainerConfigurator::import(..., exclude: [...]) ignore les fichiers dans les importations glob.
#[AsAlias(..., target: 'name')]: déclare des alias d'injection automatique nommés côté service.
#[Target] requis explicitement : la correspondance d'alias basée sur le nom du paramètre est obsolète (supprimée dans la version 9.0).
#[AsTaggedItem] sur les votants : définit la priorité des balises sans dupliquer security.voter.
Points dans les noms des variables d'environnement : %env(DATABASE.PRIMARY.URL)% est maintenant valide.
getDefaultName() / getDefaultPriority() obsolètes : remplacés par #[AsTaggedItem(index:, priority:)].

Pourquoi c'est important

Ces modifications corrigent des problèmes opérationnels concrets liés aux workers et aux architectures de type microservices, où la configuration de l'environnement doit être actualisée sans reconstruction du conteneur. La décoration déclarative des balises élimine les passes de compilation personnalisées pour les problématiques transversales. Un ciblage plus strict réduit les dysfonctionnements silencieux dus aux renommages de paramètres.

Cas d'utilisation potentiels dans le monde réel

Des processus Messenger/FrankenPHP/RoadRunner injectent des URL de base de données ou des indicateurs de fonctionnalités qui changent lors de l'exécution.
Décorer tous les générateurs de contexte ou gestionnaires de messages de la plateforme API avec la journalisation/le traçage via decorates_tag.
Déploiements multi-locataires utilisant des noms de variables d'environnement hiérarchiques provenant de gestionnaires de secrets externes.
Systèmes d'orchestration câblant des backends de stockage nommés (#[Target('image')]) sans nommage de paramètres fragile.

Extraits de code importants

public function __construct(
    #[Autowire(env: 'DB_URL')] private \Closure $dbUrl,
    #[Target('image')] private StorageInterface $storage,
) {}

my_stack:
    decorates: api_platform.serializer.context_builder
    stack:
        - class: App\Decorator\AddGroupsContextBuilder
          arguments: ['@.inner']

Composants/packages Symfony associés

symfony/dependency-injection
symfony/framework-bundle
symfony/security-core (votants, AsTaggedItem)
symfony/messenger (actualisation de l'environnement de travail de longue durée)

Attributs du contrôleur dynamique

Bref résumé

Symfony 8.1 rend les attributs du contrôleur (#[Cache], #[IsGranted], #[MapRequestPayload], attributs personnalisés) modifiables à l'exécution et plus faciles à étendre. Après la première résolution, les attributs sont stockés dans l'attribut de requête _controller_attributes, permettant ainsi aux écouteurs d'événements de les redéfinir pour chaque requête. Des événements noyau dédiés, nommés {kernelEvent}.{AttributeFQCN}, remplacent l'inspection manuelle des attributs dans les écouteurs génériques.

Principaux changements techniques

attribut de requête _controller_attributes : le premier appel ControllerEvent::getAttributes() lit à partir de la réflexion ; les lectures suivantes réutilisent les valeurs stockées.
Remplacement à l'exécution : les écouteurs appellent setController($callable, $attributes) pour remplacer les attributs d'une seule requête.
Liste d'attributs plate : getAttributes('*') renvoie les attributs dans l'ordre de déclaration ; l'accès filtré par classe reste inchangé.
ResponseEvent::$controllerArgumentsEvent: les écouteurs de réponse peuvent lire les attributs appliqués sans réflexion supplémentaire.
Événements nommés par attribut : par exemple kernel.controller_arguments.{Cache::class} avec ControllerAttributeEvent (expose $event->attribute et $event->kernelEvent).
Écouteurs intégrés migrés : CacheAttributeListener, IsGrantedAttributeListener, TemplateAttributeListener utilisent le nouveau système ; les événements ne sont déclenchés que lorsque des écouteurs existent ; l’héritage des attributs est pris en charge.

Pourquoi c'est important

Les attributs restent le comportement par défaut déclaratif dans le code source, mais le code d'infrastructure (multi-tenant, tests A/B, indicateurs de fonctionnalités, passerelles API) peut adapter son comportement à chaque requête sans dupliquer la logique du contrôleur. Les fonctionnalités transversales personnalisées basées sur des attributs deviennent pleinement opérationnelles grâce à des événements dédiés, remplaçant ainsi la réflexion fragile dans les écouteurs génériques du noyau.

Cas d'utilisation potentiels dans le monde réel

Remplacement de la durée de vie du cache par locataire dans une API SaaS sans modifier les contrôleurs.
Limitation dynamique du débit via des attributs personnalisés #[RateLimit] gérés par des écouteurs dédiés.
Sécurité basée sur les indicateurs de fonctionnalités : échanger les rôles #[IsGranted] au moment de l'exécution pour les points de terminaison bêta.
Contrôleurs de passerelle IA où la mise en cache ou l'autorisation dépend du contexte de la requête (modèle, niveau, paramètres régionaux).

Extraits de code importants

public function onKernelController(ControllerEvent $event): void
{
    $attributes = $event->getAttributes();
    $attributes[Cache::class] = [new Cache(maxage: 60, public: true)];
    $event->setController($event->getController(), array_merge(...array_values($attributes)));
}

#[AsEventListener(event: KernelEvents::CONTROLLER_ARGUMENTS.'.'.RateLimit::class)]
public function __invoke(ControllerAttributeEvent $event): void
{
    $rateLimit = $event->attribute;
}

Composants/packages Symfony associés

symfony/http-kernel
symfony/event-dispatcher
symfony/security-http (écouteur d'attribut IsGranted)
symfony/framework-bundle

Applications Symfony sans HTTP

Bref résumé

Symfony 8.1 extrait l'infrastructure du noyau et des bundles de HttpKernel vers le composant DependencyInjection, permettant ainsi aux applications de démarrer un conteneur d'injection de dépendances sans inclure de code lié à HTTP. Une nouvelle paire AbstractKernel + KernelTrait remplace MicroKernelTrait pour les charges de travail non HTTP, et le noyau de FrameworkBundle est désormais divisé en deux composants indépendants : ServicesBundle et ConsoleBundle. Ce changement structurel a des implications importantes pour les workers, les outils en ligne de commande et les consommateurs de messages.

Principaux changements techniques

Noyau dans le composant DI : Symfony\Component\DependencyInjection\Kernel\AbstractKernel et KernelTrait fournissent le cycle de vie du conteneur (construction, compilation, cache) sans HTTP.
Nouvelle KernelInterface : API réservée aux conteneurs, découplée de HttpKernelInterface ; HttpKernel\Kernel existant étend AbstractKernel (rétrocompatible).
Répertoire de journalisation nullable : getLogDir() nullable ; définissez APP_LOG_DIR=false pour exclure var/log/.
Alias obsolètes : BundleInterface, MergeExtensionConfigurationPass, FileLocator ont été déplacés de HttpKernel vers DI (les anciennes classes restent en tant qu’alias obsolètes).
ServicesBundle : services DI fondamentaux (répartiteur d’événements, système de fichiers, horloge, processeurs d’environnement).
ConsoleBundle : services de console (enregistrement des commandes, résolveurs d’arguments, écouteur d’erreurs) ; les applications minimales n’ont besoin que de ce bundle.
#[RequiredBundle]: dépendances de bundle déclaratives avec résolution récursive et ignoreOnInvalid optionnel.

Pourquoi c'est important

Les commandes de la console, les consommateurs Messenger et les processus en arrière-plan ne dépendent plus inutilement d'HttpKernel. Des initialisations plus légères permettent des démarrages à froid plus rapides, des déploiements allégés et une séparation architecturale plus nette entre les points d'entrée HTTP et non-HTTP.

Cas d'utilisation potentiels dans le monde réel

Processus de traitement Messenger dédiés avec une empreinte Symfony minimale.
Processeurs d'inférence IA ou de traitement par lots utilisant l'injection de dépendances, les événements et la console sans pile HTTP.
Utilitaires CLI de type microservice (pipelines de données, orchestrateurs cron) basés sur des conventions Symfony partagées.
Des ensembles personnalisés déclarant des dépendances sur l'infrastructure de base via #[RequiredBundle].

Extraits de code importants

class Kernel extends AbstractKernel
{
    use KernelTrait;
}

return [
    Symfony\Component\Console\ConsoleBundle::class => ['all' => true],
];

Composants/packages Symfony associés

symfony/dependency-injection (Espace de noms du noyau)
symfony/console (ConsoleBundle)
symfony/http-kernel (alias obsolètes, compatibilité ascendante)
symfony/framework-bundle (divisé en ServicesBundle + ConsoleBundle)
symfony/messenger (principal consommateur de noyaux sans HTTP)

Attribut de cache amélioré

Bref résumé

Symfony 8.1 améliore l'attribut de contrôleur #[Cache] grâce à des variables d'expression plus claires, un calcul des en-têtes etag/lastModified basé sur les fermetures, une application conditionnelle via une option if et des attributs répétables pour des politiques de cache mutuellement exclusives. Il s'agit d'améliorations incrémentales du cache HTTP ; leur impact est modéré, sauf si vous utilisez intensivement les en-têtes de cache pilotés par attributs.

Principaux changements techniques

Variables d'expression explicites : request (requête complète) et args (arguments du contrôleur résolus) remplacent les variables fusionnées plates ; les anciennes variables plates fonctionnent toujours.
Prise en charge des fermetures : lastModified et etag acceptent les fermetures PHP (array $args, Request $request) pour une logique compatible avec les IDE.
Mise en cache conditionnelle : la nouvelle option if (expression ou fermeture renvoyant un booléen) ignore l’attribut lorsqu’il est faux.
Attribut répétable : empilez plusieurs #[Cache] avec différentes conditions if sur la même action (par exemple, aperçu vs. mode public).
Règle existante préservée : les en-têtes de cache déjà définis sur la réponse ne sont pas écrasés.

Pourquoi c'est important

Réduit l'ambiguïté des expressions lorsque les noms d'arguments entrent en conflit avec les attributs de la requête. Les fermetures améliorent la maintenabilité de la logique ETag complexe. Les attributs conditionnels et répétables permettent des politiques de cache précises sans diviser les contrôleurs ni dupliquer les routes.

Cas d'utilisation potentiels dans le monde réel

API de contenu où l'etag combine l'identifiant de l'article et l'en-tête Accept-Language.
Les points de terminaison en mode aperçu ne doivent jamais être mis en cache publiquement, tandis que les vues normales sont mises en cache pendant une heure.
Points de terminaison CMS ou API headless avec horodatages Last-Modified pilotés par entité.
Politiques de mise en cache multivariantes activées par les paramètres de requête ou les indicateurs de fonctionnalités.

Extraits de code importants

#[Cache(
    etag: "request.headers.get('Accept-Language') ~ args['article'].getId()",
    public: true,
)]
public function show(Article $article): Response {}

#[Cache(public: true, maxage: 3600, if: fn (array $args, Request $r) => !$r->query->has('preview'))]
#[Cache(public: false, maxage: 0, if: fn (array $args, Request $r) => $r->query->has('preview'))]
public function article(Request $request): Response {}

Composants/packages Symfony associés

symfony/http-kernel (Attribut Cache)
symfony/http-foundation (En-têtes de cache de requête et de réponse)
symfony/expression-language (expressions de chaînes de caractères)

Amélioration de la saisie sur la console

Bref résumé

Symfony 8.1 étend la gestion des entrées console avec des invites interactives (#[Ask], #[AskChoice]), le collage d'images depuis le presse-papiers via InputFile, des valeurs par défaut pour les options, le transfert des entrées brutes pour l'orchestration de sous-processus et l'intégration de Validator pour les entrées interactives et mappées. Associées aux résolveurs d'arguments de console et aux commandes basées sur des méthodes, ces nouveautés font de Symfony Console une plateforme performante pour les outils CLI opérationnels et liés à l'IA.

Principaux changements techniques

InputFile + #[Ask]: les invites acceptent les images collées (Ghostty, iTerm2, Kitty, WezTerm, Konsole, Warp) ou les chemins de fichiers.
#[AskChoice]: invites de choix déclaratives ; prend en charge array (sélection multiple) et BackedEnum (choix dérivés automatiquement).
Valeurs par défaut des options négatives : valeur par défaut booléenne pour les options InputOption::VALUE_NEGATABLE.
Valeurs par défaut des objets : #[Option] \DateTimeImmutable $from = new \DateTimeImmutable() est maintenant autorisé.
RawInputInterface: getRawArguments(), getRawOptions(), unparse() pour transférer les jetons CLI aux processus enfants sans valeurs par défaut fusionnées.
Validateur sur #[Ask] : les contraintes sont réexaminées en cas d’échec ; Question::setConstraints() pour QuestionHelper.
validation de #[MapInput] : contraintes de validation automatiques sur les DTO d'entrée mappés (comme #[MapRequestPayload]) ; prise en charge de validationGroups ; lève InputValidationFailedException.

Pourquoi c'est important

Les commandes CLI interactives bénéficient désormais d'une validation des entrées HTTP équivalente. Le transfert des entrées brutes permet une délégation de commandes fiable et l'exécution de sous-processus parallèles. La prise en charge du collage d'images aligne Symfony Console sur les flux de travail modernes d'IA et d'opérations où les captures d'écran sont des entrées essentielles.

Cas d'utilisation potentiels dans le monde réel

Outils CLI assistés par IA acceptant les captures d'écran collées pour analyse (InputFile).
Commandes d'administration de type assistant avec invites e-mail/URL validées.
Exécuteurs de traitement par lots parallèles transmettant les arguments CLI d'origine aux sous-processus de travail.
DTO d'entrée de commande structurée (#[MapInput]) pour les opérations de création/mise à jour avec groupes de validation.

Extraits de code importants

public function __invoke(
    #[Argument, Ask('Provide an image:', constraints: [new Assert\NotBlank()])]
    InputFile $image,
): int {}

$process = new Process([
    \PHP_BINARY, 'bin/console', 'my:command',
    ...$input->getRawArguments(),
    ...$input->unparse(array_keys($options)),
]);

Composants/packages Symfony associés

symfony/console
symfony/validator
symfony/process (transfert de sous-processus)

Amélioration du flux et de l'interrogation JSON

Bref résumé

Symfony 8.1 améliore JsonStreamer grâce à un mécanisme de transformation des valeurs en objets, la gestion intégrée des intervalles de date et des fuseaux horaires, des options par défaut configurables et la conversion des fuseaux horaires pour les objets DateTime. JsonPath bénéficie désormais de l'enregistrement de fonctions personnalisées via #[AsJsonPathFunction]. Ces améliorations visent à optimiser le traitement JSON et l'interrogation de documents, notamment pour les API, les pipelines de streaming et les charges de travail d'IA/données manipulant d'importants volumes de données JSON.

Principaux changements techniques

ValueObjectTransformerInterface : mappe les objets vers/depuis des valeurs JSON scalaires ; les transformateurs auto-enregistrés remplacent le parcours des propriétés.
Objets de valeur intégrés : DateInterval (durée ISO 8601) et DateTimeZone (nom/décalage) ; personnalisables via date_interval_format.
option date_time_timezone : convertit les fuseaux horaires lors de l’encodage/décodage de DateTimeInterface.
framework.json_streamer.default_options : valeurs par défaut à l’échelle de l’application ; options personnalisées transmises aux transformateurs.
Fonctions JsonPath personnalisées : #[AsJsonPathFunction('upper')] sur les classes invocables ; FunctionReturnType::Value vs ::Logical contrôle le contexte d'utilisation.

Pourquoi c'est important

JsonStreamer évite le chargement de documents entiers en mémoire, ce qui est essentiel pour les réponses d'API volumineuses et les flux de journaux/événements. Les transformateurs d'objets de valeur permettent de conserver des types de domaine compacts en JSON sans avoir recours à des normalisateurs personnalisés par classe. L'extensibilité de JsonPath prend en charge le filtrage spécifique au domaine sans pipelines de prétraitement.

Cas d'utilisation potentiels dans le monde réel

Sérialisation en flux continu d'objets financiers « Monnaie » ou de valeurs de mesure sous forme de scalaires compacts.
Pipelines d'IA/RAG interrogeant de grands magasins de documents JSON avec des fonctions JsonPath personnalisées.
API événementielles ou analytiques diffusant du JSON paginé avec une gestion cohérente des dates, heures et fuseaux horaires.
Valeurs par défaut JSON pilotées par la configuration (inclusion de propriétés nulles, options de transformateur personnalisées) pour l'ensemble des services.

Extraits de code importants

class MoneyValueObjectTransformer implements ValueObjectTransformerInterface
{
    public function transform(object $object, array $options = []): string
    {
        return $object->amount.' '.$object->currency;
    }
}

#[AsJsonPathFunction('upper')]
final class UppercaseFunction
{
    public function __invoke(mixed $value): ?string
    {
        return \is_string($value) ? strtoupper($value) : null;
    }
}

Composants/packages Symfony associés

symfony/json-streamer
symfony/json-path
symfony/type-info
symfony/framework-bundle (configuration json_streamer)

Amélioration du mappage des charges utiles des requêtes

Bref résumé

Symfony 8.1 comble plusieurs lacunes dans #[MapRequestPayload], #[MapQueryString] et #[MapUploadedFile] : le chargement de fichiers en plusieurs parties dans les DTO, le dépaquetage variadique des DTO, la dénormalisation des charges utiles vides et les groupes de validation dynamiques. Ces améliorations ciblées de la couche API ont un impact direct sur l’ergonomie des contrôleurs et la flexibilité de la validation des entrées.

Principaux changements techniques

Mappage de fichiers multipart : #[MapRequestPayload] fusionne les paramètres de requête et les fichiers téléchargés (y compris les tableaux imbriqués) avant la désérialisation ; les propriétés UploadedFile sont remplies de manière transparente.
Arguments DTO variadiques : #[MapRequestPayload] Price ...$prices décompresse les tableaux JSON en instances DTO individuelles ; fonctionne également avec #[MapQueryString] et #[MapUploadedFile].
mapWhenEmpty: true: force la dénormalisation sur une requête/un corps vide afin que les dénormaliseurs personnalisés puissent injecter des valeurs (contexte de sécurité, session, valeurs par défaut).
Groupes de validation dynamiques : validationGroups accepte Expression ou Closure évalués au moment de la validation avec args (arguments de contrôleur résolus).

Pourquoi c'est important

Les contrôleurs d'API gérant les chargements de fichiers ne nécessitent plus de fusion manuelle ni de résolveurs fractionnés. Le mappage variadique est conforme aux bonnes pratiques PHP pour les points de terminaison par lots. Les groupes de validation dynamiques éliminent les appels manuels aux validateurs lorsque les règles dépendent d'entités de route résolues ou de rôles utilisateur.

Cas d'utilisation potentiels dans le monde réel

API de produit/catalogue acceptant le nom + l'image dans un seul DTO multipart.
Création de prix groupés ou de lignes de commande à partir de tableaux JSON via des paramètres variadiques.
Points de terminaison de recherche/filtrage où les chaînes de requête vides déclenchent toujours des valeurs par défaut basées sur le dénormaliseur (par exemple, l'ID de l'utilisateur actuel).
Validation des points de terminaison de mise à jour en fonction du rôle ou du type d'entité.

Extraits de code importants

class ProductDto
{
    public ?string $name = null;
    public ?UploadedFile $image = null;
}

public function upload(#[MapRequestPayload] ProductDto $data): Response {}

public function update(
    User $user,
    #[MapRequestPayload(validationGroups: [new Expression('args["user"].getType()')])]
    UpdateUserDto $dto,
): Response {}

Composants/packages Symfony associés

symfony/http-kernel (MapRequestPayload, MapQueryString, MapUploadedFile)
symfony/serializer
symfony/validator
symfony/expression-language
symfony/http-foundation (Fichier téléchargé)

Améliorations de Messenger

Bref résumé

Symfony 8.1 apporte des améliorations significatives à Messenger, notamment en termes de débit des workers, de comportement du transport, d'interopérabilité de la sérialisation, de gestion des erreurs et d'observabilité opérationnelle. Le traitement par lots, les intervalles de réinitialisation des services configurables, la compatibilité des noms de types entre les langages, la correction des problèmes de priorité et de délai de quorum d'AMQP, ainsi que le routage des erreurs de décodage via le pipeline de gestion des erreurs constituent les changements les plus importants pour les architectures asynchrones en production.

Principaux changements techniques

--fetch-size=N: les workers récupèrent plusieurs messages par aller-retour (SQS, Redis XREADGROUP, Doctrine LIMIT, AMQP basic_get répété).
--no-reset=N: réinitialise les services tous les N messages au lieu d'un message par message ou jamais.
#[AsMessage(serializedTypeName: '...')]: en-tête de type personnalisé pour les consommateurs inter-applications/non-Symfony.
AmqpPriorityStamp : priorité RabbitMQ par message (AMQP uniquement).
BatchHandlerTrait::getIdleTimeout(): vide les lots partiels après la période d'inactivité.
PostgreSQL LISTEN/NOTIFY : l’attente bloquante a été déplacée vers l’abonné aux événements d’inactivité ; la consommation prioritaire multi-files d’attente a été corrigée.
Échecs de décodage : acheminés via des transports de nouvelle tentative/échec ; DecodeFailedMessageMiddleware réessaie le décodage à chaque tentative.
Interface ListableReceiverInterface de Redis : all() et find() via XRANGE pour la surveillance.
Option DSN redis_cluster=true : connexion à un cluster Redis à point de terminaison unique.
Files d'attente de délai de quorum AMQP : une file d'attente par jour avec expiration sécurisée.
queues: false / []: désactiver la liaison de file d'attente par défaut pour les transports AMQP en écriture seule.
Libération du verrou de déduplication : le verrou est libéré immédiatement en cas d’échec définitif (il n’est pas maintenu jusqu’à la durée de vie totale).

Pourquoi c'est important

Ces modifications corrigent les goulots d'étranglement en production : nombre d'allers-retours réseau par message, fuites d'état et impact sur les performances des processus de longue durée, suppression silencieuse des messages erronés en cas d'échec de décodage, et cas limites de la file d'attente de quorum RabbitMQ. L'harmonisation des noms de types entre les langages et la possibilité de lister les récepteurs Redis améliorent l'interopérabilité et l'observabilité.

Cas d'utilisation potentiels dans le monde réel

Vectorisation à haut débit ou intégration de workers avec --fetch-size=10 sur SQS.
Messages du pipeline d'IA (serializedTypeName: 'crawler.vectorization_finished') consommés par les services polyglottes.
Expédition prioritaire pour les tâches d'inférence urgentes via AmqpPriorityStamp.
Surveillance des messages en attente du flux Redis sans les consommer (zenstruck/messenger-monitor-bundle).
Récupération des messages après des déploiements qui interrompent temporairement la désérialisation.

Extraits de code importants

#[AsMessage(serializedTypeName: 'crawler.vectorization_finished')]
final readonly class VectorizationFinished
{
    public function __construct(public string $crawlId) {}
}

php bin/console messenger:consume async --fetch-size=8
php bin/console messenger:consume async --no-reset=100

Composants/packages Symfony associés

symfony/messenger
symfony/amqp-messenger
symfony/redis-messenger
symfony/doctrine-messenger
zenstruck/messenger-monitor-bundle (consommateur ListableReceiverInterface)

Commandes basées sur une méthode

Bref résumé

Symfony 8.1 permet d'utiliser plusieurs commandes console dans une même classe en appliquant #[AsCommand] à chaque méthode, au lieu d'une classe par commande. Les dépendances partagées du constructeur sont initialisées une seule fois ; chaque méthode annotée est enregistrée comme une commande indépendante par autoconfiguration. L'impact est modéré : il s'agit principalement d'une amélioration de l'expérience utilisateur pour les groupes d'opérations CLI liées.

Principaux changements techniques

#[AsCommand] sur les méthodes : chaque méthode devient une commande enregistrée distincte avec son propre nom et sa propre description.
Injection par constructeur partagé : une classe, un constructeur, plusieurs points d’entrée de commande.
Utilisation de la console autonome : enregistrez les méthodes en tant qu’objets appelables de première classe via $application->addCommand($instance->create(...)).
Tests : CommandTester accepte directement la méthode appelable.

Pourquoi c'est important

Réduit le code répétitif lorsque plusieurs commandes partagent le même dépôt, client API ou système de journalisation. Reprend les modèles Symfony existants (plusieurs actions de contrôleur par classe, plusieurs gestionnaires par classe). Impact architectural mineur, mais significatif pour la maintenabilité des applications utilisant fréquemment l'interface en ligne de commande.

Cas d'utilisation potentiels dans le monde réel

Groupes de commandes de gestion des utilisateurs (app:user:create, app:user:delete) partageant un dépôt.
Commandes de pipeline de données (app:import, app:validate, app:export) avec une infrastructure commune.
Outils d'IA/opérations avec sous-commandes associées (indexer, réindexer, purger) dans une seule classe de service.

Extraits de code importants

class UserCommands
{
    public function __construct(private UserRepository $users) {}

    #[AsCommand('app:user:create', description: 'Creates a new user')]
    public function create(OutputInterface $output): int
    {
        return Command::SUCCESS;
    }

    #[AsCommand('app:user:delete', description: 'Deletes an existing user')]
    public function delete(OutputInterface $output): int
    {
        return Command::SUCCESS;
    }
}

Composants/packages Symfony associés

symfony/console
symfony/framework-bundle (autoconfiguration)

Sérialiser l'attribut

Bref résumé

Symfony 8.1 introduit l'attribut de contrôleur #[Serialize], qui sérialise automatiquement la valeur de retour d'un contrôleur en une réponse HTTP avec le type de contenu, le code de statut et les en-têtes/contexte optionnels appropriés. Ceci élimine les injections répétées du Serializer et la construction manuelle de JsonResponse. L'impact se concentre sur l'ergonomie du développement d'API ; le comportement dépend du composant Serializer installé et configuré.

Principaux changements techniques

#[Serialize] sur les méthodes du contrôleur : renvoie un objet ou un tableau ; Symfony l’encapsule dans une réponse.
Format de la requête : dérivé du format de requête actuel (JSON par défaut) ; prend en charge la négociation de contenu via les routes .{_format}.
Personnalisation : options code, headers et context (par exemple DateTimeNormalizer::FORMAT_KEY).
Réponse 415 : renvoyée automatiquement lorsque le format demandé n’est pas pris en charge.

Pourquoi c'est important

Réduit le code répétitif des contrôleurs d'API et aligne les contrôleurs de valeurs de retour sur les modèles pilotés par attributs déjà utilisés pour le mappage des entrées et la mise en cache. Conserve le contexte de sérialisation au même endroit que la définition du point de terminaison.

Cas d'utilisation potentiels dans le monde réel

Points de terminaison d'API CRUD renvoyant des DTO sans appels manuels au sérialiseur.
API multiformats (JSON/XML) via des suffixes de format de route sur une seule méthode de contrôleur.
En-têtes de réponse cohérents (par exemple, en-têtes de traçage ou de versionnage personnalisés) déclarés au niveau de l'attribut.

Extraits de code importants

#[Serialize(code: 201, context: [DateTimeNormalizer::FORMAT_KEY => 'd.m.Y H:i:s'])]
public function __invoke(): ProductCreated
{
    return new ProductCreated(101);
}

Composants/packages Symfony associés

symfony/http-kernel (Attribut Serialize)
symfony/serializer
symfony/http-foundation (Réponse, négociation de contenu)

Améliorations de la traduction

Bref résumé

Symfony 8.1 apporte des améliorations progressives au système de traduction : prise en charge des paramètres régionaux via les variables d’environnement, correction de la traduction des espaces réservés dans les champs de choix étendus, logique de repli pour les paramètres régionaux extraits et prise en charge étendue du format XLIFF, notamment le module PGS pour le pluriel, le genre et les listes déroulantes. L’impact global est modéré et se limite aux applications à forte composante internationale (i18n) et aux intégrations de formulaires.

Principaux changements techniques

Variables d'environnement dans framework.enabled_locales: %env(LOCALE_N)% avec filtrage automatique des valeurs vides.
Correction de l'espace réservé pour les choix étendus : les champs étendus EntityType utilisent désormais translation_domain (et non choice_translation_domain) pour la traduction de l'espace réservé.
LocaleFallbackProvider : calcul de chaîne de repli réutilisable (computeFallbackLocales()) et fonction d'assistance validateLocale() extraite du traducteur.
Prise en charge de XLIFF 2.1 et 2.2 : numéros de version acceptés de manière transparente (structure compatible avec 2.0).
Module XLIFF PGS : le pluriel, le genre et certains attributs ont été convertis au format de message ICU et enregistrés dans le domaine +intl-icu.

Pourquoi c'est important

Les déploiements multi-locataires et multi-environnements permettent de configurer les paramètres régionaux sans fichier de configuration par environnement. La correction du paramètre d'espace réservé pour EntityType résout une incohérence persistante liée à Form/i18n. La prise en charge de XLIFF PGS assure la compatibilité de Symfony avec les outils de traduction modernes.

Cas d'utilisation potentiels dans le monde réel

Les plateformes SaaS permettent de définir différents ensembles de paramètres régionaux par locataire via des variables d'environnement.
Formulaires avec des espaces réservés pour les boutons radio/cases à cocher traduits sur les choix d'entités Doctrine.
Services partagés calculant des chaînes de repli de localisation cohérentes en dehors du traducteur.
Importation de fichiers XLIFF 2.2 avec règles de pluriel/genre à partir de plateformes de localisation externes.

Extraits de code importants

framework:
    enabled_locales:
        - '%env(LOCALE_1)%'
        - '%env(LOCALE_2)%'

$fallbacks = (new LocaleFallbackProvider(['en']))->computeFallbackLocales('es_AR');
// ['es_419', 'es', 'en']

Composants/packages Symfony associés

symfony/translation
symfony/form (EntityType, ChoiceType)
symfony/intl (Format de message ICU via le domaine +intl-icu)

Remarque : Faible impact sur les systèmes backend/asynchrones/IA, sauf si l’application a des exigences importantes en matière d’internationalisation ou de formulaires.

Améliorations du validateur

Bref résumé

Symfony 8.1 intègre une contrainte Xml, rend les validateurs de comparaison de dates sensibles à l'horloge pour des tests déterministes, introduit des vérifications strictes optionnelles des métadonnées de propriétés et refactorise les validateurs de contraintes pour les rendre réentrants via validateInContext(). Ces améliorations concernent principalement le composant Validator ; la contrainte XML et la prise en compte de l'horloge sont celles qui ont l'impact pratique le plus évident.

Principaux changements techniques

#[Assert\Xml]: valide le XML bien formé ; schemaPath optionnel pour la validation XSD avec des violations numérotées en ligne.
Validateurs de date prenant en compte l'horloge : GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual et Range résolvent les chaînes relatives (today, -18 years) par rapport à ClockInterface lorsqu'il est disponible.
Câblage automatique de FrameworkBundle : horloge injectée dans les validateurs déclarant ClockInterface dans le constructeur.
ValidatorBuilder::enablePropertyMetadataExistenceCheck(): validateProperty() / validatePropertyValue() lève une exception sur les noms de propriétés inconnus (détection de fautes de frappe).
Validateurs réentrants : nouvelle ConstraintValidatorInterface::validateInContext() ; les implémenteurs directs doivent migrer ; validate() et initialize() sont obsolètes.

Pourquoi c'est important

Élimine le code répétitif de validation XML personnalisé pour les flux SOAP, les sitemaps et les charges utiles de configuration. Les validateurs prenant en compte l'horloge permettent des tests unitaires fiables pour les contrôles d'âge, les fenêtres de réservation et les règles de délai. Les validateurs réentrants corrigent les bogues subtils dans la validation imbriquée (par exemple, CollectionValidator).

Cas d'utilisation potentiels dans le monde réel

Validation des flux XML tiers ou des réponses SOAP par rapport aux schémas XSD.
Règles de vérification de l'âge ou de la date de réservation testées avec MockClock.
Validation stricte des propriétés dans les générateurs de code ou les outils d'administration qui valident les objets partiels par nom de propriété.
Validation complexe des DTO imbriqués sans corruption de l'état du validateur.

Extraits de code importants

#[Assert\Xml(schemaPath: 'config/schemas/report.xsd')]
public string $validatedContent;

$validator = Validation::createValidatorBuilder()
    ->enablePropertyMetadataExistenceCheck()
    ->getValidator();

Composants/packages Symfony associés

symfony/validator
symfony/clock (MockClock, ClockInterface)
symfony/framework-bundle (câblage de l'horloge)

Remarque : La validation de la console #[MapInput] et #[Ask] (composant Console) réutilise les contraintes du validateur, mais est documentée séparément.

Conclusion

Symfony 8.1 confirme une évolution très intéressante de l'écosystème vers des architectures de plus en plus modulaires, asynchrones et orientées outils.

Au-delà des améliorations apportées à l'expérience utilisateur, plusieurs nouvelles fonctionnalités témoignent clairement d'un engagement à adapter Symfony aux cas d'utilisation modernes :

travailleurs de longue date,
pipelines de données,
systèmes distribués,
API avancées,
Outils CLI,
Traitement de gros volumes de JSON,
et les applications orientées orchestration.

Même si certaines fonctionnalités restent expérimentales ou ciblent des cas d'utilisation spécifiques, le tableau d'ensemble indique une direction cohérente pour les futures versions du framework.

J'ai également préparé une présentation technique SlideWire sur les nouvelles fonctionnalités de Symfony 8.1 :

Dépôt GitHub de SlideWire

Plus d'infos sur le blog symfony : https://symfony.com/blog/category/living-on-the-edge/8.1

🎤 Sunday Labs #4 : ce que l’écosystème builder parisien cherche vraiment

Mathieu Ledru — Tue, 26 May 2026 08:05:05 +0000

Le 24 mai dernier avait lieu la quatrième édition de Sunday Labs, organisée par Build Society chez Hexa (eFounders), à Paris.

Le format était simple : réunir des builders, fondateurs, freelances, profils tech et créateurs autour de discussions ouvertes, de présentations de projets et de networking.

Pas de keynote.
Pas de conférence descendante.
L’objectif était surtout de créer des échanges utiles entre personnes qui construisent déjà quelque chose.

Le sujet central : pourquoi Paris attire encore moins que d’autres écosystèmes tech ?

La première partie de l’événement tournait autour d’une question :

Que manque-t-il à Paris pour devenir un écosystème plus attractif pour les investisseurs et les entrepreneurs tech ?

Plusieurs thèmes sont revenus quasiment dans tous les groupes.

1. Le manque de lieux et de culture builder

Beaucoup ont évoqué l’absence d’espaces réellement pensés pour les builders :

hacker houses,
cafés orientés startup,
lieux ouverts tard,
espaces hybrides entre coworking et communauté.

L’idée revient souvent : à Paris, il existe des événements tech, mais peu d’endroits où les rencontres se font naturellement au quotidien.

Le parallèle avec San Francisco ou New York a été fait plusieurs fois, notamment sur la facilité à rencontrer d’autres personnes qui construisent.

2. La culture du risque reste différente

Autre sujet récurrent : la perception de l’échec.

Plusieurs participants ont expliqué qu’en France :

l’échec entrepreneurial reste stigmatisé,
l’administratif freine certains projets,
le cadre juridique et fiscal peut décourager des profils early-stage.

À l’inverse, l’écosystème américain est perçu comme plus tolérant au risque et plus agressif sur le financement.

3. Le sujet du marché américain

Des fondateurs présents ont aussi partagé leur expérience autour des États-Unis :

création de structures dans le Delaware,
recherche de financements US,
accès à un marché plus large,
valorisations plus élevées.

Un point intéressant : plusieurs personnes ont insisté sur le fait que les talents français existent déjà, mais que beaucoup de projets finissent par partir vers les US pour des raisons économiques et de distribution.

4. La langue et l’ouverture internationale

Des participants internationaux ont également souligné que :

la barrière linguistique reste réelle,
beaucoup d’événements restent très francophones,
Paris pourrait être plus accessible aux builders étrangers.

Le sujet n’était pas présenté comme un rejet du français, mais plutôt comme une question d’accessibilité dans un environnement tech mondial.

Branding, contenu et distribution : des sujets omniprésents

Une autre partie importante des échanges concernait le contenu et le personal branding.

Le constat partagé :

publier régulièrement reste l’un des meilleurs leviers pour trouver des clients, des associés ou des opportunités,
LinkedIn fonctionne toujours très bien pour le B2B,
Substack devient intéressant pour des niches plus techniques ou spécialisées.

Plusieurs participants utilisaient déjà :

des workflows IA pour écrire leurs posts,
des agents pour automatiser la publication,
des systèmes de veille et de génération de contenu.

Un point intéressant soulevé pendant la discussion :

le problème n’est pas forcément l’IA sur LinkedIn, mais le manque de profondeur de beaucoup de contenus.

Substack a été cité comme alternative plus qualitative pour développer des réflexions longues et toucher des audiences plus ciblées.

Les projets présentés pendant l’événement

Comme souvent dans ce type de format, la partie la plus intéressante restait les échanges autour des projets en cours.

Quelques exemples :

Un Agent OS grand public

Un participant travaillait sur une interface simplifiée autour d’OpenFlow avec l’idée suivante :

rendre les agents IA accessibles à des utilisateurs non techniques,
centraliser la “vie digitale” d’un utilisateur,
automatiser certaines tâches via des agents personnels.

Une plateforme de matchmaking social

Un autre projet portait sur le matchmaking relationnel appliqué aux événements.

L’idée :

utiliser des questionnaires autour des valeurs, émotions et profils,
créer des groupes pertinents pendant des événements,
faciliter les rencontres, notamment pour les profils introvertis.

Serend

Projet présenté comme un “réseau social anti-feed”.

Le principe :

une seule nouvelle rencontre tous les trois jours,
pas de scrolling,
pas de logique de visibilité,
uniquement des conversations entre profils compatibles.

Le positionnement était clairement orienté contre les mécaniques classiques des réseaux sociaux actuels.

Meetable

Plateforme de networking via des dîners en petit comité.

L’objectif :

connecter entrepreneurs, freelances et profils complémentaires,
favoriser des échanges plus qualitatifs,
créer des rencontres orientées compétences + compatibilité humaine.

Scraping LinkedIn et signaux d’intention

Un participant présentait aussi une infrastructure de scraping LinkedIn à grande échelle :

suivi des recrutements,
détection de changements dans les entreprises,
génération de signaux d’intention d’achat.

Le sujet a rapidement dérivé vers les limites techniques, le scraping, les datasets et les modèles commerciaux possibles.

Ce que montre ce type d’événement

Le point le plus intéressant de Sunday Labs #4 n’était probablement pas un projet précis.

C’était plutôt le niveau d’ouverture dans les discussions :

partage de problématiques réelles,
retours directs,
débats sur les modèles économiques,
échanges très early-stage.

On sent aussi une évolution du format des événements startup à Paris :

moins de conférences,
plus de discussions,
plus de petits groupes,
plus de projets en construction.

L’écosystème parisien manque peut-être encore de structure et de capital comparé aux US, mais il y a clairement une génération de builders qui cherche à créer ses propres formats, ses propres communautés et ses propres réseaux.

🧩 Un agent IA aujourd’hui, c’est un stagiaire hypermotivé avec 400 onglets ouverts.

Mathieu Ledru — Sat, 23 May 2026 07:40:44 +0000

Il répond vite.
Il a confiance en lui.
Il sait utiliser Gmail, Slack, Notion, GitHub, Linear, le terminal, et parfois même Docker.

Et pourtant, dès qu’on lui donne une tâche un peu longue, tout commence à partir en vrille.

Pas parce que le modèle est mauvais.

Parce que le système autour est chaotique.

Le fantasme actuel des agents

La démo est toujours la même :

“Regarde, mon agent peut réserver un vol, envoyer un mail, créer un ticket Jira et déployer en production.”

Techniquement, oui.

Mais dans la réalité, la plupart des agents ressemblent à ça :

ils ouvrent trop d’outils
oublient le contexte initial
exécutent des actions dans le mauvais ordre
hallucinent des états intermédiaires
improvisent quand ils ne savent pas
et surtout : ils ne savent pas quand s’arrêter.

Le problème n’est plus :

“est-ce que le modèle sait faire ?”

Le problème devient :

“comment est-ce qu’on orchestre proprement ses actions ?”

Les LLM sont forts. Les systèmes autour beaucoup moins.

ChatGPT, Claude, Gemini ou Qwen sont capables de :

résumer des documents
écrire du code
comprendre du langage naturel
raisonner sur plusieurs étapes
manipuler des outils.

Mais un agent, ce n’est pas juste un LLM.

C’est :

LLM
+ mémoire
+ outils
+ permissions
+ orchestration
+ validation
+ logs
+ contraintes
+ checkpoints humains

Et aujourd’hui, la plupart des stacks IA ressemblent encore à :

“brancher plein d’APIs ensemble et espérer que ça marche.”

L’orchestration est devenue le vrai problème

Imagine un orchestre sans chef.

Les musiciens sont excellents individuellement :

très bons violons
très bonne batterie
très bons cuivres.

Mais personne ne décide :

du tempo
des entrées
des transitions
des priorités
de la fin.

Résultat :
ça fait du bruit.

C’est exactement ce qui se passe quand on empile :

prompts
tools
MCP servers
APIs
agents autonomes
workflows
memory systems sans définir :
qui décide quoi
dans quel ordre
avec quel droit de veto
et avec quelles limites.

L’autonomie sans contraintes produit surtout du chaos

Un agent IA sans garde-fous, c’est rarement “Jarvis”.

C’est plutôt :

un alternant qui a accès à la prod
sans checklist
sans supervision
sans notion du risque
avec énormément de confiance.

Le plus dangereux n’est pas qu’il se trompe.

Le plus dangereux, c’est que :

ses erreurs ont souvent l’air plausibles.

Il répond avec assurance.
Il génère des plans crédibles.
Il explique ses décisions.

Même quand il invente complètement.

Ce qu’on appelle “agent”, aujourd’hui

Beaucoup de systèmes “agents” actuels sont en réalité :

des boucles de prompts
des wrappers d’outils
des routers
des chaînes d’appels.

Très peu possèdent réellement :

une mémoire stable
une hiérarchie de décisions
une stratégie
une capacité d’arrêt
une gestion claire des permissions
une orchestration déterministe.

On a énormément travaillé l’intelligence brute.

Pas assez :

le contrôle
la coordination
la supervision
la traçabilité.

Le vrai scaling de l’IA n’est peut-être plus le modèle

Pendant des années, le scaling de l’IA consistait surtout à :

augmenter les paramètres
augmenter le compute
augmenter les datasets.

Mais le prochain problème ressemble davantage à :

“comment coordonner correctement des systèmes probabilistes.”

Autrement dit :

orchestration
runtime
mémoire
vérification
hiérarchie
contraintes
auditabilité.

Le modèle devient presque :

un composant parmi d’autres.

Construire un agent utile ressemble plus à construire une organisation

Un bon système agentique ressemble moins à :

“une IA omnisciente”

et davantage à :

“une équipe bien encadrée”.

Avec :

rôles séparés
limites claires
validation humaine
journaux d’actions
budgets
règles d’arrêt
supervision
retry contrôlé
sandboxing.

Le problème n’est pas seulement cognitif.

Il est organisationnel.

De la génération de texte à la génération de processus

Le vrai shift est peut-être là.

Les premiers LLM généraient :

du texte
du code
des images.

Les prochains systèmes généreront :

des workflows
des plans
des décisions
des exécutions
des pipelines complets.

Et plus ces systèmes deviennent autonomes, plus :

l’orchestration
les contraintes
les garde-fous
et la traçabilité

deviennent critiques.

Construire Toutouexplique

Ce week-end, on a construit un moteur Symfony capable de transformer :

un sujet YAML
une structure narrative
une grammaire de style
des contraintes de rendu

en :

voix
images
scènes
vidéo finale
article.

Le plus intéressant n’était pas la génération elle-même.

Le plus intéressant était :

la formalisation de la structure.

On ne cherchait pas à copier un créateur.

On cherchait à comprendre :

son rythme
sa densité
sa structure narrative
sa compression d’information
son pacing.

Autrement dit :

transformer une grammaire implicite en système exécutable.

Le futur du contenu IA sera structurel

Aujourd’hui, presque tous les outils IA savent générer du contenu.

Le vrai différenciateur devient :

le format
le rythme
l’orchestration
la cohérence
la structure.

Pas seulement :

“est-ce que le modèle est intelligent ?”

Mais :

“est-ce que le système sait se coordonner ?”

Et ça vaut autant pour :

les agents IA
les pipelines vidéo
les systèmes autonomes
que pour les organisations humaines.

Faut doser

Un agent utile n’est pas forcément le plus autonome.

C’est souvent :

celui qui possède les meilleures limites
les meilleures validations
la meilleure orchestration
et le moins d’onglets ouverts.

L’intelligence brute aide.

Mais sans structure :
on ne scale pas l’intelligence.

On scale juste le chaos plus vite.

⬆️ Flowvox update : Symfony devient une plateforme d’agents vocaux temps réel

Mathieu Ledru — Mon, 18 May 2026 07:21:52 +0000

En février 2026, j’avais publié un premier prototype expérimental autour de la transcription vocale en PHP avec Whisper.cpp.

https://blog.darkwood.com/article/i-m-building-a-dictation-engine-in-php-flow-symfony-whisper-cpp

L’objectif était simple :

enregistrer sa voix, la retranscrire localement, puis exporter le résultat.

Trois mois plus tard, le projet a énormément évolué.

Flowvox n’est plus seulement un POC console.

C’est désormais une plateforme de workers vocaux temps réel construite avec Symfony 8, Messenger, Mercure, Symfony UX, OpenAI Realtime et Hotwire Native.

Pourquoi cette mise à jour maintenant ?

La raison est très simple : OpenAI vient de faire évoluer massivement son API audio temps réel.

Dans leur démonstration récente, plusieurs nouveautés ont été présentées :

traduction multilingue temps réel
transcription fluide en streaming
agents vocaux capables d’appeler des tools
raisonnement en arrière-plan
conservation du contexte conversationnel.

Ce n’est plus simplement de la reconnaissance vocale.

La voix devient une interface programmable.

Et c’est précisément la direction dans laquelle Flowvox évolue.

Le prototype initial : Whisper.cpp + terminal

La première version de Flowvox était extrêmement minimaliste.

Architecture :

Microphone
→ ffmpeg
→ whisper.cpp
→ transcription locale

Le système fonctionnait entièrement en ligne de commande :

php bin/console voice:start
php bin/console voice:stop
php bin/console voice:worker

Il n’y avait :

aucune UI
aucun temps réel
aucune orchestration distribuée
aucune notion de session.

L’objectif était uniquement de valider qu’il était possible de faire de la transcription locale en PHP avec Whisper.cpp.

Passage à une architecture distribuée

La nouvelle version change complètement de philosophie.

Le cœur du système repose maintenant sur :

Symfony Messenger
darkwood/flow
Mercure
Doctrine
Symfony UX
providers de transcription interchangeables.

Architecture simplifiée :

flowchart LR
    UI["Symfony UX"]
    MQ["Messenger"]
    W["Voice Worker"]
    F["Flow Pipeline"]
    OAI["OpenAI Realtime"]
    WC["Whisper.cpp"]
    M["Mercure"]

    UI --> MQ
    MQ --> W
    W --> F
    F --> WC
    F --> OAI
    W --> M
    M --> UI

Le point important :

le worker n’est pas l’interface.

L’UI ne fait que piloter des workers vocaux indépendants.

Chaque session possède sa propre queue Messenger :

voice_demo
voice_mobile
voice_conference
voice_stream

Cela permet d’avoir :

plusieurs workers
plusieurs appareils
plusieurs sessions simultanées
une architecture distribuée.

Flow orchestration

Le pipeline repose toujours sur Darkwood Flow.

Trois étapes principales :

Étape	Rôle
InputProviderFlow	Lecture des événements START / STOP
RecorderFlow	Enregistrement audio
TranscribeFlow	Transcription

Le worker reste long-running et écoute les événements Messenger.

Lorsqu’un START est reçu :

le worker démarre l’enregistrement
ffmpeg capture l’audio
la session est suivie
les événements sont publiés via Mercure.

Lorsqu’un STOP est reçu :

le fichier WAV est finalisé
la transcription démarre
l’UI reçoit les mises à jour.

Symfony UX + Mercure : le temps réel

Une des plus grosses évolutions du projet est l’arrivée d’une vraie interface web temps réel.

Stack utilisée :

Twig
Symfony UX
Turbo
Stimulus
Mercure.

Le dashboard permet maintenant :

de voir les workers actifs
de démarrer/arrêter une session
de suivre les événements live
d’afficher les transcriptions
d’accéder à l’historique.

Architecture temps réel :

sequenceDiagram
    participant Worker
    participant Mercure
    participant Browser

    Worker->>Mercure: publish event
    Mercure->>Browser: live update
    Browser->>UI: refresh transcript

L’intérêt est énorme :

Symfony peut maintenant faire du temps réel moderne sans React ni frontend séparé.

Providers de transcription

Une autre évolution importante est l’introduction d’une couche DDD avec providers interchangeables.

Flowvox peut maintenant fonctionner avec plusieurs moteurs :

Provider	Type
whisper_cpp	Local
whisper_cpp_stream	Local realtime
openai_batch	Cloud batch
openai_realtime_whisper	Cloud realtime

La sélection se fait via une variable d’environnement :

FLOWVOX_TRANSCRIPTION_PROVIDER=

Le moteur peut changer.

L’UX reste identique.

OpenAI Realtime Whisper

C’est probablement la nouveauté la plus importante.

Avant :

START
→ parler
→ STOP
→ transcription

Maintenant :

START
→ streaming audio
→ transcription live
→ partials
→ UI temps réel

Le fonctionnement :

flowchart LR
    MIC["Micro"]
    FFMPEG["ffmpeg"]
    WS["WebSocket OpenAI"]
    WORKER["Worker"]
    MERCURE["Mercure"]
    UI["Symfony UX"]

    MIC --> FFMPEG
    FFMPEG --> WS
    WS --> WORKER
    WORKER --> MERCURE
    MERCURE --> UI

Le worker envoie les chunks audio à OpenAI Realtime via WebSocket.

Le modèle retourne des transcriptions partielles.

Le worker publie ensuite ces événements vers Mercure.

Et Symfony UX met à jour l’interface en direct.

Traduction multilingue temps réel

OpenAI introduit aussi GPT Realtime Translate.

Cela permet :

de parler en français
de traduire en anglais
ou même de changer dynamiquement de langue pendant la conversation.

Le modèle suit la structure de la phrase et attend parfois les verbes avant de traduire, ce qui rend le résultat beaucoup plus naturel.

C’est extrêmement intéressant pour :

conférences
podcasts
support client
éducation
médias.

Symfony UX Native + iOS

Autre grosse évolution : l’intégration native mobile.

Flowvox utilise maintenant :

composer require symfony/ux-native

L’idée est de conserver :

Twig
Symfony UX
Turbo
Stimulus

tout en utilisant un shell mobile natif basé sur Hotwire Native.

Architecture :

flowchart LR
    Twig --> Turbo
    Turbo --> WebView
    WebView --> SwiftUI
    Stimulus --> NativeBridge

L’application iOS repose sur une WebView connectée au serveur Symfony local.

Le résultat :

même application
même backend
même UI
version web + version native.

Darkwood Navi : traçabilité des workflows

Flowvox intègre aussi Darkwood Navi.

L’objectif :

enregistrer les événements
suivre les exécutions
tracer les workflows
rendre les traitements reproductibles.

Cela prépare surtout les prochaines étapes :

agents vocaux
tool calling
workflows déclaratifs
orchestration IA.

Vision long terme

Flowvox n’est plus seulement un moteur de transcription.

La direction devient beaucoup plus ambitieuse :

une plateforme vocale programmable pour Symfony.

Les prochaines étapes :

GPT Realtime Translate
agents vocaux
tool calling
orchestration Flow
workflows Navi
intégration Uniflow
automation pilotée par la voix.

L’objectif n’est plus simplement :

“parler à son application”.

Mais plutôt :

“avoir une application qui réagit, raisonne et agit en temps réel à travers la voix”.

Conclusion

En quelques mois, Flowvox est passé :

d’un POC terminal Whisper.cpp
→ à une plateforme vocale temps réel Symfony

Avec :

workers distribués
orchestration Flow
Symfony UX
Mercure
OpenAI Realtime
Hotwire Native
providers interchangeables
traçabilité Navi.

La voix devient progressivement une interface programmable.

Et je pense que Symfony possède aujourd’hui toutes les briques nécessaires pour devenir une excellente plateforme pour ce type de systèmes.

Flowvox continue d’évoluer comme terrain d’expérimentation autour :

des workers vocaux
de l’orchestration temps réel
des agents pilotés par la voix
de Symfony UX
de Symfony AI
et des workflows déclaratifs avec Flow et Navi.

L’objectif n’est plus simplement de retranscrire de l’audio.

L’objectif est maintenant de construire des interfaces vocales programmables capables :

d’écouter
de raisonner
de traduire
et d’agir dans des systèmes externes en temps réel.

Ressources

Tu peux ajouter cette section à la fin de l’article.

Ressources & projets

Le code source et les expérimentations autour de Flowvox sont disponibles publiquement :

Technologies utilisées :

Annonces et documentation OpenAI :

⚙️ NoLife Models - Vers une infrastructure locale des runtimes IA avec Symfony

Mathieu Ledru — Thu, 14 May 2026 07:14:53 +0000

Pendant des années, utiliser un modèle IA voulait dire appeler une API distante.

Le workflow était relativement simple :

envoyer un prompt
attendre une réponse
afficher du texte.

Mais depuis quelques mois, un nouvel écosystème est en train d’émerger autour des modèles locaux.

Un écosystème composé de :

catalogues de modèles
runtimes locaux
systèmes de benchmark
exports structurés
observabilité
gouvernance
orchestration.

Et progressivement, l’IA commence à ressembler davantage à une infrastructure logicielle qu’à un simple chatbot.

C’est dans ce contexte qu’est né *NoLife Models- :

Un projet Symfony 8 conçu pour explorer cette nouvelle couche d’infrastructure locale autour des modèles IA.

Le problème : les modèles locaux explosent

Aujourd’hui, il existe une quantité gigantesque de modèles :

Qwen
Llama
Granite
Gemma
Mistral
Phi
DeepSeek
etc.

Et chacun possède :

des tailles différentes
des quantizations différentes
des capacités différentes
des context windows différents
des comportements différents.

Le problème n’est donc plus :

“Comment utiliser un modèle ?”

Mais plutôt :

“Quel modèle utiliser, dans quel contexte, sur quel runtime, avec quelles performances ?”

models.dev : vers un catalogue standardisé des modèles

Un projet particulièrement intéressant dans cette évolution est :

models.dev

L’idée est simple :
transformer les modèles en objets structurés exploitables par des outils.

On ne parle plus seulement d’un “nom de modèle”.

On parle désormais de :

modalities
reasoning flags
pricing
capabilities
context windows
providers
compatibilité runtime.

Cela ressemble fortement à ce qu’a représenté Docker Hub pour les containers.

modles : explorer les modèles comme des artefacts logiciels

Autour de cette idée émergent aussi des interfaces d’exploration comme :

modles

Le sujet devient alors :

filtrer
comparer
explorer
comprendre les capacités réelles des modèles.

Exactement comme nous avons commencé à le faire avec :

containers
packages
runtimes cloud
images OCI.

Docker ecosystem ↔ AI runtime ecosystem

L’analogie avec Docker devient de plus en plus pertinente.

Docker ecosystem	AI runtime ecosystem
Docker Hub	models.dev
Images	GGUF / model weights
dockerd	Ollama / Kronk / vLLM
Kubernetes	agent orchestration
Observability	inference tracing
OCI runtime	runtime abstraction layers

Le sujet n’est donc plus seulement :

“faire tourner un LLM”.

Le sujet devient :

“gouverner une infrastructure de modèles.”

Ollama : le runtime HTTP local

Le runtime qui a probablement démocratisé cette approche est :

Ollama

Ollama expose les modèles comme des services HTTP locaux.

Quelques endpoints suffisent :

/api/tags
/api/generate
/api/chat

Et immédiatement :

n’importe quelle application
n’importe quel langage
n’importe quel orchestrateur

peut commencer à interagir avec des modèles locaux.

Cette simplicité est extrêmement puissante.

NoLife Models

C’est précisément ce constat qui a motivé la création de :

NoLife Models

NoLife Models est une application locale construite avec :

Symfony 8
Symfony UX
Twig
Live Components
Turbo
HttpClient

Le projet permet :

d’explorer un catalogue de modèles
de lister les modèles Ollama installés
de comparer plusieurs modèles
de lancer des benchmarks
d’exporter les résultats.

Une architecture orientée runtime

Le point central du projet est probablement cette abstraction :

interface LocalModelRuntimeInterface
{
    /*- @return list<LocalModel> */
    public function listLocalModels(): array

    public function generate(
        GeneratePromptCommand $command
    ): ModelInferenceResult
}

Cette décision transforme complètement l’architecture.

Le domaine ne dépend plus :

d’Ollama
d’OpenAI
d’un provider particulier.

Le domaine dépend uniquement :

d’un contrat d’inférence.

Et cela ouvre immédiatement la voie vers :

LM Studio
vLLM
OpenAI-compatible runtimes
embedded runtimes
futurs adapters.

Symfony 8 + Hexagonal Architecture

Le projet suit une approche DDD / hexagonale.

UserInterface
    ↓
Application
    ↓
Domain ports
    ↓
Infrastructure adapters

Les responsabilités sont séparées :

Layer	Role
Domain	contracts + models
Application	orchestration
Infrastructure	Ollama adapter, exports
UserInterface	Symfony UX + controllers

Le runtime devient alors une simple implémentation d’interface.

Comparer des modèles localement

L’un des éléments les plus intéressants du projet est le moteur de comparaison.

Même prompt.
Même runtime surface.
Même configuration.

Mais plusieurs modèles.

Cela permet de comparer :

latence
temps de chargement
vitesse de génération
raisonnement
qualité des réponses
hallucinations
OCR
vision.

Le plus important :

les benchmarks mathématiques seuls ne suffisent pas.

La qualité reste une lecture humaine.

Benchmarks et reproductibilité

Le projet permet également de lancer des benchmark suites.

L’idée :

exécuter plusieurs prompts
sur plusieurs modèles
avec des paramètres contrôlés
et produire des résultats structurés.

Cela rapproche progressivement le projet :

d’un système d’évaluation
d’un observatoire runtime
d’une couche d’observabilité.

Exports et gouvernance

Les exports jouent un rôle très important :

JSON
CSV
Markdown

Parce qu’une inférence sans artifact devient difficile à auditer.

Les exports permettent :

de tracer
reproduire
comparer
archiver
analyser.

Et c’est précisément à ce moment que l’on quitte le simple “prompt engineering”.

Kronk : une autre direction

Un autre projet particulièrement intéressant est :

Kronk

Kronk ne doit pas être vu comme :

“un meilleur Ollama”.

La philosophie est différente.

Ollama expose les modèles comme des services HTTP locaux.

Kronk pousse l’inférence directement dans le processus applicatif.

L’inférence devient alors :

embarquée
programmable
intégrée au runtime de l’application.

Avec :

GGUF
llama.cpp
Yzma
streaming
APIs compatibles OpenAI.

Le modèle cesse progressivement d’être un simple endpoint HTTP.

Il devient :

une dépendance logicielle.

Vers une infrastructure IA locale

Le plus intéressant dans cette évolution,
c’est probablement que l’on voit réapparaître les mêmes patterns que dans le cloud :

catalogues
runtimes
observabilité
orchestration
policies
exports
traces
gouvernance.

Mais appliqués cette fois :
à l’inférence locale.

Conclusion

NoLife Models n’est pas conçu comme :

un chatbot
un wrapper OpenAI
une simple UI Ollama.

Le projet explore plutôt une question plus large :

À quoi ressemble une infrastructure locale de runtimes IA ?

Avec :

catalogues
runtimes
benchmarks
exports
observabilité
abstractions runtime.

Nous sommes probablement encore au début de cet écosystème.

Mais les primitives commencent déjà à apparaître.

Et cela devient extrêmement intéressant à observer.

Depots github

🐙 An open-source database of AI models. : https://github.com/anomalyco/models.dev
☺️ Your personal engine for running open source models locally : https://github.com/ardanlabs/kronk

Sources

🚀 J’ai créé une app pour comparer vos LLM en local avec Ollama. : https://www.youtube.com/watch?v=YzxE3jQqItI
🧩 Extract Insights from Videos with Docling + OpenRAG : https://www.youtube.com/watch?v=Y0b1TANWZ-Y
🤯 AI Model explorer based on models.dev : https://github.com/dgageot/modles
😮 Baby steps with Kronk https://k33g.hashnode.dev/baby-steps-with-kronk-1
😋 How to cook a little coding agent with Docker Model Runner and Docker Agent (and sbx) https://k33g.org/20260419-little-coder-agent.html
😍 fabpot Activity https://github.com/symfony/models-dev/commits?author=fabpot

🔗 Liens de la semaine

Symfony Level Up #9 Sylvain Blondeau : https://symfonylevelup.substack.com/p/symfony-level-up-9
Les géants US vont toujours plus loin (trop ?) et la Chine montre la voie : https://www.youtube.com/watch?v=L4LCSXvA7LU
Oussama Pour la suppression massive d’emplois ! https://www.youtube.com/watch?v=GLfPVWRns-U
De 0 à 10 000€/mois avec l'IA : la méthode exacte que j'aurais voulu avoir : https://www.youtube.com/watch?v=sRtQmFEhlBE
Fouloscopie Comment discuter efficacement ? https://www.youtube.com/watch?v=8J1opDS1otY
MACI #158 - Découvrez CKE, notre Kubernetes managé - Avec Antoine Blondeau et Gilles Biannic : https://www.youtube.com/watch?v=FtAF5kN_8pY
Github Open Source Friday with Spec-Kit : https://www.youtube.com/watch?v=2IArMAhkJcE
Generate Images Locally with Docker Model Runner and Open WebUI https://www.docker.com/blog/blog-generate-images-locally-dmr-open-webui/
Commissariat au Numérique de Défense - DEF'LAN 2026 | LE DIRECT : https://www.youtube.com/watch?v=OW4VCl6P-l4
Why TTS Models Now Look Like LLMs — Samuel Humeau, Mistral : https://www.youtube.com/watch?v=3jGAU2sbAyY
Give Your Chat Agent a Voice — Luke Harries, ElevenLabs : https://www.youtube.com/watch?v=DCZZ3AJKzuc
Voice AI: when is the "Her" moment? — Neil Zeghidour, Gradium AI : https://youtu.be/P_RI1kCkRbo?is=w2jQToL-6ua941SI
Context Is the New Code — Patrick Debois, Tessl : https://www.youtube.com/watch?v=bSG9wUYaHWU
Here’s one of the engineers explaining how they use LLMs to generate $30B+ every year : https://x.com/thejayden/status/2052847766754250815?s=46
Pourquoi même la logistique légendaire d’Apple ne résiste pas à la RAMpocalypse | OctogoneTech #8 : https://www.youtube.com/watch?v=gjYbOViRy_k
La France peut-elle encore créer des géants de la tech ? (Avec Carlos Diaz) : https://www.youtube.com/watch?v=74TpWDkYpdE
Suraj vs The Future | With ChatGPT : https://www.youtube.com/watch?v=bMmEEa8-6fU
The 3 Most Important Claude Features Beginners Don’t Know About : https://www.youtube.com/watch?v=tkpdPvx65A0
How to Improve Video Streaming in Next.js - Adaptive Bitrate Streaming Tutorial | ImageKit : https://www.youtube.com/watch?v=MKbdkWfVZ1w
Des skills pour agents IA spécialisés dans la bureaucratie française : https://github.com/romainsimon/paperasse
Building a Chess Coach — Anant Dole and Asbjorn Steinskog, Take Take Take : https://www.youtube.com/watch?v=FlzpEGHNVKQ
Devenir Product Builder no code & IA avec Uncode School : https://www.youtube.com/watch?v=8Ikwj_SNSNI
Anthropic vient d'enterrer l'IA généraliste (et personne ne l'a vu) : https://www.youtube.com/watch?v=qqhQDBClm1Y
Your Agent Can Now Train Models — Merve Noyan, Hugging Face : https://www.youtube.com/watch?v=OV56RddyFuU

🎶 Music credit

A little footwork from New York New Jersey. ⚽ #FIFAWorldCup : https://vm.tiktok.com/ZNRGDjFGx/

@fifaworldcup A little footwork from New York New Jersey. ⚽ #FIFAWorldCup ♬ sonido original - FIFA World Cup

Chinese students welcome President Trump to the Great Hall of the People in Beijing 💐 🎥: @MargoMartin47

Chinese students welcome President Trump to the Great Hall of the People in Beijing 💐

🎥: @MargoMartin47 pic.twitter.com/wChlpVnphh
— Rapid Response 47 (@RapidResponse47) May 14, 2026

💫 I forced 4 AIs to recreate Mario from scratch using Symfony AI and Godot

Mathieu Ledru — Sat, 09 May 2026 07:47:30 +0000

Creating a video game with artificial intelligence has become almost commonplace.

Today, all you need to do is open Cursor, Claude Code or ChatGPT and type:

“Create me a Mario.”

And a few minutes later, something appears on the screen.

But behind this apparent simplicity lies a much more interesting problem:

How to properly orchestrate multiple AI agents to produce a coherent, playable, and maintainable result?

That's precisely what I wanted to experiment with in this video:

ChatGPT
Claude
Gemini
Grok

Even prompt.
Same objective.
Completely different results.

But above all: a completely different architecture from what is called “vibe coding” today.

An inspiration from Playdate

Before even talking about AI, we need to talk about video games.

In the video, I quickly show the Playdate, a small independent console developed by Panic with a black and white screen and a mechanical crank.

What's interesting about the Playdate isn't the power.

That's the philosophy.

The equipment imposes constraints:

limited screen
minimalist controls
simple gameplay
maximum creativity

And paradoxically, these constraints make the games more interesting.

It's exactly the same phenomenon with AI agents.

A vague prompt often results in a fragile system.

Well-defined constraints produce much more consistent results.

The Single Prompt Problem

Most AI demonstrations work like this:

Create a Mario game

The model then attempts to:

generate the gameplay
handle collisions
create the graphics
balance the levels
produce the mechanics
organize the project

The result is often impressive for a few seconds.

Then appear:

broken collisions
impossible levels
inconsistent rules
contradictory mechanisms
an immediate technical debt

The problem is not necessarily AI.

The problem is that he is being asked to do everything simultaneously without specialization.

Symfony AI + Godot

For this experiment, I used two main technologies:

Symfony AI

Symfony AI provides:

the agents
the tools
multimodal
the RAG
memory
multi-agent orchestration

The framework is divided into several specialized bundles:

Agent
Store
AI Bundle
Platform
App

The goal is to build a clean architecture around AI models rather than simply sending prompts.

Godot

Godot Engine

Godot is an open-source game engine extremely well-suited for rapid prototyping:

2D
3D
scene system
GDScript scripting
nodal architecture
multi-platform export

The idea was simple:

Orchestrate AI agents with Symfony AI to automatically generate a Godot game.

Multi-agent orchestration

The core of the project is based on a multi-agent architecture.

Instead of having a single AI that does everything, I separated the responsibilities.

The Orchestrator

The orchestrator receives the main prompt:

Generate a Mario-like platformer

Then it automatically delegates to the appropriate specialized agents.

Specialized agents

Layout Agent

The “level designer”.

It generates:

the platforms
the holes
the pipes
the stairs
the progression of the level

Gameplay Agent

The mechanics specialist.

He manages:

collisions
the enemies
the bonuses
the jumps
the checkpoints
the interactions

Godot Export Agent

The role of this agent is to transform the generated data into structures compatible with Godot:

scenes
TileMaps
objects
JSON exports

QA Agent

The most important thing.

The QA Agent verifies:

the gameplay
collisions
impossible jumps
the consistency of the mechanics
the rules of the level

This is probably the element most lacking in “vibe coding” demos.

The orchestration with Darkwood Flow and Navi

To orchestrate all of this, I use:

Flow allows you to manage the execution of multi-agent workflows.

Navi allows:

traceability
observability
routing
monitoring of executions

The pipeline looks like this:

User Prompt
    ↓
Orchestrator
    ↓
Layout Agent
Gameplay Agent
Godot Export Agent
QA Agent
    ↓
Generated Game

The orchestrator automatically chooses which agent should intervene depending on the progress of the system.

A single Symfony command

The entire generation process is launched with a simple Symfony command:

php bin/console app:mario:orchestrate

This order:

calls the orchestrator
Route to the specialist agents
generates the result
Automatically exports the game

The most interesting thing:
The pipeline becomes reproducible.

The results

ChatGPT

ChatGPT produces a very good database quickly.

We find:

a faithful structure
consistent gameplay
a rapid iteration

The result is strongly reminiscent of the old Mario Game Boy games.

The main advantage:
the speed of prototyping.

Claude

Claude produces something more graphically detailed.

The activities:

are more fluid
more modern
sometimes more ambitious

The reasoning seems more structured.

But we also feel more creative freedom compared to remaining faithful to the original.

Gemini

Gemini is probably the most visually interesting.

We find:

more modern graphics
better art direction
greater inventiveness

The gameplay also seems more refined in certain aspects.

There's a more "Nintendo-like" approach.

Grok

Grok is the most unpredictable.

He takes more initiative:

level selection
scoring system
graphic variations
new gameplay approaches

But it also deviates further from the original Mario.

The real subject is not Mario

This project was ultimately just a pretext.

The real issue lies elsewhere:

The future of AI development lies in orchestration.

A single agent can produce a prototype.

But several specialized agents can produce:

systems
pipelines
workflows
coherent architectures

And most importantly:
reproducible results.

The future of vibe coding

Current “vibe coding” often relies on:

a huge prompt
a single AI
many hallucinations
little validation

The next step is probably:

specialized agents
explicit constraints
tests
QA loops
observability
of the orchestration

In other words:

The future of vibe coding is orchestration.

Source code

Matyo91: matyo91/mario-orquestration: https://github.com/matyo91/mario-orquestration
ChatGPT: yoloyee1/SMB-clone-made-by-Godot: https://github.com/yoloyee1/SMB-clone-made-by-Godot
Claude: Axelrpg/Super-Mario-Bros-Godot: https://github.com/Axelrpg/Super-Mario-Bros-Godot
Gemini: charpurrr/SuperMarioSolarEngine: https://github.com/charpurrr/SuperMarioSolarEngine
Grok: wchen02/platformer: https://github.com/wchen02/platformer

Resources

Presentation slides: https://github.com/matyo91/slidewire
Symfony Multiagent: https://github.com/symfony/ai/blob/main/examples/multi-agent/orchestrator.php
Symfony AI
Godot Engine
Playdate

Links of the week

LIVE 1/5 LIBERTY WEBI OPEN HOUSE - THE AI SHORTCUT: https://www.youtube.com/live/L0H-rgqf7zI?is=1mc0YgZAxwjABKay
Eve of the week of May 4, 2026 Guillaume Loulier: https://guikingone.substack.com/p/veille-de-la-semaine-du-4-mai-2026
How MrBeast Works 18 Hours Per Day https://youtu.be/wPeUb2SVmEc?is=psItbJ2YNJFjVHiq
Richest People in the World (1900-2026) - From Rockefeller to Musk: https://m.youtube.com/watch?v=5h_vKrHzRvg&is=M9gch9O_AuqDTiKe
Day 287 growing my SaaS startup to $1M: https://m.youtube.com/watch?v=7aQ01ZKysl8&is=tdQGj8GddnmVH5sQ
ANDREJ KARPATHY JUST DECLARED THE END OF PROGRAMMING AS YOU KNOW IT. https://x.com/neil_xbt/status/2049687182336541013?s=46
How France's biggest pirate site was taken down: https://youtu.be/ULTV6T6jRTw?is=F9k6GcMNll0IfjZo Japan has just made a major decision: https://youtu.be/n_Kfco-kuFY?is=TBrMM-XdMTeE0qGR
check: Remove use of subtyping for monads: https://github.com/Gabriella439/grace/pull/261
Agentic Search for Context Engineering — Leonie Monigatti, Elastic: https://www.youtube.com/watch?v=ynJyIKwjonM
FLUX, open research and the future of visual AI — Stephen Batifol, Black Forest Labs: https://www.youtube.com/watch?v=x8Yb4RidLgM
How the Transformers finally devoured vision – Isaac Robinson, Roboflow: https://www.youtube.com/watch?v=VhfAVA3BG2I
This 50-minute lecture by Jeff Bezos will teach you more about business than a 2-year MBA program: https://x.com/Alokkumarzz/status/2049882855170588755?s=20
This lecture from Massachusetts Institute of Technology breaks down wealth, compounding, and long-term thinking in a way most financial advice never does: https://x.com/allen_explains/status/2049857599919825252?s=46
Stanford just taught the entire thing in a 1-hour lecture. For Free. https://x.com/codewithimanshu/status/2051240758125252872?s=46
this 2-hour Stanford lecture on AI careers. It will teach you more about winning in the AI race than all the AI content you've scrolled past this year. https://x.com/radha_ai/status/2051617864617263397?s=46
Peter Thiel gave a 1-hour class on how to create a monopoly starting from 0. https://x.com/indutripat82427/status/2051709170618098065?s=12
In this 24-minute session, Cherny outlines a future that is already his daily reality: https://x.com/datachaz/status/2051770066912379309?s=12
Radha Tripathi on X: "Claude FULL COURSE 1 HOUR (Build & Automate Anything) https://t.co/gg81I06To0" /
A Stanford University lecture taught the way engineers are actually trained to think about AI systems. You understand the why, every prompt you write, every system you design, and every agent you build operates from a completely different mental model. https://x.com/cyrilxbt/status/2049690838972723503?s=46 -Sam Altman. Dustin Moskovitz. The first lecture of the most influential startup course ever recorded. https://x.com/neil_xbt/status/2050411454830907898?s=46
OpenAI's own engineers just showed how to actually use OpenAI Codex properly. https://x.com/heyzarakhan/status/2051357610222239745?s=46
How much of your project code was written by #AI? Whether to track coding agent adoption in engineering teams or security risks introduced by vibe coding, it's time to track what Claude/Cursor/Copilot/Codex do. https://usegitai.com/: https://www.linkedin.com/posts/fzaninotto_git-ai-track-ai-code-all-the-way-to-production-share-7450124640389263360-jhxu?utm_source=share&utm_medium=member_ios&rcm=ACoAAA2M-8wBB-yYv6qd4pdeoz3fTBIAhu6HQH8
practitioners' perspective: Takeaways based on a qualitative survey of 419 practitioners involved in workflow maintenance: https://dl.acm.org/doi/10.1145/3806833
In 14 minutes, this Anthropic engineer who created MCPs will teach you more about building them right than most developers figure out on their own in months https://x.com/Av1dlive/status/2051967150894772609?s=20
Star Wars: Episode 1 - Racer (Podracing) 100% Speedrun in 1:17:33 [World Record]: https://youtu.be/OWv69snqBFs?is=kNL8iJzzGVRL3hRl
In 2007, Elon Musk Predicted Everything: https://youtu.be/xyCOvT1Y5YQ?is=igUlB5wqAuX1qbRs

🎶 Music credit

Questo trend è mio! ⭐️ : https://www.tiktok.com/@maya_cianflone/video/7607524440364289302

@maya_cianflone
Questo trend è mio! ⭐️
♬ original sound - smb.0685

⚡️ Screening of the film "My Extraordinary Life" - what living systems teach us about automation

Mathieu Ledru — Wed, 06 May 2026 07:05:30 +0000

On May 5th, at Pixelis in Paris, we screened Mon Extraordinaire, the film that follows Guillaume Lalu on his 160km solo trek during the Marathon des Sables Ultra. No codes, no agents, no LLM. And yet, for two hours, everyone in the theater had the same feeling: this film speaks directly to what we are building at Darkwood.

Because running 160 km in the sand is not about raw performance.

It's a masterclass in orchestration, resilience, and living systems.

The Myth of the Perfect Sprint

Ultra-trail running is often imagined as a matter of steely resolve and pure willpower. Guillaume Lalu shows something else: he doesn't force the desert, he builds a system capable of surviving in it.

Preparation, logistics, energy management, block-based approach, managing constant friction, recovery, rhythm, the team around him. Everything he talks about after the screening sounds exactly like a complex production pipeline.

In automation and AI, we make the same mistake as at the beginning: we believe that everything depends on initial power (best model, perfect prompt, ultra-intelligent agent).

The reality on the ground is harsh: what matters is what still holds up after 40 hours… or after 6 months in production.

Friction is not a bug, it's the nature of matter

The most telling moment in the film? The sand constantly getting into the shoes.

A seemingly ridiculous detail.

It's actually a structural problem.

Guillaume spends a huge part of his race emptying his shoes, managing irritation, losing rhythm, and expending mental energy. He can't eliminate the sand. He has to deal with it.

This is the exact metaphor for real-world workflows today:

APIs that change without warning
Exploding tokens
Drifting agents
Contexts that become unusable
Humans who intervene at the wrong time
Dirty or incomplete data

The systems that work aren't those that have eliminated all friction. They're the ones that have learned to move forward despite it. This is precisely the spirit behind Flow: data-oriented and event-driven architectures that don't strive for rigid perfection, but for the ability to keep going when things get tough.

Endurance > Cutting-edge intelligence

Guillaume isn't running to win. He's running to finish, remaining whole, fully experiencing the journey. He mentally breaks down the 160 km into four symbolic "marathons." He ticks off the blocks one by one.

That's precisely the difference between an impressive AI demo and a system that lasts.

Many automation tools shine on stage.

Few survive the night, the unforeseen events, the accumulation of small deviations.

Sustainable systems are those that know how to slow down, observe, recover, and resume. Those that tolerate imperfection. Those that maintain a narrative continuity.

Navi: The Memory of the Journey Through Chaos

In the film, Guillaume explains how he survived mentally thanks to this breakdown and this ability to look back: "Where did I lose energy? Why did I slow down here? What allowed me to start again?"

A memoryless AI agent system quickly becomes a ghost. We no longer know:

Why did this officer make this decision?
What data triggered this branch?
At what point did the workflow deviate?
What actually created value

Navi was born from this need: to transform the chaotic trace of a distributed system (agents + workflows + human interventions) into a comprehensible, narrative, visual journey. Not just logs. A story that humans can reread and understand, even days later.

Like Guillaume who, in the middle of the night, in the cold, still knows where he is in his own story.

Hybrid orchestration: the human element is not optional

The film is also a beautiful lesson in humility: no one crosses 160 km alone. There are friends (François and Julien), the coach, the medical teams, the checkpoints, loved ones, the other runners.

Ultra-trail running is becoming a collective system.

This is precisely what we observe with the best AI implementations today: the most powerful systems do not replace humans. They augment them. Humans become the immune system, the strategist, the one who sets safeguards and corrects the trajectory when the model goes astray.

Uniflow: Building for the long term, not viral

Guillaume didn't launch Epic Race looking for a viral hit. He built it slowly: episode after episode, relationship after relationship, for years. 300 episodes later, the project still holds up because it's organic.

This is the same trap that many fall into with creative automation: looking for the hack, the agent that generates 100 posts per day, explosive growth.

Uniflow is not a spam machine. It is a creative endurance infrastructure: recycling, enriching, reorchestrating, transforming a continuous flow into a living ecosystem that improves over time.

The desert as ultimate truth

The Sahara in My Extraordinary is the perfect metaphor for the environments in which we deploy our systems today: immense, unpredictable, energy-intensive, hostile at times, impossible to control totally.

In this context, rigid architectures die.

Living systems survive.

They learn to:

Dancing with friction
Maintaining a narrative memory
Human + AI orchestration
Moving forward despite the sand
Transforming chaos into continuous flow

Real automation is not magic. It is organic.

Thanks to Guillaume Lalu, Pixelis, and everyone who was present on May 5th.

The desert didn't talk about technology.

Yet he told us everything about the future of AI and automation.

And what he says is that the systems that will last will be those that know how to, like him, continue despite the sand.

✨ Transformative design: no longer designing uses, but metamorphoses

Mathieu Ledru — Fri, 01 May 2026 06:39:23 +0000

On April 30th, at Le Laptop in Paris, an event took place that broke away from the beaten path of classic Product Design: “Transformative Design: Don't just create uses, transform users”, presented by David Jeanne and organized by Jordan Thévenot.

In a room filled with around forty participants—designers, developers, and product specialists—the promise was clear: to question the current limitations of UX and propose a new direction. A direction where design no longer simply optimizes interfaces, but seeks to produce profound transformations for users.

From Experience to Transformation

Product design has long sought to make things simpler.

Less friction.
Less effort.
Less complexity.
Less waiting time.

It's a powerful promise. But it also has a limitation: by smoothing everything over, we sometimes end up smoothing over meaning itself.

David Jeanne starts from an idea from The Experience Economy: the economy evolves in stages.

We started by selling raw materials.
Then products.
Then services.
Then experiments.

But when the experience itself becomes commonplace, what remains to differentiate oneself?

The proposed answer is powerful: transformation.

It's no longer just about selling a pleasant interface or a smooth user journey. It's about designing an experience that helps a person become someone else.

For example :

to go from “I am not sporty” to “I take care of my body”;
moving from “I am at the mercy of my money” to “I am building my future”;
to move from “I am just a resource” to “I am an active participant in the project”.

This is where design becomes transformative.

Designing a passage, not just a route

Classical design often works with a persona: their needs, their pains, their motivations.

Transformative design adds a deeper question:

How do we want to help this person to grow?

This completely changes the nature of the work.

We no longer just design a user journey.
We design a passage.

A passage between a current self and a possible self.

This transition can follow the structure of initiation rites: a preparation phase, a turning point phase, and then an integration phase. The goal is not simply to create a "wow" effect, but to create an experience that leaves a lasting impression.

The role of rituals, symbols and objects

One of the most interesting aspects of the conference is the importance given to symbols.

A transformation does not happen solely through rational arguments. It also happens through forms, gestures, objects, places, words, and postures.

In the example presented, a simple, traditional meeting was transformed into a ritualistic moment. The chairs disappeared, a large strategic map was placed on the table, and the computer was put aside. The client was no longer simply someone who "gave a brief." They gradually became a strategist.

And this change in physical posture can trigger a change in mental posture.

This is a key idea: design transforms not only by what it explains, but by what it brings to life.

Preserve, amplify, help, dissolve, transform

David Jeanne presents an interesting matrix for deciding what to do with the existing elements in the experiment.

Certain elements must be preserved, as they ensure the psychological safety of the user.
Others need to be amplified, because they are already moving in the direction of the desired transformation.
Others need help when they are simply irritants to be removed.

Then come the deeper dimensions:

dissolve certain reference points;
to transform certain identity-related blockages.

This is where transformative design differs from traditional UX. It doesn't just aim to reduce problems; it seeks to identify what prevents a person from changing their perspective on themselves.

A central ethical question

Such a design obviously raises a question: how far can we go?

While design can transform, it can also manipulate.

The conference emphasizes this point: the model presented aims for empowerment, not subjugation. But this imposes a strong requirement regarding consent, protection, and intent.

Designing a transformation is not a neutral process.

This is likely one of the major topics of the coming years, especially with the massive integration of AI into digital products. Interfaces will become more adaptive, more personalized, and more persuasive. The line between guidance and manipulation will become increasingly blurred.

My takeaway for Darkwood

This conference resonates strongly with the topics I explore around Darkwood, Flow, and automation.

Today, many tools aim to save time. But save time for what purpose?

A good product shouldn't just automate a task. It should help its user change their approach.

To go from consumer to creator.
To move from executor to architect.
To go from spectator to player.
To go from being overwhelmed to being able to orchestrate their own systems.

This is probably where part of the value of future products lies: not in the total elimination of effort, but in the design of efforts that transform.

Conclusion

Transformative design encourages us to move beyond a purely utilitarian view of the product.

A product can be more than just a tool.
It can become a ritual.
A passage.
A mirror.
A trigger.

The question is therefore no longer simply:

“What use are we creating?”

But rather:

“What kind of person are we helping to emerge?”

Going further

David Jeanne has launched a campaign for his book dedicated to transformative design, which delves deeper into these concepts with concrete and operational methods.

👉 https://fr.ulule.com/design-transformatif-livre/

⚙️ Hermes X Paperclip - Building a Governed Multi-Agent Architecture with Symfony AI, Flow, and Navi

Mathieu Ledru — Thu, 30 Apr 2026 12:19:19 +0000

Multi-agent systems are everywhere:

orchestrated via Docker: https://blog.darkwood.com/fr/article/ai-tinkerers-paris-agentic-workflows-avec-docker-vers-des-systemes-autonomes-securises-et-orchestres
Simulated using frameworks like Paperclip + Hermes: https://www.youtube.com/watch?v=j7cKjTMjNLE
or integrated directly into products: https://docs.langchain.com/oss/python/langchain/multi-agent

But in most cases, they remain:

❌ collections of prompts

❌ without governance

❌ without traceability

❌ without clear responsibility

In this article, we will build an alternative, not as a fictional startup, but as a concrete example:

NoLife Agency - a digital agency entirely driven by a governed multi-agent architecture.

a digital agency that produces client websites with specialized roles.

🏢 NoLife Agency - a complete organization

Unlike simplistic demos, NoLife Agency replicates a real organization:

Direction

CEO
CTO
Governance Director Manager

Client & Delivery

Account Manager
Product Owner
Delivery Manager

Production

Architect
Developer
UX Designer
UI Designer Graphic Designer
Motion Designer

Growth

SEO / GEO
Marketing
Sales
Web Analytics

Support & Reliability

QA
DevOps
Security Officer
Data Analyst

Internal Organization

Experience Officer
Office Manager
Happiness Chief Officer
Nolife Resource

👉 Here, each role can be played by an agent.

⚠️ The trap of multi-agent architectures

What many are building:

Prompt → LLM → résultat

The result is:

*no guarantee

no control
no auditability
no contract
no governance
no trace
no trade-in
no clear responsibility

✅ The NoLife Agency Model

We introduce a strict separation:

organization (Paperclip) → who does what
specialization (Hermes) → how to think
orchestration (Flow) → when to execute
traceability (Navi) → observe and audit
intelligence (Symfony AI) → produce content

🧱 Technical architecture

The application is based on a ports & adapters architecture.

Main Ports

NoLife Agency uses ports and adapters to ensure that orchestration and governance remain decoupled from vendor/runtime specifics.

AI → AiAgentClient
Workflow → FlowWorkflowClient
Trace → NaviTraceClient
Media → MediaGenerationClient

👉 Each external dependency is isolated.

AgentRunner is the single boundary for execution and governance. Adapters provide functionality, but they do not enforce policy.

flowchart LR
demoCommand[DemoClientWebsiteCommand] --> workflowLoader[WorkflowDefinitionLoader]
workflowLoader --> workflowValidator[WorkflowDefinitionValidator]
workflowValidator --> flowPort[FlowWorkflowClient]
flowPort --> agentRunner[AgentRunner]
agentRunner --> aiPort[AiAgentClient]
agentRunner --> naviPort[NaviTraceClient]
agentRunner --> mediaPort[MediaGenerationClient]
agentRunner --> auditJsonl[Audit JSONL]
agentRunner --> runArtifacts[Run Artifacts]

Symfony AI
  ↓
Agent Contracts + Registry
  ↓
AgentRunner + Governance
  ↓
Flow Workflow Runner
  ↓
Navi Trace Client
  ↓
Operational Reports

🧠 Key principle

Agents are not dependent on tools. They are dependent on contracts.

Result :

testability
interchangeability
robustness

⚙️ The heart of the system: AgentRunner

AgentRunner is the central point:

execution
governance
audit
trace

👉 No agent can circumvent this point.

Main guarantees:

checks of the pre-flight and post-flight policy
Application of approval for high-risk states/final delivery
Workflow status security checks
confining the artifact path to the execution directory
Trace the correlation between the lifecycle and audit events

🔐 Integrated IT Governance

Each action is:

validated
traced
audited

With :

JSONL logs
trace per run
validation rules
mandatory approval

👉 This is not a blind, autonomous system.

👉 It's a controlled system.

AgentRunner is the single point of application for:

policy checks
trace the life cycle
Issuance of audit events
approval requirements

Key points:

separation of responsibilities
auditability
human validation
limitation of risky actions
typed interfaces
policy tests

🔌 Phase 3 - Typed Ports

The dependencies become ports:

Symfony AI → intelligence
Flow → orchestration
Navi → traceability
media-bundle → media generation

With one critical point:

The adapters are interchangeable via configuration

Environment variables made available on the project:

NOLIFE_AI_ADAPTER (null|symfony_ai)
NOLIFE_FLOW_ADAPTER (null|darkwood_flow)
NOLIFE_NAVI_ADAPTER (null|darkwood_navi)
NOLIFE_MEDIA_ADAPTER (null|media_bundle)
NOLIFE_FLOW_ROOT
NOLIFE_NAVI_ROOT
NOLIFE_MEDIA_BUNDLE_ROOT

🧪 Use Case - Creating a Client Website

Use case:

Client: Acme SaaS
Contact: John Do
Need: landing page + blog + SEO + short launch video

Order :

php bin/console nolife:demo:client-website acme-saas

Workflow:

lead_qualified
brief_created
architecture_defined
ux_ready
content_generated
development_ready
SEO optimized
qa_validated
media_brief_created
delivery_reviewed
human_approval_required
published

👉 We are intentionally stopping before publication.

Paperclip is modeled as an organizational concept.

Hermès is modeled as a concept of specialization.

Neither is coupled as an execution service.

📂 Generated Outputs

var/nolife-agency/runs/{run_id}/

brief.json
landing-page.md
article-draft.md
seo-geo.md
media-brief.yaml
delivery-report.md
trace.json
audit.jsonl

Expected final state: human_approval_required.

🔁 Multi-agent at all levels

1. Infrastructure

Docker / isolated services

2. Organization

Paperclip → role structure

3. Intelligence

Hermes → agent specialization

4. Application

Symfony → concrete orchestration

👉 NoLife Agency is a point of convergence.

⚠️ Real problem encountered

Today :

AI adapter: null
Using Null AI adapter

👉 The system is correct… but not yet connected.

That's normal.

Because :

The ports are in place
but the actual implementations are not enabled

🧠 What this reveals

Building a multi-agent architecture is not the same as calling an LLM.

It is :

Define contracts
Isolate the dependencies
Centralize governance
Make the system testable
Gradually activate the integrations

🚀 Next step

Enable :

Symfony AI (real intelligence)
Flow (actual workflow)
Navi (actual track)

👉 Without breaking anything:

the tests
governance
the ports

🎯 Conclusion

Multi-agent architectures are not:

magical autonomous systems

These are :

governed, orchestrated, and traceable software organizations

💡 Darkwood Positioning

NoLife Agency is showing a clear direction:

The future of AI systems is not only autonomous.

It is governed.

🕵 Project source code

nolife-agency: https://github.com/matyo91/nolife-agency

🔗 Resources

Multi-Agent Architectures: https://speakerdeck.com/chr_hertel/symfony-ai-in-action-symfonylive-berlin-2026?slide=46
What is a multi-agent system? https://www.ibm.com/fr-fr/think/topics/multiagent-system
Multi-Agent Orchestration: How to Build Agent Teams That Actually Work: https://www.mindstudio.ai/blog/multi-agent-orchestration-patterns
Building AI Teams: How Docker Sandboxes and Docker Agent Transform Development: https://www.docker.com/blog/building-ai-teams-docker-sandboxes-agent/
How To Build a Multi-Agent AI System with Docker Agent: https://www.digitalocean.com/community/tutorials/how-to-build-multi-agent-ai-system-docker-agent-digitalocean
Langchain Multi-agent: https://docs.langchain.com/oss/python/langchain/multi-agent
Github NousResearch/hermes-paperclip-adapter: https://github.com/NousResearch/hermes-paperclip-adapter
Hermes Agent, how to take advantage of the OpenClaw killer: https://www.youtube.com/watch?v=j7cKjTMjNLE
The A-Team - AI Agents for SaaS Development: https://github.com/gmoigneu/the-a-team
New Tech Role Emerging: Product Managers might evolve to “Product CEOs” (Paul Teyssier | Front): https://www.youtube.com/watch?v=J3vCkWbSYI0
Openai/symphony: https://github.com/openai/symphony

🎶 Music credit

Keine Freunde bleiben (feat. Mia Julia) - Matthias Reim: https://vm.tiktok.com/ZNRgyxKkE/

@reim.matthias Wenn Freundschaft keinen Sinn mehr macht… Wer fühlt den Song? #miajulia #matthiasreim #keinefreundebleben ♬ Keine Freunde bleiben (feat. Mia Julia) - Matthias Reim

"That way I eat more!" 😂 #nico #byilhanntwitch: https://vm.tiktok.com/ZNRg5Rsh1/

@leclippeurrapide "That way I eat more!" 😂 #nico #byilhanntwitch ♬ original sound - Le Clippeur Rapide

📖 Selection of the week

DeepSeek-R1 evolving a Game of Life pattern really feels like a breakthrough: https://www.reddit.com/r/LocalLLaMA/comments/1icqzcz/deepseekr1_evolving_a_game_of_life_pattern_really/
Unbounded: A Generative Infinite Game of Character Life Simulation: https://arxiv.org/html/2410.18975v1
LLM Interactive Story Game Architecture: https://montreal.aitinkerers.org/talks/rsvp_c82tFBRQJ9A
Can an LLM Make a Video Game? https://www.codemag.com/Article/2411061/Can-an-LLM-Make-a-Video-Game
Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps
Elon Musk explains his 5-step algorithm for running companies: https://youtu.be/tdf3luOCNks?is=L6MRoXTHzvFVIUR8
when you have vibe coder in your office: https://x.com/javinpaul/status/2048425733694124211/video/1?s=46
Sunday morning science: https://x.com/Soph_astro/status/2048333972615111050/video/1?s=46
React Native at Cdiscount with Ludwig Vantours: https://www.youtube.com/watch?v=C3toh628KJE&list=PLmewDYeBL3XIx7Lnga-jO3eRjOsKQ-HW0&index=31
Getgaal - docs(mcp): re-sync with agents/global registry resolution: https://github.com/getgaal/docs/pull/16
Arize Phoenix: https://arize.com/docs/phoenix
Design a new professional future with no-code and AI: https://www.youtube.com/watch?v=p-sHtOut884
The bullshit of open-source AI models: https://www.youtube.com/watch?v=jpg9lvtqrF8
A former spy uses AI to learn everything about you (Claude Code demonstration): https://www.youtube.com/watch?v=eQXMEvGRld4
Automate your information monitoring for free and easily: https://www.youtube.com/watch?v=6n_xwJ6YAj0
A man spent 50 years teaching at MIT. The most important hour you'll watch this week. https://x.com/suryanshti777/status/2049187998936482069?s=46
The Fastest AI Infrastructure: https://www.cerebras.ai
Diablo® IV: Lord of Hatred: https://eu.shop.battle.net/fr-fr/product/diablo-iv-lord-of-hatred

🚀 Fundraising vs. Bootstrap: Two paths to building a company

Mathieu Ledru — Wed, 29 Apr 2026 07:22:46 +0000

On April 28th, Builders Factory and NextGen VC organized a discussion in Paris around a seemingly simple question: Should you raise funds or build using bootstrapping?

Face to face: Étienne Genvrin, founder of Emma, which has raised several million euros, and Wilfried Granier, founder of Superprof, which claims impressive growth without raising funds.

Two opposing paths. Two visions of entrepreneurship. And above all, one central idea: there is no single right way to build a business.

The bootstrap: building a company that reflects you

Wilfried Granier defends a very personal vision of the company.

Superprof wasn't conceived as a startup to be sold, but as a company to be held onto. This difference changes everything. When you don't raise capital, you retain the freedom to decide, to experiment, to take your time, to make choices that may not seem rational on paper, but are consistent with your intuition.

The bootstrap also forces you to focus on the essentials: revenue.

No artificial runway. No growth financed by successive rounds of funding. The market responds directly. If customers pay, the company moves forward. If not, it must correct course.

This constraint can become a strength: it encourages creativity, efficiency, the building of a solid culture, and the search for sustainable organic levers such as SEO, community, user reviews, or gradual internationalization.

Fundraising: Accelerate, learn, iterate faster

Étienne Genvrin offers another interpretation.

For certain markets, particularly consumer applications or products requiring high execution speeds, raising funds can be almost essential. Funding allows for faster recruitment, more testing, and the ability to make more mistakes in less time.

But he insists on one important point: raising funds is a game.

This game has its rules, its codes, its expectations, its language. Many entrepreneurs fail to raise funds not because their project is bad, but because they don't yet understand how this game works.

Raising funds is therefore not just a question of business model. It is also a question of narrative, timing, network, perceived ambition, and the ability to embody a credible trajectory.

The real issue: alignment

The debate could have been reduced to “raise or not raise”. But the real question is deeper:

What type of business do you really want to build?

If your goal is to remain in control, to build for twenty years, to preserve maximum freedom, then the bootstrap may be the best path.

If your goal is to quickly capture a market, recruit expensive profiles, and move very fast in a sector where speed counts, then fundraising can become a strategic tool.

In both cases, the danger is misalignment.

Raising capital when you want a flexible structure can create ongoing problems. Bootstrapping when you're operating in a market where speed is vital can condemn the project to remain too small.

Advice is no substitute for instinct.

One of the strongest messages of the evening: entrepreneurship is learned through practice.

Listening to podcasts, reading threads, or attending conferences can be inspiring. But it doesn't replace being on the ground.

Entrepreneurial instinct is built by talking to customers, selling, recruiting, making mistakes, wasting time, correcting, and starting again.

This is also why we must be wary of absolute advice. Advice that's true for Superprof isn't necessarily true for Emma. A strategy that works in 2013 isn't necessarily effective in 2026. A tactic that works in France might fail in the United States.

The entrepreneur should not seek a universal rule. He must develop his own judgment.

Barriers to entry are built as you move forward

Another interesting point: at the beginning, it is often unnecessary to over-theorize about barriers to entry.

When you start out, you don't yet have 39 million teachers, millions of user reviews, a well-known brand, or an international database. These advantages aren't prerequisites. They're the result of years of operation.

The real initial barrier to entry is often the ability to continue when others give up.

Create a first version. Find a first client. Solve a first problem. Move from level 0 to level 1.

It's less spectacular than an ambitious pitch deck, but this is where the real building begins.

Conclusion

Fundraising and bootstrapping are not two opposing camps.

These are two different tools.

The fundraising buys time, speed, and visible ambition.
Bootstrapping buys freedom, patience, and mastery.

The real issue, therefore, is not which model is superior.

The real question is which one allows you to build the right business, at the right time, with the right level of alignment.

🚀 I rebuilt an LLM… with pixels.

Mathieu Ledru — Sun, 26 Apr 2026 15:59:27 +0000

Large Language Models (LLMs) are based on abstract concepts:
probability distribution, autoregressive generation, large-scale optimization.

These mechanisms are difficult to observe directly.

An alternative approach is to project these concepts into a visual and deterministic system, allowing us to study their dynamics.

This work is inspired by an initial demonstration shared on Twitter:
Allen Explains thread

The goal is to build an educational prototype that will:

represent a sequential generation
observe an optimization process
compare different training regimens

System Architecture

The prototype is implemented in PHP (Symfony 8) and is based on four main components:

Cellular Automaton (Game of Life)
Lambda language (AST JSON)
Genetic Algorithm
Streaming pipeline (NDJSON + SSE)

Full source code:
llm-game-of-life

Representation: from text to grid

An LLM models a distribution:

[
P(x_1, x_2, ..., x_n)
]

broken down into:

[
\prod_{t=1}^{n} P(x_t \mid x_{
]

In this prototype, this structure is transposed:

LLM	Prototype
Token	Cell
Sequence	Grid
Generation	Frame
Model	Program
Inference loop	Simulation

Each frame corresponds to a generation step.

The SSE flow produces a sequence:

frame₀ → frame₁ → frame₂ → …

equivalent to a self-regressive generation.

Model: program rather than network

Unlike traditional LLMs, no neural networks are used.

The model is defined as a program in a mini lambda language, represented as an AST JSON file:

{
  "type": "sequence",
  "nodes": [
    { "type": "birth", "x": 1, "y": 1 },
    { "type": "next" }
  ]
}

This program acts as a transition function on the grid.

This approach replaces:

the weights of a model → by instructions
the layers → through explicit transformations

Optimization: Genetic Algorithm

The training is based on a population of programs.

Each generation follows:

Fitness Assessment
Selection
Crossover
Mutation
Elitism

This process replaces gradient descent.

Unsupervised training

Unsupervised mode maximizes a fitness function based on:

entropy (diversity)
movement (variation between frames)
lifetime

Objective :

[
\text{fitness} = f(\text{entropy}, \text{motion}, \text{lifetime})
]

This regimen is analogous to pretraining:

absence of target
exploration of the solutions space

Supervised Training

The supervised mode introduces a target:

glider
blinker
block

Fitness is becoming:

[
\text{fitness} = -d(\text{frame}, \text{target}) + \lambda \cdot \text{penalty}
]

Or :

(d) is a distance between grids
the penalty limits the size of the programs

This mode corresponds to fine-tuning.

Preferences and selection

A comparison mechanism can be introduced:

Two programs produce two sequences
a preference is applied
The selection favors the best

This diagram represents a simplification of RLHF / DPO:

[
\max \log P(\text{preferred}) - \log P(\text{rejected})
]

Generation and streaming

The results are produced in NDJSON and disseminated via SSE:

Each chunk = one frame
Each stream = one generation

Canvas-based visualization interface:

matrix rendering
real-time display
metrics (fitness, generation, seed)

Presentation slides:
Slidewire presentation

Benchmark and reproducibility

The system includes a benchmark pipeline:

deterministic seed
double execution
sequence hash

Metrics:

duration (duration_ms)
memory (peak_memory_mb)
final fitness
reproducibility

Boundaries

This prototype is not intended to reproduce a real LLM:

no transformer
no tokenization
no probabilistic model
no gradient

This is a computational analogy, useful for:

observe an optimization dynamic
visualize a sequential generation
compare different learning regimes

Conclusion

Modern LLMs rely on mechanisms that are difficult to grasp directly.

Transposing this into a visual system allows us to:

make generation observable
to materialize the optimization
isolate the fundamental concepts

This approach does not replace existing models, but offers a conceptual exploration tool.

Source of the Twitter post: https://x.com/allen_explains/status/2044757995549319172?s=12
The project's source code: https://github.com/matyo91/llm-game-of-life
The presentation slides: https://github.com/matyo91/slidewire

Resources

What are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers? https://github.com/humanlayer/12-factor-agents
AIE Miami Keynote & Talks ft. OpenCode. Google Deepmind, OpenAI, and more! : https://www.youtube.com/watch?v=6IxSbMhT7v4
AIE Miami Day 2 ft. Cerebras, OpenCode, Cursor, Arize AI, and more! : https://www.youtube.com/watch?v=DeM_u2Ik0sk
How AI is transforming software engineering: a conversation with Gergely Orosz, @pragmaticengineer: https://www.youtube.com/watch?v=CS5Cmz5FssI
Microsoft at ICLR 2026: Deep Learning, LLM Reasoning, Generative Models: https://www.linkedin.com/pulse/microsoft-iclr-2026-deep-learning-llm-reasoning-generative-h74se/
ASUS DGX Spark: KI auf dem Schreibtisch – Nie wieder Token‑Kosten! | Live Modellvergleich: https://www.youtube.com/watch?v=dP4zE-DTWAg
🟣 [VIRTUAL SUMMIT DAY 1/5] How to outperform 99% of people using AI: https://www.youtube.com/watch?v=yzhg9Ks859I Ready to launch your own agent? : https://hermes-agent.org/fr/
PaperClip + Agent Hermès, it's insane! : https://www.youtube.com/watch?v=PUaZ5o8u0wY
30-minute workshop by the creator of Claude Code that will teach you more about vibe-coding: https://x.com/heyamit_/status/2046489651775713498?s=46
What Young People Expect from HR: Why the Generational Approach is a Misleading Concept: https://www.insign.fr/en/insights/young-workforce-expectations-generational-approach-an-intellectual-scam

🤖 Symfony AI in Action - Building real AI systems with Symfony

Mathieu Ledru — Fri, 24 Apr 2026 14:25:23 +0000

For two days, on April 23 and 24, 2026, the SymfonyLive Berlin conference brought the community together around the major developments of the Symfony ecosystem.

Among the talks, one in particular marks a turning point:

👉 Symfony AI in Action, presented by Christopher Hertel.

🎥 Slides: https://speakerdeck.com/chr_hertel/symfony-ai-in-action-symfonylive-berlin-2026
🧠 Symfony AI: https://ai.symfony.com
🛠️ Platform used for this article: https://slidewire.dev

This article does not summarize the conference.
He offers a Darkwood interpretation of what is happening.

The real issue: stop thinking “chatbot”

Today, many AI integrations are limited to this:

write a prompt → call a template → display a response

That's insufficient.

The real problem, in production, lies elsewhere:

orchestrate multiple models
manage context and memory
Expose actions (tools)
monitor costs and logs
integrate everything into a business architecture

👉 Symfony AI does not offer a chatbot.
👉 Symfony AI offers a complete stack.

Symfony AI: a stack, not a feature

The objective is clear:

“Enable AI features, not only LLMs.”

Symfony AI introduces several fundamental building blocks:

Platform → model abstraction
Agent → LLM loop + tools
Store → embeddings & RAG
AI Bundle → Symfony integration
MCP Bundle / SDK → tools exhibition

👉 We're moving from an API call… to a complete AI architecture.

Platform: Model abstraction

First classic problem:

OpenAI, Claude, Gemini, Mistral → Different APIs

Symfony AI introduces a unique abstraction.

$platform->invoke('gpt-5-mini', $input);

Same code, different providers.

Why this is key

change model without refactoring
optimize costs
fallback multi-provider
Integrate local and remote

👉 Symfony becomes a model orchestration layer.

Streaming & multimodal

Symfony AI goes beyond simple text:

Real-time token streaming
audio, image, PDF
binary output

Examples:

analyze a PDF
Describe an image
process an audio
generate files

👉 AI is becoming a multimodal application building block.

Structured Output: regaining control

Classic problem:

LLMs return text… not reliable data

Symfony AI introduces typed responses:

$response_format => MyDTO::class

Result :

usable PHP objects
strict validation
Direct integration into the profession

👉 We are moving from “generated text” to controlled data.

Agent: Connect the LLM to your application

An agent is:

a model that can call your code

With Symfony AI:

#[AsTool('create_recipe')]

You present your profession as a tool.

What this changes

Before :

Isolated LLM

After :

LLM + access to your system

👉 AI becomes executable.

Human in the loop: security

A critical point that is often overlooked:

An AI shouldn't do everything automatically.

Symfony AI allows you to:

intercept a tool call
request validation
block or allow

Example :

publish an article
trigger critical action

👉 You remain in control.

Memory: contextualize

Agents do not function without context.

Symfony AI allows you to:

inject user data
manage profiles
store history
control permissions

👉 AI is becoming contextual and personalized.

Store & RAG: Connect your data

Pipeline:

loading
Filtering
transforming
Vectorizing

👉 You are building a vector basis.

Afterwards :

user request
search in the store
enrichment of the prompt

👉 This is RAG (Retrieval Augmented Generation).

Real Impact

Smart FAQ
industry search engine
internal co-pilot
documented assistant

👉 You connect the AI to your business knowledge.

Multi-agent: specialization

Advanced architecture:

senior agent
specialized sub-agents
orchestration
sharing or isolation of context

Example :

support agent
technical agent
billing agent

👉 Each agent has a role.

MCP: Expose your system

Symfony AI is part of a broader movement:

👉 the MCP protocol

Objective :

Showcase your tools
make your system queryable
standardize AI interactions

👉 Your application becomes an intelligence server.

The real turning point: orchestration

The most important point is not:

the models
the prompts
the agents

👉 The real issue is orchestration.

Key questions:

Who calls what?
In what context?
Under what permissions?
With what traceability?
How to regain control?

The Darkwood Approach

At Darkwood, the answer is clear:

Suggested Stack

Symfony AI → AI building blocks
MCP → tools exposure
Flow → orchestration
Navi → execution + tracing
Uniflow → interface

Why this stack

Symfony AI provides:

the models
the agents
the tools
the RAG

But something is missing:

business orchestration
overall control
full visibility

👉 This is where Flow and Navi come in.

What this changes in practice

Before :

isolated AI scripts
fragile prompts
little control

After :

orchestrated system
traceable execution
integrated business logic

👉 We are moving from “playing with AI” to building reliable systems.

Conclusion

Symfony AI marks a major evolution:

You're no longer building a chatbot

you build a complete AI feature

Today you have:

an abstraction of models
agents connected to your code
a memory system
of the integrated RAG
a basis for orchestrating

👉 You have no more excuses.

To go further

Symfony AI: https://ai.symfony.com
Slides by Christopher Hertel: https://speakerdeck.com/chr_hertel/symfony-ai-in-action-symfonylive-berlin-2026
The technical support that allowed me to generate the slides - Slidewire: https://slidewire.dev

Darkwood

Navi → execution & tracing
Flow → orchestration
Uniflow → interface

👉 Articles coming soon with concrete implementations.