Je prenais l’exemple d’OpenClaw, mais le sujet dépasse largement cet outil. Claude Cowork/Code, Chat GPT Codex et les autres agents deviennent vraiment intéressants dès qu’on leur donne des outils, des skills, des données. Et c’est aussi là qu’ils peuvent potentiellement faire de très mauvaises choses si on leur donne de mauvaises instructions. Ils vont faire ce qu’on leur dit, mais pas forcément ce que l’on veut.

Un skill est plus que du texte

Un skill se présente en général sous la forme d’un fichier Markdown SKILL.md. Il explique à l’agent quoi faire pour réaliser une tâche, un processus. Ça a l’air innocent. Après tout, c’est juste du texte. Et effectivement, le skill seul n’est pas un problème. Sauf que l’agent IA, lui, est là précisément pour appliquer ces instructions, avec les outils, les données et les autorisations que vous lui avez accordés.

Un skill peut aussi embarquer des scripts, demander l’installation de dépendances, télécharger d’autres fichiers ou appeler des services externes. Il faut donc le considérer comme un élément de notre chaîne d’approvisionnement logicielle. Un peu comme une dépendance npm ou un script trouvé sur GitHub. Ce n’est pas une recette de cuisine inoffensive.

Pour vous donner quelques exemples de risques les plus évidents :

• Le vol de secrets : lire des variables d’environnement, des fichiers de configuration, des clés SSH ou des tokens, puis les transmettre ailleurs. Typiquement, on va essayer de vous voler vos clés d’api Claude/OpenIA, et vous vous retrouverez à payer l’usage d’un autre.
• L’exfiltration de données : envoyer le contexte de vos conversations, le contenu de fichiers ou des informations de votre projet vers un serveur externe.
• L’exécution de code : vous faire lancer une commande shell, télécharger puis exécuter un script distant, ou installer une dépendance douteuse. Votre machine pourrait devenir vérolée, servir à faire des attaques DDoS, etc.
• L’injection de prompt : cacher ou formuler des instructions pour que l’agent contourne ses règles, élargisse son périmètre ou fasse quelque chose qui n’a rien à voir avec la promesse du skill.

Le plus vicieux, c’est que ces éléments n’ont pas besoin d’être particulièrement cachés. Un curl | bash au milieu d’une procédure d’installation par exemple, une demande d’accès trop large, ou une URL qui récupère un script peuvent déjà mériter d’y prêter attention.

La plupart du temps, je crée mes propres skills (enfin, je fais créer) pour coller à mes usages. Mais il m’arrive d’en tester de sources externes. Dans ce cas, je préfère vérifier. C’est rapide, et je m’enlève un risque inutile.

Scanner un skill avant de l’utiliser

Mon outil de référence aujourd’hui est SkillSpector, un projet open source de NVIDIA. Il peut analyser un dépôt Git, un dossier, une archive ou un simple fichier SKILL.md, et remonte ensuite un score de risque et quelques explications pour attirer notre attention.

Il détecte par exemple les accès aux variables d’environnement, les lectures de fichiers sensibles, les téléchargements et exécutions de scripts, le code obfusqué, les dépendances vulnérables, ou encore les tentatives de manipulation de l’agent. Il va même chercher les caractères invisibles (oui, certains sont vicieux !). Pour les plus curieux, je vous invite à fouiller les documentations des outils (README de SkillSpector par exemple) pour découvrir les différentes catégories et attaques possibles, il y en a un paquet.

Je reviens à notre outil, SkillSpector. La version la plus simple fonctionne en analyse statique : elle lit les fichiers et cherche des comportements suspects. Ça tourne en local. Pas besoin de tokens, de clé d’API, de compte ou d’abonnement. Après installation de l’outil, on peut par exemple scanner un dépôt avant même de l’installer :

skillspector scan https://github.com/user/awesome-super-skill --no-llm

Le --no-llm est important ici : il force ce mode local et statique. C’est rapide, gratuit, et ça donne un premier filtre très utile. On peut également scanner un dossier sur notre machine, ou un fichier de skill directement. On a du choix.

Évidemment, un score faible ne transforme pas magiquement un skill en un truc sûr à 100 %. Le risque zéro n’existe pas vraiment en terme de sécurité informatique. Mais c’est un bon indicateur pour se questionner et nous aider à juger. À côté de ça, je vérifie aussi qui le maintient.

Quelques alternatives en ligne

Si vous ne voulez rien installer, ESET AI Skills Checker permet d’analyser l’URL d’un skill depuis le navigateur. Pas déconnant de la part de ESET, que je connaissais historiquement pour les anti-virus. Leur approche inclut une analyse des liens externes et de la chaîne de téléchargement. Pratique pour une première vérification.

J’ai aussi vu skill-spector.com, un service web qui dit s’inspirer de l’approche de NVIDIA et génère des rapports d’audit lisibles, avec score et points d’attention. En revanche, faites attention à ce que vous envoyez à un service en ligne : pour un skill interne ou contenant des informations sensibles, je privilégierais un outil local.

Et une alternative “boite à outils”

Petite dernière proposition. Je suis aussi tombé sur skillshare pendant mes recherches sur l’audit de skill. Celui-ci peut être intéressant si vous avez certains usages autour des skills : il propose, en plus de l’audit, de synchroniser vos skills entre Codex, Claude Code et beaucoup d’autres outils.

Bref

Les skills c’est cool, mais c’est aussi une potentielle porte d’entrée pour des problèmes. Que ce soit volontairement malveillant ou non d’ailleurs - un skill peut très bien avoir des vulnérabilités sans que l’auteur en soit conscient.

Donc un peu comme on évite d’installer des logiciels suspects sur notre machine sans creuser un minimum, on évite de télécharger des skills qui viennent de n’importe où et n’importe qui.

Je suis pas mal les nouveautés autour de l’IA et des agents. Parfois via le canal créateurs de contenu qui expérimentent beaucoup avec les agents. Ils testent les outils, partagent ce qui fonctionne, leurs use case, et ils inventent parfois de nouveaux mots pour décrire leurs façons de faire.

Et puis je suis tombé sur ce tweet de Peter Steinberger, le créateur d’OpenClaw :

Are we still talking loops or did we shift to graphs yet?

Peu de temps avant, je voyais du loop engineering partout. Maintenant, c’est le graph engineering qui commence à faire son apparition.

J’ai voulu comprendre un peu mieux ce qui se cachait derrière. Et je me suis dit : « Ah oui. On est en train de remettre des noms sur des choses que l’on connaît déjà assez bien. »

Pas exactement les mêmes choses, évidemment. Le contexte est nouveau, les outils aussi. Mais il y a comme un air de famille avec pas mal de pratiques tech et produit qui elles sont déjà ancrés depuis bien longtemps.

Avancer par petites étapes, encore et toujours

Le loop engineering, on pourrait dire que ça consiste à donner un objectif et des critères de réussite à un agent plutôt que de lui expliquer comment faire tout son travail. On lui donne un but à atteindre, pas une liste d’étape version notice IKEA. L’agent essaye, observe le résultat, corrige et recommence.

La première chose qui me vient, ce sont les tests d’acceptances. Forcément, il faut donner de bons critères de succès pour que l’agent sache de lui-même quand c’est est-ce qu’il a bien atteint son objectif.

Ça me fait penser aux boucles de feedback que l’on recherche partout quand on fabrique un produit ou du logiciel. On fait une petite chose, on vérifie si elle répond au besoin, on ajuste. Un test automatisé, une démo, un retour utilisateur, une revue de code, autant de façons d’apprendre avant d’avoir construit un gigantesque truc impossible à déplacer.

Ça me fait penser au quoi versus comment. Un PO ne va pas expliquer aux développeurs comment fabriquer la page de connexion. On explique autrement vers où on veut arriver, les collaborateurs ne sont pas de simples exécutants. On va donner de l’autonomie pour que l’équipe décide comment faire. Tiens, on pourrait penser aux OKR aussi.

Même idée avec le graph engineering. Au lieu de demander à un agent de réaliser une immense tâche dans son coin, on la découpe. On confie des responsabilités plus petites, on explicite ce qui dépend de quoi, on peut vérifier chaque morceau plus facilement.

Ça rappelle forcément le découpage d’un problème, les responsabilités bien séparées, les incréments livrables, les petites pull requests, … Bref, tout ce que l’on essaie de faire quand on veut garder un projet compréhensible et qui peut facilement évoluer.

On dirait que les agents aussi préfèrent qu’on évite de leur donner une mission du type : « Refais-moi toute l’application, et si tu as le temps pense aussi à la stratégie marketing. » Qui aurait pu prédire ? :)

Donner le bon contexte

Autre sujet que je vois revenir en permanence : le contexte.

Pour qu’un agent fasse correctement son travail, il faut lui donner les bonnes informations. Les objectifs, les contraintes, les exemples et contre-exemples, les fichiers utiles, la façon dont le projet est organisé, ce qui est acceptable ou non, des critères de succès, etc. Sinon, il devra deviner. Et quand une IA devine, elle le fait souvent avec une confiance assez impressionnante (les fameuses halucinations).

Là encore, ça me semble plutôt familier, et peut-être vous aussi.

Un nouveau développeur qui arrive dans une équipe, un collègue qui reprend un sujet, une personne à qui l’on délègue une tâche : tout le monde a besoin de contexte. Les décisions passées, le vocabulaire métier, les contraintes implicites, la définition de « c’est terminé ». Plus on explicite, plus on s’aligne, plus on travaillera efficacement ensemble.

Les fichiers d’instructions pour agents, les dossiers de contexte et les exemples de livrables sont peut-être de nouvelles façons de faire, mais le besoin qu’ils adressent est bien plus vieux : permettre à quelqu’un — ou quelque chose — de comprendre avant d’agir.

Rien de très neuf au final

Mon propos n’est pas de critiquer les personnes qui parlent de ces sujets, ou dire qu’elles n’inventent rien. Personne n’a la même histoire, le même… contexte. Je trouvais juste cette observation amusante, et j’avais envie de la partager.

Notre usage de l’IA et des agents nous faire (re)découvrir des partiques tech et produit, déjà existante. Sous une forme légèrement différente. Est-ce que l’IA remplacera nos jobs ? J’en sais rien. Mais on dirait que pour le moment, certaines façons de faire reste utile même si l’outil change. Et ça, c’est intéressant.

La culture tech et produit n’a pas pris un coup de vieux. Et c’est peut-être pour ça qu’elle était (et est toujours) pertinente.

Si on regarde en arrière, ce format était surtout utilisé par les développeurs et certains outils. C’est par exemple mon cas, je l’utilise depuis plusieurs années de différentes manières : un README qui accompagne le code des projets, mon système de notes avec Obsidian, et même ce blog - j’écris mes articles en Markdown, et c’est ensuite le moteur Hugo qui transforme ça en HTML.

Aujourd’hui, n’importe qui peut être amené à devoir lire ou manipuler un fichier Markdown en jouant avec l’essor des applications d’agents IA comme Claude Cowork ou ChatGPT Codex (voir mon guide sur la prise en mains d’agents IA). C’est également plus économique (en token) que des fichiers PDF.

La bonne nouvelle ? C’est incroyablement simple à apprendre. Pas besoin d’être développeur ou d’y connaître quelque chose dans la technique. En 5 minutes, vous aurez compris l’essentiel. Voyons ça ensemble.

C’est quoi, au juste ?

Markdown, déjà, c’est un format de fichier texte avec pour extension .md. Ça contient simplement du texte. On y retrouve le contenu de ce texte et sa mise en forme (gras, italique, …).

Quand on rédige un document sur Word ou Google Docs, si on veut faire de la mise en forme, on doit alternativement surligner des morceaux de texte puis cliquer sur un bouton : ça je veux que ce soit en gras, ça c’est en rouge, ça c’est le grand titre, etc. Et quand on copie-colle le texte ailleurs, on prie pour que ça applique bien le bon style :)

L’idée du format Markdown, c’est d’écrire le contenu textuel et d’utiliser quelques symboles pour indiquer la mise en forme, directement pendant la saisie. Par exemple : Une phrase avec un mot en *italique*.. On balise le texte (c’est un langage de balisage, comme HTML, mais bien plus simple).

Markdown se veut simple, concis, et lisible. On veut pouvoir facilement lire le texte contenu dans un fichier Markdown. Qui dit simplicité dit aussi moins de possibilités - ce format va à l’essentiel. On ne fera pas autant de folie qu’avec Word ou une page web. Et c’est tant mieux.

L’essentiel pas à pas

Les titres

Pour hiérarchiser avec des titres, des sections, on utilise le symbole dièse (#). C’est simple : plus il y a de dièses, plus le titre descend en niveau. On peut aller jusqu’à 6.

# Titre principal (H1)
## Titre de section (H2)
### Sous-titre (H3)

Mettre en valeur le texte

Besoin d’insister sur un mot ou d’ajouter du relief ? C’est le rôle de l’astérisque (*).

• Pour l’italique, on encadre les mots d’un astérisque : *italique*
• Pour le gras, on en met deux de chaque côté : **gras**
• Et si on veut vraiment appuyer en combinant les deux, on en met trois : ***les deux***

Simple, non ?

Listes

Pour faire une liste, un simple tiret (-) suivi d’un espace, et le tour est joué.

- Premier point
- Deuxième point

Ça marche aussi avec l’astérisque (*). Et si vous préférez une liste ordonnée, tapez simplement 1., 2., etc.

Citations

Pour citer quelqu’un ou mettre en avant une phrase importante, utilisez le chevron droit (>) en début de ligne. Ça donne ça :

Je sais que je ne sais rien.

Liens et images

C’est le moment le plus compliqué, mais promis, ça reste simple. Pour faire des liens, on utilise la combinaison de crochets et de parenthèses.

• Pour un lien : [le texte du lien](URL). Par exemple : [mon blog](https://jordanchapuy.com).
• Pour une image : c’est exactement la même chose, avec un point d’exclamation devant. Par exemple : ![Mon logo](https://site.com/logo.png).

Blocs de code

Même si vous n’écrivez pas de code, cette syntaxe reste utile pour isoler du texte, faire comprendre que c’est un extrait, ou montrer une formule sans que l’éditeur essaie de la formater. On utilise le backtick (`).

• Pour un passage au milieu d'une phrase, on l’encadre d’un seul backtick : `comme ceci`.
• Pour un bloc entier de plusieurs lignes, on utilise trois backticks (```) avant et après le bloc.

Ceci est un bloc de code.

Exemple complet

Voici un rapide exemple de contenu Markdown, pour assembler ce que l’on a vu. Et ça me permet de montrer une précision utile.

Après la plupart des “blocs” comme un titre, une citation, une liste, un bloc de code (tout ce qui devrait retourner à la ligne ensuite), il faut sauter une ligne pour que la mise en page soit bien prise en compte.

# Instant Kaamelott

Vais-je parler de Kaamelott dans chacun de mes articles ? 

Nooooon, je ne le cite pas tout le temps... Mais *un peu quand même*.

> Ouais, c'est pas faux ~ Perceval.

## Construire un château fort

Je m'y connais bien là-dedans, j'ai dû en bâtir **une dizaine** quand j'étais enfant. Rien de plus simple, il vous faut :

- Du [sable](https://fr.wikipedia.org/wiki/Sable),
- De [l'eau](https://fr.wikipedia.org/wiki/Eau), pour faire une sorte de ciment avec le sable, mais pas trop quand même,
- Un seau, c'est plus simple pour faire les tours.

```
[FICHE TECHNIQUE]
- Difficulté : Facile
- Temps de construction : 20 minutes
- Résistance aux vagues : 0, prévoir des douves
```

Vous voyez, ça reste facilement lisible. J’ai même envie de dire que si on ne connaît pas le Markdown, on peut tout de même comprendre le contenu.

À vous de jouer

Voilà. C’est suffisant pour la grande majorité du temps. Oui, il existe quelques autres mise en forme pour faire des tableaux complexes ou barrer du texte, mais c’est largement dispensable au début.

Pour pratiquer sans rien installer, je vous conseille d’aller sur Dillinger.io ou tout autre site qui propose une preview Markdown en ligne. Vous écrivez à gauche en texte brut, et le résultat s’affiche à droite en temps réel.

Prenez un instant pour faire le test ;)

Avec les agents IA, on ne demande plus seulement une réponse dans une conversation. On installe l’agent quelque part avec des fichiers, du contexte, des règles, des pouvoirs. Et là, il peut commencer à travailler dans un environnement, pas seulement répondre dans une fenêtre de chat.

C’est ce qui m’intéresse dans cet article : faire un premier pas concret. Pas devenir expert en automatisation, gestion de la mémoire, ou autres concepts qui gravitent autour. Non, juste créer un premier workspace IA, lancer une vraie tâche, et comprendre pourquoi ça change autant de choses.

Derrière ce titre à double sens, je vous propose donc un début accessible pour tous. Pas besoin d’être tech.

Rappel important : les IA (agent ou chat) peuvent réutiliser vos données. Faites attention au service et type d’abonnement que vous utilisez, et aux informations que vous communiquez.

Du chat à l’agent, il manque surtout un espace de travail

Dans l’article précédent sur les agents IA, je donnais l’image d’une boucle pour définir un agent : observer, décider, agir, observer à nouveau.

Un chat classique répond à ce qu’on lui donne. Si on oublie un contexte, il ne l’a pas. Si on veut qu’il reformate un fichier, il faut lui donner, expliquer la structure, récupérer le résultat, et le ranger quelque part. Ça marche, mais on finit vite par être l’assistant de notre propre assistant IA.

Un agent, lui, devient vraiment intéressant quand il a un endroit où travailler. Un dossier, des fichiers, des consignes, des exemples, du contexte, des notes, etc. Il devient davantage autonome pour atteindre un objectif.

Et c’est là-dessus qu’on va se concentrer. Notre premier pas avec les agents IA, ce ne sera pas d’écrire le prompt parfait, ni de trouver le meilleur modèle ou plateforme. Ce sera de créer un espace où l’agent peut comprendre notre contexte, poser les bonnes questions, puis produire quelque chose qui nous correspond.

Ah, et bonne nouvelle, ce premier espace est très simple à préparer.

Choisir une application, sans en faire une religion

Pour travailler avec un agent sur notre ordinateur, il faut généralement une application qui peut accéder à un dossier local, lire et manipuler des fichiers, lancer des commandes. C’est ce qui permet de passer du “chat” à un “agent qui travaille dans un projet”.

Aujourd’hui, on trouve plusieurs outils grand public dans cette famille : Claude Cowork côté Anthropic, ChatGPT Codex côté OpenAI, Antigravity côté Google, Cursor en précuseur pour les devs, et sûrement d’autres au moment où vous lirez ces lignes. Ce sont des applications à télécharger et installer sur un ordinateur.

Lequel choisir ? Honnêtement, pour commencer, je trouve que c’est moins important que le système que vous mettez en place autour.

Les modèles progressent vite, les abonnements changent, les limites bougent, et chacun aura ses préférences selon ses usages. J’en parlais déjà dans mon article sur le “meilleur” modèle IA : la bonne réponse dépend du contexte. Pour mes besoins actuels, j’ai une préférence pour Codex, avec Claude pas loin derrière. Mais ce n’est pas une véritée absolue.

L’important, pour ce premier exercice, c’est surtout de choisir un outil capable d’ouvrir un dossier de travail et d’agir sur des fichiers. Faites votre choix puis installez l’application sur votre ordinateur. Une fois que vous avez ça, on peut préparer l’espace de travail.

Préparer un premier workspace IA

On va partir sur une structure volontairement simple pour notre espace de travail. Ce n’est pas la bonne structure. C’est une structure pour commencer, que vous adapterez ensuite à votre façon de travailler et au fil de vos découvertes.

Une précision. Quand je parle d’espace de travail ou workspace, c’est tout simplement un dossier que vous ouvrirez avec votre application. L’agent pourra jouer avec tout ce qu’il y a à l’intérieur.

Vous allez donc devoir créer un dossier “workspace” où bon vous semble (sur votre bureau, dans vos documents) et avec le nom que vous souhaitez. Il faudra ensuite créer cet ensemble de dossiers et fichiers à l’intérieur du dossier workspace, qui correspond à notre structure :

workspace/
├── 00-contexte/
│   ├── a-propos-de-moi.md
│   ├── mon-style.md
│   └── regles.md
├── 01-projets/
│   └── premier-projet/
│       └── ...
├── 02-templates/
│   └── modele-xyz.md
└── 03-livrables/

Ici, plusieurs solutions. Via votre explorateur de fichier / Finder. Via Obsidian. Via un IDE ou en terminal. Peu importe. Ou sinon… pourquoi ne pas demander à un agent ? Après tout, on vient de dire qu’il peut manipuler des fichiers dans son espace de travail, alors profitons-en.

Faisons notre toute première tâche avec un agent :

• Lancez donc votre application (pour rappel, il s’agit de Claude Cowork, ChatGPT Codex, etc).
• Ouvrez votre dossier “workspace” (selon l’application, il faut créer un projet en ciblant le dossier).
• Démarrez une nouvelle conversation (en ciblant bien le dossier/projet) et demandez lui de travailler durement !

Crée l'arborescence de dossiers et les fichiers vides suivants dans mon workspace actuel :

workspace/
├── 00-contexte/
│   ├── a-propos-de-moi.md
│   ├── mon-style.md
│   └── regles.md
├── 01-projets/
│   └── premier-projet/
│       └── ...
├── 02-templates/
│   └── modele-xyz.md
└── 03-livrables/

Et voilà. J’en profite pour une rapide explication, à quoi servent chacun de ces dossiers ?

• 00-contexte contient ce que vous ne voulez pas répéter à chaque fois : qui vous êtes, comment vous travaillez, votre style, vos règles.
• 01-projets contient les informations et documents propres à chaque projet en cours. On peut imaginer des projets ma newsletter jardinage et ma super entreprise de plomberie par exemple.
• 02-templates garde la définition de vos formats à réutiliser. Le template d’une newsletter par exemple (les sections, la description de chaque section, etc), ou d’un mail de prospection.
• 03-livrables sert à ranger ce que l’agent produit.

Vous pouvez évidemment faire autrement. Ajouter un dossier archives pour les projets terminés. Un dossier ressources pour capturer des articles, posts, vidéos ou notes. On peut aussi définir des règles et styles par projet plutôt que pour tout le workspace. Ou partir sur une structure plus proche d’un wiki, comme le wiki proposé par Andrej Karpathy.

Ce qui compte, c’est que ça corresponde à vos besoins et que l’agent puisse se repérer sans que l’on doive tout réexpliquer à chaque prompt.

Les premières informations de contexte

Dans le dossier 00-contexte, on va créer trois fichiers Markdown.

Petite parenthèse sur Markdown : c’est un format de texte très simple, avec quelques symboles pour la mise en forme (gras, titre, liens). Vous pouvez apprendre le Markdown en 5 minutes avec mon guide. Au pire, vous écrivez du texte sans aucune mise en forme ou n’utilisez que des titres avec # et des listes avec -.

Son gros avantage, c’est qu’il est lisible partout. C’est du texte. On reste propriétaire de nos fichiers, et les modèles IA comprennent parfaitement ce format.

a-propos-de-moi.md

Ce fichier sert à donner le contexte humain, perso et professionnel. Qui vous êtes, ce que vous faites, vos sujets, vos objectifs, vos contraintes, vos rôles, vos domaines, etc.

L’idée n’est pas d’écrire une autobiographie complète. L’idée est d’éviter de répéter à chaque demande : “je suis indépendant”, “je suis expert en”, “mes clients sont”, etc. Pensez donc à tout ce qui sera utile à l’agent pour réussir les objectifs que vous lui donneraient.

Commencez simplement, et améliorez-le au fil du temps.

Pour donner des exemples tout au long de cet article, imaginons un personnage fictif :

# À propos de moi

Je suis Arthur, président de l'association "La Table Ronde".

Je gère une équipe de chercheurs sur le terrain (les "chevaliers"). 

Mon rôle est de suivre leurs avancées et de valider l'utilisation de notre budget annuel (financement de l'association).

Mes priorités quotidiennes :
1. Cartographier précisément les zones explorées pour éviter les doublons.
2. Suivre les indices concrets (sources historiques, pistes archéologiques).
3. Surveiller les dépenses logistiques (frais de déplacement, tavernes, équipement).

mon-style.md

Ce fichier décrit votre façon d’écrire et communiquer. Le ton, niveau de détail, structure, mots à éviter. Ajoutez aussi des exemples et contre-exemples pour aider l’agent à comprendre votre plume. Les exemples sont très puissant, mettez-en !

J’en profite pour glisser une astuce : utilisez votre agent pour vous aider à remplir ce type de fichiers. Vous pouvez lui demander de vous aider avec une suite de questions/réponses par exemple. Ou vous pouvez lui fournir des textes que vous avez rédigés. À vous de voir.

# Mon style

- **Ton :** Direct, pragmatique, professionnel mais accessible.
- **Structure :** Toujours utiliser des listes à puces et des tableaux pour les chiffres. Pas de longs paragraphes.
- **Niveau de détail :** Synthétique.
- **Formulations à éviter :** 
    - Supprimez toutes les formules de politesse excessives (pas de "noble roi", "Sire", "seigneur") 
    - Aucune expression vague ("on a cherché partout", "pas mal d'argent"). Je veux des faits précis.

regles.md

Ce fichier pose les règles de fonctionnement de l’agent. Ce qu’il doit faire, éviter, demander, où il doit écrire les résultats, comment nommer les fichiers. Et aussi comment fonctionne notre espace de travail.

# Règles de fonctionnement de l'agent

Tu dois respecter strictement les règles suivantes :

- **Limites de connaissances :** 
   - Si une information importante manque, pose une question plutôt que de supposer.
   - Dis explicitement quand tu n'es pas sûr.
- **Gestion du workspace :**
   - Ne modifie jamais les fichiers du dossier `00-contexte` sans me demander.
   - Mes projets en cours sont situés dans `01-projets`.
   - Mes templates sont dans `02-templates`.
   - Écris toutes les synthèses générées exclusivement dans le dossier `03-livrables`.
- **Traitement des données :** 
   - Ignore systématiquement les anecdotes personnelles, les histoires de taverne, les plaintes sur la météo ou la nourriture.
   - Ne conserve que : la zone géographique explorée, les indices concrets, et le montant total des dépenses.

Ajouter des instructions globales

Il faut savoir que les agents ne lisent pas automatiquement nos fichiers - son contexte exploserait sinon. Il faut soit directement les mentionner dans un prompt, soit que l’agent estime de lui-même qu’il doit lire le contenu de nouveaux fichiers pour réaliser son objectif.

Il y a quelques exceptions. Il est possible de créer des instructions globales. On peut les ajouter dans les paramètres de l’application, ou en créant un fichier spécial à la racine de notre workspace : AGENTS.md (pour la plupart) sinon CLAUDE.md (pour Claude).

C’est comme un brief permanent pour l’agent, il chargera ces instructions à chaque conversation. Et ça nous intéresse. On a au moins envie de lui indiquer de prendre en compte nos fichiers de contexte pour éviter de devoir lui rappeler à chaque fois.

Avant chaque tâche, commence par lire les fichiers du dossier `00-contexte`.

Je conseille d’utiliser les fichiers de type AGENTS.md/CLAUDE.md plutôt que les paramètres de l’application. Si demain vous changez d’outil, vos fichiers restent là. Vous n’avez pas tout caché dans les réglages d’un compte ou d’une app.

Autre chose à savoir, vous pouvez être granulaire. Une instruction globale à la racine du workspace, puis des instructions locales dans un dossier projet. On a des informations, règles, styles qui ont du sens uniquement pour un projet.

AGENTS.md
01-projets/
└── graal/
    └── AGENTS.md

Première mission

Ça y est, la base est prête. Vous pouvez commencez à utiliser un agent personnalisé avec votre contexte, dans votre projet.

Mettons-nous à la place d’Arthur. Que pourrait-il faire ? Il reçoit de nombreux rapports de quêtes de la part de ses chevaliers. Des rapports très longs, bourrés de détails inutiles, de plaintes, d’anecdotes de tavernes, etc.

• Rapport de Perceval et Karadoc
• Rapport de Lancelot

Il n’a pas de temps à perdre, il a déjà beaucoup de responsabilités. Il aimerait bien avoir des synthèses avec les informations essentielles pour prendre des décisions. Et ça tombe bien, dans son contexte, il a déjà indiqué son style et ses règles.

Il lui suffirait de mettre les fichiers texte contenant les rapport dans le dossier 01-projets/graal/rapports et de faire une simple demande à un agent :

Pour le projet Graal, je veux une synthèse des rapports des chevaliers.

Et ça suffit. On voit tout de suite la différence avec un chat. Ici, l’agent possède tout le contexte utile. Il peut décider d’aller chercher d’autres informations (les rapports). Puis il va réaliser la tâche demandée à l’origine : faire une synthèse. Le prompt est d’ailleurs assez court, car l’espace de travail a été préparé en amont.

• Synthèse générée par l’agent

C’est un cas d’usage simple, mais il permet de voir la puissance des agents. On pourrait lui demander de générer des slides sur Google Sheet pour faire une présentation des avancées. Ou de tenir à jour notre fichier Excel des dépenses.

Ce qu’il vous faut maintenant, c’est détecter quels sont tout vos process, ceux que vous répétez le plus et qui pourraient vous apporter rapidement de la valeur.

Les vérifications restantes

Une ia peut toujours se tromper, haluciner, mal interpréter une note, oublier une contrainte, etc. Vérifiez toujours le résultat. Puis, éventuellement, améliorez votre espace de travail.

Par exemple, si l’agent écrit toujours trop long, améliorez mon-style.md. S’il modifie des fichiers qu’il ne devrait pas toucher, précisez regles.md. S’il oublie une section dans chaque livrable, modifiez votre template.

C’est là que le workspace devient intéressant. Il s’améliore avec l’usage.

Pour aller plus loin

Nous voilà avec une bonne base de départ. Avec le temps, vous pourrez l’améliorer de nombreuses manières :

• en retravaillant le workspace, la structure,
• en ajoutant du contexte sur vous et vos projets,
• en connectant l’agent à d’autres outils et services (mails, drive, calendrier, slack, notion, …),
• en créant des SKILLS pour rendre réutilisable des process que vous faites régulièrement,
• en créant des tâches récurrentes,
• en creusant des concepts comme la mémoire, la gestion ducontexte, les tokens, etc.

Mais d’ici là, pratiquez, jouez avec votre nouvel espace de travail !

Je force un peu le trait, mais il faut bien compenser un peu le discours de certains :). Le mot agent est devenu un mot magique. On le colle sur un produit, un workflow, une démo, un chatbot un peu amélioré, et hop, ça donne l’impression qu’on a remplacé un humain.

Sauf que si on veut comprendre ce que c’est, il faut retirer vernis marketing et influenceur. Un agent IA, ce n’est pas une usine autonome qui tourne 24h/24 dans un coin. Je le définirais plutôt comme ça : un agent est un système qui utilise un modèle d’IA pour observer une situation, décider des prochaines étapes, utiliser des outils si besoin, puis recommencer en fonction du résultat obtenu.

Observer, décider, agir, observer à nouveau. C’est cette boucle qui change beaucoup de choses. On ne demande plus seulement une réponse à un chat. On demande d’avancer dans une tâche, d’atteindre un objectif.

Revenons un peu en arrière

Au départ, il y a les modèles de langage (LLM). Les modèles GPT permettaient de “prédir la suite probable d’un texte” (je prends un raccourci, mais l’idée de base est là). Ça marchait bien, et on s’est aperçu qu’en ajoutant un peu de contexte avant, ça permettait d’influencer le fond et la forme de la réponse.

À partir de là, il n’a pas fallu longtemps pour voir arriver la naissance de ChatGPT. C’est encore un modèle GPT dans l’arrière-boutique, mais cette fois avec une interface web par-dessus et un gros prompt système pour créer ce semblant de conversation. Et c’était déjà impressionnant. On pouvait demander une explication, reformuler un texte, générer du code, résumer un document, etc. Mais le fonctionnement restait assez simple : une demande, une réponse. Puis une autre demande, une autre réponse.

Plus tard, on voit apparaitre de premières connexions avec des outils, et même un protocole pour standariser cela (MCP). Les agents arrivent.

Ce qui change avec un agent

Un agent IA ajoute trois choses fondamentales. La première, c’est la capacité à utiliser des outils. L’agent peut lire des fichiers, les modifier, lancer une commande, chercher une information, suivre une todo-list, … Ça dépend évidemment de l’environnement qu’on lui donne, mais l’idée est là : il ne produit plus seulement une réponse directe, il peut agir dans cet environnement.

Agent : Je vais récupérer tes rendez-vous de la journée sur ton Google Calendar.

La deuxième, c’est la capacité à enchaîner plusieurs étapes. On ne lui demande plus uniquement “réponds à cette question”, mais plutôt “atteins ce résultat”. Il peut inspecter un fichier, constater qu’il manque une information, lire un autre fichier, lancer un test, corriger une erreur, puis revenir avec le résultat.

Agent : Je met à jour l’outil que tu m’a demandé. C’est fait. Oh, ça ne compile plus. Ok je viens de voir qu’il faut modifier ce fichier pour l’adapter avec la nouvelle façon de faire. Cette fois, c’est bon.

La troisième, c’est une forme de mémoire de travail. Parfois, c’est simplement l’état de la tâche en cours : à quelle étape il est, ce qu’il a déjà essayé, ce qu’il a observé, les erreurs rencontrées. Mais cette mémoire suffit déjà à créer une différence importante avec un simple prompt isolé. L’agent peut suivre un plan.

Agent : Je viens de comparer trois sources, j’ai gardé les points communs en tête, je vais maintenant pour voir générer un résumé.

Dans un usage technique, c’est très parlant. On peut demander “corrige ce bug”. Un chat classique va souvent répondre avec des hypothèses et du code à copier. Un agent, lui, peut lire le code existant, modifier un fichier, exécuter les tests, voir que ça casse ailleurs, ajuster, recommencer cette boucle trois fois jusqu’à avoir des tests OK, puis expliquer ce qu’il a fait.

On passe de “je te réponds” à “je peux avancer dans la tâche avec toi”. L’agent décide quoi faire en fonction de l’état, et il agit.

Comment on utilise un agent, concrètement ?

Le premier contact, pour beaucoup de monde, peut venir des chats web comme ChatGPT, Claude, Perplexity et bien d’autres. Aujourd’hui, ils ne cherchent plus à seulement répondre tout de suite. Ils ont beaucoup plus d’outils et de capacités - des connecteurs, du raisonnement, de la recherche profonde, etc. Ils peuvent analyser un document, faire une multitude de recherches sur le web, puis produire une analyse détaillée.

La frontière entre un agent et un chat devient un peu plus floue d’ailleurs. Ce qui est intéressant à observer maintenant, c’est si le chat / le service permet de réaliser des tâches, d’atteindre des objectifs. Et dans quel environnement.

Là où ça prend davantage forme, à mon sens, c’est avec les outils qui ont accès à un environnement permettant une plus grande liberté. Cursor, Claude Code, OpenAI Codex, et d’autres outils du même genre peuvent lire un projet sur notre machine, chercher dans les fichiers, créer ou modifier du code, lancer des commandes, puis se corriger selon le résultat.

La différence est assez marquante. Dans un chat web classique, on peut demander : “explique-moi comment réorganiser ce projet” ou “écris-moi un script pour faire ça”, et on devra ensuite le faire manuellement. En espérant avoir donné tous les bons détails et fichiers. Avec un agent lancé dans le dossier du projet, on va directement lui demander d’effectuer l’action, et il cherchera les informations lui-même. Il ne travaille plus seulement sur une description du problème, il travaille dans le contexte réel.

Note : j’ai pris l’exemple d’un projet de code, mais on peut également imaginer un dossier avec un ensemble de fichiers de comptabilité, d’idées pour une chaîne YouTube, etc. Cela reste des fichiers et du texte, c’est très facilement manipulable par un agent.

Les avantages d’un agent

On a vu qu’un agent peut utiliser des outils, premier bon avantage. On pourra lui demander de lire ou envoyer des mails, chercher une information sur le web, lister les retours clients sur Zendesk, etc. A priori tout ce qu’on pouvait faire à la main et qui contient une interface web / api / cli.

Autre gros avantage que l’on a aussi vu, c’est la possibilité d’enchaîner des étapes. Même si elles ne sont pas très complexes, c’est un gain d’autonomie. On n’est plus obligé de micro-manager un chat en lui disant étape par étape quoi faire. Ici, l’agent peut atteindre un objectif en trouvant lui-même le chemin.

Dit autrement, on pourrait parler de travailler dans l’incertitude. Si on veut créer un script ou une automatisation, on doit connaitre chaque étape au moment de créer cette automatisation, et il faudra que ça se passe bien comme on l’a prévu, sinon ça casse. L’agent, lui, peut réussir à s’adapter en cours de route.

Au final, l’agent a cette capacité de s’adapter. Et c’est peut-être là son plus gros avantage. On en revient à la boucle : observer, décider, agir, observer à nouveau.

Les limites à garder en tête

Un agent peut coûter plus cher à utiliser, même si ce n’est pas une règle absolue. Un agent léger, avec peu d’outils et peu d’allers-retours, peut rester raisonnable. Mais dans l’idée, un agent est plus autonome, il décide quoi faire, il explore, utilise une commande, lit un fichier ou un résultat, etc. Et tout ça, eh bien ça consomme plus de tokens. Avant, une partie de ces actions étaient du côté de l’humain alors que maintenant, l’agent doit le verbaliser.

Il y a aussi un côté moins prévisible. Un agent peut décider de faire dix étapes au lieu de trois. De charger un énorme fichier que l’on avait pas prévu. De reboucler car il n’est pas encore satisfait d’après sa compréhension du succès. On n’est plus sur un simple une demande, une réponse.

Il faut donc surveiller le contexte, les quotas, les tokens, et parfois simplement la pertinence de le lancer pour une petite tâche. Sinon, à la fin on obtient une facture salée (si on passe par l’API) ou une limite atteinte prématurément (paie-t-on l’abonnement supérieur pour continuer ?). Sachant qu’en plus, tout ça bouge beaucoup. C’est par exemple au tour d’Anthropic de mettre le feu à la communauté en ce moment avec un abaissement des limites et des nouvelles contraintes autour l’exécution autonome des agents (claude -p pour ceux qui suivent).

À côté de cela, il y a également la question du contrôle. Plus on donne d’outils à un agent, plus il peut faire de choses utiles et plus il peut faire de bêtises : modifier le mauvais fichier, envoyer une requête au mauvais endroit, mal comprendre une consigne, ou bien pire. La suppression de la base de données de production et des backups d’une entreprise par exemple ?

Ce qu’un agent n’est pas

Un agent IA, en lui-même, ce n’est pas forcément un système qui tourne tout seul 24 h/24. Si vous voulez quelque chose qui se réveille tous les matins, surveille une boîte mail, lance une analyse, envoie un rapport et recommence demain, il faut quelque chose autour.

Ça peut être un serveur. Un cron. Un outil comme n8n. Un outil d’orchestration. Un setup avec OpenClaw. Un Agentic OS (sûrement le prochain mot à la mode). Peu importe la forme exacte, mais il faut un mécanisme qui déclenche le travail, garde l’état, gère les erreurs, relance si besoin, stocke les résultats.

L’agent peut être une brique dans ce système. Par exemple, n8n peut déclencher un workflow toutes les heures ou selon un événement, récupérer des données, puis appeler un modèle d’IA pour analyser. Là, l’agent ou le modèle intervient à une étape précise. Mais l’autonomie globale vient surtout de l’orchestration qu’il y a autour. Autre exemple avec OpenClaw, c’est lui qui maintient en vie les agents avec un système de heartbeat et une communication par les messageries type Telegram, Discord, etc.

C’est une distinction importante. Sinon on finit par appeler “agent” n’importe quel automatisme un peu sexy.

Est-ce qu’on en a vraiment besoin ?

Pas toujours. Justement parce que parfois on a besoin d’une automatisation plus que d’un agent IA. Un truc prédictif qui est un enchainement de tâches définies et d’outils selon un déclencheur, par exemple. C’est “moins vendeur”, “moins à la mode”, mais c’est ce qui réponds au besoin.

“À chaque fois qu’un retour client arrive sur notre outil de support, on veut répondre automatiquement qu’on s’en occupe, puis l’ajouter dans sur notre board d’équipe et nous notifier sur Teams”.

Nul besoin d’un agent ici, un workflow sur n8n ou similaire fera l’affaire. Et vraiment si besoin, on peut y glisser un noeud IA (pour analyser le message par exemple), ce qui coûtera moins cher que si un agent faisait tout.

Et je pense que c’est le point le plus pratique à garder en tête. Un agent IA est intéressant quand la tâche est moins prédictible, demande plus d’adaptation ou d’autonomie. Qu’on ne connait pas le chemin. L’exploration pour corriger un bug est un bon exemple qu’on a vu précédemment, une boucle d’écriture/critique/réécriture d’un script de vidéo YouTube pourrait en être un autre.

Et puis parfois, peut-être même qu’un simple prompt pourrait suffire. Si on garde une bibliothèque de côté et/ou quelques fichiers d’instructions, on pourrait dans certains cas revenir à un mode de chat demande/réponse plus classique quand il n’y a pas un long chemin à parcourir.

Plusieurs questions à se poser donc, sauf si on n’a aucun problème avec l’argent et l’énergie :

• est-ce qu’on connait le chemin ? est-ce qu’il faudra s’adapter ?
• est-ce qu’on est sur une boucle d’actions / observations ?
• est-ce qu’on veut de la reproductibilité ?
• est-ce qu’une simple demande sur un chat suffirait ?

Bref

Un agent IA, ce n’est pas un nouveau collègue virtuel totalement autonome. C’est d’abord un modèle d’IA placé dans un système qui lui permet d’observer, de décider, d’utiliser des outils, puis de réagir au résultat pour continuer.

C’est puissant, surtout quand la tâche dépasse le simple échange question-réponse. Mais ce n’est pas magiquement autonome, fiable, économique ou nécessaire. Il faut encore un cadre, des permissions, dans certains cas une orchestration, et surtout un peu de jugement.

Donc avant de mettre un agent partout, je trouve plus sain de comprendre ce que c’est, puis partir du besoin. C’est ma culture produit qui parle. Parfois, l’agent est exactement la bonne brique. Parfois, un prompt suffit. Parfois, un script ou workflow fera mieux le travail. Le besoin avant la solution.