Créer un agent IA : objectif, contexte, outils, validation

Créer un agent IA, c'est donner à un modèle un objectif précis, le contexte dont il a besoin, des outils limités et une règle qui dit ce qu'il doit te soumettre avant d'agir. Commence simple : Anthropic recommande la solution la plus simple qui marche, et OpenAI de tirer le maximum d'un seul agent avant d'en ajouter.

L'essentiel à retenir :

• Un agent se crée en cinq étapes : écrire l'objectif, écrire le contexte, ouvrir les accès, fixer la validation, tester en brouillon.
• L'outil vient en dernier. La plupart des agents qui échouent ont commencé par lui.
• Deux ou trois accès suffisent pour un premier agent. Chaque accès en plus est un risque en plus.
• Tout ce qui envoie, publie, paie ou supprime attend ta validation.
• Si la tâche suit toujours la même règle, une automatisation suffit : pas besoin d'agent.

Ce guide présente ce qu'il faut pour créer un agent, les cinq étapes une par une, la question du code, les cas où un agent ne vaut pas la peine, et la façon dont un agent réel du système d'Ilyass BM a été cadré. Ce qu'est un agent et de quoi il est composé est expliqué dans agent IA : définition, fonctionnement et limites.

Que faut-il pour créer un agent IA ?

Pour créer un agent IA, il faut trois composants (un modèle, des instructions et des outils), plus deux choses qu'on oublie souvent : une mémoire simple et une règle de validation.

OpenAI ramène l'agent à ces trois composants dans son guide « A practical guide to building agents » (page datée du 15 janvier 2026) :

• le modèle, qui raisonne et décide ;
• les outils, les fonctions ou API avec lesquelles l'agent agit ;
• les instructions, des consignes explicites et des garde-fous qui disent comment l'agent se comporte.

Pour un agent qui tourne dans ton activité, ajoute deux pièces. Une mémoire, pour qu'il sache ce qu'il a déjà fait d'un passage à l'autre. Et une règle de validation, pour qu'il s'arrête avant ce qui ne se défait pas.

Le choix du modèle compte moins qu'on le croit. Le guide d'OpenAI conseille de construire d'abord le prototype avec le modèle le plus capable, pour avoir une référence, puis d'essayer des modèles plus petits là où le résultat reste acceptable. Un agent qui se trompe de dossier se trompera avec n'importe quel modèle si son objectif et son contexte sont flous.

Étape 1 : comment écrire l'objectif de ton agent ?

Écris l'objectif en une phrase qui nomme une seule tâche et un résultat que tu peux vérifier.

Un bon objectif ressemble à : « chaque matin, lister les factures échues et préparer une relance pour chacune ». Un mauvais ressemble à : « gérer ma facturation ». Le premier dit quoi produire et quand. Le second laisse l'agent deviner, et un agent qui devine invente des étapes.

Trois tests rapides :

• Une tâche. Si la phrase contient « et » entre deux métiers, tu as deux agents.
• Un résultat observable. Une liste, un brouillon, une note dans une base. Tu dois pouvoir dire « c'est fait » ou « ce n'est pas fait » en regardant.
• Une erreur rattrapable. Le premier agent travaille là où une erreur se corrige sans dommage.

Pour choisir la tâche elle-même, passe tes candidats à une grille de six critères : fréquence, stabilité, exceptions, données, réversibilité, mesure. La méthode, avec un exemple noté, est dans quel processus agentiser en premier.

Étape 2 : quel contexte lui donner ?

Donne-lui par écrit tout ce qu'il doit lire avant d'agir : la procédure, les cas particuliers, les exemples de bon résultat et l'endroit où il note ce qu'il a fait.

Un agent ne connaît pas ton activité. Il travaille avec ce qu'on lui met sous les yeux. Le guide d'OpenAI conseille de partir des documents qui existent déjà (procédures, scripts, règles) et de découper les tâches denses en étapes plus petites et plus claires. Il recommande aussi de prévoir les cas limites : que faire quand une information manque, ou quand une demande sort du cadre.

Le contexte écrit contient en général :

• la procédure, comme si tu la confiais à quelqu'un qui débute ;
• les exceptions que tu connais déjà, avec la réponse attendue ;
• un ou deux exemples de bonne sortie ;
• la mémoire : l'endroit où l'agent note chaque passage, pour ne pas refaire deux fois la même chose.

Si la procédure n'existe que dans ta tête, écris-la d'abord. Fais la tâche une fois à la main en suivant ton texte. Ce que tu as dû improviser manque au contexte.

Étape 3 : quels outils et quels accès lui ouvrir ?

Ouvre-lui seulement les outils dont sa tâche a besoin, avec les droits minimum : lecture quand il doit lire, écriture seulement là où il doit écrire.

L'OWASP en fait un risque à part entière, « Excessive Agency », dans son Top 10 for LLM Applications 2025 (version publiée le 18 novembre 2024). La fiche donne trois causes : trop de fonctions, trop de permissions, trop d'autonomie. Son exemple est parlant : une extension qui doit résumer des e-mails n'a besoin que de les lire. Elle ne doit pas pouvoir en envoyer ni en supprimer.

Avant d'ouvrir un accès, pose trois questions :

• Quelle fonction ? L'agent a-t-il besoin de cet outil pour sa tâche, ou seulement « au cas où » ?
• Quel droit ? Lire suffit-il, ou doit-il écrire ?
• Quelle action seul ? Que peut-il faire sans te demander ?

Le guide d'OpenAI propose de noter chaque outil en risque faible, moyen ou élevé, selon qu'il est en lecture seule ou en écriture, réversible ou non, et selon son impact financier. Un outil à risque élevé déclenche une pause ou une remontée à un humain.

Dans le système d'Ilyass, l'agent « Dispatch Tâches » passe par deux outils : Airtable et la messagerie entre agents.

Étape 4 : qu'est-ce qu'il doit te soumettre avant d'agir ?

Ton agent doit te soumettre tout ce qui sort de chez toi ou ne se défait pas : un envoi, une publication, un paiement, une suppression, un changement d'accès.

Écris cette liste avant le premier branchement, pas après le premier incident. Le guide d'OpenAI range les actions « sensibles, irréversibles ou à fort enjeu » parmi les déclencheurs d'une intervention humaine, jusqu'à ce que la confiance dans l'agent grandisse.

Une bonne demande de validation a trois traits :

• Elle est précise. Ce qui est prêt, ce qui reste à décider, où répondre.
• Elle est au bon endroit. Un tableau ou une messagerie que tu lis vraiment.
• Elle bloque la suite. Rien ne part tant que tu n'as pas répondu.

Cette règle doit tenir hors du prompt. Si l'agent n'a pas le droit d'envoyer, il ne peut pas envoyer par erreur. Une consigne « ne jamais envoyer » écrite dans ses instructions, elle, peut être mal comprise.

Dans le système d'Ilyass, la règle est écrite et permanente : une publication, un envoi externe, un merge ou un changement d'offre attendent un GO écrit. Les bots préparent jusqu'au dernier geste.

Étape 5 : comment le tester avant de le laisser tourner ?

Teste-le en mode brouillon : il travaille sur de vraies entrées, mais sans droit d'action, et tu relis ce qu'il aurait fait jusqu'à ce que ses sorties ne demandent plus de correction.

1 - Faire tourner en brouillon

Retire les droits d'envoi et de suppression pendant le test. L'agent produit ce qu'il ferait, et toi tu compares avec ce que tu aurais fait.

2 - Tenir un journal

Note à chaque passage l'entrée, ce que l'agent a proposé et ce que tu as corrigé. Une correction qui revient indique une règle qui manque au contexte.

3 - Vérifier le résultat, pas le message

Quand l'agent dit « fait », regarde dans l'outil. Un agent peut décrire une action qu'il n'a pas réussie.

4 - Ouvrir un droit à la fois

Quand les brouillons sont justes plusieurs fois de suite, ouvre une seule permission. Puis observe de nouveau.

Les premières semaines demandent de la patience. Un témoignage publié sur X le 12 octobre 2026 le dit sans détour : « Des consignes à refaire 15 fois, des agents qui partent en vrille » (@hakimdotia). L'auteur vend l'installation d'agents IA aux PME : son récit peut être biaisé, mais il décrit bien ce que montre un journal de test.

Faut-il savoir coder pour créer un agent IA ?

Non, il n'est pas nécessaire de savoir coder pour créer un premier agent IA : trois familles d'outils existent, et le choix dépend de ta tâche plus que de ton niveau technique.

• Les assistants avec connecteurs. Tu écris les instructions en langage naturel et tu branches l'assistant sur tes applications. C'est le plus rapide pour une tâche de lecture et de préparation.
• Les outils d'automatisation visuels. Tu dessines un scénario et tu y places une ou plusieurs étapes d'IA. C'est adapté quand une partie du chemin est fixe.
• Le code. Tu appelles un modèle depuis un programme et tu définis toi-même les outils. Anthropic conseille, dans Building effective agents (19 décembre 2024), de commencer par utiliser directement les API des modèles, beaucoup de schémas tenant en quelques lignes, et de bien comprendre le code d'un framework si on en utilise un.

Quelle que soit la famille, les quatre premières étapes restent les mêmes. Un objectif flou ne devient pas clair parce que l'outil est sans code.

Quand un agent ne vaut-il pas la peine d'être créé ?

Un agent ne vaut pas la peine d'être créé quand la tâche suit toujours la même règle, quand elle est rare, ou quand une erreur coûte trop cher pour être confiée à une décision automatique.

Anthropic distingue, dans le même article, deux familles de « systèmes agentiques » :

• les workflows, où le modèle et les outils suivent des chemins de code prédéfinis ;
• les agents, où le modèle dirige lui-même ses étapes et l'usage de ses outils.

Sa recommandation est de chercher la solution la plus simple possible et de n'ajouter de la complexité que si nécessaire, ce qui peut vouloir dire ne pas construire de système agentique du tout. Pour beaucoup d'usages, note l'article, un seul appel au modèle bien préparé suffit.

La question à poser : la règle de ta tâche tient-elle en une phrase sans « ça dépend » ? Si oui, une automatisation fait le travail pour moins cher. Les autres cas sont détaillés dans quand ne pas utiliser un agent IA.

Exemple : comment l'agent « Dispatch Tâches » a-t-il été cadré ? ★

Section signée par Ilyass BM.

« Dispatch Tâches » a été cadré avec les cinq pièces de ce guide : un objectif, un contexte, deux outils, une règle de validation et une mémoire. Je l'ai mis en place le 9 octobre 2026.

• L'objectif. Faire circuler le travail entre mes agents. Il repère les tâches sans owner, en retard ou bloquées, et relance la bonne personne.
• Le contexte et la planification. À intervalles réguliers, il lit la table Tâches de ma base Airtable.
• Les outils. Deux : Airtable et la messagerie entre agents.
• La validation. Il lit et il annote. Il ne passe jamais une tâche en « Terminé » à la place de son owner, ne publie rien et n'envoie rien à l'extérieur.
• La mémoire. Il laisse une note « réponse transmise » sur chaque tâche traitée. Avant de transmettre une réponse, il vérifie cette note, ce qui l'empêche d'envoyer deux fois la même chose.

Rien dans ce cadrage ne dépend de l'outil. On pourrait reconstruire le même agent ailleurs avec les mêmes cinq lignes.