Forem: Mathieu Ledru

👨‍💻 Benchmarking Small Language Models in the Real World

Mathieu Ledru — Tue, 21 Apr 2026 07:55:27 +0000

On Saturday, April 18th, I participated in a hackathon that invites machine learning engineers, data engineers and researchers to Paris for an in-depth study of the evaluation of small language models (SLM).

This hackathon, organized by AI Tinkerers Paris, addresses a very concrete problem:

test the actual ability of language models to produce production-ready executable code.

The theme - "Benchmarking Small Language Models in the Real World" - sets a clear framework: moving beyond impressive demos to confront models with real-world constraints (execution, performance, resources).

🎯 Objective

The challenge is to automatically generate Polars queries from natural language, with a strong requirement:

produce correct code
ensure that it is executable
Optimize execution time and memory consumption

The scoring reflects this reality:

Score = N / (T × VRAM^0.1 × RAM^0.01)

👉 In other words: accuracy alone is not enough - system efficiency becomes a central constraint.

⚙️ Technical Context

Each team works in a standardized environment:

execution under Docker
Use of Polars for data processing
GPU/memory constraints
evaluation dataset provided

The goal is not to create "the best prompt", but to build a system capable of:

withstand real data
produce robust code
run an automated benchmark

🧩 Positioning

This hackathon stands out because of its approach:

no marketing demo
no "impressive but fragile" generation
focus on what really works

👉 This is an environment that directly exposes the current limitations of LLM:

hallucinations
syntax errors
Misunderstanding of the data schema

And it forces you to build around it.

prompt structured engineering
systematic validation
fast iteration loop

📊 Reading

This is not a "creative" hackathon, but an engineering benchmark.

The final deliverable is not an idea, but:

a measurable, reproducible, and comparable system.

🏗️ Day's Organization

Morning - framing and initialization

The morning is dedicated to setting up the technical and organizational framework:

Team formation via the event portal
Presentation of the problem by the organizers and mentors
Clarification of expectations (generation of executable Polars code + scoring)
Initial setup of the work environment

The Darkwood team is formed around:

The objective of this phase is to reduce uncertainty and align everyone on an executable pipeline from the very first hours.

Midday - Forced Break

Lunch provided on site
informal exchanges between teams
Consultation of the message center (general questions, clarifications from the jury)

👉 Short phase, without real decoupling: the project remains in iteration.

Afternoon - Implementation and Iterations

The afternoon is entirely production-oriented:

implementation of the benchmark (polars-bench)
integration of the model via ai-harness
experimentation on prompts (structure, format, constraints)
Adjusting model behavior via dataset and prompt engineering
progressive validation via actual execution

The iterations focus on three areas:

Hallucination reduction (schema-aware prompting)
improved executable code rate
score optimization (time / memory / accuracy)

👉 The logic is not to add features, but to tighten the system around real constraints.

⚙️ Benchmark Architecture

The system relies on a clear separation of responsibilities:

ai-harness → pattern orchestration layer
polars-bench → execution and evaluation engine

This breakdown allows us to isolate the generation (LLM) from the execution reality (runtime), which is precisely the objective of the benchmark.

🤝 Sponsors, Mentors & Organizers, Teams

This hackathon is made possible thanks to an ecosystem of complementary players: sponsors, mentors and organizers, each playing a key role in the overall experience.

🏢 Organizers

The event is organized by the AI Tinkerers Paris community, a collective active in experimenting with and sharing AI technologies.

🌐 Official website: https://paris.aitinkerers.org
📅 Hackathon page: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk
👥 Organizers: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/organizers

Their positioning is clear: to promote concrete experimentation around AI models, with a focus on real engineering rather than demonstration.

💼 Sponsors

Sponsors support the event by providing:

technical resources (GPU, infrastructure, tools)
funding
visibility

👉 Their role is critical to enabling a realistic environment (compute constraints, Docker execution, etc.).

Mistral
- Sponsor page: Hackathon Sponsors
- Representative: Matthieu Dinot — AI Scientist at Mistral
Alpic
- Sponsor page: Hackathon Sponsors
- Representative: Nikolay Rodionov — COO at Alpic
- Other links:
- X / Twitter
- GitHub
Cloudfare
- Sponsor page: Hackathon Sponsors
- Representative: Nans Cyril Bouissou — Account executive at Cloudfare
Fold
- Sponsor page: Hackathon Sponsors
- Representative: Raouf Chebri — Developer Relations Engineer at Replit
Microsoft
- Sponsor page: Hackathon Sponsors
- Representative: Julien Bichon — Developer Experience | GTM Manager at Microsoft
ESGI (venue partner mentioned alongside sponsors)
- Sponsor / venue page: Hackathon Sponsors
- Representative: Astrid Beaucourt — Communications Officer at ESGI
- School links:
- LinkedIn
- X/Twitter

🧑‍🏫 Mentors

Mentors support participants throughout the hackathon:

assistance in structuring approaches
Feedback on templates and prompts
tips on performance and optimization

👉 They help avoid common dead ends:

over-optimization of the prompt
lack of validation
errors in data interpretation
Arthur Mensch
- Mentor page: Hackathon Mentors
- Role: Co-founder and CEO of Mistral AI
- Public profile link: not visible in the provided data
Leo Arsenin
- Mentor page: Hackathon Mentors
- LinkedIn: Léo Arsenin
- Role: Solutions engineer at Cloudfare
Matthieu Dinot
- Mentor page: Hackathon Mentors
- LinkedIn: Matthieu Dinot
- Role: AI Scientist at Mistral
Preetham Kaukuntla
- Mentor page: Hackathon Mentors
- LinkedIn: Preetham Kaukuntla
- Role: Staff Data Scientist at Glassdoor
Mentors Message Board
- Mentors Message Board

👥 Teams

Darkwood
- Status: 1st Place
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_qFVxlREukLQ
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_qFVxlREukLQ
- Demo video: YouTube
- Members:
- Mathieu Ledru
- Mirza Marotsaha
- Victor-eliejah GARNIER
bluebull
- Status: Best Startup
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_-p8xvdGl-oA
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_-p8xvdGl-oA
- Members:
- Vasiliki Doropoulou
Muon
- Status: 10x Data Scientist
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_ub4tDzlrft0
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_ub4tDzlrft0
- Members:
- Imane Momayiz
Polaris
- Status: Finalist
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_y4_Yz6P5BZE
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_y4_Yz6P5BZE
- Members:
- Hippolyte Dupont
- Ghaith ABDESSALEM
- Jacques Dumora
Training Expert
- Status: Finalist
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_njEtwEBAmUE
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_njEtwEBAmUE
- Members:
- Eva Useros Marugan
- Paul-Louis Fouesnant
CodeMind
- Status: Submitted
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_wRj-nEG24zE
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_wRj-nEG24zE
- Members:
- Amelie Smith
- Damien Frechou
- Anis Kaci
- Choutri Adel Djalil
Coffe is life
- Status: Submitted
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_RFBTGYYwbm4
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_RFBTGYYwbm4
- Members:
- Pierre Lepagnol
- Filipp Trigub
PiLLM
- Status: Submitted
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_Gc4SneBV2D4
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_Gc4SneBV2D4
- Members:
- Din Sokheng
- Ahmed Abdelaziz Mokeddem

🔗 Useful Links

🏠 Home: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk
👥 Teams: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/teams
📩 Message Center: https://paris.aitinkerers.org/message_center?board_key=meetup_mu_eZJ5tCXlA2A
🏆 Submissions: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/entries
📊 Results: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/results

🧱 Technical Stack

The architecture is intentionally simple, but constrained by real-world conditions:

Python for execution
Polars as a search engine
Quinn 2.5 as a generation model
FastAPI for the interface
Local sandbox (CPU) with memory constraints

The core of the system is an API that transforms a natural request into directly executable Polars code.

🔄 Execution Pipeline

The benchmark requires a complete chain, without shortcuts:

User Query (NL)
    ↓
Prompt enrichi (schema + règles)
    ↓
LLM
    ↓
Code Polars généré
    ↓
Exécution réelle
    ↓
Validation
    ↓
Scoring

👉 The model is not evaluated on what it "says", but on what its code actually produces.

🧠 Generation Strategy

The key choice is simple:

❌ train the model
✅ to constrain one's behavior

Rather than heavy-handed fine-tuning, the system is based on:

a structured prompt
a dataset of targeted examples

Required Format

System:
- règles Polars
- contraintes strictes

User:
- schéma
- requête

Assistant:
- code uniquement

👉 The model learns an execution pattern, not general knowledge.

🗂️ Dataset

The dataset is not massive, it is intentional:

15 to 500 examples
focused on critical patterns

Cutlery:

selection
filters
aggregations
joins
window functions
nulls
edge cases

👉 Coverage is more important than volume.

📊 Schema injection

The model doesn't guess anything.
The scheme is injected systematically:

{
  "columns": ["card_name", "mana_cost", "frequency"]
}

Direct effects:

fewer hallucinations
Valid queries on the first try
strong dependence on the provided context

👉 Without a diagram, the system collapses.

⚡ Inference Constraints

~6GB model
CPU only
high latency

Consequence:

Every call counts
Re-sorting is expensive
The prompt must be precise from the outset

👉 The cost of error is included in the score.

🧪 Validation & scoring

The benchmark validates a complete behavior, not a raw output.

Levels

Valid code
Successful execution
Correct result
Acceptable performance

Score

Score = N / (T * VRAM^0.1 * RAM^0.01)

👉 We measure a constrained system, not an abstract model.

🔁 Architectural choices

Three options:

fine-tuning → too heavy
multi-models → too complex
prompt + dataset → chosen

👉 Decision: encode the behavior in the data

🧩 Implementation

The API exposes a simple stream:

input:
- request
- metadata
output:
- Polars code

The service:

builds the prompt
calls the model
returns the code

👉 Voluntary simplicity: the real difficulty lies elsewhere.

📦 Positioning

The project is not presented as an LLM wrapper, but as:

a secure analytical copilot for tabular data

With :

guided prompts
structured context
execution verified

👉 The product is defined by its constraints, not by the model.

🧭 System reading

This benchmark shows one thing:

The performance of a small model is a property of the system, not of the model alone.

The real levers:

structure of the prompt
dataset
Context injection
runtime validation

👉 We're going from an ML problem to an engineering problem.

🧱 Components

Harness

abstraction of models
standardization of inputs/outputs

Executor

isolated execution
error capture
runtime metrics

Scoring

validity
performance
stability

📊 What is measured

Execution → Is it running?
Correction → Is this correct?
Polars Quality → correct use of the motor
Performance → actual cost

🔍 Real-life case

Input:

"Find the top 10 most frequent cards with mana cost ≤ 3"

Expected :

filter correct
correct aggregation
sorting + limit

Observed:

valid but incorrect code
Python fallback
silent errors

👉 The benchmark reveals the gap between generation and execution.

⚠️ Real stakes

An LLM generates plausible code, not reliable code

So, in production:

sandbox required
systematic validation
controlled retrievals
monitoring

👉 Without this, the system is unstable by default.

🧠 Project Contribution

This benchmark introduces:

an end-to-end executable pipeline
a multi-criteria assessment
a reproducible approach
a production-friendly environment

Rest :

ai-harness → orchestration
polars-bench → evaluation

👉 This is no longer a model test, it's a complete system test.

📹 Demo

Submission video:

📦 Hackathon Deliverables

Full benchmark code
Test set
Reproducible pipeline
Comparative results

Example of a provided structure:

submission_example
main benchmark code
datasets
logs

🧭 Conclusion

This hackathon is not intended to demonstrate that LLMs work.

It shows where they break.

And most importantly:

A useful benchmark does not measure generation.
It measures performance.

🔮 Darkwood Perspective

This type of benchmark fits directly into a broader vision:

orchestration of AI pipelines
systematic validation
generation/execution separation
observability

👉 This is not a demo tool.
It's a building block for constructing reliable systems.

🚀 Sundays Lab #3 - When AI becomes a collective playground

Mathieu Ledru — Mon, 20 Apr 2026 12:15:35 +0000

On Sunday, April 19, 2026, at Hexa (eFounders) in Paris, a new edition of Sundays Lab was held.
A seemingly simple format: coworking, AI workshop, exchange session.

But in practice:
👉 a concrete demonstration of what the builder ecosystem will become in 2026.

⚙️ A paradigm shift: from conference to interactive system

The first strong signal of the event is not technical.

This is the format.

We are no longer sure:

top-down talks
“Inspiring” speakers

We are on:

a real-time construction
an ongoing interaction**
a system where the audience becomes a co-creator

“We didn’t want a traditional workshop. We wanted everyone to participate.”

Here's a section ready to integrate into your Darkwood article 👇

🧑‍🚀 Speakers & Participants - Projects and Weak Signals

👤 Pato - AI & Automated Go-To-Market

As the founder of Cluently, he embodies the “builder + sales” profile.
His presentation shows how AI can replace entire business functions (prospecting, matching, CRM).

👉 Project presented:

AI agent for automated prospecting
Intelligent matching between profiles / opportunities
Build Society community app generated live

👉 Key signal:

The future of SaaS = agent + distribution, not just product

👤 Jules - Growth & Creative AI

Founder of Loops, focused on performance marketing.

👉 Project:

SaaS for generating high-performing ads
Focus on creativity as the main driver of growth

👉 Insight:

Growth no longer comes from targeting
but large-scale content creation via AI

👤 Tom - Personal branding & distribution

Content creator (philosophy + tech), rapid growth on Instagram.

👉 Positioning:

Build an audience before a product
Transforming complex ideas into viral content

👉 Insight:

Distribution is becoming a stronger asset than tech.

👤 Lucas Lefner - Startup advisory & network

Provides support to early-stage startups (strategy, sales, equity).

👉 Model:

support in exchange for equity or mission
creation of a business club (Startup Hunters)

👉 Key insight:

“90% of business is networking”

👉 Signal:

return of network-driven business
Importance of private circles / clubs

👤 Enzo - Iomaris

Real estate startup (beta phase).

👉 Product:

Platform for managing a real estate project from start to finish
Profitability analysis, taxation, market
collaboration between individuals and professionals

👉 Business model:

Free for individuals
Monetization via professionals (leads)

👉 Insight:

extreme simplification of a complex domain via AI
trend “vertically integrated business assistant”

👤 Eli - Gamified Education App

Student (HEC), project focused on academic productivity.

👉 Product:

collaborative work app
Strava-type logic applied to the study
comparison between students / classes

👉 Insight:

gamification + social = strong engagement lever
“public progress tracking” logic

👤 Romain - Automated Pentest with AI

Profile not an expert in cybersecurity.

👉 Product:

Automated penetration testing service via AI
Use of scripts + LLM to detect vulnerabilities

👉 Model:

one-off service (audit)
no ongoing maintenance

👉 Key insight:

AI makes it possible to create expert services without initial expertise.

👉 Signal:

explosion of AI-augmented agencies

👤 Laurent (Startup Hunters) - Ecosystem & Support

Supports startups and young entrepreneurs.

👉 Activity:

business structuring
Connecting investors and founders

👉 Insight:

Lack of operational support for early founders
growing need for on-the-ground guidance

👤 GEO Project (AI Search Optimization)

E-commerce consultant / Advanced SEO.

👉 Product:

optimization tool to appear in LLM responses
alternative to traditional SEO

👉 Function:

analysis of the sources used by AI
Content optimization + ecosystem

👉 Key insight:

AI traffic will surpass traditional SEO

👤 Social Matching Project (anonymous)

Next generation social network concept.

👉 Product:

Weekly matching based on deep interests
No profile, no swipe
authentic interaction

👉 Insight:

reaction to the saturation of social networks
back to qualitative interactions

🧭 Overall reading

These profiles show a clear convergence:

1. All projects use AI

But at different levels:

Automation (sales, penetration testing)
product (ads, real estate)
distribution (content, GEO)

2. The technical barrier disappears

➡️ Everyone can build
➡️ so the difference lies elsewhere

3. The real weapons become:

network
distribution
branding
niche

In concrete terms:

an app generated live
decisions made via vote
a product built in front of the audience

👉 The event itself becomes a product prototype.

🤖 AI is no longer a tool, it's a production interface

The workshop highlighted a key point:

👉 Software creation is now iterative, public, and assisted.

A concrete example observed:

app scenario generation
code generation with LLM (Claude)
Automatic error correction
near-immediate deployment (Cloudflare)

“Claude generates the code, corrects his errors, and we build the app as we go.”

What it actually changes

Before :

design → dev → test → deploy

NOW :

intention → generation → feedback → correction

👉 The cycle becomes continuous and conversational.

🧠 The real issue: distribution > technology

One point came up several times during the exchange session:

👉 Technology is no longer the barrier to entry.

What remains difficult:

find customers
distribute a product
create an audience

“Code is becoming commoditized. The real barrier is distribution.”

Direct consequence

We observe a shift:

Before	Now
Build a product	Build an audience
Optimize tech	Optimize acquisition
Be a developer	Be a full operator

📈 Acquisition: Organized Chaos

The discussions highlighted a reality:

👉 There is no longer a single dominant channel.

Canals mentioned

LinkedIn (B2B, decision-makers)
Instagram (creation + virality)
Twitter/X (monitoring + opportunities)
Email (still extremely effective)

Key Insight

👉 Efficiency comes from:

repetition
multi-channel presence
the transformation of content into multiple formats

“A video → shorts → reels → LinkedIn post → newsletter”

🧩 The emergence of “hybrid builders”

One profile keeps recurring:

👉 people not technically expert
→ capable of creating products using AI

A striking example:

creation of an automated penetration testing service
without advanced cybersecurity expertise
based on tool orchestration + LLM

“I don’t have strong technical skills, but it works.”

🧠 The underlying problem: cognitive overload

Everyone shares the same feeling:

👉 AI is going too fast

Symptoms :

permanent FOMO
too many tools
too many new things

Observed response:

👉 Return to:

Task structuring (SOP)
simplification
focus

“Write down your tasks one by one, then see what AI can optimize.”

🧬 AI amplifies… but does not replace

A central question was raised:

👉 Will AI kill products?

Overall response from the group:

❌ No
✅ It filters

What disappears

low-quality products
SaaS without distribution
worthless clones

What remains

branding
network
human relationship

“AI amplifies both the good and the bad.”

🌐 Towards a new layer: GEO (AI Search)

An advanced topic has emerged:

👉 GEO (Generative Engine Optimization)

Objective :

appear in LLM responses (ChatGPT, etc.)
not just in Google

Figures mentioned:

18x growth in AI traffic
4x conversion on this traffic

“Users coming from ChatGPT convert 4x more.”

👉 This is probably the equivalent of SEO… AI version.

🤝 The heart of the model: connecting people

The product built during the event is revealing:

👉 a matching app for participants

Aim :

Connect problems ↔ solutions
create real synergies

“Matching problems with solutions.”

🧭 Darkwood Reading

This meetup confirms several major trends:

1. The technical stack becomes secondary

Symfony, Node, etc. → important
But more differentiating on its own

2. Orchestration becomes key

What you do with Flow → totally aligned

👉 Connect:

data
agents
workflows

3. The product = system + distribution

Not just code

4. The future is hybrid

AI → execution
human → direction

⚡ Conclusion

Sundays Lab #3 is not a meetup.
This is a prototype of what the tech ecosystem is becoming.

👉 A space where:

on build live
we learn by doing
we connect in real time

And most importantly:

👉 where the real skill is no longer coding
but to transform an intention into a functional system.

⚙️ Message-oriented vs. Data-oriented orchestration - from data to knowledge

Mathieu Ledru — Fri, 17 Apr 2026 15:37:26 +0000

For intellectual property reasons, the subject chosen for the application of this article will not be the one discussed, although it is closely related. For any further information, please contact Omer who will be happy to answer, and apologize for any potential inconvenience.

In this article, we explore two fundamental approaches to software orchestration:

Message-Oriented Orchestration: via Symfony Messenger synchronous respectively asynchronous
Data-Oriented Orchestration: via Navi for synchronous and Flow for asynchronous

The case study is based on a classic but structuring problem: text mining applied to a set of Git repositories.

For the practical demonstration, I will take the EIT tutorial from 2007/2008 carried out at the time on classification with Matthieu Beyou during computer science class tutorials.

For the data, we use those of Omer (former work colleague) available on his site https://git.arkalo.ovh (via the api).

The goal is not to produce the best machine learning model, but to understand how the form of orchestration influences the complexity, readability, and scalability of the system.

The problem: transforming repositories into usable knowledge

The dataset consists of a list of Git repositories defined in a repos.json file, the data of the directories listed on https://git.arkalo.ovh/explore/repos.

For your information, you can extract the information using the Composio connector for https://composio.dev/toolkits/gitea. Refer to my previous article for the implementation: https://blog.darkwood.com/fr/article/relacher-les-connecteurs-des-outils-au-langage.

Each deposit becomes a canonical document constructed from:

repository name
description
README
metadata (owner, topics…)

This document is then transformed via a classic text mining pipeline:

Pretreatment (cleaning, tokenization)
Feature Extraction
TF-IDF Weighting
Similarity between documents
Classification / clustering

This pipeline is directly inspired by historical approaches:

TF-IDF: weight = tf * log(N / df)
Cosine similarity between documents
Supervised Naive Bayes Classification
Unsupervised k-means clustering

What interests us here is not the algorithm, but the way to orchestrate it.

Note that if you are fond of documentation, you can refer to the Resources section at the bottom of the article which lists a number of topics concerning data mining applied in computer science.

Business pipeline (independent of orchestration)

First and foremost, the core business needs to be isolated.

Repository → Document → Tokens → Features → TF-IDF → Similarity → Results

This pipeline represents a data transformation.

Each step:

takes a piece of data
produces new data
without strong dependence on an external context

This is precisely where the two approaches diverge.

Approach 1 Message-Oriented - Orchestration via Symfony Messenger

In the Message-Oriented implementation, the pipeline is not expressed as a continuous data transformation.

It is encapsulated in a message, then executed via the Symfony bus.

Execution Model

Command → Message Bus → Handler → PipelineService → Stages

In concrete terms:

a CLI command triggers the execution
A message is sent
a handler takes care of the execution
the core business remains centralized in a shared service

RunMessengerPipelineMessage
→ RunMessengerPipelineHandler
→ PipelineService

Separation of responsibilities

This implementation adheres to a key project constraint:

The core business is strictly shared between the two approaches

So :

Messenger contains no business logic
he only orchestrates the execution

Actual Pipeline Executed

The handler triggers a deterministic pipeline:

1. ingest
2. preprocess
3. feature build
4. classification
5. clustering

Each step is executed in a common application service (PipelineService).

Concepts introduced by Messenger

The orchestration explicitly introduces:

a message class
a dedicated handler
a dependence on the bus
a dispatch layer

Command → Message → Handler → Service

These elements are specific to Messenger and do not exist in the data-oriented model

Observability and debugging

Messenger offers a natural debugging model:

message inspection
middleware
bus logging
Extensibility towards async / queue

Debug = niveau message + middleware

Nature of the overhead

In this MVP, the overhead is conceptually measurable:

introduction of an artificial message
Indirection via handler
the need to structure the execution around the bus

But this overhead is located in the orchestration adapter, not in the hardware.

Summary

This approach transforms the pipeline into:

a distributed work unit

She favors:

Symfony standardization
extensibility towards async
integration with the ecosystem

At the cost of an additional layer of indirection.

Conceptual Example

final class ComputeTfIdfMessage
{
    public function __construct(public DocumentId $id) {}
}

final class ComputeTfIdfHandler
{
    public function __invoke(ComputeTfIdfMessage $message)
    {
        $document = $this->repository->get($message->id);
        $vector = $this->tfidf->compute($document);

        $this->bus->dispatch(new ComputeSimilarityMessage($vector));
    }
}

Benefits

strong decoupling
resilience (retry, queue)
native parallelization
Symfony standard

Structural Limitations

The problem quickly becomes apparent:

➡️ the message becomes an artificial envelope

We manipulate:

IDs
persistent states
indirect transitions

The problem is simply:

data → transformation → data

This introduces:

the boilerplate
implicit dependencies
a loss of overall readability

Approach 2 Data-Oriented - Orchestration via Navi (synchronous) and Flow (asynchronous)

In the Data-Oriented implementation, the pipeline is expressed as an ordered sequence of actions applied to a context.

There is no message.

There is no dispatch.

There is only:

a piece of data
a context
a sequential transformation

Execution Model

Command → WorkflowRunner → Actions → PipelineService → Data

In concrete terms:

a command triggers a workflow
The WorkflowRunner executes a list of actions
each action transforms a Context
The business services are identical to Messenger

WorkflowRunner
→ PipelineStageAction[]
→ Context
→ PipelineService

Pipeline Structure

The pipeline is explicitly defined as a sequence:

[IngestAction,
 PreprocessAction,
 FeatureBuildAction,
 ClassificationAction,
 ClusteringAction]

Each action:

takes a Context
applies a transformation
returns a new Context

Nature of the Context

The Context becomes the central object:

it contains the pipeline status
it evolves at each stage
it is inspectable

Context₀ → Context₁ → Context₂ → ... → Contextₙ

Concepts introduced by Flow

This approach introduces:

explicit actions
a runner
an evolving context

Data → Action → Data

Unlike Messenger:

no message
no handler
no bus

Observability and debugging

The debugging process changes completely in nature:

Debug = suite d’actions + snapshots de contexte

Benefits :

visible execution order
inspectable intermediate state
deterministic pipeline

Nature of readability

The pipeline can be directly read as a stream:

ingest → preprocess → features → classification → clustering

Without structural transformation.

Structural Overhead

The cost introduced is different:

need for a Context
abstraction via actions

But :

no envelope
no bus detours
no break in the data flow

Summary

This approach transforms the pipeline into:

a series of data transformations

She favors:

immediate readability
direct transformation of data
absence of envelope
deterministic pipeline
ease of testing

Boundaries

less suitable for complex distributed systems
requires strict discipline regarding the purity of the transformations
Tooling less standard than Messenger

Direct Comparison

Criteria	Message-Oriented	Data-Oriented
Mental model	Events / Messages	Data streams
Readability	fragmented	linear
Overhead	high (messages, handlers)	low
Scalability	excellent	depends on the design
Debug	indirect	direct
Business coupling	weak but diffuse	strong but explicit

Appearance	Messenger	NaviFlow
Central unit	Message	Context
Orchestration	Bus + Handler	Runner + Actions
Flow	indirect	direct
Debug	message-centric	data-centric
Overhead	message + handler	action + context
Pipeline	encapsulated	explicit

Key point: the illusion of complexity

In the case of text mining, each step is:

pure
determinist
functional

Examples:

TF-IDF → simple mathematical formula
Similarity cosine → normalized dot product

There is no natural need for messages.

The introduction of Messenger is therefore an architectural decision, not a business necessity.

Main Insight

Message-oriented transforms data into events.

Data-oriented technology transforms data into data.**

In a system like this:

Message-Oriented adds a layer
Data-Oriented reveals the model

Implications for Symfony

Symfony is evolving towards:

async
workers
sidekicks (FrankenPHP)
distributed orchestration

But this raises a fundamental question:

👉 Does everything have to be orchestrated via messages?

The answer depends on the problem.

When to use each approach

Message-Oriented

distributed workflows
long tasks
resilient systems
industry events

Data-Oriented

analytical pipelines
data transformations
deterministic systems
intensive calculations

Source code

The project's source code is free and can be viewed here: https://github.com/matyo91/omer-quotes

Conclusion

This project demonstrates one simple thing:

👉 Orchestration is not neutral

Two functionally identical implementations can produce:

radically different systems
opposing cognitive costs
divergent evolutionary capacities

In the case of text mining:

Message-Oriented makes things more complex
Data-Oriented clarifie

Symfony Messenger orchestrates a pipeline as a unit of work.

Darkwood Flow orchestrates a pipeline as a data transformation.

The next step in the project is to:

extend the pipeline (clustering, classification)
to integrate more advanced models
expose an API
compare actual performance

But most importantly:

👉 continue to question the form of the orchestration.

Resources

Thank you for writing the article

Omer's git repository for data and inspiration: https://git.arkalo.ovh
Leverage Messenger to Improve Your Architecture - Tugdual Saunier for the article outline: https://speakerdeck.com/tucksaun/tirez-profit-de-messenger-pour-ameliorer-votre-architecture
Polytech Paris Sud (formerly IFIPS) 2008: Information Extraction from Texts Project - Document Classification by François Yvon and Alexandre Allauzen, carried out as a tutorial during the 2007/2008 academic year using the Perl language with Matthieu Beyou https://www.linkedin.com/in/matthieu-beyou-9a425a32/

Examples from friends on EIT topics and mathematical models applied to AI

Claude just changed sales calls forever! (free skill) - Alexandra Spalato | AI Automation: https://www.youtube.com/watch?v=FuVIGGWwYKY
Demystifying AI: A practical guide for PHP developers - Iana IATSUN - PHP Forum 2024: https://www.youtube.com/watch?v=u-yrK_-\_p9g
Embeddings in PHP: Symfony AI in practice: https://speakerdeck.com/lyrixx/embeddings-symfony-ai-en-pratique
Stack Overflow tags - automatic prediction using machine learning algorithms - Marco Berta: https://www.youtube.com/watch?v=fFKXFDDjEJU Help! I'm being asked to use AI! - Drupal Camp Grenoble 2026 - Alexandre Balmes: https://speakerdeck.com/pocky/au-secours-on-me-demande-dutiliser-de-lia-drupal-camp-grenoble-2026
DeepMind's New AI Just Changed Science Forever - Two Minute Papers: https://www.youtube.com/watch?v=Io_GqmbNBbY
Langflow Models Are Smart. Data Is Everything. Building Context-Rich AI Systems with Unstructured: https://www.youtube.com/watch?v=fNLUv6Pvc6w
I am a legend: hacking hearthstone with machine learning - Elie Bursztein, Celine Bursztein: https://elie.net/talk/i-am-a-legend Tell me something about myself that I don't yet know by Nathalie | A Voice That Carries: https://x.com/Bonzai_Star/status/2031432381471797589

The Future of AI as Seen by Yann LeCun

Nobody realizes what Yann LeCun has just created - Grand Angle Nova: https://www.youtube.com/watch?v=P-wAr687qxg
For those who are curious: Inaugural lecture by Yann LeCun - Deep Learning and Beyond: The New Challenges of AI - École nationale des ponts et chaussées: https://www.youtube.com/watch?v=Z208NMP7_-0
What is knowledge made of? From Arthur Sarrazin https://www.linkedin.com/in/arthursarazin in https://srzarthur.substack.com/p/what-is-knowledge-made-of

🤩 Unleach connectors - From Tools to Language

Mathieu Ledru — Tue, 14 Apr 2026 07:17:40 +0000

Introduction

Automation has reached a paradox.

We have never had so many tools:

connectors
workflows
orchestration engines
AI agents

Yet, something fundamental is still missing.

We don’t have a language.

This article revisits a previous experiment around Composio and MCP, and introduces a new direction:

Automation should not be a workflow. It should be a language.

Revisiting the First Approach

A year ago, an implementation was proposed to automate Gmail and Google Calendar using PHP agents, MCP, and Composio.

The system relied on:

tool exposure via MCP
connector orchestration
agent-driven execution

While functional, this approach had structural limitations:

tight coupling to specific providers (Composio)
workflow-centric design
lack of composability
no abstraction of intent

This led to the archival of the original project:
→ composio-mcp

The problem was not the tools.

The problem was the model.

The Limits of Connectors

Modern automation platforms provide access to hundreds of integrations:

Composio
Symfony Mate
Kestra
n8n

Each exposes capabilities:

send email
fetch data
trigger workflows
call APIs

However, these systems share a common limitation:

They define how to connect, not how to compute.

They operate as:

pipelines
graphs
sequences

But not as a formal system.

Back to First Principles

To redefine automation, we revisit two foundational models:

Church - The Language

Lambda calculus defines computation as:

function abstraction
function application

Example:

λx.x + 1
(λx.x + 1)(5) = 6

Key properties:

functions are first-class
no mutable state
computation = evaluation

Turing - The Execution

The Turing machine defines:

how computation is executed
how state evolves
how instructions are processed

Equivalence

The Church–Turing thesis states:

Any computation expressed as a Turing machine can be expressed in lambda calculus.

A New Model for Automation

Applying this equivalence:

Concept	Role
Lambda	Language (intent)
Flow	Execution (runtime)
Connectors	External primitives

This leads to a new architecture:

Intent → Lambda → Execution → Connector

Connect Flow

A new system, connect-flow, implements this model.

It introduces three core domains:

1. LambdaCapability

Represents:

a computation
a composable expression
a formal structure

Example:

λfetchemails.λuserId.fetchemails(userId)

2. Execution (Flow)

Execution is delegated to:

an orchestration engine
supporting async and parallel computation

Flow acts as the Turing machine of the system.

3. LanguageCapability

A higher-level abstraction:

transforms natural language into lambda expressions
uses a local LLM (Ollama + Mistral)
preserves privacy (RGPD-compliant)

From Tools to Primitives

In this model:

Composio
Symfony Mate
n8n
Kestra

are no longer central systems.

They become:

execution backends

Each tool becomes a primitive callable within lambda.

Practical Example

Lambda Execution

bin/console connect-flow:lambda:run \
"λfetchemails.λuserId.fetchemails(userId)" \
--args "[5]"

This defines:

a function taking fetchemails
then userId
applying fetchemails(userId)

Natural Language → Lambda

bin/console -vvv connect-flow:language:to-lambda \
"fetch emails you have the tool 'fetchemails'"

Produces:

λfetchemails.fetchemails()

Why This Matters

Traditional automation:

Workflow → Tools → Execution

This model:

Intent → Lambda → Flow → Connector

Key Differences

Traditional	Lambda-based
Static workflows	Dynamic composition
Tool-driven	Language-driven
Provider-dependent	Provider-agnostic
Hard to scale	Composable

Extending the Language

Future iterations will introduce:

data mappers
conditional logic
loops
HTTP primitives
process execution

Example:

compose(
  fetch_emails,
  filter_important,
  map(summary),
  send_email
)

Relationship with Functional Programming

This approach builds upon:

lambda calculus
combinatory logic
functional composition

As previously explored in:

→ Lambda interpreter in PHP
→ Y combinator implementations
→ Flow execution model

Toward a Universal Execution Layer

This architecture suggests a new category of systems:

Capability Composition Engines

Where:

connectors are interchangeable
execution is abstracted
intent is formalized

Projet sources

You can find sources of the project here : https://github.com/matyo91/connect-flow

Conclusion

Automation has evolved from scripts to workflows.

The next step is clear:

From workflows to language.

By combining:

Lambda (Church)
Flow (Turing)
Connectors (primitives)

we obtain a system that is:

composable
extensible
formally grounded

Final Thought

Automation is not a sequence of steps.
It is a computation.

And computation deserves a language.

Resources

💡 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