Aller au contenu principal

Créer et gérer des agents de projet

Configure un agent pour les tâches d’un projet, accorde son équipement et démarre une tâche dont tu peux vérifier le résultat.

12 min de lecture

Crée un agent de projet pour disposer d’une configuration réutilisable sur les tâches du projet. Il associe un environnement d’agent, un modèle, des instructions et un équipement autorisé. Chaque tâche sur laquelle il travaille s’exécute dans un worker, une copie de l’agent en cours d’exécution dans sa propre sandbox. Tu dois pouvoir modifier le projet actif. Les Membres voient les agents du projet dans son onglet Agents, qui leur indique de demander un nouvel agent à un Éditeur ou à un Admin. Tant qu’un projet n’a pas d’agents propres, ses tâches peuvent aller à l’agent standard de l’organisation. Seuls un Propriétaire ou un Admin peuvent changer les secrets accordés.

Préparer la première tâche

Choisis un résultat limité, comme vérifier les approbations manquantes dans un brief de lancement. L’agent nécessite des identifiants de fournisseur compatibles et une sandbox disponible. Enregistrer sa configuration ne prouve pas encore qu’une exécution réussira.

Sépare les instructions réutilisables de la tâche. « Repère les preuves manquantes et indique les contrôles effectués » appartient à l’agent. Le document, la date de revue et les critères d’acceptation appartiennent à la tâche.

L'onglet Agents — les agents du projet ; chaque ligne nomme l’environnement d’agent, le fournisseur et le modèle.

Configurer l’agent

  1. Choisir un nom et un environnement

    Ouvre l’onglet Agents du projet et choisis Nouvel agent. Donne-lui un Nom reconnaissable, puis choisis l’Environnement d'agent, son programme d’exécution. Les noms sont uniques dans le projet, qui accepte jusqu’à 50 agents.

    Tale tire du nom un handle de mention, que tu saisis après @ pour trouver l’agent : « My Opus Agent #3 » devient @my-opus-agent-3. Si ce handle est déjà pris, par un autre agent du projet ou par un membre ou une automatisation qu’on mentionne déjà ainsi, l’agent reçoit le suivant libre : -02, puis -03. Si un membre ou une automatisation se met plus tard à répondre au handle de l’agent, l’agent passe lui aussi au suivant libre. Le handle figure dans l’onglet Agents et sous Nom quand tu modifies l’agent. Renommer l’agent change son handle ; les mentions écrites avant continuent de désigner l’agent et affichent son nouveau nom.

    Tu peux aussi partir d’une tâche : tant que le projet n’a pas d’agent, Créer un agent… sous Assigné à ouvre Nouvel agent par-dessus la tâche et lui assigne l’agent que tu crées.

  2. Choisir le modèle et le fournisseur

    Recherche un Modèle par nom ou identifiant API. Le même modèle peut apparaître une fois par fournisseur : lis le fournisseur de l’entrée avant de la choisir. Cela fixe la combinaison pour les prochaines exécutions. Les offres par abonnement n’apparaissent qu’avec un environnement compatible, et un modèle qui n’appelle des tools que via l’API Responses d’OpenAI, comme GPT-6.1 Sol, n’apparaît qu’avec Codex.

    Une ancienne configuration peut nommer un modèle sans fournisseur fixé. Le dialogue indique alors quel fournisseur le servirait actuellement ou pourquoi aucun ne peut le faire. Choisis une entrée pour fixer ce choix.

  3. Accorder l’équipement et écrire les instructions

    Sous Skills, connectors & outils, ajoute les bundles, services et opérations nécessaires. Pour un nouvel agent, les skills de documents docx, pptx, xlsx et pdf sont cochés s’ils sont accessibles au projet. Ils contiennent des consignes pour travailler avec des fichiers Word, PowerPoint, Excel et PDF. Décoche ceux dont l’agent n’a pas besoin. La modification d’un agent existant conserve son équipement enregistré. La liste de skills suit les accès des équipes du projet, pas seulement ta visibilité personnelle. Un skill absent peut donc demander une modification de son partage. Après une modification du partage, la liste se met à jour dans chaque boîte de dialogue Nouvel agent ou de modification ouverte, y compris dans les sessions d’autres personnes, sans rechargement.

    Le menu Skills d’un nouvel agent, avec les skills de documents déjà activés ; chaque skill indique qui l’a créé.

    Le champ de recherche du menu filtre les skills, connectors et outils au fil de la saisie. Rechercher dans les connaissances figure sous Connaissances comme toujours actif : chaque agent recherche dans les connaissances du projet, sans autorisation.

    Lis Écrit des données avant d’accorder un outil d’écriture : il autorise des opérations réelles selon ses règles d’accès. Le broker de connectors ne propose que des lectures aux agents. Les outils GitHub directs et les secrets explicitement accordés suivent d’autres voies.

    Modifier la priorité et l'agent assigné aux tâches permet à un agent de projet de prioriser les tâches existantes, de les assigner à un agent du même projet ou de retirer leur assignation, sans démarrer de travail. Cette autorisation reste désactivée tant que tu ne l’accordes pas et n’est pas proposée aux nœuds agent des automatisations. L’agent doit d’abord lire la tâche et joindre les valeurs lues à sa demande de modification. Si ces valeurs ont changé entre-temps, toute la demande est refusée et il doit relire la tâche. Un changement d’assignation exige une tâche ouverte, sans exécution active, revue en attente ou question ouverte. Modifier uniquement la priorité conserve ces passages de relais. Le Tool ne change ni le statut ni le réviseur, ne répond à aucune question destinée à une personne et ne lance aucune exécution. Seule une exécution active disposant de droits sur tout le projet peut l’utiliser, pas une exécution démarrée par un Membre.

    Revoir les résultats des tâches d’autres agents autorise un relecteur désigné à décider d’un résultat terminé produit par un autre agent de projet. Cette permission est désactivée au départ et n’est pas proposée aux nœuds agent des automatisations. Choisir un agent comme relecteur ne lui accorde pas cet outil et ne démarre aucune exécution. Il relit depuis sa propre tâche, avec des droits actuels sur tout le projet et la permission de relecture toujours accordée. Sa décision enregistre un retour et des éléments de vérification : une approbation termine la tâche examinée, tandis qu’une demande de modifications la remet à À faire sans démarrer de travail. Les compétences humaines requises et les approbations de workflows restent protégées. Configurer un relecteur indépendant décrit le parcours complet.

    Lancer d'autres agents sur des tâches permet à l’agent de mettre au travail un autre agent de ce projet, par exemple un agent coordinateur qui distribue le travail prêt et relance un agent après avoir répondu à sa question. Il désigne une tâche, éventuellement l’agent à qui l’assigner, et un message que l’exécution lancée traite en premier. L’exécution lancée agit pour le compte de la même personne que l’exécution du coordinateur, et elle désigne le coordinateur comme l’agent qui l’a lancée. Un agent lancé de cette façon ne peut pas lancer d’autres agents, une exécution démarrée par un Membre ne peut en lancer aucun, un coordinateur ne peut pas se lancer lui-même sur une autre tâche, et une tâche bloquée par une tâche ouverte n’est pas lancée. Un agent qui travaille déjà sur d’autres tâches est tout de même lancé : son exécution prend un worker distinct ou en attend un, et la réponse dit pourquoi elle attend. N’accorde cet outil qu’à un agent dont les instructions précisent quel travail il peut distribuer ; l’automatisation des tâches décrit ce qu’une telle exécution peut faire.

    Ajouter et modifier des entrées de connaissances permet à l’agent d’enregistrer des informations comme entrées de connaissances de toute l’organisation, une par sujet. Pour modifier une entrée, il doit indiquer la version qu’il a lue ; si l’entrée a changé entre-temps, rien n’est enregistré et l’agent intègre sa modification au texte actuel. Il ne peut pas supprimer d’entrées, et une exécution lancée par un Membre ne peut pas en enregistrer. Accorde-le à un agent dont les instructions précisent quelles informations méritent d’être conservées.

    Les appels de connectors d’une exécution se font au nom du membre qui l’a démarrée, que ce soit avec Démarrer l'agent, Relancer, un passage à En cours ou une mention de l’agent avec @. Ils utilisent les identifiants des connectors de l’organisation et sont enregistrés au nom de ce membre. Si ce membre quitte l’organisation ou est désactivé, les appels sont refusés : utilise Annuler l'exécution (ou laisse l’exécution se terminer), puis redémarre-la pour qu’elle se fasse en ton nom. Quand un commentaire relance l’exécution pour la guider, comme le font tous les environnements sauf Claude Code, les appels se font ensuite au nom de l’auteur du commentaire.

    Rédige des Instructions qui définissent responsabilité, preuves et limites. Pour la revue du lancement : « Lis le brief fourni. Signale les approbations manquantes et les dates contradictoires avec le passage correspondant. Ne termine pas la tâche. »

  4. Vérifier et enregistrer

    Si le travail demande des Secrets, un Propriétaire ou Admin accorde des identifiants nommés de l’organisation. L’agent en cours peut lire leurs valeurs : utilise des jetons limités et remplaçables. Modifier une valeur partagée affecte aussi les autres agents et nœuds de workflow qui utilisent ce nom. Une exécution qu’un Membre démarre ne reçoit aucun de ces secrets, ni le jeton d’une connexion GitHub équipée : un Éditeur ou un rôle supérieur doit démarrer le travail qui en a besoin.

    Pour un repository privé, utilise une clé limitée à ce repository et précise les opérations Git autorisées dans les instructions de l’agent. Les exécutions équipées d’identifiants utilisent le nom et l’e-mail Git du propriétaire de l’espace de travail, même sans accès accordé au connector GitHub. Garde la vérification de l’hôte SSH activée. Un sandbox auto-hébergé fait passer le SSH du repository par son proxy existant ; Accès SSH aux repositories décrit la configuration.

    Choisis Créer l'agent. Vérifie l’environnement, le fournisseur et le modèle de la nouvelle ligne. Rouvre l’agent pour examiner l’équipement et les instructions enregistrés.

Affecter et démarrer le travail

Ouvre une tâche du même projet, affecte-la à l’agent et choisis Démarrer l'agent. L’affectation et l’exécution sont deux actions distinctes. Fournis les fichiers et les critères d’acceptation avant le démarrage. Il n’est pas nécessaire de pouvoir modifier le projet : un Membre fait travailler un agent sur les tâches qu’il a créées ou qui lui sont attribuées, un Éditeur ou un rôle supérieur sur n’importe quelle tâche du projet. Une exécution qu’un Membre démarre s’en tient à cette tâche, sans les secrets de l’agent et dans un espace de travail à part ; Exécutions démarrées par un Membre détaille ce qui change.

Le compte rendu apparaît dans les commentaires et les fichiers collectés sont joints comme résultats. Si un admin a activé la génération d’images, l’agent peut aussi créer des images pour la tâche ; elles apparaissent parmi les fichiers produits et comptent pour le membre qui a lancé l’exécution. Après un travail réussi, la tâche passe En revue pour que le relecteur humain ou l’agent relecteur indépendant désigné l’évalue. Mentionne l’agent dans un commentaire pour guider ou poursuivre le travail. L’environnement d’agent détermine si le message rejoint le processus actif ou lance une continuation.

L’automatisation des tâches explique le suivi, l’arrêt et la revue. L’assistant de chat ordinaire reste distinct, même avec un contexte de projet.

Faire travailler un agent sur plusieurs tâches

Un agent est une configuration ; un worker en est une copie en cours d’exécution. Chaque tâche sur laquelle l’agent travaille en même temps s’exécute dans un worker distinct : une sandbox avec son propre espace de travail, sa mémoire et ses processus. Deux tâches ne partagent donc jamais de fichiers et ne se ralentissent pas l’une l’autre. Lance l’agent Scribe sur « Notes de version » et sur « Journal des modifications » : les deux avancent en même temps, chacune dans son worker.

Les workers comptent dans la limite Workers d’agent de ton organisation, dans Sandboxes, que partagent tous les agents de l’organisation. Quand tous sont occupés, une nouvelle exécution attend au lieu d’échouer, et la tâche indique pourquoi sous Exécution : En attente d’un worker. Elle démarre d’elle-même dès qu’un worker se libère, sans consommer de nouvelle tentative automatique, et dispose alors de tout son temps de travail. Les Propriétaires et les Admins y voient un lien pour relever la limite. Quand plusieurs exécutions attendent, un worker libéré va d’abord à l’agent qui a le moins d’exécutions en cours, puis à l’exécution qui attend depuis le plus longtemps. Pour retirer une exécution en attente, utilise Annuler l'exécution ou affecte la tâche à quelqu’un d’autre : une exécution qui n’a pas encore démarré est annulée avec la réaffectation.

L’exécution suivante d’une tâche retourne dans le worker où elle a travaillé en dernier quand celui-ci est libre : l’agent y poursuit la conversation et retrouve ses fichiers. Si ce worker est occupé, l’exécution en prend un autre et repart de zéro avec la description, la discussion, les pièces jointes et les résultats de la tâche. Après l’échec ou l’annulation d’une exécution, son worker reste réservé à cette tâche pendant 15 minutes, pour qu’une relance retrouve ce que l’exécution a laissé ; l’exécution d’une autre tâche ne le prend que si aucun autre worker n’est libre.

L’agent standard

Un projet sans agents propres peut quand même confier du travail à un agent. Sauf si un Admin l’a désactivé dans Gouvernance > Modèles, Assigné à y propose l’option Agent standard, à toutes les personnes qui peuvent assigner la tâche, Membres compris. La première fois que quelqu’un la choisit, Tale met l’agent en place dans le projet et lui assigne la tâche. Tu le démarres ensuite comme n’importe quel autre agent, ou tu le mentionnes dans un commentaire. S’il ne peut pas démarrer pour toi, le champ de commentaire te le signale, et ton commentaire est enregistré comme une simple mention.

L’onglet Agents d’un projet dont les tâches vont à l’agent standard.

L’onglet Agents l’affiche avec le badge Standard. Personne ne le modifie : son environnement d’agent, son modèle et ses instructions suivent les réglages de l’organisation, relus à chaque démarrage d’une exécution, et son équipement se limite aux skills de documents docx, pptx, xlsx et pdf que le projet peut utiliser au démarrage d’une exécution. Si un admin en désactive un, il disparaît de son équipement au lieu de bloquer l’agent. Sur Automatique, chaque exécution utilise un modèle que la personne qui la démarre peut utiliser ; il peut donc fonctionner avec des modèles différents selon les personnes.

Pour donner au projet un agent propre, choisis Nouvel agent. Dès lors, le projet ne propose plus l’agent standard ; celui déjà mis en place reste assignable jusqu’à ce que tu le supprimes. Sa suppression conserve l’historique de ses tâches, et tant que le projet n’a pas d’agents, la prochaine tâche confiée à l’agent standard le remet en place.

Modifier ou retirer un agent

Utilise le menu de sa ligne pour le modifier ou le supprimer. L’agent standard n’a que Supprimer l'agent. Les changements concernent les prochaines exécutions ; une exécution active conserve sa configuration initiale. La suppression retire les affectations à l’agent mais conserve l’historique des tâches. Elle efface aussi les espaces de travail de tous ses workers avec leurs fichiers, y compris ceux des Membres. Examine le travail en cours et conserve les résultats nécessaires avant de retirer l’agent.

Si la création échoue, lis la cause affichée : un nom déjà utilisé, un accès au projet manquant, un modèle indisponible et un skill invisible sont des problèmes distincts. Une exécution qui échoue définitivement indique en haut de sa tâche ce qui s’est passé et qui peut y remédier ; Quand l’agent ne peut pas terminer détaille les cas. Modifier les instructions ne résout pas ces prérequis.