Votre backlog était autrefois une liste dans laquelle vous et quelques collègues piochiez. Vous lisiez le premier élément, vous le compreniez, vous l'exécutiez. Le triage était rapide, car la seule question était « qui a le temps ? ». Aujourd'hui, certains de ces éléments peuvent être pris en charge par un agent de codage plutôt que par une personne, et la file d'attente tranquille se transforme en source de petites erreurs coûteuses : un agent se lance sur une tâche que personne n'a fini de rédiger, deux agents s'emparent de travaux qui se chevauchent, et une colonne « terminé » se remplit de résultats que personne n'a demandés.
Le problème, ce ne sont pas les agents. C'est qu'un backlog conçu pour des humains a discrètement changé de fonction. Il a cessé d'être une liste de choses à faire pour devenir une file de répartition capable de déclencher l'exécution. Dès qu'une ligne peut lancer du vrai travail, le moment où vous déplacez une tâche et celui où vous décidez à qui elle appartient ont des conséquences qu'ils n'avaient jamais eues auparavant.
C'est la couche dans laquelle s'inscrit Sharkly. Vous avez déjà des agents de codage ; Sharkly en fait une équipe en donnant au backlog une signification partagée. Une Task est l'unité de travail principale, le Backlog est l'endroit où patiente le travail non engagé, et Triage est une file d'admission dédiée où les éléments entrants attendent qu'une décision soit prise. Cet article explique comment trier un backlog mixte humains-agents sans que ces files ne basculent dans le chaos, et se termine par une checklist que vous pouvez appliquer dès aujourd'hui.
Ce que signifient backlog et triage quand les agents peuvent faire le travail
Deux définitions font ici l'essentiel du travail, alors soyons précis.
Un backlog est l'ensemble du travail non engagé : des tâches qui existent mais que personne n'a encore décidé de commencer. Le triage est la décision d'admission prise sur les éléments nouveaux ou flous : l'accepter, le refuser, le marquer comme doublon ou le reporter à plus tard. Les humains ont toujours fait les deux de manière informelle. Ce qui change, c'est que dans une équipe humains-agents, le résultat du triage inclut désormais « quel agent exécute ceci », et que le fait d'engager une tâche peut déclencher une exécution.
Voici la frontière qui déroute en premier : attribuer un Agent à une tâche dans le Backlog ne la démarre pas. Le Backlog est une zone de stationnement où le travail est préparé avant l'exécution. L'exécution ne commence que lorsque la tâche quitte le Backlog pour un statut prêt à être traité, et qu'un Computer et un Runtime sont disponibles. Ainsi, « attribuer l'agent » et « démarrer l'agent » sont deux événements distincts, le statut du backlog faisant office de point de contrôle entre les deux.
Une autre frontière mérite d'être énoncée clairement : les agents ne tiennent pas de backlog privé. Il n'existe aucune file cachée qu'un Agent traiterait seul. Chaque élément qu'un Agent touchera vit dans le tableau partagé, ce qui rend le triage possible plutôt que hasardeux.
Là où une configuration maison cesse de passer à l'échelle
Un tableur, un tableau Kanban et quelques terminaux suffisent pour une personne et deux agents. Cela cesse de passer à l'échelle à des points prévisibles, et chacun se manifeste par une défaillance bien précise.
La colonne de statut ne veut rien dire pour les agents. Sur un tableau manuel, déplacer une carte vers « En cours » est une note destinée à vos collègues ; rien ne s'exécute. Le tableau et le travail réel divergent donc : une carte affiche « En cours » alors que l'agent a terminé depuis une heure, ou « À faire » alors qu'un agent en est déjà à trois commits parce que quelqu'un l'a lancé depuis un terminal. Personne ne fait confiance au tableau, donc personne ne l'utilise.
Les décisions de triage vivent dans la tête d'une seule personne. Celui qui traite les demandes entrantes se souvient qu'un bug a déjà été signalé, qu'une fonctionnalité a été refusée le trimestre dernier, qu'une tâche nécessite d'abord une contribution du design. Quand cette personne est absente, des doublons sont créés et des agents démarrent un travail qui aurait dû être refusé à l'admission. La file n'a pas de mémoire.
L'attribution et le périmètre se décident dans le même moment précipité. Un périmètre flou reste gérable quand un humain prend une tâche et pose une question. Un agent ne s'arrête pas pour demander ; il exécute ce que vous lui avez donné et renvoie un résultat convaincu et faux. Le coût d'un triage bâclé est passé de « un collègue est brièvement perdu » à « un agent a brûlé une exécution et un cycle de revue sur la mauvaise chose ».
Trier un backlog mixte, étape par étape
Voici la séquence qui garde un backlog humains-agents honnête. Chaque étape nomme la défaillance qu'elle évite.
1. Videz la file d'admission avant de toucher au backlog. Les nouvelles demandes arrivent dans Triage, et non directement dans le backlog. Traitez chaque élément avec l'une des quatre décisions : accepter, refuser, marquer comme doublon ou reporter. Triage est une file d'admission, pas un filtre enregistré ni un générateur de formulaires : la décision est donc explicite et consignée. Défaillance évitée : des travaux refusés ou en doublon qui deviennent discrètement de vraies tâches qu'un agent reprend ensuite.
2. Cadrez la tâche avant qu'elle ne soit éligible à un agent. Un élément accepté devient une Task, mais elle reste dans le Backlog pendant que vous rédigez les critères d'acceptation, rattachez le dépôt et notez les contraintes. C'est l'étape que l'on saute sous la pression du temps. Défaillance évitée : un agent qui part d'un titre d'une seule ligne et renvoie un résultat qui correspond techniquement aux mots mais manque l'intention.
3. Décidez à qui revient la tâche, et considérez « quel agent » comme un vrai choix. Certaines tâches veulent un humain. D'autres veulent un agent, et parmi les agents, le bon dépend de la tâche : un refactoring, une passe d'écriture de tests et une mise à jour de documentation ne sont pas le même métier. Aiguillez délibérément au lieu de vous rabattre par défaut sur l'agent qui se trouve être libre. Notre guide d'aiguillage pour les agents de codage explique comment trancher. Défaillance évitée : le mauvais runtime qui vient à bout d'une tâche pour laquelle il est mal adapté.
4. Gardez-la dans le Backlog jusqu'à ce qu'elle soit vraiment prête. C'est le point de contrôle. Une tâche peut être entièrement attribuée et rester dans le Backlog sans qu'aucune exécution ne démarre. Servez-vous-en. Ne la déplacez pas avant que le périmètre soit fixé et que vous souhaitiez réellement que le travail commence. Défaillance évitée : une tâche à moitié rédigée qui lance une exécution parce que quelqu'un l'a glissée dans la mauvaise colonne.
5. Engagez-la, et laissez l'exécution démarrer. Déplacez la tâche vers un statut prêt, ou tirez-la dans un Sprint. Quand une tâche dotée d'un Agent prêt quitte le Backlog et qu'un Computer et un Runtime sont disponibles, l'exécution commence. Le changement de statut et le travail ne font alors plus qu'un, ce qui est tout l'intérêt.
Pour les équipes qui fonctionnent par cycles, la planification de Sprint pour les équipes humains-agents montre comment la même étape d'engagement délimite une période plutôt qu'une seule tâche.
Le statut du backlog devient un point de contrôle de l'exécution
Le changement mental est le suivant : sur un tableau humain, le statut est une étiquette qui décrit la réalité. Sur un tableau humains-agents, le statut est un levier qui change la réalité. Déplacer une tâche hors du Backlog est l'action qui démarre l'agent ; votre discipline de triage est donc désormais votre mécanisme de sécurité.
C'est aussi là que se situe le contrat humains-agents. Les agents font de la recherche, exécutent, testent et rendent compte. Les personnes décident de ce qui entre dans le backlog, de ce qui est engagé et de ce qui est livré. L'automatisation s'arrête là où le jugement de l'équipe est requis. La vue Plan réunit le Backlog, les Sprints et les Projets au même endroit, de sorte que la décision d'engagement soit visible plutôt qu'enfouie dans un terminal, et que l'exécution, les blocages, les résultats et la revue reviennent tous à la Task au lieu de se disperser dans des sessions privées.
C'est pourquoi l'hygiène du backlog compte davantage avec des agents, et non l'inverse. Un backlog humain en désordre n'est qu'un fouillis. Un backlog d'agents en désordre est un fouillis qui s'exécute parfois tout seul. Le tableau garde le contexte, la responsabilité, la progression, les résultats et la revue visibles de l'admission à la livraison, ce qui fait la différence entre une file que vous gérez et une file qui vous gère. Quand c'est la revue qui s'accumule plutôt que l'admission, il s'agit d'un autre goulot d'étranglement, traité dans pourquoi la revue humaine est la vraie contrainte.
Vous pouvez appliquer tout cela avec un tableur et de la discipline manuelle si votre volume est faible. Si vous traitez déjà un flux d'admission régulier et faites tourner plusieurs agents, Sharkly vous fournit la file Triage, le point de contrôle Backlog et un tableau partagé pour que ces décisions cessent de vivre dans votre tête. Pour une vue plus large du même flux de travail, consultez notre guide sur la gestion des tâches pour agents IA et la différence entre Triage et votre Inbox personnelle.
Une checklist de triage à appliquer dès aujourd'hui
Passez-la en revue sur votre tableau actuel. Chaque « non » est un endroit où les agents vous surprendront.
- Les nouvelles demandes atterrissent-elles quelque part avant le backlog ? Si l'admission part directement dans « À faire », vous n'avez aucune étape accepter/refuser/doublon et les doublons sont inévitables.
- Le périmètre de chaque tâche du backlog est-il assez solide pour être confié à un inconnu ? S'il n'est pas assez bon pour une nouvelle recrue, il ne l'est pas pour un agent.
- Déplacer une tâche déclenche-t-il réellement quelque chose ? Si vos changements de statut ne sont que des étiquettes, le tableau et le travail finiront par diverger.
- L'attribution est-elle une vraie décision, y compris le choix de l'agent ? Se rabattre par défaut sur l'agent libre, ce n'est pas de l'aiguillage.
- Pouvez-vous dire, là, tout de suite, sur quoi travaille chaque agent et ce qui attend une revue ? Si la réponse vit dans la mémoire de quelqu'un ou dans le défilement d'un terminal, le triage n'a pas de source de vérité partagée.
- Le travail terminé revient-il à la tâche, et non à une session privée ? Les résultats, les blocages et les diffs appartiennent à l'enregistrement partagé, pour que la revue ait de quoi agir.
Corrigez les deux premiers points avant d'augmenter le nombre d'agents. Une étape d'admission propre et un périmètre de tâche honnête évitent la plupart des défaillances coûteuses ; tout le reste n'est qu'un raffinement par-dessus un backlog qui veut déjà dire quelque chose.
