Une tâche rédigée pour une personne peut tenir en trois mots. « Corrige le bug de connexion » fonctionne, parce que la personne vous demandera ce que vous vouliez dire. Une tâche rédigée pour un agent ne peut pas s'appuyer sur cette conversation, et la différence se traduit par des exécutions gaspillées, des résultats que personne ne relit et un tableau où la colonne de statut ne veut plus dire ce que les gens croient.
La gestion des tâches pour agents IA est la discipline qui consiste à rédiger, attribuer et clôturer un travail qu'un agent exécute et qu'une personne accepte. Ce guide couvre les trois éléments qui déterminent si l'ensemble tient debout : ce que contient une tâche prête pour un agent, comment la répartition se fait entre les personnes et les agents, et comment le statut et la revue se comportent réellement une fois que des exécutions entrent en jeu. Les exemples suivent la manière dont Sharkly l'implémente, et les mêmes règles s'appliquent à tout système qui traite les agents comme des exécutants.
En bref
Une tâche prête pour un agent énonce un résultat, un périmètre, un contexte et la façon dont l'achèvement sera vérifié. L'attribution comporte deux emplacements : les personnes sont responsables, et un agent ou une crew exécute. Les catégories de statut pilotent l'exécution : un état de backlog en attente empêche une exécution, en sortir peut en déclencher une, et les états annulé ou doublon arrêtent les exécutions actives, contrairement à l'état terminé. Le statut de la tâche et l'état d'exécution de l'agent sont deux choses distinctes, et la revue est un état nommé qui doit parvenir à une personne, et non une intention qu'on traitera plus tard.
Ce que contient une tâche prête pour un agent
La description, c'est l'interface. Tout ce que l'agent sait de votre intention en provient, ainsi que ce que la tâche porte dans ses champs.
Une tâche utile nomme le résultat plutôt que le sujet, et sa description ajoute ce dont une nouvelle personne ou un agent aurait besoin pour avancer :
- pourquoi le travail compte ;
- ce qui entre dans le périmètre et ce qui en sort ;
- les fichiers, liens, exemples ou comportements observés pertinents ;
- les contraintes et les décisions déjà prises ;
- la façon dont l'achèvement sera vérifié.
Cette dernière ligne fait plus de travail que toutes les autres réunies. C'est la différence entre un résultat que vous pouvez accepter en deux minutes et un résultat qu'il vous faut reconstituer à l'envers. Commencez petit et affinez au fil de l'analyse ; une description de tâche a le droit de s'améliorer.
Les champs portent le reste : type, statut, priorité, dates, libellés, et un projet ou un sprint pour le contexte de planification. Une exécution assemblée pour l'agent peut inclure le titre et la description, le statut et la priorité actuels, le contexte de l'espace et du sprint, les commentaires récents — y compris celui qui a déclenché l'exécution —, les instructions et compétences de l'agent, les dépôts, l'environnement et les paramètres d'exécution. Des descriptions trop maigres ne sont pas compensées par de bons modèles.
L'attribution : deux emplacements, pas un seul
L'erreur de conception la plus répandue dans la gestion des tâches pour agents, c'est un champ d'assignation unique.
Gardez-les séparés. Les personnes sont assignées pour la responsabilité, et un espace peut en autoriser une ou plusieurs. Un agent ou une crew est assigné à l'emplacement d'exécution, qui reste à sélection unique. Une tâche peut avoir les deux à la fois : modifier l'ensemble des personnes ne change pas l'exécutant, et assigner un agent ne remplace pas les personnes.
L'avantage, c'est qu'aucune tâche n'appartient jamais à un bot. Quand un résultat exige une décision, un nom y est associé. Quand un agent se trompe, la conversation de revue a un participant. Notre présentation de la gestion de projet avec Claude Code montre la même séparation sur une seule tâche, de l'issue à la fusion.
Les crews occupent le même emplacement d'exécution, et l'exécution se fait leader en premier : l'agent leader démarre, lit le contexte, puis mobilise les membres selon les besoins. Utilisez un seul agent pour un travail bien défini et une crew quand le travail demande de la coordination.
Le statut : la partie qui contrôle l'exécution
Le statut n'est pas décoratif dès lors que des agents entrent en jeu. Chaque statut visible appartient à une catégorie, et cette catégorie porte une signification système.
| Catégorie de statut | Ce qu'elle signifie | Effet sur les exécutions d'agents |
|---|---|---|
| Backlog | En attente, pas prêt | Créer ou assigner ici ne déclenche aucune exécution |
| Non démarré | Prêt, pas commencé | Passer ici depuis le backlog peut démarrer l'agent assigné |
| Démarré | En cours | Les exécutions se poursuivent ; plusieurs statuts peuvent partager cette catégorie |
| Terminé | Fait, terminal | Terminal, mais n'annule pas une exécution déjà active |
| Annulé | Ne continuera pas | Arrête les exécutions démarrées pour la tâche |
| Doublon | Représenté ailleurs | Arrête les exécutions démarrées pour la tâche |
Deux conséquences méritent d'être bien assimilées. Le backlog est une véritable zone de préparation : préparez la tâche, attachez l'agent, et rien ne se passe avant que vous ne la déplaciez. Et marquer quelque chose comme terminé n'équivaut pas à l'arrêter : annulez donc une exécution que vous voulez réellement interrompre.
La deuxième règle, c'est que le statut du cycle de vie et l'état de travail de l'agent sont distincts. Une tâche peut rester dans un statut démarré pendant que l'agent travaille, attend une réponse humaine, attend une revue humaine ou signale une erreur. Les états d'exécution tels que en file d'attente, distribué, en cours, terminé, échoué et annulé décrivent la progression de l'exécution et ne déplacent pas automatiquement la tâche. C'est en confondant les deux qu'un tableau semble sain alors que trois résultats restent non lus.
La revue : rendre le transfert explicite
Les agents terminent leurs exécutions à l'un de deux endroits utiles : avec un résultat, ou avec une question. Dans les deux cas, il faut que cela parvienne à une personne.
Attendre une réponse humaine, attendre une revue, et un travail échoué ou bloqué sont des signaux d'attention. Ils alimentent une file personnelle, et dans Sharkly il s'agit de la boîte de réception de l'agent, où la personne responsable peut ouvrir la tâche, répondre dans le contexte, examiner le résultat ou décider de relancer ou de réattribuer le travail.
Les commentaires constituent la conversation durable autour de la tâche. Utilisez-les pour le nouveau contexte, les conclusions de revue et les décisions, et gardez l'objectif stable ainsi que les critères d'acceptation dans la description, afin que l'exigence en cours reste facile à retrouver. Le commentaire d'un membre sur une tâche dont l'agent assigné est prêt peut mettre en file une nouvelle exécution : c'est ce qui permet au retour de revue de poursuivre le travail plutôt que de lancer un second processus. Les mentions changent la donne : mentionner une personne ou utiliser une mention globale ne déclenche pas en soi une exécution d'agent, et un commentaire qui mentionne d'autres cibles sans l'assigné supprime l'exécution par défaut.
Avant d'accepter, lisez les preuves, pas seulement le diff. Le journal d'exécution montre pourquoi une exécution a été mise en file, quand elle a commencé et s'est terminée, les appels d'outils et événements d'exécution, la source du déclenchement et les détails de l'échec. Accepter, c'est une personne qui décide que le résultat est correct, ce qu'aucun état d'exécution ne peut faire à votre place. Téléchargez Sharkly si vous voulez que ces états soient reliés entre eux plutôt qu'assemblés à la main.
Un modèle de tâche à copier
Les équipes qui rédigent bien leurs tâches pour agents convergent généralement vers le même squelette. Gardez-le dans un snippet et remplissez-le ; l'ensemble prend environ trois minutes et évite une exécution gaspillée.
Outcome: <what is true when this is done>
Context:
- Why this matters now
- Observed behavior, with the exact error or reproduction steps
- Files, links, or examples that are relevant
Scope:
- In: <the change you want>
- Out: <adjacent work the agent should not touch>
Constraints:
- Decisions already made, conventions to follow, things not to change
Review:
- How completion will be checked, and by whom
La ligne « hors périmètre » est celle qui rapporte le plus vite. Un agent à qui l'on donne un objectif étroit sans aucune limite a tendance à améliorer des choses que vous n'avez pas demandées, et chacune de ces améliorations coûte du temps de revue. Nommer ce qu'il faut laisser tranquille coûte moins cher que de relire ce qu'il a touché.
Cinq erreurs à éviter
- Un seul champ d'assignation. La responsabilité et l'exécution se confondent, et la notion de propriétaire disparaît.
- Confondre une exécution terminée avec un résultat terminé. Le fait que l'exécution se termine ne dit rien de la justesse du changement.
- Relancer les exécutions échouées par réflexe. Ouvrez d'abord le journal. Des erreurs de fournisseur qui se ressemblent exigent souvent des correctifs opposés.
- Laisser les revues s'accumuler. Les résultats d'agents non relus sont une dette qui s'accumule plus vite que les pull requests non fusionnées.
- Rédiger des tâches pour la personne qui sait déjà. Si les critères d'acceptation sont dans votre tête, l'agent devine.
FAQ
Un agent peut-il modifier le statut d'une tâche ? Dans certaines limites. Le workflow du type de tâche détermine quels statuts sont disponibles, donc un agent ne peut choisir que les statuts autorisés par ce workflow.
Que se passe-t-il si je commente pendant qu'une exécution est active ? Un commentaire éligible peut être mis en file pour le cycle d'exécution suivant plutôt que de lancer un doublon parallèle, et les commentaires rapprochés sont regroupés afin de ne pas créer d'exécutions en attente en double.
Faut-il un type de tâche distinct pour le travail des agents ? Généralement non. Utilisez un type distinct lorsque le travail nécessite un ensemble de champs ou un workflow nettement différents, et des libellés quand une classification légère suffit.
En quoi est-ce différent de la gestion de projet classique ? Les primitives sont les mêmes ; la rigueur ne l'est pas. Notre guide sur la gestion de projet pour agents IA détaille ce qui change dans chaque primitive quand un exécutant ne peut pas poser de question de clarification dans le couloir.
