Guide
Comment superviser les agents de code IA sur les postes des développeurs
Que surveiller quand Claude Code, Codex ou Cursor tournent sur les portables de l’équipe, ce que hooks et télémétrie révèlent ou non, et comment respecter la vie privée.
· 9 min de lecture · Par l’équipe vetkit
Pourquoi les approbations ne suffisent pas
Les agents de code IA demandent votre accord avant une action risquée, ou laissent un relecteur automatique trancher. Cela protège le moment de l’approbation. Mais cela ne dit pas à une équipe ce qui s’est passé au fil de centaines de sessions sur des dizaines de portables : quel agent a lu un identifiant cloud, lequel a envoyé des données vers un domaine que personne ne connaît, ou lequel a discrètement modifié ses propres réglages pour que l’exécution suivante demande moins.
La supervision comble ce vide. L’objectif n’est pas de surveiller les développeurs, mais de pouvoir répondre à une question simple quand quelque chose cloche : à quoi l’agent a-t-il touché ? Le guide sur ce à quoi les agents ont accès explique pourquoi cette surface est plus large que la plupart des gens ne le pensent.
Que surveiller
L’essentiel du risque se concentre dans quelques catégories. Un bon outil de supervision couvre chacune d’elles et rattache l’activité à l’agent qui l’a provoquée.
| Catégorie | Exemples | Pourquoi c’est important |
|---|---|---|
| Accès aux identifiants | Clés SSH et GPG, identifiants cloud, jetons, trousseau, données du navigateur | Ce qu’il y a de plus précieux sur un poste de développeur |
| Trafic sortant | Envois de fichiers, services de type pastebin et de partage de fichiers, domaines jamais vus | C’est par là que les données sortent ; la lecture d’un identifiant suivie d’un trafic sortant est la séquence classique |
| Actions destructrices | Suppressions massives, réécriture de l’historique git, suppression de tables, modification de ressources cloud | Les erreurs coûtent cher ici, même sans attaquant |
| Périmètre | Lectures, recherches et écritures hors du projet | Une tâche de code a rarement besoin du reste du disque |
| Chaîne d’approvisionnement | Installations de paquets, script distant redirigé vers un shell, lancement de serveurs MCP | Du nouveau code arrive et s’exécute avec vos droits |
| Persistance et posture | Éléments d’ouverture de session, profils de shell, réglages et fichiers d’instructions des agents, modes de contournement des approbations | Des changements qui survivent à la session et façonnent la suivante |
Ce que les outils fournissent nativement
Les agents eux-mêmes exposent des hooks et une télémétrie utiles. C’est un bon point de départ, avec des limites nettes.
- Hooks. Claude Code, Codex et Cursor peuvent exécuter votre propre script avant ou après un appel d’outil, par exemple avant une commande shell ou un appel MCP. Claude Code et Cursor indiquent que les hooks laissent passer par défaut en cas de timeout ou d’erreur (fail open), et Claude Code recommande le système de permissions plutôt que les hooks pour les règles strictes d’autorisation ou d’interdiction.
- OpenTelemetry. Claude Code et Codex peuvent exporter les décisions et résultats des outils via OpenTelemetry. C’est désactivé par défaut, les prompts ne sont pas journalisés sauf si vous l’activez explicitement, et aucun des deux outils ne laisse la configuration propre d’un dépôt activer la télémétrie ou choisir sa destination.
- Ce qu’ils ne voient pas. Les signaux natifs décrivent ce que l’agent a demandé à ses outils. Une commande shell qui lance d’autres processus, un script exécuté pendant l’installation d’une dépendance ou un conteneur lancé par l’agent échappent à cette vue, et chaque outil produit ses rapports dans son propre format.
Trois façons de superviser
| Approche | Points forts | Limites |
|---|---|---|
| Hooks et télémétrie des agents | Appels d’outils exacts, mise en route peu coûteuse, pris en charge par l’éditeur | Une configuration par outil, fail open, aveugles aux processus enfants, dépendants de la configuration de chaque développeur |
| Sécurité des terminaux (EDR) | Voit chaque processus et chaque connexion sur la machine | Ne sait pas quelle activité provient d’une session d’agent, et ses règles sont écrites pour les logiciels malveillants, pas pour un assistant de code très actif |
| Un outil dédié à la supervision des agents | Rattache l’activité du système d’exploitation à l’agent et à la session, une vue unique pour tous les outils, des règles écrites pour le comportement des agents | Une application de plus à installer ; il faut un modèle de confidentialité clair pour qu’une équipe l’accepte |
Ces approches se combinent bien. Les hooks donnent l’intention précise, un outil dédié apporte la couverture et l’attribution, et l’EDR reste le filet de sécurité pour tout le reste de la machine.
Raisonner en sessions, pas en événements
Une lecture de fichier isolée est rarement intéressante. Une session qui a lu un identifiant cloud puis envoyé quelque chose vers un domaine jamais vu, si. Deux idées rendent la supervision utile plutôt que bruyante :
- Regrouper par session et par règle. Un même comportement répété doit incrémenter un compteur, pas créer une nouvelle alerte à chaque fois.
- Affirmer ce qui ne s’est pas produit, honnêtement. Le résultat le plus rassurant d’un outil de supervision est une affirmation comme « aucune lecture hors du projet » ou « trafic sortant uniquement vers les domaines autorisés ». Une telle affirmation ne vaut que ce que vaut la couverture des capteurs qui la sous-tend ; elle doit donc signaler quand cette couverture était partielle, par exemple après un redémarrage du capteur ou quand l’agent a délégué du travail à Docker ou à SSH.
Superviser sans surveiller les personnes
Observer ce qu’un outil fait sur le portable de quelqu’un s’apparente à la surveillance des salariés, et doit être conçu en conséquence :
- L’appairage d’un appareil doit être une action explicite de la personne, sur sa propre machine.
- Envoyer des métadonnées (alertes, résumés de session), pas le contenu des fichiers, les prompts ou les frappes clavier.
- Masquer les secrets sur l’appareil avant que quoi que ce soit n’en sorte.
- Permettre aux organisations de limiter ce que voient les administrateurs, et journaliser chaque consultation des détails d’une personne par un administrateur.
- Garder une durée de conservation courte et permettre à chacun de révoquer son propre appareil à tout moment.
- Vérifier les obligations d’information, de consentement et de consultation des représentants du personnel prévues par votre droit local avant le déploiement.
La place de vetkit
Agent Watch est l’application de bureau de vetkit conçue pour cela. Elle surveille les sessions Claude Code, Codex, Cursor, Windsurf, Copilot, Gemini CLI, Cline et Aider sur une machine appairée et signale les accès aux identifiants, le trafic sortant, les commandes destructrices, le périmètre, la chaîne d’approvisionnement, la persistance et la posture, regroupés par règle et par appareil. Chaque session porte des attestations marquées vérifiée, partielle ou inconnue selon la couverture des capteurs. Elle observe et signale ; elle ne bloque rien.
Elle suit le modèle de confidentialité décrit plus haut : les appareils s’appairent via un code que la personne approuve, les envois se limitent aux métadonnées, les événements bruts ne sont envoyés que si l’organisation et l’utilisateur l’ont tous deux activé, les consultations par un administrateur des détails d’un autre membre sont auditées, et les membres peuvent révoquer leur appareil à tout moment. La documentation d’Agent Watch détaille la disponibilité et les offres. Côté configuration, le guide des permissions montre ce que l’audit de dépôt signale dans les réglages d’agent commités.
Sources
Nous avons relevé les informations sur chaque outil dans sa propre documentation le :
Les noms de produits sont des marques de leurs propriétaires respectifs. vetkit n’est ni affilié à ceux-ci, ni approuvé ou sponsorisé par eux. Vous avez repéré une information obsolète ? Écrivez à contact@vetkit.dev et nous la corrigerons.