Ce que l'on sait de l'incident, au 18 octobre 2026
OpenCode, agent de programmation open source permettant d'utiliser plusieurs modèles d'intelligence artificielle, a confirmé samedi 17 octobre 2026 avoir subi une intrusion informatique survenue dans la nuit du 16 au 17 octobre. L'entreprise indique que 1,4 % des utilisateurs de son service OpenCode Console sont concernés. Il s'agit, précise-t-elle, uniquement des comptes ayant connecté des fournisseurs externes d'intelligence artificielle, c'est-à-dire leurs propres identifiants chez OpenAI, Anthropic ou Google.
Selon le site Cyberattaque.org, OpenCode Console conserve l'identifiant du fournisseur dans l'espace de travail (workspace) d'une équipe et l'ajoute automatiquement aux requêtes envoyées à son API. Les membres d'une équipe peuvent ainsi exploiter les modèles sans jamais voir la clé elle-même. C'est précisément cette fonctionnalité centralisée qui est concernée par l'incident. OpenCode affirme avoir identifié tous les comptes touchés et les avoir prévenus par e-mail dès la matinée du 17 octobre, précisant que les personnes n'ayant reçu aucune notification ne sont pas concernées par le périmètre actuellement identifié. L'entreprise n'a pas publié le nombre absolu de comptes affectés ni de bilan définitif des données exposées.
Une "attaque de distillation" dont le mécanisme reste flou
Dans sa déclaration, OpenCode relie l'incident à une "attaque de distillation à grande échelle". La notification envoyée aux utilisateurs concernés évoque pourtant d'abord autre chose : un accès non autorisé à un ancien système que l'entreprise était en train de démanteler. Ce sont les clés de fournisseurs tiers enregistrées dans les workspaces qui auraient ensuite pu être exposées par ce biais.
Plusieurs médias spécialisés, dont Frandroid, Cyberattaque.org et Pix Geeks, relèvent qu'OpenCode n'a jamais détaillé le lien technique entre l'intrusion dans ce système legacy et la distillation évoquée. La distillation est une méthode d'entraînement légitime quand elle est autorisée : un modèle "professeur" répond à des milliers de questions et un modèle "élève" apprend à l'imiter. Elle devient une attaque lorsqu'un acteur tente d'aspirer, sans accord, les capacités d'un modèle concurrent en multipliant les requêtes. Anthropic a documenté ce type de campagnes dans un rapport publié en septembre 2026, évoquant des comptes frauduleux et des clés API volées. Dans le cas d'OpenCode, la distillation semble présentée comme le mobile de l'attaque plutôt que comme sa méthode d'intrusion : rien n'indique par exemple une injection de prompt visant à faire révéler des secrets à une IA.
Le cofondateur d'OpenCode, Dax Raad, a précisé sur X que c'est bien le service hébergé Console qui est touché, et non l'outil en ligne de commande (CLI) : les clés enregistrées localement via la commande /connect restent sur la machine du développeur et ne parviennent jamais à l'entreprise. Il a ajouté que ses propres comptes personnels avaient également été ciblés.
Des factures qui grimpent avant même l'alerte officielle
Plusieurs développeurs ont signalé des consommations anormales sur leurs comptes avant même la communication d'OpenCode. Selon Frandroid, un utilisateur rapporte 355 euros de frais non autorisés sur son compte Anthropic, et un autre évoque environ 200 euros de facturation Google, avec un projet suspendu pour usage abusif. Le site Pix Geeks rapporte, de son côté, que le développeur Colin Parsons dit avoir constaté 281 dollars facturés sur sa clé OpenAI et 168 dollars sur sa clé Anthropic, deux clés qu'il n'utilisait que dans OpenCode. Un autre utilisateur cité par ce même site, Max Weinbach, affirme avoir relevé près de 35 millions de tokens consommés en une seule journée sur 8 966 requêtes, faisant passer le solde prépayé de son compte OpenAI à -2,15 dollars. Chez Anthropic, une collaboratrice citée par Pix Geeks indique que l'entreprise a révoqué les clés API Claude jugées concernées et conseille à ceux qui en avaient stocké une dans OpenCode d'en créer une nouvelle. Ces témoignages restent individuels : aucune des sources consultées ne fait état d'un bilan financier global communiqué par OpenCode.
Le vrai sujet pour un DSI : où vivent les clés API de l'entreprise ?
Au-delà du cas OpenCode, l'incident illustre un risque structurel que connaissent bien les équipes sécurité : la centralisation de secrets d'authentification chez un tiers qui orchestre l'accès à plusieurs fournisseurs d'IA. Frandroid le résume ainsi : un outil qui stocke les clés de plusieurs fournisseurs au même endroit reste une cible de choix, puisqu'une seule intrusion ouvre plusieurs portes à la fois. Le même média rappelle que lors du piratage du service Brevo, une seule clé compromise avait suffi à menacer plus de 100 000 sites.
Pour une direction informatique française qui connecte ses abonnements OpenAI, Anthropic ou Google à un outil tiers, plusieurs modèles de gestion des clés coexistent, avec des surfaces d'exposition très différentes.
| Modèle de gestion des clés | Où la clé est stockée | Ce qui est exposé en cas de piratage de l'outil tiers |
|---|---|---|
| Clé personnelle connectée à un orchestrateur hébergé (cas d'OpenCode Console) | Côté serveur de la plateforme tierce, dans l'espace de travail de l'équipe | Toutes les clés enregistrées par l'ensemble des comptes du workspace, avec facturation chez le fournisseur réel |
| Clé personnelle utilisée en local (cas du CLI OpenCode, selon Dax Raad) | Sur la machine du développeur, jamais transmise à l'éditeur de l'outil | Uniquement le poste individuel compromis, pas l'ensemble des utilisateurs de l'outil |
| Accès par abonnement sans clé tierce à fournir par le client | Aucune clé OpenAI, Anthropic ou Google détenue par l'entreprise cliente | Pas de clé individuelle à révoquer côté fournisseur en cas d'incident sur la plateforme d'accès |
Les gestes à appliquer si votre organisation utilise OpenCode Console
Les recommandations relayées par Frandroid et par le guide pratique publié sur DEV Community convergent sur un même ordre d'opérations.
- Révoquer chaque clé enregistrée dans la Console depuis le tableau de bord du fournisseur concerné : la page des clés API d'OpenAI, la Console d'Anthropic, ou Google AI Studio selon l'endroit où la clé a été créée.
- Créer une nouvelle clé avant de supprimer l'ancienne, pour éviter d'interrompre un service en production, puis déployer la nouvelle clé partout où l'ancienne était utilisée.
- Vérifier la consommation récente de chaque compte afin de repérer les requêtes non lancées par l'organisation.
- Fixer un plafond de dépenses sur chaque compte, pour limiter les dégâts en cas de nouvelle fuite.
- Prévenir le fournisseur concerné : chez OpenAI, le contrat qui encadre l'API rend le client responsable de toute activité sur son compte et lui demande de signaler rapidement un accès non autorisé.
Ce que cela implique pour les plateformes IA utilisées en France
L'épisode rappelle qu'un abonnement IA "multi-fournisseurs" ne se construit pas de la même façon selon que l'entreprise cliente doit elle-même détenir et stocker des clés API chez chaque fournisseur, ou qu'elle accède aux modèles via un abonnement qui ne lui demande pas de gérer ces secrets. Moon AI, plateforme française éditée par Stellarr Studio SAS, propose par exemple un accès à plus de 70 modèles (GPT, Claude, Gemini, Mistral, DeepSeek, Llama, Grok, Qwen, ainsi que son modèle maison Moon 6) dans un abonnement unique, sans que le client ait à créer ou à enregistrer ses propres clés chez chacun de ces fournisseurs. La plateforme applique par ailleurs un procédé nommé Moon Blur, qui remplace les données personnelles par des jetons avant l'envoi aux modèles tiers, puis les rétablit au retour : un mécanisme réversible, donc une pseudonymisation au sens du RGPD, et non une anonymisation. L'application et le stockage de Moon AI sont hébergés chez OVHcloud, à Strasbourg et à Roubaix, mais les requêtes adressées aux modèles tiers partent bien chez leurs fournisseurs respectifs après pseudonymisation : les données ne restent pas confinées en France à ce stade du traitement.
Cette architecture ne supprime pas tous les risques liés à un fournisseur tiers de modèles, mais elle déplace le problème : l'entreprise cliente n'a plus à gérer elle-même des clés API multiples, qui restent, comme le montre l'incident OpenCode, l'un des maillons faibles les plus exposés d'une chaîne IA. Le site Stackademic, qui a couvert l'incident en anglais, évoque également une exposition potentielle au RGPD pour les utilisateurs européens dont des métadonnées de requêtes auraient pu transiter par des journaux compromis, une hypothèse qu'aucune autre source consultée ne confirme à ce jour.
Questions fréquentes
Le client OpenCode installé en local (CLI) est-il concerné par cette fuite ?
Selon le cofondateur d'OpenCode, Dax Raad, cité par Pix Geeks, seule la Console hébergée est touchée : les clés ajoutées en local via la commande /connect restent sur la machine du développeur et ne remontent jamais vers l'entreprise. Le site DEV Community souligne toutefois que cette distinction CLI/Console repose en partie sur un consensus de commentateurs et n'a pas fait l'objet d'une confirmation technique détaillée de la part d'OpenCode.
Comment savoir si une clé API a été utilisée frauduleusement ?
Il faut comparer la consommation récente (nombre de requêtes, coût journalier, modèles utilisés) à l'activité habituelle du compte chez chaque fournisseur. Un modèle inhabituel dans le mix de consommation, ou une activité pendant des plages horaires sans tâche planifiée correspondante, sont des signaux à vérifier en priorité.
Faut-il révoquer une clé même si l'organisation n'a reçu aucun e-mail d'OpenCode ?
OpenCode affirme que les utilisateurs n'ayant reçu aucune notification ne font pas partie du périmètre identifié actuellement. L'enquête étant toujours en cours selon l'entreprise, la prudence recommandée par plusieurs sources consiste néanmoins à considérer comme sensible toute clé ayant un jour été enregistrée dans un workspace Console, et à vérifier son historique de consommation.
Un abonnement multi-modèles évite-t-il ce type de risque ?
Un abonnement qui n'exige pas de l'entreprise cliente qu'elle crée et stocke ses propres clés API chez chaque fournisseur supprime ce maillon précis de la chaîne : il n'y a plus de clé individuelle à révoquer en cas d'incident côté outil d'accès. Cela ne dispense pas pour autant de vérifier comment les données transitent vers les modèles tiers une fois la requête envoyée.