Le déroulé, journal à l’appui
L’incident concerne la version 12.33.4 de Postman pour macOS. Le journal de l’application enregistre un événement d’installation automatique (« auto-existing-upgrade ») qui pose un plugin dans Codex et en active un autre dans Claude Code. Le même passage ajoute une interface en ligne de commande Postman dans le dossier des exécutables de l’utilisateur et déclare une connexion MCP distante vers les serveurs de l’éditeur.
Le plugin Codex arrive avec un hook de démarrage. À chaque nouvelle session, ce petit script glisse une consigne dans le contexte de l’agent : pour tout travail un peu sérieux sur une API, charger la compétence « postman:api-engineer ». La consigne ne se limite pas aux demandes qui mentionnent Postman. Elle couvre tout le travail API, et l’agent finit logiquement par tout faire passer par Postman.
Codex dispose pourtant d’un garde-fou prévu pour ce cas. Un hook exécute du code sans intervention humaine, donc l’outil conserve une empreinte de chaque hook et attend que l’utilisateur l’approuve. D’après le code source cité dans le ticket, l’installateur de Postman écrit lui-même cette approbation. L’étape de validation humaine disparaît.
Le rapport ajoute que la commande de désinstallation de Postman ne remet pas tout en état : il faut retoucher les fichiers de configuration à la main. Aucun envoi de données n’a été constaté, et la connexion MCP échouait d’ailleurs à s’authentifier sur la machine du développeur.
Pourquoi le sujet concerne le DPO
Un agent de développement lit le code source, les fichiers de configuration, parfois un fichier .env oublié ou un extrait de base copié pour reproduire un bogue. Dans beaucoup d’équipes, ces extraits contiennent des données réelles : noms, adresses, numéros de dossier. Quand un éditeur tiers décide à la place de l’équipe des outils que l’agent utilise, et ouvre un canal vers ses propres serveurs, il crée un chemin vers l’extérieur que personne n’a évalué.
Sécurité du traitement (article 32)
L’article 32 du RGPD impose des mesures adaptées au risque. Savoir quels logiciels tournent sur les postes qui manipulent des données personnelles fait partie du minimum. Une mise à jour qui reconfigure d’autres logiciels sans prévenir casse cette maîtrise, même quand l’intention de l’éditeur est commerciale et non malveillante.
Destinataires, sous-traitance et transferts
Si des données personnelles partaient vers le service MCP de Postman, l’éditeur en deviendrait destinataire. Selon l’usage, il faudrait alors un contrat au sens de l’article 28, une mise à jour du registre et une analyse du transfert vers les États-Unis (Data Privacy Framework ou clauses contractuelles types). Rien de tout cela n’existe quand l’outil s’invite tout seul.
Protection dès la conception (article 25)
Les plateformes d’agents ont construit des mécanismes d’approbation pour que l’humain garde la main. Un installateur qui valide sa propre confiance contredit l’esprit de l’article 25 : les réglages par défaut doivent rester les plus protecteurs, et l’ouverture d’un canal vers un tiers devrait passer par un choix explicite.
Et l’article 82 de la loi Informatique et Libertés ?
L’article 82 encadre l’écriture d’informations dans l’équipement terminal d’un utilisateur. Il vise d’abord les cookies et traceurs, et son application à un logiciel qui en reconfigure un autre reste discutable. La question se pose quand même, puisque le hook sert l’intérêt commercial de l’éditeur et non un besoin exprimé par l’utilisateur.
Lire sa propre configuration
Le tableau part de ce qu’un développeur trouve en ouvrant ses fichiers. Pour chaque trace, il indique ce qu’elle signifie, à quoi ressemble une configuration choisie par l’utilisateur et la commande qui permet de le vérifier soi-même.
| Fichier | Ce que vous voyez | Ce que cela signifie | Configuration choisie par vous | Comment vérifier |
|---|---|---|---|---|
| Codex | Une place de marché « postman-plugin » et un hook SessionStart dans config.toml. | Chaque session démarre avec une consigne qui oriente l’agent vers Postman. | Seules les places de marché et les hooks que vous avez ajoutés vous-même, et dont vous vous souvenez. | grep -i postman ~/.codex/config.toml |
| Hooks Codex | Un hook Postman marqué comme approuvé dans le fichier d’état des hooks. | Le hook s’exécute sans que vous ayez validé son contenu. | Chaque hook approuvé correspond à une validation que vous avez faite dans l’interface de Codex. | Ouvrir la liste des hooks dans Codex et retirer l’approbation de ceux que vous ne reconnaissez pas. |
| Claude Code | L’entrée postman@claude-plugins-official activée dans settings.json. | Le plugin Postman se charge dans toutes vos sessions. | Les plugins que vous avez installés avec la commande claude plugin install. | grep -i postman ~/.claude/settings.json |
| Exécutables | Un fichier postman dans ~/.local/bin. | Une interface en ligne de commande a été ajoutée hors de toute installation volontaire. | Les outils installés par vous ou par votre gestionnaire de paquets. | ls -l ~/.local/bin | grep -i postman |
| Serveurs MCP | Une connexion vers mcp.postman.com dans la liste des serveurs MCP. | L’agent peut envoyer des requêtes à un service distant de l’éditeur. | Uniquement les serveurs MCP validés par l’équipe et inscrits au registre. | Taper /mcp dans une session Claude Code et consulter la liste équivalente dans Codex. |
La commande de désinstallation de Postman ne suffit pas à tout retirer. Après nettoyage, relancer les mêmes vérifications permet de confirmer que plus rien ne subsiste.
Que faire selon ma situation ?
Je suis DPO et je n’ai pas accès aux postes des développeurs
Je suis développeur et Postman est installé sur ma machine
Nous n’utilisons pas Postman
Au-delà de Postman
Le cas Postman a peu de chances de rester isolé. Chaque éditeur d’outils pour développeurs veut désormais sa place dans les agents, et la tentation de s’installer par défaut est forte. Côté organisation, quelques décisions simples limitent la casse : inscrire les agents de développement et leurs extensions au registre des logiciels, avec les traitements qu’ils touchent ; bannir les données réelles des environnements où tournent ces agents ; demander aux éditeurs une option claire pour désactiver toute installation automatique.
Testez vos réflexes
A. La validation humaine du code exécuté à chaque session
B. Le chiffrement des échanges avec l’agent
C. La licence du logiciel
A. Rien, l’outil est gratuit
B. Qualifier son rôle, encadrer le transfert et mettre à jour le registre
C. Le consentement écrit de chaque développeur
A. Oui
B. Non, il faut aussi corriger les fichiers de configuration
Voir le barème
Questions fréquentes
Des données ont-elles fuité chez les utilisateurs de Postman ?
Faut-il déclarer une violation de données à la CNIL ?
Les agents de développement doivent-ils figurer au registre ?
À retenir
Aucune fuite n’est rapportée. La configuration des agents de développement fait pourtant partie de la surface d’attaque, au même titre que les extensions de navigateur il y a quelques années. Un fichier de configuration modifié en silence suffit à faire passer des données par un tiers que le registre ignore.