Agency Agents : guide du cadre open source

Agency Agents fournit une collection de rôles d’agents IA décrits par des fichiers de configuration, des processus et des livrables attendus. Nous expliquons comment l’utiliser avec Claude Code, Cursor et d’autres outils, comment organiser les rôles selon la taille de votre équipe et quelles capacités de sécurité, d’exécution et de contrôle doivent encore être ajoutées.

Donnée vérifiée le 13 août 2026 : le dépôt officiel annonce plus de 230 agents spécialisés et plus de 10 000 lignes de descriptions, de processus et d’exemples de code. (dépôt officiel Agency Agents)

Notre jugement : Agency Agents convient si vous cherchez des rôles prêts à adapter dans Claude Code ou Cursor. Il ne convient pas comme plateforme autonome de collaboration d’entreprise, car l’orchestration, l’isolation, les permissions et les validations restent à construire.

Nous avons préparé ce guide pour les développeurs indépendants qui veulent créer rapidement des agents de développement, de design, de test ou de marketing ; pour les équipes produit et logiciel qui évaluent une organisation par rôles ; ainsi que pour les responsables de l’automatisation qui envisagent de faire fonctionner des tâches d’agents dans un environnement distant et durable.

Agency Agents fournit-il une équipe ou seulement ses rôles ?

La distinction est essentielle. Agency Agents n’est pas un nouveau modèle de langage, ni un service qui attribue automatiquement les tâches au bon agent. Le projet fournit une collection de fichiers décrivant des spécialistes : leur identité, leur manière de raisonner, leurs procédures, leurs livrables et parfois leurs critères de réussite. Le dépôt officiel présente explicitement chaque agent comme une spécialisation réutilisable, installable dans plusieurs outils de développement.

Nous pouvons donc le résumer ainsi :

• Agency Agents fournit la couche « qui fait quoi » ;
• Claude Code, Cursor ou un autre outil fournit le moteur d’exécution ;
• l’équipe doit encore définir « quand », « avec quelles données » et « avec quelles permissions » ;
• un orchestrateur externe est nécessaire pour gérer une véritable chaîne multi-agents.

Cette architecture explique l’intérêt du projet. Un rôle de développeur frontend ne se contente pas de répondre « écrivez du React ». Il peut imposer une méthode d’analyse, proposer des livrables précis et rappeler des contrôles de qualité. Le fichier devient ainsi une forme de contrat comportemental.

Mais ce contrat reste une instruction. Il ne crée pas automatiquement :

• une file de tâches ;
• une mémoire partagée fiable ;
• un système de reprise après échec ;
• une séparation des secrets ;
• une journalisation complète ;
• un contrôle de coût ou de consommation ;
• une validation humaine avant fusion.

Le vocabulaire de « société d’agents IA » peut être parlant pour présenter le projet, mais il ne faut pas le transformer en promesse d’autonomie. Le dépôt fournit des spécialistes configurés, pas une entreprise numérique qui recrute, planifie, exécute et contrôle seule ses collaborateurs.

Que contient réellement un rôle spécialisé ?

Un rôle utile comporte généralement quatre couches.

La première est l’identité. Elle définit le domaine de compétence, le ton, les priorités et les limites. Un agent de design peut privilégier la cohérence visuelle et l’accessibilité, tandis qu’un agent de sécurité cherchera les surfaces d’attaque, les secrets exposés et les dépendances risquées.

La deuxième est le processus. Le rôle peut demander de commencer par inspecter le dépôt, de formuler des hypothèses, de distinguer les faits des suppositions et de proposer un plan avant toute modification.

La troisième est le livrable. Une réponse libre est difficile à contrôler. Un livrable comme une note d’architecture, un rapport de tests, une liste de risques ou un diff commenté est plus facile à relire et à transmettre au rôle suivant.

La quatrième est le critère de réussite. Le rôle doit préciser ce qui permet de considérer la tâche comme terminée : tests exécutés, fichiers modifiés listés, décisions justifiées, risques résiduels signalés ou documentation mise à jour.

C’est cette combinaison qui transforme un simple prompt en configuration de rôle. Elle ne garantit toutefois pas que le résultat sera exact. Le modèle utilisé, le contexte du projet, les permissions et la qualité de la demande restent déterminants.

Le dépôt officiel et son guide d’installation permettent de consulter les fichiers et de vérifier leur licence MIT. Le projet indique que les configurations peuvent être utilisées à titre personnel ou commercial, avec attribution appréciée mais non obligatoire.

Quel choix pour chaque taille d’équipe ?

Nous recommandons de ne pas installer tout le catalogue au premier jour. Le nombre de rôles disponibles n’est pas un indicateur de maturité opérationnelle. Plus les rôles sont nombreux, plus il devient difficile de savoir lequel a influencé une décision, lequel a modifié un fichier et lequel doit être corrigé après un échec.

Pour un développeur indépendant

Nous commencerions avec trois rôles seulement : un rôle de planification, un rôle d’exécution et un rôle de revue. Cette combinaison permet de tester la complémentarité sans transformer le projet en laboratoire d’administration d’agents.

Un rôle d’architecture peut analyser la structure du dépôt et proposer une solution. Un rôle d’implémentation peut réaliser une partie délimitée. Un réviseur peut vérifier le diff, les tests et les effets secondaires. Pour un projet audio, vidéo ou design, le même modèle fonctionne avec une recherche de références, une production de variante et une vérification de cohérence visuelle ou éditoriale.

L’objectif n’est pas de simuler une équipe complète. Il est de réduire une difficulté précise : comprendre le code, produire une première version, préparer une interface, rédiger une documentation ou contrôler une livraison.

Pour une équipe produit ou contenu

Une équipe produit peut organiser ses agents autour du chemin de décision :

1. recherche des besoins et des contraintes ;
2. formulation de l’opportunité ;
3. conception de la solution ;
4. production d’un prototype ou d’un contenu ;
5. contrôle de la qualité et des risques.

La règle à imposer est simple : chaque rôle doit recevoir une entrée identifiable et produire une sortie nommée. Une note de recherche ne doit pas être envoyée telle quelle à un agent de production sans indiquer les décisions retenues, les points incertains et les éléments à ne pas inventer.

Sans ce contrat d’entrée et de sortie, plusieurs personnalités peuvent générer des textes qui semblent différents mais qui répètent la même analyse. La diversité de ton n’est pas une diversité de raisonnement.

Pour le design, nous conseillons d’ajouter une contrainte visuelle concrète : format de livraison, état des composants, variantes mobile, contraste, hiérarchie et fichiers de référence. Pour la vidéo ou l’audio, le rôle de production doit également recevoir les contraintes de durée, de format, de licence des éléments utilisés et de validation éditoriale.

Pour une équipe de développement

Le découpage doit suivre le cycle logiciel, et non les noms attractifs des agents :

• planification : clarification du besoin, critères d’acceptation et plan de modification ;
• architecture : choix des interfaces, des données et des dépendances ;
• implémentation : modification d’un périmètre clairement défini ;
• tests : vérification fonctionnelle, régression et cas limites ;
• sécurité : secrets, permissions, dépendances et exposition réseau ;
• documentation : mise à jour des instructions, décisions et procédures.

Les tâches peuvent être parallélisées lorsqu’elles ne partagent ni fichiers critiques ni état mutable. Une recherche de dépendances, une proposition de tests et une analyse de sécurité peuvent avancer en même temps. En revanche, deux agents qui réécrivent le même module ne doivent pas travailler dans le même répertoire sans contrôle.

Nous utiliserions des branches ou des worktrees séparés, puis une porte de fusion commune : tests obligatoires, revue humaine, vérification des fichiers modifiés et contrôle des dépendances. Les fonctionnalités de règles de Cursor reposent elles aussi sur des fichiers de projet versionnés dans .cursor/rules, avec des modes d’application différents selon le contexte. (documentation officielle des règles Cursor)

Installation dans Claude Code et Cursor

Le dépôt propose plusieurs chemins. Le plus simple consiste à utiliser l’application native annoncée pour macOS, Linux et Windows, qui parcourt le catalogue et installe les agents dans plusieurs outils. Pour une équipe technique, nous préférons toutefois comprendre le chemin fichier par fichier.

Installation avec Claude Code

Le dépôt indique que les agents Claude Code sont copiés directement dans ~/.claude/agents/, sans conversion supplémentaire. La commande documentée est :

./scripts/install.sh --tool claude-code

Il est également possible de limiter l’installation à une division ou à un rôle précis. Nous recommandons cette approche pour éviter de charger un catalogue inutile dans un environnement personnel.

Anthropic documente Claude Code comme un outil qui peut fonctionner en mode interactif ou non interactif, avec des options de reprise, de sortie JSON et de contrôle des permissions. La documentation rappelle également que le mode qui ignore les demandes de permission doit être utilisé avec prudence. (documentation officielle de Claude Code)

La procédure que nous suivrions est la suivante :

1. cloner le dépôt dans un répertoire temporaire ;
2. inspecter les fichiers des rôles retenus ;
3. vérifier les instructions qui peuvent déclencher des commandes ou modifier des fichiers ;
4. installer uniquement les divisions nécessaires ;
5. ouvrir une session Claude Code dans un projet de test ;
6. invoquer explicitement un rôle et lui demander un livrable contrôlable ;
7. comparer le résultat à une version produite sans rôle spécialisé.

Cette comparaison est importante. Si le rôle ne change ni la qualité, ni la structure de sortie, ni la couverture des contrôles, il n’apporte peut-être pas assez de valeur pour rester dans votre flux.

Installation avec Cursor

Pour Cursor, le dépôt convertit les agents en fichiers .mdc placés dans .cursor/rules/. La documentation de Cursor précise que ces règles peuvent être toujours actives, attachées automatiquement à certains fichiers, demandées par l’agent ou appelées manuellement.

Nous éviterions de rendre tous les rôles actifs en permanence. Une règle de sécurité ou de style global peut être pertinente dans chaque session. Un rôle de recherche produit ou de spécialiste audio, en revanche, devrait être activé uniquement lorsque le projet le nécessite.

Après installation :

1. vérifier que le fichier .mdc possède une description compréhensible ;
2. définir son périmètre d’application ;
3. éviter les règles contradictoires avec les instructions du dépôt ;
4. invoquer le rôle par son nom pour le premier test ;
5. observer quels fichiers et quelles consignes entrent réellement dans le contexte ;
6. versionner la configuration avec le projet si elle doit être partagée.

Cursor rappelle que les règles sont injectées comme contexte et que les modèles ne conservent pas automatiquement la mémoire d’une complétion à l’autre. Cela signifie qu’une règle persistante améliore la cohérence, mais augmente également la quantité de contexte et le risque d’instructions incompatibles.

Attention : une configuration de rôle est une instruction lue par un agent. Elle peut donc être influencée par d’autres fichiers du dépôt, des documents importés ou des contenus non fiables. Nous considérons chaque fichier de rôle comme du code de configuration à relire, pas comme un texte décoratif.

Les capacités de gouvernance à ajouter en entreprise

Agency Agents ne fournit pas automatiquement une gouvernance complète. Pour un projet professionnel, nous séparerions au moins cinq responsabilités.

Les permissions. Un agent de recherche n’a pas besoin des mêmes accès qu’un agent capable de modifier le code ou de déclencher une livraison. Les droits doivent être accordés selon la tâche, et non selon le prestige du rôle.

Les secrets. Les clés d’API, jetons de dépôt et identifiants de production ne doivent pas être copiés dans les fichiers de rôle. Ils doivent rester dans un gestionnaire de secrets ou un mécanisme d’injection limité.

Les journaux. Il faut savoir quel agent a reçu quelle demande, quels fichiers il a lus, quelles commandes il a exécutées et qui a accepté le résultat. Sans journal exploitable, un échec devient difficile à reproduire.

La conservation des données. Les équipes doivent définir ce qui peut rester dans les sessions, les fichiers temporaires, les logs et les historiques de conversations. Cette question devient importante lorsque les rôles traitent des briefs clients, des données personnelles ou du code propriétaire.

L’approbation humaine. Un agent peut préparer une fusion ou un rapport, mais une personne doit pouvoir vérifier le résultat avant une action irréversible. Les recommandations de gouvernance des agents mettent en avant les risques liés aux secrets, aux actions autonomes, à l’injection de consignes et à la perte de visibilité sur le travail réalisé. (risques et mesures d’atténuation documentés)

Un environnement distant peut aider à rendre les exécutions répétables, mais il ne crée pas à lui seul une politique de sécurité. Les environnements isolés sont utiles parce qu’ils séparent les fichiers, les outils et le réseau de l’environnement principal ; ils doivent toutefois être configurés avec des limites adaptées au projet.

Passer d’un essai à un usage fiable

Voici notre grille d’acceptation. Nous ne passerions pas à une équipe de rôles plus large tant que les cases essentielles ne sont pas validées.

• [ ] Le rôle a une mission distincte et non une simple variation de ton.
• [ ] Son entrée attendue est documentée.
• [ ] Son livrable peut être relu par une personne ou un autre agent.
• [ ] Les fichiers qu’il peut modifier sont limités au périmètre de la tâche.
• [ ] Une erreur peut être relancée sans perdre l’état utile.
• [ ] Les sorties d’un rôle peuvent être transmises au rôle suivant sans recopier toute la conversation.
• [ ] Les rôles ne partagent pas de secrets dans leurs instructions.
• [ ] Les tâches parallèles utilisent des branches ou des worktrees séparés.
• [ ] Les tests et contrôles de sécurité sont exécutés avant la fusion.
• [ ] Une personne sait interrompre l’exécution et reprendre la main.
• [ ] Les journaux permettent de comprendre l’origine d’une modification.
• [ ] Le temps d’exécution et les appels de modèle sont observables.
• [ ] Le rôle produit un résultat utile même lorsque certaines informations manquent.
• [ ] Le résultat est comparé à une procédure sans Agency Agents.

Pour un premier projet, nous choisirions un rôle de planification, un rôle d’exécution et un rôle d’audit. Nous leur donnerions une tâche réelle mais limitée : créer une fonctionnalité isolée, produire une variante d’interface, écrire une documentation d’installation ou vérifier une intégration audio et vidéo. Après cette validation, nous ajouterions un rôle uniquement si une faiblesse précise apparaît.

La décision d’utiliser une machine distante ne doit pas dépendre du nombre total de rôles installés. Elle dépend plutôt du nombre de tâches simultanées, de la durée des sessions, des dépendances à installer, de la nécessité de laisser un processus actif et du besoin de séparer les environnements. Un petit catalogue peut nécessiter une infrastructure sérieuse s’il exécute plusieurs tâches longues. À l’inverse, une grande collection peut rester parfaitement locale si seuls deux rôles sont utilisés ponctuellement.

FAQ : les limites à connaître avant l’adoption

Agency Agents est-il un framework multi-agents ?

Pas au sens d’une plateforme qui planifie, lance et surveille automatiquement plusieurs agents. Agency Agents est surtout une collection de configurations de rôles spécialisées. Elle décrit une identité, une méthode de travail et des livrables. Pour obtenir une véritable exécution multi-agents, il faut ajouter un orchestrateur, des files de tâches, une gestion des permissions et des espaces de travail isolés.

Avec quels outils peut-il fonctionner ?

Le dépôt officiel documente des intégrations pour Claude Code, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Aider, Windsurf, Codex et d’autres outils. Le format dépend de chaque environnement : fichiers Markdown, règles MDC, sous-agents, fichiers TOML ou conventions de projet. Il faut donc vérifier l’intégration ciblée avant de déployer tous les rôles.

Comment choisir les bons rôles ?

Commencez par le flux de travail réel plutôt que par le catalogue. Sélectionnez un rôle qui prépare la décision, un rôle qui produit un livrable et un rôle qui le vérifie. Par exemple : architecte logiciel, développeur frontend et réviseur de code. Ajoutez ensuite un rôle spécialisé seulement si une lacune mesurable apparaît.

Le travail parallèle est-il préférable ?

Le parallélisme convient aux tâches indépendantes : recherche, documentation, tests séparés ou variantes de design. Les modifications qui touchent les mêmes fichiers doivent rester isolées dans des branches ou des worktrees. Dans ce cas, une séquence planification, implémentation puis revue est souvent plus fiable qu’un lancement simultané.

Est-ce adapté à un projet d’entreprise ?

Oui, comme couche de rôles et de procédures, mais pas comme solution complète de gouvernance. Une entreprise doit ajouter une gestion des identités, des secrets, des journaux, de la conservation des données, des limites réseau, des validations humaines et une exécution isolée. Le dépôt fournit des configurations d’agents ; il ne remplace pas ces contrôles.

Si vous utilisez déjà un poste local, vous pouvez commencer sans infrastructure supplémentaire. La solution actuelle reste néanmoins limitée par la veille de la machine, les conflits entre sessions, l’accès aux dépendances, l’absence d’isolation forte et la difficulté de conserver des tâches longues actives. Pour des rôles qui doivent fonctionner en parallèle ou rester disponibles pendant plusieurs heures, un environnement distant apporte une exécution plus stable, des espaces séparés et une meilleure continuité. Nous vous conseillons d’examiner les options de location d’un Mac distant aux États-Unis, puis de vérifier les conditions d’utilisation de ZekVPS avant de choisir une configuration.

Pour démarrer proprement, retenez trois rôles : un planificateur, un exécutant et un vérificateur. Faites-les travailler sur un projet réel, mesurez la qualité des livrables et la facilité de reprise, puis ajoutez les rôles manquants. Si l’exécution doit devenir permanente, parallèle ou isolée, le sujet ne sera plus seulement Agency Agents : il faudra aussi une infrastructure distante, des règles d’accès et une procédure d’acceptation que l’équipe pourra réellement appliquer.