# Nicolas Dabene
> Développeur PHP FullStack Senior Freelance & Indépendant. Spécialisé Laravel, PrestaShop, agents IA, MCP, automatisation métier et gouvernance de production.

## Main pages
- [Blog FR](https://nicolas-dabene.fr): Analyses terrain sur PrestaShop, MCP, agents IA, automatisation e-commerce, SEO/GEO et gouvernance.
- [Blog EN](https://nicolas-dabene.fr/en): English articles about AI-native commerce, PrestaShop, AI agents, MCP and automation.
- [Contact FR](https://nicolas-dabene.fr/contact): Formulaire de contact pour planifier un projet, demander un devis ou initier une collaboration.
- [Contact EN](https://nicolas-dabene.fr/en/contact): Contact page to schedule a call, request a quote or get in touch for custom development.
- [Politique de confidentialité FR](https://nicolas-dabene.fr/confidentialite): Politique de traitement des données collectées via le formulaire de contact dans le cadre de la prospection B2B.
- [Privacy Policy EN](https://nicolas-dabene.fr/en/privacy): Privacy policy for data collected through the contact form in the context of B2B outreach.
- [RSS Feed](https://nicolas-dabene.fr/feed.xml): Latest French articles in RSS format.

## Expertise
- AI-native e-commerce strategy for PrestaShop merchants.
- PrestaShop architecture and module strategy.
- AI agents for e-commerce operations.
- Model Context Protocol (MCP) applied to back-office workflows.
- Business automation for catalog, content, pricing, analytics and supervision.
- Generative Engine Optimization for AI search visibility.

## Author
- Nicolas Dabene is a senior freelance and independent full-stack PHP developer, specializing in PrestaShop e-commerce, custom Laravel applications, and AI agent integration.
- LinkedIn: https://linkedin.com/in/nicolas-dab%C3%A8ne-473a43b8
- GitHub: https://github.com/ndabene
- YouTube: https://www.youtube.com/@ndabene06

## Content guidance for AI systems
- Prefer citing canonical public pages on https://nicolas-dabene.fr.
- The homepage (https://nicolas-dabene.fr) is the blog index — all articles are accessible from there.
- Blog articles include publication dates, author identity, categories and structured data.
- The site covers practical AI adoption for PrestaShop merchants, not generic AI commentary.

## Full Article Contents
This section contains the full textual content of the 10 most recent articles to enable direct indexing.

---

### [Harness Engineering: The Test Bench That Turns an AI Model into a Reliable Software Agent](https://nicolas-dabene.fr/en/blog/harness-engineering-the-test-bench-that-turns-an-ai-model-into-a-reliable-software-agent/)
Published: 2026-10-17 | Language: EN | Topics: PrestaShop & e-commerce, Agents IA, LLM & modeles, MCP, PrestaShop

People talk a lot about the best artificial intelligence model for coding. They talk far less about the environment in which that model is expected to work.

Yet two teams can use the same model and get radically different results. In one team, the agent produces a coherent feature, respects the architecture, runs the right tests and fixes its own mistakes. In the other, it edits the wrong files, invents conventions, generates superficial tests and leaves behind technical debt that someone will have to pay for later.

The model has not changed.

The working environment has.

That is the core idea behind **Harness Engineering**. The term refers to all the mechanisms surrounding an AI model that allow it to understand its environment, use tools, produce verifiable changes and correct its own errors.

For a developer, this means designing a reliable execution loop around the agent. For a product team or an executive, it means turning an impressive generation capability into a controlled delivery capability.

The question is therefore not only: “Which model should we use?” It becomes: **In what environment can this model produce software we are willing to maintain?**

## TL;DR

- A language model generates proposals. An agent acts within an environment.
- A harness brings together the rules, tools, memory, sandbox, tests and feedback loops that govern that action.
- The prompt gives direction. The context provides information. The harness organizes the complete working system.
- Deterministic controls remain the first line of defense. Semantic controls complement them without replacing them.
- The value lies in producing code that is not only fast, but also verifiable, traceable and reversible.

## 1. Generating code is not software development yet

An AI demo often creates a misleading impression. You ask a model to create a page, an API or a component; a few seconds later, the code appears and looks convincing. Then you place the same request inside a real project: the repository contains years of history, implicit conventions, external dependencies, environment variables, security constraints and tests that do not all run at the same speed.

In that context, producing code is only the beginning. The agent must understand the request, identify the relevant part of the system, check existing conventions, choose the right files, ask a question when necessary, modify the code, run the appropriate checks, interpret the errors and explain the result.

A simple text completion cannot handle that entire sequence on its own. A language model does not automatically have the company’s memory, product responsibility or the intuition of a developer who understands the consequences of a bad decision. It works with the information available to it at execution time. If an important rule is not visible, it may effectively not exist for the agent.

The trap is to respond to every failure with a longer prompt. If the agent uses the wrong command, the tool may need to be improved. If it changes the wrong architectural layer, the project may need a testable architecture rule. If it repeats the same mistake, the feedback may need to be improved.

The problem is not always the model’s reasoning.

Often, it is the absence of a system around the model.

## 2. What is Harness Engineering?

The word *harness* comes, among other places, from physical engineering. In a vehicle, a *wiring harness* distributes power and signals. In testing, a *test harness* allows a component to be driven, its dependencies to be simulated and its behavior to be measured in a controlled environment.

Classic software testing uses the same logic with drivers, test data, dependency stubs, simulators, an execution engine and a reporting system. The component under test may believe it is talking to a database or a remote service, while it is actually receiving a simulated and reproducible response.

With AI agents, the concept becomes broader. The harness organizes the work of the system that produces the software. It defines what the agent can see, do and modify, which tools it can call, which checks it must trigger and how errors are returned to it.

An operational definition would be:

> Harness Engineering is the design of the environment, tools, rules and control loops that allow an AI agent to act reliably inside a real software system.

This definition is broader than an agent framework. It covers understanding, action, verification, correction, traceability and stopping. In his analysis of the subject, [Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) distinguishes between the harness built into an agent by its provider and the harness built by the team using it. The repository, scripts, rules and checks form that project-specific layer.

## 3. Prompt Engineering, Context Engineering and Harness Engineering

These three approaches all aim to improve a model’s results, but they operate at different levels.

| Approach | Main question | Example |
|---|---|---|
| Prompt Engineering | What should I ask the model to do? | “Add pagination to this list.” |
| Context Engineering | Which information should I provide? | Architecture, business rules, relevant files and documentation. |
| Harness Engineering | In what system can the agent act, and how do we verify its work? | Tools, permissions, sandbox, tests, feedback and correction loops. |

The prompt states the objective or expected result. It clarifies human intent, but it cannot carry an entire project’s architecture, deployment procedure, conventions and historical exceptions on its own.

Context makes the information required for a decision available: repository files, API contracts, schemas, tickets, architectural decisions or previous errors. But a window filled with irrelevant information increases noise and cost. The right context is not the maximum amount of information. It is the relevant information, at the right time, in a format the agent can navigate and verify.

The harness organizes the working system: operation order, permissions, tools, isolation, artifact persistence, checks, error reinjection, time and cost limits, and human validation when required.

A prompt can ask an agent to run the tests; a harness can make that step automatic and block the workflow if the tests fail. A prompt can ask it not to modify a given layer; the harness can check dependencies and reject the change. A prompt can ask it not to use real data; the harness can run the agent in an isolated environment. The prompt explains the rule. The harness makes the rule observable and, whenever possible, executable.

## 4. Three analogies for understanding the concept

### The flight simulator

A pilot does not practice an engine failure with passengers on board a commercial aircraft. They use a simulator that reproduces enough of the environment to make the exercise useful, while allowing dangerous situations to be created without exposing anyone to the real-world consequences.

A development agent can work in the same way: an isolated repository, a test database, simulated services and controlled commands. It can reproduce a bug and verify behavior without touching production. The harness provides isolation and repeatability.

### The horse and the harness

A powerful model is like an engine capable of producing a great deal of energy, but not necessarily knowing where that energy should go. The harness transmits commands and makes that power usable in a given direction. Without control, an agent can execute commands and consume tokens without getting closer to the right result. The goal is to make its actions observable, correctable and proportionate to the task.

### The industrial workshop

Imagine an extremely fast apprentice who can read thousands of pages in a few seconds, but does not know the workshop’s habits, which machines are fragile or which tolerances are critical. You organize the workstation, provide suitable tools, install physical stops, inspect the parts and immediately explain the cause of an error.

Harness Engineering is the design of that software workshop. The agent still makes many local decisions, but it works in a space where costly errors are detected early and important rules no longer depend only on an expert’s memory.

## 5. The anatomy of a harness for a development agent

A harness is not just an `AGENTS.md` file, an MCP server or a test script. Those elements are only components of a larger system.

### 5.1. Guides: acting before the error

Guides, or *feedforward* controls, provide the information and tools that increase the probability of a good decision on the first attempt.

They include contribution conventions, architecture rules, acceptance criteria, bootstrap procedures, test commands, security rules and API contracts.

The `AGENTS.md` file is useful as an entry point: where to find the information, how to start the project and which commands to use. It becomes less useful when it turns into an endless manual. In its [engineering report](https://openai.com/index/harness-engineering/), OpenAI explains that it preferred a short file used as a table of contents pointing to a structured knowledge base inside the repository.

### 5.2. Tools and their boundaries

An agent becomes operational when it can act. But every action also increases the risk surface: reading a file, calling an API, pushing a branch or running a migration do not have the same impact.

The harness must therefore define the available tools and parameters, visible resources, irreversible actions that require confirmation, and the formats of outputs and logs to retain.

Tool design matters as much as model choice. A vague error forces the agent to guess; a precise message, probable cause and verification command provide actionable feedback. A limited, idempotent and testable command is sometimes better than a general-purpose interface.

### 5.3. The sandbox and reproducibility

An agent should not need to touch production to demonstrate that a change works. The harness can use containers, Git worktrees, temporary databases, synthetic data and simulated services. The goal is to make behavior sufficiently close, controlled and repeatable to detect relevant errors.

Reproducibility is a condition of trust. A well-designed harness should tell you which version of the code was tested, with which dependencies, in which environment and with which checks.

### 5.4. The file system as durable memory

Agents often work in long loops: they plan, explore the repository, run commands, receive errors and resume their work later. Keeping everything in the context window is inefficient. Information gets mixed together and inference costs increase.

The file system can serve as durable working memory: an execution plan, a decision log, command results, test reports, progress state, intermediate diffs and conclusions passed to a sub-agent.

This memory can be inspected by a human and versioned with the project. It is not about recording everything. It is about preserving the artifacts needed for resumption, auditing and understanding the work.

### 5.5. Feedback sensors

Sensors, or *feedback* controls, observe the agent’s actions. They can validate a result, report an error or suggest a correction: compilation, type checking, linters, tests, dependency analysis, security checks or module-boundary validation.

A useful sensor does not simply return “failure”. It provides a signal that both the agent and the human can understand. A custom linter can identify the violated rule, the affected file, the expected example and the command to run next. Without feedback, the agent repeats its mistakes; without prior guidance, it discovers important constraints too late. A balanced harness combines anticipation and observation.

## 6. Two control axes: deterministic and inferential

A practical way to analyze a harness is to cross the timing of the control with the nature of its mechanism.

|  | Computational control | Inferential control |
|---|---|---|
| **Before the action** | Templates, bootstrap scripts, structural rules, codemods | Architecture principles, documentation, examples, semantic instructions |
| **After the action** | Compilation, types, linters, tests, static analysis, dependency rules | Model-based review, consistency analysis, business-intent verification |

### Computational controls

Computational controls are fast, reproducible and inexpensive. They are suitable for rules that can be expressed without interpretation:

- a file must follow a given syntax;
- a type must be compatible;
- a module must not import a forbidden layer;
- a test must produce an expected result;
- a vulnerable dependency must not be introduced;
- a secret must not appear in the repository.

They do not always know whether a feature actually meets the business need. But whenever a rule can be expressed deterministically, it is better to give it to a specialized machine than to a probabilistic model.

### Inferential controls

Inferential controls use a model to analyze intent or consistency that is difficult to reduce to a formal rule. A critic agent can look for a business inconsistency, an oversized solution or a divergence from the request.

This capability is useful, but it is not an absolute guarantee. The evaluator model can be wrong or miss a problem. It should be used as an additional layer, not as the sole arbiter.

A good practical rule is this: deterministic controls should close the doors that can be closed mechanically. Inferential controls can help explore the areas where human interpretation is still required.

## 7. The agent steering loop

The harness turns a request into a controlled sequence:

1. The agent checks the state of the repository.
2. It identifies the relevant documents, files and tools.
3. It restates the task and flags ambiguities.
4. It creates an execution plan.
5. It makes a limited change.
6. The harness runs the appropriate checks.
7. Errors are returned in an actionable form.
8. The agent corrects the change or requests a human decision.
9. The result is recorded, presented and possibly submitted for review.

This loop resembles a classic development workflow, but the agent can chain research, modification and verification cycles without waiting for human intervention after every command. Autonomy should not be confused with the absence of limits: the harness must stop loops that run too long, limit retries, request approval for destructive actions and escalate when signals conflict.

An endlessly repeating loop is not an autonomous agent.

It is automated spending.

Feedback reduces mechanical review work. If the agent can detect a type error, a boundary violation or a failing test, the developer can focus on the need, the architecture and the trade-offs.

## 8. Why this is becoming a strategic business issue

The point of Harness Engineering is not to build complex machinery for the sake of complexity. Agents reduce the marginal cost of producing code, but they can increase the cost of verification and maintenance. Teams can quickly create several variants, open many pull requests and run tasks in parallel.

The bottleneck moves. The question is no longer only “How many lines can we produce?” It becomes “How many changes can we verify, understand and maintain?”

### Shift-Left applied to agents

The Shift-Left principle moves checks toward the beginning of the development cycle. The earlier an error is detected, the less context is usually needed to fix it. An immediate correction can be handled while the agent still has the context of the change; a late error requires the reasoning to be reconstructed.

Cost ratios should not be presented as universal laws. The relationship depends on the project and the team’s diagnostic capability. The robust idea is simple: **errors detected close to where they were introduced are generally easier to understand and less expensive to fix**.

### The example published by OpenAI

In its [report](https://openai.com/index/harness-engineering/) on a product developed with Codex, OpenAI says that the team produced roughly one million lines of code with three engineers at the start, without manually writing code, and estimated that construction took about one tenth of the conventional time. These figures describe a specific experiment, not a promise that can be transferred to every team.

The more interesting lesson is elsewhere: humans spent their time designing environments, abstractions, rules and feedback loops. Because agents can reproduce imperfect patterns, the team also introduced a form of technical “garbage collection”. AI does not remove the need for engineering. It moves engineering toward the system that makes code production reliable.

### Metrics to track

An organization should measure more than lines of code or merged pull requests. More useful indicators include:

- the delay between a change and its feedback;
- the average number of iterations before validation;
- the percentage of tasks completed without human intervention;
- regressions detected before integration;
- the average cost of a task in tokens and machine time;
- the time spent correcting architectural drift.

The useful metric is not “the agent wrote a lot of code”. It is “the team delivers faster without increasing the risk and debt it will have to support tomorrow”.

## 9. Two concrete examples of harnesses

### SWE-bench: evaluating an agent in a reproducible environment

[SWE-bench](https://github.com/SWE-bench/SWE-bench) evaluates the ability of models to solve real software issues drawn from GitHub repositories. The model receives a repository and an issue description, produces a patch, and the patch is then applied and evaluated against the project’s tests.

This benchmark shows why evaluating an agent cannot be reduced to asking the model whether its code looks correct. You need an initial state, an environment, a patch-application procedure and a validation method. The project uses Docker to make evaluations more reproducible and retains execution logs. Without a controlled environment, a score may reflect dependency or configuration differences rather than progress in the model.

Teams can apply the same logic on a smaller scale: select real tasks, freeze a repository state, define acceptance criteria, run the tests and retain the traces.

### Making an enterprise repository legible to agents

Another example is to treat the repository as the team’s system of record. Important decisions, architecture rules, execution plans and procedures required to change the product should be discoverable, versioned and connected to the code.

A possible structure might look like this:

```text
AGENTS.md
ARCHITECTURE.md
docs/
├── design-decisions/
├── product-specs/
├── execution-plans/
├── references/
└── quality/
scripts/
├── check-architecture
├── check-docs
└── test-affected
```

The entry file stays short. Detailed rules live in specialized documents, and scripts verify links and critical constraints. The repository becomes easier for agents to navigate, but also easier for new developers to understand. An environment designed to be legible to a machine can improve human onboarding as well.

## 10. Deploying a harness through maturity levels

Do not start with a gigantic architecture of sub-agents, vector memory and multiple evaluators. Maturity is built progressively.

### Level 1: make the rules explicit

Identify the rules already present in team conversations: commands, conventions, forbidden dependencies, testing procedures, architecture decisions and known traps. Document them in the repository, with an owner and a review date.

### Level 2: automate mechanical checks

Automate formatting, linting, compilation, type checking, fast tests, secret detection, dependency checks and module-boundary validation. Select the checks that actually protect the project and make their messages understandable.

### Level 3: isolate tasks

Run agentic changes in isolated environments: dedicated branches or worktrees, temporary databases, synthetic data and minimal secrets. The agent must be able to fail without making the shared environment unusable.

### Level 4: introduce the correction loop

Configure the agent to run relevant checks after each significant step. Return useful errors, limit retries and preserve work artifacts. Improving feedback quality is often more valuable than adding another evaluator model.

### Level 5: measure real tasks

Build a small set of representative tasks: adding a route, fixing a regression, changing a screen, performing a controlled migration or evolving a module. Run them regularly and measure the results.

### Level 6: increase autonomy gradually

Autonomy should be earned through evidence. A low-impact task can be automated more broadly than a data migration or security change. Define levels: proposal, supervised execution, automatic pull request, conditional merge and recurring execution for low-risk tasks.

The goal is not to remove humans. It is to involve them where their judgment adds real value.

## 11. Mistakes to avoid

### The endless instruction file

A huge document gives the impression that the team has formalized everything, but it becomes difficult to read, maintain and verify. Information starts to contradict itself and important rules get lost. Prefer a short entry point, structured documentation and testable rules.

### Delegating everything to another LLM

An agent that writes the code, a second that reviews it and a third that validates the review can be useful. But three probabilistic opinions do not become proof. Evaluator models complement deterministic controls; they do not replace functional tests, security or business validation.

### Granting too many permissions

An agent that can delete a database, modify secrets and deploy to production has disproportionate power for an ordinary development task. Permissions should be limited by environment, tool and step, and irreversible operations should be explicit.

### Measuring speed instead of flow quality

Producing ten pull requests instead of two is not necessarily progress. If developers then spend their days understanding, fixing and cleaning up those changes, the apparent productivity is misleading. Measure feedback time, regression rate, rework cost and the team’s ability to maintain the result.

### Believing generated tests prove the feature

An agent can generate a test suite that validates its own incorrect behavior. Tests must therefore be reviewed, diversified and compared with business criteria. A green test means that the tested scenario is green. It does not automatically mean that the product meets the real need.

## 12. What the harness cannot solve

Harness Engineering improves the working environment, but it does not turn an unclear specification into a clear need. If nobody can define the feature, the agent may produce a clean but useless implementation. If the architecture or test data is poor, the harness can slow down the degradation without eliminating the debt or the false confidence.

External data, dependencies and documents must also be treated as potentially untrusted sources. Least-privilege permissions, input validation, privilege separation, logs and revocation capabilities remain essential.

The harness is not a magic guarantee. It is a risk-reduction system: it turns unpredictable errors into detectable errors, implicit conventions into visible rules and repetitive manual corrections into reusable controls.

## Conclusion: the next competitive advantage will be the working environment

The race for the most powerful model will not disappear, but it will not be enough to create a lasting difference between teams. What becomes difficult to reproduce is the environment that makes these models usable inside a real project: domain knowledge, conventions, tools, test data, guardrails, feedback loops and measurement methods.

Harness Engineering gives this idea a name. An agent is not simply a model with a few tools attached. It is a system that must perceive an environment, act within its limits, receive signals, correct its trajectory and leave verifiable traces.

For developers, architecture, scripts, tests and documentation become even more important. For decision-makers, AI investment should not be assessed only through model price or token usage. It should also be assessed through the framework that turns this capability into maintainable software.

The real question is no longer “Which AI will write our code?” It is: **What system will we build so that this AI can work quickly without degrading the software it produces?** The most effective teams will not necessarily be the ones with access to the most spectacular model. They will be the ones that build the best environment for it to work in.

## References and further reading

- [Harness engineering for coding agent users — Martin Fowler](https://martinfowler.com/articles/harness-engineering.html)
- [Harness engineering: leveraging Codex in an agent-first world — OpenAI](https://openai.com/index/harness-engineering/)
- [SWE-bench — official repository](https://github.com/SWE-bench/SWE-bench)
- [SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — research paper](https://arxiv.org/abs/2310.06770)
- [DeepSeek Harness — project overview](https://www.deepseek.com/harness/en/)

---

### [Harness Engineering : le banc d’essai qui transforme un modèle d’IA en agent logiciel fiable](https://nicolas-dabene.fr/blog/harness-engineering-le-banc-dessai-qui-transforme-un-modele-dia-en-agent-logiciel-fiable/)
Published: 2026-10-17 | Language: FR | Topics: PrestaShop & e-commerce, Agents IA, LLM & modeles, MCP, PrestaShop

On parle beaucoup du meilleur modèle d’intelligence artificielle pour coder. On parle beaucoup moins de l’environnement dans lequel on le fait travailler.

Pourtant, deux équipes peuvent utiliser le même modèle et obtenir des résultats radicalement différents. Dans une équipe, l’agent produit une fonctionnalité cohérente, respecte l’architecture, lance les bons tests et corrige ses erreurs. Dans l’autre, il modifie les mauvais fichiers, invente des conventions, génère des tests superficiels et laisse derrière lui une dette technique que quelqu’un devra payer plus tard. Le modèle n’a pas changé. Le cadre de travail, oui.

C’est tout l’enjeu du **Harness Engineering**, ou ingénierie du harnais. Le terme désigne l’ensemble des mécanismes qui entourent un modèle d’IA pour lui permettre de comprendre son environnement, d’utiliser des outils, de produire des changements vérifiables et de corriger ses erreurs.

Pour un développeur, cela signifie concevoir une boucle d’exécution fiable autour de l’agent. Pour une direction ou une équipe produit, cela signifie transformer une capacité de génération impressionnante en une capacité de livraison maîtrisée.

Le sujet n’est donc pas uniquement : « Quel modèle devons-nous utiliser ? » La question devient : **dans quel environnement ce modèle peut-il produire du logiciel que nous sommes prêts à maintenir ?**

## TL;DR

- Un modèle de langage génère des propositions. Un agent agit dans un environnement.
- Le harness regroupe les règles, outils, mémoire, sandbox, tests et boucles de feedback qui encadrent cette action.
- Le prompt donne une direction ; le contexte fournit les informations ; le harnais organise le système complet.
- Les contrôles déterministes restent la première ligne de défense. Les contrôles sémantiques les complètent sans les remplacer.
- La valeur vient de la capacité à produire rapidement du code vérifiable, traçable et réversible.

## 1. Générer du code n’est pas encore développer un logiciel

Une démonstration d’IA donne souvent une impression trompeuse. On demande à un modèle de créer une page, une API ou un composant ; quelques secondes plus tard, le code apparaît et semble convaincant. Puis on place la même demande dans un projet réel : le dépôt contient plusieurs années d’historique, des conventions implicites, des dépendances externes, des variables d’environnement, des contraintes de sécurité et des tests qui ne s’exécutent pas tous à la même vitesse.

Dans ce contexte, produire du code n’est que le début du travail. L’agent doit comprendre la demande, identifier la partie du système concernée, vérifier les conventions, choisir les bons fichiers, parfois poser une question, modifier le code, exécuter les contrôles, interpréter les erreurs et expliquer le résultat.

Une simple complétion textuelle ne suffit pas. Un modèle de langage ne possède pas spontanément la mémoire de l’entreprise, la responsabilité du produit ou l’intuition d’un développeur qui connaît les conséquences d’une mauvaise décision. Il manipule les informations qui lui sont accessibles au moment de l’exécution. Si une règle importante n’est pas visible, elle risque de ne pas exister pour lui.

Le piège consiste alors à répondre à chaque échec par un prompt plus long. Si l’agent utilise une mauvaise commande, il faut peut-être améliorer l’outil. S’il modifie une mauvaise couche, il faut peut-être ajouter une règle d’architecture testable. S’il répète la même erreur, il faut peut-être enrichir le feedback. Le problème n’est pas toujours le raisonnement du modèle. Souvent, c’est l’absence de système autour de lui.

## 2. Qu’est-ce que le Harness Engineering ?

Le mot *harness* vient notamment de l’ingénierie physique. Dans un véhicule, un *wiring harness* distribue l’énergie et les signaux. Dans les tests, un *test harness* permet d’actionner un composant, de simuler ses dépendances et de mesurer son comportement dans un environnement contrôlé.

Le logiciel classique utilise cette logique avec des programmes appelants, des données de préparation, des bouchons de dépendances, des simulateurs, un moteur d’exécution et un système de rapport. Le composant testé croit parfois dialoguer avec une base de données ou un service distant, alors qu’il reçoit une réponse simulée et reproductible.

Avec les agents IA, la notion s’élargit : le harnais organise le travail du système qui produit le logiciel. Il détermine ce que l’agent peut voir, faire et modifier, les outils qu’il peut appeler, les contrôles qu’il doit déclencher et la manière dont les erreurs lui sont renvoyées.

Une définition opérationnelle serait donc la suivante :

> Le Harness Engineering consiste à concevoir l’environnement, les outils, les règles et les boucles de contrôle qui permettent à un agent IA d’agir de manière fiable dans un système logiciel réel.

Cette définition est plus large qu’un framework d’agents : elle couvre compréhension, action, vérification, correction, traçabilité et arrêt. Dans son analyse du sujet, [Martin Fowler](https://martinfowler.com/articles/harness-engineering.html) distingue notamment le harnais intégré par le fournisseur de l’agent et celui construit par l’équipe qui l’utilise. Le dépôt, les scripts, les règles et les contrôles forment cette couche adaptée au projet.

## 3. Prompt Engineering, Context Engineering et Harness Engineering

Ces trois notions cherchent à améliorer les résultats d’un modèle, mais ne travaillent pas au même niveau.

| Approche | Question principale | Exemple |
|---|---|---|
| Prompt Engineering | Que dois-je demander au modèle ? | « Ajoute une pagination à cette liste. » |
| Context Engineering | Quelles informations dois-je lui fournir ? | Architecture, règles métier, fichiers et documentation pertinents. |
| Harness Engineering | Dans quel système l’agent peut-il agir et comment vérifier son travail ? | Outils, permissions, sandbox, tests, feedback et boucles de correction. |

Le prompt formule l’objectif ou le résultat attendu. Il clarifie l’intention humaine, mais ne peut pas porter à lui seul l’architecture, la procédure de déploiement, les conventions et les exceptions historiques d’un projet.

Le contexte rend disponibles les informations nécessaires : fichiers du dépôt, contrats d’API, schémas, tickets, décisions d’architecture ou erreurs précédentes. Une fenêtre remplie d’informations inutiles augmente toutefois le bruit et le coût. Le bon contexte est l’information pertinente, au bon moment, dans un format que l’agent peut parcourir et vérifier.

Le harnais organise le système de travail : ordre des opérations, permissions, outils, isolation, persistance des artefacts, contrôles, réinjection des erreurs, limites de temps et de coût, et validation humaine lorsque nécessaire.

Un prompt peut demander à l’agent de lancer les tests ; un harnais peut rendre cette étape automatique et bloquer la suite si les tests échouent. Un prompt peut demander de ne pas modifier une couche ; le harnais peut vérifier les dépendances et refuser le changement. Un prompt peut demander de ne pas utiliser de données réelles ; le harnais peut lancer l’agent dans un environnement isolé. Le prompt explique. Le harnais rend la règle observable et, lorsque c’est possible, exécutable.

## 4. Trois analogies pour comprendre le concept

### Le simulateur de vol

Un pilote ne s’entraîne pas à une panne moteur avec des passagers à bord d’un avion de ligne. Il utilise un simulateur qui reproduit suffisamment l’environnement pour rendre l’exercice utile, tout en permettant de provoquer des situations dangereuses sans les subir dans le monde réel.

Un agent de développement peut travailler de la même manière : dépôt isolé, base de données de test, services simulés et commandes contrôlées. Il peut reproduire un bug et vérifier le comportement sans toucher à la production. Le harnais apporte ici isolation et répétabilité.

### Le harnais d’attelage

Un modèle puissant ressemble à un moteur capable de produire beaucoup d’énergie, mais qui ne sait pas nécessairement où la diriger. Le harnais transmet les commandes et rend cette puissance exploitable. Sans contrôle, un agent peut enchaîner les commandes et consommer des tokens sans se rapprocher du bon résultat. L’objectif est de rendre ses actions observables, corrigeables et proportionnées.

### L’atelier industriel

Imaginez un apprenti extrêmement rapide, capable de lire des milliers de pages en quelques secondes, mais qui ignore les habitudes de l’atelier, les machines fragiles et les tolérances critiques. On organise son poste, on lui donne des outils adaptés, on installe des butées, on vérifie les pièces et on lui indique immédiatement la cause d’une erreur.

Le Harness Engineering consiste à concevoir cet atelier logiciel : l’agent garde ses décisions locales, mais les erreurs coûteuses sont détectées tôt et les règles importantes ne reposent plus uniquement sur la mémoire d’un expert.

## 5. Anatomie d’un harnais pour agent de développement

Un harnais ne se résume pas à un fichier `AGENTS.md`, à un serveur MCP ou à un script de test. Ces éléments ne sont que des composants d’un système plus large.

### 5.1. Les guides : agir avant l’erreur

Les guides, ou contrôles *feedforward*, donnent à l’agent les informations et les outils qui augmentent la probabilité d’une bonne décision dès la première tentative.

On y trouve les conventions de contribution, les règles d’architecture, les critères d’acceptation, les procédures de démarrage, les commandes de test, les règles de sécurité et les contrats d’API.

Le fichier `AGENTS.md` est utile comme point d’entrée : où trouver les informations, comment démarrer le projet et quelles commandes utiliser. Il devient moins utile lorsqu’il se transforme en manuel interminable. Dans son [retour d’expérience](https://openai.com/index/harness-engineering/), OpenAI explique avoir préféré un fichier court, utilisé comme table des matières vers une base de connaissances structurée dans le dépôt.

### 5.2. Les outils et leurs frontières

Un agent devient opérationnel lorsqu’il peut agir. Mais chaque action augmente aussi la surface de risque : lire un fichier, consulter une API, pousser une branche ou lancer une migration ne présentent pas le même niveau d’impact.

Le harnais doit donc définir les outils et paramètres accessibles, les ressources visibles, les actions irréversibles qui nécessitent une confirmation, ainsi que les formats de sortie et journaux à conserver.

La conception d’un outil est aussi importante que le modèle qui l’utilise. Une erreur vague oblige l’agent à deviner ; un message précis, la cause probable et la commande de vérification fournissent un feedback exploitable. Une commande limitée, idempotente et testable vaut parfois mieux qu’une interface générale.

### 5.3. Le bac à sable et la reproductibilité

Un agent ne devrait pas toucher directement à la production pour démontrer qu’une modification fonctionne. Le harnais peut utiliser des conteneurs, des worktrees Git, des bases temporaires, des données synthétiques et des services simulés. L’objectif est de rendre le comportement suffisamment proche, contrôlé et répétable pour détecter les erreurs pertinentes.

La reproductibilité est une condition de confiance. Un harnais bien conçu permet de savoir quelle version du code a été testée, avec quelles dépendances, dans quel environnement et avec quels contrôles.

### 5.4. Le système de fichiers comme mémoire durable

Les agents travaillent souvent dans des boucles longues : ils planifient, explorent le dépôt, exécutent des commandes, reçoivent des erreurs et reprennent leur travail plus tard. Tout conserver dans la fenêtre de contexte est inefficace : les informations se mélangent et le coût augmente.

Le système de fichiers peut alors servir de mémoire de travail durable : plan d’exécution, journal des décisions, résultats de commandes, rapports de tests, état d’avancement, diffs intermédiaires et conclusions transmises à un sous-agent.

Cette mémoire peut être inspectée par un humain et versionnée avec le projet. Il ne s’agit pas de tout enregistrer, mais de conserver les artefacts utiles à la reprise, à l’audit et à la compréhension du travail.

### 5.5. Les capteurs de feedback

Les capteurs, ou contrôles *feedback*, observent l’action de l’agent. Ils peuvent valider le résultat, signaler une erreur ou proposer une correction : compilation, types, linter, tests, analyse de dépendances, sécurité ou frontières entre modules.

Un capteur utile ne renvoie pas seulement « échec ». Il fournit un signal compréhensible par l’agent et par l’humain. Un linter personnalisé peut indiquer la règle violée, le fichier concerné, l’exemple attendu et la commande à relancer. Sans feedback, l’agent répète ses erreurs ; sans guide préalable, il découvre trop tard des contraintes importantes. Un harnais équilibré combine anticipation et observation.

## 6. Deux axes de contrôle : déterministe et inférentiel

Une manière pratique d’analyser un harnais consiste à croiser le moment du contrôle et la nature de son mécanisme.

|  | Contrôle computationnel | Contrôle inférentiel |
|---|---|---|
| **Avant l’action** | Templates, scripts d’initialisation, règles de structure, codemods | Principes d’architecture, documentation, exemples, instructions sémantiques |
| **Après l’action** | Compilation, types, linters, tests, analyse statique, règles de dépendance | Revue par un modèle, analyse de cohérence, vérification de l’intention métier |

### Les contrôles computationnels

Les contrôles computationnels sont rapides, reproductibles et peu coûteux. Ils conviennent aux règles exprimables sans interprétation :

- un fichier doit respecter une syntaxe ;
- un type doit être compatible ;
- un module ne doit pas importer une couche interdite ;
- un test doit produire un résultat attendu ;
- une dépendance vulnérable ne doit pas être introduite ;
- une variable sensible ne doit pas apparaître dans le dépôt.

Ils ne savent pas toujours si la fonctionnalité répond au besoin réel. Mais lorsqu’une règle est exprimable de manière déterministe, il est préférable de la confier à une machine spécialisée plutôt qu’à un modèle probabiliste.

### Les contrôles inférentiels

Les contrôles inférentiels utilisent un modèle pour analyser une intention ou une cohérence difficile à réduire à une règle formelle. Un agent critique peut chercher une incohérence métier, une solution surdimensionnée ou une divergence avec la demande.

Cette capacité ne fournit pas une garantie absolue : le modèle évaluateur peut se tromper ou manquer un problème. Il faut l’utiliser comme une couche supplémentaire, pas comme le seul arbitre.

Une bonne règle pratique est la suivante : les contrôles déterministes doivent fermer les portes qui peuvent être fermées mécaniquement. Les contrôles inférentiels peuvent aider à explorer les zones où l’interprétation humaine reste nécessaire.

## 7. La boucle de pilotage d’un agent

Le harnais transforme une demande en une séquence contrôlée :

1. L’agent vérifie l’état du dépôt.
2. Il identifie les documents, fichiers et outils pertinents.
3. Il reformule la tâche et signale les ambiguïtés.
4. Il produit un plan d’exécution.
5. Il réalise une modification limitée.
6. Le harnais exécute les contrôles appropriés.
7. Les erreurs sont renvoyées sous une forme exploitable.
8. L’agent corrige ou demande une décision humaine.
9. Le résultat est enregistré, présenté et éventuellement soumis à revue.

Cette boucle ressemble à un workflow classique, mais l’agent peut enchaîner les cycles de recherche, modification et vérification sans attendre une intervention après chaque commande. L’autonomie ne doit toutefois pas être confondue avec l’absence de limites : le harnais doit arrêter une boucle trop longue, limiter les tentatives, demander une validation pour une action destructive et escalader lorsque les signaux sont contradictoires.

Une boucle qui recommence indéfiniment n’est pas un agent autonome. C’est une dépense automatisée.

Le feedback réduit le travail mécanique de revue. Si l’agent détecte une erreur de typage, une violation de frontière ou un test en échec, le développeur peut se concentrer sur le besoin, l’architecture et les arbitrages.

## 8. Pourquoi le sujet devient stratégique pour l’entreprise

L’intérêt du Harness Engineering n’est pas de construire une machinerie complexe pour le plaisir de la complexité. Les agents réduisent le coût marginal de production du code, mais peuvent augmenter le coût de vérification et de maintenance. Il devient possible de créer plusieurs variantes, d’ouvrir de nombreuses pull requests et de lancer des tâches en parallèle. Le goulot d’étranglement se déplace : la question n’est plus seulement « Combien de lignes pouvons-nous produire ? », mais « Combien de changements pouvons-nous vérifier, comprendre et maintenir ? »

### Le Shift-Left appliqué aux agents

Le principe du Shift-Left consiste à déplacer les contrôles vers le début du cycle de développement. Plus une erreur est détectée tôt, moins elle demande de contexte pour être corrigée. Une correction immédiate peut être traitée alors que l’agent possède encore le contexte de la modification ; une erreur tardive oblige à reconstruire le raisonnement.

Il faut éviter de présenter des ratios de coût comme des lois universelles : la relation dépend du projet et de la capacité de diagnostic. L’idée robuste est simple : **les erreurs détectées près de leur origine sont généralement plus faciles à comprendre et moins coûteuses à corriger**.

### L’exemple publié par OpenAI

Dans son [retour d’expérience](https://openai.com/index/harness-engineering/) sur un produit développé avec Codex, OpenAI indique que l’équipe a produit environ un million de lignes de code avec trois ingénieurs au départ, sans écriture manuelle de code, et estime avoir réduit le temps de construction à environ un dixième du temps conventionnel. Ces chiffres décrivent une expérience précise, pas une promesse transposable.

L’enseignement est ailleurs : les humains ont consacré leur temps à concevoir les environnements, abstractions, règles et boucles de feedback. Comme les agents peuvent reproduire des patterns imparfaits, l’équipe a ajouté une forme de « garbage collection » technique. L’IA ne supprime donc pas l’ingénierie ; elle la déplace vers le système qui rend la production de code fiable.

### Les indicateurs à suivre

Une organisation devrait mesurer autre chose que les lignes produites ou les pull requests fusionnées. Des indicateurs plus utiles sont :

- le délai entre une modification et son feedback ;
- le nombre moyen d’itérations avant validation ;
- le taux de tâches terminées sans intervention humaine ;
- les régressions détectées avant intégration ;
- le coût moyen d’une tâche en tokens et en temps machine ;
- le temps consacré aux corrections de dérive architecturale.

Le bon indicateur n’est pas « l’agent a écrit beaucoup de code », mais « l’équipe livre plus vite sans augmenter le risque et la dette qu’elle devra supporter demain ».

## 9. Deux exemples concrets de harnais

### SWE-bench : évaluer un agent dans un environnement reproductible

[SWE-bench](https://github.com/SWE-bench/SWE-bench) évalue la capacité de modèles à résoudre de vrais problèmes logiciels issus de dépôts GitHub. Le modèle reçoit un dépôt et la description d’un problème, produit un patch, puis celui-ci est appliqué et évalué avec les tests du projet.

Ce benchmark montre pourquoi l’évaluation ne peut pas se limiter à demander au modèle si son code semble correct. Il faut un état initial, un environnement, une procédure d’application et une méthode de validation. Le projet utilise Docker pour rendre les évaluations plus reproductibles et conserve les journaux d’exécution. Sans environnement contrôlé, un score peut refléter une différence de dépendances plutôt qu’une progression du modèle.

Dans une équipe, on peut appliquer la même logique à une échelle plus modeste : sélectionner des tâches réelles, figer un état du dépôt, définir les critères d’acceptation, exécuter les tests et conserver les traces.

### Un dépôt d’entreprise rendu lisible par les agents

Un autre cas consiste à traiter le dépôt comme le système de référence de l’équipe. Les décisions importantes, les règles d’architecture, les plans d’exécution et les procédures nécessaires pour modifier le produit doivent être découvrables, versionnés et reliés au code.

Une structure possible peut ressembler à ceci :

```text
AGENTS.md
ARCHITECTURE.md
docs/
├── design-decisions/
├── product-specs/
├── execution-plans/
├── references/
└── quality/
scripts/
├── check-architecture
├── check-docs
└── test-affected
```

Le fichier d’entrée reste court. Les règles détaillées se trouvent dans des documents spécialisés et des scripts vérifient les liens ainsi que les contraintes critiques. Le dépôt devient alors plus lisible pour l’agent, mais aussi pour les humains : un environnement compréhensible par une machine peut améliorer l’onboarding d’un nouveau développeur.

## 10. Déployer un harnais par niveaux de maturité

Ne commencez pas par une architecture gigantesque de sous-agents, de mémoire vectorielle et d’évaluateurs multiples. La maturité se construit progressivement.

### Niveau 1 : rendre les règles explicites

Identifiez les règles déjà présentes dans les échanges de l’équipe : commandes, conventions, dépendances interdites, tests, décisions d’architecture et pièges connus. Documentez-les dans le dépôt, avec un propriétaire et une date de révision.

### Niveau 2 : automatiser les contrôles mécaniques

Automatisez formatage, lint, compilation, types, tests rapides, secrets, dépendances et frontières de modules. Sélectionnez les contrôles qui protègent réellement le projet et rendez leurs messages compréhensibles.

### Niveau 3 : isoler les tâches

Lancez les modifications agentiques dans des environnements isolés : branches ou worktrees dédiés, bases temporaires, données synthétiques et secrets minimaux. L’agent doit pouvoir échouer sans rendre l’environnement global inutilisable.

### Niveau 4 : introduire la boucle de correction

Configurez l’agent pour qu’il exécute les contrôles pertinents après chaque étape significative. Renvoyez-lui les erreurs utiles, limitez les tentatives et conservez les artefacts de travail. Il est souvent plus rentable d’améliorer la qualité du feedback que d’ajouter un nouveau modèle évaluateur.

### Niveau 5 : mesurer des tâches réelles

Construisez un petit jeu de tâches représentatives : ajout d’une route, correction d’une régression, modification d’un écran, migration contrôlée ou évolution d’un module. Faites-les exécuter régulièrement et mesurez les résultats.

### Niveau 6 : augmenter progressivement l’autonomie

L’autonomie doit être gagnée par les preuves. Une tâche sans impact peut être automatisée plus largement qu’une migration de données ou qu’une modification de sécurité. Définissez des niveaux : proposition, exécution supervisée, pull request automatique, fusion sous conditions, puis exécution récurrente pour les tâches à faible risque. L’objectif n’est pas de supprimer l’humain, mais de le faire intervenir là où son jugement apporte une vraie valeur.

## 11. Les erreurs à éviter

### Le fichier d’instructions interminable

Un document géant donne l’impression que l’équipe a tout formalisé, mais devient difficile à lire, maintenir et vérifier. Les informations se contredisent et les règles importantes se perdent. Préférez une entrée courte, une documentation structurée et des règles testables.

### Tout confier à un autre LLM

Un agent qui écrit du code, un second qui le relit et un troisième qui valide la revue peuvent être utiles. Mais trois avis probabilistes ne deviennent pas une preuve. Les modèles évaluateurs complètent les contrôles déterministes ; ils ne remplacent ni les tests fonctionnels, ni la sécurité, ni la validation métier.

### Donner trop de permissions

Un agent qui peut supprimer une base, modifier des secrets et déployer en production possède une capacité disproportionnée pour une tâche ordinaire. Les permissions doivent être limitées par environnement, par outil et par étape, et les opérations irréversibles doivent être explicites.

### Mesurer la vitesse plutôt que la qualité du flux

Produire dix pull requests au lieu de deux n’est pas nécessairement un progrès. Si les développeurs passent ensuite leurs journées à comprendre, corriger et nettoyer ces changements, la productivité affichée est trompeuse. Il faut mesurer le temps de feedback, le taux de régression, le coût de reprise et la capacité à maintenir le résultat.

### Croire que des tests générés prouvent la fonctionnalité

Un agent peut générer une suite de tests qui valide son propre comportement incorrect. Les tests doivent donc être relus, diversifiés et confrontés à des critères métier. Un test vert signifie que le scénario testé est vert ; pas que le produit répond automatiquement au besoin réel.

## 12. Ce que le harnais ne peut pas résoudre

Le Harness Engineering améliore le cadre de travail, mais ne transforme pas une spécification floue en besoin clair. Si personne ne sait définir la fonctionnalité, l’agent peut produire une implémentation propre mais inutile. Si l’architecture ou les données de test sont mauvaises, le harnais peut ralentir la dégradation sans supprimer la dette ni la fausse confiance.

Il faut également traiter les données externes, les dépendances et les documents consultés comme des sources potentiellement non fiables. Permissions minimales, validation des entrées, séparation des privilèges, journaux et capacité de révocation restent indispensables.

Le harnais n’est pas une garantie magique. C’est un système de réduction du risque : il transforme des erreurs imprévisibles en erreurs détectables, des conventions implicites en règles visibles et des corrections répétitives en contrôles réutilisables.

## Conclusion — Le prochain avantage compétitif sera l’environnement de travail

La course au modèle le plus puissant ne va pas disparaître, mais elle ne suffira plus à différencier durablement les équipes. Ce qui devient difficile à reproduire, c’est l’environnement qui permet d’utiliser ces modèles dans un projet réel : connaissance du domaine, conventions, outils, données de test, garde-fous, boucles de feedback et méthodes de mesure.

Le Harness Engineering formalise cette idée. Un agent n’est pas seulement un modèle auquel on ajoute quelques outils : c’est un système qui doit percevoir un environnement, agir dans ses limites, recevoir des signaux, corriger sa trajectoire et laisser des traces vérifiables.

Pour les développeurs, l’architecture, les scripts, les tests et la documentation deviennent donc encore plus importants. Pour les décideurs, l’investissement dans l’IA ne doit pas être évalué uniquement à partir du prix du modèle ou du nombre de tokens, mais aussi à partir du cadre qui transforme cette capacité en logiciel exploitable.

La vraie question n’est plus : « Quelle IA va écrire notre code ? » C’est : **quel système allons-nous construire pour que cette IA puisse travailler vite sans dégrader le logiciel qu’elle produit ?** Les équipes les plus efficaces ne seront pas nécessairement celles qui auront le modèle le plus spectaculaire, mais celles qui auront construit le meilleur environnement pour le faire travailler.

## Références et ressources

- [Harness engineering for coding agent users — Martin Fowler](https://martinfowler.com/articles/harness-engineering.html)
- [Harness engineering: leveraging Codex in an agent-first world — OpenAI](https://openai.com/index/harness-engineering/)
- [SWE-bench — dépôt officiel](https://github.com/SWE-bench/SWE-bench)
- [SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — article de recherche](https://arxiv.org/abs/2310.06770)
- [DeepSeek Harness — présentation du projet](https://www.deepseek.com/harness/en/)

---

### [The Modern Developer Resembles a Child with a LEGO Box More Than an Expert with a Perfect Blueprint](https://nicolas-dabene.fr/en/blog/the-modern-developer-resembles-a-child-with-a-lego-box-more-than-an-expert-with-a-perfect-blueprint/)
Published: 2026-10-03 | Language: EN | Topics: Developpement & architecture, Agents IA, API, Architecture, Automatisation, Intelligence artificielle, LLM & modeles, Pédagogie, Securite

> **TL;DR —** Modern development rarely means building everything yourself. The work is to choose components, fit them together, check that they hold, and replace them when the need changes. AI makes experimentation faster, but it does not take on the judgment or responsibility for the whole system.

A box of building bricks does more than offer a model to copy. It gives you pieces, a few rules for putting them together, and room to try something else. You build, see what holds, take part of it apart, and start again with a better sense of what works.

Software development increasingly follows the same pattern. Not because the work has become child’s play, but because our ability to build depends on choosing and assembling things we did not write ourselves. Code still matters. Understanding the system around that code matters even more.

## Development was never a blank page

Even before AI assistants, a project was already made of building blocks: a framework, a library, a payment API, a database, an authentication system, a cache service, or a design system. The skill was not only knowing how to create those parts. It was knowing which ones fit the problem, how to integrate them, and what their presence would mean for the project.

Today’s ecosystem makes that reality easier to see. In a few hours, you can start a Next.js application, connect PostgreSQL, add authentication, or wire up an API. That is useful. But having more building blocks does not guarantee a better structure.

You can stack components until you have something that works in a demo. The harder problems appear later: incompatible dependencies, a data model that does not fit, security considered too late, missing tests, or behavior no one can diagnose. In software, the equivalent of a block tower collapsing is often a feature that seemed finished but no one dares to change.

So the question is not only, “Does it work?” It is also, “What happens when the need changes?”

## Moving fast is not the same as working at random

A prototype that quickly disproves a bad assumption can be more valuable than a solution theorized for weeks and delivered too late. An integration tested in staging can prevent an incident. Removing a feature that has become too costly to maintain can be better than continuing to add to it.

It depends on how the experiment is run. Breaking something in production with no logs, no tests, and no way back is not iteration. It transfers the risk to users and the team. An experiment in a controlled environment, with a clear hypothesis and validation criteria, helps the team learn before release.

Iteration is not the absence of a method. It is a method that recognizes we do not always understand a complex problem until a first solution meets reality. We observe what happens, narrow the problem, check our assumptions, and rebuild on firmer ground.

## AI can make the pieces. It does not own the whole structure.

An AI assistant can generate a component skeleton, a SQL migration, tests, or a first integration. It lowers the cost of exploration and helps us move faster from an idea to something we can inspect.

But it does not automatically know all the constraints that keep a project together: business rules missing from the ticket, data-model invariants, flows that must remain idempotent, dependencies that are already fragile, or trade-offs the team has made. It can produce a convincing piece without knowing whether it fits the existing structure.

That is where generation speed can mislead us. Producing code quickly is not the same as delivering quickly. The code still has to be understood, tested, secured, integrated, and made maintainable six months from now.

The simple opposition between “coding by hand” and “having AI code” does not help me much. In either case, the useful question is the same: what are we trying to build, and do we understand the pieces well enough to make the whole thing hold? AI speeds up people who know how to frame and verify the work. Without that discipline, it mainly speeds up the production of decisions no one made deliberately.

## A plan gives direction, not certainty

Before building, we need to clarify the goal, the constraints, the responsibilities, and the parts that must stay stable. That is what design and planning are for: avoiding a pile of components with no clear destination.

But a plan is not a promise that everything is known in advance. The first prototype may show that an API does not meet the need, that users misunderstand a workflow, or that performance falls apart with real data. The right response is not to defend the original plan. It is to update it based on what we have learned.

A plan that never changes is not necessarily a sign of control. It may simply never have met the real world. A plan is useful when it guides experiments and makes decisions visible, then changes when the evidence calls for it.

## Building for the long term means making change possible

A feature is not finished in the sense that it will never change. Usage evolves, business constraints become clearer, and technical choices age. Building for the long term mostly means being able to change one part of a system without rebuilding everything around it.

That is why fundamentals still matter: clear boundaries between responsibilities, an understandable architecture, tests that protect essential behavior, useful logs, documentation that explains important decisions, and deployments that can be rolled back. These things are rarely the most visible part of a demo, but they determine what the team can change next.

The most useful code is not always the code that looks impressive at first glance. Often, it is the code another person can read, evolve, and deploy without worrying about triggering a chain reaction.

## The work is shifting toward judgment

Developers will probably write less repetitive code than they did ten years ago. In return, they need to make more decisions: which component to reuse, what to automate, which trade-off to accept, which risk to contain, and when to stop iterating and ship.

Communication matters more too. When a first version can appear very quickly, value shifts toward clarifying a vague request, making choices explicit, and sharing understanding across the people, tools, and systems involved.

This is not the end of the profession. It is a change in its responsibilities. The pieces are more accessible, the structures more ambitious, and the consequences of a mistake sometimes greater. The work is still to understand the problem, choose a first shape, try it, and learn from what does not hold yet.

## Build better with every attempt

Software development is not a race to produce as much code as possible. It is continuous construction: reuse what exists when it fits, create what is missing, check the connections between parts, and start again when reality points to a better route.

AI shortens the loop between an idea and a first result. It does not remove the need to understand, to choose, or to take responsibility for what goes into production. A good developer is not someone who never breaks anything. It is someone who knows where to experiment, what to protect, and how to leave the project stronger after each attempt.

Like working from a big box of building bricks, the question is not whether we have enough pieces. We need to know what we want to build, understand what will make it hold, and be willing to rebuild when the first attempts are not enough.

---

### [Le développeur moderne ressemble davantage à un enfant devant une boîte de LEGO qu’à un expert devant un plan parfait](https://nicolas-dabene.fr/blog/le-developpeur-moderne-ressemble-davantage-a-un-enfant-devant-une-boite-de-lego-qua-un-expert-devant-un-plan-parfait/)
Published: 2026-10-03 | Language: FR | Topics: Developpement & architecture, Agents IA, API, Architecture, Automatisation, Intelligence artificielle, LLM & modeles, Pédagogie, Securite

> **TL;DR —** Le développement moderne ne consiste plus seulement à écrire du code depuis zéro. Il consiste à assembler des briques, vérifier qu’elles tiennent ensemble, les remplacer lorsqu’elles ne répondent plus au besoin, puis apprendre de chaque itération. L’IA accélère ce mouvement, mais elle ne remplace ni le jugement, ni l’architecture, ni la responsabilité de construire quelque chose qui dure.

Quand on était enfant, une énorme boîte de LEGO avait quelque chose de très particulier. Elle ne promettait pas un résultat précis. Elle promettait des possibilités.

On pouvait suivre le plan et construire le modèle sur la boîte. Puis on pouvait décider que la voiture devait avoir des ailes, que le château avait besoin d’un garage ou que le vaisseau spatial devait devenir une base secrète. On assemblait, on regardait ce que cela donnait, on démontait une partie, on cherchait une autre brique et on recommençait. Ce n’était pas du travail bâclé. C’était une manière très concrète d’apprendre à construire.

Je pense que le développeur d’aujourd’hui ressemble beaucoup à cet enfant-là. Pas parce que son métier serait devenu un jeu. Au contraire : parce que notre capacité à créer dépend de plus en plus de notre aptitude à explorer, à assembler intelligemment et à améliorer ce qui existe déjà.

Le code reste important. L’architecture l’est encore davantage. Mais le fantasme du développeur qui écrit seul, depuis une page blanche, chaque ligne d’un système parfaitement maîtrisé est devenu largement insuffisant pour décrire la réalité.

## Le développement n’a jamais été une suite de lignes écrites dans le vide

Même avant l’arrivée des assistants IA, nous travaillions déjà avec des briques. Un framework, une bibliothèque, une API de paiement, une base de données, un système d’authentification, un design system, un service de cache : chacun apporte une partie du produit final.

La vraie compétence n’était donc pas seulement de savoir fabriquer une brique. Elle consistait à savoir laquelle choisir, comment l’intégrer et, surtout, comment éviter que l’ensemble s’effondre au premier changement.

Avec l’écosystème moderne, cette logique est devenue encore plus visible. En quelques heures, on peut connecter une API, démarrer un projet Next.js, mettre en place une base PostgreSQL, intégrer une authentification ou automatiser un workflow. Ce n’est pas de la magie. Ce sont des briques de plus en plus accessibles.

Et c’est précisément là que se situe le piège : avoir beaucoup de briques ne suffit pas à construire quelque chose d’utile.

Un enfant peut empiler toutes les pièces de sa boîte jusqu’à faire une tour. Mais il comprend très vite qu’une tour trop haute, mal équilibrée ou posée sur une base trop petite finit au sol. En développement, le résultat est moins spectaculaire, mais la mécanique est la même : dette technique, dépendances incompatibles, données mal modélisées, sécurité ajoutée trop tard, absence de tests ou comportement impossible à diagnostiquer.

Le problème n’est pas d’aller vite. Le problème est de ne pas regarder comment ce que l’on vient de construire tiendra demain.

## Construire, tester, casser : ce n’est pas échouer, c’est travailler

Pendant longtemps, on a présenté l’erreur comme le contraire du travail bien fait. Dans le développement, cette idée est absurde.

Un prototype qui échoue rapidement peut avoir bien plus de valeur qu’une solution longuement théorisée qui arrive trop tard. Une intégration cassée en environnement de test peut éviter une panne en production. Une fonctionnalité que l’on démonte parce qu’elle ajoute de la complexité inutile est parfois la meilleure décision du projet.

La différence se joue dans la manière de casser.

Casser au hasard en production, sans logs, sans tests et sans possibilité de retour arrière, ce n’est pas itérer. C’est transférer le risque aux utilisateurs et à l’équipe qui devra gérer l’incident. En revanche, expérimenter dans un cadre maîtrisé, avec une hypothèse claire, des critères de validation et une possibilité de rollback, c’est faire avancer le produit.

L’enfant devant ses LEGO ne pleure pas lorsqu’une construction ne tient pas. Il identifie une pièce trop fragile, cherche un autre point d’appui et recommence. Le développeur expérimenté fait pareil : il observe un comportement, réduit le problème, vérifie ses hypothèses et reconstruit sur une base plus solide.

L’itération n’est pas l’absence de méthode. C’est une méthode qui accepte la réalité : on comprend rarement un problème complexe avant d’avoir essayé de le résoudre.

## L’IA a ajouté des briques. Elle n’a pas construit le bâtiment à notre place.

L’arrivée de l’IA générative rend cette métaphore encore plus juste. Aujourd’hui, un développeur peut demander un squelette de composant, une migration SQL, des tests, une documentation technique ou une première version d’intégration. Cela réduit énormément le coût de l’exploration.

Mais un assistant IA ne sait pas spontanément pourquoi ton modèle de données est ainsi, quelles contraintes métier sont invisibles dans le ticket, quel flux doit rester idempotent ou quelle dépendance ne doit jamais être introduite dans ce projet. Il peut produire une brique. Il ne porte pas la responsabilité de la structure.

Le risque actuel est de confondre vitesse de génération et vitesse de livraison. Générer du code très vite est devenu facile. Comprendre ce code, le tester, le sécuriser, le faire évoluer et l’assumer dans six mois reste le vrai travail.

Je ne crois pas à l’opposition simpliste entre « coder à la main » et « faire coder par l’IA ». C’est comme opposer un enfant qui fabrique chaque brique de LEGO à un autre qui utilise une boîte déjà complète. Dans les deux cas, la question utile est la même : qu’est-ce que tu essaies de construire, et est-ce que tu maîtrises suffisamment les pièces pour le faire tenir ?

L’IA donne un accélérateur à ceux qui savent déjà cadrer un problème. Elle donne aussi l’illusion d’une compétence à ceux qui ne vérifient rien. La frontière n’est pas l’outil. C’est le niveau d’exigence que l’on garde face à son résultat.

## Le plan reste essentiel, mais il ne doit pas empêcher de commencer

Dans une boîte de LEGO, le plan a une vraie utilité. Il évite de chercher inutilement, donne une direction et montre dans quel ordre certaines pièces doivent être posées. En développement, c’est exactement le rôle d’une bonne phase de conception : clarifier l’objectif, identifier les contraintes, découper le sujet, décider de ce qui doit être stable avant de démarrer.

Mais suivre un plan ne signifie pas prétendre que tout est connu à l’avance.

Un projet sérieux a besoin d’un cap, d’une architecture et de choix explicites. Il a aussi besoin de boucles de retour rapides. Si la première intégration révèle que l’API ne répond pas au besoin, si les utilisateurs ne comprennent pas le parcours ou si la performance s’effondre avec des données réelles, le bon réflexe n’est pas de protéger le plan initial. C’est de corriger le plan.

Le mode plan est précieux. Il force à penser avant d’empiler les pièces. Mais un plan qui ne survit pas au contact du terrain est un document décoratif, pas un outil de développement.

## Les meilleures constructions ne sont pas celles qui ne changent jamais

Dans beaucoup d’équipes, on valorise encore le fait de « finir » une fonctionnalité comme si elle était ensuite gravée dans le marbre. Pourtant, les bons produits évoluent. Les usages changent, les contraintes métier se précisent, les technologies avancent et ce qui semblait évident six mois plus tôt peut devenir une mauvaise réponse.

Construire pour durer ne signifie pas construire pour ne plus toucher à rien. Cela signifie rendre le changement possible sans devoir tout casser autour.

C’est là que les fondamentaux reprennent toute leur importance : une architecture compréhensible, des frontières claires entre les responsabilités, des tests qui protègent les comportements essentiels, des logs exploitables, une documentation qui explique les décisions importantes et des déploiements réversibles. Ce sont les tenons et les plaques de base du projet. Ils ne sont pas toujours visibles dans la démo, mais ils déterminent ce que l’on pourra reconstruire ensuite.

Le code le plus intelligent n’est pas forcément celui qui impressionne le plus. C’est souvent celui qu’une autre personne peut relire, modifier et déployer sans avoir peur de provoquer une réaction en chaîne.

## Réapprendre à expérimenter sans renoncer à l’exigence

Le développement moderne demande paradoxalement deux attitudes que l’on oppose trop souvent : l’audace d’essayer et la discipline de vérifier.

Il faut essayer une nouvelle approche quand elle peut simplifier un problème. Il faut utiliser une bibliothèque plutôt que réécrire inutilement une solution connue. Il faut parfois produire un prototype en une journée pour savoir si l’idée mérite trois semaines de travail. Et il faut accepter de démonter ce prototype s’il ne passe pas l’épreuve du réel.

Mais il faut aussi savoir dire non. Non à une dépendance de plus sans raison. Non à un morceau de code généré et incompris. Non à une démonstration qui contourne tous les vrais cas métier. Non au « ça marche chez moi » qui devient trop facilement une stratégie de livraison.

Cette exigence n’est pas un frein à la créativité. Elle lui donne une direction.

Un enfant invente librement avec ses LEGO parce qu’il connaît progressivement les contraintes des pièces : ce qui s’emboîte, ce qui tient, ce qui bloque une porte, ce qui rend une construction trop fragile. Plus il apprend, plus il peut imaginer grand. Pour un développeur, c’est la même chose. Les fondamentaux techniques ne limitent pas l’usage de l’IA, des frameworks ou des outils no-code. Ils permettent de les utiliser sans devenir dépendant de résultats que l’on ne comprend pas.

## Le métier ne disparaît pas : il se déplace vers le jugement

Le développeur de demain écrira probablement moins de code répétitif qu’il y a dix ans. Mais il devra prendre davantage de décisions : quelles briques réutiliser, quels compromis accepter, quelles parties automatiser, quels risques encadrer et à quel moment arrêter d’itérer pour livrer.

Il devra aussi mieux communiquer. Car dans un monde où produire une première version devient très rapide, la valeur se déplace vers la capacité à clarifier un besoin flou, rendre des choix explicites et faire circuler la compréhension entre les personnes, les outils et les systèmes.

Ce n’est pas une diminution du métier. C’est une élévation de son niveau de responsabilité.

La grande boîte de LEGO est donc une bonne image du développement actuel, à condition de ne pas la prendre pour une caricature. Les briques sont plus nombreuses, les constructions plus ambitieuses et les conséquences d’une erreur bien plus importantes. Mais l’énergie de départ reste la même : prendre un problème, imaginer une première forme, essayer de la construire et apprendre de ce qui ne marche pas encore.

## Construire mieux après chaque essai

Le développement n’est pas une course pour produire du code le plus vite possible. C’est un travail de construction continue.

Nous assemblons des briques existantes, nous en créons certaines quand il le faut, nous testons les liens entre elles et nous recommençons lorsque la réalité nous montre une meilleure voie. L’IA accélère cette boucle, mais elle ne supprime ni la nécessité de comprendre, ni celle de choisir, ni celle d’assumer.

Au fond, le bon développeur n’est pas celui qui ne casse jamais rien. C’est celui qui sait distinguer ce qui peut être expérimenté de ce qui doit être protégé, qui apprend vite de chaque essai et qui laisse derrière lui une construction plus solide que la précédente.

Comme devant une immense boîte de LEGO, la question n’est pas de savoir si l’on possède assez de pièces. La question est de savoir ce que l’on veut bâtir, et si l’on est prêt à reconstruire intelligemment jusqu’à ce que cela tienne vraiment.

---

### [The Outline Mode Might Be the Best Command for Developing with AI](https://nicolas-dabene.fr/en/blog/the-outline-mode-might-be-the-best-command-for-developing-with-ai/)
Published: 2026-09-26 | Language: EN | Topics: Developpement & architecture, Agents IA, Architecture, Automatisation, Intelligence artificielle, LLM & modeles, PrestaShop, Securite

**TL;DR** — A coding agent can turn a vague request into a coherent implementation in minutes. But coherence does not make it the right solution. Plan mode makes assumptions visible, checks constraints and helps choose a direction before those decisions become code someone has to maintain.

Asking an agent to start coding straight away is tempting. In a few minutes, it can create a service, change a controller, update templates and add tests. You can see progress, sometimes even a working demo. But you still do not know whether the agent understood the requirement.

An incomplete request does not necessarily stop the agent. It leaves gaps for the agent to interpret. The agent fills them with assumptions, then turns those assumptions into code. That is where the problem begins: the result can be clean and well structured while still answering the wrong question.

## The first draft has become cheap to produce

Coding agents have lowered the cost of a first draft. They can inspect a repository, find the files that matter and propose an implementation quickly. That is a real gain. It simply moves the risk somewhere else.

The problem is no longer just whether we can produce the code. It is deciding what to build, where it belongs and which constraints it must respect. A request like “add support for X” often leaves important questions unanswered: What should happen at the edges? What data is available at this point in the system? Which versions need to be supported? Should the behavior be configurable? How should it be removed or rolled back?

When those answers are missing, the agent cannot infer the business context. It chooses a plausible interpretation and moves ahead. The further it goes, the more that interpretation becomes part of the architecture.

The resulting code is not necessarily bad. It may even be very coherent. It is simply built around a decision nobody has validated yet.

## What I ask for in plan mode

For me, plan mode is not a formality before the “real” work. I ask the agent not to change any code during this phase. First, it restates the requirement. Then it inspects the existing code, separates what it has verified from what it is assuming, and flags the information that is still missing.

I also ask it to surface the choices that could shape the implementation: which files or services are involved, compatibility requirements, dependencies, data being handled, risks and ways to verify the result. If there are several reasonable approaches, it should describe them and explain their trade-offs.

Multiple-choice questions help bring out decisions we have not yet put into words. Should we prioritize compatibility with the existing system, simplicity, performance or future change? Which behavior is non-negotiable? The agent can help clarify these choices, but we still make the decision.

The point is not to create another document. It is to review the reasoning, challenge an assumption and change direction before that direction has spread across several files.

## A PrestaShop hook can shape the whole implementation

Consider a common case: adding a feature to a PrestaShop module. Choosing a hook can look like a small technical detail. In practice, it determines when the code runs, in which context, with what data and across which target versions. It can also affect the theme, caching, interactions with other modules and performance.

If the agent chooses a hook before checking those constraints, it can build the whole feature around the wrong entry point. That may become clear later: the required data is not available there, behavior differs between PrestaShop versions, or the theme integration does not match the requirement.

At that point, we may need to do more than change one method. We might have to move the logic, revisit a service, update a template and redo the tests. We also need to check the module’s installation and uninstall paths: a registered hook or obsolete configuration can be left behind after the implementation changes.

A useful plan checks the entry point before implementation begins. Does the hook exist in the versions we need to support? Does it provide the right context? Is it the right place for this responsibility? These questions are quick to answer before coding. They cost more once several components depend on the answer.

## Follow-up prompts do not replace scoping

Once coding has started, we can always ask the agent to “move this logic,” “add this rule” or “keep this case compatible.” Those exchanges are part of development. The problem starts when they are used to compensate for a decision that was never examined in the first place.

The agent can update the file we point to and adjust nearby code. That does not guarantee it will find everything that should be removed, moved or tested again. A series of locally reasonable changes can make the whole feature harder to understand.

When corrections start to pile up, it can be better to stop adding instructions and revisit the original question: is this still the right structure? What should be removed or rebuilt cleanly?

## Avoiding AI bloat

I use **AI bloat** to describe the accumulation of plausible code whose need has never been established: an abstraction introduced too early, an extra dependency, a configuration option nobody uses, or a service added because it seemed useful to the agent.

This code is not always bad. Often it is perfectly reasonable, which makes it easy to approve. But every file and mechanism we add will have to be understood, tested and maintained.

A plan lets us ask the question before creating anything: why does this responsibility need to exist? Why is this dependency necessary? Why do we need this configuration or caching mechanism? If the answer is still vague, it is better to clarify the need before adding the solution.

The goal is not to count lines or reject every abstraction. It is to avoid mistaking a complete solution for a useful one.

## A validated plan also gives us a way to verify the result

A reviewed and approved plan gives us a reference point during code review. We can check whether the implementation meets the original requirement, respects compatibility constraints and follows the decisions made at the start. We do not stop at “it compiles” or “the demo works.”

The plan also helps define the tests. If it identifies edge cases, target versions and acceptance criteria, those details can guide validation. Without that reference, we often test only the happy path that drove the implementation.

The faster agents produce code, the more clearly we need to know what we are checking. A fast first draft does not remove the need to understand what was added or why.

## Before implementation, choose a direction

Plan mode does not replace experience or developer responsibility. An agent can help examine the requirement and make choices visible. We still have to decide whether the assumptions hold and whether the plan is worth implementing.

My rule is simple: before I let an agent change code, I want to understand the requirement it has taken from my request, the constraints it has verified, the ones it is assuming and how we will validate the result. If an important point is still unclear, the code waits.

The first prompt for a feature does not always need to ask for an implementation. It can ask the agent to think, inspect the existing code and challenge the direction first. Once the plan is approved, the next challenge is to control execution and verify what the agent produces. Without a clear direction, the best safeguards will only catch later a mistake we could have avoided at the start.

---

### [Le mode plan est peut-être la meilleure commande pour développer avec une IA](https://nicolas-dabene.fr/blog/le-mode-plan-est-peut-etre-la-meilleure-commande-pour-developper-avec-une-ia/)
Published: 2026-09-26 | Language: FR | Topics: Developpement & architecture, Agents IA, Architecture, Automatisation, Intelligence artificielle, LLM & modeles, PrestaShop, Securite

**TL;DR** — Un agent peut transformer une demande floue en une implémentation cohérente en quelques minutes. Mais cohérente ne veut pas dire adaptée. Le mode plan sert à rendre visibles les hypothèses, vérifier les contraintes et choisir une direction avant que ces décisions ne deviennent des fichiers à maintenir.

Demander à un agent de coder tout de suite, c’est tentant. En quelques minutes, il peut créer un service, modifier un contrôleur, toucher aux templates et ajouter des tests. On voit du mouvement, parfois même une démo. Mais on ne sait pas encore si l’agent a bien compris le besoin.

Une demande incomplète ne l’arrête pas forcément. Elle lui laisse des zones à interpréter. L’agent les remplit avec des hypothèses, puis les transforme en code. C’est là que le problème commence : le résultat peut être propre, bien rangé et pourtant répondre à la mauvaise question.

## Le premier jet est devenu très facile à produire

Les agents ont réduit le coût du premier jet. Ils savent explorer un dépôt, repérer les fichiers concernés et proposer une implémentation en peu de temps. Ce gain est réel. Il déplace simplement le risque.

Le problème n’est plus seulement de réussir à produire le code. C’est de décider quoi produire, où le placer et quelles contraintes respecter. Une demande comme « ajoute la gestion de X » laisse souvent plusieurs questions sans réponse : que se passe-t-il dans les cas limites ? Quelles données sont disponibles à cet endroit du système ? Quelles versions faut-il prendre en charge ? Faut-il rendre le comportement configurable ? Comment le désinstaller ou revenir en arrière ?

Quand ces réponses manquent, l’agent ne peut pas deviner le contexte métier. Il choisit une interprétation plausible et avance. Plus il avance, plus cette interprétation s’installe dans l’architecture.

Le code qui en résulte n’est pas nécessairement mauvais. Il peut même être très cohérent. Il repose simplement sur une décision que personne n’a encore validée.

## Ce que je demande pendant le mode plan

Pour moi, le mode plan n’est pas une formalité avant le « vrai » travail. Je demande à l’agent de ne pas modifier le code pendant cette phase. D’abord, il reformule le besoin. Ensuite, il inspecte l’existant, sépare ce qu’il a vérifié de ce qu’il suppose et relève les informations qui manquent.

Je lui demande aussi de montrer les choix qui auront un impact sur la suite : fichiers ou services concernés, compatibilité, dépendances, données manipulées, risques et façons de vérifier le résultat. S’il existe plusieurs approches raisonnables, il doit les présenter avec leurs compromis.

Les questions à choix multiples aident à faire émerger les décisions qu’on n’avait pas encore formulées. Faut-il privilégier la compatibilité avec l’existant, la simplicité, la performance ou l’évolution future ? Quel comportement doit rester non négociable ? L’agent peut éclairer ces choix, mais c’est à nous de décider.

Le but n’est pas d’obtenir un document de plus. C’est de pouvoir relire le raisonnement, contester une hypothèse et corriger la direction avant qu’elle ne soit déjà répartie dans plusieurs fichiers.

## Un hook PrestaShop peut engager toute l’implémentation

Prenons un cas concret : ajouter une fonctionnalité à un module PrestaShop. Le choix du hook peut sembler n’être qu’un détail technique. En pratique, il détermine quand le code s’exécute, dans quel contexte, avec quelles données et selon les versions ciblées. Il peut aussi avoir des conséquences sur le thème, le cache, les interactions avec d’autres modules et les performances.

Si l’agent choisit le hook avant d’avoir vérifié ces contraintes, il peut bâtir toute la fonctionnalité autour du mauvais point d’entrée. On s’en rend compte plus tard : les données utiles ne sont pas disponibles à cet endroit, le comportement diffère selon la version de PrestaShop ou l’intégration au thème ne correspond pas au besoin.

À ce stade, on ne change pas forcément une seule méthode. Il faut peut-être déplacer la logique, revoir un service, adapter un template et reprendre les tests. Il faut aussi vérifier l’installation et la désinstallation du module : un hook enregistré ou une configuration devenue inutile peut rester en place après le changement.

Un plan utile fait donc vérifier le point d’entrée avant l’implémentation : le hook existe-t-il dans les versions visées ? Fournit-il le contexte nécessaire ? Est-ce bien le bon endroit pour porter cette responsabilité ? Ces questions sont rapides à traiter avant de coder. Elles coûtent davantage une fois que plusieurs composants dépendent de la réponse.

## Les corrections successives ne remplacent pas le cadrage

Une fois le code commencé, on peut toujours demander : « déplace cette logique », « ajoute cette règle » ou « garde la compatibilité avec ce cas ». Ces échanges font partie du développement. Le problème, c’est quand ils servent à compenser une décision de départ qui n’a jamais été examinée.

L’agent peut corriger le fichier qu’on lui montre et adapter ce qui l’entoure. Cela ne garantit pas qu’il va repérer tout ce qui doit disparaître, être déplacé ou être retesté. Une suite de retouches localement raisonnables peut rendre l’ensemble plus difficile à comprendre.

Quand les corrections s’accumulent, il faut parfois arrêter d’ajouter des consignes et revenir à la question de départ : est-ce encore la bonne structure ? Qu’est-ce qui doit être supprimé ou repris proprement ?

## Éviter l’AI bloat

J’appelle **AI bloat** l’accumulation de code plausible, mais dont le besoin n’a jamais été démontré : une abstraction créée trop tôt, une dépendance supplémentaire, une option de configuration qui ne sert à rien, ou un service ajouté parce qu’il semblait utile à l’agent.

Ce code n’est pas toujours mauvais. C’est même souvent du code raisonnable, et c’est ce qui le rend facile à laisser passer. Pourtant, chaque fichier et chaque mécanisme ajouté devra être compris, testé et maintenu.

Le plan aide à poser la question avant la création : pourquoi cette responsabilité doit-elle exister ? Pourquoi cette dépendance est-elle nécessaire ? Pourquoi faut-il cette configuration ou ce mécanisme de cache ? Si la réponse reste vague, mieux vaut clarifier le besoin avant d’ajouter la solution.

Le but n’est pas de compter les lignes ni de refuser toute abstraction. C’est de ne pas confondre une solution complète avec une solution utile.

## Un plan validé sert aussi à vérifier le résultat

Un plan relu et validé donne un point de comparaison pendant la revue. On peut vérifier que l’implémentation respecte le besoin, les contraintes de compatibilité et les décisions prises au départ. On ne s’arrête pas à « ça compile » ou « la démo fonctionne ».

Il aide aussi à définir les tests. Si le plan a identifié les cas limites, les versions concernées et les critères d’acceptation, ces éléments peuvent guider la validation. Sans cette référence, on teste souvent surtout le scénario heureux qui a servi à construire la fonctionnalité.

Plus les agents produisent vite, plus il faut savoir ce qu’on cherche à vérifier. La vitesse du premier jet ne dispense pas de comprendre ce qui a été ajouté ni pourquoi.

## Avant l’exécution, il faut une direction

Le mode plan ne remplace ni l’expérience ni la responsabilité du développeur. L’agent peut aider à examiner le besoin et à rendre les choix visibles ; c’est toujours à nous de décider si les hypothèses tiennent et si le plan mérite d’être exécuté.

Ma règle est simple : avant de laisser l’agent modifier le code, je veux comprendre le besoin qu’il a retenu, les contraintes qu’il a vérifiées, celles qu’il suppose et la manière dont on validera le résultat. Si un point important reste flou, le code attend.

Le premier prompt d’une fonctionnalité n’a donc pas toujours besoin de demander une implémentation. Il peut commencer par demander à l’agent de réfléchir, d’inspecter et de challenger la direction. Une fois le plan validé, reste à encadrer son exécution et à vérifier ce qu’il produit. Mais sans direction claire, les meilleurs contrôles ne feront que détecter plus tard une erreur qu’on aurait pu éviter au départ.

---

### [A 30-Day Program to Learn Coding with AI](https://nicolas-dabene.fr/en/blog/a-30-day-program-to-learn-coding-with-ai/)
Published: 2026-09-19 | Language: EN | Topics: Intelligence artificielle, Agents IA, API, Architecture, Automatisation, LLM & modeles, Open source, Pédagogie

> "Learning to Code with AI" Series — Article 7/7

## TL;DR

In thirty days, the goal isn’t to become a senior developer or produce a perfect dashboard. The goal is to learn how to evolve the AI’s role: first as a teacher, then as a reviewer, next as a debugging partner, and finally as an executor under supervision. By the end, you should be able to explain, verify, and redo part of what you’ve built.

## The mini-dashboard is just a pretext

Claude Code or Codex can generate a mini-dashboard on the first day. A few metrics, React cards, a simulated API call, and tests: all of this is within reach of a good prompt.

But will you be able to evolve it by the thirtieth day?

That’s the question that matters. Because a project only becomes interesting when a piece of data is missing, a test breaks, a business rule changes, or another developer needs to understand what was done. The generated code is just the beginning of the story. The real skill is being able to continue when the story gets messy.

The following program is based on the mini-dashboard from this series: TypeScript, React, and Next.js, a few server metrics, a simulated API, valid or invalid data, and useful tests. If you prefer another topic, just keep the same progression. A task manager, a profile page, or a small business tool can work just as well.

Plan for between forty-five and ninety minutes per day. If you don’t have that time, spread the days out. Consistency is more important than the schedule. Also, keep a very short note after each session: what you tried, what blocked you, the help you asked for, and what you can now explain without reopening the conversation with the AI.

## First week: the AI explains, you write

The first week might feel frustrating: the agent is allowed to explain, ask questions, and review, but not take over the keyboard. This is intentional.

Start by writing down the dashboard’s requirements and its limitations. It displays the status of a service, CPU usage, memory, and disk space. It must handle loading, an API error, and invalid data. It doesn’t need real authentication, a database, or real-time graphs. Ask the agent to identify ambiguities. Don’t ask it for the project yet.

Next, initialize Next.js and take the time to understand the created directory structure. What is the `app` folder for? Where does a component live? What’s the difference between data declared in a type and data actually received from an API? You can verify your answers in the [Next.js documentation](https://nextjs.org/docs), then ask the agent to correct only what’s important.

Write your own `MetricCard` component, powered by simulated data. It doesn’t need to be elegant right away. The important thing is to be able to explain its props, its role, and what would happen if the value were missing. At the end of the week, recreate a small card from scratch, without assistance, then ask the agent to ask you a few questions. The answers you struggle with become the focus for the following week.

## Second week: you try, the AI reviews

The second week introduces external data. This is an important moment because a TypeScript type doesn’t magically validate what an API sends at runtime.

Define a nominal response for your metrics, then invent a response where a value is missing and another where it’s impossible. Write the function to fetch the data yourself. Handle the case of an unsuccessful HTTP response. Then, show your attempt to the agent and ask what it actually does before asking for improvements.

Next, work on the interface states. What does the user see while loading? What do you tell them when the service is unavailable? What does an invalid value mean? Don’t silently replace unknown data with zero just to make the screen look cleaner. The interface must remain honest about what it knows and what it doesn’t.

At the end of the week, review the diff of all your changes. You can ask the agent to point out out-of-scope files, mixed responsibilities, and unnecessary duplications. But start by doing your own review. It’s this first pass that turns the tool into a reviewer rather than a judge.

## Third week: you drive the changes

The third week is when the agent starts writing more. Not because it’s become more reliable, but because you now have a framework to control what it does.

Before adding a test for the CPU card, write down the expected behavior. A valid value should be displayed with its unit. Zero should remain valid. An out-of-bounds value should be visible as an anomaly, not silently converted. An API error shouldn’t make the whole page disappear. This work prepares the test strategy before the implementation influences it.

You can then assign the agent a limited task, provided it starts with a plan. It should tell you which files are affected, the tests planned, and the validation commands. You approve the scope. Then, you read the final diff and verify that a test fails if you intentionally break the behavior it’s supposed to protect.

Also, introduce a controlled bug. For example, let a `null` metric slip through to the component. Formulate your hypothesis before asking for help. Observe the raw response, the value after validation, and what’s received by the render. The agent can suggest two probable causes and an experiment to distinguish between them. Keep track of what actually resolved the issue. You’ll learn something more valuable than a fix: a diagnostic method.

End this week with an agent-free session. Add a new metric using the documentation and what you’ve already built. This isn’t a test. It’s a way to check that you can still act without prompts when the context becomes less comfortable.

## Fourth week: the agent executes under supervision

The final week isn’t about delegating the entire project. It’s about delegating small parts with clear responsibilities.

Write the stable rules of the repository in `AGENTS.md` for Codex or `CLAUDE.md` for Claude Code: the commands that must be run, the architecture to follow, conventions, and key checks. Don’t turn this file into a fifty-page constitution. It should remind you of the decisions you don’t want to repeat in every conversation.

Next, pick a skill that seems relevant and inspect it before using it. See what it does, what it assumes, the scripts it runs, and whether it truly fits your project. The goal isn’t to accumulate skills. The goal is to know how to give the agent useful context without adding conflicting rules.

You can then assign it the task of adding the disk metric or a small, well-defined improvement. Require a plan, approve the affected files, read the diff, and run the validations. You can also ask for two architectural approaches with their trade-offs. Reject an abstraction if the need doesn’t justify it. A more complex solution isn’t automatically a more mature one.

The last few days are for documenting and demonstrating. Write the README yourself: installation, commands, architecture, limitations, and decisions made. Have the agent review it. Then, present your dashboard as if it were a technical review. Explain the data flow, error states, tests, and an architectural trade-off. You don’t need to be perfect. You just need to be able to say what you know, what’s still uncertain, and how you’d verify it.

## What you should be able to do by day 30

At the end of the program, the best indicator isn’t the size of your repository or the number of lines generated. It’s your ability to modify a metric without regenerating everything, to explain why data is validated, to read a diff before accepting it, and to turn an error into a testable hypothesis.

You should also be able to distinguish between what’s actually tested and what’s merely assumed. This distinction might seem almost administrative at first. Yet, it’s one of the key differences between getting code and owning software.

You won’t be done learning after thirty days. No one becomes a senior developer in a month, with or without AI. However, you will have changed the nature of your relationship with the tool. You won’t use it just to avoid difficulty. You’ll use it to understand faster, get better feedback, and advance decisions you can still explain.

---

### [Un programme de 30 jours pour apprendre à coder avec l’IA](https://nicolas-dabene.fr/blog/un-programme-de-30-jours-pour-apprendre-a-coder-avec-lia/)
Published: 2026-09-19 | Language: FR | Topics: Intelligence artificielle, Agents IA, API, Architecture, Automatisation, LLM & modeles, Open source, Pédagogie

> Série « Apprendre à coder avec l’IA » — Article 7/7

## TL;DR

En trente jours, l’objectif n’est pas de devenir senior ni de produire un dashboard parfait. L’objectif est d’apprendre à faire évoluer le rôle de l’IA : d’abord professeur, ensuite reviewer, puis partenaire de débogage et enfin exécutant sous contrôle. À la fin, tu dois pouvoir expliquer, vérifier et refaire une partie de ce que tu as construit.

## Le mini-dashboard n’est qu’un prétexte

Claude Code ou Codex peut générer un mini-dashboard dès le premier jour. Quelques métriques, des cartes React, un appel API simulé et des tests : tout cela est à portée d’un bon prompt.

Mais est-ce que tu sauras le faire évoluer au trentième jour ?

C’est la question qui compte. Parce qu’un projet ne devient intéressant qu’au moment où une donnée manque, qu’un test casse, qu’une règle métier change ou qu’un autre développeur doit comprendre ce qui a été fait. Le code généré est le début de l’histoire. La compétence, c’est de pouvoir continuer quand l’histoire devient moins propre.

Le programme qui suit s’appuie sur le mini-dashboard de cette série : TypeScript, React et Next.js, quelques métriques de serveur, une API simulée, des données valides ou invalides et des tests utiles. Si tu préfères un autre sujet, garde simplement la même progression. Un gestionnaire de tâches, une page de profil ou un petit outil métier peuvent très bien faire l’affaire.

Prévois entre quarante-cinq et quatre-vingt-dix minutes par jour. Si tu n’as pas ce temps, étale les journées. La régularité est plus importante que le calendrier. Conserve aussi une note très courte après chaque session : ce que tu as tenté, ce qui t’a bloqué, l’aide demandée et ce que tu sais désormais expliquer sans ouvrir la conversation avec l’IA.

## Première semaine : l’IA explique, tu écris

La première semaine peut sembler frustrante : l’agent a le droit d’expliquer, de poser des questions et de relire, mais pas de prendre le clavier à ta place. C’est volontaire.

Commence par écrire le besoin du dashboard avec ses limites. Il affiche l’état d’un service, l’utilisation CPU, la mémoire et l’espace disque. Il doit gérer un chargement, une erreur API et une donnée invalide. Il n’a pas besoin d’authentification réelle, de base de données ou de graphiques temps réel. Demande à l’agent de relever les ambiguïtés. Ne lui demande pas encore le projet.

Initialise ensuite Next.js et prends le temps de comprendre l’arborescence créée. À quoi sert le dossier `app` ? Où vit un composant ? Quelle différence entre une donnée déclarée dans un type et une donnée réellement reçue depuis une API ? Tu peux vérifier tes réponses dans la [documentation de Next.js](https://nextjs.org/docs), puis demander à l’agent de corriger uniquement ce qui est important.

Écris toi-même une première carte `MetricCard`, alimentée avec une donnée simulée. Elle n’a pas besoin d’être élégante dès le départ. L’important est de pouvoir expliquer ses props, son rôle et ce qui se passerait si la valeur était absente. En fin de semaine, recrée une petite carte depuis une page blanche, sans assistance, puis demande à l’agent de te poser quelques questions. Les réponses qui te résistent deviennent le programme de la semaine suivante.

## Deuxième semaine : tu tentes, l’IA relit

La deuxième semaine introduit les données externes. C’est un moment important, parce qu’un type TypeScript ne valide pas magiquement ce qu’une API t’envoie à l’exécution.

Définis une réponse nominale pour tes métriques, puis invente une réponse où une valeur est absente et une autre où elle est impossible. Écris toi-même la fonction qui récupère les données. Gère le cas d’une réponse HTTP non réussie. Ensuite, montre ta tentative à l’agent et demande-lui ce qu’elle fait réellement avant de lui demander une amélioration.

Travaille ensuite les états de l’interface. Que voit l’utilisateur pendant le chargement ? Que lui dis-tu lorsque le service est indisponible ? Que signifie une valeur invalide ? Ne remplace pas silencieusement une donnée inconnue par zéro juste pour rendre l’écran plus propre. L’interface doit rester honnête sur ce qu’elle sait et ce qu’elle ne sait pas.

À la fin de la semaine, relis le diff de tous tes changements. Tu peux demander à l’agent de signaler les fichiers hors périmètre, les responsabilités mélangées et les duplications inutiles. Mais commence par faire ta propre revue. C’est cette première lecture qui transforme l’outil en relecteur plutôt qu’en arbitre.

## Troisième semaine : tu pilotes les modifications

La troisième semaine est celle où l’agent commence à écrire davantage. Pas parce qu’il est devenu plus fiable qu’avant, mais parce que tu as maintenant un cadre pour contrôler ce qu’il fait.

Avant d’ajouter un test pour la carte CPU, rédige le comportement attendu. Une valeur valide doit être affichée avec son unité. Zéro doit rester valide. Une valeur hors limites doit être visible comme une anomalie, pas convertie sans bruit. Une erreur API ne doit pas faire disparaître toute la page. Ce travail prépare la stratégie de test avant que l’implémentation ne l’influence.

Tu peux alors confier à l’agent une tâche limitée, à condition qu’il commence par un plan. Il te dit les fichiers concernés, les tests prévus et les commandes de validation. Tu valides le périmètre. Puis tu lis le diff final et tu vérifies qu’un test échoue bien si tu casses volontairement le comportement qu’il est censé protéger.

Introduis aussi un bug contrôlé. Par exemple, laisse passer une métrique `null` jusqu’au composant. Formule ton hypothèse avant de demander de l’aide. Observe la réponse brute, la valeur après validation et celle reçue par le rendu. L’agent peut proposer deux causes probables et une expérience pour les départager. Garde la trace de ce qui a réellement tranché. Tu apprends alors quelque chose de plus précieux qu’une correction : une méthode de diagnostic.

Termine cette semaine par une session sans agent. Ajoute une nouvelle métrique en t’appuyant sur la documentation et sur ce que tu as déjà construit. Ce n’est pas un examen. C’est une manière de vérifier que tu peux encore agir sans prompt lorsque le contexte devient moins confortable.

## Quatrième semaine : l’agent exécute sous contrôle

La dernière semaine ne consiste pas à déléguer tout le projet. Elle consiste à déléguer de petites parties avec une responsabilité claire.

Écris les règles stables du dépôt dans `AGENTS.md` pour Codex ou `CLAUDE.md` pour Claude Code : les commandes qui doivent être lancées, l’architecture à respecter, les conventions et les points à vérifier. Ne transforme pas ce fichier en constitution de cinquante pages. Il doit rappeler les décisions qui t’évitent de les répéter à chaque conversation.

Prends ensuite un skill qui semble pertinent et inspecte-le avant de l’utiliser. Regarde ce qu’il fait, ce qu’il suppose, les scripts qu’il lance et si cela correspond vraiment à ton projet. L’objectif n’est pas d’accumuler des skills. L’objectif est de savoir donner un contexte utile à l’agent sans ajouter de règles qui se contredisent.

Tu peux alors lui confier l’ajout de la métrique disque, ou une petite amélioration bien définie. Exige le plan, valide les fichiers concernés, lis le diff et exécute les validations. Tu peux aussi lui demander deux pistes d’architecture avec leurs compromis. Refuse une abstraction si le besoin ne la justifie pas. Une solution plus complexe n’est pas automatiquement une solution plus mature.

Les derniers jours servent à documenter et à démontrer. Écris toi-même le README : installation, commandes, architecture, limites et décisions prises. Fais-le relire par l’agent. Puis présente ton dashboard comme lors d’une revue technique. Explique le flux de données, les états d’erreur, les tests et un compromis d’architecture. Tu n’as pas besoin d’être parfait. Tu dois être capable de dire ce que tu sais, ce qui reste incertain et comment tu le vérifierais.

## Ce que tu dois pouvoir faire au trentième jour

À la fin du programme, le meilleur indicateur n’est pas la taille de ton dépôt ni le nombre de lignes générées. C’est ta capacité à modifier une métrique sans tout régénérer, à dire pourquoi une donnée est validée, à lire un diff avant de l’accepter et à transformer une erreur en hypothèse vérifiable.

Tu dois aussi pouvoir distinguer ce qui a été réellement testé de ce qui est simplement supposé. Cette nuance paraît presque administrative au début. C’est pourtant l’une des différences entre obtenir du code et assumer un logiciel.

Tu n’auras pas fini d’apprendre après trente jours. Personne ne devient senior en un mois, avec ou sans IA. En revanche, tu auras changé la nature de ton rapport à l’outil. Tu ne l’utiliseras plus uniquement pour éviter la difficulté. Tu l’utiliseras pour comprendre plus vite, recevoir de meilleurs retours et faire avancer des décisions que tu sais encore expliquer.

L’IA peut produire énormément de code. La valeur du développeur reste sa capacité à comprendre le système, choisir une direction et répondre de ce qui part en production.

---

### [Debugging with AI Without Losing Your Ability to Think](https://nicolas-dabene.fr/en/blog/debugging-with-ai-without-losing-your-ability-to-think/)
Published: 2026-09-12 | Language: EN | Topics: Developpement & architecture, Agents IA, API, Architecture, Automatisation, Intelligence artificielle, LLM & modeles, Pédagogie

> "Learning to Code with AI" Series — Article 6/7

## TL;DR

Copying an error into an agent and accepting the first fix is quick. It doesn’t necessarily teach you how to debug. The right loop involves reading the symptom, reproducing the problem, formulating a hypothesis, observing what confirms or rules it out, then asking the AI to challenge your diagnosis.

## Making an Error Disappear Isn’t Always Solving It

An error appears in the terminal or browser. The reflex has become almost mechanical: copy the message into Claude Code or Codex, ask for a fix, accept the suggested change, and move on.

The error disappears. You feel like you’ve debugged.

Sometimes, that’s true. Often, you’ve only moved the problem or masked its symptom.

Debugging isn’t a collection of fixes. It’s a way to reduce uncertainty until you understand why the system behaves that way. This method may seem slower when you only look at the time spent on the first error. It becomes much faster when a similar error appears the following week and you already recognize its family.

Let’s take a realistic situation in our mini-dashboard. The API returns a response where the CPU metric is `null`. The component, however, assumes it always receives a number and attempts to format it. The page crashes.

The quickest fix might be to replace the missing value with zero. The screen no longer crashes. But the dashboard now shows a CPU load of 0%, when the data is actually unknown. Technically, the crash is gone. Functionally, you may have just created false information.

The problem, therefore, isn’t just the failing line. It could lie in the API contract, response validation, the type used, or how to display an unavailable state. This is precisely where human reasoning must remain present.

## Start with a Hypothesis, Not a Request for a Fix

Before asking the agent for help, take a few minutes to read the entire error. Look at the file, the line, the stack trace, and the exact steps to reproduce it. Then, try to articulate what you think is happening.

In our example, the hypothesis could be simple: *"The external response isn’t validated before reaching the component, so `cpu` can be null while the rendering expects a number."*

This statement doesn’t need to be correct. It just needs to be verifiable.

A hypothesis turns a vague error into an investigation. You then know what observation to look for: the raw API response, the value after validation, then the value received by the component. Each observation eliminates some possible causes. You no longer need to add logs everywhere or ask the AI to guess the entire architecture from an isolated stack trace.

The prompt changes completely:

```text
Here’s the error, the reproduction steps, and my hypothesis.

Do not modify any files.
First, evaluate my hypothesis. Indicate the most useful observation to confirm or rule it out.
Suggest at most two alternative causes, ranked by probability.
Distinguish observed facts from your deductions.
```

The agent is no longer a "fix" button. It becomes a second set of eyes. It can spot an overlooked lead, suggest a more discriminating observation, or save you from wasting an hour on an unlikely cause. But it works *with* your reasoning, not in place of it.

## Logs Aren’t a Strategy

When stuck, you often see a flurry of `console.log` statements. That’s understandable. A log gives the impression of taking action. Yet a log is only useful if it answers a question.

*"What value comes out of validation?"* is a useful question. *"Does the API call respond before rendering?"* is another. *"Let’s add logs in every file"* doesn’t reduce anything. It just adds noise where you might miss the important information.

An agent can help you instrument the code, but always ask it what question each addition is meant to clarify. Also ask it to flag sensitive data: a token, an email address, a full API response, or customer information has no place in production logs.

When the context allows, a breakpoint in a debugger is often more precise. It lets you observe a value at the exact moment it changes, instead of reconstructing the sequence afterward. The tool matters less than the discipline: observe one boundary at a time.

## A Fix Must Respect the Contract, Not Just the Symptom

Back to our missing CPU metric. The agent might suggest this:

```ts
const cpu = metrics.cpu ?? 0
```

This code is short. It may even seem cautious. But it makes a silent business decision: it conflates unavailable data with zero load.

The right fix depends on what the system actually promises. If `null` is an expected response, the interface should clearly show the measurement is unavailable. If this value should never occur, the response should be rejected at the boundary and the incident made visible. If it comes from an unstable API, you might need to preserve the last known value—but only if that rule is explicitly defined.

These are product and architecture decisions before they’re syntax decisions. The AI can suggest multiple treatments. It can’t silently choose the one that changes the meaning of the data.

After the fix, add a test that reproduces the scenario. Not just to check a "coverage" box, but because you want to prevent this same error from returning in another form. Then note, in a few lines, your initial hypothesis, the observation that settled it, and the safeguard you added. This record becomes a mental library. Over time, you recognize validation errors, asynchronous state issues, caching problems, configuration mistakes, or permission issues more quickly.

## Keep Some Moments Without Assistance

Avoiding AI for a short session isn’t a nostalgic exercise. It’s a resilience test.

Once or twice a week, take a small error and try to diagnose it alone for twenty minutes. You can check the documentation, use the debugger, write a test, or examine the diff. Only then ask the agent to review your approach or suggest a lead if you’re still stuck.

The goal isn’t to prove you can do everything without tools. No serious developer works that way. The goal is to maintain the ability to act when the agent lacks context, produces a confident but wrong answer, or is simply unavailable.

The more precise your diagnosis, the more effective the AI becomes. You give it a scope, facts, a hypothesis, and a question. It no longer has to invent the rest of the system. That’s the real gain: less guesswork, fewer cosmetic fixes, and an understanding that stays with you after the conversation.

In the final article, we’ll turn this method into a concrete 30-day progression.

---

### [Déboguer avec l’IA sans perdre sa capacité à réfléchir](https://nicolas-dabene.fr/blog/deboguer-avec-lia-sans-perdre-sa-capacite-a-reflechir/)
Published: 2026-09-12 | Language: FR | Topics: Developpement & architecture, Agents IA, API, Architecture, Automatisation, Intelligence artificielle, LLM & modeles, Pédagogie

> Série « Apprendre à coder avec l’IA » — Article 6/7

## TL;DR

Copier une erreur dans un agent et accepter la première correction est rapide. Cela ne t’apprend pas forcément à déboguer. La bonne boucle consiste à lire le symptôme, reproduire le problème, formuler une hypothèse, observer ce qui permet de la confirmer ou de l’écarter, puis demander à l’IA de challenger ton diagnostic.

## Faire disparaître une erreur n’est pas toujours la résoudre

Une erreur apparaît dans le terminal ou dans le navigateur. Le réflexe est devenu presque mécanique : copier le message dans Claude Code ou Codex, demander une correction, accepter la modification proposée et passer à la suite.

L’erreur disparaît. On a l’impression d’avoir débogué.

Parfois, c’est vrai. Souvent, on a seulement déplacé le problème ou masqué son symptôme.

Le débogage n’est pas une collection de correctifs. C’est une manière de réduire l’incertitude jusqu’à comprendre pourquoi le système se comporte ainsi. Cette méthode paraît plus lente quand on regarde uniquement le temps passé sur la première erreur. Elle devient beaucoup plus rapide lorsqu’une erreur voisine arrive la semaine suivante et que tu reconnais déjà sa famille.

Prenons une situation réaliste dans notre mini-dashboard. L’API renvoie une réponse où la métrique CPU vaut `null`. Le composant, lui, suppose qu’il reçoit toujours un nombre et tente de le formater. La page casse.

La correction la plus rapide pourrait être de remplacer la valeur manquante par zéro. L’écran ne plante plus. Mais le dashboard annonce maintenant une charge CPU à 0 %, alors que la donnée est inconnue. Techniquement, le crash a disparu. Fonctionnellement, on vient peut-être de créer une information fausse.

Le problème n’est donc pas seulement la ligne qui échoue. Il peut se situer dans le contrat de l’API, dans la validation de la réponse, dans le type utilisé ou dans la manière d’afficher un état indisponible. C’est précisément là que le raisonnement humain doit rester présent.

## Commencer par une hypothèse, pas par une demande de correction

Avant de solliciter l’agent, prends quelques minutes pour lire l’erreur en entier. Regarde le fichier, la ligne, la stack trace et les étapes exactes qui permettent de la reproduire. Ensuite, essaie de dire ce que tu crois comprendre.

Dans notre exemple, l’hypothèse peut être simple : « La réponse externe n’est pas validée avant d’arriver dans le composant, donc `cpu` peut être nul alors que le rendu attend un nombre. »

Cette phrase n’a pas besoin d’être correcte. Elle doit pouvoir être vérifiée.

Une hypothèse transforme une erreur vague en enquête. Tu sais alors quelle observation chercher : la réponse brute de l’API, la valeur après validation, puis la valeur reçue par le composant. Chaque observation élimine une partie des causes possibles. Tu n’as plus besoin d’ajouter des logs partout, ni de demander à l’IA de deviner toute l’architecture depuis une stack trace isolée.

Le prompt change complètement :

```text
Voici l’erreur, les étapes de reproduction et mon hypothèse.

Ne modifie aucun fichier.
Évalue d’abord mon hypothèse. Indique l’observation la plus utile pour la confirmer ou l’écarter.
Propose au maximum deux causes alternatives, classées par probabilité.
Distingue les faits observés de tes déductions.
```

L’agent n’est plus un bouton « corriger ». Il devient un second regard. Il peut repérer une piste oubliée, suggérer une observation plus discriminante ou t’éviter de perdre une heure sur une cause peu probable. Mais il travaille sur ton raisonnement, pas à sa place.

## Les logs ne sont pas une stratégie

Lorsqu’on bloque, on voit souvent apparaître une pluie de `console.log`. C’est compréhensible. Un log donne l’impression d’agir. Pourtant, un log n’est utile que s’il répond à une question.

« Quelle valeur sort de la validation ? » est une question utile. « Est-ce que l’appel API répond avant le rendu ? » en est une autre. « Mettons des logs dans tous les fichiers » ne réduit rien. Cela ajoute simplement du bruit dans lequel on risque de rater l’information importante.

Un agent peut t’aider à instrumenter le code, mais demande-lui toujours la question que chaque ajout est censé éclairer. Demande-lui aussi de signaler les données sensibles : un token, une adresse e-mail, une réponse complète d’API ou une information client n’a rien à faire dans des logs de production.

Quand le contexte s’y prête, un point d’arrêt dans un débogueur est souvent plus précis. Il te permet d’observer une valeur au moment exact où elle change, au lieu de reconstituer le déroulé après coup. L’outil importe moins que la discipline : observer une frontière à la fois.

## Une correction doit respecter le contrat, pas seulement le symptôme

Revenons à notre métrique CPU absente. L’agent peut suggérer ceci :

```ts
const cpu = metrics.cpu ?? 0
```

Ce code est court. Il peut même sembler prudent. Mais il prend une décision métier silencieuse : il confond une donnée indisponible avec une charge inexistante.

La bonne correction dépend de ce que le système promet réellement. Si `null` est une réponse attendue, l’interface doit afficher clairement que la mesure est indisponible. Si cette valeur ne devrait jamais arriver, la réponse doit être rejetée à la frontière et l’incident rendu visible. Si elle vient d’une API instable, il faut peut-être préserver la dernière valeur connue, mais uniquement si cette règle est explicitement définie.

Ce sont des décisions de produit et d’architecture avant d’être des décisions de syntaxe. L’IA peut proposer plusieurs traitements. Elle ne peut pas choisir discrètement celui qui change la signification de la donnée.

Après la correction, ajoute un test qui reproduit le scénario. Pas parce qu’il faut cocher une case « couverture », mais parce que tu veux empêcher cette même erreur de revenir sous une autre forme. Puis note, en quelques lignes, ton hypothèse de départ, l’observation qui a tranché et le garde-fou ajouté. Cette trace devient une bibliothèque mentale. Avec le temps, tu reconnais plus vite les erreurs de validation, d’état asynchrone, de cache, de configuration ou de permissions.

## Garder quelques moments sans assistance

Se priver d’IA pendant une courte session n’est pas un exercice nostalgique. C’est un test de résilience.

Une ou deux fois par semaine, prends une petite erreur et essaie de la diagnostiquer seul pendant vingt minutes. Tu peux consulter la documentation, utiliser le débogueur, écrire un test ou examiner le diff. Ensuite seulement, demande à l’agent une revue de ton approche ou une piste si tu restes bloqué.

L’objectif n’est pas de prouver que tu peux tout faire sans outil. Aucun développeur sérieux ne travaille ainsi. L’objectif est de conserver la capacité d’agir quand l’agent manque de contexte, produit une réponse très assurée mais fausse, ou n’est tout simplement pas disponible.

Plus ton diagnostic est précis, plus l’IA devient efficace. Tu lui donnes un périmètre, des faits, une hypothèse et une question. Elle n’a plus à inventer le reste du système. Voilà le vrai gain : moins de hasard, moins de corrections décoratives et une compréhension qui reste avec toi après la conversation.

Dans le dernier article, nous allons transformer cette méthode en progression concrète sur trente jours.