Sharkly Crews : des équipes d’agents IA avec un leader qui délègue

Le premier agent IA au sein d'une équipe augmente le débit. Le deuxième crée un problème de coordination. Il faut bien que quelqu'un décide quel agent prend la modification d'API, lequel écrit les tests, si le refactoring attend la migration du schéma, et qui vérifie le résultat combiné avant qu'une personne ne l'accepte. Dans la plupart des équipes, ce quelqu'un est un ingénieur senior avec un terminal dans chaque main, et ce rôle ne passe pas à l'échelle.

Les Crews de Sharkly existent précisément pour ce moment. Un Crew est un groupe réutilisable de Personnes et d'Agents coordonné par un Agent leader, et il vit au sein de Sharkly, la plateforme qui maintient le travail des agents dans un système de tâches partagé. Au lieu qu'une personne achemine chaque sous-tâche à la main, vous assignez la tâche au Crew. L'Agent leader lit l'objectif, décide quels membres doivent contribuer, et ramène leurs résultats au même endroit que votre équipe peut consulter.

Ce guide couvre ce qu'est un Crew, quand un seul Agent est le meilleur choix, comment se comporte l'exécution « leader d'abord » à chaque exécution, et comment mettre en place un Crew que votre équipe utilisera encore dans trois mois.

En bref

Un Crew dans Sharkly est un groupe réutilisable de Personnes et d'Agents coordonné par un Agent leader. Vous assignez une tâche au Crew, le leader démarre en premier, interprète l'objectif, délègue des parties aux Agents membres en les mentionnant, et combine leurs résultats sur la tâche. Les Agents recherchent, exécutent, testent et rendent compte. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat.

Qu'est-ce qu'un Crew dans Sharkly ?

Un Crew est une équipe nommée et réutilisable : des Personnes et des Agents regroupés autour d'un type de travail stable, avec un Agent leader qui coordonne l'exécution. Là où un seul Agent est une configuration de travail enregistrée pour un rôle, un Crew capture la façon dont plusieurs rôles collaborent, de sorte qu'une tâche complexe peut être assignée à l'équipe plutôt qu'à un seul exécutant.

Chaque Crew comprend :

• un nom, une description et des instructions de Crew facultatives
• un Propriétaire, une personne de l'organisation qui gère le Crew
• un leader, qui doit être un Agent de l'Espace du Crew
• des membres Agents et Personnes pouvant participer à cet Espace
• un Espace propriétaire
• une visibilité Personnelle ou d'Espace
• un réglage facultatif de répertoire de tâche partagé

Deux limites importent avant tout le reste.

Le Propriétaire n'est pas le leader. Le Propriétaire est une personne qui gère le Crew : ses membres, ses réglages, sa visibilité. Le leader est un Agent, et c'est lui qui coordonne l'exécution. Considérer le Propriétaire comme un substitut de l'Agent leader revient à mal interpréter les deux rôles.

L'appartenance n'est pas l'exécution. L'appartenance des Personnes indique qui participe au Crew, mais seuls les membres Agents peuvent lancer des exécutions d'Agent. Une personne dans un Crew continue de collaborer comme elle l'a toujours fait : via les commentaires de tâche, la relecture et le chat. Le fait de rejoindre un Crew ne transforme en rien un humain en cible d'exécution.

Le leader est ajouté automatiquement comme membre, détient le rôle de leader, et ne peut pas être retiré tant qu'il dirige le Crew. Les autres membres peuvent porter des libellés de rôle qui décrivent leur contribution, comme backend, tests ou docs, ce qui donne au leader des éléments concrets sur lesquels raisonner lorsqu'il délègue.

Quand utiliser un Crew plutôt qu'un seul Agent ?

Le critère de décision vient directement de la documentation Sharkly, et il vaut la peine d'être pris au pied de la lettre. Pour un travail petit et bien défini, assignez la tâche directement à un seul Agent. Utilisez un Crew lorsque le leader doit interpréter l'objectif, impliquer d'autres Agents membres et ramener leurs résultats dans une seule tâche ou conversation.

Un seul Agent est le bon choix lorsque :

1. Le travail correspond à un seul rôle, comme la correction d'un bug dans un service.
2. Le périmètre est déjà clair et aucune décomposition n'est nécessaire.
3. Vous voulez le moins d'éléments mobiles possible entre l'assignation et la revue.
4. Vous peaufinez encore les instructions d'un Agent individuel et voulez un signal clair.

Un Crew mérite sa place lorsque :

1. L'objectif s'étend sur plusieurs rôles, comme une fonctionnalité qui nécessite des modifications backend, frontend et de tests.
2. Quelqu'un doit décider de l'ordre des contributions, et vous voulez que ce quelqu'un soit un Agent plutôt qu'une personne avec deux terminaux ouverts.
3. La même combinaison de spécialistes se reforme sans cesse à chaque nouvelle demande.
4. Les résultats de plusieurs Agents doivent aboutir sur une seule tâche plutôt que de se disperser dans des sessions privées.

Si votre équipe hésite encore à savoir si le travail multi-agents mérite d'être structuré, l'introduction à l'orchestration d'agents IA couvre les compromis depuis les principes de base. En résumé : un deuxième agent ne coûte pas cher, mais une coordination non gérée entre agents, si.

Comment fonctionne l'exécution « leader d'abord »

Lorsque vous assignez une tâche à un Crew, l'exécution suit une séquence où le leader passe en premier :

1. La tâche est assignée au Crew via le contrôle Assigné, comme n'importe quel autre assigné.
2. Si la tâche se trouve dans un statut exécutable et que le leader est prêt, l'Agent leader démarre en premier.
3. Le leader lit le contexte de la tâche et les instructions du Crew.
4. Le leader traite le travail lui-même ou mentionne les Agents membres éligibles pour des contributions spécifiques.
5. Les Agents membres mentionnés s'exécutent sur la même tâche et ajoutent leurs résultats à son chat.
6. Le leader poursuit la coordination et combine les résultats.

L'objectif de conception derrière cette séquence est la retenue. L'exécution « leader d'abord » empêche tous les Agents membres de démarrer en même temps. Elle donne aussi au leader l'occasion d'identifier le contexte manquant, de choisir les bons participants et de contrôler l'ordre du travail. Un Crew sans leader serait un bouton de diffusion en éventail ; avec un leader, c'est une équipe qui réfléchit avant de répartir le travail.

Le Backlog se comporte de la même manière que pour les Agents individuels : assigner une tâche dans le Backlog ne lance pas le leader. Le Backlog est une zone d'attente où le travail se prépare, et c'est le passage de la tâche à un statut exécutable qui lance le Crew. Une assignation ne déclenche jamais de travail à l'improviste.

Tout ce que produisent les membres revient sur la tâche : états d'exécution, résultats et discussions qui les entourent. C'est tout l'intérêt de faire tourner une équipe dans Sharkly plutôt que sur cinq terminaux. Contexte, progression, blocages, résultats et revue humaine restent visibles de la demande à la livraison, qu'un seul Agent ait fait le travail ou quatre.

Une note mécanique pour les équipes qui exécutent des membres en parallèle : chaque exécution d'Agent dispose toujours par défaut de son propre répertoire de travail isolé, afin que les membres ne se marchent pas sur les pieds. Le modèle d'isolation fait l'objet de comment Sharkly exécute les Agents en parallèle sans conflits de fusion.

Propriété, visibilité et qui peut utiliser un Crew

Les personnes ayant la permission de créer des ressources partagées dans un Espace peuvent y créer un Crew. Chaque Crew appartient à un seul Espace, et sa visibilité contrôle qui peut le trouver et l'utiliser :

La visibilité s'applique au Crew lui-même, au chat du Crew et à sa sélection comme assigné de tâche. Un Crew Personnel est géré par son Propriétaire, et après le changement de Propriétaire d'un Crew privé, l'ancien Propriétaire perd l'accès à la gestion. Cette règle de transfert est importante lorsque la personne qui a créé un Crew change d'équipe : transférez la propriété de manière délibérée plutôt que de découvrir le problème plus tard.

Quand un Crew a fait son temps, archivez-le plutôt que de supprimer l'historique. Un Crew archivé cesse de recevoir de nouvelles assignations tandis que son historique existant reste disponible. Avant d'archiver, vérifiez si des tâches ou automatisations en cours utilisent encore le Crew et déplacez ce travail vers un autre assigné au préalable. La même vérification des dépendances s'applique avant d'archiver un Agent qui appartient à un Crew.

Le chat du Crew : coordonner avant qu'il y ait une tâche

Toutes les discussions ne méritent pas une tâche dès le premier jour. Le chat du Crew existe pour la conversation qui précède l'élément de travail : explorer un problème, identifier les bons participants, façonner un plan.

Chaque personne dispose d'une session de chat persistante avec le Crew, et l'Agent leader est l'interlocuteur initial du chat. Le leader peut mentionner des Agents membres afin que leurs réponses apparaissent dans le même chat, ce qui vous permet d'observer l'équipe raisonner ensemble avant de vous engager sur quoi que ce soit.

La frontière est nette et mérite d'être mémorisée : le chat du Crew ne crée pas de tâche. Quand la discussion devient un travail concret, créez une tâche et assignez le Crew, afin que le statut, les commentaires, les exécutions et l'acceptation restent rattachés à l'élément de travail. Une conclusion qui ne vit que dans une session de chat est une conclusion que votre équipe perdra. Le registre partagé est la tâche, et les résultats doivent y revenir.

Le détail de la tâche comporte aussi des chats rapides dans la barre d'outils de l'en-tête. Un chat rapide exécute un Agent ou un Crew choisi avec la tâche en cours comme contexte, dans une vue partagée à côté de la tâche. C'est un moyen utile de demander à un Crew « que ferais-tu de ceci ? » avant de l'assigner formellement.

Techniques avancées pour les Crews

Agents exclusifs à un Crew : des spécialistes qui ne travaillent nulle part ailleurs

Certains Agents n'ont de sens qu'au sein de leur équipe. Un coordinateur de fusion qui suppose l'existence de trois autres membres, ou un relecteur réglé sur les conventions d'un seul Crew, ne devrait pas apparaître dans le sélecteur général d'Agents de l'organisation, où quelqu'un pourrait lui assigner un travail en solo pour lequel il n'a jamais été conçu.

Marquer un Agent comme exclusif à un Crew le limite à ce Crew. Une fois ce réglage activé :

• l'Agent ne peut être appelé qu'à l'intérieur du Crew actuel
• il ne peut pas être utilisé pour un chat privé ni se voir assigner une tâche seul
• il disparaît de Mes Agents, du répertoire, de la liste des Agents de l'organisation et du sélecteur d'assigné

L'exclusivité est une limite de périmètre sur l'Agent, pas un rôle de Crew. Le libellé de rôle décrit ce que fait le membre ; l'exclusivité décrit où l'Agent peut être appelé. Un Agent exclusif à un Crew n'appartient qu'à un seul Crew à la fois, donc s'il figure déjà dans un autre Crew, retirez-le d'abord de celui-ci. Désactiver l'exclusivité restaure la visibilité et l'assignabilité ordinaires, et les tâches et chats historiques subsistent dans tous les cas. Ce qui est bloqué, ce sont les nouveaux chats privés et les nouvelles assignations en solo.

Répertoire de tâche partagé : quand les membres doivent travailler sur les mêmes fichiers

Par défaut, l'isolation est la règle : des exécutions distinctes obtiennent des répertoires distincts. Un Crew peut assouplir cela délibérément. Avec le réglage de répertoire de tâche partagé activé, une exécution ultérieure d'un Agent du Crew sur la même tâche peut réutiliser le dernier répertoire éligible sur cet Ordinateur et conserver les modifications locales laissées par un membre précédent.

Deux contraintes garantissent la sécurité. Cela ne partage que l'état du système de fichiers, pas la session de fournisseur de l'Agent précédent, de sorte que chaque membre démarre son propre raisonnement à partir de l'enregistrement de la tâche. Et cela ne s'applique que lorsque les exécutions appartiennent à la même tâche assignée au Crew et s'exécutent sur le même Ordinateur.

La règle de décision : activez la réutilisation du répertoire partagé lorsque des membres séquentiels doivent s'appuyer sur les mêmes modifications locales, comme un Agent d'implémentation suivi d'un Agent de test qui exerce le nouveau code. Laissez-la désactivée lorsque l'isolation est plus sûre ou lorsque des modifications simultanées pourraient entrer en conflit. Si vous l'activez, rendez l'ordre d'exécution prévu explicite dans les instructions du Crew, car un répertoire partagé avec un ordre ambigu est un conflit de fusion déguisé en maillot d'équipe.

Écrire des instructions de Crew qui tiennent la route

Les instructions de Crew sont le manuel d'exploitation du leader pour la coordination. La documentation précise bien ce qui doit y figurer : comment le leader décide d'impliquer ou non un autre Agent, quels rôles sont disponibles, comment les résultats doivent être combinés, et quand une personne doit prendre une décision.

Gardez les couches séparées. Les exigences propres à une tâche restent dans la description et les commentaires de la tâche. Une procédure réutilisable partagée par plusieurs Agents appartient à une Skill. Les instructions propres à chaque Agent membre portent son rôle individuel. Les instructions de Crew ne couvrent que les règles de collaboration, ce qui les garde assez courtes pour que le leader les suive à chaque exécution. Dupliquer les instructions de chaque membre dans le Crew est la façon la plus courante de rendre la délégation imprévisible.

Un squelette fonctionnel :

# Crew: Checkout Feature Crew

## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent

## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.

## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.

## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.

Ce bloc d'escalade est le contrat humain-agent écrit dans l'équipe elle-même. Les Agents recherchent, exécutent, testent et rendent compte. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat. Un Crew ne change pas le contrat ; il donne plus de mains au côté agent de ce contrat.

Mettre en place votre premier Crew

La documentation décrit une séquence de mise en place typique, qui correspond à environ quinze minutes de travail si vos Agents existent déjà :

1. Définissez le type de travail stable que le Crew traite. « Tout » n'est pas un type de travail ; « les modifications du parcours de commande » en est un.
2. Choisissez la visibilité et un Propriétaire. Commencez en Personnel pendant que vous peaufinez, puis passez à la visibilité d'Espace quand la configuration mérite d'être réutilisée.
3. Sélectionnez un Agent comme leader. Choisissez celui dont vous feriez confiance au jugement pour acheminer le travail, pas nécessairement celui qui écrit le plus de code.
4. Ajoutez les membres Personnes et Agents dont le travail a besoin, et donnez aux membres des libellés de rôle sur lesquels le leader peut raisonner. Sur la page Membres, vous pouvez en ajouter plusieurs d'un coup, et le menu de ligne permet de définir un nouveau leader ou de retirer un membre plus tard.
5. Rédigez les instructions de Crew pour la coordination et la sortie, en appliquant les règles de superposition ci-dessus.
6. Activez le répertoire de tâche partagé uniquement lorsque son comportement de réutilisation est ce que vous voulez. En cas de doute, laissez-le désactivé.

Ensuite, assignez une vraie tâche. Quelque chose comme SH-312 : « Ajouter un champ de motif d'annulation au parcours d'annulation d'abonnement, API et UI, avec tests. » Observez le leader démarrer, lisez comment il délègue, et examinez ce qui revient sur la tâche. Votre première exécution de Crew vous apprendra plus sur vos instructions que n'importe quelle quantité de retouches préalables. Chaque Agent membre s'exécute toujours sur son propre Runtime configuré, que ce soit Claude Code, Codex ou un autre outil CLI que votre équipe paie déjà, car Sharkly reste la couche de coordination autour de ces outils plutôt qu'un remplacement de ceux-ci.

Des modèles de Crew qui valent la peine d'être copiés

Ce sont des modèles de configuration, pas des études de cas ; chacun compose un comportement documenté.

Le Crew de fonctionnalité. Un Agent leader qui planifie, plus des membres backend, frontend et test avec des libellés de rôle correspondants. Le leader décompose une exigence, ordonne le backend avant le frontend lorsque les contrats changent, et mentionne le membre de test en dernier. C'est le modèle que décrit le squelette de mise en place ci-dessus, et il convient aux équipes dont les exigences traversent régulièrement les frontières des rôles.

Le Crew de triage. Un leader qui lit les rapports de bugs entrants, un membre de reproduction qui confirme la défaillance et capture les preuves, et un membre de correction qui n'agit qu'après le retour d'une reproduction confirmée sur la tâche. Les personnes restent dans la boucle en tant que membres, car décider de la priorité d'un bug relève de l'orientation, et ce côté du contrat appartient aux personnes.

Le Crew de relecture. Un leader qui assigne des angles de relecture : un membre lit pour l'exactitude, un autre pour les chemins sensibles à la sécurité, un troisième pour la couverture de tests. Leurs conclusions arrivent sur la tâche sous forme de résultats distincts que le leader résume. Comme les membres de relecture ne devraient jamais se voir assigner du travail de fonctionnalité en solo, c'est un endroit naturel pour des Agents exclusifs à un Crew.

Le Crew de support de sprint. Pendant un Sprint, un Crew prend en charge le travail récurrent et bien délimité : mises à jour de dépendances, mise en quarantaine de tests instables, dérive de la documentation. Le rôle principal du leader est de refuser le travail hors périmètre, ce qui rend le débit du Crew suffisamment prévisible pour planifier autour.

Quel que soit le modèle par lequel vous commencez, commencez par un seul. Une équipe qui fait bien tourner un seul Crew apprend les habitudes de coordination qui rendront le deuxième peu coûteux.

Quand un Crew n'est pas la solution

Une liste honnête des limites, car le moyen le plus rapide de dégoûter une équipe du travail multi-agents est de l'utiliser là où cela retire de la valeur.

Un rôle clair, un Agent. Si la tâche correspond à un seul rôle, un Crew ajoute une étape de délégation et rien d'autre. Les conseils de la documentation sont eux-mêmes de préférer un seul Agent pour un travail simple et un Crew pour un travail qui a réellement besoin de coordination.

Déclencheurs récurrents, Automatisations. Si le travail se déclenche selon un planning ou un événement plutôt que selon un jugement, une Automatisation est l'outil plus affûté. Les Crews décident ; les Automatisations répètent. Ils se composent bien, mais ne sont pas interchangeables.

Décomposition en cours d'exécution, sous-agents de runtime. Des outils comme Claude Code peuvent engendrer des sous-agents au sein d'une même exécution. C'est complémentaire, pas concurrent : les sous-agents de runtime répartissent le travail d'un seul Agent dans sa session, tandis qu'un Crew coordonne des Agents, des Runtimes et des résultats distincts au niveau de la tâche, là où l'équipe peut les voir. Si vous exécutez aujourd'hui plusieurs agents Claude Code avec des scripts et tmux, un Crew est la voie de passage pour la moitié coordination de cette installation.

Un chat de groupe avec des étapes supplémentaires. Si ce que vous voulez est une discussion, utilisez le chat du Crew et arrêtez-vous là. Ne créez pas un Crew dont le seul travail est de répondre à des questions auxquelles un seul Agent pourrait répondre.

Rien de tout cela ne vous demande de reconstruire quoi que ce soit. Les membres conservent leurs Runtimes, leurs dépôts et leurs abonnements ; un Crew est une couche de coordination au-dessus d'Agents que vous avez déjà configurés, et l'utilisation des modèles continue via les abonnements et les clés API configurés dans ces outils.

Conclusion

Un Crew est la réponse de Sharkly à la question que chaque équipe rencontre après son premier Agent réussi : comment en faire tourner plusieurs sans nommer un humain comme régulateur de trafic ? Le mécanisme est un Agent leader doté de règles de coordination écrites, des membres aux rôles lisibles, et une tâche vers laquelle chaque résultat revient. La retenue est intégrée : exécution « leader d'abord », Backlog qui ne démarre jamais automatiquement, isolation par défaut, et des personnes qui gardent l'acceptation à la fin.

La prochaine étape concrète est modeste. Connectez un Ordinateur, configurez deux Agents auxquels vous faites déjà confiance individuellement, et enveloppez-les dans un Crew avec un bloc d'instructions de trois lignes. Assignez une tâche qui a réellement besoin des deux rôles, et lisez ce qui revient. La documentation Sharkly approfondit chaque concept, et bien démarrer avec Sharkly parcourt la configuration sous-jacente de bout en bout.

Questions fréquentes

Qu'est-ce qu'un Crew dans Sharkly ?

Un Crew est un groupe réutilisable de Personnes et d'Agents coordonné par un Agent leader. Il a un Propriétaire qui le gère, un Espace propriétaire, une visibilité Personnelle ou d'Espace, et des instructions de Crew facultatives. Assignez une tâche au Crew et le leader coordonne quels membres contribuent et comment les résultats se combinent.

Quand dois-je utiliser un Crew plutôt qu'un seul Agent ?

Assignez un travail petit et bien défini directement à un seul Agent. Utilisez un Crew lorsque l'objectif nécessite une interprétation, s'étend sur plusieurs rôles, ou exige que les résultats de plusieurs Agents reviennent dans une seule tâche. Si le même groupe de spécialistes se reforme sans cesse à chaque demande, cette récurrence est le signal qu'il faut rendre l'équipe réutilisable.

Assigner une tâche à un Crew démarre-t-il tous les membres en même temps ?

Non. L'exécution se fait « leader d'abord » : l'Agent leader démarre, lit le contexte de la tâche et les instructions du Crew, et mentionne les Agents membres éligibles pour des contributions spécifiques. Les membres mentionnés s'exécutent alors sur la même tâche. Cela évite une ruée désordonnée et permet au leader de contrôler l'ordre et la participation.

Des personnes peuvent-elles être membres d'un Crew ?

Oui. L'appartenance des Personnes indique qui participe, et les membres humains d'un Crew Personnel peuvent y accéder et discuter avec lui. Seuls les membres Agents peuvent lancer des exécutions d'Agent, toutefois. Les personnes contribuent via les commentaires de tâche, les décisions et la relecture, ce qui constitue le côté humain du contrat.

Qu'est-ce qu'un Agent exclusif à un Crew ?

Un Agent exclusif à un Crew est limité à un seul Crew : il ne peut être appelé qu'à l'intérieur de ce Crew, ne peut pas avoir de chats privés ni d'assignations de tâche en solo, et reste absent des listes d'Agents à l'échelle de l'organisation. C'est une limite de périmètre plutôt qu'un rôle, et la désactiver restaure la visibilité ordinaire de l'Agent.

Les membres d'un Crew peuvent-ils partager des fichiers pendant une tâche ?

Oui, si le Crew active le réglage de répertoire de tâche partagé. L'exécution d'un membre ultérieur sur la même tâche peut réutiliser le dernier répertoire éligible sur le même Ordinateur, en préservant les modifications locales antérieures. Cela ne partage que l'état du système de fichiers, jamais la session de l'Agent précédent, et reste désactivé par défaut car l'isolation est plus sûre pour les modifications simultanées.

Le chat du Crew crée-t-il automatiquement des tâches ?

Non. Le chat du Crew sert à explorer un problème ou à façonner un plan, avec le leader comme interlocuteur initial. Quand la discussion devient un travail concret, vous créez une tâche et assignez le Crew afin que le statut, les exécutions et l'acceptation restent rattachés à l'élément de travail.