Le Moment
Tous les dix ans environ, un nouveau langage de patterns émerge et change notre façon de construire des logiciels.
En 1994, le Gang of Four nous a donné les Design Patterns. En 2003, Hohpe et Woolf nous ont donné les Enterprise Integration Patterns. Depuis : Microservices Patterns, Cloud Patterns, et maintenant Agent Patterns.
Mais il manque quelque chose. Les agents peuvent discuter et raisonner seuls - mais ils ne peuvent pas « agir » sans outils. Des standards comme MCP ont résolu la façon dont les agents découvrent et appellent les outils. La couche protocole est réglée. Ce qui manque, c’est la couche design : des patterns pour construire des outils que les agents savent vraiment utiliser. C’est ça, le chaînon manquant.
Ce qu’on a appris
On a construit plus de 8 000 outils sur 100+ intégrations - le plus grand catalogue d’outils agent-ready en production. Pas des wrappers d’API. Des outils taillés pour la prod qui gèrent les cas limites : rate limits, pagination, refresh d’auth, échecs partiels.
Toutes les erreurs possibles - descriptions floues, messages d’erreur inutiles, paramètres qui nous semblaient logiques mais pas à un LLM -, on les a faites. On a appris que « fonctionnel » et « utilisable par un agent » ne sont pas la même chose.
Un outil peut renvoyer les bonnes données et rater quand même, parce que l’agent n’a pas su quand l’appeler.
Après des milliers d’itérations, des patterns ont émergé. On a construit des checklists internes, des processus de review, et finalement un framework pour livrer des outils de qualité de façon régulière. Pas de la théorie : ce qui marche quand on construit des outils que les agents utilisent vraiment.
On les a documentés. On les partage maintenant. Explorez le catalogue complet sur arcade.dev/patterns.
Le Changement de Paradigme
Pendant deux décennies, on a construit l’intégration autour d’un modèle simple : le middleware orchestre, les applications consomment. Les ESB routaient les messages. Les moteurs de workflow imposaient la séquence. La couche d’intégration décidait quoi, quand et dans quel ordre.
L’outillage agent fait s’effondrer toute cette couche. Plus de bus. Plus de workflow prédéfini. L’agent décide quel outil appeler, interprète les paramètres, gère la réponse et détermine la suite. La logique d’orchestration qui vivait dans votre middleware est maintenant émergente, reconstruite par l’agent à chaque invocation, sans garantie que ça se passe deux fois de la même façon.
Ce n’est pas de l’intégration traditionnelle avec un nouveau consommateur. C’est un type de consommateur entièrement nouveau, et les fondamentaux ont changé.
Aspect | Traditionnel (2003) | Outils Agent (2025+) |
Consommateur | Applications | Agents IA (LLMs) |
Modèle d'état | Messages sans état | Sessions avec état |
Routage | Flux prédéfinis | Sélection par l'agent (non déterministe) |
Gestion des erreurs | Dead letter queues | Guidance de reprise pour retry |
Documentation | Lisible par l'humain | Optimisée pour l'agent |
Composition | Orchestration ESB | Chaînage piloté par l'agent |
Quand un LLM choisit quel outil appeler, interprète les paramètres et décide quoi faire des erreurs, les contraintes de conception sont fondamentalement différentes. Les anciens patterns ne conviennent plus. Il en faut de nouveaux.
Alors par où commencer ? Par une façon de classer ce qu’on construit.
Trois axes de classification
Chaque outil existe quelque part dans trois dimensions. Comprendre où vous situez aide à choisir les bons patterns.
La maturité est l’axe vertical : le degré de sophistication de votre outil. Les outils atomiques font une seule chose : get_user(id). Les outils orchestrés en coordonnent plusieurs en gérant l’état entre les appels. On creusera cet axe dans le modèle de maturité ci-dessous.
L’intégration, c’est ce à quoi votre outil se connecte : APIs, bases de données, systèmes de fichiers ou opérations système. Chaque type apporte ses propres contraintes de conception. Les outils de base de données ont besoin du pattern Idempotent Operation, parce que les agents retentent sur timeout et votre outil doit gérer gracieusement les appels en double.
L’accès, c’est le mode d’exécution. Les outils synchrones sont simples : appel, attente, réponse. Mais un outil de génération de rapport qui bloque pendant 45 secondes va timeout ou bloquer l’agent. C’est là qu’intervient le pattern Async Job : l’agent appelle generate_report(), reçoit un job ID, et interroge check_status(job_id) jusqu’à la fin.
Vos coordonnées sur ces trois axes déterminent les patterns dont vous avez besoin. Un outil Composite × Database × Async a des exigences de conception très différentes d’un outil Atomic × API × Sync.
Préoccupations transversales
Savoir où se situe votre outil sur les trois axes vous indique lesquels des patterns considérer. Mais quatre préoccupations traversent tous les axes : l’expérience agent, les périmètres de sécurité, la reprise guidée par les erreurs et la composition d’outils. Ratez-les et peu importe à quel point vous avez bien classifié votre outil.
Expérience agent
Concevez pour le LLM, pas pour l’humain. Les descriptions d’outils, les noms de paramètres et les messages d’erreur doivent être optimisés pour la compréhension de l’agent.
Le pattern Parameter Coercion en est un bon exemple : un agent peut passer “2024-01-15”, “January 15” ou “yesterday” - votre outil accepte tout et normalise en interne.
Périmètres de sécurité
Les prompts expriment une intention, le code impose des règles. Ne faites jamais confiance à l’agent pour enforcer la sécurité. L’autorisation et les secrets doivent être gérés côté serveur.
Le pattern Context Injection transmet l’identité de l’utilisateur, les permissions et les credentials via un objet de contexte côté serveur, jamais par le LLM.
Reprise guidée par les erreurs
Les erreurs doivent instruire, pas seulement échouer. Quand ça tourne mal, fournissez une guidance actionnable. Que doit tenter l’agent ensuite ? Un 429 brut ne dit rien à un LLM. Une réponse qui dit « rate limited, réessayez dans 30 secondes ou réduisez la taille du batch à 50 » donne à l’agent une voie à suivre.
Composition d’outils
Les outils doivent bien se composer ensemble, comme des pipes Unix, pas comme une chaîne de commandement. Ça implique des formats de réponse cohérents pour que la sortie d’un outil alimente proprement l’entrée d’un autre, un support batch pour éviter les boucles un par un, et plusieurs niveaux d’abstraction pour que l’agent choisisse la bonne granularité.
Le panorama : 54 patterns, 10 catégories
Ces quatre principes - expérience agent, périmètres de sécurité, reprise guidée par les erreurs et composition d’outils - traversent tout. Ils se manifestent différemment selon l’outil, mais les questions qu’ils soulèvent sont universelles : comment les agents vont-ils comprendre ça ? Comment garder ça sécurisé ? Que se passe-t-il en cas d’échec ? Comment les outils s’articulent-ils sans se diriger mutuellement ?
On a organisé nos réponses en 54 patterns répartis en 10 catégories. Chaque catégorie répond à l’une de ces questions récurrentes :
| Catégorie | La question | Transversal avec |
|---|---|---|
| Types d’outils | Query, Command ou Discovery ? | (aucun) |
| Interface outil | Comment les agents vont-ils le comprendre et l’appeler ? | Expérience agent |
| Découverte outil | Comment les agents trouvent-ils le bon outil ? | Expérience agent |
| Composition outil | Faut-il regrouper les opérations ? | Maturité |
| Exécution outil | Sync, async ou transactionnel ? | Pattern d’accès |
| Réponse outil | À quoi doivent ressembler les résultats ? | Agent |
| Contexte outil | Comment identité et état sont-ils gérés ? | Périmètres de sécurité |
| Résilience outil | Comment récupère-t-il des échecs ? | Reprise guidée par les erreurs |
| Sécurité outil | Comment l’accès est-il contrôlé ? | Périmètres de sécurité |
| Intégration | Comment se connecte-t-il aux systèmes externes ? | Type d’intégration |
Chaque pattern inclut le problème qu’il résout, quand l’appliquer, les points d’implémentation et des exemples de code.
Le catalogue complet est sur arcade.dev/patterns.
Comment l’utiliser concrètement ?
Construire votre premier outil
Par où commencer dépend de deux choses : où se situe votre outil sur les trois axes, et à quel niveau de maturité vous êtes aujourd’hui.
Classifiez votre outil
Répondez à quatre questions : quel type : Query, Command ou Discovery ? Quelle intégration : API, base de données, système de fichiers ou système ? Quel pattern d’accès : sync, async, streaming ou event-driven ? Et quel niveau de maturité : opération unique ou workflow groupé ?
Trouvez votre niveau
Votre position sur l’axe de maturité vous indique par quels patterns commencer. N’over-engineerez pas : commencez atomique, observez comment les agents utilisent vraiment vos outils, et montez en niveau quand vous voyez les signaux dans vos traces.
Les signaux observables entre les niveaux sont des choses bien réelles que vous trouverez dans vos logs : des taux de retry élevés signalent que votre outil a besoin de meilleures descriptions et d’une meilleure guidance d’erreur. Des séquences d’outils répétées indiquent qu’il est temps de regrouper. Des completions partielles sur des opérations multi-étapes signifient que vous avez besoin de frontières transactionnelles et de compensation.
Rejoignez-nous
Ces patterns existent grâce à la rigueur d’ingénierie qui les sous-tend. L’équipe d’ingénierie d’Arcade.dev, notamment Eric, Renato, et Francisco , a créé des milliers d’outils et construit les processus de contrôle qualité qui ont transformé des leçons chèrement acquises en standards reproductibles.
Ce travail leur est dédié, ainsi qu’à la communauté plus large de l’ingénierie d’outils et MCP, et à chaque équipe qui a appris à la dure que « fonctionnel » et « utilisable par un agent » ne sont pas la même chose.
L’ensemble des patterns est sur arcade.dev/patterns. Chaque pattern inclut des diagrammes, des exemples de code et des points d’implémentation.
On publie ces patterns en accès libre parce que de meilleurs outils profitent à tout le monde. Quand l’écosystème construit de meilleurs outils, les agents deviennent plus capables. Quand les agents deviennent plus capables, plus de gens construisent avec eux. C’est l’avenir qu’on veut contribuer à créer.
Qu’avons-nous manqué ? Quels patterns avez-vous découverts qui ne sont pas là ? Où avons-nous tort ? Vos retours nous intéressent - envoyez-nous un message, dites-nous ce qui ne vous semble pas juste.
C’est un langage partagé. Aidez-nous à construire de meilleurs outils.
*Explorez le catalogue complet de patterns.
Les 54 patterns avec exemples, compromis et guide d’implémentation :* *arcade.dev/patterns*
*Prêt à construire ?
Arcade vous fournit le runtime, les outils et la couche d’auth pour livrer des agents qui fonctionnent vraiment en production.**Commencer*
