Votre fournisseur d'IA est un risque fournisseur : ce que révèlent deux incidents de 2026

Conclusion opérationnelle

Une entreprise qui adopte un assistant d'IA générative évalue généralement le modèle : sa qualité, son prix, le sort des données qu'on lui confie. Elle évalue rarement ce qui l'entoure : le compte qui y donne accès, les services auxquels il est connecté, les logiciels dont il dépend.

Deux incidents rendus publics en septembre 2026 montrent que c'est là que se situe le risque. Chez OpenAI, des chercheurs ont atteint des dépôts de code internes en partant d'une image envoyée sur le forum d'aide de l'éditeur.^[1] Chez CrowdSec, éditeur français de solutions de sécurité, le code source privé a été téléchargé avec le compte d'un ancien salarié, compromis par un paquet logiciel piégé.^{[2] [3]}

Ni l'un ni l'autre n'a exploité le produit principal. Les deux sont passés par les abords : un service annexe, une dépendance, un accès maintenu après un départ.

Décision recommandée : traitez votre fournisseur d'IA comme n'importe quel fournisseur critique. Recensez les connexions que vous lui avez ouvertes, réduisez-les au strict nécessaire, revoyez-les régulièrement, et faites en sorte que la compromission d'un seul compte ne donne pas accès à tout.

1. D'une image sur un forum aux dépôts internes d'OpenAI

Le 25 juillet 2026, l'équipe de recherche en sécurité Hacktron a enchaîné deux vulnérabilités pour prendre le contrôle de comptes ChatGPT de plusieurs employés d'OpenAI. Le récit qui suit est celui qu'en ont publié les chercheurs le 13 septembre.^[1]

Le point d'entrée était le forum d'aide d'OpenAI, community.openai.com, qui fonctionne avec le logiciel Discourse. Une image au format HEIF, spécialement fabriquée, exploitait une faille dans la bibliothèque de décodage d'images libheif, utilisée par ImageMagick pour traiter les images envoyées. Les chercheurs ont ainsi obtenu l'exécution de code sur le serveur du forum.^[1]

L'escalade est venue de l'authentification unique (SSO). Le forum était relié au système d'identification d'OpenAI. Selon les chercheurs, une faille de ce système permettait, depuis le forum compromis, de prendre le contrôle des comptes ChatGPT et Codex des personnes qui s'y connectaient, sans aucune action de leur part.^[1]

L'impact tenait aux connecteurs. Le compte d'un employé était relié à l'organisation GitHub d'OpenAI par l'intermédiaire de Codex, l'assistant de programmation de l'éditeur. Pour prouver l'accès sans consulter de code interne, les chercheurs ont demandé à cet assistant d'ouvrir une demande de modification dans le dépôt principal interne d'OpenAI, puis ont arrêté leurs tests. Ils soulignent que ChatGPT et Codex pouvant être connectés à GitHub, Slack ou à la messagerie, le périmètre théoriquement accessible était très large.^[1]

Toute la chaîne, de la découverte à l'accès aux dépôts, a pris moins de 72 heures. Les chercheurs ont signalé les failles à OpenAI et à Discourse, qui les ont corrigées ; OpenAI leur a versé une prime de 6 500 dollars, en précisant qu'elle récompense la faille de son système d'identification : les tests contre le forum sortaient du périmètre de son programme de primes. Ils insistent sur un point : la faille qui a permis l'escalade n'était pas propre au forum. Tout service, interne ou tiers, utilisant le même système d'identification aurait pu servir de point de départ.^[1]

2. Un paquet piégé, un ancien salarié, 170 dépôts privés

Le second incident suit un chemin différent. CrowdSec en a publié une déclaration et une analyse détaillée, signée de son dirigeant.^{[2] [3]}

Le 11 mai 2026, un groupe d'attaquants a compromis TanStack, un ensemble de paquets logiciels très utilisé pour développer des interfaces web en JavaScript, en y insérant un programme conçu pour voler des identifiants et des jetons d'accès.^[3]

Le 22 mai, en moins de dix minutes, le contenu d'environ 170 dépôts de code privés de CrowdSec a été téléchargé. L'enquête, menée avec l'aide de GitHub, a établi que le compte utilisé était celui d'un développeur qui venait de quitter l'entreprise, mais qui restait membre de l'organisation GitHub pour finir un travail en cours, d'un commun accord. Selon l'entreprise, son poste avait été compromis par l'attaque de TanStack. Son accès a été retiré le 25 mai.^[3]

CrowdSec n'a appris la fuite que le 16 septembre, près de quatre mois plus tard, lorsqu'un tiers l'a prévenue qu'une archive de son code circulait. Dans sa déclaration du lendemain, l'entreprise indiquait qu'aucune donnée client ni aucun identifiant n'avait fuité.^[2] Son analyse détaillée, publiée quelques jours plus tard, est plus précise : l'archive contenait aussi 83 adresses e-mail d'utilisateurs, conservées pour des statistiques d'usage, ainsi que les noms et adresses e-mail de 51 investisseurs potentiels de 2020 ; l'entreprise annonce les prévenir, et informer les autorités compétentes pour les seconds. Le compte n'a servi qu'à copier les dépôts : aucune activité n'a été relevée sur l'infrastructure. Parmi les jetons d'accès présents dans le code, un seul restait utilisable, limité à l'envoi de notifications ; il a été testé le 17 août. Les autres étaient déjà renouvelés ou inutilisables depuis Internet, et les jetons et identifiants nécessaires ont été renouvelés dès la découverte.^{[2] [3]}

CrowdSec n'est pas un fournisseur d'IA. Son cas est pourtant instructif pour la suite : c'est la mécanique ordinaire d'une compromission par la chaîne d'approvisionnement logicielle, celle à laquelle s'expose tout outil, y compris d'IA, qui dépend de centaines de composants tiers.

3. Ce que les deux incidents ont en commun

Le maillon faible était à côté du produit. Un forum d'aide chez OpenAI ; un paquet de développement chez CrowdSec. Dans les deux cas, le composant compromis n'était pas celui que l'on aurait audité en priorité.

L'identité a fait le reste. Chez OpenAI, une erreur de configuration de l'authentification unique, qui a transformé la compromission d'un service annexe en accès aux comptes.^[1] Chez CrowdSec, un compte maintenu actif après un départ, pour de bonnes raisons.^[3] Dans les deux cas, un seul accès compromis ouvrait un périmètre bien plus large que son usage réel.

La détection est venue de l'extérieur. OpenAI a été alertée par les chercheurs, CrowdSec par un tiers, quatre mois après les faits.^{[1] [2]} Les chercheurs de Hacktron ajoutent que, dans la campagne plus large dont cette attaque faisait partie, ils n'ont connaissance d'aucune entreprise ayant détecté leur activité, à une exception près, alors même que les serveurs de traitement d'images plantaient à répétition.^[1]

4. Le risque propre à l'IA : les connecteurs

Le premier incident éclaire un risque qui prend une ampleur nouvelle avec les assistants d'IA connectés. Un assistant relié à la messagerie, à l'espace documentaire et aux dépôts de code concentre dans un seul compte des accès qui, autrement, seraient répartis entre plusieurs outils. Prendre le contrôle de ce compte revient à les obtenir tous.

L'ANSSI avait anticipé ce point dans ses recommandations de sécurité pour les systèmes d'IA générative, publiées en avril 2024. Elle relève que certains outils d'IA générative proposent des connexions avec la messagerie, l'espace documentaire, les dépôts de code source ou les services de visioconférence, et recommande une attention particulière à leurs droits d'accès.^[4] Trois de ses recommandations s'appliquent directement :

• R35 — Revoir les droits des connecteurs. Examiner les droits d'accès des outils d'IA générative dès leur activation, pour vérifier que les réglages par défaut ne sont pas trop ouverts, puis les revoir régulièrement, par exemple tous les mois, car les mises à jour du produit peuvent les modifier.^[4]
• R27 — Limiter les actions automatiques. Limiter, voire proscrire, les actions automatiques sur le système d'information déclenchées par un système d'IA à partir d'entrées non maîtrisées, comme des données issues d'Internet ou des e-mails.^[4]
• R34 — Pas de données sensibles dans les outils en ligne. Ne pas soumettre de données sensibles de l'entreprise à un outil d'IA générative sur Internet dont elle n'a pas la maîtrise.^[4]

5. L'économie de l'attaque change

Un élément du premier incident mérite l'attention. Les chercheurs indiquent avoir utilisé un modèle d'IA récent pour écrire l'exploit de la faille libheif : quelques heures ont suffi là où un modèle précédent peinait depuis plusieurs sessions.^[1] Selon eux, l'ensemble de leur campagne, menée sur deux mois contre plusieurs grandes entreprises, a coûté moins de 3 000 dollars en calcul, et l'adaptation de l'exploit à chaque nouvelle cible prenait un à deux jours.^[1]

Leur conclusion : la difficulté technique protégeait jusqu'ici, en pratique, les entreprises ordinaires contre les attaques sophistiquées, et l'IA réduit cette protection en transformant une expertise rare en temps de calcul.^[1] Il s'agit de l'analyse d'une société dont la recherche de vulnérabilités est le métier ; elle n'en est pas moins étayée par l'incident qu'elle décrit.

Pour une PME, la conséquence pratique est simple : l'argument « nous sommes trop petits pour intéresser un attaquant sophistiqué » perd de sa force quand l'attaque sophistiquée devient bon marché.

6. Traiter le fournisseur d'IA comme un fournisseur

Rien de ce qui précède n'impose de renoncer aux assistants d'IA. Mais ils doivent entrer dans le même cadre que les autres fournisseurs critiques.

Le contrat. Lorsque le fournisseur traite des données personnelles pour votre compte, la CNIL rappelle qu'il faut encadrer la relation par un contrat de sous-traitance, qui précise les périmètres de responsabilité et les accès autorisés aux données.^[5] C'est aussi le moment de demander comment le fournisseur vous informera d'un incident qui vous concerne.

Les accès. Chaque connecteur ouvert à un assistant est une porte supplémentaire vers vos données. Le principe est celui du besoin d'en connaître : un connecteur par usage justifié, avec les droits minimaux, revus régulièrement, conformément à la recommandation R35 de l'ANSSI.^[4]

Les comptes. Le cas CrowdSec rappelle que la fin d'un contrat de travail doit entraîner la fin des accès, y compris aux outils d'IA et aux services qui leur sont connectés, et qu'une exception, même justifiée, doit être bornée dans le temps.^[3]

Les dépendances. Si vous développez vos propres outils autour d'un modèle, l'ANSSI recommande de recenser les bibliothèques et modules externes utilisés et d'évaluer leur niveau de confiance.^[4] CrowdSec indique pour sa part imposer une ancienneté minimale aux paquets JavaScript qu'elle installe, ce qui laisse le temps à une version piégée d'être repérée.^[3]

La sortie. Un fournisseur critique doit pouvoir être remplacé. Savoir où sont vos données, sous quel format les récupérer et quels usages dépendent de quel service vous évite de devoir choisir entre continuer avec un outil compromis et tout arrêter. Pour les données les plus sensibles, un modèle exécuté sur vos propres machines est une autre option, que nous avons examinée dans notre article du 30 septembre.

7. Plan d'action

1. Recenser les outils d'IA utilisés dans l'entreprise, y compris ceux adoptés individuellement par les équipes.
2. Lister leurs connecteurs : messagerie, documents, dépôts de code, agenda, messagerie instantanée.
3. Couper ce qui n'a pas d'usage justifié et réduire les droits du reste au minimum.
4. Activer l'authentification forte sur les comptes d'IA, au même niveau que la messagerie.
5. Inscrire les outils d'IA dans la procédure de départ des salariés et des prestataires.
6. Programmer une revue des droits, par exemple mensuelle, comme le suggère l'ANSSI.
7. Vérifier les contrats : sous-traitance des données, notification des incidents, conditions de sortie.

Recommandation finale

Les deux incidents de 2026 ne disent pas que les fournisseurs d'IA sont moins sûrs que les autres. Ils disent que leur sécurité ne se résume pas à celle de leur modèle, et que la vôtre dépend largement de ce que vous leur avez connecté.

La mesure la plus efficace est aussi la moins spectaculaire : savoir, à tout moment, quels outils d'IA ont accès à quoi dans votre entreprise, et pouvoir le justifier.

Cette note constitue une analyse technique et opérationnelle générale ; elle ne constitue ni un avis juridique ni un audit de sécurité. Les incidents décrits le sont d'après les publications de leurs auteurs et des entreprises concernées, citées en fin d'article ; nous n'en avons pas vérifié les éléments techniques de façon indépendante.