Comment créer un agent IA qui tient en production : les 6 étapes, du choix agent vs workflow aux permissions, souvent négligées par les tutoriels.
Créer un agent IA fonctionnel prend une après-midi avec Claude API et un outil comme n8n. Le vrai travail commence après : décider ce que cet agent a le droit de faire, et surtout ce qu'il n'a pas le droit de faire. La plupart des tutoriels sautent cette étape, et c'est exactement là que ça casse en production.
Ce guide déroule six étapes pour construire un agent IA solide, de la définition de la tâche jusqu'au monitoring, avec un focus sur le point que la majorité des guides zappent : les permissions.
1. Définir la tâche : agent ou simple workflow ?
Beaucoup de projets échouent avant même d'écrire une ligne de code, simplement parce qu'un agent a été choisi là où une fonction déterministe aurait suffi.
Tech Insider, Microsoft Agent Framework Setup, septembre 2026 "decide deliberately between an agent and a workflow rather than defaulting to whichever one you learned first. If you can write a plain function to handle a task deterministically, do that instead."
Le choix entre agent et workflow doit être délibéré. Si une tâche peut être résolue par du code classique, un if, une boucle, un appel API direct, inutile d'y greffer un LLM.
Un agent IA a du sens quand la tâche demande du raisonnement non déterministe : interpréter une demande client ambiguë, choisir entre plusieurs outils selon le contexte, s'adapter à une réponse imprévue. Si votre "agent" ne fait qu'enchaîner trois étapes fixes, appelez-le script. Ça coûtera moins cher, et ça plantera moins.
Piège : construire un agent avec boucle de raisonnement complète pour une tâche qui aurait tenu dans 15 lignes de code classique. Résultat : latence multipliée, coût qui grimpe, comportement moins prévisible qu'un simple
switch/case.
2. Choisir le modèle et l'architecture d'orchestration
Une fois la tâche validée comme réellement agentique, il faut choisir le modèle et la façon d'orchestrer ses appels d'outils.
Claude API reste un choix solide pour les cas qui demandent un raisonnement en plusieurs étapes, avec une boucle agentique native : l'agent décide lui-même s'il doit appeler un outil, lit le résultat, puis recommence. Côté orchestration, les frameworks type LangChain ou CrewAI structurent cette boucle avec des composants réutilisables, mais aucun ne dispense de définir précisément le périmètre d'action avant de coder quoi que ce soit.
Et c'est justement ce périmètre qui détermine si l'agent va tenir en production ou pas.
3. Connecter les outils via MCP plutôt que via des intégrations sur mesure
Le Model Context Protocol (MCP), standard ouvert introduit par Anthropic, permet à un agent de se connecter à des outils externes, bases de données, CRM, gestionnaires de mots de passe, via une interface unifiée plutôt qu'une intégration codée à la main pour chaque outil.
Le standard progresse vite. Fin septembre 2026, 1Password a publié un serveur MCP qui expose ses "Environments" à n'importe quel agent compatible, permettant à un agent Claude Code de récupérer des identifiants sans jamais les exposer en clair dans le code. Cursor, de son côté, a intégré les "Agent Skills", un format ouvert porté par Anthropic, directement dans son panneau de configuration, aux côtés des règles et des serveurs MCP.
Concrètement : au lieu de coder un connecteur maison vers chaque API, on décrit l'outil une fois dans un serveur MCP, et n'importe quel agent compatible peut s'en servir ensuite. On l'a déjà évoqué dans notre définition de l'agent IA, MCP est ce qui transforme un agent isolé en agent réellement connecté à un écosystème d'outils.
4. Limiter les permissions dès la conception, pas après coup
C'est là que la plupart des guides s'arrêtent trop tôt. Donner à un agent un accès complet "pour que ça marche du premier coup" est la décision qui coûte le plus cher six mois plus tard.
Hostinger, Tutoriel Claude, septembre 2026 "Match each agent's access to its actual role. If it only sends outbound messages, don't let it delete emails or change inbox rules."
L'accès d'un agent doit correspondre strictement à son rôle. Un agent qui répond aux emails clients n'a aucune raison de pouvoir en supprimer, ni de modifier les règles de la boîte.
Mais la vraie question n'est pas technique. Elle est organisationnelle : qui décide, dans l'équipe, du niveau de droits accordé à chaque agent ? Trois niveaux à trancher avant même d'écrire le premier prompt système :
| Niveau | Exemple concret | Risque si accordé trop vite |
|---|---|---|
| Lecture seule | Consulter le statut d'une commande | Aucun, c'est le défaut recommandé |
| Écriture limitée | Créer un ticket, envoyer un email | Doublons, spam |
| Écriture large | Modifier une base client, supprimer | Perte de données irréversible |
Un agent ne devrait jamais démarrer en écriture large. On monte les droits progressivement, une fois que le comportement en lecture seule a été observé sur des cas réels, pas sur des cas de démo.
5. Tester en bac à sable avant toute connexion réelle
Avant de brancher l'agent sur les vraies données, faites-le tourner sur un jeu de données de test, avec des logs complets de chaque décision qu'il prend. Un agent qui se comporte bien presque tout le temps en test peut se planter pile au moment où ça compte le plus en production, et ce sera souvent le cas le plus coûteux.
On avait creusé ce sujet dans notre article sur la sécurité des agents IA en production : les attaquants ciblent justement les agents mal cadrés, ceux à qui on a laissé plus de marge de manœuvre que nécessaire.
6. Monitorer, mesurer, itérer
Un agent IA n'est jamais "fini" au moment du déploiement. Suivez trois indicateurs dès le premier jour : le taux d'appels d'outils réussis, le coût moyen par tâche complétée, et le nombre d'interventions humaines nécessaires pour corriger une décision de l'agent.
Si ce dernier chiffre ne baisse pas après deux ou trois semaines, le problème n'est probablement pas le modèle. C'est le périmètre de la tâche qui est mal défini.
Conclusion
Construire un agent IA qui fonctionne en démo est devenu accessible en quelques heures. Le distinguer d'un agent qui tient en production demande trois choses : une tâche réellement agentique, des outils connectés via un standard comme MCP plutôt que du bricolage, et des permissions pensées avant le premier déploiement, pas après un incident.
Chez fstck, on accompagne les équipes qui veulent passer du prototype d'agent IA à un outil interne sur mesure réellement fiable. Si votre projet en est à cette étape, c'est le bon moment pour en discuter.
Questions fréquentes
Quelle différence entre un agent IA et un simple script d'automatisation ?
Un script suit une séquence fixe d'instructions. Un agent IA décide lui-même, à chaque étape, quel outil appeler et dans quel ordre, en fonction du contexte. Si le comportement est toujours identique quelle que soit l'entrée, ce n'est pas un agent, c'est un script déguisé.
Faut-il obligatoirement utiliser MCP pour connecter un agent à ses outils ?
Non, on peut coder des intégrations spécifiques par outil. Mais MCP évite de réécrire un connecteur pour chaque nouvel outil : le standard décrit une fois l'interface, et n'importe quel agent compatible peut s'en servir ensuite, y compris ceux qu'on ajoutera plus tard.
Combien de temps faut-il pour créer un agent IA basique avec Claude API ?
Un prototype fonctionnel, un agent qui appelle un ou deux outils via l'API Claude, se monte en quelques jours de développement. La partie qui prend réellement du temps n'est pas le code : c'est définir précisément le périmètre d'action et le tester avant de le connecter à des données réelles.
Comment limiter les dégâts si un agent IA prend une mauvaise décision ?
En amont, en limitant ses permissions au strict nécessaire pour sa tâche, lecture seule par défaut, écriture ajoutée progressivement. En aval, en gardant des logs complets de chaque décision, pour identifier et corriger rapidement l'origine du problème.
Un agent IA peut-il remplacer complètement un développeur sur une tâche métier ?
Pas dans la plupart des cas observés aujourd'hui. Un agent bien cadré automatise une portion répétitive d'une tâche, mais la définition du périmètre, la supervision et la correction des erreurs restent un travail humain, au moins pour l'instant.
