DEV Community: Mathieu Ledru

🤖 Veille Darkwood - 2026-06-20

Mathieu Ledru — Sat, 20 Jun 2026 05:01:24 +0000

Points saillants

VMAF v1: Good Is Not Good Enough
- By Christos G. Bampis, Zhi Li, Kyle Swanson, Nil Fons Miret and Pavan MadhusudanaraoWill this encode look good to Netflix members? Does switching to a new codec improve quality at the same bitrate and by how much? What...
Thinking Fast & Slow for a Personalized Notification System
- by Matthew Wood, Ishan Gupta, Kevin Mercurio, Devon Bryant, and Claire DormanIn his seminal book “Thinking, Fast and Slow,” Daniel Kahneman describes two systems that drive human cognition: System 1, which operates auto...
A Human-Augmenting Agentic Workflow for Causal Inference
- By Winston Chou, Adrien Alexandre, Lars Olds, Yi Zhang, Garrett Hagemann, and Nathan KallusIntroductionImagine asking a data agent to analyze the causal relationship between two variables, such as the effect of watching...
Data Projects: Managing Data Assets at Netflix Scale
- By Amer Hesson, Marcelo Mayworm, James Mulcahy, and Brittany TruongThe Problem: Managing Assets at Netflix ScaleNetflix’s Data Platform is vast. We have millions of tables in our data warehouse and tens of thousands of...
The Evolution of Cassandra Data Movement at Netflix
- By Guil Pires, Jennifer Prince, Jose Camacho, Ken Kurzweil, Phanindra ChunduruBackgroundIn a previous post, we introduced Data Bridge, a unified management plane for batch Data Movement at Netflix. Historically, several...

Sources

Partenaires

Groover — Groover a besoin de plus d'artistes comme toi. Offre -10 %, gagne 10 Grooviz – de quoi contacter 5 médias et pros gratuitement !
Cursor — Earn up to $250 every month by sharing Cursor.
Tella — Share Tella with friends & earn — votre ami obtient 20 % de réduction pendant 3 mois, vous recevez 20 $ par utilisateur parrainé.
Bonzai Skillflix — Formation et communauté tech — commission d'affiliation 40 %.
Bonzai Premium — Abonnement mensuel (49 €), annuel (299 €), à vie (499 €).

🚨 Premium content.
⬆️ Upgrade to access full analysis.
👉 Subscribe here : https://www.bonzai.pro/matyo91/shop/48ov_2168/automation-avec-flow-en-php

🤖 Veille Darkwood - 2026-06-19

Mathieu Ledru — Fri, 19 Jun 2026 19:53:48 +0000

Points saillants

Symfony AI Spotlight: One API to Rule Them All
- Symfony AI is approaching its 1.0 release — so let’s take a tour. In this first post of this series, we introduce the Platform component — the foundation layer that connects your PHP application to the world of AI. The...
Symfony UX 3.2.0 and 2.36.1 released
- Symfony UX 3.2.0 and 2.36.1 are now available. Both releases fix two security issues, one in UX Icons and one in UX Toolkit, so every application using these packages should upgrade as soon as possible. On top of the se...
CVE-2026-55877: XSS in symfony/ux-icons via unsanitized SVG content in local files and Iconify on-demand responses
- Affected versions Symfony UX Icons versions >=2.17.0<2.36.1, >=3.0.0<3.2.0 are affected by this security issue. The issue has been fixed in Symfony UX Icons 2.36.1, 3.2.0. Description The ux_icon() Twig function is mark...
CVE-2026-55878: Path Traversal in symfony/ux-toolkit Allows Arbitrary File Write and Read via Crafted Recipe Manifest
- Affected versions Symfony UX Toolkit versions >=2.32.0<2.36.1, >=3.0.0<3.2.0 are affected by this security issue. The issue has been fixed in Symfony UX Toolkit 2.36.1, 3.2.0. Description The ux:install console command...

🚨 Premium content.
⬆️ Upgrade to access full analysis.
👉 Subscribe here : https://www.bonzai.pro/matyo91/shop/48ov_2168/automation-avec-flow-en-php

🌊 Le mirage du Vibe-coding - démo, produit ou illusion (il n'y a pas de quatrième option)

Mathieu Ledru — Thu, 18 Jun 2026 16:00:21 +0000

Introduction : l'effondrement de la barrière

Le coût de production d'une ligne de code est devenu quasi nul. Nous sommes entrés dans une ère où les barrières à l'entrée dans le secteur du développement logiciel se sont effondrées. Il ne s'agit pas d'une évolution progressive, mais d'une défaillance structurelle des mécanismes traditionnels de sélection des développeurs. Historiquement, la complexité de la syntaxe et le travail manuel que représentait l'implémentation faisaient office de filtre. Aujourd'hui, ce filtre a disparu.

Le développement logiciel n'est pas devenu simple. La simulation, en revanche, est devenue facile.

Le paysage actuel est marqué par une dangereuse asymétrie : l’IA réduit considérablement le coût de la génération de code, mais elle ne réduit pas – et ne peut pas réduire – le coût de la compréhension des systèmes logiciels complexes au même rythme. Nous assistons à l’industrialisation de la « démo », un phénomène où les artefacts visuels des logiciels sont produits à une vitesse qui dépasse largement l’intégrité architecturale nécessaire à leur maintien.

Cela crée une illusion de « code virtuel ». Pour un œil non averti, une URL fonctionnelle est indiscernable d'un système en production. Pour le marché, un ensemble de fonctionnalités déployé rapidement apparaît comme un avantage concurrentiel. En réalité, nous accumulons des risques systémiques à un rythme exponentiel. Si personne ne comprend votre environnement d'exécution, vous n'avez pas de produit. Vous avez une illusion qui se compile.

Archétype n° 1 — Le codeur d'ambiance : l'architecte de la surface

Le Vibe Coder est le principal bénéficiaire de la disparition des barrières à l'entrée. Cet archétype est souvent non technique ou semi-technique ; il utilise des outils de « programmation intuitive » comme Replit ou Lovable pour créer des logiciels par la seule force de son intention. Pour le Vibe Coder, le logiciel est un exercice esthétique. Si l'interface répond et que l'URL est résolue, le développement est considéré comme « terminé ».

L'esthétique de la mise en œuvre

Vibe Coder privilégie l'esthétique et la rapidité. L'entreprise peut « déployer » une application d'apparence fonctionnelle en quarante-huit heures et la partager en interne pour susciter immédiatement l'enthousiasme des parties prenantes. Cependant, cette rapidité est obtenue au détriment des piliers fondamentaux du génie logiciel : les serveurs, les bases de données persistantes et les protocoles de sécurité.

Le Vibe Coder fonctionne exclusivement dans le cadre d'un fonctionnement optimal. Son code est un assemblage de fragments qui répondent aux exigences immédiates d'une démo, mais ne possèdent aucune logique interne pour gérer l'entropie d'un environnement réel. Dans l'univers du Vibe Coder, une URL fonctionnelle est l'objectif final, sans tenir compte du fait qu'une URL n'est qu'un pointeur vers un noyau potentiellement vide.

Le mirage de l'achèvement

Le danger des développeurs à l'esthétique tape-à-l'œil ne réside pas dans leur manque de compétences, mais dans leur confusion entre apparence et ingénierie. Ils créent des produits « chouchous » – des outils que la communauté adore car ils résolvent un problème superficiel – sans comprendre que « la rentabilité vient après l'engouement », et seulement si le produit fonctionne réellement. Lorsqu'une démonstration d'un développeur à l'esthétique tape-à-l'œil est prise pour un produit, cela crée un précédent dangereux pour l'organisation, laissant croire que le « vrai » travail d'ingénierie peut être négligé.

Archétype n° 2 — Le gestionnaire d'invites : l'orchestrateur du code anonyme

Le Gestionnaire de sprints est souvent un développeur chevronné qui est passé du rôle de programmeur à celui d'orchestrateur d'agents. Il utilise des LLM pour gérer les audits de sécurité, les frameworks de test et la génération de code standard à une vitesse impressionnante. Il livre rapidement. Il respecte les délais. C'est le héros du sprint.

L'érosion de l'intention architecturale

L'échec du gestionnaire de processus est subtil : la perte de la maîtrise de l'architecture. En avançant à une vitesse fulgurante, il sacrifie le temps de réflexion nécessaire pour définir précisément ce qui est construit. L'architecture n'est pas un assemblage de fragments fonctionnels ; c'est une stratégie cohérente de gestion de l'état, des flux et des erreurs.

Lorsque le code est généré par invite plutôt que conçu, l'architecture sous-jacente commence à se dégrader. Le gestionnaire d'invites devient un simple passager dans son propre code, incapable de prendre en compte les interactions subtiles entre les modules générés. Il gère un système dont les invariants internes — les règles à ne jamais enfreindre — lui sont même inconnus.

L'illusion de la productivité

Le responsable de la sécurité confond progrès visible et progrès technique. Il croit, à tort, que la présence d'« agents de sécurité » garantit la sécurité de son système. Les audits de sécurité automatisés constituent un minimum, non une garantie. Sans une compréhension approfondie de l'environnement d'exécution, ce responsable bâtit une organisation superficielle : il gaspille ressources et énergie pour s'imposer, tandis que les fondations techniques se dégradent. Il livre un code qu'il ne peut plus expliquer.

Archétype n° 3 — L'ingénieur système : le gardien de l'exécution

L'ingénieur système est le seul archétype à reconnaître l'illusion pour ce qu'elle est. Il utilise l'IA — et peut-être même plus efficacement que les autres — mais il conserve la maîtrise absolue du cœur du système. Pour l'ingénieur système, le code est la partie la moins importante du logiciel. Les éléments les plus importants sont les invariants, les modes de défaillance et l'observabilité.

Appropriation de la complexité

L'ingénieur système sait que la difficulté de son métier n'a jamais été de faire apparaître quelque chose à l'écran. Le plus difficile est de garantir le bon fonctionnement du système lorsque les données doivent être stockées correctement, lorsque des cas particuliers surviennent et lorsque la maintenance du système s'impose six mois plus tard.

Ils considèrent l'IA comme un stagiaire très performant, et non comme un architecte principal. Chaque ligne de code générée par l'IA est soumise à une validation rigoureuse par rapport aux invariants du système. Ils se concentrent sur le comportement à l'exécution : comment le code se comporte réellement sous charge, dans un environnement distribué ou lors d'une panne réseau partielle.

Le manifeste de l'ingénierie

Pour l'ingénieur système, une invite n'est pas de l'architecture. L'ingénierie est la discipline qui consiste à transformer une illusion générée par l'IA en quelque chose de réel. Ses priorités sont :

Invariants : Définition des vérités constantes de l'état du système
Observabilité : Concevoir des systèmes qui expliquent leur propre état interne aux opérateurs
Modes de défaillance : Anticiper les défaillances du système et concevoir une dégradation progressive
Évolutivité : Comprendre les limites théoriques des structures de données et des modèles de concurrence choisis

L'ingénieur système est celui qui empêche le produit de sombrer dans le « marasme économique ». Il comprend que si l'IA peut générer le « quoi », l'humain doit toujours définir et justifier le « comment » et le « pourquoi ».

Pourquoi les managers se font avoir : la psychologie de la démo

Le moment le plus dangereux du cycle de vie d'un produit est la première démonstration réussie. Les parties prenantes non techniques voient une interface utilisateur fonctionnelle sur une URL déployée et demandent immédiatement : « Pourquoi ne pouvons-nous pas simplement commercialiser cela ? ».

Le piège de la visibilité

Les gestionnaires et les investisseurs en capital-risque sont naturellement enclins à réagir aux progrès visibles. À leurs yeux, si l'interface utilisateur est achevée à 90 %, le projet l'est aussi à 90 %. Ils ne voient ni le système dorsal inexistant, ni la base de données non chiffrée, ni les problèmes de concurrence dans le modèle de gestion des accès concurrents.

Le mirage du codage Vibe exploite ce biais cognitif. Il présente le « visible » comme le « précieux ». Cette pression pousse les équipes d'ingénierie à « aller plus vite », ce qui ne fait qu'accélérer l'accumulation d'une complexité non maîtrisée.

Le chouchou contre le flambeur

Sur le marché actuel, les dirigeants recherchent le succès immédiat, le produit chouchou de la communauté. Ils utilisent des démos pour lever des fonds, tels des flambeurs, dilapidant leurs liquidités dans la distribution. Mais sans la rigueur d'un ingénieur système, ces entreprises disparaissent en moins de 14 mois. La démo leur a permis d'obtenir le rendez-vous ; l'absence de produit a causé leur perte.

Le coût caché de la complexité : la dette invisible

L'IA amplifie la complexité. En réduisant les obstacles à la production de code, elle encourage la création de systèmes plus vastes et plus complexes que ce qu'un être humain, voire une équipe, peut appréhender pleinement.

Érosion architecturale et dette technique

Lorsque nous utilisons des agents pour « avancer à toute vitesse », nous négligeons souvent la phase de conception. Nous passons sous silence les exigences et les documents de conception dont l'humain et l'IA ont besoin pour bien comprendre l'objectif. Cela conduit à une érosion de l'architecture, où la structure du système devient un assemblage disparate d'optimisations locales incohérentes à l'échelle globale.

Le mur de la concurrence et de la scalabilité

L'IA est notoirement mauvaise pour raisonner sur la concurrence et les modes de défaillance dans les systèmes distribués. Elle peut générer une boucle d'événements, mais elle est incapable de prédire son comportement face à un problème de forte concurrence. Elle peut écrire une requête SQL, mais elle ne comprend pas les implications de cette requête en termes de scalabilité sur un ensemble de données de plusieurs téraoctets.

À mesure que le code source s'étoffe, la charge cognitive liée à la compréhension du système augmente de façon exponentielle. Le goulot d'étranglement se déplace : il ne s'agit plus du nombre de lignes de code que l'on peut écrire, mais de la quantité d'informations du système existant que l'on peut assimiler simultanément.

L'avenir de l'ingénierie : la compréhension comme valeur fondamentale

L'avenir de la valeur du génie logiciel se déplace de la syntaxe vers l'orchestration système de haut niveau et les modèles d'exécution.

Le passage à l'orchestration

Dans un monde où le code est devenu une ressource courante, la valeur de l'ingénieur réside dans sa capacité à gérer les systèmes distribués, les boucles d'événements et les systèmes asynchrones. Le nouveau défi n'est plus d'écrire la fonction, mais de s'assurer que ses effets de bord sont observables et réversibles.

Le mandat d'observabilité

Nous nous dirigeons vers un avenir où nous devrons gérer des logiciels que nous n'avons pas écrits. L'observabilité devient ainsi la discipline d'ingénierie la plus cruciale. Si la lecture du code ne nous permet pas de le comprendre, nous devons l'observer s'exécuter. Cela exige une connaissance approfondie de la télémétrie, du traçage et de l'agrégation des journaux.

Les ingénieurs qui réussiront seront ceux qui sauront définir les invariants et utiliser l'IA pour concevoir les mécanismes qui les garantissent. Ils seront les architectes de systèmes robustes, non pas parce que chaque ligne de code est parfaite, mais parce que l'architecture du système est conçue pour résister à l'imperfection.

Références et bibliographie

Sources primaires

Karpathy, A. (2025, 2 février). Article sur X présentant le « codage par vibrations »

MIT Technology Review. (16 avril 2025). Qu'est-ce que le codage vibratoire, exactement ?

Bencoding. (2026, 20 avril). Démo vs IA opérationnelle : la confusion la plus coûteuse en IA

Uphack. (s.d.). L'illusion du bâtiment

He, Y., et al. (2026). La dette derrière le boom de l'IA : une étude empirique à grande échelle du code généré par l'IA en conditions réelles. arXiv.

Winters, T., Manshreck, T. et Wright, H. (2020). Le génie logiciel chez Google : leçons tirées de la programmation au fil du temps (Chap. 10, Documents de conception). O'Reilly. https://abseil.io/resources/swe-book/html/ch10.html

Forsgren, N., Humble, J., et Kim, G. (2018). Accelerate : la science du logiciel agile et du DevOps. IT Revolution Press.

Stack Overflow. (31 juillet 2025). Les outils de programmation IA aident-ils à lutter contre le syndrome de l'imposteur ou l'aggravent-ils ?

CB Insights. (2025). Pourquoi les startups échouent : principales raisons

Consultation Myriade. (2022). Entreprises : comment résister aux crises grâce à la frugalité ?

Littérature scientifique et technique

Brooks, FP (1975). Le mythe du mois-homme. Addison-Wesley.

Dijkstra, EW (1989). Sur la cruauté de l'enseignement réel de l'informatique. Communications of the ACM, 32(12). https://doi.org/10.1145/76380.76381

Vogels, W. (2008). Eventually consistent. ACM Queue, 6(6). https://doi.org/10.1145/1466443.1466448

DORA. (2023). Rapport sur l'état du DevOps. Google Cloud.

Amdahl, GM (1967). Validité de l'approche monoprocesseur pour l'obtention de capacités de calcul à grande échelle. Actes de la conférence AFIPS. https://doi.org/10.1145/1465482.1465560

Conclusion finale

Le mirage du codage visuel est un chant de sirène pour l'ère moderne. Il promet les avantages de l'ingénierie sans l'effort de compréhension. Mais le logiciel n'est pas un média visuel ; c'est un média structurel.

Il nous faut revenir aux fondamentaux : exécution, observabilité et invariants. Si nous continuons à confondre la démo avec le produit, nous ne bâtissons pas un avenir numérique ; nous construisons un cimetière numérique.

« Si vos agents de codage disparaissaient demain, quelle part de votre code source comprendriez-vous encore vraiment ? »

Diagnostic brutal

Sécurisé : Vous pouvez expliquer chaque transition d'état de votre système et recréer le modèle mental de l'architecture à partir de zéro lors d'une session de tableau blanc. Dangereux : Vous vous fiez à l'IA pour expliquer le comportement de « votre » code lorsqu'un bug apparaît. Vous ne disposez d'aucun document de conception ni d'invariants enregistrés. Dépendance critique : Vous ne pouvez ni déployer, ni déboguer, ni faire évoluer votre système sans qu’une fenêtre LLM soit ouverte. Vous êtes comme un passager dans un véhicule sans volant.

🤖 Veille Darkwood - 2026-06-18

Mathieu Ledru — Thu, 18 Jun 2026 08:24:54 +0000

Points saillants

Utilitaire : Mailway redirige vos liens mailto dans la bonne app
- Vous avez un Mac, mais vous jonglez entre plusieurs apps ou services de mail ? Sur macOS, cliquer sur une adresse mail ou sur un lien de contact, les fameux liens mailto, ouvre toujours l’app de mail définie par défaut....
La pénurie de RAM va bien peser sur les prix d'Apple
- Apple a réussi ce qui ressemble à un miracle il y a peu. Alors que tout le monde augmentait le prix des appareils électroniques à cause de la flambée du cours de la RAM, la société a réussi à en augmenter la dotation à...
Apple : faut-il acheter maintenant avant que les prix augmentent ?
- Il y a quelques semaines, Carl Pei s’était fait remarquer par une déclaration pour le moins abrupte : « Si vous songez à remplacer votre téléphone, le meilleur moment, c'était hier ». Sous ses airs de provocation, le pa...
Nouvelle Google Home : une enceinte connectée taillée pour Gemini
- Après plusieurs années à vivre dans l'ombre de la marque Nest, Google Home fait son retour. Nouvelle enceinte, nouveau design, nouvel assistant : Google profite de l'occasion pour confier les clés de la maison connectée...

🚨 Premium content.
⬆️ Upgrade to access full analysis.
👉 Subscribe here : https://www.bonzai.pro/matyo91/shop/48ov_2168/automation-avec-flow-en-php

🤖 Veille Darkwood - 2026-06-17

Mathieu Ledru — Wed, 17 Jun 2026 19:26:45 +0000

Points saillants

HE.SHE.THEY. Embarks on East Asian Pride Month Tour
- The HE.SHE.THEY Asia Tour is the LGBTQ+ outfit’s biggest to date, and it kicked off with the largest-ever Pride event in Nepal. HE.SHE.THEY has cemented itself as one of the world’s most prominent LGBTQ+ nightlife brand...
Party Crashers? No Worry! These New Games Handle Up To 6+ Players!
- by Steph Hodge How about some games that will play with a higher player count? Here are a whole bunch of releases coming soon that will handle up to 6 or more players![imageid=9389228 medium rep]▪️ Synapses Games announ...
Designer Diary: boop. Shuffle
- by Scott Brady Three years later and I am no better at keeping ongoing notes about my design journey than I was when I penned the Designer Diary for boop. I usually become so focused on my projects that I’ve never found...
Life on a canal boat, 18 months in!
- Last year the electric van I'd been living in for three years was destroyed in a crash on the motorway. Thankfully I'd just bought a canal boat, or I would be homeless.Living in a tiny electric van for three yearsIn Oct...

🤖 Veille Darkwood - 2026-06-16

Mathieu Ledru — Tue, 16 Jun 2026 10:32:46 +0000

Points saillants

New in Symfony 8.1: Tui Component
- Contributed by Fabien Potencier in #63778 A new generation of terminal tools (AI coding assistants, log viewers, interactive dashboards, file managers, etc.) share something the Console component was never meant to do:...
Fragments: June 16
- “Prag Dave” Thomas (co-author of the outstanding “Pragmatic Programmer”) has loved programming since he was young. Programming was how I could express myself. I wasn’t an artist. When I sing, dogs howl. When I draw, fri...
Symfony: The Fast Track, now in nine languages
- Earlier this week, I announced the Symfony 8.1 edition of The Fast Track. If you made it to the end of that post, you read that the book was available in five languages. That line is already out of date, and I could not...

😶‍🌫️ This person does not exist - PHP synchrone à l'orchestration asynchrone avec Flow

Mathieu Ledru — Sat, 13 Jun 2026 14:25:19 +0000

Vous devez télécharger dix images depuis une API distante. Entre chaque requête, vous attendez une seconde pour respecter un rate limit. Chaque image suit le même chemin : fetch, hash, sauvegarde, reporting.

Le code ressemble à une boucle for familière. Il fonctionne. Mais pendant qu'une image télécharge, les neuf autres attendent. Pendant qu'une fibre dort sur un sleep(), tout le processus est figé. Les unités de travail sont indépendantes — seule l'orchestration les traite comme si elles ne l'étaient pas.

C'est le problème concret que nous avons isolé dans le projet flow-thispersondoesnotexist : une commande Symfony minimale qui récupère plusieurs images depuis ThisPersonDoesNotExist et les sauvegarde sur disque.

L'objectif n'était pas de télécharger des images plus rapidement.

L'objectif était de comprendre comment faire évoluer une exécution séquentielle vers une orchestration asynchrone avec darkwood/flow — sans changer la logique métier, en changeant le modèle d'exécution.

La transition se résume en deux commits :

fae47e8 — commande app:fetch-thispersondoesnotexist, boucle synchrone
c61c929 — même commande, orchestrée par Flow et FiberDriver

Un seul fichier change entre les deux : src/Command/FetchThisPersonDoesNotExistCommand.php.

Le point de départ : une boucle synchrone

La première version (fae47e8) utilise une boucle for classique. Fetch, hash, sauvegarde et reporting sont exécutés inline ; un sleep(1) bloque le processus entre chaque téléchargement :

$savedFiles = [];

for ($index = 1; $index <= $count; ++$index) {
    if ($count > 1) {
        $this->io->section(sprintf('Download %d/%d', $index, $count));
    }

    try {
        $image = $this->fetchImage();
        $checksum = $this->computeChecksum($image);
        $filename = $this->generateFilename($checksum, $file);
        $outputPath = $this->saveFile($filename, $image);
        $this->report($outputPath, $checksum, \strlen($image));
    } catch (\RuntimeException $exception) {
        $this->io->error($exception->getMessage());

        return Command::FAILURE;
    }

    $savedFiles[] = $outputPath;

    if ($index < $count) {
        $this->io->note(sprintf('Waiting %d second(s) before next download...', self::DOWNLOAD_DELAY_SECONDS));
        sleep(self::DOWNLOAD_DELAY_SECONDS);
    }
}

Le fonctionnement est linéaire : télécharger, traiter, attendre, passer à l'image suivante. Chaque étape bloque entièrement le processus — y compris le sleep(), qui immobilise le programme même quand aucun travail utile n'est en cours.

Cette approche est facile à comprendre, mais elle gaspille les temps d'attente I/O : tant qu'une image n'est pas terminée, aucune autre ne peut avancer.

À noter : la version synchrone conservait aussi une méthode alternative fetchImageViaFileGetContents(). Elle sera supprimée dans la version Flow — les streams explicites (fopen) sont préférés pour la suite.

Observer le workflow caché

Derrière la boucle se cache un pipeline répété pour chaque image :

Fetch Image → Save Image → Report Result

Image #1 : Fetch → Save → Report
Image #2 : Fetch → Save → Report
Image #3 : Fetch → Save → Report

Chaque image est une unité de travail autonome. La question devient alors : pourquoi attendre la fin complète de l'image #1 avant de démarrer l'image #2 ?

Avant / Après : le changement architectural

Avant l'introduction de Flow, l'exécution est strictement séquentielle :

Image 1 → Fetch → Save → Sleep
Image 2 → Fetch → Save → Sleep
Image 3 → Fetch → Save → Sleep

Après, les unités de travail sont planifiées indépendamment et traversent un pipeline commun :

Image 1 ─┐
Image 2 ─┼─> Flow Pipeline (Fetch → Save + Report) ─> résultats
Image 3 ─┘

Le for ne pilote plus l'exécution étape par étape. Il enqueue des Ip (unités de travail). Flow orchestre leur passage dans le pipeline ; await() synchronise à la fin.

Introduire Flow

La dépendance darkwood/flow est ajoutée au projet avant la commande (e71899a). La version c61c929 l'utilise enfin pour orchestrer le travail.

Les imports introduits :

use Flow\Driver\FiberDriver;
use Flow\ExceptionInterface;
use Flow\FlowFactory;
use Flow\Ip;

Chaque image devient une unité de travail indépendante.

Dans Flow, cette unité est représentée par un Ip (Instruction Pointer) :

$flow(new Ip($index));

Le pipeline est décrit sous forme d'étapes avec FlowFactory et un générateur :

$driver = new FiberDriver();
$savedFiles = [];

$flow = (new FlowFactory())->create(function () use ($file, &$savedFiles, $driver) {
    yield [
        fn (int $index) => $this->fetchImage($index, $driver),
        fn (ExceptionInterface $exception) => throw new \RuntimeException($exception->getMessage()),
    ];
    yield function (string $image) use ($file, &$savedFiles): string {
        $outputPath = $this->saveAndReport($image, $file);
        $savedFiles[] = $outputPath;

        return $outputPath;
    };
}, ['driver' => $driver]);

for ($index = 1; $index <= $count; ++$index) {
    $flow(new Ip($index));
}

try {
    $flow->await();
} catch (\RuntimeException $exception) {
    $this->io->error($exception->getMessage());

    return Command::FAILURE;
}

Conceptuellement, cela revient à écrire :

Ip($index)
 ↓
Fetch Image        ← étape async (fiber + delay)
 ↓
Save + Report      ← étape suivante, reçoit le string image

Chaque image traverse exactement le même pipeline.

Les responsabilités sont extraites en méthodes dédiées :

fetchImage(int $index, FiberDriver $driver): string — téléchargement, avec suspension cooperative
saveAndReport(string $image, ?string $fileOverride): string — hash, sauvegarde, reporting

La gestion d'erreur quitte la boucle : un errorJob sur l'étape fetch relance une RuntimeException, capturée une seule fois autour de await().

Remplacer l'attente bloquante

Le changement le plus important concerne la gestion du temps d'attente.

Dans la version synchrone, le délai est global et bloquant :

private const int DOWNLOAD_DELAY_SECONDS = 1;

// dans la boucle, entre chaque image :
sleep(self::DOWNLOAD_DELAY_SECONDS);

Dans la version Flow, le délai est par fibre et cooperative :

private const int DELAY_MIN_SECONDS = 1;
private const int DELAY_MAX_SECONDS = 3;

// dans fetchImage(), avant le téléchargement :
$delay = random_int(self::DELAY_MIN_SECONDS, self::DELAY_MAX_SECONDS);
$this->io->note(sprintf('#%d: suspending fiber for %ds before download...', $index, $delay));
$driver->delay($delay);

$driver->delay() suspend uniquement la fibre en cours. Les autres fibres continuent :

Image #1 attend (delay 2s)
Image #2 télécharge
Image #3 sauvegarde
Image #4 démarre son delay

Avec --count=5, le temps total se rapproche du max(delays + fetch) plutôt que de leur somme.

Les Fibers comme fondation d'exécution

Sous le capot, FiberDriver s'appuie sur les Fibers de PHP 8.1 : une Fiber peut être suspendue puis reprise plus tard, ce qui permet d'exécuter plusieurs traitements indépendants avec une écriture proche du PHP classique.

$driver = new FiberDriver();

Chaque image dispose de sa propre Fiber. Lorsqu'une Fiber attend ($driver->delay()), les autres continuent leur progression. Le logging reflète ce comportement :

#2: suspending fiber for 2s before download...
#2: downloading (other fibers may run while this one waits)...
#2: fetch complete in 1.34s

Flow ne remplace pas les Fibers : il les utilise via un driver. Le choix du driver détermine comment le pipeline s'exécute ; la description du pipeline reste identique.

Le point de synchronisation

Le for enqueue les unités de travail :

for ($index = 1; $index <= $count; ++$index) {
    $flow(new Ip($index));
}

await() devient le point de synchronisation unique :

$flow->await();

Planifier Ip(1)
Planifier Ip(2)
Planifier Ip(3)
…
await() — barrière finale

La responsabilité de l'orchestration est déplacée vers Flow. Le for ne fait plus le travail : il enqueue des unités. Flow les exécute en parallèle ; await() attend que tout le pipeline soit terminé.

Pourquoi conserver les Streams PHP ?

Le projet utilise volontairement :

$stream = fopen(self::FETCH_URL, 'r', false, $context);
$content = stream_get_contents($stream);

plutôt que file_get_contents().

L'objectif n'est pas de réinventer un client HTTP.

L'objectif est de rester proche des primitives PHP — le commentaire du code le dit explicitement :

Preferred for Flow experimentation: the resource handle is the primitive that can later be wired to stream_select(), non-blocking mode, or fibers.

Ces primitives pourront ensuite évoluer vers :

stream_set_blocking(false);
stream_select(...);

ou être intégrées dans des drivers plus avancés (Amp, React, Swoole — tous supportés par darkwood/flow).

Les streams constituent une base naturelle pour expérimenter les modèles asynchrones en PHP.

Limiter la concurrence (étape suivante)

Dans ce POC, toutes les images partent en parallèle (jusqu'à --count fibres actives).

Pour un usage production, Flow propose des stratégies comme MaxIpStrategy :

use Flow\IpStrategy\MaxIpStrategy;

yield [$job1, $errorJob1, new MaxIpStrategy(5)];

L'exemple officiel du package (examples/flow.php) utilise MaxIpStrategy(2) pour plafonner le nombre de jobs simultanés sur chaque étape.

Ce n'est pas encore branché dans flow-thispersondoesnotexist, mais c'est le levier naturel pour du rate limiting sans retomber dans du sleep() séquentiel.

Un modèle applicable bien au-delà des images

L'exemple ThisPersonDoesNotExist est volontairement simple. Le même schéma se retrouve dans les pipelines Darkwood :

Scraping YouTube     → Lister → Télécharger / transcrire → Sauvegarder
Traitement vidéo     → Générer assets → Encoder → Persister
Agent IA             → Lire → Transformer → Publier

Dans tous les cas : des unités de travail indépendantes qui traversent une succession d'étapes. Flow ne cherche pas à exécuter une tâche — il orchestre des flux de tâches.

Récapitulatif de la migration

Aspect	`fae47e8` (synchrone)	`c61c929` (Flow)
Boucle	`for` avec fetch/save inline	`for` enqueue + `$flow->await()`
Délai	`sleep(1)` global	`$driver->delay()` par fibre
Erreurs	`try/catch` dans la boucle	`errorJob` + `catch` sur `await()`
Fetch	`fetchImage()`	`fetchImage($index, $driver)`
Save	inline	`saveAndReport()`
Concurrence	aucune	fibres parallèles via `FiberDriver`

Ce que Flow n'est pas

Avant de conclure, une clarification utile pour éviter les confusions courantes.

Flow n'est pas une event loop. Il ne gère pas directement un cycle select / poll sur des descripteurs I/O.

Flow n'est pas une implémentation de Fibers. Les Fibers sont une primitive PHP 8.1. Flow les orchestre via des drivers, mais ne les remplace pas.

Flow n'est pas un runtime. Il ne modifie pas le modèle d'exécution de PHP. Il s'exécute dans un processus PHP standard.

Flow n'est pas un substitut à Amp, ReactPHP ou Swoole. Ces bibliothèques fournissent des runtimes et des boucles d'événements. Flow peut s'appuyer dessus — AmpDriver, ReactDriver, SwooleDriver — sans entrer en concurrence avec elles.

Ce que Flow apporte, c'est un modèle d'orchestration :

décrire des unités de travail (Ip)
composer des pipelines d'étapes (yield dans FlowFactory)
déléguer l'exécution à un driver choisi (FiberDriver, AmpDriver, ReactDriver, SwooleDriver, …)

Le modèle d'orchestration est séparé du modèle d'exécution. On peut décrire un pipeline une fois, puis changer de driver selon le contexte — CLI avec Fibers, worker Swoole, service React — sans réécrire la logique métier.

Conclusion

Le passage du synchrone vers l'asynchrone n'est pas avant tout une question de performance.

C'est un changement de modèle mental :

Avant : exécuter l'opération A, puis B, puis C — et attendre entre chaque étape.

Après : décrire un pipeline, enqueue des unités de travail,
        laisser l'orchestrateur planifier l'exécution.

La boucle for devient un producteur d'Ip. Les étapes fetch et save deviennent des jobs chaînés. await() remplace la succession de sleep(). La logique métier (télécharger, hasher, sauvegarder) reste la même ; ce qui change, c'est qui décide quand chaque étape s'exécute.

C'est exactement le modèle dont Darkwood a besoin pour ses pipelines à venir : scraping YouTube et extraction de transcripts, traitement média dans MediaBundle, agents IA multi-étapes, orchestration de workflows longue durée. Des unités indépendantes, des étapes composables, un point de synchronisation explicite.

Le projet ThisPersonDoesNotExist en est la démonstration minimale : un seul fichier, un pipeline à deux étapes, un driver — suffisant pour illustrer la transition sans en masquer la portée.

Pour aller plus loin

Dépôt du POC : flow-thispersondoesnotexist — commits fae47e8 → c61c929
Package : darkwood/flow — exemple examples/flow.php
L'article de Frédéric Bouchery retrace l'histoire de la programmation asynchrone en PHP, depuis les streams introduits dans PHP 4.3 jusqu'aux Fibers modernes de PHP 8.1 : https://f2r.github.io/fr/asynchrone.html

🚀 Darkwood v8.1.0 disponible

Mathieu Ledru — Sun, 07 Jun 2026 13:18:33 +0000

Darkwood v8.1.0 vient d'être publié.

⬆️ Mise à jour vers Symfony v8.1.0
✨ Ajouter le recteur dans les outils

🏷️ Journal des modifications complet v8.0.13...v8.1.0

🚀 Darkwood-com v1.0.6 disponible

Mathieu Ledru — Sun, 07 Jun 2026 11:33:58 +0000

Darkwood-com v1.0.6 vient d'être publié.

⬆️ Mise à jour vers Symfony 8.1
✨ Ajouter Navi
🔐 Ajouter du contenu premium
🚀 Ajouter une section de publication de blog et des émojis
✨ Réaction à l'ajout d'un article API
🔥 Nettoyage

Journal des modifications complet v1.0.5...v1.0.6

💫 Le Grand BBQ Polytech Paris-Saclay 2026 : trente ans de transformations technologiques

Mathieu Ledru — Sun, 07 Jun 2026 07:17:02 +0000

Le samedi 6 juin 2026, les anciens élèves de Polytech Paris-Saclay se sont réunis à la Maison de l’Ingénieur à Orsay pour le traditionnel Grand BBQ organisé par l’association des Alumni.

Chaque année, cet événement permet aux différentes promotions de se retrouver autour d’un moment simple : discuter, partager des souvenirs et revoir celles et ceux avec qui une partie de leur parcours d’ingénieur s’est construite.

Polytech Paris-Saclay est l’école d’ingénieur interne à l’Université Paris-Saclay et fait partie du réseau Polytech depuis 2010, considéré comme le premier réseau français de formation d’ingénieurs.

Installée au cœur du plateau de Saclay, l’école forme aujourd’hui près de 1000 élèves ingénieurs autour de quatre grandes spécialités :

électronique et informatique pour l’embarqué
informatique et ingénierie mathématique
matériaux, mécanique et énergie
photonique et systèmes optroniques

Une école avant l’école

L’établissement s’appuie également sur une vingtaine de laboratoires de recherche et un important réseau d’entreprises partenaires, dans un environnement où se croisent recherche scientifique, ingénierie et innovation technologique.

L’édition 2026 du Grand BBQ réunissait notamment plusieurs promotions anniversaires, avec une attention particulière portée aux diplômés de 1986, 1996, 2006 et 2016.

Dès l’arrivée sur le campus, quelque chose frappait immédiatement : le contraste entre les générations présentes.

Avant de devenir Polytech Paris-Saclay, l’établissement portait le nom de NFI-FIIFO, la Formation d’Ingénieur en Informatique de la faculté d’Orsay.

À cette époque, l’école ne ressemblait pas encore à une grande école d’ingénieurs telle qu’on l’imagine aujourd’hui.

Pas de véritable bâtiment.
Pas de campus structuré.
Pas de salle informatique moderne.
Parfois même pas assez de budget pour le ménage.

Les étudiants suivaient leurs cours dans les locaux de l’IUT d’Orsay, dans un environnement encore très expérimental. La Maison de l’Ingénieur n’existait pas encore réellement. Sa construction fut retardée après la découverte d’une villa gallo-romaine sur le site prévu pour les fondations. Certains anciens évoquaient une époque où l’école ne disposait pas encore réellement de locaux dédiés, où les cours étaient parfois répartis entre plusieurs bâtiments et où l’informatique fonctionnait avec des moyens bien plus limités qu’aujourd’hui.

Et pourtant, malgré ces contraintes, quelque chose était déjà là.

Une culture.

D’autres échangeaient naturellement autour des sujets actuels :

intelligence artificielle
cloud computing
cybersécurité
simulation
calcul distribué
ou encore évolution des métiers du numérique

Au fil des discussions, une idée revenait souvent :
les technologies changent rapidement, mais certaines fondations restent étonnamment stables.

Curiosité technique.
Capacité d’adaptation.
Culture scientifique.
Et volonté de construire des systèmes capables d’évoluer avec leur époque.

L’organisation de la journée était assurée par le bureau des Alumni de Polytech Paris-Saclay, avec notamment une session de prises de parole organisée en début d’après-midi pour les promotions anniversaires.

Entre mémoire étudiante et évolution technologique

La partie la plus marquante de l’après-midi fut probablement la série de discours réalisés par les anciennes promotions.

Au-delà de l’aspect nostalgique, ces prises de parole retraçaient surtout plusieurs décennies d’évolution de l’enseignement informatique et du paysage technologique français.

Les anciens élèves évoquaient une époque où l’école portait encore un autre nom, avant les regroupements successifs ayant conduit à la création de l’IFIPS puis à l’intégration au réseau Polytech.

À travers les souvenirs racontés, on découvre surtout une autre manière d’apprendre l’informatique.

Les promotions des années 80 et 90 décrivaient un environnement beaucoup plus artisanal :

peu de moyens matériels
peu de machines
peu de locaux dédiés
des ressources limitées
des temps de calcul longs
et une forte culture débrouillarde

Certains rappelaient que la Maison de l’Ingénieur n’existait même pas encore au début de leur cursus.
Les cours étaient alors répartis entre plusieurs bâtiments du campus d’Orsay, dans une période où les infrastructures informatiques universitaires restaient encore en construction.

Un autre sujet revenait régulièrement dans les discussions :
les débuts d’Internet.

Les anciens parlaient des premières architectures TCP/IP, des calculs réalisés sous MATLAB, des travaux autour des réseaux neuronaux ou encore des contraintes techniques qui imposaient une véritable rigueur dans l’utilisation des ressources machines.

À une époque où quelques secondes d’animation pouvaient nécessiter des heures de calcul, l’informatique se pratiquait dans un rapport beaucoup plus direct aux limites matérielles.

Les discours mettaient également en avant un élément souvent oublié aujourd’hui :
la dimension humaine des écoles d’ingénieurs.

Plusieurs anciens racontaient la création d’associations étudiantes, l’organisation de galas, de séjours au ski ou d’événements destinés à donner une identité collective à des promotions qui cherchaient encore leur place dans le paysage des grandes écoles françaises.

Cette volonté de “faire exister l’école” revenait souvent dans les témoignages.

Et avec le recul, ces initiatives racontent aussi l’évolution du rôle de l’ingénieur lui-même.

L’ingénieur moderne n’est plus uniquement un technicien spécialisé.
Il évolue désormais dans des environnements où la communication, l’adaptation et la collaboration deviennent aussi importantes que les compétences purement techniques.

Les parcours évoqués pendant les discours reflétaient parfaitement cette diversité :

défense
aérospatial
banque
industrie
recherche
administration
international
entrepreneuriat

À travers ces trajectoires très différentes, un point commun restait visible :
la capacité de l’informatique à évoluer constamment, tout en conservant certaines bases fondamentales.

Les technologies changent rapidement.
Les outils se transforment.
Les usages explosent.

Mais les fondations scientifiques évoquées dans les discours — mathématiques, réseaux, algorithmique, calcul, modélisation — restent encore aujourd’hui au cœur des systèmes modernes.

Photo des promotions anniversaire

Une évolution qui dépasse les générations

Ce qui ressort finalement de cette journée, ce n’est pas uniquement la nostalgie des anciennes promotions.

C’est surtout la manière dont plusieurs générations d’ingénieurs ont traversé différentes transformations majeures de l’informatique :

les débuts des réseaux
l’arrivée d’Internet
la démocratisation du web
l’explosion du mobile
le cloud computing
l’industrialisation des infrastructures
et désormais l’accélération autour de l’intelligence artificielle

En écoutant les échanges entre anciens élèves, on réalise rapidement que chaque génération a eu l’impression de vivre une période de rupture technologique.

Pour certains, cette rupture fut Internet.
Pour d’autres, le web.
Aujourd’hui, elle prend la forme de l’IA générative et des nouveaux usages qui l’accompagnent.

Et pourtant, malgré ces évolutions successives, les discours rappelaient une réalité assez simple :
les fondamentaux restent souvent les mêmes.

Comprendre un système
Analyser un problème
Modéliser
Optimiser
Construire
Tester
S’adapter

Les outils évoluent énormément, mais la logique d’ingénierie reste étonnamment stable.

Cette continuité se ressent particulièrement dans un environnement comme le plateau de Saclay, où se croisent depuis des décennies :

recherche scientifique
industrie
ingénierie
et innovation technologique

C’est un moment où différentes époques de l’informatique se rencontrent physiquement au même endroit.

Des générations qui ont connu les débuts des stations Unix échangent avec des ingénieurs travaillant aujourd’hui sur des infrastructures cloud ou des systèmes IA modernes.

Et au milieu de ces discussions, une chose devient évidente :
l’évolution technologique ne remplace pas réellement les générations précédentes.

Elle s’appuie sur elles.

Les systèmes modernes existent aussi grâce aux fondations construites par celles et ceux qui expérimentaient déjà les réseaux, les modèles mathématiques ou les architectures distribuées il y a plusieurs décennies.

Et evenement rappel finalement quelque chose d’assez rare dans l’industrie technologique actuelle :
l’informatique possède déjà sa propre mémoire collective.

Et cette mémoire continue de se transmettre, année après année, entre les promotions qui se succèdent sur le campus de Polytech Paris-Saclay.

Des trajectoires radicalement différentes

Trente ans plus tard, les parcours des anciens élèves sont devenus extrêmement variés.

Certains travaillent dans le luxe.
D’autres dans la défense, la banque, l’aérospatial ou l’administration.

Certains sont partis vivre au Mexique, en Suède ou en Suisse.
L’un a ouvert un SPA.
Un autre a construit un simulateur d’Airbus A320 en LEGO.

Le discours rappelle quelque chose d’essentiel :
une école d’ingénieur ne produit pas des trajectoires identiques.

Elle crée une base commune à partir de laquelle chacun construit son propre chemin.

Ce qu’il reste trente ans après

Le moment le plus fort du discours arrive probablement à la fin, lorsque les anciens s’adressent aux jeunes diplômés :

“Osez changer de poste, osez être vous-même, osez avoir vos propres convictions.”

Le message est simple.
Les carrières ne sont pas linéaires.
Les parcours techniques non plus.

Et peut-être que c’est précisément cela qui relie toutes ces générations :
la capacité à continuer à construire malgré l’incertitude.

En regardant ces promotions se retrouver trente ans plus tard, une autre évidence apparaît.

Les technologies changent.
Les frameworks changent.
Les langages changent.
L’intelligence artificielle transforme déjà l’industrie.

Mais certaines choses restent identiques :

la curiosité
la débrouillardise
la volonté de créer
et les liens humains construits autour de cette aventure commune qu’est l’informatique

Merci

Merci aux promotions pour leurs témoignages.
Merci aux anciens professeurs et aux équipes de Polytech Paris-Saclay.
Et merci aux organisateurs du Grand BBQ Alumni d’avoir permis à toutes ces histoires de se reconnecter, le temps d’un après-midi.

Dans une industrie obsédée par la nouveauté permanente, cette journée rappelait finalement une chose simple : derrière chaque rupture technologique se trouvent souvent plusieurs générations d’ingénieurs qui ont construit les fondations bien avant qu’elles deviennent visibles.

Parce qu’au final, derrière les technologies,
ce sont surtout des générations de personnes qui continuent d’exister ensemble.

🌟 HeroClip - Transformez vos conversations en flux de travail de génération vidéo

Mathieu Ledru — Sat, 06 Jun 2026 07:04:28 +0000

HeroClip - Et si créer des vidéos était aussi simple qu'une conversation ?

Créer des vidéos avec l'IA devrait être magique.
Mais aujourd'hui, c'est souvent une corvée.
On ouvre un outil pour écrire les instructions.
Un autre pour générer les visuels.
Un autre pour monter les scènes.
Un autre pour ajouter des transitions.
Un autre pour exporter le résultat final.
Et après tout ça ?
On passe encore des heures à peaufiner.
Et si on abordait le problème différemment ?
Et si créer une vidéo ressemblait plus à une conversation avec un créatif ?
C'est l'idée derrière HeroClip.

De la conversation à la vidéo

HeroClip est une application intégrée directement à ChatGPT.
Au lieu d'apprendre à utiliser un logiciel complexe, il suffit de partir d'une idée.
Par exemple :

« Créer un teaser de 12 secondes pour le lancement de mon produit.»

C'est tout.
À partir de là, HeroClip construit votre expérience vidéo de manière conversationnelle.
L'application propose d'abord plusieurs pistes créatives.
Vous pouvez les parcourir comme sur les réseaux sociaux :

lancement cinématographique
storytelling viral TikTok
récit émotionnel
publicité futuriste
révélation minimaliste. Dès qu'une piste vous semble pertinente, HeroClip génère automatiquement le storyboard. Puis la vidéo elle-même. Et le plus intéressant ? Vous pouvez poursuivre l'histoire naturellement, au fil de la conversation.

Une autre façon de créer du contenu

La plupart des outils vidéo IA sont encore conçus comme des logiciels traditionnels.
Chronologies.
Boutons.
Panneaux.
Éditeurs complexes.
HeroClip explore une autre voie :

L'IA comme partenaire créatif.

Au lieu d'imposer des flux de travail techniques aux utilisateurs, l'application se concentre sur :

les idées
la narration
l'itération
et la dynamique. Vous restez immergé dans la conversation tout au long du processus. Pas de changement d'outils. Pas de processus de montage complexe. Aucune configuration technique. Juste la créativité en mouvement.

Un flux de travail créatif intuitif

Nous avons rapidement compris que la créativité est rarement linéaire.
On ne sait généralement pas exactement ce qu'on veut du premier coup.
C'est pourquoi HeroClip propose des variantes.
L'application suggère plusieurs interprétations de votre idée pour vous permettre d'explorer rapidement différentes pistes avant de générer des ressources vidéo coûteuses.
L'expérience est ainsi beaucoup plus fluide :

découvrir des idées
choisir une ambiance
affiner le récit
poursuivre l'histoire. Le processus ressemble davantage à un brainstorming avec un directeur artistique qu'à l'utilisation d'un logiciel de montage traditionnel.

Une narration IA plutôt que la création de prompts

La création de prompts est un outil puissant.
Mais elle est aussi épuisante.
La plupart des gens ne souhaitent pas passer des heures à apprendre comment structurer des prompts pour chaque scène.
HeroClip simplifie cette complexité.
L'objectif est simple :

se concentrer sur l'histoire, pas sur les outils.
L'application gère :

les variantes

les storyboards

les flux de travail de génération

la continuité visuelle

et la création itérative de scènes. Vous, vous vous concentrez sur votre intention créative.

Conçu pour l'ère du contenu court

Internet est de plus en plus axé sur la vidéo.
TikTok.
Instagram Reels.
YouTube Shorts.
Teasers de produits.
Image de marque personnelle.
Micro-récits.
La demande de contenu court explose.
Mais produire du contenu en continu est difficile.
HeroClip a été conçu pour répondre à cette nouvelle réalité :

itération rapide
expérimentation rapide
flux de travail conversationnels
boucles de continuation infinies. L'idée n'est pas simplement de générer une seule vidéo. Il s'agit d'aider les créateurs à générer des histoires en continu.

Pourquoi ChatGPT change tout

HeroClip n'est pas seulement rendu possible par la génération vidéo par IA.
C'est l'émergence des applications conversationnelles.
Avec ChatGPT Apps et MCP (Model Context Protocol), les conversations elles-mêmes deviennent des expériences logicielles interactives.
La conversation n'est plus seulement du texte.
Elle devient :

une interface
un moteur de workflow
une mémoire créative
et un environnement narratif. Ceci ouvre des perspectives inédites pour la conception logicielle.

La vision

HeroClip est toujours en développement.
Mais la vision se précise :

La création de contenu doit être intuitive et conversationnelle.
Non technique.
Non fragmentée.
Non noyée sous des menus et des chronologies.
Vous devriez pouvoir :

décrire une idée

explorer des pistes créatives

générer du contenu

poursuivre l'histoire

et publier plus rapidement que jamais. Le tout, au fil d'une conversation.

L'avenir des outils créatifs

Nous pensons que la prochaine génération d'outils créatifs sera différente des logiciels traditionnels.
Ils seront plus collaboratifs.
Plus intuitifs.
Plus adaptatifs.
Moins « logiciels de montage ».
Plus « partenaires créatifs ».
HeroClip est une expérience dans ce sens.
Et ce n'est que le début

📍 Une journée à Rotterdam

Mathieu Ledru — Tue, 02 Jun 2026 08:53:20 +0000

Après la première journée passée à la TwitchCon Rotterdam 2026, j’ai décidé de consacrer mon dimanche à découvrir simplement la ville.

Le programme était finalement assez simple :

Rotterdam Centraal
balade dans le centre-ville
Markthal
Cube Houses
promenade en bateau
zoo
puis retour vers Zuidplein avant le bus du soir.

Et honnêtement, Rotterdam se prête très bien à ce genre de journée sans pression.

Arrivée à Rotterdam Centraal

La journée a commencé à Rotterdam Centraal.

Même sans être passionné par les gares, celle-ci impressionne immédiatement :
grande, moderne, très propre et surtout extrêmement fluide.

On sent que Rotterdam est une ville pensée autour :

des transports
du vélo
des piétons
et des déplacements rapides.

Depuis la gare, beaucoup de lieux intéressants sont accessibles facilement à pied ou en tram.

Découverte du centre-ville

Le centre-ville de Rotterdam est très différent d’Amsterdam.

Les rues sont plus larges, les bâtiments plus modernes et l’ambiance plus calme que ce à quoi je m’attendais.

On alterne constamment entre :

immeubles récents
zones commerçantes
cafés
places ouvertes
et architecture contemporaine.

La ville donne une impression très agréable pour marcher sans forcément avoir un itinéraire précis.

Le Markthal

Le Markthal est probablement l’un des endroits les plus connus de Rotterdam.

L’immense bâtiment en arche attire immédiatement l’attention.

À l’intérieur :

stands de nourriture
spécialités locales
cafés
street food
touristes
habitants
photographes.

L’endroit est vivant en permanence.

Le plafond couvert d’illustrations géantes donne une vraie identité au lieu, et l’ambiance mélange à la fois marché local et attraction touristique.

C’est aussi un très bon endroit pour faire une pause pendant une journée de visite.

Les maisons cubiques

Juste à côté du Markthal se trouvent les célèbres Cube Houses.

Même en les ayant déjà vues en photo, le résultat est surprenant en vrai.

Ces maisons inclinées donnent complètement une identité particulière au quartier.

Autour, il y a beaucoup :

de visiteurs
de cafés
de petites boutiques
et de gens simplement installés à observer le quartier.

Le vieux port juste à côté apporte aussi une ambiance beaucoup plus calme et agréable.

Balade en bateau

L’un des moments les plus agréables de la journée a probablement été la promenade en bateau.

Voir Rotterdam depuis l’eau permet vraiment de comprendre la ville différemment :

les ponts
les immeubles modernes
les anciens docks
les zones portuaires
les grands bâtiments récents.

Le contraste entre les espaces industriels et les nouveaux quartiers est très visible.

Et surtout, cela rappelle à quel point Rotterdam reste une ville profondément liée à son port.

Le zoo de Rotterdam

L’après-midi s’est poursuivi avec une visite du zoo de Rotterdam.

Le parc est immense et très bien entretenu.

On y trouve différentes zones thématiques avec :

animaux africains
espaces tropicaux
aquarium
oiseaux
grands espaces extérieurs.

L’ambiance est assez calme malgré le nombre de visiteurs.

Après l’agitation de la TwitchCon la veille, c’était aussi un bon moyen de ralentir un peu le rythme avant le retour.

Zuidplein et retour vers Ahoy

En fin de journée, direction Zuidplein.

Le quartier autour du Rotterdam Ahoy avait une ambiance très différente de la veille pendant la TwitchCon :
beaucoup plus calme, avec les visiteurs qui commencent progressivement à repartir.

C’était assez étrange de revoir les alentours du salon après toute l’énergie du samedi.

Impression générale

Cette deuxième journée a montré une autre facette de Rotterdam.

Au-delà de l’architecture moderne, la ville est surtout agréable à vivre :

facile à parcourir
bien organisée
très accessible à pied
avec beaucoup d’espaces ouverts.

Et finalement, le mélange entre :

centre-ville moderne
vieux port
grands bâtiments
espaces verts
transports efficaces
et ambiance internationale

rend Rotterdam très différente des autres villes néerlandaises.

C’était probablement la meilleure façon de terminer ce week-end TwitchCon.