Comment Je Construis Reellement des Agents IA Qui Font le Travail

Il y a six mois, j'ai regarde un ingenieur faire la demo d'un agent IA qui reservait des reunions, redigeait des propositions et mettait a jour un CRM — le tout a partir d'un seul prompt. La sequence entiere a pris environ quatre-vingt-dix secondes. Le public a applaudi. Quelqu'un a demande "c'est reel ?" Le presentateur a souri et a dit oui.

Je suis rentre chez moi et j'ai essaye de construire la meme chose. Il m'a fallu trois semaines pour obtenir quelque chose qui fonctionnait a moitie. L'agent hallucinait des appels d'outils. Il perdait le contexte entre les etapes. Il appelait les mauvais endpoints d'API avec les mauvais parametres. A un moment, il a envoye un e-mail de test a un vrai client avec l'objet "TODO: fix this later."

Cette experience m'a appris quelque chose sur lequel je reviens sans cesse : l'ecart entre une demo d'agent IA et un agent IA qui fonctionne en production est enorme. Et presque personne ne parle de ce qui comble cet ecart.

J'ai recemment regarde l'analyse de Remy Gasill sur la maitrise des agents IA — un parcours veritablement complet qui couvre toute la stack, des modeles mentaux a l'architecture pratique. Cela a cristallise beaucoup de patterns que j'utilisais intuitivement en frameworks que je peux maintenant expliquer clairement. Ce qui suit est ma vision de ces concepts, filtree a travers des mois de construction d'agents avec Claude Code pour des projets reels, des clients reels et des erreurs reelles.

Ce qui m'a le plus surpris ? La partie la plus difficile de la construction d'agents IA utiles n'est pas l'IA. C'est tout ce qui entoure l'IA.

Les Modeles de Chat Ne Sont Pas des Agents (et la Confusion Vous Coute des Semaines)

Je dois clarifier cela en premier parce que le malentendu est tellement repandu qu'il est devenu le modele mental par defaut — et il est faux.

Quand la plupart des gens disent "j'utilise des agents IA," ils veulent dire qu'ils ouvrent ChatGPT ou Claude et tapent des questions. C'est un modele de chat. Un tres bon. Mais c'est fondamentalement une interaction a coup unique : vous demandez, il repond, vous demandez encore, il repond encore. Chaque echange est relativement isole. Le modele ne part pas faire des choses pour vous. Il repond.

Un agent est architecturalement different. Un agent recoit un objectif, le decompose en etapes, execute ces etapes en utilisant des outils, evalue les resultats et decide quoi faire ensuite — tout cela sans que vous tapiez un autre prompt. L'humain definit la destination. L'agent conduit.

Pensez-y de cette facon. Si vous demandez a un modele de chat de "configurer un nouveau projet Express.js avec TypeScript, ESLint et Prettier configures," il vous donnera une magnifique reponse expliquant chaque etape. Peut-etre meme des blocs de code que vous pouvez copier-coller. Mais vous devez encore creer les fichiers. Vous devez encore executer les commandes. Vous devez encore debugger les conflits de configuration entre ESLint et Prettier que le modele a oublie de mentionner.

Un agent tournant dans Claude Code ? Il cree le repertoire. Initialise le projet. Installe les dependances. Ecrit les fichiers de configuration. Lance le linter pour verifier que tout fonctionne. Corrige les deux conflits de configuration qu'il trouve. Fait un commit du resultat. Termine.

Cette difference — entre vous dire quoi faire et reellement le faire — c'est tout le changement de paradigme. Et cela change votre facon de penser chaque tache que vous deleguez a l'IA.

J'ai passe mon premier mois avec Claude Code en le traitant encore comme un modele de chat. Poser des questions. Lire les reponses. Executer manuellement les suggestions. Le moment ou j'ai commence a lui donner des objectifs au lieu de questions, ma productivite a change d'une maniere que je peux mesurer : des taches qui me prenaient 45 minutes ont commence a se terminer en moins de 10. Non pas parce que l'IA est devenue plus intelligente. Parce que j'ai arrete d'etre le goulet d'etranglement entre sa reflexion et son action.

Mais voila — un agent ne fonctionne que si son architecture sous-jacente est solide. Et cette architecture a un nom.

La Boucle de l'Agent : Observer, Penser, Agir

Tout agent IA fonctionnel fonctionne sur la meme boucle centrale. Remy Gasill l'appelle "observer, penser, agir," et cette formulation est la plus claire que j'ai vue. Une fois que vous comprenez cette boucle, vous comprenez pourquoi les agents reussissent ou echouent — et plus important encore, comment les debugger quand ils cassent.

Observer. L'agent absorbe du contexte. Cela inclut la tache originale, tous les fichiers qu'il a lus, les sorties d'outils des etapes precedentes, les messages d'erreur, l'etat de l'environnement. Tout ce que l'agent sait a cet instant vit dans sa fenetre de contexte. La qualite de cette phase d'observation determine tout ce qui suit.

Penser. Le LLM raisonne sur ce qu'il a observe. Qu'est-ce qui a ete accompli jusqu'ici ? Que reste-t-il ? Quelle est la prochaine etape logique ? Doit-il appeler un outil, demander des clarifications ou livrer un resultat final ? C'est la ou l'intelligence du modele compte reellement — et c'est la ou les modeles moins chers commencent a peiner sur les taches complexes.

Agir. L'agent execute un appel d'outil. Lire un fichier. Executer une commande terminal. Faire une requete API. Modifier du code. Quelle que soit l'action selectionnee par l'etape de raisonnement, l'agent l'execute. Le resultat de cette action alimente la phase d'observation, et la boucle continue.

Ce cycle se repete — parfois trois fois, parfois trente — jusqu'a ce que l'agent determine que la tache est terminee.

Voici ce qui m'a pris du temps a interioriser : la qualite de l'agent reside dans la boucle. Pas dans le modele. Pas dans les outils. Dans la boucle. Un modele mediocre avec une excellente ingenierie de contexte et des outils bien concus surpassera un modele brillant avec un contexte neglige et des outils mal definis. Je l'ai teste. J'ai execute la meme tache via Claude Opus 4.6 avec des fichiers de contexte mediocres versus Claude Sonnet avec un contexte soigneusement elabore. Sonnet a gagne. Systematiquement.

C'est pourquoi les trois concepts suivants — les harnesses, l'ingenierie de contexte et les skills — comptent autant. Ce sont tous des mecanismes pour faire fonctionner la boucle mieux.

Harnesses d'Agents : Le Cockpit ou Votre IA s'Assoit

La boucle de l'agent ne tourne pas dans le vide. Elle a besoin d'un environnement — un harness — qui gere l'execution de la boucle, fournit les outils, gere les permissions et presente l'interface avec laquelle vous interagissez. Pensez-y comme le cockpit d'un avion. Le LLM est le pilote. Le harness, c'est chaque instrument, surface de controle et systeme de securite entourant ce pilote.

J'ai travaille intensivement avec quatre harnesses, et chacun a sa personnalite.

Claude Code est mon outil quotidien. Natif du terminal, integration profonde avec le systeme de fichiers et git, permissions granulaires. Quand j'ai besoin d'un agent capable de raisonner sur un codebase entier et d'executer des changements en toute confiance, rien d'autre n'arrive a la cheville pour l'instant.

Codex d'OpenAI cree un environnement sandbox dans le cloud pour chaque tache — vos fichiers locaux restent intacts sauf si vous synchronisez explicitement les resultats. Excellent pour les equipes soucieuses du rayon d'impact. Le compromis, c'est la latence due a la creation de l'environnement.

OpenClaw est l'option open-source a surveiller. Base sur le terminal, extensible, porte par la communaute. Des aretes plus rugueuses que Claude Code, mais un controle maximal sur le comportement de l'agent.

Les agents Co-work (comme l'agent web Claude d'Anthropic) gerent les taches de longue duree. Lancez une requete, fermez le navigateur, revenez pour les resultats. Synthese de recherche, analyse de documents volumineux, workflows multi-etapes qui n'ont pas besoin d'interaction en temps reel.

Choisissez le harness qui correspond a votre facon de travailler. J'ai perdu deux semaines a essayer d'utiliser un agent web pour de l'iteration rapide de code avant de passer a Claude Code — et ma frustration a disparu du jour au lendemain. Il n'y a pas de meilleur choix universel, seulement le bon pour votre workflow.

Mais quel que soit le harness que vous choisissez, il y a un protocole qui devient rapidement le standard pour connecter les agents a des outils externes. Et si vous ne l'utilisez pas encore, vous construisez avec une main attachee dans le dos.

MCP : Le Port USB-C pour les Agents IA

Model Context Protocol — MCP — est une de ces choses qui semble ennuyeuse jusqu'a ce que vous compreniez ce qu'elle debloque vraiment. Ensuite, cela devient la piece la plus passionnante de la stack d'agents.

Voici le probleme que MCP resout. Disons que vous voulez que votre agent interagisse avec votre base de donnees. Sans MCP, vous ecririez du code personnalise : une fonction qui se connecte a PostgreSQL, execute une requete, formate les resultats et les renvoie a l'agent. Ensuite, vous voulez l'integration Slack. Plus de code personnalise. Puis Google Calendar. Plus de code personnalise. Puis votre API interne. Plus de code personnalise. Chaque integration est sur mesure, fragile et maintenue par vous seul.

MCP standardise cela. Il cree un protocole universel — pensez-y comme un port USB-C — auquel n'importe quel outil peut se brancher. Quelqu'un construit un serveur MCP pour PostgreSQL une fois, et chaque harness d'agent qui supporte MCP peut l'utiliser. Une autre personne en construit un pour Slack. Un autre pour Notion. Un autre pour votre CRM. L'agent ne se soucie pas de comment l'outil fonctionne en interne. Il l'appelle simplement via MCP et recoit des resultats structures en retour.

J'utilise actuellement des serveurs MCP pour GitHub, l'acces au systeme de fichiers et une API interne personnalisee que j'ai construite pour un projet client. Ajouter une nouvelle capacite a mon agent signifiait autrefois ecrire du code d'integration. Maintenant, cela signifie ajouter trois lignes a un fichier de configuration pointant vers un serveur MCP.

La configuration pratique ressemble a ceci dans Claude Code :

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Placez cela dans votre configuration .claude/, et soudain votre agent peut interroger des repos GitHub et des bases de donnees PostgreSQL aussi naturellement qu'il lit des fichiers. Pas de wrappers personnalises. Pas de code API fragile. Juste des outils, disponibles et prets.

L'ecosysteme MCP croit rapidement. Debut 2026, il existe des serveurs maintenus par la communaute pour des dizaines de services — bases de donnees, outils de communication, fournisseurs cloud, plateformes de gestion de projet. La qualite varie (certains sont excellents, d'autres sont des projets de week-end), mais la trajectoire est claire. MCP est en train de devenir la couche d'integration standard pour les agents IA.

Une note de securite que je veux signaler ici parce que c'est important : chaque serveur MCP que vous ajoutez elargit la surface d'attaque de votre agent. Un serveur MCP avec acces a la base de donnees signifie que votre agent peut lire — et potentiellement ecrire dans — votre base de donnees. Definissez les permissions de maniere stricte. Utilisez des connexions en lecture seule quand c'est possible. Ne donnez pas a votre agent les cles de la production a moins d'avoir serieusement reflechi a ce qui se passe quand il fait une erreur. Parce qu'il fera des erreurs. Les miens en ont certainement fait.

Cela nous amene a quelque chose d'aussi important que les outils que votre agent peut utiliser — et possiblement plus important : le contexte que votre agent recoit avant de commencer a travailler.

Ingenierie de Contexte : La Competence Que Personne N'Enseigne

Je pensais autrefois que l'ingenierie de prompts etait la competence limitante pour travailler avec l'IA. Ecrire de meilleurs prompts, obtenir de meilleurs resultats. Et c'est vrai — pour les modeles de chat. Pour les agents, le goulet d'etranglement est different : l'ingenierie de contexte.

L'ingenierie de contexte est la pratique de structurer ce qu'un agent sait avant et pendant l'execution. Ce n'est pas juste le prompt que vous tapez. Ce sont les fichiers que l'agent lit automatiquement. Les instructions de niveau projet qu'il ingere avant de traiter votre requete. La memoire qu'il porte des sessions precedentes. Les conventions qu'il suit sans qu'on les lui rappelle a chaque fois.

Dans Claude Code, l'ingenierie de contexte vit principalement dans deux endroits : les fichiers CLAUDE.md et agents.md.

Votre fichier CLAUDE.md est la premiere chose que Claude Code lit quand il demarre une session dans n'importe quel repertoire. Le mien contient les conventions specifiques au projet, les decisions architecturales, les standards de code et des instructions explicites sur ce qu'il ne faut PAS faire. Cette derniere partie — les contraintes negatives — s'est averee etonnamment importante. Sans elles, les agents font des suppositions raisonnables-mais-fausses en permanence.

Voici un exemple simplifie d'un de mes projets Laravel :

# CLAUDE.md

## Project Architecture
- Laravel 11 with Inertia.js + React 19 + TypeScript
- PostgreSQL 16, Redis 7 for caching and queues
- All API responses use the ApiResponse helper class — never return raw arrays

## Conventions
- Controllers: single-action when possible, __invoke method
- Form Requests for ALL validation — never validate in controllers
- Feature tests use RefreshDatabase, unit tests don't touch the database

## Do NOT
- Never modify the User model without explicit approval
- Never change database migrations that have already been committed
- Never use DB::raw() — use the query builder or Eloquent scopes
- Never create routes outside of routes/web.php and routes/api.php

Ce fichier m'evite de corriger l'agent des dizaines de fois par session. Sans lui, Claude Code mettait occasionnellement de la logique de validation dans les controllers, utilisait des requetes SQL brutes ou creait des fichiers de routes dans des emplacements non standard. Des choix tous raisonnables isolement — simplement faux pour ce projet specifique.

Le pattern agents.md etend cela encore plus pour les configurations multi-agents. Quand j'ai des agents specialises — un agent de revue de code, un agent de documentation, un agent de tests — chacun recoit son propre fichier de contexte definissant son role, ses contraintes et son comportement attendu. C'est comme cela que vous passez d'un agent generaliste a une equipe d'agents specialises ou chacun fait bien son travail.

Remy Gasill a fait une remarque qui m'est restee : l'ingenierie de contexte consiste en fin de compte a reduire le nombre de decisions qu'un agent doit prendre seul. Chaque decision qu'il prend de maniere autonome est une erreur potentielle. Chaque decision que vous encodez dans le contexte est une opportunite en moins pour l'agent de devier. Les meilleures configurations d'agents que j'ai construites sont presque ennuyeuses a regarder. L'agent ne prend pas de decisions creatives. Il suit un chemin bien defini, utilisant des outils bien definis, dans des contraintes bien definies. Et il produit un travail excellent grace a cette previsibilite, pas malgre elle.

Mais les fichiers de contexte ne couvrent que ce que l'agent doit savoir au depart. Qu'en est-il de ce qu'il apprend pendant le travail ?

Memory.md : Apprendre a Votre Agent a Se Souvenir

C'est la fonctionnalite qui a transforme mes workflows d'agents, passant de base-session a continus.

Par defaut, quand vous fermez une session Claude Code, tout ce que l'agent a appris pendant cette session disparait. Ouvrez une nouvelle session, et il repart de zero. Il ne sait rien du bug que vous avez corrige hier. Il ne sait rien du pattern d'API sur lequel vous vous etes mis d'accord la semaine derniere. Il ne sait pas que la classe UserService a ete refactorisee en trois services plus petits lors de la session precedente.

Memory.md change cela. C'est un fichier persistant — stocke dans le repertoire de votre projet — que l'agent lit au debut de chaque session et peut mettre a jour pendant la session. Pensez-y comme un carnet partage entre vos sessions passees et futures avec l'agent.

Mon memory.md pour un projet en cours ressemble a quelque chose comme ceci :

# Memory

## Decisions Made
- 2026-03-10: Switched from JWT to session-based auth. JWT was causing issues
  with token refresh on mobile. Session approach uses Redis for storage.
- 2026-03-14: Moved all email templates from Blade to React Email. Better
  component reuse and type safety.
- 2026-03-17: Added rate limiting middleware to all public API endpoints.
  Config: 60 requests/minute for authenticated, 20 for unauthenticated.

## Known Issues
- The PaymentService has a race condition on concurrent subscription updates.
  Temporary fix: database-level advisory lock. Proper fix planned for next sprint.
- Test suite takes 4+ minutes to run. Focus: writing targeted tests, not
  running the full suite on every change.

## Patterns Established
- All new services use constructor injection with interfaces, not facades.
- Background jobs extend BaseJob which handles retry logic and dead-letter queue.
- API versioning: URI-based (/v1/), not header-based.

Quand l'agent lit ce fichier au debut de la session, il a immediatement de la continuite. Il ne suggerera pas JWT pour le systeme d'authentification. Il n'utilisera pas Blade pour les templates d'e-mail. Il connait la condition de concurrence et ne la declenchera pas accidentellement. Il suit les patterns etablis sans qu'on le lui rappelle.

Je mets a jour ce fichier manuellement environ une fois par semaine, et j'ai commence a faire en sorte que l'agent lui-meme ajoute des entrees quand des decisions significatives sont prises pendant une session. La commande est simple — "ajoute cette decision a memory.md" — et l'agent formate et ajoute l'entree.

L'effet compose est reel. Apres un mois de maintenance du memory.md, mes sessions d'agent demarrent sensiblement plus vite. Moins de corrections. Moins de repetitions. Moins de "non, on a decide de ne pas faire comme ca." L'agent a une connaissance institutionnelle. Et cette connaissance persiste.

Si vous preferez que quelqu'un configure toute cette architecture d'agents — fichiers de contexte, systemes de memoire, integrations MCP, l'ensemble du workspace — j'accepte exactement ce type de missions. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Maintenant, la memoire dit a l'agent ce qui s'est passe dans le passe. Mais comment lui dites-vous comment effectuer des taches recurrentes correctement, a chaque fois ?

Skills : Des Procedures Operationnelles Standard Que Votre Agent Peut Suivre

Les skills sont le concept qui a finalement rendu mes agents consistants. Avant de les adopter, chaque fois que je demandais a un agent d'"ecrire un article de blog" ou de "creer un endpoint d'API" ou de "configurer un nouveau microservice," la qualite du resultat variait. Parfois excellente. Parfois mediocre. Toujours legerement differente de la derniere fois.

Le probleme n'etait pas le modele. C'etait moi. Je donnais des instructions vagues et j'attendais des resultats consistants. C'est comme donner a quelqu'un un titre de poste sans manuel d'integration et etre surpris quand il fait les choses differemment de ce que vous attendiez.

Les skills sont le manuel d'integration.

Un skill est un fichier markdown — stocke dans .claude/skills/ — qui contient des instructions etape par etape pour une tache specifique et repetable. L'agent lit le skill pertinent avant d'executer et le suit comme une procedure operationnelle standard.

Voici un skill reel que j'utilise pour creer des endpoints d'API dans mes projets Laravel :

# Skill: Create API Endpoint

## Steps
1. Create a Form Request class in `app/Http/Requests/` with validation rules
2. Create a single-action controller using `__invoke` method
3. Add the route to `routes/api.php` inside the appropriate version group
4. Create a feature test in `tests/Feature/Api/` that covers:
   - Successful request with valid data
   - Validation failure with each invalid field
   - Authentication/authorization check
   - Edge cases specific to the endpoint
5. Run the test suite: `php artisan test --filter={TestClassName}`
6. If tests pass, add the endpoint to the API documentation in `docs/api.md`

## Conventions
- Response format: always use ApiResponse::success() or ApiResponse::error()
- Status codes: 201 for creation, 200 for retrieval/update, 204 for deletion
- Never return Eloquent models directly — use API Resources

## Common Mistakes to Avoid
- Don't forget to add the route inside the auth middleware group
- Don't use Route::resource() — we use explicit single-action routes
- Don't skip the authorization check in the Form Request

Quand je dis a l'agent "cree un endpoint d'API pour la mise a jour du profil utilisateur," il lit ce skill et le suit etape par etape. A chaque fois. La structure du controller est consistante. La couverture de tests est consistante. Le format de reponse est consistant. Plus de variations. Plus de "oh, cette fois il a oublie le Form Request."

La beaute des skills en tant que simples fichiers markdown, c'est la portabilite. Ils fonctionnent a travers differents harnesses d'agents. Le meme fichier de skill que j'utilise dans Claude Code fonctionne dans Cursor, dans OpenClaw, dans n'importe quel outil qui lit des instructions markdown. Une seule source de verite, plusieurs consommateurs.

J'ai actuellement onze skills dans mon projet principal : creation d'endpoint d'API, migration de base de donnees, scaffolding de composants, ecriture de tests, revue de code, mise a jour de documentation, verifications de deploiement, audit de securite, revue de performance, triage de bugs et generation de descriptions de PR. Chacun m'a pris 15-20 minutes a ecrire. Combines, ils me font gagner des heures par semaine et — plus important encore — ils ont elimine toute une categorie de moments "l'agent l'a mal fait."

Les skills se composent avec la memoire. L'agent lit le skill pour savoir comment faire quelque chose. Il lit memory.md pour savoir quelles decisions ont deja ete prises. Ensemble, ils donnent a l'agent la connaissance procedurale et le contexte institutionnel dont il a besoin pour operer comme un membre de l'equipe present sur le projet depuis des mois, pas comme un prestataire qui voit le codebase pour la premiere fois.

Securite et Portee des Permissions : La Conversation Que Personne Ne Veut Avoir

Je vais etre direct : donner a un agent IA acces a votre systeme de fichiers, terminal et APIs externes est une decision de securite. Traitez-la comme telle.

Un ingenieur que je connais a donne a son agent un acces en ecriture total et il a ecrase un fichier .env de production lors d'un refactoring de routine. Rien de malveillant — juste une decision raisonnable-mais-catastrophique dans un contexte ou l'agent n'aurait pas du avoir ce pouvoir.

Mes principes de permissions :

Principe du moindre privilege. Donnez a l'agent exactement l'acces dont il a besoin et rien de plus. S'il n'a besoin que de lire des fichiers, n'accordez pas l'acces en ecriture. S'il n'a besoin de travailler que dans /src, ne le laissez pas acceder a /. Les serveurs MCP doivent utiliser des connexions en lecture seule a la base de donnees sauf si les ecritures sont explicitement requises pour la tache.

Isolez les operations non fiables. Quand vous testez un nouveau skill ou un nouveau serveur MCP, executez-le d'abord dans un environnement isole. Une nouvelle branche git, un conteneur Docker, une VM jetable. Observez ce que fait l'agent avant de lui confier quoi que ce soit de precieux.

Les pistes d'audit comptent. Les diffs git sont vos allies. Chaque changement de l'agent devrait faire l'objet d'un commit incremental pour que vous puissiez examiner et annuler. Je passe en revue les diffs generes par l'agent de la meme facon que je passe en revue les pull requests de developpeurs juniors — avec attention et un scepticisme sain.

Separez les environnements strictement. Les projets de production recoivent des permissions plus strictes, moins de serveurs MCP et des sections explicites Do NOT. Les projets experimentaux recoivent plus de liberte parce que le rayon d'impact est plus petit.

Cles d'API et identifiants. Ne mettez jamais d'identifiants dans des fichiers de configuration accessibles par l'agent. Utilisez des variables d'environnement. Partez du principe que tout ce que l'agent peut lire pourrait accidentellement apparaitre dans un log ou un commentaire de code genere. Je l'ai vu arriver.

Les agents auxquels je fais le plus confiance sont ceux que j'ai contraints avec le plus de soin.

En parlant d'architecture soignee — la facon dont vous organisez toutes ces pieces compte plus que vous ne l'imagineriez.

Architecture du Workspace : La Structure de Dossiers Qui Passe a l'Echelle

Apres des mois d'iteration, je me suis arrete sur une structure de workspace pour les projets alimentes par des agents qui gere tout — contexte, memoire, skills, configuration MCP — sans devenir un fouillis au fur et a mesure que le projet grandit.

project-root/
├── .claude/
│   ├── settings.json          # MCP servers, permission config
│   ├── agents/
│   │   ├── code-review.md     # Specialized agent: code review
│   │   ├── documentation.md   # Specialized agent: docs
│   │   └── testing.md         # Specialized agent: test writing
│   └── skills/
│       ├── create-endpoint/
│       │   └── skill.md
│       ├── write-migration/
│       │   └── skill.md
│       ├── security-audit/
│       │   └── skill.md
│       └── deploy-check/
│           └── skill.md
├── CLAUDE.md                  # Project-level context (read on every session)
├── memory.md                  # Persistent agent memory
├── src/                       # Your actual code
├── tests/
└── docs/

Trois decisions de conception a souligner. Premierement, CLAUDE.md vit a la racine du projet, pas enterre dans .claude/ — la visibilite assure la maintenance. Deuxiemement, les skills sont des dossiers (pas des fichiers uniques) parce qu'ils finissent par accumuler des templates et exemples de support. Troisiemement, memory.md est singulier et global. J'ai essaye des fichiers de memoire par agent. La synchronisation etait un cauchemar. Un seul fichier partage garde la connaissance institutionnelle unifiee entre tous les agents.

Cette structure a survecu a quatre projets clients sans necessite de reorganisation. La cle est de commencer avec elle des le premier jour — l'adapter retroactivement a un projet existant est possible mais fastidieux.

Pour Commencer : Votre Premiere Configuration d'Agent Prete pour la Production en 30 Minutes

Si vous avez lu jusqu'ici, vous avez le modele mental. Maintenant voici comment passer de zero a une configuration d'agent fonctionnelle qui inclut tout ce que nous avons couvert — contexte, memoire, skills et integration MCP de base. Trente minutes. Pas de raccourcis, pas d'exemples jouets.

Etape 1 : Installez Claude Code (5 minutes)

npm install -g @anthropic-ai/claude-code

Lancez claude dans le repertoire de votre projet. Il s'authentifiera avec votre compte Anthropic au premier lancement. Si vous avez besoin d'une configuration plus economique, j'ai couvert le Claude Code avec OpenRouter dans un guide separe.

Etape 2 : Creez votre CLAUDE.md (10 minutes)

Ce sont les dix minutes les plus impactantes que vous investirez. Creez un CLAUDE.md a la racine de votre projet avec quatre sections : Vue d'Ensemble du Projet (ce que c'est, quelle stack), Architecture (decisions cles, structure des repertoires), Conventions (standards de code, patterns de nommage) et Do NOT (choses que l'agent ne doit jamais faire).

Soyez specifique. "Suivre les bonnes pratiques" est inutile. "Toutes les reponses API doivent utiliser la classe ResponseHelper dans app/Helpers/" est utile. L'agent ne peut pas lire dans vos pensees, mais il peut lire votre markdown.

Etape 3 : Initialisez memory.md (2 minutes)

Creez un memory.md a la racine du projet avec trois sections vides : Decisions Prises, Problemes Connus et Patterns Etablis. Commencez leger. Ce fichier grandit organiquement au fur et a mesure que vous et l'agent prenez de vraies decisions ensemble. Forcer du contenu prematurement cree du bruit.

Etape 4 : Creez votre premier skill (8 minutes)

Choisissez la tache que vous effectuez le plus frequemment. Pour moi, c'etait la creation d'endpoints d'API. Pour vous, ce pourrait etre l'ecriture de tests, le scaffolding de composants ou la configuration de nouvelles pages. Quoi que ce soit — ecrivez les etapes que vous suivez a chaque fois dans un fichier skill.md :

mkdir -p .claude/skills/your-task-name

Ecrivez le fichier de skill avec des etapes numerotees, des conventions et des erreurs courantes. Gardez-le en dessous de 50 lignes. Si c'est plus long, vous combinez probablement plusieurs skills ou vous sur-specifiez.

Etape 5 : Ajoutez un serveur MCP (5 minutes)

Commencez avec quelque chose a faible risque. Le serveur MCP du systeme de fichiers ou celui de GitHub sont de bons premiers choix. Creez .claude/settings.json :

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Stockez le vrai token dans vos variables d'environnement, pas dans le fichier de configuration. Testez en demandant a l'agent de "lister mes pull requests recentes sur GitHub" et verifiez qu'il retourne des donnees reelles.

Etape 6 : Lancez votre premiere tache agentique (5 minutes)

Commencez avec quelque chose dont vous connaissez la bonne reponse — pas quelque chose de complexe. Demandez a l'agent d'effectuer une tache couverte par votre fichier de skill. Observez comment il utilise le contexte de CLAUDE.md et suit les etapes du skill.

Si le resultat ne fait pas mouche, la solution se trouve presque toujours dans les fichiers de contexte, pas dans le prompt. Affinez le CLAUDE.md. Mettez a jour le skill avec l'etape qu'il a sautee. Cet affinage iteratif est le vrai travail de construction d'agents de production.

L'Avenir Est un Systeme d'Exploitation IA Personnel

Voici ce a quoi je pense quand je regarde ou tout cela se dirige — et je veux etre honnete, c'est de la speculation informee par des patterns, pas une prediction sur laquelle je parierais mon credit immobilier.

Nous construisons vers des systemes d'exploitation IA personnels. Pas du genre vaporware presente en conference. Du genre pratique ou votre workspace d'agents devient l'interface principale pour vos outils numeriques. Pensez a ce que nous avons deja : un agent qui lit des fichiers, execute des commandes, interagit avec des APIs via MCP, se souvient des decisions passees, suit des procedures documentees et s'ameliore au fur et a mesure que le contexte et les skills s'accumulent. Ce n'est pas un chatbot. C'est une couche de systeme d'exploitation entre vous et vos outils.

Remy Gasill a pointe vers cette meme conclusion. MCP fournit le standard d'integration. Les skills fournissent la connaissance procedurale. La memoire fournit la continuite. L'ingenierie de contexte fournit l'alignement. Les pieces existent. Elles sont construites sur des protocoles ouverts que n'importe quel harness peut adopter.

Ce qui m'enthousiasme le plus, ce n'est pas l'expansion des capacites — c'est la multiplication de l'effet de levier. Un ingenieur avec un workspace d'agents bien configure travaille a une echelle differente. Des taches qui necessitaient autrefois d'embaucher quelqu'un deviennent des taches que vous deleguez entre le cafe et votre premiere reunion.

Ce Que Cela Change Reellement dans Votre Facon de Travailler

Voici ce que je veux que vous reteniez — un modele mental clair et une action concrete.

Le modele mental : un agent IA est une boucle (observer, penser, agir) tournant dans un harness (Claude Code, Codex, etc.), connecte a des outils (via MCP), guide par du contexte (CLAUDE.md, agents.md), suivant des procedures (skills) et se souvenant du travail passe (memory.md). Chacun de ces composants est un levier que vous pouvez actionner pour ameliorer votre agent. Quand quelque chose ne va pas, identifiez quel composant a echoue et corrigez-le — ne reecrivez pas simplement votre prompt.

L'action concrete : prenez trente minutes aujourd'hui et construisez la structure de workspace que j'ai decrite dans la section d'implementation. Creez le CLAUDE.md. Commencez le memory.md. Ecrivez un skill. Ajoutez un serveur MCP. Lancez une tache. C'est votre ligne de depart.

Dans six mois, vous regarderez en arriere le workflow d'agents que vous avez construit — le contexte accumule, les skills affines, le fichier de memoire eprouve au combat — et vous realiserez quelque chose. L'agent n'est pas devenu plus intelligent pendant ces six mois. Vous etes devenu meilleur pour le diriger. Et c'est la vraie competence que personne n'enseigne : pas comment utiliser l'IA, mais comment architecturer le systeme qui rend l'IA utile.

Quelle est la premiere tache que vous allez deleguer ?

Foire Aux Questions

Quelle est la difference entre un agent IA et un chatbot classique ?

Un agent IA execute de maniere autonome des taches multi-etapes en utilisant des outils — lisant des fichiers, executant des commandes, appelant des APIs — dans une boucle continue jusqu'a ce que l'objectif soit atteint. Un chatbot repond a des prompts individuels sans passer a l'action. Pour plus de details sur la boucle observer-penser-agir, consultez la section Boucle de l'Agent ci-dessus.

Comment fonctionne MCP (Model Context Protocol) avec les agents IA ?

MCP fournit une interface standardisee pour connecter les agents IA a des outils et services externes comme les bases de donnees, les APIs et les plateformes de communication. Vous configurez des serveurs MCP dans le fichier de configuration de votre agent, et l'agent les appelle comme des outils natifs. Consultez la section MCP ci-dessus pour des exemples de configuration.

Ai-je besoin d'experience en programmation pour configurer des agents IA pour la productivite ?

Une familiarite basique avec le terminal et l'edition de fichiers suffit pour commencer. La configuration du workspace utilise des fichiers markdown et de la configuration JSON — aucun code de framework n'est requis. Le tutoriel etape par etape dans la section d'implementation couvre la configuration complete pour les debutants.

Quel harness d'agent IA devrais-je utiliser — Claude Code, Codex ou OpenClaw ?

Choisissez en fonction de votre workflow : Claude Code pour le developpement natif terminal avec une integration profonde du systeme de fichiers, Codex pour l'execution en cloud isolee avec des garanties de securite, OpenClaw pour une extensibilite open-source maximale. La section Harnesses d'Agents ci-dessus compare chacun en detail.

Comment garder mon agent IA securise en lui donnant acces a des outils ?

Appliquez les principes du moindre privilege : connexions en lecture seule a la base de donnees, tokens d'API a portee limitee, tests isoles pour les nouveaux outils et contraintes de permissions explicites dans vos fichiers de contexte. Ne stockez jamais d'identifiants dans des fichiers de configuration accessibles par l'agent — utilisez des variables d'environnement. Les pratiques de securite completes sont couvertes dans la section Securite ci-dessus.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io