1
Rôle
Question de contrôle
De quoi cet agent est-il responsable ?
Pratique opératoire
Définissez le job en termes opératoires : classer des bugs, rédiger un triage, préparer un sprint ou surveiller un risque.
La vraie question en gestion de projet IA n'est plus "est-ce que l'IA peut aider ?"
Elle peut. Elle peut résumer des réunions, rédiger des tickets, chercher dans la documentation, préparer des updates et repérer du travail bloqué. C'est utile, mais ce n'est pas le vrai sujet de gouvernance.
La vraie question est : que doit-on autoriser l'IA à faire ?
Dès qu'un agent IA peut créer des tâches, modifier des documents, déplacer des cards, déclencher des workflows, appeler des outils MCP, notifier des systèmes externes ou rédiger des messages clients, la gestion de projet devient aussi un problème de contrôle.
Ce guide propose un framework pratique pour accélérer avec des agents IA sans perdre les limites, les validations et les traces.
Assistants IA vs agents IA
Un assistant IA est surtout réactif.
Il :
- répond aux questions ;
- résume du contexte ;
- génère des brouillons ;
- attend des instructions ;
- laisse généralement l'exécution à un humain.
Un agent IA est opérationnel.
Il :
- poursuit un objectif ;
- utilise du contexte projet ;
- appelle des outils ou workflows ;
- peut créer, modifier, assigner, déplacer ou notifier ;
- peut proposer ou exécuter du travail ;
- a besoin de limites, de logs et de gouvernance.
Le risque n'est pas le même. Un mauvais résumé fait perdre du temps. Une mauvaise action modifie la source de vérité.
Les cinq couches de contrôle d'un agent IA
Chaque agent projet devrait être cadré par cinq couches : rôle, périmètre, permissions, approbation et audit trail.
2
Périmètre
Question de contrôle
Ou cet agent peut-il agir ?
Pratique opératoire
Commencez par un projet, board, milestone, type de card, ensemble documentaire, pipeline ou outil connecté.
3
Permissions
Question de contrôle
Quels outils et actions peut-il utiliser ?
Pratique opératoire
Séparez lecture, création, mise à jour, assignation, changement de statut, notification, MCP et actions destructrices.
4
Approbation
Question de contrôle
Quand un humain doit-il décider ?
Pratique opératoire
Mettez des gates sur ownership, engagements, accès, messages externes, documents officiels, coût et batch updates.
5
Audit trail
Question de contrôle
Que peut-on inspecter après coup ?
Pratique opératoire
Loggez initiateur, rôle, scope, instruction, contexte, outil, action proposée ou exécutée, approbation, résultat, coût et erreurs.
1. Rôle
Le rôle répond à la question : à quoi sert cet agent ?
Exemples utiles :
- analyste projet ;
- sprint planner ;
- assistant documentation ;
- reviewer QA ;
- coordinateur delivery ;
- moniteur de risques ;
- rédacteur de release notes ;
- assistant triage backlog.
"Aide le projet" est trop vague. "Analyse les nouveaux bugs, classe leur sévérité, identifie les informations manquantes et rédige un commentaire de triage" est opérationnel.
2. Périmètre
Le périmètre répond à la question : où peut-il agir ?
Périmètres courants :
- workspace ;
- projet ;
- scope ou milestone ;
- card ou issue ;
- document ;
- pipeline ;
- inbox d'équipe ;
- outil externe connecté.
Commencez étroit. Un agent limité à un projet ou un type de document est beaucoup plus facile à revoir qu'un agent qui agit partout.
3. Permissions
Les permissions répondent à la question : quels outils peut-il utiliser ?
Séparez :
- lecture seule ;
- création ;
- mise à jour ;
- assignation ;
- changement de statut ;
- notification ;
- communication externe ;
- outils MCP ou plugins ;
- actions destructrices.
Toutes les écritures ne se valent pas. Modifier une checklist interne n'a pas le même risque qu'envoyer un message client ou supprimer une tâche.
4. Approbation
L'approbation répond à la question : quand un humain doit-il valider ?
Actions qui demandent souvent validation :
- changement de statut sur du travail critique ;
- changement d'owner ;
- notification externe ;
- message client ou leadership ;
- modification d'un document officiel ;
- action irréversible ou destructrice ;
- appel outil coûteux ;
- batch update large ;
- changement qui donne accès à d'autres personnes ou systèmes.
L'approbation ne ralentit pas l'agent. Elle conserve la responsabilité au bon endroit.
5. Audit trail
L'audit trail répond à la question : que peut-on relire après coup ?
Un audit trail utile inclut :
- qui ou quoi a déclenché le run ;
- le rôle et la configuration de l'agent ;
- le périmètre projet ou objet ;
- l'instruction ;
- le contexte accessible ;
- l'action proposée ou exécutée ;
- l'outil utilisé ;
- input et output ;
- statut d'approbation et approver ;
- timestamp ;
- résultat ;
- coût ;
- échecs et retries.
Sans trace, l'équipe ne peut ni corriger, ni auditer, ni construire la confiance.
Un modèle d'autonomie pratique
L'autonomie doit progresser par niveaux — c'est aussi vrai pour un scrum master IA que pour un agent de rédaction.
Échelle d'autonomie
Augmentez les permissions un niveau à la fois
Utilisez le niveau le plus bas capable de faire le travail.
Niveau 001 / 06
Lecture seule
Lire le contexte et répondre sans modifier le système.
- Exemple
- Résumer les blocages d'un projet.
- Risque
- Faible.
- Contrôles
- Scope limité et sources visibles.
Niveau 102 / 06
Suggestion
Proposer du travail sans exécuter.
- Exemple
- Proposer des cards depuis une réunion.
- Risque
- Faible à moyen.
- Contrôles
- Revue humaine et rationale visible.
Niveau 203 / 06
Préparer l'action
Rédiger les changements exacts qu'un humain applique.
- Exemple
- Préparer un sprint plan avec assignées proposés.
- Risque
- Moyen.
- Contrôles
- Vue diff ou proposal et owner review.
Niveau 304 / 06
Agir avec approbation
Exécuter certains changements après validation explicite.
- Exemple
- Déplacer des cards bloquées après approval du lead.
- Risque
- Moyen à élevé.
- Contrôles
- Approval gate, audit trail et rollback.
Niveau 405 / 06
Autonomie bornée
Exécuter des actions faible risque dans un scope étroit.
- Exemple
- Mettre à jour une checklist interne ou un label stale.
- Risque
- Moyen.
- Contrôles
- Permissions strictes, monitoring et alertes d'exception.
Niveau 506 / 06
Workflow multi-agent avec gates
Coordonner plusieurs agents et outils dans un workflow gouverné.
- Exemple
- Draft QA, review, approval, puis notification équipe.
- Risque
- Élevé.
- Contrôles
- Gates pipeline, historique, owner et coûts.
La bonne question n'est pas "jusqu'où peut-on autonomiser ?" mais "quel niveau d'autonomie convient à cette action, dans ce périmètre, avec ce risque ?"
Où les agents IA créent de la valeur
Les agents sont utiles quand ils enlèvent de la coordination sans retirer le jugement humain.
Transformer des notes de réunion en cards
- Contexte requis
- Transcript, objectifs projet, backlog, owners et templates.
- Limite
- Ne pas créer de travail prioritaire ou assigner d'owners sans validation, sauf scope très étroit.
- Preuve
- Notes sources, items extraits, cards proposées ou créées et décision du reviewer.
Détecter le travail bloqué
- Contexte requis
- Board, statuts, commentaires, dépendances, dates et activité owner.
- Limite
- Ne pas déplacer ou escalader sans validation.
- Preuve
- Raison du blocage, preuves utilisées et action suggeree.
Rédiger des updates projet
- Contexte requis
- État courant, décisions récentes, travail terminé, risques et prochaines milestones.
- Limite
- Ne pas envoyer l'update a des clients ou dirigeants sans review.
- Preuve
- Objets sources, brouillon, edits, approver et statut d'envoi.
Préparer un sprint planning
- Contexte requis
- Backlog, estimations, capacité, dépendances, carry-over, priorités produit et contraintes.
- Limite
- Ne pas committer le sprint ou changer les dates sans approbation.
- Preuve
- Scope proposé, travail exclu, hypothèses et résultat d'approbation.
Relier documents et tâches
- Contexte requis
- Docs projet, descriptions de cards, titres de documents et décisions.
- Limite
- Suggérer les liens automatiquement, mais revoir les références officielles.
- Preuve
- Documents liés, justification et changement éventuel de statut document.
Préparer des checklists QA
- Contexte requis
- Critères d'acceptation, notes d'implémentation, changements récents et standards qualité.
- Limite
- Ne pas approuver le travail a la place du reviewer.
- Preuve
- Items générés, critères sources et edits du reviewer.
Identifier des tâches obsolètes
- Contexte requis
- Dernière activité, statut, owner, due date, dépendances et priorité.
- Limite
- Labelliser du stale work faible risque ; demander validation avant fermeture ou suppression.
- Preuve
- Critères stale, tâches concernées et follow-up.
Suggérer des changements roadmap
- Contexte requis
- Objectifs produit, feedbacks clients, dépendances, effort et signaux delivery.
- Limite
- Ne pas changer des engagements roadmap sans approbation.
- Preuve
- Preuves, arbitrages, changements proposés et décision owner.
Coordonner des handoffs
- Contexte requis
- Stage workflow, owner actuel, prochain owner, checklist et artifacts requis.
- Limite
- Notification interne possible si risque faible ; communication externe revue.
- Preuve
- Déclencheur de handoff, destinataire, message et résultat.
Générer des résumés leadership
- Contexte requis
- État portefeuille, risques, décisions, blocages et métriques clés.
- Limite
- Ne pas masquer les hypothèses ou gonfler la confiance.
- Preuve
- Sources, informations exclues, hypothèses et reviewer final.
MCP et permissions outils
MCP et l'accès outils changent le niveau de risque. Un agent connecté à des outils ne produit plus seulement du texte : il peut lire, écrire, déclencher et connecter des systèmes.
Matrice de permissions outils
Séparez lecture, écriture, externe et destructif
Lecture
Lire cards, docs et statut projet.
Exposition de données ou contexte obsolète.
Souvent non, mais scope limite.
Brouillon
Préparer changements, documents ou checklists.
Mauvaise recommandation.
Revue avant application.
Écriture interne
Créer une card, mettre à jour un champ, ajouter un commentaire.
Mauvais état système ou bruit.
Selon scope et impact.
Workflow
Déclencher pipeline, retry run, ouvrir une review gate.
Processus inattendu.
Souvent oui pour les flux a risque moyen.
Communication externe
Slack, email, update client.
Risque réputationnel ou contractuel.
Oui, sauf cas faible risque preapprouve.
Accès
Inviter, donner permission, ajouter un collaborateur.
Exposition de données.
Oui.
Destructif
Supprimer, archiver, retirer, écraser.
Perte de données ou de travail.
Oui, et souvent interdit.
Coûteux
Long run, gros appel modèle, API externe.
Dépense inutile.
Approbation par seuil.
Le meilleur setup MCP n'est pas celui qui expose le plus d'outils. C'est celui où chaque outil a un but, un owner, un niveau de permission et un chemin de review.
Human-in-the-loop
Human-in-the-loop ne veut pas dire tout ralentir. Cela signifie placer les validations aux endroits où le jugement, la confiance ou le risque sont élevés.
Exemples :
- l'agent rédige un sprint plan, le PM approuve ;
- l'agent suggère de déplacer des cards bloquées, le lead confirme ;
- l'agent écrit un update client, un humain valide ;
- l'agent met à jour une checklist interne, il peut agir seul ;
- l'agent prépare des release notes, le product owner édite et publie.
La règle : laissez les agents collecter le contexte et préparer des options. Mettez des gates sur les engagements, accès, communications externes et documents officiels.
Audit trails : quoi logger et pourquoi
L'auditabilité sert à la confiance, au debugging, à la responsabilité, au contrôle des coûts, à l'amélioration des agents et à la revue d'incident.
Checklist :
- Qui a lancé l'action ?
- Quel rôle et mode d'autonomie ?
- Quel contexte l'agent a-t-il vu ?
- Quels outils ont été utilisés ?
- Qu'est-ce qui a changé ?
- Qui a approuvé ?
- Qu'est-ce qui a échoué ?
- Combien cela a-t-il coûté ?
- Que faut-il améliorer ?
Avec de bons logs, l'équipe peut savoir si le rôle était trop large, le contexte obsolète, l'outil trop puissant ou l'approbation mal placée.
Erreurs fréquentes
Les rollouts ratés viennent souvent d'un mauvais design opératoire :
- trop d'accès trop tôt ;
- confusion entre suggestion et exécution ;
- communication externe sans approval ;
- pas d'owner humain ;
- audit trail insuffisant ;
- docs obsolètes ;
- contexte incomplet ;
- automations et agents qui se chevauchent ;
- pas de rollback ;
- coûts invisibles ;
- instructions agents non revues.
La réponse n'est pas forcément "moins d'IA". C'est souvent : scope plus étroit, meilleur contexte, gates mieux placées, logs relus.
Plan de déploiement en 30 jours
Déploiement 30 jours
N'étendez qu'après preuve visible
Semaine 1
Lecture seule et résumés
Donner un scope étroit et obtenir des résumés de statut, blocages, stale work et trous documentaires.
Cas sûrs
- Resume projet hebdo
- Digest blockers
- Rapport stale tasks
- Analyse des trous documentaires
Contrôles
- Read-only
- Pas de messages externes
- Pas d'écriture
- Sources requises
Signal de succès
Les résumés sont justes, le contexte manquant est visible et l'équipe sait quels docs ou champs nettoyer.
Semaine 2
Suggestions et brouillons
Préparer des proposals concrètes sans les exécuter.
Cas sûrs
- Cards depuis notes de réunion
- Sprint proposal
- QA checklist draft
- Owners suggérés
Contrôles
- Proposal-only
- Reviewer assigne
- Rationale requis
- Pas de batch apply
Signal de succès
Les humains acceptent ou editent une part utile des suggestions, et aucune modification cachee n'a lieu.
Semaine 3
Actions avec approbation
Exécuter certaines actions après validation humaine.
Cas sûrs
- Créer des cards approuvees
- Mettre a jour des champs approuvés
- Déplacer du travail confirme
- Attacher des docs revus
Contrôles
- Approval gate
- Diff visible
- Audit trail
- Rollback
- Owner pour chaque run
Signal de succès
Les actions approuvees s exécutent correctement et les logs sont assez utiles pour la review.
Semaine 4
Autonomie bornée et revue d'audit
Autoriser des actions faible risque lorsque le scope et la policy sont clairs.
Cas sûrs
- Label stale
- Checklist interne
- Résumés récurrents
- Draft status update
- Notification interne prévisible
Contrôles
- Scope limite
- Tools allowlistes
- Limites budget
- Revue quotidienne ou hebdo
- Alerte sur volume inattendu
Signal de succès
L'agent economise du temps de coordination, les humains inspectent les changements et le prochain niveau d'autonomie est clair.
Checklist de gouvernance
Avant de laisser un agent toucher du travail live, vérifiez :
Checklist avant mise en live
À confirmer avant qu'un agent touche le projet
- Rôle défini
- Périmètre défini
- Owner assigne
- Permissions revues
- Outils read et write séparés
- Outils externes revus
- Règles d'approbation configurees
- Audit trail active
- Fallback défini
- Rollback connu
- Visibilité coût disponible
- Cadence de revue planifiée
- Chemin d'escalade documente
- Sources documentaires revues
Comment Stellary aborde ce sujet
Stellary est conçu autour d'agents IA gouvernés qui travaillent dans le même système que les projets, documents, cards, missions, pipelines, approbations et cockpit.
Les agents sont des acteurs opérationnels du workspace. Ils peuvent avoir rôles, modes d'autonomie, outils autorisés, skills, règles, mémoire, affectation projet, historique de missions, proposals, validations, traces et visibilité des coûts.
Cela ne remplace pas le jugement. Cela donne un endroit clair pour l'appliquer.
FAQ
Qu'est-ce que la gouvernance des agents IA en gestion de projet ?
C'est l'ensemble des rôles, périmètres, permissions, règles d'approbation, logs, owners et revues qui contrôlent comment les agents travaillent dans le système projet.
Faut-il autoriser les agents IA à déplacer des tâches automatiquement ?
Parfois, mais seulement dans des cas bornés. Déplacer une tâche interne faible risque peut être acceptable. Modifier un engagement, un statut critique ou un owner doit généralement demander approbation.
Quelles actions doivent demander validation humaine ?
Communication externe, actions irréversibles, changements d'accès, documents officiels, updates clients, batch changes, usages coûteux et tout changement d'engagement ou de responsabilité.
Quelle différence entre automatisation et agent IA ?
Une automatisation suit une règle prédéfinie. Un agent interprète le contexte, applique du jugement, utilise des outils et choisit parfois l'action pertinente.
Pourquoi l'auditabilité compte-t-elle ?
Elle permet de comprendre ce que l'agent a fait, pourquoi, avec quel contexte, quel outil, quelle approbation, quel résultat et quel coût.
Comment MCP change-t-il les permissions ?
MCP donne aux agents un accès structuré à des outils et données. Cela augmente l'utilité, mais impose de séparer outils de lecture, écriture, communication externe et actions destructrices.
Comment commencer prudemment ?
Commencez en lecture seule sur un scope étroit. Passez aux suggestions. Ajoutez ensuite des actions avec approbation. N'autorisez l'autonomie bornée qu'après avoir confiance dans les logs.
Sources et lectures liées
Sources officielles revues : Asana AI Teammates, ClickUp Super Agents et audit logs, Notion Agent et MCP, monday.com AI Agents, Linear Agents et MCP, Atlassian Rovo Studio, Wrike AI Agents, Taskade AI Agents et Motion AI Workflows.
Lectures Stellary :
- Top 10 des outils de gestion de projet IA en 2026 pour équipes agentiques
- Gestion de projet avec des agents IA
- Documentation et mémoire IA
- Ce que MCP change pour les outils de code IA en 2026
- Connecter des agents IA à Stellary via MCP
- Stellary
Conclusion
Le futur de la gestion de projet n'est pas l'autonomie aveugle.
C'est la délégation gouvernée.
Les équipes qui réussiront avec les agents IA ne seront pas celles qui laissent tout faire aux agents. Ce seront celles qui savent quoi déléguer, quoi relire, quoi logger et quand augmenter l'autonomie.
Le but n'est pas de perdre le contrôle. Le but est de le rendre assez explicite pour que humains et agents travaillent plus vite dans le même système de vérité.