La fuite accidentelle : ce qui se passe quand une stack trace atterrit dans ChatGPT

Ça commence presque toujours de la même façon. Quelque chose casse, le terminal se remplit de rouge, et le moyen le plus rapide d’obtenir une solution semble être de tout coller dans ChatGPT ou Claude en demandant « qu’est-ce qui se passe ? ». Personne ne décide de divulguer un identifiant à ce moment-là — on cherche juste à se débloquer. Mais une stack trace complète, un log de débogage ou un console.log(process.env) oublié d’une session précédente contient généralement plus que l’erreur elle-même. Il contient tout ce qui se trouvait dans le contexte au moment où les choses ont mal tourné.

Ce que contient vraiment un dump d’erreur classique

Les erreurs applicatives arrivent rarement propres. Un gestionnaire de requêtes qui plante en cours de route affiche souvent l’objet requête qu’il traitait — en-têtes compris. Un script de démarrage qui échoue avant que l’application soit entièrement configurée affichera volontiers l’objet de config qu’il essayait de construire, parce que c’est exactement ce qu’on veut voir pour déboguer un échec au démarrage. Rien de tout cela n’est un bug au sens strict. C’est la sortie de débogage qui fait son travail : vous montrer tout ce qui était vrai au moment où ça a cassé.

Voici le genre de contenu qui se retrouve dans une fenêtre de terminal juste avant que quelqu’un sélectionne tout, copie et colle dans une fenêtre de chat (les valeurs ci-dessous sont fictives, structurées pour paraître plausibles sans être utilisables) :

Error: connect ECONNREFUSED 127.0.0.1:5432
    at TCPConnectWrap.afterConnect [as oncomplete]

Config at time of failure:
{
  OPENAI_API_KEY: 'sk-test-FAKEexampleKeyDoNotUse1234567890',
  DATABASE_URL: 'postgres://admin:test-password@db.internal:5432/app',
  PORT: 3000
}

Pour la personne qui débogue, la ligne intéressante est ECONNREFUSED — la base de données est injoignable. La clé API et le mot de passe de la base ne sont là que par hasard, affichés parce que l’objet de config a été imprimé en bloc plutôt que champ par champ. C’est ce schéma qu’il faut remarquer : la fuite ne vient pas d’une négligence envers les secrets en particulier, elle vient d’habitudes de débogage ordinaires qui affichent plus de contexte que l’erreur n’en a besoin.

Pourquoi c’est facile à manquer sur le moment

En plein incident, on cherche la ligne qui explique l’échec, on ne relit pas le reste de la sortie à la recherche d’informations sensibles. Une stack trace de 40 lignes est sélectionnée et copiée d’un bloc, parce que séparer « la partie utile » du « reste » prend un temps qu’on n’a pas l’impression d’avoir. C’est une façon tout à fait raisonnable de travailler sous pression — simplement, ce workflow ne laisse aucune pause naturelle pour une vérification de sécurité.

Une fois ce collage arrivé dans la fenêtre de chat d’un outil d’IA, il échappe à votre contrôle immédiat d’une manière qu’un terminal local ne connaît pas. Ce qu’il devient dépend des paramètres de conservation et d’entraînement de l’outil, de qui peut voir cette conversation par-dessus votre épaule ou dans un espace partagé, et de votre capacité à penser à nettoyer le même log avant de le coller dans un ticket de support ou un fil Slack cinq minutes plus tard. Rien de tout cela n’exige une intention malveillante — c’est simplement une surface d’exposition plus large que celle d’un terminal.

Où placer réellement l’étape de masquage

La solution n’est pas « faire plus attention » — ce n’est pas un changement de workflow, c’est un vœu pieux. La solution plus fiable consiste à placer la vérification au seul point par lequel passe chaque version de cette histoire : le collage lui-même. Qu’il s’agisse d’une habitude manuelle (parcourir le bloc à la recherche de tout ce qui suit un = ou un : et ressemble à une clé, un jeton ou un mot de passe avant de coller) ou d’un outil qui fait cette analyse automatiquement au moment du collage, le principe est le même — l’intercepter après la copie mais avant qu’il ne quitte votre presse-papiers, pas une fois qu’il est déjà dans l’historique de chat de quelqu’un d’autre.

C’est précisément ce moment autour duquel PasteCloak est conçu : un raccourci clavier qui analyse le presse-papiers à la recherche de formats de secrets connus — clés API, jetons bearer, URL de base de données, clés privées — juste avant la fin du collage, et remplace tout ce qu’il reconnaît par un marqueur comme [OPENAI_API_KEY_1] avant que le texte n’arrive dans ChatGPT, Slack ou un formulaire de support. Le contexte de débogage reste intact — on voit toujours qu’une connexion à la base a échoué — seul l’identifiant ne fait plus partie de ce qui est envoyé.

Disons-le clairement : une détection par motifs ne peut pas tout intercepter. Elle reconnaît des formats connus — clés API de fournisseurs identifiés, motifs structurels comme les clés privées PEM, affectations explicites comme password: ou DATABASE_URL= — et elle manquera un identifiant dont elle ne reconnaît pas la forme. C’est une vraie limite, pas une note de bas de page. Elle réduit nettement la fréquence à laquelle une stack trace se transforme en clé divulguée ; elle ne fait pas du collage dans un outil d’IA une action sans risque. Relire votre sortie avant de la copier reste utile quand vous avez dix secondes de plus.