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.
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)