Agents IA
Vue d'ensemble
Un agent IA (agent d'intelligence artificielle : un travailleur logiciel automatisé piloté par un grand modèle de langage) est traité comme un acteur de première classe dans Vaks PM, au même titre que les utilisateurs humains. Un agent peut se voir confier du travail, réclamer des tâches, produire des livrables et déclarer son coût — mais il est gouverné bien plus strictement qu'une personne.
La boucle de travail
Les agents suivent un modèle en « pull » (tirer) plutôt qu'en poussée : un agent se connecte au serveur MCP de l'organisation avec son jeton, puis traite une tâche selon un cycle de vie appliqué côté serveur — la machine à états n'existe que sur le serveur, et un mauvais ordre est refusé plutôt que suivi. Le schéma ci-dessous montre ce cycle de bout en bout.
Deux façons d'entrer dans la boucle
Une tâche peut arriver à un agent de deux manières, qui n'appliquent pas les mêmes filtres. En découverte autonome (entrée A), l'agent demande sa prochaine tâche et le serveur ne lui propose que des tâches éligibles : un projet ouvert aux agents dont il est membre, les prérequis satisfaits, et surtout les compétences requises couvertes par l'agent au niveau demandé. À l'inverse, quand un humain assigne directement une tâche précise (entrée B), l'agent la voit dans sa liste et peut la réclamer telle quelle — sans le filtre de compétences : c'est alors la personne qui assigne qui porte la responsabilité de l'adéquation. Dans les deux cas, la réclamation reste atomique et soumise aux mêmes garde-fous (projet ouvert aux agents, budgets, allowlist de modèles du client) ; l'assignation ne réclame jamais la tâche à la place de l'agent — elle ne fait que la rendre visible.
Le cycle de vie, étape par étape
| Étape | Ce qui se passe |
|---|---|
| Réclamer | L'agent demande la prochaine tâche éligible et la réclame de façon atomique — deux agents ne peuvent jamais détenir la même tâche. La réclamation est refusée si un budget ou une policy (voir plus bas) l'interdit. |
| Travailler | L'agent lit un contexte de travail consolidé (le brief du projet, les garde-fous, les critères d'acceptation de la tâche, et un journal vivant des résultats déjà approuvés) et effectue le travail. |
| Livrer | L'agent soumet un ou plusieurs livrables — un lien, un fichier téléversé, ou du contenu Markdown stocké dans le magasin d'objets — chacun avec une justification en langage naturel. |
| Réviser | Un réviseur humain (jamais l'auteur du livrable) approuve ou demande des changements. Une demande de changements renvoie la tâche ; l'agent peut resoumettre une nouvelle version qui remplace la précédente. |
| Clôturer | À l'approbation, la tâche progresse et, si le projet l'a choisi, se clôture automatiquement. Les critères d'acceptation sont cochés et une entrée est ajoutée au journal vivant. |
Les statuts de tâche concernés sont À faire → Réclamée → En cours → En revue → Approuvée → Terminée, plus Changements demandés. Le journal vivant est alimenté uniquement par les livrables approuvés, de sorte qu'une production non révisée ne peut jamais contaminer le contexte futur d'un agent.
Identités & provisioning
Un agent est une identité dédiée (ce n'est pas un identifiant partagé ni un compte humain). Il porte un nom d'affichage, un e-mail interne synthétique de la forme agent-<nom>@agents.invalid, un propriétaire obligatoire, un niveau de confiance, un ensemble de capacités (voir plus bas) et un profil optionnel de modèle/coût. Les agents sont créés de trois manières :
Manuel (admin)
Un administrateur crée l'agent directement sous espace admin → Utilisateurs & Identité → Agents, définit son propriétaire et ses capacités, et génère son jeton d'accès.
Synchronisation d'annuaire
Un connecteur importe des identités d'agents depuis un annuaire d'agents externe (Microsoft Entra Agent ID d'abord) sous Intégrations → Annuaires d'agents, avec un test de connexion et un Synchroniser maintenant manuel. Les secrets sont chiffrés au repos.
Enregistrement entrant
Une plateforme sans connecteur peut auto-enregistrer un agent en appelant POST /agents avec une clé API d'organisation. L'agent arrive en lecture seule, à l'état brouillon, sans jeton, et reste inerte tant qu'un humain ne l'a pas activé.
Chaque agent s'authentifie avec son propre PAT (Personal Access Token, jeton d'accès personnel), distinct de tout jeton utilisateur, avec une expiration obligatoire (90 jours par défaut, 2 ans maximum) et affiché une seule fois à la création. Le provisioning exige toujours un propriétaire : un connecteur d'annuaire qui ne peut pas en fournir un retombe sur un propriétaire par défaut configuré. Les agents sont uniquement suspendus, jamais supprimés silencieusement.
Obtenir un jeton sans secret à distribuer Inclus
Émettre un PAT manuellement reste la voie par défaut et fonctionne toujours ; elle devient lourde au-delà de quelques dizaines d'agents, chacun avec un secret à distribuer et à faire tourner. Deux mécanismes s'y ajoutent pour éliminer ce fardeau, sous la licence agents :
| Mécanisme | Pour quel agent | Principe |
|---|---|---|
| Fédération d'identité (RFC 8693, échange de jeton) | Un agent qui tourne sur une plateforme dotée de sa propre identité : un pod Kubernetes (jeton de ServiceAccount), un service principal Entra (jeton de charge de travail), un job GitHub Actions (jeton OIDC). | L'agent présente le jeton que sa plateforme lui a délivré ; Vaks PM le vérifie contre un émetteur de confiance déclaré à l'avance (clés publiques collées ou JWKS, audience obligatoire, liste blanche d'algorithmes) et l'échange contre un PAT Vaks PM de courte durée. Aucun secret n'est jamais distribué ni tourné. |
| Auto-service headless | Un agent sans tissu d'identité autour de lui — une machine, un script, un environnement d'exécution générique. | Un humain émet une fois un identifiant machine rotatif ; l'agent l'échange ensuite lui-même, indéfiniment, contre des jetons de travail courts qui se renouvellent automatiquement. Le vol d'un identifiant déjà consommé (rejeu) est détecté et révoque toute la chaîne. |
Dans les deux cas, un jeton obtenu n'accorde jamais de droits par lui-même : les portes habituelles s'appliquent toujours (propriétaire humain actif, agent non suspendu, capacités déclarées). Le détail des deux mécanismes, plateforme par plateforme, vit dans le guide Authentification des agents.
Ce qu'un agent peut faire — capacités & permissions
Les droits effectifs d'un agent sont l'intersection de trois limites : les permissions RBAC de son rôle, les portées (scopes) de son jeton, et ses capacités déclarées. Une permission doit apparaître dans les trois pour que l'agent puisse l'utiliser. Les capacités sont, par construction, incapables d'accorder les actions les plus sensibles — un agent ne peut jamais obtenir de permissions finance, gestion client, administration ou saisie de temps. De plus, un jeton d'agent n'agit que sur la surface d'API publique : il est rejeté sur l'application d'administration privée, même si le compte sous-jacent est privilégié. Le résultat net est qu'un agent opère dans un sous-ensemble strict de ce qu'un contributeur humain prudent pourrait faire.
Résilience de l'exécution — bail, battements de vie & retour de revue
Une tâche réclamée par un agent est protégée par un bail d'exécution : une fois le travail commencé, l'agent doit envoyer périodiquement un battement de vie (heartbeat) pour signaler qu'il est toujours actif. S'il cesse de répondre — panne, crash, coupure réseau — sans qu'un battement n'arrive avant l'expiration du bail (30 minutes par défaut, réglable de 5 minutes à 24 heures, ou désactivable), la tâche est automatiquement libérée : elle repasse à À faire, la réclamation et l'assignation sont retirées, et le compteur de tentatives est incrémenté — sans qu'un humain n'ait à intervenir pour la débloquer. Ce mécanisme ne s'applique qu'aux agents ; un humain qui ferme son ordinateur portable ne perd jamais sa tâche de cette façon.
Chaque battement de vie renvoie aussi à l'agent ses limites restantes — temps de bail, nombre de tentatives, enveloppes budgétaires — de sorte qu'il connaît ses bornes avant de continuer à produire plutôt que de les découvrir après coup. Et quand une tâche revient avec une demande de changements, le contexte de travail de l'agent inclut désormais le verdict le plus récent : la décision, le texte exact laissé par le réviseur, son nom et la date, ainsi que les versions précédentes du livrable — l'agent n'a plus à deviner ce qu'on lui reproche avant de resoumettre.
Chaîner le travail — sous-tâches, sorties structurées & assistance ciblée
Trois mécanismes évitent à un agent de deviner une valeur, un découpage ou une réponse au lieu de les obtenir du serveur :
Sorties structurées
Un livrable peut porter, en plus de son contenu narratif, une poignée de faits clés (un identifiant, une URL, un numéro de version…) sous forme de paires nom/valeur simples — pas de structure imbriquée, volontairement, pour que ce canal reste des faits et non un fourre-tout documentaire. Une fois le livrable approuvé, ces faits deviennent lisibles par les tâches qui en dépendent directement et par ses sous-tâches, dans leur propre contexte de travail — un agent n'a plus besoin de re-demander une valeur déjà produite en amont. Comme pour le journal vivant, seuls les livrables approuvés alimentent ce canal.
Décomposition bornée
Un agent peut découper la tâche qu'il tient en sous-tâches, mais de façon strictement encadrée : un seul niveau de profondeur, uniquement sous la tâche qu'il a lui-même réclamée et qui est toujours active, sans pouvoir poser de champ de gouvernance sur ce qu'il crée. Une sous-tâche sans plafond propre hérite de l'enveloppe budgétaire de sa tâche parente, et c'est la somme de l'arbre entier (parent et sous-tâches) qui est comparée au plafond — découper une tâche plafonnée ne permet donc pas d'en contourner la limite.
Demande d'assistance
Quand une tâche exige une compétence que l'agent n'a pas, il peut demander de l'aide en un seul geste : un commentaire est ajouté à la tâche à titre de trace, une demande de compétence part automatiquement vers l'équipe du projet qui couvre le besoin (l'agent ne choisit pas qui il sollicite), et la tâche passe en attente avec la question comme motif — elle reste réclamée par l'agent (personne d'autre ne peut la prendre) mais son bail d'exécution s'éteint en attendant une réponse humaine. Trois personnes sont alertées directement : le chef de projet, le propriétaire de l'agent et les co-assignés de la tâche — un appel à l'aide qui ne réveille personne n'en est pas un.
Découper une tâche — ce que la sous-tâche doit porter
Une sous-tâche est un passage de relais : celui qui découpe sait pourquoi il le fait, celui qui reprendra ne le saura pas. Une sous-tâche réduite à un titre est techniquement disponible et pratiquement infaisable. Le produit exige donc, au moment où un agent en crée une, qu'elle porte de quoi travailler sans son auteur :
| Ce qui est exigé | Pourquoi |
|---|---|
| Une description substantielle | Ce qu'il y a à faire, ce qui est déjà connu ou décidé, et à quoi ressemble le résultat attendu. Une sous-tâche sans description est refusée, avec un message qui indique quoi écrire. |
| Une compétence | Reprise de la tâche parente par défaut, et remplaçable si le découpage sert justement à changer de compétence. Sans elle, la file de travail des agents n'a aucun critère de routage : n'importe quel agent du projet pourrait tirer une tâche qu'il ne sait pas faire — alors même que « il me manque une compétence » est le premier motif de découpage. |
| Le contexte de son parent | Transmis automatiquement : l'énoncé de la tâche parente, sa description, ses critères d'acceptation, ses garde-fous et ses résultats déjà approuvés. S'y ajoutent les résultats approuvés des autres sous-tâches du même découpage, qui se répondent entre elles. |
Un agent ne peut pas fixer les critères d'acceptation de ce qu'il crée — c'est une décision humaine, et un agent n'écrit jamais la barre sur laquelle son propre travail sera jugé. C'est le niveau de preuve exigé de la tâche parente, réglé par la gouvernance, qui s'applique à tout le découpage.
Valider un découpage — la remontée de preuve
Quand le travail réel vit dans les sous-tâches, valider la tâche parente sur son seul résumé reviendrait à ignorer ce que ses sous-tâches ont — ou n'ont pas — démontré. Deux règles s'appliquent donc au moment où un agent soumet une tâche parente en revue :
- Le découpage doit être terminé. Tant qu'une sous-tâche est ouverte, la tâche parente ne part pas en revue : on ne met pas dans la file d'un réviseur un travail dont on sait qu'il est incomplet.
- La tâche parente vaut son maillon le plus faible. Chaque sous-tâche doit avoir un livrable approuvé, et au niveau de preuve exigé de la tâche parente. Une seule sous-tâche restée en dessous invalide l'ensemble — sinon il suffirait de noyer une pièce faible parmi des pièces solides.
La tâche parente porte en plus son propre livrable de synthèse. Ce n'est pas une formalité : des sous-tâches validées séparément prouvent que chaque morceau tient, jamais que l'ensemble tient une fois assemblé — c'est le cas classique où chaque test unitaire passe et où l'intégration casse. La synthèse est ce qui prouve le tout.
Avant de tenter la soumission, un agent peut consulter l'état de son découpage : ce qui est terminé, ce qui manque encore, et quelles sous-tâches restent sous le niveau de preuve exigé. Il corrige alors plutôt que de se heurter à un refus.
Gouvernance — activation, policies, budgets & vérification
Les agents sont désactivés par défaut et contraints à plusieurs niveaux indépendants :
- Projets ouverts aux agents : un projet doit être explicitement ouvert aux agents et porter un brief écrit avant qu'un agent puisse y réclamer du travail. Les projets non ouverts aux agents ne sont pas affectés.
- Policies : des règles déclaratives, configurées sous Utilisateurs & Identité → Policies agents, sont évaluées à chaque transition d'état. Une règle peut exiger une revue, refuser l'action, ou notifier, selon des conditions telles qu'une étiquette, le niveau de confiance de l'agent, l'estimation de la tâche ou la transition elle-même. Un réglage de backpressure de revue plafonne le nombre d'éléments en attente de revue humaine par projet, pour que les agents ne prennent pas de l'avance sur les réviseurs.
- Budgets : des plafonds de coût dans la devise de l'organisation sont appliqués au moment de la réclamation, et en continu pendant l'exécution — par agent (jour et mois), par projet, et par tâche. Dépasser un plafond refuse la réclamation avec un motif clair plutôt que de dépenser silencieusement au-delà ; côté exécution, la déclaration de coût d'un agent en cours de travail est elle-même un point de contrôle, de sorte qu'un agent en boucle est arrêté (avec alerte à son propriétaire) dès que son enveloppe est atteinte plutôt qu'après coup. Un réglage optionnel de coupe-circuit va plus loin et retire en plus la tâche à l'agent au moment du dépassement, au prix de perdre le travail en cours.
- Vérification des livrables : chaque livrable est évalué par une porte déterministe qui classe la force de la preuve qui le soutient. Le sujet est détaillé dans la section suivante.
Vérification des livrables & preuve d'intégration continue
Quand un agent annonce « c'est fait, mes tests passent », rien n'oblige à le croire sur parole. Vaks PM classe chaque livrable selon la force de la preuve qui le soutient, sur une échelle allant de la simple déclaration de l'agent à la revue humaine :
| Méthode | Ce qu'elle vaut |
|---|---|
| Auto-attestation | L'agent déclare lui-même que son travail est bon. La plus faible : rien ne la corrobore. |
| Sortie d'outil | L'agent joint les journaux et le code de sortie de ce qu'il a exécuté. Plus solide, mais c'est toujours lui qui rapporte. |
| Validation par un agent | Un autre agent, jamais l'auteur, contre-vérifie le livrable et rend son verdict. |
| Preuve d'intégration continue signée | La chaîne d'intégration continue (CI) du client atteste elle-même du résultat, avec une signature que l'agent ne peut pas fabriquer. |
| Revue humaine | La plus forte, et le recours universel : une personne tranche. |
La méthode exigée pour un livrable donné n'est pas choisie par l'agent : elle est dérivée de l'enjeu de la tâche croisé avec le niveau de confiance de l'agent. Une tâche à faible enjeu confiée à un agent éprouvé se contente d'une auto-attestation ; une tâche critique exige une revue humaine quel que soit l'agent. Si le terrain ne permet pas de produire la méthode requise — un dépôt sans CI, par exemple — l'exigence retombe sur la revue humaine. Il n'y a jamais de blocage sans issue.
La preuve d'intégration continue, concrètement
C'est le seul niveau de preuve mécanique qu'un agent ne peut pas fabriquer, et il repose sur un principe simple : Vaks PM ne se connecte jamais à votre chaîne d'intégration continue. Il n'a aucun accès sortant, ne détient aucun identifiant chez votre hébergeur de code, et n'interroge rien. C'est votre CI qui pousse son résultat vers Vaks PM, et la seule chose que le serveur fait activement est de vérifier une signature calculée avec un secret partagé convenu à l'avance.
Le rapprochement entre un résultat de CI et une tâche se fait par le SHA du commit — l'empreinte unique d'un enregistrement dans le dépôt de code. Votre CI ne connaît ni vos projets ni vos tâches : elle dit seulement « le commit abc123 a fini, verdict succès ». De son côté, l'agent, qui sait sur quelle tâche il travaille, déclare le SHA du commit qu'il a produit en soumettant son livrable. Vaks PM apparie les deux. Les deux flux arrivent dans n'importe quel ordre — la CI signe souvent avant que l'agent n'ait fini de rédiger son livrable — c'est pourquoi les résultats reçus sont conservés 24 heures en attente d'appariement.
Un connecteur de CI se configure sous Intégrations → Vérification CI, à raison d'un par organisation et par outil. Le secret partagé y est saisi une fois et chiffré au repos ; l'interface ne le réaffiche jamais. Deux formats sont pris en charge :
GitHub Actions
Vaks PM parle nativement le format des webhooks GitHub. Côté dépôt, il suffit d'ajouter un webhook pointant vers l'adresse indiquée par le connecteur, d'y coller le secret partagé, et de s'abonner aux exécutions de workflow. Aucun développement.
CI générique
Pour GitLab CI, Jenkins, Azure DevOps ou une chaîne maison, Vaks PM définit un contrat minimal : le SHA du commit et le verdict, signés dans un en-tête. Une étape en fin de pipeline suffit à le poster.
Chaque résultat reçu est consigné dans le journal d'audit, tout comme les rejets : une signature invalide est traitée comme une tentative de falsification, pas comme une erreur bénigne. Le connecteur affiche le diagnostic du dernier événement reçu, ce qui permet de vérifier un branchement sans fouiller les journaux. La procédure complète vit dans le guide Vérification CI.
Observation seule ou application stricte
La porte de vérification tourne par défaut en observation seule : elle mesure la force de la preuve fournie face à ce qui était exigé, journalise l'écart, mais ne bloque ni n'approuve rien de sa propre autorité. C'est délibéré — cela permet de collecter des données de calibration réelles avant de serrer. Un projet peut ensuite basculer en application stricte, où une preuve insuffisante escalade au lieu de passer. Le réglage se fait par projet, dans l'onglet IA de ses paramètres, et un projet qui ne tranche pas hérite du défaut de l'organisation : on peut ainsi serrer sur un projet outillé tout en restant en observation partout ailleurs.
Coût & facturation
Un agent n'a pas de feuille de temps ; sa consommation se mesure en usage du modèle, pas en heures. Après avoir travaillé, un agent déclare le coût réel de chaque exécution (le nombre de jetons — tokens — d'entrée et de sortie, un token étant l'unité dans laquelle les modèles de langage comptent le texte). Le coût interne est dérivé de taux configurables par 1000 tokens d'entrée et de sortie, et le montant facturé à un client, le cas échéant, d'un taux de vente distinct par 1000 tokens. Ces chiffres alimentent la vue de résultat (profit & perte) du projet, les rapports projet et portefeuille, et les exports CSV, tableur et PDF, de sorte que le coût et le revenu des agents apparaissent aux côtés du travail humain.
Gérer les agents — espaces admin & le rôle « Administrateur IA »
Trois espaces d'administration couvrent le quotidien : Agents (identités, propriétaires, confiance, capacités et jetons, sous Utilisateurs & Identité), Annuaires d'agents (connecteurs externes, sous Intégrations), et Policies agents (règles de gouvernance et backpressure, sous Utilisateurs & Identité). Par défaut, ces espaces exigent des droits d'administrateur complets.
Pour les organisations qui veulent déléguer la gestion des agents sans distribuer l'administration complète, un octroi « Administrateur IA » est disponible. Ce n'est pas un rôle distinct — l'utilisateur conserve son rôle d'organisation existant — mais un octroi orthogonal et cumulable qui ajoute la seule permission « gérer les agents » par-dessus le rôle que la personne détient déjà (par exemple un chef d'équipe ou un simple membre). Un administrateur l'active sur le profil d'un utilisateur (sous Utilisateurs & Identité → Utilisateurs). Un utilisateur qui ne détient que cet octroi atteint l'espace d'administration en mode restreint : les trois espaces d'agents ci-dessus sont visibles et utilisables, et rien d'autre — pas de réglages, pas de gestion des membres, pas de journal d'audit.
État initial & activation
À partir d'une installation vierge, activer les agents de bout en bout comporte les étapes suivantes :
- Créer une identité d'agent et lui affecter un propriétaire humain (Utilisateurs & Identité → Agents), ou connecter un annuaire d'agents pour en importer une.
- Définir ses capacités au minimum requis par le travail, et générer son jeton d'accès (le noter — il n'est affiché qu'une fois).
- Ouvrir un projet aux agents et lui donner un brief ; définir éventuellement des budgets de projet et de tâche.
- Configurer les policies (exiger une revue, backpressure) selon l'appétence au risque de l'organisation.
- Donner à l'agent l'accès via le connecteur IA. Comme les agents agissent par MCP, le connecteur doit être activé (il est inclus, gratuit) ; les actions d'écriture des agents requièrent en plus la bascule d'écriture du connecteur. Au-delà de 5 agents, une licence
agentsest nécessaire. Voir connecteur IA (MCP).