Le premier agent d'une équipe relève de l'histoire de la productivité individuelle. Le cinquième, de l'échelle organisationnelle. Entre les deux, un groupe cesse d'être une équipe qui utilise l'IA pour devenir une équipe agentique : des humains et des agents travaillant sur le même tableau, sur les mêmes tâches, selon des règles que quelqu'un a dû coucher par écrit.
C'est dans cette transition que se logent les questions les plus intéressantes. Qui est responsable du travail exécuté par un agent ? À quoi ressemble un stand-up quand le tableau se met à jour tout seul ? Combien d'agents un relecteur peut-il absorber ? Ce guide couvre la composition d'une équipe agentique, la répartition du travail qui résiste au contact du réel, et les conventions de travail qui valent la peine d'être reprises. Sharkly est la plateforme que nous construisons pour ce type d'équipe, et les modes de défaillance décrits ci-dessous viennent de situations où les choses ont mal tourné.
TL;DR
Une équipe agentique est un groupe où les personnes et les agents IA se voient tous attribuer du travail dans un même système partagé, les humains conservant la direction, l'autorité et l'acceptation. Les agents font la recherche, l'exécution, les tests et le reporting. Les personnes fixent la direction, accordent l'autorité et acceptent le résultat. Les prérequis concrets sont les suivants : un enregistrement de tâche que les deux peuvent lire, un assigné à l'exécution distinct de la personne responsable, un état de revue qui atteint quelqu'un, et un périmètre suffisamment détaillé pour que l'agent n'ait pas à deviner.
De quoi se compose une équipe agentique
Trois types de participants, et il vaut mieux les nommer précisément.
Les personnes créent et mettent à jour les tâches, commentent, reçoivent des éléments de file d'attente, se voient attribuer du travail, relisent les résultats des agents et gèrent les paramètres que leur rôle autorise. Ce sont les seules participantes qui peuvent être tenues responsables.
Les agents sont des configurations de travail enregistrées plutôt que des prompts ponctuels : instructions, environnement d'exécution tel que Claude Code ou Codex, dépôts, environnement, paramètres d'exécution et compétences associées. Un agent ressemble davantage à un rôle documenté qu'à une personne. Notre article présentant les Sharkly Agents détaille ce qu'ils contiennent.
Les crews regroupent des agents sous un agent chef pour le travail qui nécessite de la coordination. L'exécution est pilotée par le chef : celui-ci lit la tâche et les instructions de la crew, puis soit traite le travail, soit fait appel à des membres précis. Cet ordre existe pour éviter que tous les membres se lancent en même temps. Les détails sont dans notre guide des Sharkly Crews.
L'accès vient se superposer : un rôle d'organisation détermine la capacité administrative globale, et l'appartenance à un espace détermine les zones de travail auxquelles une personne peut accéder. Les agents sont cadrés de la même manière, sur des dépôts précis et des machines précises.
La répartition du travail qui fonctionne
Le contrat appliqué chez Sharkly constitue un bon point de départ, car il est assez restreint pour être appliqué : les agents font la recherche, l'exécution, les tests et le reporting ; les personnes fixent la direction, accordent l'autorité et acceptent le résultat.
Quatre responsabilités restent aux humains, quelle que soit la puissance des agents.
- La direction. Décider ce qui vaut la peine d'être fait, et dans quel ordre.
- Le contexte. Rédiger un périmètre sur lequel un agent peut agir : pourquoi le travail compte, ce qui est hors périmètre, les fichiers et contraintes pertinents, et comment la réalisation sera évaluée.
- L'acceptation. Lire les preuves et décider que le travail est terminé. Une exécution terminée n'est pas un résultat accepté.
- L'escalade. Décider de la suite lorsqu'un agent est bloqué, se trompe ou tombe sur une question qui demande du jugement.
Tout le reste est négociable et dépend du degré de confiance de votre équipe envers le bilan d'un agent donné sur un type de travail donné.
Comment le travail circule dans l'équipe
La boucle est courte et mérite d'être explicitée, car les équipes qui sautent une étape le ressentent en moins d'une semaine.
- Une personne rédige une tâche avec un résultat attendu et des critères d'acceptation.
- La tâche reçoit un assigné humain pour la responsabilité, et un agent ou une crew comme assigné à l'exécution. Ce sont deux champs distincts : modifier l'un ne modifie pas l'autre.
- Le fait de sortir la tâche d'un état de backlog en attente déclenche l'exécution lorsque l'agent assigné est prêt.
- L'exécution se déroule sur une machine connectée, dans un répertoire isolé, la progression et les points de blocage remontant dans la tâche.
- L'agent laisse le travail en attente de réponse humaine ou en attente de revue humaine, ce qui arrive dans la boîte de réception des agents de la personne responsable.
- Une personne lit la trace et le diff, puis accepte, commente pour poursuivre, ou réattribue.
Les commentaires constituent la conversation durable. Un commentaire sur une tâche dont l'agent est prêt peut déclencher l'exécution suivante, ce qui fait de la revue et de l'exécution un seul et même geste plutôt que deux systèmes.
Trois configurations qui fonctionnent
Le développeur en binôme. Chaque développeur conserve un ou deux agents pour son propre travail récurrent : couverture de tests, mises à jour de dépendances, refactorisations qu'il a déjà réalisées vingt fois. L'avantage pour l'équipe, c'est que ces définitions d'agents sont partagées : une nouvelle recrue hérite de cinq configurations opérationnelles dès le premier jour au lieu de construire les siennes.
L'escouade avec une crew partagée. Une crew prend en charge une catégorie de travail dont toute l'escouade dépend, comme la préparation de release ou le triage des incidents. Un agent chef décide quel membre contribue, et un humain est responsable de la catégorie. C'est la configuration qui passe le plus facilement à l'échelle avant que la capacité de revue ne devienne le facteur limitant.
L'équipe plateforme qui standardise. Une équipe plateforme ou expérience développeur est propriétaire des définitions d'agents, des compétences et de la configuration des machines pour plusieurs équipes produit. Les équipes produit attribuent le travail ; l'équipe plateforme maintient à jour les environnements d'exécution, les permissions et les instructions. Cette configuration échange un peu d'autonomie contre de la cohérence, et c'est généralement le bon compromis au-delà d'une trentaine d'ingénieurs.
Aucune des trois n'exige de réorganiser quoi que ce soit. Ce sont des modèles qui déterminent qui est propriétaire de la configuration des agents, la question qui décide si la capacité des agents se cumule à l'échelle de l'équipe ou reste individuelle.
Des conventions de travail à adopter
Un humain redevable par tâche. Même quand une crew de quatre agents fait le travail. Surtout dans ce cas.
Le périmètre s'écrit avant l'attribution. Si personne ne peut dire comment le résultat sera vérifié, la tâche n'est pas prête pour un agent. Cette seule règle élimine la plupart des mauvaises exécutions.
La revue est une capacité planifiée, pas du temps libre. Décidez combien de travail d'agent chaque relecteur peut absorber par jour et tenez ce chiffre. Une pile grandissante de résultats d'agents non relus représente la même dette que des pull requests non fusionnées, et elle grossit plus vite.
Les exécutions échouées se diagnostiquent, on ne les relance pas. Ouvrez le journal d'exécution et lisez d'abord le titre et les détails techniques. Des erreurs de fournisseur qui se ressemblent demandent souvent des correctifs opposés : un relancement réflexe masque la cause réelle.
Les définitions d'agents ont un propriétaire et une date de revue. Les instructions s'usent. Le développeur qui a écrit l'agent de migration s'en va, les conventions changent, et l'agent continue d'appliquer avec assurance les règles du trimestre dernier.
Ce qui casse en premier quand l'équipe grandit
La capacité de revue lâche en premier, à chaque fois. La deuxième contrainte est la capacité machine : les exécutions font la queue en attendant de la concurrence ou un répertoire de travail libre, et une équipe qui a ajouté des agents sans ajouter d'ordinateurs découvre une file d'attente invisible depuis le tableau.
La troisième est la dérive des responsabilités. Quand plusieurs agents contribuent à des tâches liées et que personne ne renomme le propriétaire après une passation, on se retrouve avec un travail techniquement assigné et concrètement sans propriétaire. Un passage hebdomadaire sur les tâches dotées d'un agent assigné et d'un propriétaire humain obsolète prend dix minutes et évite la version chaotique de ce problème. Si vous préférez partir d'un système qui sépare déjà ces champs, téléchargez Sharkly et faites-y tourner un type de travail récurrent pendant une semaine.
FAQ
Combien d'agents par développeur est raisonnable ? Commencez par un ou deux et laissez le débit de revue fixer le plafond. Le bon nombre est celui où les résultats n'attendent pas plus d'une journée de travail une décision humaine.
Les agents participent-ils au stand-up ? Leur travail, oui. Le tableau porte le statut, donc le stand-up devient la liste des exceptions : échecs, exécutions bloquées et résultats en attente de personnes.
Un agent peut-il être le seul assigné ? Non. Gardez une personne responsable du résultat, avec l'agent au poste d'exécution. Notre guide sur la gestion de projet avec des agents IA explique pourquoi cette séparation compte d'autant plus que le volume augmente.
Comment intégrer un nouvel agent à l'équipe ? De la même manière qu'une personne : confiez-lui d'abord une tâche étroite, relisez de près, puis élargissez le périmètre. Enregistrez ce qui a fonctionné comme instructions et compétences de l'agent, pour que la prochaine équipe n'ait pas à le redécouvrir.
