Le tableau de bord de projet de votre équipe repose sur un postulat silencieux : chaque assigné est une personne. Chaque changement de statut a été déclenché par quelqu'un. Chaque « Terminé » signifie qu'un humain a fait le travail et qu'un autre humain y a jeté un œil. Ce postulat a tenu pendant vingt ans de logiciels de gestion de projet, et il vacille le jour où votre équipe commence à confier du vrai travail à des agents de codage IA.
Les agents ne se comportent pas comme les assignés pour lesquels votre tableau a été conçu. Ils travaillent à 2 h du matin. Ils terminent en quelques minutes, puis attendent, en silence, que quelqu'un s'en aperçoive. Ils produisent un diff, une exécution de tests et un résumé plutôt qu'une mise à jour de standup. Si votre outil de suivi ne peut représenter rien de tout cela, le travail des agents se déroule hors du tableau : dans des terminaux privés, des conversations privées et des décisions privées. Le travail est fait, mais personne ne peut le voir, se l'approprier ou l'accepter.
Combler cet écart est une discipline qui a un nom : la gestion de projet d'agents IA. Ce guide la définit, la distingue des termes avec lesquels on la confond, détaille sa boucle opérationnelle et montre ce qui change dans chaque primitive de gestion de projet familière. Nous utiliserons Sharkly comme implémentation de référence, tout comme notre guide sur l'orchestration d'agents IA : la catégorie d'abord, le produit ensuite.
En bref : qu'est-ce que la gestion de projet d'agents IA ?
La gestion de projet d'agents IA est la pratique consistant à assigner, suivre et réviser le travail effectué par des agents IA aux côtés de celui des personnes, afin que chaque tâche d'agent ait un responsable, un statut, un contexte complet et un humain qui accepte ou rejette le résultat. Elle traite les agents comme des assignés au sein d'un système de travail partagé, et non comme des outils dans des terminaux privés. Elle se distingue de l'orchestration d'agents, qui fait tourner les agents ; la gestion de projet d'agents rend leur travail visible, attribué et accepté. Vous en avez besoin lorsque le travail des agents devient un travail d'équipe : plusieurs agents, plusieurs personnes et des résultats suffisamment importants pour être révisés.
La définition décortiquée
La gestion de projet d'agents IA est la discipline qui consiste à gérer un travail dont les assignés incluent des agents IA : définir des tâches que les agents peuvent exécuter, les assigner au bon agent ou à la bonne personne, conserver le contexte et l'historique d'exécution dans un lieu partagé unique, et faire passer chaque résultat par une révision et une acceptation humaines.
Cinq mots de cette phrase portent tout le poids :
- Assignation. Un agent peut recevoir une tâche comme un collègue, avec l'objectif, les contraintes et les critères d'acceptation attachés, et non collés dans un prompt qui disparaît à la fermeture du terminal.
- Suivi. Le travail de l'agent a un statut que toute l'équipe peut voir, de « en file d'attente » à « en cours » puis « en attente de révision », aux côtés du travail humain dans le même plan.
- Contexte. L'agent lit sa tâche comme le ferait un nouveau collègue : description, commentaires, code lié, décisions antérieures. Et sa production revient dans ce même enregistrement.
- Révision. Une personne lit ce que l'agent a produit avant que cela compte.
- Responsabilité. Chaque tâche d'agent a un humain qui en répond. L'agent a exécuté ; une personne assume le résultat.
Si votre configuration réunit ces cinq éléments, vous faites de la gestion de projet d'agents IA, quel que soit l'outillage. Si elle n'en réunit aucun, vous avez des agents, mais vous n'avez pas de gestion.
Ce que la gestion de projet d'agents IA n'est pas
Trois termes voisins sont amalgamés avec celui-ci, et cet amalgame crée une vraie confusion lorsque les équipes cherchent des outils.
Pas de la gestion de projet traditionnelle avec des agents greffés dessus
Jira, Linear et leurs pairs ont été bâtis sur le postulat de l'assigné humain : un seul type d'assigné, des statuts calqués sur les rythmes de travail humains, et aucune distinction dans le modèle de données entre qui est responsable et ce qui exécute. Certains ont évolué vers les agents (Linear peut déléguer un ticket à un agent de codage connecté, qui remonte sa progression et un diff sur le ticket), mais l'exécution se déroule toujours à l'intérieur de l'agent hébergé du fournisseur que vous avez connecté, selon les conditions de ce fournisseur. Ce que vous n'obtenez pas, c'est une couche neutre pour faire tourner votre propre mélange de runtimes sur des machines que vous contrôlez, avec un enregistrement partagé unique de chaque exécution. Nous comparons jusqu'où vont les outils de suivi traditionnels dans notre guide des alternatives à Jira pour les équipes humains-agents.
Pas de l'orchestration d'agents
C'est la distinction qui compte le plus, car les deux disciplines sont adjacentes et complémentaires. L'orchestration d'agents concerne l'exécution : acheminer une tâche vers un agent, isoler l'espace de travail de chaque agent pour que les exécutions parallèles ne se percutent pas, et maintenir la machinerie en marche. La gestion de projet d'agents concerne le travail lui-même : qui l'a demandé, ce qu'il doit accomplir, dans quel état il se trouve, qui le révise et s'il a été accepté.
Une façon simple de les distinguer : l'orchestration fait tourner les agents ; la gestion de projet d'agents rend leur travail visible, attribué et accepté. Une équipe peut avoir une excellente orchestration et aucune gestion de projet d'agents, ce qui ressemble à dix agents qui tournent en parallèle sans anicroche pendant que personne ne peut dire sur quoi ils travaillent ni qui valide.
Pas un framework d'agents
Les frameworks tels que LangGraph ou les patrons multi-agents des SDK d'agents sont des bibliothèques de code pour construire des applications d'agents. Ils concernent les développeurs qui construisent un agent. La gestion de projet d'agents concerne les équipes qui utilisent des agents, le plus souvent des runtimes de codage prêts à l'emploi comme Claude Code ou Codex, et qui ont besoin que ce travail s'intègre dans un plan d'équipe. Vous pouvez adopter la gestion de projet d'agents sans écrire une seule ligne de code de framework. Si déléguer du travail de codage à des outils autonomes est nouveau pour vous, commencez par notre introduction à ce qu'est le codage agentique.
La boucle opérationnelle : définir, assigner, exécuter, réviser, accepter
Dépouillez n'importe quelle configuration de gestion de projet d'agents jusqu'à son squelette et vous retrouvez la même boucle en cinq étapes. Chaque étape a une moitié humaine et une moitié agent, et la boucle ne fonctionne que lorsque les deux sont explicites.
1. Définir. Une personne rédige la tâche : l'objectif, pourquoi elle compte, ce qui est dans le périmètre et hors périmètre, et comment l'achèvement sera jugé. Cela compte encore plus avec des agents qu'avec des personnes, car un agent ne peut pas absorber le contexte de couloir. Un collègue qui reçoit un ticket vague pose une question de clarification à midi ; un agent soit pose la question dans un commentaire, soit devine.
2. Assigner. La tâche revient à un assigné, et c'est ici que la primitive se scinde en deux. La responsabilité revient à une personne : l'humain qui assume le résultat. L'exécution revient à un agent, ou à une personne pour le travail que les agents ne devraient pas toucher. Maintenir ces deux champs séparés, plutôt qu'un seul « assigné » surchargé, est le changement le plus important du modèle de données en gestion de projet d'agents. Cela préserve la responsabilité tout en permettant à l'exécution de passer au logiciel. Notre tutoriel sur l'assignation d'un ticket Jira à un agent IA et l'obtention d'une PR en retour montre cette étape de bout en bout.
3. Exécuter. L'agent lit la tâche, inspecte le code, effectue des modifications, lance des vérifications. C'est l'étape dont l'orchestration a la charge, et la gestion de projet d'agents ne lui demande qu'une chose : que la progression, les blocages et les résultats reviennent dans la tâche plutôt que de défiler dans un terminal. Une exécution qui ne laisse aucun enregistrement partagé est une exécution que l'équipe ne peut pas gérer.
4. Réviser. L'agent s'arrête et une personne lit : le diff, les résultats de tests, le résumé de l'agent lui-même sur ce qu'il a fait et ce qui reste incertain. La révision est le point où la vitesse de l'agent rencontre le jugement humain, et la version honnête de cette étape inclut le rejet. Un réviseur qui ne peut que cliquer sur « approuver » est un tampon, pas un filtre.
5. Accepter. La personne responsable prend la décision : accepter, demander des modifications ou réassigner. L'acceptation se distingue de la révision comme la fusion se distingue de la lecture d'une pull request. C'est le moment où la responsabilité se concrétise, et il est délibérément humain. Les agents recherchent, exécutent, testent et font leur rapport. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat.
Puis la boucle s'auto-alimente : le travail accepté définit la tâche suivante, et le travail rejeté revient à l'étape de définition avec des critères plus précis.
Ce qui change dans chaque primitive de gestion de projet
Le vocabulaire de la gestion de projet survit à l'arrivée des agents. Les mécanismes sous-jacents changent presque tous.
| Primitive | Postulat de la gestion de projet traditionnelle | Gestion de projet native pour agents |
|---|---|---|
| Tâche | Rédigée pour un humain qui peut se renseigner autour de lui | Brief autonome avec objectif, périmètre, liens et critères d'acceptation vérifiables |
| Assigné | Un seul champ, toujours une personne | Deux champs : une personne responsable plus un agent ou une personne qui exécute |
| Statut | Déplacé à la main selon les rythmes humains (jours) | Statut de workflow plus un état d'exécution en direct (en file d'attente, en cours, échoué) mis à jour en quelques minutes |
| Sprint | Dimensionné selon la disponibilité humaine | Périmètre mixte ; le débit des agents est limité par la capacité machine et la bande passante de révision |
| Capacité | Effectif et heures | Heures des personnes plus parallélisme des agents, avec la révision humaine comme véritable plafond |
| Piste d'audit | Commentaires et historique manuel des statuts | Journaux d'exécution, traces, diffs et rapports d'agents attachés à l'enregistrement de la tâche |
Les tâches cessent d'être des rappels pour devenir des briefs. Un assigné humain tolère l'ambiguïté ; un agent la convertit en réponses fausses et assurées. Rédiger des tâches avec un périmètre explicite et des critères d'acceptation, longtemps prêché et rarement pratiqué, devient essentiel.
Le statut se scinde en deux couches. Le statut de workflow décrit toujours où en est le travail pour l'équipe. En dessous, l'exécution de l'agent a ses propres états : en file d'attente, en cours, terminé, échoué, annulé. Une tâche peut rester « En cours » alors que l'exécution de son agent a échoué sans que personne ne l'ait remarqué. Un outillage natif pour agents fait remonter les deux couches et achemine les moments « en attente de votre révision » et « exécution échouée » vers la personne responsable, au lieu d'espérer que quelqu'un vérifie.
Les sprints gardent leur forme et changent leur physique. Un sprint reste un périmètre limité dans le temps avec un objectif. Mais quand une partie du périmètre s'exécute en minutes plutôt qu'en jours, la planification passe de « ce que les personnes peuvent finir » à « ce que les personnes peuvent définir et réviser ». Nous détaillons les mécanismes dans le fonctionnement des Sprints dans Sharkly.
La capacité devient un nombre à deux faces. La capacité côté agents relève du calcul de machines et de parallélisme. La capacité côté humains, c'est la bande passante de révision : combien de résultats d'agents votre équipe peut lire attentivement. Le second nombre est presque toujours le plus petit, et prétendre le contraire est la façon dont les équipes finissent par fusionner du travail que personne n'a lu.
La piste d'audit passe d'une hygiène facultative à une exigence fondamentale. Quand une personne a fait le travail, vous pouvez lui demander ce qui s'est passé. Quand c'est un agent, la seule réponse honnête est l'enregistrement d'exécution : la tâche, la trace, les vérifications lancées et le rapport laissé.
Quand vous n'avez pas besoin de gestion de projet d'agents IA
Un guide honnête inclut les cas où la réponse est « pas encore ». Passez la couche de gestion de projet d'agents quand vous êtes un développeur solo faisant tourner un seul agent, quand le volume d'agents se limite à quelques tâches par semaine qui peuvent vivre comme des tickets ordinaires, ou quand le travail est un prototypage jetable qui ne sera jamais révisé ni maintenu. Le processus doit suivre le volume, pas le précéder.
Adoptez-la quand les signaux s'inversent : plus d'une personne a besoin de voir le travail des agents, plus d'un agent tourne en même temps, ou une modification d'agent non révisée a déjà causé un désastre. Utilisez un système partagé quand le travail des agents devient un travail d'équipe, et pas avant.
À quoi ressemble la gestion de projet d'agents en pratique : Sharkly
La catégorie est indépendante des outils ; les mécanismes sont plus faciles à voir dans un système concret. Sharkly est un système de gestion du travail pour les personnes et les agents. Ce n'est pas un remplacement de Claude Code, Codex ou d'autres outils d'exécution. Il ajoute la couche partagée de tâches, de contexte, de contrôle et de révision autour des runtimes que votre équipe utilise déjà, l'utilisation des modèles continuant via les abonnements ou les clés API configurés dans ces outils.
La tâche est l'unité d'enregistrement : objectif, description, statut, priorité, commentaires, et l'état d'exécution, la trace et le résultat de l'agent, le tout au même endroit. L'assignation met en œuvre la séparation décrite plus haut : une personne enregistre la responsabilité humaine tandis qu'un agent ou une Crew est l'assigné à l'exécution, et une tâche peut porter les deux à la fois. Le backlog fait office d'état de stationnement, si bien qu'assigner un agent ne lance pas d'exécution tant que la tâche n'a pas atteint un statut prêt à être traité.
Pendant qu'un agent travaille, les états d'exécution restent distincts du statut de workflow de la tâche, et les deux sont visibles sur le tableau. Les résultats, les blocages et les discussions de suivi reviennent dans la tâche : le rapport de l'agent est stocké sous forme de commentaire lié à sa trace d'exécution, et la boîte de réception achemine les moments « en attente de votre révision » vers la personne responsable. L'acceptation reste humaine. La documentation Sharkly approfondit chaque concept.
L'essentiel
La gestion de projet a gagné ses lettres de noblesse en rendant le travail humain visible, attribué et révisable. La gestion de projet d'agents IA étend le même contrat à des assignés qui se trouvent être des logiciels : définir clairement le travail, séparer responsabilité et exécution, laisser les résultats revenir dans un enregistrement partagé, et garder l'acceptation entre des mains humaines. L'orchestration rendra vos agents rapides. C'est cette discipline qui rend leur production digne de confiance. Commencez petit : prenez un élément récurrent du travail de vos agents qui vit aujourd'hui dans un terminal, donnez-lui une tâche avec de vrais critères d'acceptation, et faites-le passer une fois dans la boucle.
FAQ
Qu'est-ce que la gestion de projet d'agents IA en une phrase ?
C'est la pratique consistant à assigner, suivre et réviser le travail effectué par des agents IA aux côtés des personnes, afin que chaque tâche d'agent ait un responsable, un statut, un contexte complet et un humain qui accepte le résultat. En bref, elle traite les agents comme des assignés au sein d'un système de travail partagé plutôt que comme des outils dans des terminaux privés.
En quoi la gestion de projet d'agents IA diffère-t-elle de l'orchestration d'agents ?
L'orchestration fait tourner les agents : acheminement, isolation des espaces de travail, exécution parallèle, capacité machine. La gestion de projet d'agents rend leur travail visible, attribué et accepté : tâches, statuts, révision et responsabilité. Ce sont des couches complémentaires, et une configuration complète a besoin des deux. Notre guide sur l'orchestration couvre en profondeur le volet exécution.
Puis-je faire de la gestion de projet d'agents IA dans Jira ou Linear ?
Partiellement. Vous pouvez représenter les tâches d'agents sous forme de tickets, et certains outils de suivi délèguent désormais des tickets à des agents de codage connectés. Ce qu'ils ne vous offrent pas, c'est une couche d'exécution neutre à travers votre propre mélange de runtimes et de machines, avec un enregistrement partagé unique de chaque exécution. Consultez notre comparaison des alternatives à Jira pour les équipes humains-agents.
Qui est responsable quand un agent IA fait le travail ?
Une personne, toujours. Dans la gestion de projet d'agents, l'humain responsable et l'agent qui exécute sont des champs distincts sur la même tâche : l'agent exécute, et la personne assume le résultat, révise le travail et décide de l'acceptation. Un agent n'est jamais la réponse finale à « qui a validé ceci ».
Que rechercher dans un outil de gestion de projet d'agents IA ?
Quatre choses correspondent à la boucle opérationnelle : une assignation qui transmet le contexte complet de la tâche à l'agent, un suivi en direct qui affiche à la fois le statut de workflow et l'état d'exécution, une piste d'audit où les traces et les résultats reviennent dans la tâche, et une étape intégrée de révision et d'acceptation humaines. Ajoutez une planification de Sprint hybride si vous faites tourner des agents dans une cadence d'équipe.
