Créer un agent d’IA : méthode, garde-fous et critères de recette

Cette page s'adresse aux directeurs marketing, opérations ou SI qui veulent créer un agent d'IA utile en production, et pas seulement un assistant qui répond. Elle fixe l'ordre des décisions : ce qu'on écrit avant de choisir un outil, jusqu'où on laisse l'agent agir, quelles briques on assemble, et à quoi on reconnaît qu'il est prêt.

Elle suppose acquis le cadre général de notre panorama des agents d'IA, dont elle reprend les quatre niveaux de droits et les sept familles d'agents.

Ce qu'il faut avoir écrit avant de construire un agent

Un agent n'apporte de valeur que s'il exécute dans votre environnement (données, outils, processus) et si vous pouvez prouver ce qu'il a fait. Avant de brancher la moindre API, définissez un cadre de pilotage mesurable : limites d'action, indicateurs suivis, traçabilité complète. Sans cela, vous « automatisez » sans rendre l'autonomie acceptable.

Formalisez ces pré-requis en une page, celle que vous relirez dans six mois pour arbitrer entre ses droits et ce qu'on lui demande.

• Objectif : un résultat observable (réduire le temps de tri des anomalies techniques, accélérer la mise à jour des pages à fort impact).
• Données : sources autorisées, fréquence de mise à jour, qualité minimale.
• Droits d'accès : lecture seule ou écriture, environnements séparés (dev/staging/prod), principe du moindre privilège.
• Critères de réussite : indicateurs avant/après (délais, taux d'erreur, volume de recommandations acceptées).

Deux décisions se prennent à ce moment-là, et pas plus tard : l'agent lit tout mais écrit peu, dans un cadre contrôlé ; ses droits sur vos outils de publication restent limités aux brouillons tant que la boucle de mesure n'a pas été validée. Ces règles coûtent peu au départ et deviennent presque impossibles à imposer après un premier succès.

Choisir le niveau d'agentivité, et où l'agent s'arrête

La plupart des échecs viennent d'un mauvais « niveau d'agentivité » : trop autonome trop tôt, ou pas assez outillé pour agir. Un agent perçoit un contexte, raisonne selon un objectif et agit via des outils (API, fichiers, tickets) ; ce qui le sépare d'un assistant, c'est l'orchestration d'actions traçables. Réduisez l'ambition, puis industrialisez : le bon niveau dépend de trois facteurs.

• Le risque : image de marque, conformité, caractère irréversible des actions.
• La complexité : nombre d'étapes et de sources à concilier.
• L'accès aux outils : ce que l'agent peut réellement lire ou modifier.

Quatre niveaux, du diagnostic à l'autonomie encadrée

L'autonomie n'est pas binaire : elle se règle, et par écrit. Chaque niveau engage un dispositif de contrôle différent, et c'est ce dispositif, pas la capacité du modèle, qui décide de ce que vous pouvez déployer. Ces quatre paliers correspondent aux quatre niveaux de droits d'un agent d'IA du panorama.

Le passage d'un niveau au suivant se décide sur les journaux d'exécution du niveau précédent. Un agent qui a tenu trois semaines en supervision sans arrêt automatique a démontré quelque chose ; un agent « plutôt bon » n'a rien démontré.

Les seuils d'arrêt, et pourquoi la chaîne doit rester courte

La fiabilité ne se dégrade pas proportionnellement au nombre d'étapes : elle s'effondre quand la chaîne s'allonge, chaque étape héritant des approximations de la précédente. Réduisez donc les étapes et externalisez les vérifications dans du code et des règles plutôt que dans le modèle.

Votre conception doit aussi dire où l'agent s'arrête et ce qui se passe alors : un arrêt propre, puis un transfert vers un humain avec le contexte, jamais une relance aveugle. Les cas d'arrêt sont toujours les mêmes.

• Preuve insuffisante : le signal existe, mais la mesure qui le justifie manque.
• Incohérence : deux sources se contredisent sur la même donnée.
• Action irréversible : l'effet ne pourrait pas être annulé.

Un agent qui ne sait pas s'arrêter n'est pas un agent autonome : c'est un agent que personne ne surveille.

Les quatre briques d'un agent : modèle, outils, mémoire, orchestration

Construire un agent robuste revient à séparer « penser » et « agir », puis à instrumenter chaque étape. Le modèle interprète, planifie et produit des sorties structurées ; vos règles métier s'écrivent dans du code et des seuils, où elles restent lisibles, testables et modifiables sans toucher au modèle. Ce découpage rend le comportement reproductible.

La boîte à outils et la mémoire : ce que l'agent lit, ce qu'il retient

Un agent n'exécute que s'il peut appeler des outils, et chaque outil expose des fonctions limitées, documentées et contrôlées par permissions : un catalogue de fonctions étroites et auditables, en trois catégories.

• Connecteurs de données : extraction des mesures, inventaire des pages, gabarits éditoriaux.
• Fonctions d'action : créer un ticket, proposer un correctif, créer un brouillon, demander une validation.
• Validateurs : schémas de sortie, règles de cohérence, seuils de risque.

Côté mémoire, la mémoire courte tient le fil de la tâche en cours ; la mémoire persistante capitalise (décisions, exceptions, préférences), mais elle augmente les enjeux de conformité et de sécurité. Quand l'agent décide à partir de documents internes, l'ancrage contrôlé sur un corpus est le sujet de l'agent d'IA avec RAG.

La boucle plan → action → observation → décision

Une boucle agentique robuste ressemble à un système de contrôle : elle observe, décide, agit, puis re-observe. Séparez une boucle « plan », qui propose une liste d'actions, et une boucle « exécution », qui applique une action à la fois en vérifiant les préconditions et en journalisant l'effet.

• Plan : sélectionner une action prioritaire candidate et produire une sortie structurée stricte.
• Action : exécuter via un connecteur, avec idempotence.
• Observation : collecter les métriques et l'état, avant et après.
• Décision : continuer, escalader vers un humain, ou arrêter (seuil atteint, risque).

Cette séparation réduit la dérive et rend la supervision possible. Si vous codez cette boucle vous-même, structure, patrons et tests relèvent de l'agent d'IA en Python. Et quand le problème devient plusieurs agents, l'orchestration d'agents d'IA prend le relais.

Écrire la spécification et le protocole de décision

La qualité d'un agent dépend moins du modèle que de vos spécifications. En B2B, la traçabilité est un prérequis d'acceptabilité, pas un bonus. Rien n'impose d'écrire du code : la même spécification se tient dans un constructeur visuel, et c'est son contenu qui protège. Un agent devient imprévisible dès qu'il ignore trois choses.

• Quoi produire : le format de sortie attendu.
• Quand s'arrêter : les seuils qui déclenchent l'arrêt ou l'escalade.
• Comment prouver : les journaux qui relient l'action à sa décision.

La spécification, un contrat entre le modèle, vos outils et votre équipe

Une spécification d'agent est un contrat entre le LLM, vos outils et votre équipe. Elle réduit l'ambiguïté, donc les dérives, et rend les tests automatiques possibles. Écrivez-la avant d'automatiser, en quatre rubriques.

Une spécification qui tient sur une page vaut mieux qu'un document exhaustif que personne ne relira. Le test : un collègue étranger au projet doit pouvoir dire, en la lisant, si une sortie est conforme.

Le protocole de décision : scoring, règles métier et garde-fous

Un agent utile ne « recommande » pas au hasard : il arbitre. Votre protocole doit rendre la décision explicable et stable, même quand le modèle varie, grâce à trois mécanismes.

• Scoring : impact estimé, effort, risque, dépendances, urgence.
• Règles métier : interdits (pages légales), seuils (trafic minimal), fenêtres (gel de version).
• Garde-fous : arrêt si preuve insuffisante, si incohérence de données, ou si action irréversible.

Écrit ainsi, le protocole devient contestable : une décision peut être rejouée, discutée, puis corrigée en modifiant une règle, pas en réécrivant un prompt en espérant que le comportement change.

Traiter l'erreur et prouver ce qui a été fait

Les erreurs ne sont pas des « exceptions » : interfaces indisponibles, quotas atteints, contenus incomplets et formats inattendus sont le fonctionnement normal. Une architecture robuste formalise la reprise au lieu de relancer aveuglément ; le dessin de ces branchements étape par étape est le sujet de l'agent d'IA en workflow. Cinq mécanismes sont à prévoir.

• Délais d'attente : couper proprement, puis escalader.
• Nouvelles tentatives : seulement si l'erreur est transitoire, et en nombre limité.
• Idempotence : identifiant d'opération unique pour éviter les doublons.
• Retour arrière : annuler, rétablir, ou créer un ticket de correction.
• Transfert : passer la main à un humain avec contexte, journaux et proposition de résolution.

Journaliser la décision, pas seulement l'action

Sans journaux, vous ne pouvez ni déboguer ni convaincre. Journalisez l'action, mais aussi la décision et ses preuves, et versionnez prompts et règles : sinon, impossible de dire ce qui a changé entre une exécution correcte et une exécution ratée.

• Exécution : identifiant, horodatage, entrée et sortie, modèle utilisé.
• Décision : scores, règles appliquées, seuils déclenchés.
• Preuves : état avant/après, mesure d'origine, page concernée.
• Versionnage : prompts, schémas, connecteurs, règles, configuration.

Les deux premiers objets servent celui qui doit corriger l'agent ; les deux derniers, celui qui doit autoriser l'élargissement du périmètre. Des journaux purement techniques ne font jamais franchir l'étape du comité.

Classer les données, et fermer ce que l'agent n'a pas à ouvrir

66 % des utilisateurs se fient aux sorties d'une IA sans en vérifier l'exactitude (Squid Impact, 2025). La vérification doit donc être portée par le système, pas par la bonne volonté : liste blanche de fonctions, validation stricte des entrées contre les contenus piégés, secrets hors du code. Comptes de service, droits par environnement et rotation des secrets sont détaillés dans l'intégration d'un agent d'IA. Classifiez enfin les données en trois catégories avant de les intégrer.

• Admis sous conditions : métriques agrégées, URL publiques, extraits non sensibles.
• Interdit : données personnelles, secrets, identifiants, documents internes non anonymisés.
• À valider : journaux détaillés, contenus avant publication, données clients.

Recetter avant de lâcher la main, puis surveiller

56 % des utilisateurs déclarent avoir commis des erreurs à cause de l'IA (Squid Impact, 2025). C'est le jeu de cas qui révèle le taux d'erreur résiduel, jamais la démonstration, qui ne montre que le chemin nominal. Testez comme un logiciel : la question n'est pas « est-ce que ça marche », mais « que se passe-t-il quand ça ne marche pas ».

Jeux de cas, critères d'acceptation et non-régression

La recette d'un agent se prépare comme celle d'un composant logiciel, avec trois volets. Ils tiennent dans un document unique, relu à chaque changement de prompt, de règle ou de connecteur.

• Jeux de cas : pages « normales », pages sensibles, données manquantes, quotas atteints.
• Critères d'acceptation : taux de sorties valides, taux d'escalade, taux d'actions refusées correctement.
• Non-régression : même entrée → même décision, dans un intervalle acceptable.

Le troisième volet est celui qu'on oublie, et le plus discriminant : un agent dont la décision varie sur une entrée identique n'est pas prêt. Le refus correct d'une action interdite est un résultat de test au même titre qu'une réussite.

Ce qu'on surveille une fois en production

Sans métriques, impossible de piloter. Surveillez trois familles d'indicateurs, et distinguez bien le coût d'inférence du coût opérationnel (maintenance, incidents, validation humaine), car le second décide de la rentabilité réelle.

• Métriques agent : taux de réussite par étape, latence, taux d'escalade vers un humain.
• Métriques métier : volume traité, backlog résolu, effet mesuré sur une période cohérente.
• Coûts : appels modèle, appels d'API, stockage, supervision.

Un agent vieillit vite : interfaces, règles et gabarits bougent. Prévoyez la maintenance comme une charge récurrente, pas comme un incident, et déployez un petit périmètre d'abord, avec un plan de retour arrière.

Un exemple déroulé : de la détection à un backlog exécutable

Prenons une équipe contenu qui veut confier à un agent la détection des pages à retravailler. Le point difficile n'est pas de « détecter » : c'est de prioriser sans biais et de relier la décision à un enjeu réel. Commencez par une carte de signaux, chacun relié à une preuve mesurable et à une action.

Un signal sans preuve reste une intuition, qui n'entre pas dans un backlog. La priorisation doit ensuite survivre à la réalité : un scoring simple, réplicable et contestable, sans score « magique ». Le facteur risque protège les pages critiques d'une optimisation correcte techniquement mais absurde commercialement.

Enfin, l'ordre d'exécution compte : séquencez par dépendances et par gains rapides à faible risque, pour valider la boucle de mesure avant d'augmenter la portée, lot par lot.

• Lot 1 : corrections techniques à faible risque, avec des métriques faciles à suivre.
• Lot 2 : optimisations de contenu avec validation humaine systématique.
• Lot 3 : production de brouillons et publication contrôlée sur des périmètres non critiques.

Continuez votre lecture

La méthode se décline selon votre contexte d'équipe et d'outillage.

• Vous voulez valider la méthode sans mobiliser d'équipe technique : la démarche complète, du premier test à la mise à l'échelle, est celle de l'agent d'IA no-code.
• Votre contexte impose l'auditabilité ou un hébergement maîtrisé : licences, souveraineté et charge d'exploitation se comparent sur l'agent d'IA open source.
• Vos équipes travaillent déjà dans l'éditeur et veulent y faire agir l'agent : ce qu'il fait sur un dépôt ouvert et ce qu'il faut lui interdire relèvent de l'agent d'IA dans VS Code.
• Vous devez juger un projet d'agent existant ou le déclencher depuis votre intégration continue : c'est le terrain de l'agent d'IA sur GitHub.
• La méthode est arrêtée et il reste à choisir avec quoi construire : modèles, éditeurs et outils d'automatisation se comparent sur une plateforme d'agent d'IA.

Et si le point qui vous bloque est la première puce de vos pré-requis, des sources de données autorisées, à jour et cohérentes, c'est une plateforme de pilotage GEO et SEO qui traite cette tâche.

FAQ : questions fréquentes sur la création d'un agent d'IA

Quels types d'agents IA peut-on créer selon les usages ?

Les types d'agents qu'on peut créer sont les sept familles décrites dans notre panorama des agents d'IA, des agents réflexes simples aux systèmes multi-agents. Un projet d'équipe marketing ou contenu relève presque toujours d'un agent orienté tâches utilisant des outils, dont l'autonomie se règle ensuite avec les quatre niveaux de droits.

Est-il possible de créer sa propre IA ?

Oui, vous pouvez concevoir votre propre agent en assemblant un modèle de langage, une orchestration et des outils, avec vos données et vos règles. Entraîner un modèle de fondation de zéro est un projet très différent, coûteux et rarement pertinent pour une équipe marketing : la voie réaliste construit autour d'un modèle existant.

Comment créer un agent d'IA simple ?

Un agent simple se crée sur une tâche non critique et une chaîne très courte, car la fiabilité se dégrade quand les étapes s'empilent. Définissez une entrée, une sortie structurée et une seule action outillée, puis faites valider chaque sortie par un humain, puis mesurez le temps gagné et les erreurs avant d'ajouter une étape.

Quelles étapes suivre pour créer un agent IA de bout en bout ?

Créer un agent de bout en bout suit sept étapes : pré-requis de pilotage, niveau d'agentivité et seuils d'arrêt, briques, spécification et protocole de décision, traitement de l'erreur et journalisation, recette sur jeux de cas, puis déploiement par petits périmètres. La recette est l'étape la plus souvent sautée, et c'est elle qui sépare un prototype d'un agent exploité.

Quel est le coût d'un agent IA ?

Le coût d'un agent se décompose en appels au modèle, appels aux interfaces tierces, stockage, supervision humaine et maintenance des connecteurs et des règles. Ce dernier poste est sous-estimé, car un agent vieillit à chaque changement d'API ou de gabarit : partez d'un périmètre étroit et élargissez quand le coût opérationnel est connu.

Peut-on créer un agent IA en local sans exposer ses données ?

Oui, un agent peut tourner en local, mais « local » ne veut pas dire « sans risque ». Le fonctionnement local réduit l'exposition des données si les accès sont sécurisés et l'hébergement conforme, au prix d'une maintenance plus lourde. La minimisation des données envoyées au modèle et la journalisation restent les mêmes.

Quelle architecture choisir entre mémoire persistante et exécution « stateless » ?

L'exécution « stateless » convient aux tâches courtes et fortement testables, quand on veut réduire l'exposition de données. La mémoire persistante s'impose pour la personnalisation, l'historique et l'apprentissage opérationnel, au prix d'une sécurité renforcée. Le compromis fréquent garde une mémoire « métier » (décisions, tickets, règles) et limite la mémoire conversationnelle.

Comment évaluer la fiabilité d'un agent avant de le laisser exécuter en autonomie ?

La fiabilité d'un agent s'évalue sur des scénarios multiples, avec des taux d'erreur mesurés par étape et un humain dans la boucle au démarrage. Vérifiez que le format de sortie est respecté, que la preuve est présente et qu'une action interdite est bloquée, puis élargissez l'autonomie aux seules actions à faible risque et répétitives, sur la foi des journaux.