Comment créer un agent IA ? Frameworks, étapes et pièges à éviter

Article 2/4 de la série « Agents IA » — Qu'est-ce qu'un agent IA ? · Agents IA dans l'équipe (à venir) · Agents IA face aux organisations (à venir)

Vous savez ce qu'est un agent IA. Maintenant, construisons-en un. Pas en théorie — en production, avec un cas concret et les erreurs que j'aurais aimé éviter.

La semaine où j'ai mis mon premier agent en production, il m'a coûté 40 dollars en tokens en une nuit. Pas parce qu'il marchait mal — parce qu'il marchait trop bien. Une boucle de relance automatique mal bornée sur une API temporairement indisponible : l'agent tournait en boucle, le compteur de tokens montait, et personne ne regardait.

C'est la leçon que j'ai tirée le plus vite : construire un agent IA, ce n'est pas un projet de data science. C'est un projet d'architecture. Les erreurs les plus coûteuses ne sont pas techniques — elles sont structurelles.

Dans le premier article de cette série, j'ai posé les bases : le cycle ReAct, les quatre briques (mémoire, planification, outils, action), la différence entre un chatbot et un agent. Ici, on passe au concret. Comment j'ai construit trois agents qui tournent en production sur ma stack personnelle, quels frameworks j'utilise, et surtout : les pièges que personne ne mentionne dans les tutoriels.

Choisir son framework — ou pas #

Le réflexe naturel quand on veut construire un agent, c'est de comparer les frameworks. LangGraph, CrewAI, Claude Agent SDK, OpenAI Agents SDK — le marché en propose une dizaine, chacun avec ses promesses.

Mais voici ce que personne ne dit dans les tutoriels : vous n'avez pas besoin d'un framework pour construire votre premier agent.

Un agent, dans sa forme la plus simple, c'est un LLM (grand modèle de langage) + un prompt système bien construit + un outil (comme la recherche web). Mistral Le Chat, ChatGPT ou Claude permettent de créer ça en quelques clics — sans écrire une ligne de code. C'est le meilleur point de départ.

Le paysage en 2026 #

Les frameworks deviennent utiles quand les besoins se complexifient :

La progression naturelle : on commence sans code pour valider le cas d'usage, puis on migre vers un framework quand les limites apparaissent — pas avant. Trop de projets échouent parce qu'ils ont choisi l'infrastructure avant de valider le besoin.

Mistral Vibe : un cas à part #

Mistral Vibe n'est pas un framework d'agents au sens strict. C'est un agent de code — un outil en ligne de commande, piloté par le modèle Devstral 2, qui implémente du code à partir d'instructions en langage naturel. Concrètement, c'est le marteau, pas le menuisier : il exécute le code, mais c'est un autre programme (l'orchestrateur) qui décide quand l'appeler et vérifie le résultat. Et c'est la seule alternative européenne crédible dans cet espace.

Cinq étapes pour construire un agent qui tient en production #

Étape 1 : Définir l'objectif en termes de résultat, pas de technologie #

« Déployer un agent IA » n'est pas un objectif. « Réduire le temps de production d'une page web de 4 heures à 20 minutes » en est un.

Chaque agent que j'ai mis en production répond à une mission formulée en une phrase :

• Agent Figma → Code : « Transforme un frame Figma en composant web fonctionnel, vérifié visuellement, en moins de 10 minutes. »
• Agent PRD : « Produis un PRD (Product Requirements Document — cahier des charges produit) structuré à partir de notes de discovery brutes, en moins de 15 minutes. »
• Agent Audit Digital : « Génère un rapport d'audit de la présence digitale d'une entreprise en moins de 10 minutes, à partir de son URL. »

Si vous ne pouvez pas formuler la mission en une phrase avec un livrable et un délai, vous n'avez pas encore un cas d'usage d'agent — vous avez une envie de technologie.

Étape 2 : Choisir les outils que l'agent va piloter #

Un agent sans outils est un cerveau sans bras. Mais un agent avec trop d'outils devient imprévisible — il choisit le mauvais outil au mauvais moment, ou enchaîne des appels inutiles qui font exploser le coût.

Ma règle : maximum 5 outils par agent. Au-delà, je divise en sous-agents spécialisés.

Pour mes trois agents en production :

Agent Figma → Code :

• Connecteur Figma via MCP (Model Context Protocol — lecture de la maquette)
• Mistral Vibe (génération du code)
• Navigateur headless (screenshot pour vérification)
• Comparaison visuelle (diff pixel entre maquette et rendu)

Agent PRD :

• Lecture de fichiers (notes de discovery, transcripts)
• Recherche web (benchmark concurrence, données marché)
• Génération structurée (template PRD avec sections obligatoires)

Agent Audit Digital :

• Analyse technique (stack, headers sécurité, performance)
• Analyse SEO (meta tags, structure, vitesse)
• Recherche web (présence sociale, avis, offres d'emploi)
• Génération de rapport (synthèse structurée)

Entre 3 et 4 outils par agent — assez pour couvrir la mission, pas assez pour que l'agent se perde. Chaque outil a un rôle précis, et l'agent enchaîne les étapes sans intervention humaine entre elles.

Étape 3 : Designer le prompt système et les garde-fous #

Le prompt système est la constitution de votre agent. C'est le document qui définit ce qu'il peut faire, ce qu'il ne doit jamais faire, et comment il doit réagir quand les choses tournent mal.

Trois blocs non négociables :

L'identité et la mission — Qui est l'agent, quel est son objectif, quel est le livrable attendu. Plus c'est spécifique, moins l'agent dérive.

Les contraintes et interdictions — Ce que l'agent ne doit jamais faire. Pour mon agent Figma → Code : ne jamais modifier le fichier Figma source (maintenant que le MCP le permet l'erreur est vite arrivée), ne jamais déployer en production, toujours soumettre le résultat à validation avant livraison. C'est le prompt injection — la vulnérabilité #1 des agents — qui rend ces garde-fous critiques.

Les règles de dégradation — Que fait l'agent quand un outil ne répond pas ? Quand le résultat est incohérent ? Quand il a consommé plus de X tokens sans progresser ? Sans ces règles, c'est la boucle infinie à 40 dollars (minimum)la nuit.

Étape 4 : Tester en sandbox avant toute mise en production #

Un agent qui fonctionne en démo ne fonctionne pas forcément en production. Les conditions changent : les API ont des limites de débit, les fichiers d'entrée ne sont pas toujours propres, le réseau tombe.

Mon protocole de test :

1. Tests unitaires par outil — Chaque outil est testé isolément avec des entrées normales et des entrées dégradées (fichier corrompu, API en timeout, réponse vide).
2. Tests de bout en bout — L'agent complet est lancé sur 10 cas représentatifs, avec des variations (maquette simple vs complexe, URL valide vs redirigée, notes structurées vs brouillon).
3. Tests de coût — Je mesure le nombre de tokens consommés par mission type. Si un agent dépasse 100 000 tokens pour une tâche simple, c'est qu'il tourne en boucle. Je fixe un plafond de tokens par exécution — un circuit breaker (disjoncteur automatique) qui tue l'agent s'il dépasse le budget.
4. Tests adversariaux — J'injecte des données malveillantes dans les entrées pour vérifier que les garde-fous tiennent. Un contenu web qui tente un prompt injection, un fichier qui contient des instructions cachées.

Étape 5 : Déployer avec human-in-the-loop #

Aucun de mes agents ne tourne en autonomie complète. Chacun a un point de validation humaine avant l'action finale.

L'agent Figma → Code génère le composant, fait le screenshot, produit le diff visuel — puis me montre le résultat avant de créer le commit. L'agent PRD produit le document — puis attend ma relecture avant de le partager. L'agent Audit génère le rapport — puis attend ma validation avant envoi.

Ce n'est pas de la prudence excessive. C'est de l'architecture. Un agent autonome qui envoie un rapport d'audit contenant une erreur factuelle détruit la crédibilité qu'il était censé construire. Le human in the loop n'est pas un frein — c'est un filet de sécurité qui permet de donner plus d'autonomie à l'agent sur tout le reste.

Mettre les mains dedans : un premier agent en un week-end #

Vous avez lu les cinq étapes. Vous pourriez lire encore trois articles, comparer cinq frameworks et regarder dix tutoriels YouTube. Ou vous pourriez ouvrir Mistral Le Chat et construire votre premier agent dans l'heure.

Le meilleur moyen de comprendre comment fonctionne un agent IA, ce n'est pas de lire la documentation — c'est d'en construire un, de le tester, de voir où il casse, et de corriger. Le prompt que je partage ici n'est pas une destination. C'est un point de départ. Prenez-le, cassez-le, modifiez les filtres, changez le secteur, voyez ce qui change. C'est en tordant le prompt que vous comprendrez ce qui fait qu'un agent tient — ou dérive.

Le cas : créer un agent de veille réglementaire avec Mistral Le Chat #

Dans l'article précédent, j'évoquais la veille réglementaire comme cas d'usage typique d'un agent : surveiller les publications officielles, filtrer ce qui concerne votre secteur, produire un résumé structuré. Deux heures de travail humain chaque matin, compressées en quelques minutes.

Construisons-le. Pas avec un framework, pas avec du code — avec Mistral Le Chat, qui permet de créer un agent personnalisé en quelques clics. Un seul agent, un outil (la recherche web native), un objectif borné. Le prompt complet est disponible sur GitHub (agent-veille-reglementaire) — vous pouvez le copier-coller et l'adapter à votre secteur.

Étape 1 appliquée — L'objectif en une phrase #

« Analyser les dernières publications officielles et produire un résumé des textes qui concernent le numérique dans le secteur public, avec pour chacun : l'essentiel en trois lignes, le niveau d'impact et le lien vers la source. »

Pas « surveiller toute la réglementation française ». Pas « produire une analyse juridique ». Un périmètre serré — un secteur, un type de source, un livrable défini.

Étape 2 appliquée — Un seul outil, bien utilisé #

L'agent utilise la recherche web native de Mistral Le Chat. Pas besoin de connecteur API, pas de base de données vectorielle. Il consulte les sources officielles (Légifrance, CNIL, ANSSI, DINUM, Commission européenne), extrait le contenu et produit la synthèse.

Dans le prompt système, on liste explicitement les sources à consulter. C'est la version minimaliste de l'étape 2 — un seul outil, mais bien cadré.

Étape 3 appliquée — Le prompt système et les garde-fous #

C'est là que se joue la qualité de l'agent. Le prompt définit trois choses.

Les critères de filtrage — l'agent ne retient que les textes qui touchent à l'accessibilité numérique (RGAA), la cybersécurité (NIS2), les données personnelles (RGPD), l'intelligence artificielle (IA Act), la dématérialisation ou l'open data. Tout le reste est ignoré, même si c'est récent.

La grille d'impact :

Les garde-fous — et c'est ici que le premier test m'a corrigé. Lors de mes essais, l'agent remontait des textes publiés des mois plus tôt, simplement parce qu'ils apparaissaient dans les résultats de recherche récents. J'ai dû ajouter une règle explicite : « Ne te fie jamais à la date d'indexation — seule la date affichée sur la page source fait foi. Si la date n'est pas vérifiable, ne l'inclus pas. »

Autres garde-fous : ne jamais donner d'avis juridique (résumer, pas trancher), toujours citer la source avec un lien vérifiable, et surtout — produire un résumé vide quand il n'y a rien à signaler. Un agent qui trouve toujours quelque chose, même quand il n'y a rien, est un agent qui hallucine pour justifier son existence.

Étape 4 appliquée — Tester sur cinq jours variés #

Ne testez pas sur un jour calme où rien n'a été publié. Choisissez cinq jours variés :

1. Un jour avec une publication directement pertinente (test de détection)
2. Un jour chargé en publications hors périmètre (test de filtrage — l'agent doit ignorer)
3. Un jour avec un texte ambigu, à la frontière du périmètre (test de jugement)
4. Un jour sans aucune publication pertinente (l'agent doit produire un résumé vide, pas inventer)
5. Un jour avec un texte long et complexe (test de synthèse — le résumé tient-il en trois lignes ?)

Le cas 4 est le plus révélateur. C'est le même réflexe que le consultant qui allonge ses livrables pour remplir le PowerPoint — sauf que l'agent, lui, le fait sans mauvaise conscience.

Étape 5 appliquée — Le human in the loop #

L'agent produit le résumé. Vous le lisez avec votre café. Vous décidez si un texte mérite d'être transmis à l'équipe juridique, au DSI ou au COMEX (comité exécutif).

Le jour où le filtrage est fiable, vous ajoutez une brique : envoi automatique par email. Puis une autre : archivage dans une base de connaissances. Puis une autre : croisement avec votre registre de conformité pour identifier les écarts.

C'est la logique incrémentale. Santiago Fernández de Valderrama Aparicio, AI Product Manager, a appliqué la même approche à la recherche d'emploi automatisée : un agent qui évalue une offre est devenu un système à douze modes qui en a traité plus de 500, généré 354 CV personnalisés et envoyé 68 candidatures — pas en construisant tout d'un coup, mais en empilant des briques validées une par une.

Trois agents en production : retour d'expérience #

Agent 1 : Figma → Code → Vérification visuelle #

La mission : transformer un frame Figma en composant web fonctionnel, vérifié visuellement contre la maquette.

Le workflow :

1. L'agent lit le frame Figma via le serveur MCP Figma — il récupère la structure, les tokens de design, les composants référencés.
2. Il passe la spécification à Mistral Vibe, qui génère le code (HTML, CSS, composants).
3. Il ouvre le résultat dans un navigateur headless et capture un screenshot.
4. Il compare le screenshot avec la maquette Figma originale — alignement, couleurs, espacements, typographie.
5. Si le diff dépasse un seuil de tolérance, il identifie les écarts et relance Mistral Vibe avec des corrections ciblées.
6. Il itère (maximum 3 passes) jusqu'à convergence, puis me soumet le résultat.

Ce qui marche : sur des composants de complexité moyenne (card, section hero, formulaire), l'agent atteint un résultat publiable en 2 à 3 itérations. Le gain de temps est réel — ce qui prenait 2 à 4 heures manuellement prend 10 à 20 minutes.

Ce qui casse : les layouts complexes avec de nombreuses variantes responsives. L'agent converge sur le desktop mais diverge sur le mobile. J'ai appris à découper : un frame Figma = un composant = une exécution d'agent. Pas de page entière d'un coup.

Coût moyen : 30 000 à 80 000 tokens par composant, soit entre 0,50 € et 2 € selon le modèle et le nombre d'itérations. Sur Devstral 2 via Mistral Vibe, le coût est dans la fourchette basse.

Agent 2 : PRD express #

La mission : transformer des notes de discovery brutes (verbatims utilisateurs, transcripts d'interview, tickets support) en un Product Requirements Document structuré.

Le workflow :

1. L'agent ingère les fichiers d'entrée — notes en vrac, transcripts, captures d'écran annotées.
2. Il extrait les thèmes récurrents, les douleurs utilisateurs, les opportunités mentionnées.
3. Il recherche des données marché complémentaires (benchmark concurrence, tendances sectorielles).
4. Il structure un PRD complet : contexte, problème, persona cible, user stories avec critères d'acceptation, métriques de succès, risques et dépendances.
5. Il soumet le draft pour validation.

Ce qui marche : la capacité de synthèse est impressionnante. L'agent identifie des patterns dans les verbatims que je n'aurais pas vus manuellement — des corrélations entre douleurs utilisateurs et demandes de fonctionnalités qui ne sont pas évidentes quand on lit les notes une par une.

Ce qui casse : la priorisation. L'agent génère des user stories exhaustives mais ne sait pas distinguer le must-have du nice-to-have. C'est logique — la priorisation est un acte de jugement stratégique qui dépend du contexte business, pas des données d'entrée. C'est exactement là que le human in the loop prend tout son sens.

Coût moyen : 50 000 à 120 000 tokens selon le volume de notes en entrée. Entre 1 € et 3 €.

Agent 3 : Audit digital express #

La mission : générer un rapport d'audit complet de la présence digitale d'une entreprise à partir de son URL, en moins de 10 minutes.

Le workflow :

1. L'agent reçoit une URL et lance une analyse technique : stack technologique, headers de sécurité, score de performance, certificat SSL.
2. Il analyse le SEO : meta tags, hiérarchie des headings, vitesse de chargement, schema.org.
3. Il scrute la présence sociale : profils LinkedIn, Twitter/X, dernières publications, fréquence.
4. Il cherche les signaux complémentaires : avis clients (Google, Trustpilot), offres d'emploi en cours (signal de croissance ou de turnover), mentions presse récentes.
5. Il compile le tout dans un rapport structuré avec un score par dimension et des recommandations priorisées.

Ce qui marche : le rapport est bluffant en pré-meeting commercial ou en due diligence légère. En 10 minutes, j'ai une vision plus complète que ce que la plupart des consultants produisent en une demi-journée. Les signaux faibles sont souvent les plus utiles — les offres d'emploi qui révèlent un pivot stratégique, les headers de sécurité qui trahissent une infrastructure vieillissante.

Ce qui casse : les sites qui bloquent les robots. L'agent gère les cas classiques (Cloudflare, rate limiting) mais certains sites restent impénétrables. J'ai ajouté une règle de dégradation : si un domaine résiste, l'agent le signale dans le rapport au lieu de boucler.

Coût moyen : 40 000 à 100 000 tokens. Entre 0,80 € et 2,50 €.

Les pièges que personne ne mentionne #

Le piège du « ça marche en démo » #

Un agent qui réussit 8 démos sur 10 échouera 3 fois sur 10 en production. La différence : en démo, les entrées sont propres. En production, les maquettes Figma ont des calques mal nommés, les notes de discovery sont en franglais, les URLs redirigent trois fois.

J'ai appris à dimensionner mes tests sur les cas dégradés, pas sur les cas idéaux. Si l'agent tient sur des entrées sales, il tiendra partout.

L'hallucination en chaîne #

C'est le risque le plus sous-estimé. Un agent multi-étapes propage les erreurs : si l'étape 2 hallucine un fait, les étapes 3, 4 et 5 construisent dessus sans le remettre en question. Le résultat final a l'air cohérent — mais il est faux.

La parade : des checkpoints de vérification entre les étapes critiques. Mon agent PRD, par exemple, vérifie chaque source citée avant de passer à la structuration. Si une source n'est pas accessible, il la supprime au lieu de la garder.

Le coût qui explose faute de surveillance #

Un agent en boucle de relance sur une API indisponible peut brûler des centaines de dollars en quelques heures. Je l'ai vécu : 40 dollars de coût API en une nuit, parce qu'un agent tournait en boucle sur un service temporairement indisponible et que personne (moi) n'avait posé de disjoncteur. Quand on déploie plusieurs agents en parallèle, les dérapages de coût se multiplient vite.

Trois protections non négociables :

• Plafond de tokens par exécution — L'agent s'arrête automatiquement au-delà d'un seuil.
• Timeout par étape — Si un appel d'outil ne répond pas en 30 secondes, l'agent abandonne cette action et passe à un plan B.
• Budget quotidien — Au-delà de 10 euros par jour, toute exécution est suspendue et une alerte est envoyée.

Le shadow agentic #

C'est le dernier piège — et le plus organisationnel. Des collaborateurs déploient leurs propres agents IA via des outils no-code, sans supervision IT. Des agents connectés au CRM (outil de gestion de la relation client), à la messagerie, aux bases de données — sans garde-fous, sans monitoring, sans politique d'usage.

C'est le shadow IT version 2026. Sauf que le shadow IT classique ne pouvait pas envoyer des emails à vos clients, modifier vos données ou exfiltrer votre base contacts. Un agent mal configuré, si.

Si vous êtes CDO (Chief Digital Officer) et que vous n'avez pas encore de politique d'usage des agents IA, vous en avez déjà une — celle de vos équipes.

Ce que cet article ne couvre pas — et pourquoi #

J'ai volontairement laissé de côté deux sujets qui méritent chacun leur propre article.

Le premier, c'est le déploiement d'agents dans les équipes — pas sur une stack perso, mais dans une organisation avec des utilisateurs non-techniques, des processus existants et de la résistance au changement. C'est l'objet de l'article 3.

Le second, c'est la gouvernance : qui valide ce qu'un agent a le droit de faire ? Qui est responsable quand un agent se trompe ? Comment on audite un agent ? C'est l'article 4.

La série complète :

• Article 1 — Qu'est-ce qu'un agent IA ? Définition, architecture, exemples
• Article 2 (celui-ci) — Comment créer un agent IA ? Frameworks, étapes et pièges à éviter
• Article 3 — Agents IA dans l'équipe : cas d'usage concrets et premiers déploiements (à venir)
• Article 4 — Agents IA face aux organisations : gouvernance, autonomie et questions stratégiques (à venir)

Construire un agent, c'est finalement assez simple. Le faire tourner en production sans qu'il vous coûte une fortune, hallucine dans le vide ou envoie un email embarrassant à un client — ça, c'est le vrai métier.

Pour recevoir la suite dès sa publication, abonnez-vous au flux RSS ou suivez-moi sur mon profil LinkedIn.