Trust Levels per Agent Action
Pattern de gouvernance documenté par intodesignsystems.com : graduer la confiance accordée aux agents AI selon le type d'action, pas en mode tout-ou-rien. Exemples : auto-merge OK pour ajouter une test unit, draft-PR seulement pour modifier un composant DS, suggest-only pour toucher aux tokens. GitHub Primer va jusqu'à : agents authorisés à créer des issues uniquement, jamais à merger. Granularité fine évite le piège 'soit tout-AI soit rien'. Implémentation détaillée (voir pattern `per-action-trust-levels`) : auto-merge si tests passent et action safe (typo, story manquante, lint fix), draft-PR si tests passent et action structurante (token modifié, variant ajouté, props ajoutés) avec review humaine attendue, suggest-only si action critique (composant atomique, pattern layout, a11y), l'agent ne peut que proposer un commentaire sur une PR existante. Le même raisonnement vaut hors du code : un agent de prospection comme Harvey trouve les entreprises, lit leurs sites et vérifie les adresses sans aucune validation, parce que se tromper là ne coûte rien, et ne demande ton accord qu'au seul endroit irréversible, l'envoi du mail. La confiance se grade par le coût de l'erreur, pas par la difficulté de la tâche.
Forces
- Sort de l'extrême auto-merge / no-AI, politique nuancée, défendable, calibrée
- Compatible avec glass-box-ai : trust-levels haut → décisions surfacées détaillées requises
- Modèle GitHub Primer prouve la viabilité enterprise : agents = issues only, pas merge
Limites
- Demande effort initial de catégorisation : quelles actions AI dans quelles catégories de risque ?
- Outillage 2026 limité : la plupart des CI/CD n'ont pas de granularité native, à coder à la main
Pour qui
- Design system manager qui doit présenter une politique AI à son management ou comité de gouvernance
- Équipe qui scale AI à 20+ devs et veut éviter les deux extrêmes (full-auto vs full-block)