Construire des agents IA qui fonctionnent vraiment
Un agent IA est un LLM avec la capacité de poser des actions. Au lieu de juste générer du texte, il peut appeler des API, interroger des bases de données, envoyer des messages, déclencher des workflows et prendre des décisions en boucle. La promesse, c'est l'automatisation : un système qui gère des tâches sans supervision humaine constante.
La réalité est plus nuancée. Les agents fonctionnent brillamment pour des tâches bien délimitées avec des frontières claires. Ils s'effondrent spectaculairement quand on leur donne des objectifs vagues, un accès illimité aux outils et aucune garde-fous. La différence entre un agent de démo et un agent de production n'est pas le LLM — c'est tout ce qui entoure le LLM.
Ce qu'est vraiment un agent
Enlève le hype et un agent a quatre composantes :
Le LLM reçoit une entrée (message utilisateur, déclencheur planifié, événement). Il décide quels outils appeler. Il les appelle via les serveurs MCP. Il reçoit les résultats. Il décide quoi faire ensuite. Cette boucle continue jusqu'à ce que la tâche soit terminée ou que l'agent décide de s'arrêter.
Simple en théorie. Le diable est dans chaque détail.
Construire un agent sur Zubnet
Sur la plateforme, créer un agent implique quatre étapes. Chacune a des décisions qui détermineront si ton agent fonctionne de façon fiable ou devient une source d'appels à 3 h du matin.
1. Créer l'agent
Donne-lui un nom, choisis un modèle et écris un prompt système.
Le modèle compte plus que tu ne penses. Pour les agents qui doivent appeler des outils de façon fiable, utilise un bon modèle de raisonnement. Claude Sonnet 4, GPT-4.1 ou Gemini 2.5 Pro. Les petits modèles économisent de l'argent mais prennent de moins bonnes décisions d'appel d'outils, et un mauvais appel d'outil dans un agent n'est pas juste une mauvaise réponse — c'est une mauvaise action.
Le prompt système est la constitution de ton agent. Sois explicite sur :
• Ce que l'agent devrait faire (et ce qu'il ne devrait jamais faire)
• Quand utiliser chaque outil et quand les ignorer
• Comment gérer les erreurs et l'ambiguïté
• Quand demander une clarification à l'utilisateur vs. prendre une décision
• Quel ton utiliser dans les messages
Être trop vague. “Tu es un assistant utile qui gère notre repo GitHub” mènera à un agent qui crée des issues aléatoires, ferme des choses qu'il ne devrait pas, et merge des PR sans review. “Tu peux créer des issues GitHub quand les utilisateurs signalent des bugs dans le canal #bugs. Tu ne dois jamais fermer des issues, merger des PR ou modifier les paramètres du dépôt.” — ça, c'est un prompt système qui produit un agent fiable.
2. Connecter un canal
Les canaux sont la façon dont les agents communiquent avec le monde. Sur Zubnet, tu peux connecter :
• Telegram — colle ton token de bot depuis @BotFather
• Discord — colle ton token de bot depuis le Discord Developer Portal
• Webhooks — n'importe quel endpoint HTTP qui peut envoyer/recevoir du JSON
Le canal détermine où vit l'agent. Un agent bot Telegram répond dans les chats Telegram. Un agent bot Discord vit dans ton serveur Discord. Un agent webhook répond aux appels d'API.
Choisis un seul canal pour commencer. N'essaie pas de construire un agent multi-canal le premier jour. Fais-le fonctionner de façon fiable sur une plateforme d'abord.
3. Ajouter des outils (serveurs MCP)
Les outils sont ce qui rend les agents plus que des chatbots. Sur Zubnet, les outils sont fournis par des serveurs MCP (Model Context Protocol). Nous en avons 117. Quelques exemples :
• GitHub — chercher des repos, créer des issues, lire des fichiers, lister des PR
• PostgreSQL / MySQL — interroger des bases de données (lecture seule si tu es malin)
• Brave Search — chercher sur le web
• Filesystem — lire et écrire des fichiers
• Slack — envoyer des messages, lire des canaux
Active les serveurs dont tu as besoin, configure leurs identifiants (clés API, URL de base de données), et l'agent peut les utiliser.
Ne donne aux agents que les outils dont ils ont vraiment besoin. Un agent qui peut chercher sur GitHub n'a pas besoin d'accès en écriture à la base de données. Un agent qui envoie des résumés quotidiens n'a pas besoin d'accès au filesystem. Chaque outil inutile est une surface d'attaque pour que les choses tournent mal.
4. Configurer les déclencheurs
Les déclencheurs déterminent quand l'agent s'active :
• Message utilisateur — répond quand quelqu'un envoie un message au bot (défaut pour les agents de chat)
• Cron — tourne à des heures fixées (ex., “tous les jours à 9 h”)
• Événement — se déclenche quand quelque chose de spécifique arrive (payload webhook qui correspond à un motif)
Les agents déclenchés par cron sont super pour les tâches récurrentes : résumés de standup quotidiens, rapports analytics hebdomadaires, vérifications de monitoring. Les agents déclenchés par événement gèrent les workflows réactifs : nouvelle issue GitHub → triage et étiquetage, nouveau ticket de support → rédaction d'une réponse.
Les parties difficiles
Construire l'agent prend 20 minutes. Le rendre fiable prend des semaines. Voici où les agents de production échouent vraiment :
Gestion d'erreurs : quand le LLM hallucine un appel d'outil
Les LLM appellent parfois des outils avec de mauvais paramètres, appellent des outils qui n'existent pas, ou appellent le bon outil dans le mauvais contexte. Ton agent doit gérer tout ça avec élégance.
Sur Zubnet, les appels d'outils échoués retournent des messages d'erreur au LLM, qui peut alors décider quoi faire. Mais il faut lui dire quoi faire dans le prompt système :
If a tool call fails:
1. Do NOT retry the same call with the same parameters
2. Analyze the error message
3. If it is a permission error, tell the user you cannot do that
4. If it is a rate limit, wait and try once more
5. If it is an unknown error, summarize what happened and ask for help
6. Never retry more than twice totalSans ces instructions, les agents restent bloqués dans des boucles de retry, brûlant des tokens et du temps sur le même appel qui échoue encore et encore.
Limites de débit : plafonds de fréquence
Un agent connecté à un serveur Discord occupé avec 500 utilisateurs actifs peut recevoir des centaines de messages par minute. Sans limitation de débit, il va :
• Épuiser ton budget de tokens API en quelques heures
• Atteindre les limites de débit du fournisseur et commencer à retourner des erreurs
• Générer tant de réponses que le canal devient inutilisable
Configure des plafonds de fréquence. Sur Zubnet, tu peux configurer :
• Max de réponses par minute (par canal)
• Max de tokens par heure (contrôle de budget)
• Période de cooldown entre les réponses au même utilisateur
• Limite de profondeur de file (abandonner les messages quand trop en retard)
Permissions : restreindre ce que les agents peuvent faire
C'est celle qui va te sauver des désastres. Les agents devraient avoir le minimum de permissions nécessaires pour leur travail.
• Outils de base de données : lecture seule sauf si des écritures sont spécifiquement nécessaires
• Outils GitHub : lecture + création d'issues, mais pas close/merge/delete
• Outils filesystem : répertoires spécifiques seulement, jamais /
• Outils de messagerie : canaux spécifiques seulement, jamais de DM aux dirigeants
Pense-y comme ça : quelle est la pire chose que cet agent pourrait faire avec les outils qu'il a ? Si la réponse te rend nerveux, réduis les permissions.
Dégradation élégante
Quand un outil est hors ligne, l'agent ne devrait pas crasher. Il devrait reconnaître la limitation et faire ce qu'il peut sans cet outil. Inclus ça dans ton prompt système :
If a tool is unavailable or returning errors:
- Acknowledge it to the user: "I cannot access GitHub right now"
- Do what you can without that tool
- Never make up data to compensate for a missing tool
- Suggest the user try again laterExemples réels
Exemple 1 : Bot de support
Un bot Telegram qui répond aux questions des clients en utilisant ta base de connaissances.
• Modèle : Claude Sonnet 4 (fort pour suivre les instructions)
• Outils : Brave Search (pour la doc), PostgreSQL (lecture seule, pour les recherches de compte)
• Canal : Telegram
• Déclencheur : Message utilisateur
• Limite de débit : 30 réponses/min, cooldown de 2 s par utilisateur
Le prompt système se concentre sur : répondre à partir de la doc d'abord, escalader à un humain si pas sûr, ne jamais partager les données d'autres clients, ne jamais faire de promesses sur les fonctionnalités ou les échéanciers.
Exemple 2 : Agent de résumé quotidien
Un bot Discord qui publie un résumé matinal de ce qui s'est passé pendant la nuit.
• Modèle : GPT-4.1 (bon pour les résumés structurés)
• Outils : GitHub (lire PR et issues), Slack (lire canaux)
• Canal : Discord (canal #daily-summary)
• Déclencheur : Cron, chaque jour de semaine à 9 h
• Limite de débit : 1 message par déclenchement (se déclenche une seule fois)
Le prompt système se concentre sur : résumer les PR mergées, issues ouvertes/fermées et discussions Slack clés. Garder sous 500 mots. Utiliser des puces. Mentionner les membres d'équipe pertinents.
Exemple 3 : Moniteur de contenu
Un agent qui surveille des événements spécifiques et alerte l'équipe.
• Modèle : Gemini 2.5 Pro (rapide, bon pour la classification)
• Outils : Brave Search (surveiller les mentions), Slack (envoyer les alertes)
• Canal : Webhook (déclenché par un service de monitoring)
• Déclencheur : Événement (webhook entrant avec résultats de recherche)
• Limite de débit : 10 alertes/heure (éviter la fatigue d'alerte)
Le prompt système se concentre sur : classer les mentions comme positives/négatives/neutres, n'alerter que sur les négatives ou critiques, inclure l'URL source et un résumé d'une phrase.
Tests : commence petit
Les agents Zubnet ont deux modes :
• Mode rapide — configuration simplifiée, bon pour les tests. Configuration d'outils limitée, déclencheurs basiques. Utilise-le pour valider que le concept de ton agent fonctionne du tout.
• Mode avancé — configuration complète, prêt pour la production. Prompts système détaillés, limites de débit granulaires, contrôles de permission, déclencheurs multiples.
Commence toujours en mode rapide. Fais fonctionner le comportement de base. Puis passe au mode avancé et ajoute les garde-fous.
• Envoie 20 messages normaux — répond-il correctement ?
• Envoie 5 messages qu'il devrait refuser — refuse-t-il ?
• Désactive un outil — se dégrade-t-il élégamment ?
• Envoie 50 messages en 1 minute — la limitation de débit fonctionne-t-elle ?
• Envoie un message dans une langue qu'il ne devrait pas supporter — le gère-t-il ?
• Demande-lui de faire quelque chose hors de son périmètre — reste-t-il dans sa voie ?
La vérité inconfortable sur les agents
Les agents ne sont pas magiques. Ce sont des LLM en boucle avec accès aux outils. Ils font des erreurs. Ils vont parfois faire la mauvaise chose. La question n'est pas “mon agent va-t-il faire une erreur ?” — c'est “que se passe-t-il quand il en fait une ?”
Les agents qui fonctionnent en production sont ceux avec :
• Un périmètre serré (“fais bien cette seule chose”)
• Des frontières explicites (“ne fais jamais ces choses”)
• Des permissions limitées (moindre privilège, toujours)
• Des limites de débit et de budget (éviter les coûts incontrôlés)
• Des voies d'escalade humaine (“en cas de doute, demande à un humain”)
• Du monitoring et des logs (pour savoir ce qui s'est passé)
Les agents sur Zubnet sont disponibles pour tous les utilisateurs. Commence avec un simple bot Telegram ou Discord, fais-le bien, puis élargis. L'infrastructure gère les parties difficiles — tu te concentres sur le prompt système, les outils et les garde-fous.
Prêt à construire ? Crée ton premier agent sur zubnet.com