Identifier les responsabilités, les risques, les anti-modèles et les besoins de traçabilité
À mesure que les agents deviennent plus capables, il peut être tentant d’imaginer que la responsabilité passe au système. Ce n’est pas le cas. Les systèmes agentiques peuvent exécuter des travaux, mais les humains restent responsables des résultats et des contrôles qui régissent l’exécution.
Dans cette unité, vous allez apprendre
Qui est responsable des actions et des résultats de l’agent
Quels sont les risques courants et les anti-modèles qui apparaissent dans les systèmes d’agent
Comment GitHub contrôles atténuent ces risques
Pourquoi la traçabilité et l’observabilité sont requises pour les systèmes dignes de confiance
La responsabilité ne se déplace pas avec l’exécution
Lorsqu’un agent crée une demande de fusion, modifie le code ou répond aux commentaires, il participe au flux de travail, mais n'assume pas la responsabilité des résultats. Les parties responsables sont toujours les personnes et les équipes qui :
Définition de la tâche
Définir des autorisations
Choisir et configurer des contrôles
Approbation de la modification résultante
Un modèle de révision des demandes de tirage rend cela explicite : le système peut proposer, mais les humains décident de ce qui est accepté.
Risques courants et anti-modèles
Les systèmes d’agent de première phase échouent généralement de manière prévisible :
Exécution sans plan L’agent commence à modifier le code sans approche claire et inspectable.
Les agents avec trop d'autorisations L'agent (ou son jeton d'authentification/credentials d'outil de workflow) dispose d'un accès plus large que nécessaire.
Le raisonnement masqué Le flux de travail expose uniquement les sorties (les différences) sans artefacts intermédiaires (plan, hypothèses, points de décision, contexte d’exécution).
Confiance aveugle dans l’automatisation Le passage des tests CI est important, mais ces contrôles ne valident que ce pour quoi ils sont conçus. Une build de passage ne signifie pas automatiquement que la modification est terminée, appropriée ou à faible risque.
Mappage de l’implémentation : atténuation des risques → GitHub
| Risque / anti-modèle | À quoi cela ressemble dans GitHub | Atténuation avec les contrôles GitHub |
|---|---|---|
| Exécution sans plan | La demande de tirage a une différence, mais aucun plan ni raison | Exiger une section de planification via un modèle de demande de pull ; révision obligatoire avant fusion |
| Agents sur-autorisés | Les flux de travail peuvent écrire dans le référentiel, accéder aux secrets à grande échelle | GITHUB_TOKEN de moindre privilège ; environnements avec réviseurs requis ; restreindre les personnes pouvant déclencher des workflows |
| Raisonnement masqué | Aucune hypothèse/étendue/trace de décision | Exiger un plan et lier des exécutions de processus de travail et enregistrer des décisions dans les commentaires de pull request |
| Confiance aveugle dans l’automatisation | « CI passé, expédier l’état d’esprit » | Combiner des vérifications avec CODEOWNERS, des révisions requises et des approbations basées sur les risques |
Traçabilité et observabilité
Pour bien superviser un agent, vous avez besoin de plus qu'une comparaison finale - vous avez besoin d'une trace. Dans GitHub, cette piste peut inclure :
Pull requests et historique des commits
Passer en revue les commentaires et les approbations
Exécutions de workflow et artefacts téléchargés (rapports de test, logs)
Chargements et alertes d’analyse du code
Alertes d’analyse des secrets et événements de protection Push
Événements du journal d’audit de l’organisation (la disponibilité et l’accès dépendent de la configuration de l’organisation/entreprise)
L’objectif n’est pas seulement la conformité. Il s’agit d’une compréhension opérationnelle : quand quelque chose échoue, vous devez savoir ce qui a changé, qui l’a approuvé, quelle preuve existait et ce qui s’est passé ensuite.
Piste d’audit minimale pour les contributions de l’agent
Un objectif indiqué (lien vers le problème ou description de la pull request)
Un plan inspectable (section ou fichier de plan de demande de tirage)
Ensemble de modifications limité (branche et commits)
Preuve automatisée (exécution de flux de travail et artéfacts)
Jugement humain (examen et approbation)
Résultat clair (fusion, annulation ou escalade)
Supposons que le correctif de vulnérabilité de l’agent passe CI, mais qu’il provoque ultérieurement une régression. La question clé n’est pas seulement de savoir si l’agent a fait une erreur, c’est si le système a fait l’erreur compréhensible et évitable :
Y a-t-il un plan et une étendue visibles ?
Les réviseurs appropriés ont-ils été demandés (et ont-ils approuvé) ?
Les vérifications correspondent-elles au risque de modification ?
La piste d’audit suffit-elle pour reconstruire ce qui s’est passé ?
Les systèmes agentiques changent qui effectuent du travail, mais pas qui possède les résultats. Les équipes humaines restent responsables, c'est pourquoi elles doivent concevoir en évitant les anti-modèles courants et exiger une traçabilité forte à travers les artefacts et journaux GitHub natifs.
Une fois que vous comprenez le fonctionnement de la responsabilité, la dernière étape consiste à décider comment le travail de l’agent doit être jugé. Dans l’unité suivante, vous allez appliquer le modèle contributeur à la sortie générée par l’agent.