DEV Community: Mathieu Ledru

💡 I created a GDPR-compliant AI app in 1 hour with Symfony

Mathieu Ledru — Fri, 03 Apr 2026 06:41:54 +0000

Today, many developers use AI to generate code.

The question we are addressing here is the following:

👉 How to transform an idea into an executable system?

And that's normal.

Because we learned to:

coding features
write functions
connect APIs

But not to:

structuring an idea so that it can be executed

At Darkwood, we never start with the code.

We begin with a much more fundamental step:

👉 the reasoning

In this article, we will look at the following in concrete terms:

How to transform an idea into a usable unit
How to use AI to execute this idea
How to apply this in a real project: SketchUp Shape

🧠 1. An idea is not code

When you think:

“Créer une application”

Your reflex as a developer is often:

“Okay, I’m going to code an API, a database, etc.”

👉 Bad starting point.

An idea is not yet something you can execute.

That's right:

👉 a vague intention

💡 The right mental model

At Darkwood, we believe that:

👉 one idea = one task

No more, no less.

Example

“Créer une application”

becomes :

Task: create_app

It may seem trivial.

But this is a significant change:

👉 You no longer think in terms of “projects”
👉 You think in executable units

⚙️ Why this method works: Church, Turing, and the idea as an executable unit

One might think that “prompting an AI” is a recent, almost purely practical topic, linked to current LLM news.

In reality, the problem is much older.

When a developer takes an idea and tries to turn it into an executable system, they always encounter the same question:

How do we move from an abstract intention to a form that the machine can actually process?

This is exactly the type of question that lies at the root of theoretical computer science.

In a previous Darkwood article - Create a Lambda Interpreter in PHP - we already explored this boundary between:

the idea of a calculation
and its actual execution by a machine

This article started with Alonzo Church's λ-calculus, then linked it to the Turing machine, recalling a fundamental point:

The λ-calculus and the Turing machine are two equivalent models of computation

In other words:

Church provides a conceptual model
Turing provides a model of execution

And that's exactly what interests us here.

🧠 Church: before execution, a conceivable form is necessary

Alonzo Church does not start from a machine.
It stems from a much deeper problem:

What is a function?

and more broadly:

What is a calculation?

The λ-calculus responds to this with a radical idea:

Any calculation can be expressed as an abstraction and application of functions.

In this model:

A function is a transformation
a value can be passed to another function
and evaluation consists of applying functions to one another

This is the theoretical root of many things we use today without thinking about it:

functional programming
the currying
closures
the combinators
pure transformations
DSLs

In the article on the lambda interpreter in PHP, this idea was presented in a very concrete way:
We started with an expression, tokenized it, parsed it, built an AST, and then evaluated it.

In other words:

before a system executes something,
First, it must understand a form

This is exactly the point that interests us regarding AI.

When you give an LLM a sentence like:

Create a house

You haven't given it an execution yet.
You give it an abstract form, an intention, a request that is still insufficiently structured.

And that's where Church's intuition becomes useful to us.

Developer translation

When we talk about ideas in this article, we are not talking about vague inspiration or brainstorming.

We are already talking about a manipulable abstraction.

In other words:

An idea must become a unit upon which a system can reason.

That's why, at Darkwood, we make an initial mental shift:

An idea is not yet code.

An idea is already a transformation in progress.

Or, to put it another way:

An idea is a potential task

⚙️ Turing: once the form is defined, it must be executed

Church formalizes calculation on the side of abstraction.
Turing, however, answers a different question:

What does a machine capable of performing this calculation look like?

His answer is famous:

a memory strip
a reading head
a current state
transition rules

The power of the model does not come from its complexity, but rather from its simplicity.

A Turing machine reads a cell, takes its state into account, applies a rule, possibly writes something, and then moves on.

It's an extremely simple model, but sufficient to reason about what a machine can do.

What interests us here is not teaching the entire theory of automata.
It's about recovering a very concrete intuition:

An executable system needs readable units.

and a clear mechanism for switching from one state to the other

This is where the link with modern work on ideas, tasks, and AI agents becomes very concrete.

🔁 What Church and Turing teach us about working with AI

The essential point is this:

Church teaches us to think of calculation as transformation
Turing teaches us to think of computation as structured execution

When you combine the two, you get a much healthier way of working with AI.

We stop thinking:

“I’m going to ask the model for some code”

And we start to think:

“I’m going to give him a structured unit of work,
that he will be able to transform,
then another system can execute”

That's exactly what we do at Darkwood.

🧩 Darkwood translation: an idea becomes a task

At this stage, we can simplify the model without betraying it.

Here is the translation we are using as a basis:

Theoretical concept	Darkwood interpretation
Abstraction	Structured idea
Function	Transformation
Memory slot	Task
Strip	To-do list / stack
Read	Execute
Transition	Change from one state to another

This gives us a simple rule:

an idea becomes a task

a task becomes a readable unit

A readable unit can be executed.

It is this change of perspective that matters.

Because as long as an idea remains only in your head, it is unusable by the system:

nor your terminal
nor your IDE
nor your LLM
nor your orchestrator

cannot work on it properly.

It therefore needs to be given a form.

💡 The idea as a unit of calculation

This is where our method becomes truly meaningful.

When we say:

Créer une application

It's not a system yet.
This is not yet architecture.
This is not yet a usable prompt.

But it's not "nothing" either.

That's already it:

a unit of calculation to be specified

At Darkwood, we put it through a nomination and reduction stage.

For example :

Task: create_app

Task: generate_sketchup_shape

From this point on, the machine - or the system of agents - no longer manipulates just a human sentence.
She is manipulating an identifiable task.

And once you can identify a task, you can:

store it
reread it
reproduce it
transmit it
cut it
parallelize it
to orchestrate it

That's it, that's the real change.

🧠 Why this is so useful for a developer

A developer often tends to jump directly to implementation:

create a folder
Install Symfony
connect an API
write an order

But if the initial idea has not been modeled correctly, everything else becomes unstable.

This leads to what many people experience with LLMs today:

vague prompts
unclear outputs
fragile structures
projects that “work”, but lack coherence

The theory of Church and Turing reminds us of something very simple:

The quality of the execution depends on the quality of the initial representation.

In other words:

If you want to improve the performance of an AI,
First, you need to represent your idea better.

And that's precisely what we're going to do next with SketchUp Shape:

starting from an intention
convert it into a task
to structure it
transform it into a design
then only in code

🧭 The rule to remember

If this entire section had to be condensed into a single sentence, it would be this:

A useful idea for AI is not an inspiration.

It's a sufficiently clear abstraction to become an executable task

And that's where Church and Turing cease to be distant theory.

They become a practical model for the modern developer:

Church helps you think about form
Turing helps you think about execution
Darkwood helps you connect the two

📚 Concrete example

You have several ideas:

- créer une app
- construire une API
- générer un modèle 3D

👉 You can represent them as a stack:

Stack:
- create_app
- build_api
- generate_model

And then, everything becomes simpler:

You can handle each task one by one

in parallel

⚡ 2. Your brain already works like this

You don't need to learn a new system.

👉 You're already using it.

🧠 Simple case: different tasks

Task A: répondre à un message
Task B: installer un package

👉 No link
👉 You can easily switch between them

⚠️ Complicated case: similar tasks

Task A: coder une API
Task B: refactor la même API

👉 Now, things are getting tough

For what ?

same context
same mental variables
same files

👉 Result:

confusion
errors
fatigue

💥 What this implies

Your brain:

has limited memory
handles too much context poorly
saturates quickly

👉 So:

You can't manage many complex tasks at the same time.

🧩 3. The real problem: reproducibility

A task is only valuable if you can:

find her
to revive it
share it

👉 Otherwise, it stays in your head
👉 and she disappears

🧠 Darkwood Approach

We introduce a simple idea:

👉 one task = one pointer

In concrete terms

You write your task in Joplin
she has an ID
This ID becomes your “pointer”

And then:

in your terminal → you are referencing this task
in your IDE → same
in your AI → same

👉 Result:

you manipulate the same object, everywhere

💡 What this changes

You no longer say:

“I’m going to work on my idea.”

You say:

“I will carry out this task”

And that's much more powerful.

⚙️ 4. AI: not a magic tool, an execution system

Today, many developers use AI like this:

“generate a function for me”
“write me a class”
“Fixes this bug”

👉 It works.

But you remain within a certain logic:

responsive

🧠 Darkwood Approach

We completely change the perspective:

👉 AI is becoming an execution system

🏗 We model like a business

Rather than “magical agents”, a simple structure is used:

👤 You (human)

you define the intention
you pose the problem

🧠 AI Architect

he understands your intention
he breaks it down into tasks
he decides how to organize the system

⚙️ Agents

they execute
they produce code
they transform the data

💡 Key Rule

👉 The prompt = your intention

If your prompt is unclear:

👉 the system is unclear

If your prompt is structured:

👉 the system becomes structured

🔥 Example

❌ Bad prompt:

“Generate a house”

✅ Good prompt:

“Create a structured architectural design of a house,
with walls, roof, proportions and constraints,
then generate SketchUp Ruby code from it”

👉 Here, you give:

a direction
a structure
a clear objective

🧠 What you need to remember

👉 You don't need to be better at coding

👉 You need to get better at:

structuring
intention
orchestration

And that's exactly what we're going to apply now with:

👉 SketchUp Shape

🚀 5. Practical application: SketchUp Shape

Project :
👉 https://github.com/matyo91/sketchup-shape

🎯 Objective

Transformer:

“Create a house”

in:

👉 Ruby script executable in SketchUp

🧱 Why SketchUp?

3D modeling tool
Documented Ruby API: → SketchUp Ruby API
extensible (plugins, scripts)

🎓 Context

I personally learned SketchUp with
Sébastien Maison (YouTube)

👉 Here, the goal is not to use their AI:

→ Official SketchUp AI

👉 But to build our own system

⚙️ 6. Pipeline: from idea to (concrete) 3D model

Before going any further, let's take a real-life example.

👉 Here, we're not talking about an abstract API
👉 We're talking about generating a 3D object in SketchUp

🧱 A little background: why SketchUp?

SketchUp is a widely used 3D modeling tool:

architecture
design
prototyping

Personally, I discovered SketchUp thanks to Sébastien Maison, with whom I took a course.

👉 I modeled a house there “by hand”

And that's where the idea came from:

👉 “What if I could generate that directly with code?”

⚠️ Why not use SketchUp's native AI?

SketchUp already offers AI:

👉 SketchUp AI

But that's not the point here.

👉 We are developers.

👉 We want:

to understand
control
automate

So we go through:

👉 SketchUp Ruby API

🧠 The technical entrance

To do this, SketchUp explains:

👉 In concrete terms:

You write Ruby like this:

model = Sketchup.active_model
entities = model.entities

And you build:

faces
volumes
groups

🧩 Resources used

To make the AI more reliable, I used:

Ruby API Stubs
👉 to give the LLM a clear view of the available objects
Official examples
👉 to understand the real patterns

And if you want to go further:

👉 SketchUp Extensions
→ You can package your code as a plugin

⚠️ Important prerequisite

To run Ruby:

👉 You must use the desktop version:

SketchUp Pro Trial

👉 The web version does not allow this (or only in very limited ways)

🔁 Pipeline Darkwood (applied)

Now that we have the context, here is the actual pipeline:

Intention
   ↓
Design (LLM #1)
   ↓
Code (LLM #2)
   ↓
SketchUp

🧠 Step 1: Intention

You start with a simple idea:

bin/console app:generate-shape "Create a house"

👉 Nothing more.

🧱 Step 2: Design (LLM #1)

Here, AI does not code.

👉 She thinks

She acts like an architect:

{
  "type": "house",
  "structure": {
    "walls": {...},
    "roof": {...}
  }
}

👉 She decides:

proportions
elements
of the structure

⚙️ Step 3: Code (LLM #2)

Only then:

👉 a second AI transforms this plan into code

model.start_operation('House', true)
...
model.commit_operation

👉 She acts like a developer:

It uses the SketchUp API
she constructs the geometry

⚠️ 7. Why 2 LLMs (and not 1)

This is one of the most important parts.

❌ Naive approach

idée → code

👉 What you get:

inconsistent
unpredictable
difficult to correct

✅ Darkwood Approach

idée → design → code

👉 You separate:

🧠 the what
⚙️ the comment

💡 It's exactly like in a team:

architect → decides
developer → implements

🧠 8. The real problem encountered

When I launched:

Create a house

👉 Result:

technically valid
but visually… false

👉 It wasn't a house

❌ Why?

Because AI did this:

“A house = shapes”

👉 She stacked:

cubes
a roof
without logic

💥 The real problem

AI doesn't understand:

gravity
the proportions
actual usage

👉 She doesn't understand:

what a house is

🧠 Correction made

A layer was introduced:

👉 structured design

Instead of :

{ "parts": [...] }

We force:

{
  "type": "house",
  "foundation": {...},
  "walls": {...},
  "roof": {...},
  "constraints": {
    "symmetry": true,
    "alignment": "centered"
  }
}

👉 Result:

consistency
stability
made credible

⚙️ 10. Technical Stack

🧱 Backend

Symfony 8
Symfony AI
darkwood/navi

👉 Installation:

composer require darkwood/navi

🧠 Local AI (GDPR)

👉 everything runs locally

⚖️ Why this is important

no external API
no data leak
total control

👉 You build a system:

GDPR compliant by design

⚙️ 11. Orders

🧠 Local LLM

ollama pull ministral-3:8b
ollama serve

⚙️ Generation

bin/console app:generate-shape "Create a house"

Useful Options

-o house.rb        # sauvegarde du script
--spec design.json # sauvegarde du design
-v                 # debug complet

🧠 12. What you really need to remember

❌ This is not:

“How to use AI”

✅ It is:

👉 How to structure an idea so that an AI can execute it

🔁 Final Model

idée
 → tâche
 → design
 → code
 → exécution

🚀 Conclusion

The future of development is not:

write more code

But :

structuring ideas
and orchestrate their execution

👉 At Darkwood:

we are not trying to go faster

we are trying to be fairer

🎨 Darkwood v1.0.4 - Présentation du design V4

Mathieu Ledru — Mon, 16 Mar 2026 12:29:36 +0000

Darkwood v1.0.4 est maintenant disponible.

Cette version introduit Design V4, la quatrième itération visuelle majeure de Darkwood.

Pour les nouveaux lecteurs, voici deux idées de versionnage différentes :

v1.0.4 est la version du logiciel
Design V4 est la quatrième évolution de l'interface de Darkwood
Au fil des ans, Darkwood a connu plusieurs itérations de conception :

V1 se concentrait sur la première identité visuelle
V2 a exploré de nouvelles orientations de mise en page
V3 a affiné la marque et la structure globale
V4 remanie la navigation sur l'ensemble du site
Cette version n'est donc pas « Darkwood version 4 » au sens du terme. Il s'agit de la version 1.0.4, qui introduit Darkwood Design V4.

Et c'est important, car cette mise à jour ne se limite pas à une simple amélioration visuelle. Elle modernise également l'infrastructure technique et ouvre Darkwood aux flux de travail basés sur l'IA.

Notes de version : https://github.com/darkwood-com/darkwood-com/releases/tag/v1.0.4

Qu'est-ce que Darkwood ?
Darkwood est un jeu tactique axé sur les API.

Il est conçu comme les deux :

un système de jeu jouable
un terrain de jeu technique
une application Symfony conçue pour l'expérimentation à long terme
L'idée de base est simple : le gameplay ne doit pas dépendre entièrement de l'interface graphique.

L'interface utilisateur est importante, mais la logique du jeu réside avant tout dans l'API.

Cette approche a été décrite précédemment ici : https://blog.darkwood.com/article/darkwood-building-an-api-first-tactical-game

Cette version s'inscrit dans cette continuité.

Darkwood combine désormais :

une interface repensée
une pile PHP mise à jour
et intégration MCP pour les agents d'IA
Pourquoi concevoir V4 ?
Au fil du temps, Darkwood a accumulé des couches.

Des pages ont été ajoutées. Les expériences ont été intégrées. Navigation étendue.

Le résultat était fonctionnel, mais pas toujours clair.

La version 4 de Design se concentre sur un objectif principal :

Redonner au navigateur un aspect naturel.

Le changement le plus important entre la version V3 et la version V4 ne réside pas dans la marque elle-même. Il s'agit de la manière dont les utilisateurs naviguent sur le site.

Les versions précédentes portaient principalement sur la mise en page et l'identité visuelle. Celui-ci concerne l'architecture de navigation.

La nouvelle conception a d'abord été explorée avec Pencil, ce qui a permis d'accélérer les études d'interface et les décisions de mise en page avant la mise en œuvre.

Elle bénéficie également directement des leçons apprises lors de la construction d'Uniflow.

Chez Uniflow, un travail considérable a été consacré à l'amélioration de la clarté des menus sur ordinateur et mobile. Cette expérience a contribué à façonner le nouveau modèle de navigation de Darkwood.

Une bonne façon de résumer cet état d'esprit est :

Penser macro, agir micro.

Au niveau macro, la plateforme a besoin d'une structure claire. Au niveau micro, chaque interaction doit rester simple.

Voilà l’esprit qui anime le design V4.

Qu'est-ce qui a changé dans l'interface ?
Une nouvelle structure de navigation
Le changement le plus visible concerne la navigation.

Darkwood utilise désormais une navigation centrée en haut au lieu de l'ancienne structure latérale.

Le site est organisé autour de quatre sections principales :

Jouer - accéder au jeu tactique
Monde - explorez l'univers et son contexte
Journal - Consultez les articles techniques et les notes de développement
Projets - Découvrez des expériences et des travaux connexes
Cela rend la plateforme plus facile à comprendre au premier coup d'œil.

Au lieu d'être fragmentée, l'expérience est désormais organisée autour de quatre points d'entrée clairement définis.

La même logique est utilisée sur ordinateur et mobile, la navigation reste donc cohérente quel que soit l'appareil.

Une tête plus légère
L'en-tête a été repensé pour paraître plus léger et plus réfléchi.

Elle reste disponible pendant le défilement, mais avec un poids visuel réduit.

Le but n'était pas de le rendre plus décoratif. L'objectif était de le rendre plus utile.

Un pied de page remanié
Le pied de page a également été restructuré.

Elle permet désormais de regrouper le contenu plus clairement tout en restant secondaire par rapport à la page elle-même.

L'objectif était d'améliorer l'orientation sans que le pied de page ne domine l'expérience de lecture.

Un système visuel plus cohérent
La version 4 de Design introduit également un nettoyage plus global du site :

espacement amélioré
Hiérarchie de boutons plus claire
meilleure navigation mobile
Expérience de connexion améliorée
Comportement de mise en page plus cohérent
Il ne s'agit pas d'une refonte radicale. Il s'agit d'un passage de cohérence à travers l'expérience complète.

Construit avec une pile mise à jour
Cette version met également à jour les fondements techniques de Darkwood.

Darkwood fonctionne désormais avec :

PHP 8.5
Symfony 8
FrankenPHP v1.12.1
Il comprend également :

Migration des contrôleurs des annotations vers les attributs PHP
Configuration Nix et CI mise à jour
Mise à jour des recettes et de la configuration du framework
Corrections de dépréciation concernant le groupe d'exceptions Darkwood IA
Renforcement de la sécurité en production sur plusieurs points, notamment le référencement naturel, Castor, la sérialisation des utilisateurs, reCAPTCHA et l'intégration optionnelle de Baserow
L'objectif est simple :

Maintenir la plateforme à jour, rapide et facile à maintenir.

Pas par mode. Pour sa durabilité.

Darkwood devrait pouvoir se développer sans rencontrer de difficultés techniques évitables.

Intégration MCP pour les flux de travail d'IA
Cette version ajoute également l'intégration de l'outil MCP grâce aux nouvelles capacités d'IA de la plateforme API.

Référence: https://les-tilleuls.coop/blog/sortie-dapi-platform-4-3-rencontre-avec-lia

Cela correspond naturellement à l'approche « API-first » de Darkwood.

Si la logique du jeu existe déjà sous forme d'API, l'exposer à des agents d'IA devient une extension de la même philosophie.

Autrement dit, le jeu tactique était déjà programmable. Il est désormais également prêt pour les agents.

Outils MCP de DarkwoodGame
La ressource API DarkwoodGame expose désormais quatre outils MCP :

get_darkwood_state Renvoie l'état actuel du jeu

darkwood_action Exécute une action de jeu à partir d'une entrée

list_darkwood_archives Liste des captures d'écran archivées des puzzles pour les utilisateurs premium

get_darkwood_archive Récupère une archive par identifiant pour les utilisateurs premium

Tous utilisent une sortie de contenu structuré, ce qui signifie que la réponse de l'API est directement renvoyée sous forme de sortie de l'outil MCP.

Aucune nouvelle route HTTP n'a été introduite pour cela.

La couche MCP expose simplement les capacités API existantes de manière à ce que les agents d'IA puissent les exploiter sans problème.

Outils MCP de l'article
Les articles de Darkwood sont désormais également accessibles via MCP.

Deux outils ont été ajoutés :

list_articles
get_article
Cela permet aux agents d'IA de récupérer des données structurées d'articles tout en conservant les mêmes règles de sécurité que la ressource API elle-même.

Là encore, l'objectif n'est pas de dupliquer l'application. Il s'agit de rendre le système existant accessible via une nouvelle couche d'interaction.

Gratuit vs Premium
Darkwood est actuellement en cours de développement en Bêta Saison 0.

La proposition commerciale reste inchangée.

Deux types de clés d'accès sont disponibles.

🎟 Accès bêta (gratuit)
Clé API personnelle
Actions quotidiennes limitées
Accès à l'état jouable actuel
Accès aux archives impossible
💎 Fondateur Premium
Clé API personnelle
Actions quotidiennes illimitées
Accès aux instantanés archivés des puzzles
Statut de soutien précoce
Les archives sont des instantanés en lecture seule des états jouables antérieurs. Ils permettent de révéler l'état historique du jeu sans affecter la partie en cours.

Édition limitée pour les fondateurs
Cette version reste volontairement confidentielle.

Disponible dès maintenant :

5 clés d'accès bêta
5 clés Fondateur Premium
C'est tout.

Il ne s'agit pas d'un lancement destiné au marché de masse. Il s'agit d'une version contrôlée destinée à valider le modèle.

L'accès est géré par Bonzai :

Accès bêta (gratuit) https://www.bonzai.pro/matyo91/shop/yDxv_7247/darkwood-api-beta-access-free

Fondateur Premium https://www.bonzai.pro/matyo91/shop/lQxn_7249/darkwood-api-founder-premium

Chaque clé est personnelle et peut être changée si nécessaire.

Ce que cette publication signifie réellement
Darkwood v1.0.4 est une version qui poursuit trois objectifs :

rendre l'interface plus facile à naviguer
Mettre à jour l'architecture technique selon les normes modernes
Étendre le modèle de jeu basé sur les API aux agents d'IA via MCP
Le design V4 correspond à la partie visible.

Mais en coulisses, le projet se consolide et s'ouvre également.

On peut désormais aborder ce même jeu tactique par le biais de :

le site web
l'API
et les flux de travail pilotés par l'IA
Cette continuité est importante.

Darkwood ne se divise pas en idées distinctes. Cela devient plus cohérent.

Découvrez la version
Darkwood v1.0.4 est disponible.

Il apporte Design V4, une pile Symfony et PHP modernisée, et une intégration MCP pour le jeu tactique axé sur les API.

Explorez l'interface. Lisez le journal. Accédez à l'API. Ou commencez à jouer.

Libérer: https://github.com/darkwood-com/darkwood-com/releases/tag/v1.0.4

👾 Darkwood : Créer un jeu tactique axé sur les API

Mathieu Ledru — Sun, 08 Mar 2026 09:31:07 +0000

Darkwood est désormais jouable entièrement via API.

Il n'y a pas d'interface utilisateur dédiée. Aucune interface utilisateur requise. Pas de client graphique.

Vous interagissez avec le jeu via HTTP.

Que signifie réellement « API-First » ?
Dans Darkwood, la boucle de jeu est simple et explicite :

GET /api/darkwood/state → observer la situation actuelle
Interpréter la réponse JSON
POST /api/darkwood/action → décider de l'action à effectuer
Recevoir l'état mis à jour
Répéter
Le jeu se comporte comme une machine à états via HTTP.

Chaque réponse comprend :

état — où vous vous trouvez (principal, combat, infos, boutique, etc.)
mode — sous-phase (combat, victoire, mort, etc.)
data — détails contextuels (vie, ennemi, statistiques, session de combat)
Votre client — qu'il s'agisse de curl, d'un outil en ligne de commande, d'un script ou d'un agent d'IA — lit l'état et décide de la prochaine action.

Il n'y a pas de logique d'interface utilisateur cachée.

Le protocole est la clé du jeu.

Deux niveaux d'accès
Darkwood divise l'accès en deux niveaux :

1️⃣ Accès API
Chaque demande doit inclure :

X-API-Key:
La clé API contrôle :

Si vous pouvez appeler l'API
Que vous fassiez partie de la saison bêta 0
Que vous ayez un accès premium
Votre quota d'actions quotidien (pour les clés gratuites)
2️⃣ Identité du joueur
Pour jouer avec un personnage spécifique (progression persistante, combats, statistiques), vous vous authentifiez avec :

Authorization: Bearer
Le JWT identifie le compte du joueur. La clé API contrôle l'accès et la monétisation.

Ils sont séparés par conception.

La documentation complète est disponible sur GitHub : https://github.com/darkwood-com/darkwood-com/blob/main/docs/

Gratuit vs Premium
Darkwood est actuellement en cours de développement en Bêta Saison 0.

Il existe deux types de clés :

Édition limitée pour les fondateurs
Pour que ce lancement reste sous contrôle :

5 clés d'accès bêta
5 clés Fondateur Premium
C'est ça.

Il ne s'agit pas d'un lancement à grande échelle. Il s'agit d'une version ciblée visant à valider le modèle.

Les ventes sont gérées par Bonzai :

Accès bêta (gratuit) : https://www.bonzai.pro/matyo91/shop/yDxv_7247/darkwood-api-beta-access-free

Premium Fondateur : https://www.bonzai.pro/matyo91/shop/lQxn_7249/darkwood-api-founder-premium

Chaque clé est personnelle. Les touches peuvent être pivotées si nécessaire.

Pourquoi pas d'interface utilisateur ?
Parce que l'interface est optionnelle.

Vous pouvez jouer à Darkwood avec :

curl
Postman
une interface de ligne de commande personnalisée
un petit client web
un script
un agent d'IA
L'API définit le contrat du jeu.

Le client n'est qu'un interprète.

Saison bêta 0
La logique du jeu reste inchangée.

L'objectif de cette phase est :

Stabilité de l'API
Modèle de monétisation propre (clé API uniquement)
Flux d'état déterministe
Clarté de la documentation
Pas de sur-ingénierie. Aucune fonctionnalité superflue.

Un simple jeu tactique déguisé en protocole.

Darkwood n'est pas qu'un simple projet backend.

C'est un jeu qui fonctionne entièrement via HTTP.

Et la saison 0 de la bêta est maintenant disponible.

🚀 Création d'une application PHP MCP pour publier des articles Darkwood

Mathieu Ledru — Sun, 01 Mar 2026 20:09:22 +0000

Les grands modèles de langage sont déjà performants pour la génération de texte. Ce qui manque encore, dans de nombreux projets, c'est une méthode simple pour transformer cette génération de texte en un véritable flux de travail : rédiger un brouillon, le relire, le corriger, le publier et l'intégrer de manière intuitive dans une application cliente d'IA.

C’est précisément là que les applications MCP deviennent intéressantes.

Dans ce projet, l'objectif n'était pas de créer « une énième intégration de chatbot ». L'objectif était de développer une véritable application MCP en PHP permettant de publier un article de blog Darkwood via un flux de travail éditorial simplifié :

générer un brouillon,
le réviser ou le corriger,
le publier,
et, si nécessaire, revenir en arrière avant la publication.
Le résultat est un serveur PHP MCP qui peut fonctionner sur stdio ou HTTP, exposer des outils, exposer des ressources d'interface utilisateur et être conditionné comme une extension Claude Desktop.

Pourquoi les applications MCP sont importantes
Un serveur MCP classique peut exposer des outils et des ressources. C'est déjà utile : un LLM peut appeler un outil, obtenir une sortie structurée et poursuivre son raisonnement.

Mais les applications MCP ajoutent quelque chose de plus pratique : elles permettent à un outil d’intégrer sa propre interface utilisateur embarquée.

Cela modifie considérablement le modèle d'interaction.

Au lieu de se contenter de renvoyer du texte, un outil peut désormais ouvrir une interface dédiée au sein du système hôte. Cette interface peut afficher l'état des entrées, présenter les résultats, guider l'utilisateur tout au long d'un flux et déclencher des appels d'outils supplémentaires. Autrement dit, l'outil cesse d'être une simple fonction distante et se comporte davantage comme une interface d'application à part entière.

Dans un flux de travail éditorial, c'est beaucoup plus adapté que le simple texte brut.

Générer un brouillon n'est pas le plus difficile. La difficulté réside dans la gestion de la transition entre le texte généré et le contenu prêt à être publié. C'est là qu'une interface utilisateur d'application MCP s'avère utile : elle structure le processus.

Le cas d'utilisation de Darkwood
Le cas d'utilisation concret est ici simple à expliquer.

Cette application MCP est utilisée pour faciliter la publication d'un article de blog sur Darkwood.

Le flux de travail commence par une première étape, GenerateDraft, qui produit une ébauche initiale à partir d'un sujet ou d'un contexte.

Vient ensuite la deuxième étape, PublishDraft, qui gère le processus de publication. Si le brouillon n'est pas encore satisfaisant, le processus peut se poursuivre. Il est possible de revenir en arrière et de procéder à une correction ou une révision avant de tenter une nouvelle publication.

Cette boucle est importante.

En pratique, le processus de publication est rarement linéaire. Une première ébauche peut être trop brouillonne, trop générique, trop longue, ou tout simplement ne pas correspondre à l'intention éditoriale. C'est pourquoi l'application MCP est conçue autour d'une idée réaliste : la publication est l'objectif final, mais l'itération fait partie intégrante du cheminement.

Un serveur MCP, plusieurs façons de l'utiliser
Un aspect utile de ce projet est que la même logique MCP est réutilisée dans plusieurs modes d'exécution.

Le serveur peut être utilisé :

via stdio, généralement pour les intégrations locales et le packaging Claude Desktop,
via HTTP, pour les hôtes basés sur un navigateur ou les points de terminaison MCP locaux,
via le serveur Symfony, lorsque vous souhaitez une configuration HTTP plus standard autour de public/index.php,
via une extension Claude Desktop, conditionnée sous forme de .mcpb,
et, dans tous ces cas, en tant qu'outil compatible avec l'application MCP lorsque l'hôte prend en charge l'interface utilisateur intégrée.
C'est important du point de vue de l'architecture : la logique métier n'est pas liée à un seul client ni à un seul protocole de transport. Le protocole de transport change, le modèle d'orchestration évolue légèrement, mais l'interface MCP reste la même.

Architecture
La manière la plus simple de comprendre le projet est de le diviser en quatre rôles : l’hôte, le serveur PHP MCP, l’interface utilisateur de l’application MCP et la couche d’orchestration.

Vue d'ensemble
De manière générale, le système fonctionne comme suit :

schema-architecture

un hôte MCP se connecte au serveur PHP,
l'hôte découvre les outils et ressources disponibles,
l'hôte appelle un outil tel que GenerateDraft ou PublishDraft,
si l'outil déclare une ressource d'interface utilisateur, l'hôte charge également la vue d'application MCP correspondante.
l'interface utilisateur et l'hôte communiquent entre eux via JSON-RPC sur postMessage,
et l'outil de transfert d'appels de l'hôte renvoie les appels au serveur PHP.
Voici l'idée clé : l'interface utilisateur ne communique pas directement avec le serveur. L'hôte fait office d'intermédiaire.

Cette séparation est utile car elle permet de conserver l'interface utilisateur portable sur les hôtes compatibles tout en préservant un contrat MCP propre côté serveur.

Transports
Le projet soutient deux principaux modes de transport.

Stdio
En mode stdio, l'hôte démarre le serveur PHP en tant que sous-processus et communique via STDIN et STDOUT.

C'est le cas idéal pour les extensions Claude Desktop. L'hôte lance le serveur, envoie des messages JSON-RPC via l'entrée standard et lit les réponses depuis la sortie standard.

Ce mode est simple, local et efficace lorsque le client est responsable de la gestion des processus.

HTTP
En mode HTTP, le serveur expose un point de terminaison MCP tel que POST /mcp.

Ce mode est utile pour les hôtes orientés navigateur, les tests locaux ou toute configuration où une limite HTTP est plus pratique qu'un processus enfant.

Dans ce projet, le protocole HTTP peut être servi de deux manières :

grâce à un processus dédié et durable tel que le flow worker,
ou via un point d'entrée web plus traditionnel tel que public/index.php.
Messagerie
Une fois connectés, l'hôte et le serveur communiquent avec JSON-RPC 2.0.

Cela signifie que le modèle d'interaction reste clair et explicite :

l'hôte envoie des requêtes,
le serveur renvoie des réponses, Des notifications peuvent être échangées lorsqu'aucune réponse n'est attendue.
Cela reste vrai, que le transport soit stdio ou HTTP. Le transport change, mais le contrat du protocole demeure le même.

De plus, lorsque des applications MCP sont impliquées, l'interface utilisateur communique avec l'hôte via un autre canal JSON-RPC, cette fois via postMessage.

Il y a donc en réalité deux niveaux de communication :

hôte ↔ serveur via MCP,
Interface utilisateur ↔ hôte via le pont MCP Apps.
C’est cette séparation qui rend possible l’intégration d’une interface utilisateur sans coupler directement le front-end à l’environnement d’exécution PHP.

Cycle de vie
Une interaction typique se déroule en quelques étapes prévisibles.

Tout d'abord, l'hôte initialise la connexion et découvre les capacités du serveur.

Ensuite, il liste les outils et les ressources.

Lorsqu'un utilisateur déclenche un outil, l'hôte appelle cet outil sur le serveur. Si cet outil est associé à une ressource d'interface utilisateur, l'hôte lit également la ressource ui://... correspondante et l'affiche dans une iframe isolée.

À ce stade, l'application MCP devient interactive. Elle peut recevoir les données saisies par l'outil, afficher le résultat et déclencher des actions complémentaires via l'hôte.

Dans le flux de travail Darkwood, cela signifie que l'utilisateur ou l'assistant peut passer de la génération d'ébauches à la publication, et éventuellement revenir dans une boucle de correction, sans quitter le modèle d'interaction MCP.

Ce qui se passe où
Le serveur PHP MCP possède la surface de protocole :

initialiser
tools/list
outils/appel
ressources/liste
ressources/lire
L’interface utilisateur de l’application MCP est responsable de l’expérience interactive.

L'hôte gère le transport, le rendu et la liaison entre l'interface utilisateur et le serveur.

La couche Flow gère l'orchestration des flux de travail lorsque celle-ci est nécessaire.

Ce dernier point est important car les flux éditoriaux impliquent souvent plus d'une action et plus d'une transition d'état.

Stdio, HTTP et le serveur Symfony ne sont pas la même chose
Même si la logique métier reste la même, le modèle d'exécution n'est pas identique d'un mode à l'autre.

Avec stdio et un worker HTTP persistant, vous pouvez envisager un processus persistant. Cela ouvre la voie à des fonctionnalités asynchrones, des boucles d'événements et une orchestration continue au sein du même environnement d'exécution.

Avec Symfony Server, le modèle est plus classique. Chaque requête est traitée dans un cycle HTTP synchrone. C'est généralement plus simple à mettre en œuvre, mais cela implique une orchestration différente : la couche HTTP reste synchronisée, tandis que la logique de workflow est déléguée à Flow ou à une coordination externe.

Il est important de faire explicitement cette distinction, car « prend en charge HTTP » ne signifie pas automatiquement « prend en charge le même modèle d'exécution partout ».

Pourquoi cette conception est-elle efficace pour les flux de travail de publication ?
Le flux de publication d'un blog se trouve dans une situation délicate.

Il ne s'agit pas d'un simple appel de fonction, ni d'une application back-office complète. Elle nécessite une structure suffisante pour gérer l'état et les décisions, tout en restant assez légère pour être déclenchée par une conversation avec une IA.

C’est précisément pourquoi les applications MCP sont parfaitement adaptées ici.

L'interface de l'outil confère au modèle une surface d'interaction. L'interface utilisateur offre à l'utilisateur ou au client une vue contrôlée du flux de travail. Enfin, l'orchestration du flux permet au système de gérer les transitions en plusieurs étapes.

Cette combinaison est efficace car chaque couche reste ciblée :

le modèle décide quand utiliser l'outil,
l'outil expose le flux de travail,
l'interface utilisateur rend le flux de travail visible,
le serveur l'exécute sans problème.
Utilisation de l'application MCP dans Claude
L'un des résultats pratiques de ce projet est que le même serveur MCP peut être intégré sous forme d'extension Claude Desktop.

Cela signifie que le projet n'est pas seulement un prototype local ou une démo pour navigateur. Il peut être installé dans Claude et utilisé comme une véritable intégration d'outil.

Dans cette configuration :

le manifeste de l'extension définit comment Claude lance le serveur,
le serveur fonctionne via stdio,
Claude fait office d'hôte du MCP,
et l'application MCP devient disponible en tant qu'outil au sein du client.
Voilà un bon exemple qui illustre l'importance de séparer les protocoles de transport de la logique métier. Un même serveur PHP MCP peut ainsi gérer le développement local, les expérimentations HTTP et l'utilisation de Claude Desktop sans qu'il soit nécessaire de réécrire son fonctionnement de base.

De la démo aux outils éditoriaux réels
Ce qui rend ce projet intéressant, ce n'est pas l'existence d'un énième générateur de brouillons.

C’est le fait que le projet définit déjà une forme réutilisable pour les outils éditoriaux :

un outil pour produire un brouillon,
un outil pour publier,
un endroit pour gérer les révisions,
une couche d'interface utilisateur pour prendre en charge l'interaction,
et un serveur MCP indépendant du transport en dessous.
C'est une base beaucoup plus durable qu'une chaîne de distribution ponctuelle.

Une fois cette structure en place, l'amélioration du flux de travail devient beaucoup plus simple. Vous pouvez optimiser la qualité de la génération, enrichir les métadonnées de publication, ajouter des validations ou intégrer un véritable CMS. Le contrat entre l'hébergeur, l'interface utilisateur et le serveur reste stable.

Open source
Le projet complet est disponible en tant que dépôt open-source sur GitHub.

https://github.com/darkwood-com/darkwood-publish-article-mcp-apps

Conclusion
Ce projet démontre que les applications MCP ne se limitent pas à proposer des outils aux titulaires d'un LLM. Elles visent également à proposer des flux de travail utilisables.

Dans le cas de Darkwood, le plus intéressant n'est pas que PHP puisse communiquer avec MCP. Le plus intéressant est qu'un serveur PHP MCP puisse désormais servir de backend à une petite application éditoriale, accessible depuis un client d'IA, avec à la fois la sémantique de l'outil et une interface utilisateur intégrée.

Cela fait passer l'intégration de « le modèle peut appeler une fonction » à « le modèle peut participer à un flux de travail de publication contrôlé ».

Et c'est un endroit bien plus utile.

Sources Démarrage rapide des applications MCP
README.md
php-mcp-apps-mvp-architecture.md

🚀 Je construis un moteur de dictée en PHP (Flow + Symfony + Whisper.cpp)

Mathieu Ledru — Sun, 22 Feb 2026 22:24:27 +0000

Construire un moteur de dictée en 2026 est trivial.

Construire une architecture propre autour d’un moteur de dictée est plus intéressant.

Cet article présente Flowvox, un MVP de moteur de transcription audio développé en PHP, en s’appuyant sur :

Symfony
Symfony Messenger
Flow : orchestrateur maison
ffmpeg
whisper.cpp
Le code source est disponible en open source : 👉 https://github.com/darkwood-com/flowvox

L’objectif n’était pas simplement d’utiliser Whisper. L’objectif était de structurer correctement le pipeline.

Le problème : la transcription n’est qu’une étape
Un moteur vocal minimal peut se résumer à :

Audio → Texte
Mais dans un système réel, plusieurs contraintes apparaissent :

Déclenchement start / stop
Finalisation propre du fichier audio
Gestion d’état du recorder
Orchestration des étapes
Extension vers post-traitement (résumé, LLM, analyse)
La question devient alors :

Comment modéliser un pipeline audio propre, extensible et maîtrisé ?

Stack technique
Le MVP repose sur :

PHP 8+
Symfony
Symfony Messenger
Flow (orchestrateur)
ffmpeg (captation audio locale)
whisper.cpp (transcription open source locale)
Aucune API distante. Aucun service cloud. Transcription 100% locale.

Architecture générale
L’architecture est organisée en trois flows :

InputProvider → Recorder → Transcribe
Chaque étape est isolée et responsable d’un rôle précis.

InputProviderFlow
Responsabilité :

Écouter les commandes voice:start et voice:stop
Émettre un VoiceControlEvent
Les commandes CLI déclenchent des messages via Symfony Messenger.

Le worker, en arrière-plan, reçoit ces événements et les injecte dans Flow.

Ce découplage permet :

Un contrôle granulaire
Une gestion multi-session
Une séparation claire des responsabilités
RecorderFlow
Responsabilité :

Piloter une instance de VoiceRecorder
Gérer le cycle de vie d’un processus ffmpeg
Le VoiceRecorder encapsule un processus système lancé via :

Symfony\Component\Process\Process
Problème central :

Comment gérer proprement start / stop sans corrompre le fichier audio ?

Trois états sont explicitement modélisés :

idle
recording
stopping
Lors d’un stop, un SIGINT est envoyé à ffmpeg afin de finaliser correctement le header WAV.

L’état stopping évite :

Les double-start
Les conflits concurrents
Les fichiers incomplets
Le processus est maîtrisé, pas subi.

TranscribeFlow
Responsabilité :

Recevoir un fichier WAV finalisé
Lancer whisper.cpp
Produire un texte transcrit
Whisper est exécuté localement via CLI.

Le MVP reste volontairement simple :

Pas de streaming
Pas de chunking temps réel
Une transcription synchrone
L’objectif est de valider l’intégration et l’orchestration.

Worker et orchestration
Le moteur fonctionne via un worker Symfony :

php bin/console voice:worker
Ce worker :

Instancie Flow
Enregistre les flows
Écoute Symfony Messenger
Ordonne l’exécution des étapes
Commandes disponibles :

voice:start
voice:stop
voice:worker-list
Le flux complet devient :

voice:start
→ Recorder démarre
→ voice:stop
→ Recorder finalise
→ TranscribeFlow s’exécute
→ Texte produit
Sans état global externe.

Pourquoi Flow ?
Flow permet :

Une architecture orientée pipeline
Des stratégies d’Input Processing (IP Strategy)
Une gestion explicite des événements
Une séparation nette entre orchestration et logique métier
Le système n’est pas couplé à Whisper.

Whisper est une implémentation. Flow est la structure.

Ce que valide le MVP
Gestion propre d’un processus système
Modélisation explicite des états
Orchestration événementielle
Extensibilité du pipeline
Ce n’est pas un produit.

C’est une base architecturale.

Évolutions possibles
Les prochaines itérations naturelles :

Streaming par chunk audio
Transcription parallèle
Post-traitement LLM
Intégration NativePHP (desktop)
Support mobile
Batching multi-modèles
Mais ces évolutions ne changent pas le cœur :

Une architecture claire. Une orchestration maîtrisée. Un pipeline extensible.

Code source
Le dépôt open source est disponible ici :

👉 https://github.com/darkwood-com/flowvox

Contributions, suggestions et retours sont les bienvenus.

Conclusion
Construire un moteur vocal en PHP est simple.

Construire une architecture propre autour d’un moteur vocal est plus intéressant.

Flowvox valide un principe :

La transcription n’est qu’un composant. L’orchestration est la véritable structure.

⚔️ Découverte de l'extension cataclysme Hearthstone

Mathieu Ledru — Fri, 20 Feb 2026 22:06:20 +0000

La nouvelle ère destructrice arrive le 17 mars 2026

L’auberge est sur le point d’être secouée comme jamais. L’extension Cataclysme s’inspire d’une version alternative de l’univers de World of Warcraft, où Aile de mort n’a jamais été battu et règne en maître sur Azeroth.

🌋 Une intrigue sombre : la menace d’Aile de mort
À la fin de Par-delà les voies temporelles, Chromie déclenche par erreur une ligne temporelle cauchemardesque dans laquelle Aile de mort triomphe et envahit Azeroth avec ses six terribles lieutenants colossaux.

Dans Cataclysme :

Le ciel est rougeoyant
Azeroth doit à nouveau se défendre
Les héros et héroïnes doivent rallier les Vols draconiques
De nouvelles cartes et mécaniques sont là pour faire pencher la balance
💥 Nouvelle carte héroïque : Aile de Mort le Brise-monde
L’une des grandes nouveautés de Cataclysme est la première carte héroïque Deathwing jouable dans Hearthstone :

En la jouant, votre héros se transforme en Aile de Mort le Brise-monde
Son Cri de guerre vous permet de choisir un Cataclysme
Vous pouvez déclencher différentes actions destructrices selon vos choix et ressources
Plus vous utilisez le mot-clé Convocation avant de la jouer, plus vous pouvez déclencher de Cataclysmes simultanément
🧱 Mécaniques clés de Cataclysme
🔹 Convocation
Ce mot-clé est au cœur de l’extension :

Jouer un serviteur avec Convocation invoque un soldat colosse sur le plateau
Plus vous utilisez Convocation, plus votre serviteur colossal devient puissant
Convocation renforce aussi Aile de Mort le Brise-monde pour déclencher davantage de Cataclysmes
🔹 Retour des serviteurs Colossaux
Géants qui occupent plusieurs cases du plateau
Sont accompagnés d’appendices (bras, têtes) qui ont leurs propres effets
Une nouvelle légendaire colossale est disponible pour chaque classe fidélisée à Aile de mort (ex : Ragnaros le Grand Feu pour les guerriers)
🔹 Scission
Ce mot-clé innovant affecte certaines cartes de type défense des Vols draconiques :

Quand vous piochez une carte Scission, elle se sépare en deux morceaux
Ces morceaux se placent aux extrémités de votre main
Si vous les réunissez en jouant les cartes entre eux, ils se recombinent pour déclencher deux effets pour le prix d’un seul
🌀 Autres effets innovants
Cataclysme ajoute également des cartes qui permettent de :

Cibler des cartes spécifiques dans votre main
Manipuler la main à des fins tactiques
Renforcer votre deck pour des stratégies plus dynamiques
🛡️ Les Vols draconiques en renfort
Pour contrer la puissance d’Aile de mort :

🌟 Les classes mage, prêtre, druide, chasseur, paladin bénéficient d’un nouvel Aspect draconique légendaire. Par exemple, le chasseur obtient Ébyssian du Vol noir, capable de se transformer en puissant dragon.

🎁 Récompenses gratuites et événements
Blizzard a prévu un flot de récompenses pour préparer votre aventure :

🎉 Avant la sortie :
Paquets gratuits à gagner durant les diffusions Twitch
Accès temporaire aux cartes des extensions Au cœur du Rêve d’émeraude et La cité perdue d’Un’Goro du 10 mars jusqu’à la sortie de Cataclysme
Carte légendaire Maître de guerre Corne-Noire offerte au bonus de connexion
Drops Twitch jusqu’à plusieurs paquets gratuits
Récompenses pour événements en jeu (quêtes, vagues, hauts faits)
📅 Pendant et après le lancement :
Carte légendaire colossale gratuite au parcours de récompenses de la taverne
Récompenses hebdomadaires en connexion (paquets, cartes signature)
Récompenses liées aux quêtes de l’événement de lancement
Dos de carte spécial si vous terminez certains exploits en Bras de fer
👉 Bref : beaucoup de contenu gratuit à récupérer sans dépenser un centime si tu joues régulièrement.

📆 Calendrier important
🗓️ 10-17 mars : Bras de fer de prélancement – essayez la carte Aile de Mort et gagnez des récompenses 🗓️ 17 mars 2026 : Lancement de l’extension Cataclysme 📆 Du 10 mars au lancement : Accès temporaire aux cartes d’anciennes extensions pour tester des decks

💡 En résumé : qu’est-ce qui change ?
Cataclysme apporte une histoire alternative intense
Aile de mort est jouable et destructrice
De puissants mots-clés : Convocation, Scission
Retour des serviteurs colossaux
Beaucoup de récompenses gratuites
Un gameplay plus tactique et stratégique
💬 Mon avis Darkwood : Cette extension promet une expérience plus riche tactiquement, avec des decks qui récompensent la planification et la gestion de main. Elle offre aussi de nombreuses opportunités gratuites pour les joueurs Free-to-Play.

Références :

https://hearthstone.blizzard.com/fr-fr/expansions-adventures/cataclysm "Cataclysme"
https://hearthstone.blizzard.com/fr-fr/news/24245219/aile-de-mort-contre-attaque-dans-cataclysme-la-nouvelle-extension-de-hearthstone "Aile de mort contre-attaque dans CATACLYSME, la nouvelle extension de Hearthstone - Hearthstone"
https://hearthstone.blizzard.com/fr-fr/news/24242864/votre-guide-pour-decouvrir-les-cartes-de-cataclysme-et-obtenir-des-recompenses-gratuites "Votre guide pour découvrir les cartes de CATACLYSME et obtenir des récompenses gratuites - Hearthstone"

🤖 Développement parallèle d'IA avec Cursor et Git Worktrees

Mathieu Ledru — Sun, 15 Feb 2026 22:28:07 +0000

Dans cet article, je souhaite présenter un exemple concret de parallélisation du développement à l'aide de Cursor, Git worktrees et d'un véritable bundle Symfony :

👉 https://github.com/darkwood-com/ia-exception-bundle

L’objectif est simple : améliorer le produit en travaillant simultanément sur deux fonctionnalités indépendantes sans conflit, grâce à des agents d’IA.

Contexte
Je travaille actuellement sur un bundle Symfony appelé :

Pack d'exceptions Darkwood IA Dépôt : https://github.com/darkwood-com/ia-exception-bundle

Son objectif est d'améliorer la gestion des exceptions Symfony grâce à l'IA : lorsqu'une erreur 500 se produit, le module analyse l'exception et génère des diagnostics structurés (causes probables, solutions suggérées, score de confiance, etc.).

Cependant, en travaillant dessus en local, j'ai identifié deux améliorations.

🟥 Problème 1 Améliorer l'icône d'erreur
L'icône actuelle est une icône de « danger » standard de Bootstrap. Cela fonctionne, mais cela ne communique pas visuellement que l'exception est augmentée par l'IA.

L'idée : Remplacez-la par une icône de danger sur le thème de l'IA plus appropriée.

🟦 Problème 2 : Rendu asynchrone de l’analyse IA
Actuellement:

Une exception se produit.
L'appel à l'IA est déclenché.
La réponse HTTP attend l'IA.
La page complète n'est affichée qu'une fois que l'IA a terminé.
Cela introduit une latence.

Nous voulons plutôt :

Rendu immédiat des exceptions.
L'analyse IA est chargée de manière asynchrone. La page sera mise à jour dès réception de la réponse de l'IA.
Pour cela, nous utilisons Symfony UX.

Le Défi
Comment pouvons-nous travailler sur les deux problèmes en parallèle en utilisant Cursor sans créer de conflits de fichiers ?

La réponse provient d'une idée popularisée dans des articles récents sur les agents de codage IA :

Utilisez les répertoires de travail Git pour l'isolation du contexte.

Petit rappel concernant les arbres de travail Git
Un répertoire de travail Git vous permet de créer un nouveau répertoire de travail rattaché au même dépôt.

Ce n'est pas un clone parfait.

Il partage l'historique Git mais réside dans un répertoire physique distinct.

Exemple:

git worktree add ../feature-ai-icon feature/ai-icon
git worktree add ../feature-async-render feature/async-render
Vous avez maintenant :

Dépôt principal
Arborescence de travail A → Fonctionnalité 1
Arborescence de travail B → Fonctionnalité 2
Chacun peut évoluer indépendamment.

Aucun conflit de fichiers. Pollution sans contexte.

Pourquoi c'est important pour les agents IA
Avec Cursor, vous pouvez affecter un agent d'IA à chaque arbre de travail.

L'agent 1 travaille uniquement à l'intérieur :

feature/ai-icon
L'agent 2 travaille uniquement à l'intérieur :

feature/async-render
Chaque agent opère de manière isolée.

C’est ce que nous appelons :

Isolation du contexte

Et c'est essentiel pour paralléliser le développement piloté par l'IA.

Mise en œuvre pratique
Étape 1 Créer deux arbres de travail
J'ai créé manuellement deux arborescences de travail correspondant aux deux problèmes.

Ensuite, pour chaque arbre de travail, je :

Ouvert dans le curseur
J'ai collé la description du problème GitHub
Laisser l'agent IA implémenter la fonctionnalité
Étape 2 Rendu asynchrone des exceptions
Pour la fonctionnalité asynchrone, l'IA a implémenté :

Un chargeur de route dédié
Un IAExceptionController
Un système de stockage de contexte
Un service d'analyse différée de l'IA Comportement conditionnel lorsque le mode asynchrone est activé
Le flux de travail est maintenant le suivant :

L'exception est générée instantanément.
Symfony UX charge l'analyse IA de manière asynchrone.
La page se met à jour dynamiquement dès réception de la réponse de l'IA.
Cela améliore considérablement la performance perçue.

Amélioration de l'icône de l'étape 3
Dans le deuxième arbre de travail, l'agent :

Icône de danger Bootstrap remplacée
Introduction d'un SVG plus épuré sur le thème de l'IA
Compatibilité de mise en page maintenue
Style Bootstrap préservé
Cela était totalement indépendant de la fonctionnalité asynchrone.

Pas de code qui se chevauche.

Basculement entre les fonctionnalités
Comme il s'agit d'arborescences de travail, changer de contexte est facile.

Dans mon application Darkwood locale :

Le paquet est normalement chargé via Composer.
J'ai temporairement lié le paquet à l'arborescence de travail correspondante.
Cache vidé.
Une exception contrôlée a été déclenchée.
Je pourrais alors tester chaque fonctionnalité indépendamment.

Passer de la fonctionnalité A à la fonctionnalité B est uniquement nécessaire :

Modification du lien symbolique
Nettoyage du cache
Rafraîchissant
Pas de fusion. Pas de rebasage. Aucun conflit.

Nos réalisations
Nous avons maintenant :

Deux demandes de fusion indépendantes
Deux agents d'IA isolés Aucun conflit de fichiers
Séparation claire des préoccupations
Ces modifications ont été publiées dans :

👉 v1.0.2 https://github.com/darkwood-com/ia-exception-bundle/releases/tag/v1.0.2

Cette version introduit :

Améliorations de l'interface utilisateur pour le rendu des exceptions d'IA
Chargement de l'analyse IA asynchrone
Séparation architecturale améliorée pour les développements futurs
Quand cela va-t-il se rompre ?
Le développement parallèle fonctionne mieux lorsque les problèmes sont :

Clairement séparés
Cibler différentes couches
Ne pas modifier les mêmes fichiers
Si deux problèmes se modifient :

Le même service
Le même modèle Twig
La même manette
Vous rencontrerez des conflits de fusion plus tard.

Le développement parallèle de l'IA nécessite une décomposition adéquate des tâches.

Considérations relatives à la production
Si vous poussez plusieurs branches :

Vous pourriez rencontrer des conflits de ports au niveau local.
Les environnements de prévisualisation peuvent nécessiter une configuration.
Les fonctionnalités asynchrones peuvent nécessiter la persistance du contexte.
Ces problèmes sont gérables, mais doivent être pris en compte.

Pourquoi c'est puissant
La véritable valeur ne réside pas dans le modèle d'IA.

C'est:

Isolement
Orchestration
Contrôle du contexte
Les arborescences de travail Git nous permettent de faire évoluer les sessions de codage IA sans chaos.

Conclusion
Le développement parallèle de l'IA ne consiste pas à exécuter davantage de modèles.

Il s'agit d'isoler correctement le contexte.

Avec:

Arbres de travail Git
Agents de curseur
Expérience utilisateur Symfony
Décomposition propre des problèmes
Vous pouvez faire évoluer en toute sécurité des systèmes complexes sans compromettre vos propres modifications.

Références
Ensemble d'exceptions IA du référentiel https://github.com/darkwood-com/ia-exception-bundle

Version 1.0.2 https://github.com/darkwood-com/ia-exception-bundle/releases/tag/v1.0.2

Arbres de travail Git pour agents de codage IA parallèles Upsun https://devcenter.upsun.com/posts/git-worktrees-for-parallel-ai-coding-agents/

Arbres de travail Git : La puissance des agents parallèles de Cursor DEV.to https://dev.to/arifszn/git-worktrees-the-power-behind-cursors-parallel-agents-19j1

Configuration des arborescences de travail de la documentation du curseur https://cursor.com/fr/docs/configuration/worktrees

🤖 Comment rendre Darkwood prêt pour les agents

Mathieu Ledru — Thu, 12 Feb 2026 07:55:32 +0000

Les sites web ne sont plus seulement consommés par les humains.

Elles sont analysées, résumées, classées et interprétées par des agents d'IA.

Les moteurs de recherche ont constitué la première vague. Les agents utilisant LLM représentent la seconde.

Récemment, j'ai décidé d'auditer darkwood.com et d'y apporter des améliorations concrètes afin de le rendre plus compréhensible et plus explicite pour les systèmes d'IA.

Cet article explique ce qui a changé et pourquoi.

Pourquoi optimiser pour les agents IA ?
Le référencement traditionnel se concentre sur les signaux de classement.

Les agents d'IA fonctionnent différemment.

Ils:

Analyser la structure
Extraire l'intention
Suivre les liens comme des chemins de décision
Classer les types de pages
Évaluer le niveau de confiance
Si votre site web est ambigu, la compréhension d'un agent devient probabiliste et fragile.

L'objectif était simple :

Réduire l'ambiguïté. Accroître la clarté.

Observation initiale : Ambiguïté de la page d’accueil
Historiquement, Darkwood combine plusieurs dimensions :

Un blog technique
Projets personnels
Un espace de jeu/communauté
Pour les humains, cet écosystème est logique.

Cependant, pour les systèmes d'IA qui arrivent sur la page d'accueil, les signaux visuels dominants (connexion, jeu, chat, classement) peuvent biaiser l'interprétation vers un portail de jeux plutôt que vers un centre de connaissances techniques.

Ce n'est pas « faux », mais c'est imprécis.

La précision est essentielle lorsque les agents décident comment classer et réutiliser les informations.

Étape 1 — Ajout de llms.txt
La première amélioration a consisté à introduire un fichier llms.txt à la racine.

Ce fichier sert de couche de guidage légère pour les systèmes d'IA.

Il définit explicitement :

Qu'est-ce que Darkwood ?
Où se trouve le contenu à signal élevé ?
Ce que les agents sont autorisés à faire
Ce qu'ils doivent éviter
Comportement d'exploration suggéré
Au lieu d'obliger les agents à déduire la structure par l'exploration, nous proposons un contrat minimal.

Exemple d'extrait :

Primary entry points (recommended)

Blog: https://blog.darkwood.com/
Profile: https://hello.darkwood.com/

What to avoid

Do not attempt login/register
Do not submit forms
Avoid aggressive crawling Ce petit ajout réduit considérablement l'ambiguïté et empêche toute interaction involontaire avec les zones dynamiques ou authentifiées.

Cela permet également au blog d'être immédiatement repérable comme la principale plateforme de contenu à forte valeur ajoutée.

Étape 2 — Mise en œuvre des données structurées (JSON-LD)
Le type de contenu le plus important sur Darkwood est l'article de blog.

Pour que cela soit explicite, chaque page d'article expose désormais un bloc JSON-LD Schema.org BlogPosting.

Cela comprend :

headline
description
datePublished
dateModified
inLanguage
author
publisher
mainEntityOfPage (URL canonique)
Exemple:

{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Making Darkwood Agent-Ready",
"datePublished": "2026-02-12T00:00:00+01:00",
"inLanguage": "en",
"author": {
"@type": "Person",
"name": "Mathieu Ledru",
"url": "https://hello.darkwood.com/"
},
"publisher": {
"@type": "Organization",
"name": "Darkwood",
"url": "https://darkwood.com/"
}
}
Pourquoi c'est important :

Les agents n'ont plus besoin de deviner le type de page
Les métadonnées de publication deviennent fiables
L'alignement canonique est explicite
Le contexte linguistique est clair
Les données structurées renforcent la confiance dans les systèmes de raisonnement automatisés.

Cela réduit l'entropie interprétative.

Ce qui a changé techniquement
La mise en œuvre requise :

Ajout d'un fichier statique llms.txt à la racine du domaine
Garantie d'une diffusion correcte en texte brut
Injection de JSON-LD dans les modèles d'articles
Alignement des URL canoniques
Normalisation du format de date ISO-8601
Aucune nouvelle dépendance n'a été introduite. Aucune modification de l'interface utilisateur n'a été nécessaire.

Les modifications sont minimes, mais structurelles.

Pourquoi c'est important
L'optimisation pour les agents d'IA ne consiste pas à suivre les tendances.

Il s'agit de :

Énoncer clairement son intention
Réduire l'ambiguïté
Rendre le contenu interprétable par machine
Définir explicitement les limites
Les sites web s'intègrent de plus en plus à des écosystèmes automatisés.

La clarté n'est plus une option.

Détails de mise en œuvre
Vous pouvez consulter l'implémentation exacte dans la demande d'extraction correspondante :

👉 https://github.com/darkwood-com/darkwood-com/pull/106

🧑‍💻 Codeur vs Vibe codeur

Mathieu Ledru — Wed, 11 Feb 2026 09:22:32 +0000

Pendant longtemps, la distinction entre un bon développeur et un développeur médiocre se faisait sur des critères classiques : lisibilité du code, architecture, performances, tests. Ces critères restent valables. Mais ils ne suffisent plus à décrire ce qui est en train d’émerger.

Avec l’arrivée d’outils comme Cursor, une autre posture devient visible : celle du vibe codeur.

Ce n’est pas un nouveau métier. Ce n’est pas non plus “coder avec de l’IA”. C’est un déplacement du centre de gravité.

Le codeur : le code comme point d’entrée
Le codeur “classique” travaille dans un environnement où :

les fichiers sont centraux
l’arborescence est la carte du territoire
l’IDE est un instrument de précision
La logique est la suivante :

Le problème est compris → le code est écrit → le résultat émerge

Dans cette posture :

le code est la source de vérité
l’outil (IDE, AI, terminal) est un accélérateur
l’intention est traduite manuellement en structure
Cette approche est robuste, déterministe, efficace sur des problèmes bien définis. Elle reste indispensable.

Le vibe codeur : l’intention comme point d’entrée
Avec les IDE augmentés par l’IA, une autre posture apparaît.

Dans Cursor, un simple détail devient révélateur : le fait de placer l’agent AI à gauche et les fichiers à droite.

Ce changement n’est pas cosmétique.

Il traduit une inversion :

l’interface principale devient conversationnelle
les fichiers deviennent une projection
le code n’est plus le point de départ, mais le résultat
Le raisonnement devient :

J’exprime une intention → je valide une direction → le code s’aligne

Ce qui change réellement
La différence ne se situe pas dans :

le langage
le framework
la qualité syntaxique
Elle se situe dans ce qui guide l’action.

Le vibe codeur ne “lâche” pas la technique. Il la retarde volontairement.

Le code devient une conséquence, pas une preuve
Dans une approche vibe :

on ne prouve plus la compétence par la complexité du code
on la prouve par la cohérence du résultat
le code est jetable, réécrivable, ajustable
Ce qui compte :

la clarté de l’intention
la vitesse de convergence
la capacité à corriger le tir sans attachement excessif à l’implémentation
Le code cesse d’être un artefact sacré. Il devient un support de matérialisation.

Cursor n’est pas la cause, c’est le révélateur
Important : Cursor ne crée pas le vibe coding.

Il le rend visible.

Il expose :

une mémoire de contexte persistante
une continuité d’intention
un espace où la pensée précède la structure
Le changement de layout (agent à gauche, fichiers à droite) agit comme un révélateur cognitif :

ce n’est plus le code qui guide la pensée, c’est la pensée qui guide le code.

Le codeur et le vibe codeur ne s’opposent pas
Ils ne sont pas concurrents. Ils sont complémentaires.

le codeur excelle dans la stabilisation
le vibe codeur excelle dans l’exploration
l’un solidifie
l’autre oriente
Dans les systèmes complexes, les deux sont nécessaires. Mais ignorer l’émergence du vibe coding, c’est manquer une mutation majeure : celle où l’intention devient la primitive principale du développement.

Conclusion
Le vibe codeur ne remplace pas le codeur. Il déplace simplement le centre de gravité :

du code vers l’intention
de l’implémentation vers l’expérience
de l’outil vers le flux cognitif
Le code reste indispensable. Il n’est simplement plus le point de départ.

⚙️ FOSDEM 2026 : signaux structurels de l’écosystème open source

Mathieu Ledru — Sun, 01 Feb 2026 19:15:57 +0000

IMG_4396.jpg
FOSDEM 2026 a marqué ma première participation en présentiel à l'événement, limitée aux sessions du samedi. Ce qui frappe immédiatement, c'est son ampleur : des dizaines de sessions parallèles, des centaines de conférences et une nécessité constante de faire des choix. On comprend très vite que FOSDEM ne se prend pas à la légère ; sans préparation, la densité même du contenu devient vite étouffante.

Une seule journée sur place a suffi pour comprendre que le véritable défi n'est pas l'accès à l'information, mais sa sélection. Choisir les salles à privilégier, les conférences à suivre en direct ou en différé, et quand utiliser le système de chat de la conférence, fait partie intégrante de l'expérience. Cet article reflète cette première impression, en combinant observations directes et données techniques issues des sessions suivies.

Discours d'ouverture et souveraineté numérique Le discours d'ouverture de FOSDEM 2026 a abordé la question de la souveraineté numérique. Un concept central introduit était celui de « logiciels libres et open source en temps de guerre, de pénurie et d'IA (adversaire) » ou de location stratégique d'ordinateurs », décrivant la transition progressive du secteur vers des stratégies privilégiant le cloud et la facilité d'utilisation au détriment de l'autonomie. Ce modèle renforce les dépendances structurelles aux plateformes propriétaires, exposant les utilisateurs et les organisations à des modifications unilatérales, des interruptions de service ou des contraintes imposées par des politiques spécifiques.

D'un point de vue systémique, la chaîne d'approvisionnement logicielle est apparue comme une surface d'attaque majeure. Une entreprise européenne moyenne dépendant de dizaines de milliers de composants logiciels, l'infrastructure moderne ressemble de plus en plus à une tour de Jenga : stable jusqu'à ce qu'un seul bloc, souvent invisible, soit retiré. Des incidents tels que la porte dérobée XZ et des stratégies d'infiltration similaires à long terme illustrent comment les faiblesses de la chaîne d'approvisionnement sont exploitées de manière asymétrique au fil du temps.

Plutôt que de proposer des réponses axées sur la réglementation, le discours d'ouverture a mis l'accent sur la structure organisationnelle comme enjeu technique fondamental. Plus précisément, les organisations à responsabilité limitée dotées de missions d'intérêt public explicites ont été présentées comme une alternative structurelle aux modèles axés sur le capital-risque, où les incitations à la sortie à court terme entrent souvent en conflit avec l'intégrité de l'infrastructure à long terme.

Échelle, densité et nécessité de préparation FOSDEM 2026 a réuni plus de 8 000 participants et proposé plus de 1 000 conférences réparties dans 65 salles de développement, ce qui en fait l'un des rassemblements techniques open source les plus importants d'Europe. Ma première participation, limitée à la première journée, a suffi à mettre en évidence une contrainte récurrente : FOSDEM ne se prête pas à une approche opportuniste.

Le nombre important de sessions parallèles rend la prise de décision en temps réel inefficace. Tirer pleinement profit de l'événement nécessite une préparation en amont, notamment l'identification préalable des thématiques, des intervenants et des domaines techniques. Sans cela, la conférence se transforme rapidement en un exercice de changement constant de contexte plutôt qu'en un moment d'apprentissage ciblé.

Cette densité se reflète dans l'écosystème numérique de FOSDEM. La plateforme de chat officielle, fonctionnant sous Matrix/Element et accessible via chat.fosdem.org, prolonge les discussions au-delà des salles physiques. Elle sert de plateforme de coordination pour les modifications de dernière minute, les suivis techniques et les échanges asynchrones, un complément essentiel lorsque la présence physique seule ne suffit pas.

L'évolution des outils plutôt que le battage médiatique Plusieurs sessions ont confirmé une tendance plus générale : l’innovation significative dans l’open source se situe actuellement au niveau des outils de base, et non au niveau des nouveautés de la couche produit.

Les discussions autour de Git v3 se sont concentrées sur les contraintes de mise à l'échelle extrême, notamment pour les dépôts contenant des dizaines de millions de références. L'adoption du backend reftable permet des mises à jour atomiques et des vues de référence cohérentes, palliant ainsi les limitations persistantes des systèmes de fichiers. Les recherches sur le découpage par blocs défini par le contenu pour les objets volumineux laissent également entrevoir la réintégration de fonctionnalités auparavant externalisées vers des systèmes comme Git LFS.

Git

De même, les sessions Webview ont mis l'accent sur la portabilité et la spécification comportementale plutôt que sur de nouvelles abstractions. Les ingénieurs documentent de plus en plus les divergences entre les plateformes, notamment entre Android et iOS, afin de définir des bases stables pour le contenu web intégré. L'intérêt porté au moteur Servo témoigne d'une volonté de disposer de composants découplés et performants, indépendants des moteurs monolithiques du système d'exploitation.

Webview

Dans les deux cas, l'accent est mis sur la maintenance, la prévisibilité et l'échelle, et non sur la perturbation.

Systèmes appliqués soumis aux contraintes du monde réel La présentation de Botronics a illustré comment l'ingénierie appliquée se confronte aux contraintes physiques. Concevoir un chariot de golf autonome grand public avec un prix cible d'environ 5 000 € implique des compromis constants entre fonctionnalités, fiabilité et coût.

Les principales décisions techniques ont été dictées par la réalité opérationnelle :

La migration vers Zenoh pour la communication de mémoire partagée a permis de réduire l'utilisation du processeur d'environ 10 %, améliorant ainsi l'efficacité thermique et énergétique. * Balena a été adopté pour les mises à jour OTA afin d'éviter la complexité opérationnelle liée à la maintenance d'images Yocto personnalisées sur un parc d'appareils. * L'exploitation en environnements extérieurs non contrôlés a orienté les efforts vers une localisation robuste et une détection d'obstacles par vision par ordinateur, en évitant délibérément les systèmes de capteurs coûteux tels que le LiDAR.
Il ne s'agissait pas d'un discours sur l'innovation pour l'innovation, mais sur la discipline de l'ingénierie sous contrainte.

Boucles de rétroaction directe : le cas Joplin Joplin stand

L'un des atouts structurels de FOSDEM demeure l'accès direct aux responsables de la maintenance. Les échanges avec Laurent Cozic, créateur de Joplin, et Greg Lagarde, responsable marketing chez Joplin, ont permis de mieux comprendre l'évolution du projet, notamment celle de l'application web open source Joplin, actuellement en version bêta.

Ces échanges permettent d'obtenir des retours d'information qui vont au-delà des outils de suivi des problèmes, notamment concernant les modèles de synchronisation, la cohérence interplateforme et les pratiques d'utilisation réelles. Cela rejoint les précédents articles de Darkwood qui présentent Joplin comme un outil quotidien de gestion des connaissances, notamment :

Introduction à Joplin
Automatisation de la création de notes dans Joplin
Cette interaction a renforcé le positionnement de Joplin en tant que système de gestion autonome des connaissances, où le contrôle des données, des formats et des flux de travail demeure primordial. Vous pouvez en avoir un aperçu sur la chaîne YouTube.

Automatisation, IA et mentalité de chaîne d'outils Les discussions sur l'IA lors du FOSDEM ont été remarquablement pragmatiques. Plutôt que de présenter l'IA comme un substitut cognitif, plusieurs conversations ont fait écho à la mise en garde du discours d'ouverture concernant la délégation de la pensée elle-même, parfois décrite comme un chemin vers la « démence numérique ».

L’attention s’est plutôt portée sur l’IA comme outil d’augmentation des infrastructures :

Utilisation de plugins tels que Jarvis pour une assistance contextuelle dans les notes. * Exploration des intégrations basées sur MCP pour connecter les systèmes de notes à des modèles de langage locaux ou auto-hébergés. * Maintien des charges de travail d'IA locales, conteneurisées et auditables, en évitant les dépendances opaques aux solutions SaaS.
Dans cette perspective, l'IA est considérée comme une couche de nettoyage prenant en charge des tâches répétitives ou structurelles plutôt que comme une source de vérité faisant autorité.

Écosystème, campus et réalité physique La présence des distributions fondamentales Ubuntu, Debian, Nix à FOSDEM souligne la nature stratifiée de l'écosystème open source. Ces projets constituent le socle sur lequel repose l'innovation de plus haut niveau.

Ubuntu Nix

Le campus Solbosch de l’Université Libre de Bruxelles (ULB), situé à environ 30 minutes du centre de Bruxelles en métro et en bus, offre un pendant physique idéal à cette structure à plusieurs niveaux : vaste, décentralisé et parfois complexe à parcourir. Son ampleur souligne la nécessité d’une circulation intentionnelle, tant physique qu’intellectuelle, tout au long de l’événement.

Au-delà des conférences et des stands, FOSDEM sert également de point de convergence pour des rencontres informelles et directes. Ces échanges informels font souvent émerger des problématiques de gouvernance, des orientations de projets à long terme et des tensions au sein de l'écosystème qui sont rarement abordées lors de présentations formelles.

ULB

Conclusion
FOSDEM 2026 confirme une évolution majeure au sein de l'open source : un passage d'une innovation fragmentée à des infrastructures intégrées, résilientes et souveraines. Aujourd'hui, les travaux les plus importants se concentrent sur des domaines souvent considérés comme peu attrayants : l'outillage, la maintenance, la gouvernance et la gestion des dépendances.

Tirer profit d'un tel écosystème exige de la préparation, de la sélectivité et une bonne compréhension de celui-ci. FOSDEM ne récompense pas la consommation passive. Il valorise ceux qui l'abordent comme un système à appréhender, et non comme un événement auquel participer.

🎮 Comprendre l’ECS : la brique invisible derrière les jeux modernes

Mathieu Ledru — Mon, 13 Oct 2025 09:30:13 +0000

Quand on conçoit un jeu, surtout un jeu tactique ou systémique comme Darkwaar, on se retrouve vite à jongler entre :

des entités (joueurs, ennemis, objets, cases),
des comportements (mouvement, attaque, effet),
et des systèmes (rendu, IA, collisions, effets de statut...).
Les approches orientées objet classiques finissent vite par créer des hiérarchies trop profondes : Player extends Character extends Entity extends Drawable extends Object… Résultat : une usine à gaz.

C’est là qu’intervient l’ECS — Entity Component System.

⚙️ L’idée de base
L’ECS part d’un principe simple :

séparer les données, le comportement, et l’exécution.

| Élément | Rôle | Exemple | | ------------- | ------------------------------------------- | --------------------------------------------------------- | | Entity | Identifiant unique | #23 = Guerrier sur la case (3,2) | | Component | Données brutes (pas de logique) | Position(3,2), Vie(10), Attaque(3) | | System | Comportement (agit sur certains composants) | SystemeDeMouvement, SystemeDeCombat, SystemeDeRendu |

L’ECS ne remplace pas la programmation orientée objet — il la déstructure pour la rendre évolutive. Au lieu d’écrire ce que fait chaque classe, on définit comment les données interagissent.

🧩 Exemple concret
Prenons un exemple simplifié en GDScript (Godot) :

Composant Position

class_name CPosition
extends Resource
@export var q:int
@export var r:int

Composant Vie

class_name CVie
extends Resource
@export var hp:int = 10

Système de rendu

extends Node
const CPosition = preload("res://components/CPosition.gd")

func process_system(dt):
for entity in get_entities_with([CPosition]):
var pos = entity.get_component(CPosition)
draw_unit(pos.q, pos.r)
Ici :

l’entité ne “fait” rien — elle contient des composants ;
les systèmes se déclenchent sur les entités qui possèdent un certain ensemble de composants.
C’est une approche data-driven : tout est piloté par les données.

🧮 Pourquoi c’est puissant
L’ECS n’est pas juste un design pattern à la mode. C’est une approche structurante qui résout trois problèmes majeurs :

Évolutivité Tu peux ajouter de nouveaux comportements sans casser les anciens :

Ajouter un composant CInvisible suffit pour qu’un système “Rendu” ignore ton entité.

Rejeu et simulation
Tu peux rejouer une partie en appliquant la même séquence d’événements, car tout l’état du jeu est pur data, sérialisable, diffable et testable.
Performance
Les ECS modernes (comme Flecs, EnTT ou Unity DOTS) stockent les données en mémoire contiguë. Le CPU adore ça :

moins d’appels, moins de cache-miss, plus de vitesse.

🧱 Dans Darkwaar 5
Darkwaar 5 repose sur un ECS léger en GDScript, sans moteur externe. L’objectif est d’avoir :

un monde (World) central,
des entités simples (un Node par personnage ou objet),
des composants (Resource) pour les données,
des systèmes (Node) pour la logique.
Exemple simplifié :

GameRoot.gd

@onready var world := $World

func _ready():
var unit = world.create_entity()
unit.add_component(CPosition.new())
unit.add_component(CVie.new())
Chaque frame :

le World passe sur les systèmes actifs ;
les systèmes parcourent les entités qui les concernent ;
et la logique s’exécute sur les données brutes.
Cette séparation permet d’ajouter facilement :

un système de buffs (effets temporaires),
un système de résolution de combat,
ou un système de puzzle pour les niveaux.
🧩 ECS ≠ magie
L’ECS ne fait pas “mieux” qu’une approche orientée objet : il fait plus simple à maintenir.

Mais il y a un coût : il faut penser en flux de données, pas en hiérarchie d’objets.

Pas de “Player.move()”, mais un SystemMouvement qui lit les CPosition et CVitesse.
Pas de “Enemy.attack()”, mais un SystemCombat qui lit les CCombat et CVie.
C’est un changement de paradigme — mais une fois compris, tout devient plus clair.

🧭 Ce que Darkwood en retient
Chez Darkwood, l’ECS n’est pas qu’une architecture de jeu. C’est une façon de penser la modularité :

Dans Darkwaar, il structure le gameplay et les puzzles.
Dans Uniflow, il inspire la logique des “flows” de données.
Dans Flow, il sert de base pour la composition visuelle d’automatisations.
Même combat : séparer les données, les comportements et la logique d’exécution.

🔮 Et après ?
La prochaine étape pour Darkwaar 5 :

intégrer l’ECS au système de carte isométrique ;
lier chaque case à une entité ;
et synchroniser les composants entre la vue (haut) et le HUD (bas).
Cela posera les fondations d’un moteur tactique isométrique open-source, pensé pour la génération procédurale, les puzzles et les systèmes émergents.

🧩 Ressources
ECS FAQ – Sander Mertens (Flecs)
Zeste de Savoir – L’Entity Component System
Bevy Engine – ECS in Rust
Unity DOTS documentation

🚀 Uniflow 1.1.18

Mathieu Ledru — Mon, 06 Oct 2025 09:33:59 +0000

✨ Darkwood Update : Uniflow 1.1.18 & les prototypes Darkwaar intégrés sur uniflow.io

🧩 Uniflow 1.1.18 – Le nouveau composant HtmlFlow
La version 1.1.18 d’Uniflow introduit un nouveau composant clé : HtmlFlow. Il permet désormais d’afficher directement du contenu HTML stocké dans une variable de contexte — que ce soit un fragment de texte, un rendu visuel ou même une iframe générée dynamiquement par un autre flow.

Ce composant, développé la semaine dernière, marque une étape importante dans la philosophie Flow Based Programming d’Uniflow : rendre les flows autonomes, visuels et interactifs, sans dépendre d’une interface externe.

⚙️ Exemple minimal
// JavascriptFlow
const iframe = <iframe frameborder="0" src="https://itch.io/embed-upload/15043973?color=333333" allowfullscreen width="640" height="380"> <a href="https://darkwoodcom.itch.io/darkwaar1">Play Darkwaar1 on itch.io</a> </iframe>;

context.gameHtml = iframe;
return context;

// HtmlFlow → Variable = gameHtml
Ici, le JavascriptFlow crée une iframe (par exemple vers un jeu itch.io) et la stocke dans gameHtml. Le HtmlFlow récupère cette variable et l’affiche directement, sans iframe interne, grâce à un rendu sécurisé côté client.

🔒 Un rendu HTML sécurisé
Le HtmlFlow n’est pas un simple dangerouslySetInnerHTML. Il applique un filtrage DOM personnalisé, spécialement conçu pour autoriser les intégrations (iframe, markup simple) tout en bloquant les attaques XSS ou les injections CSS.

Parmi les règles appliquées :

Suppression des balises dangereuses (script, object, embed, form, button, etc.)
Suppression des attributs on* (ex. onclick) et style
Vérification stricte des URLs (https: ou relatives uniquement)
Nettoyage des iframe : seuls les attributs sûrs (src, width, height, frameborder, allowfullscreen, sandbox) sont conservés
Ajout automatique d’un sandbox sécurisé sur les iframes
Protection SSR : pas d’exécution côté serveur
Mémoïsation et limites de taille pour éviter les rendus excessifs
Ces garde-fous garantissent un équilibre entre flexibilité et sécurité, idéal pour intégrer des visualisations ou des jeux sans compromettre la stabilité du flow.

🎮 Darkwaar – Vers un puzzle game jouable
En parallèle, l’univers Darkwaar continue de prendre forme. J’ai commencé plusieurs prototypes de puzzle games, jouables directement sur itch.io, explorant différentes mécaniques :

Placement stratégique sur une grille,
Tour par tour et gestion des pions,
Résolution par logique (trouver le prochain coup gagnant).
Ces prototypes me permettent d’itérer rapidement sur le gameplay avant de stabiliser une version principale. L’objectif à court terme : un puzzle jouable au format web, accessible à tous depuis itch.io.

🌐 Uniflow × Darkwaar – Intégration native via HtmlFlow
Grâce au nouveau composant HtmlFlow, j’ai pu intégrer directement les quatre projets Darkwaar dans Uniflow. Chacun des prototypes est désormais visible depuis un flow dédié sur uniflow.io/flows.

Cette intégration montre concrètement comment Uniflow peut servir de hub créatif : les flows deviennent des modules capables d’orchestrer, d’afficher et d’héberger des créations interactives — ici, des jeux Darkwaar — dans un même environnement.

💡 Cette approche ouvre la voie à un espace où automatisation et création ludique se rejoignent. Chaque prototype Darkwaar est un flow, et chaque flow peut devenir une expérience jouable.

🔗 Liens utiles
🧩 Uniflow 1.1.18 — Lire la release sur GitHub
✨ Article technique complet — HtmlFlow sur le blog Uniflow
🎮 Prototypes Darkwaar — Disponible sur uniflow.io/flows
🌑 Darkwood — darkwood.com
🔮 Et après ?
Les prochaines versions d’Uniflow continueront d’explorer la dimension visuelle et interactive des flows :

presets d’intégration sécurisée (itch.io, YouTube, dashboards),
composants de visualisation avancés,
et connexion naturelle entre automatisation, jeu et création artistique.
Darkwaar, de son côté, suivra ce mouvement. L’objectif reste le même : construire un univers cohérent où la programmation, l’imagination et le jeu se rencontrent.

✍️ Mathieu Ledru Darkwood – Automate. Create. Play. Music

🎁 Je propose des séances de coaching gratuites de 30 minutes pour aider les créateurs comme vous à automatiser leurs processus et à gagner du temps ⏱️

👉 Réservez votre séance gratuite ici : https://www.bonzai.pro/matyo91/lp/4471/je-taide-a-automatiser-tes-process

Merci de votre lecture ! Créons ensemble des workflows intelligents, rapides et automatisés 💻⚡