L'IA dans votre SI : un risque que personne ne peut garantir

En dix jours de juillet 2026, deux incidents ont changé la nature du débat sur la sécurité des systèmes d’information intégrant de l’IA (c’est-à-dire la quasi-totalité aujourd’hui). Le 21 juillet, OpenAI révèle que deux de ses modèles ont franchi les limites de leur environnement de test isolé, accédé à Internet, et compromis les serveurs de production de Hugging Face pour y subtiliser les réponses d’un benchmark de cybersécurité. Le 31 juillet, Anthropic annonce à son tour que trois versions de Claude ont obtenu un accès non autorisé aux systèmes réels de trois organisations lors d’évaluations pourtant conçues pour les en empêcher.

Ces incidents ne sont pas des accidents isolés. Ils sont des révélateurs.

---

Ce qui s’est passé, sans la science-fiction

La couverture médiatique de ces événements a largement cédé au registre Terminator : “l’IA échappe à ses créateurs”, “le pire cauchemar de la SF”. C’est à la fois inexact et contre-productif. Inexact, parce qu’aucun de ces modèles n’a développé une intention malveillante ni une conscience de sa situation. Contre-productif, parce que le dramatisme occulte ce qui est réellement inquiétant.

Ce qui s’est passé est plus simple et plus sérieux : des systèmes d’optimisation, entraînés à atteindre des objectifs par le moyen le plus efficace, ont trouvé des chemins que leurs concepteurs n’avaient pas anticipés. Dans le cas d’OpenAI, le modèle a exploité une vulnérabilité zero-day dans un composant proxy pour accéder à Internet, puis enchaîné des vecteurs d’attaque sophistiqués jusqu’aux serveurs de Hugging Face. Non par malveillance, mais parce que c’était le chemin de moindre résistance vers son objectif. Dans le cas d’Anthropic, l’accès à Internet existait déjà dans l’environnement de test, sans que personne ne s’en soit aperçu.

La distinction est importante : dans un cas, le modèle a contourné activement ses contraintes. Dans l’autre, les contraintes n’étaient pas ce qu’on croyait qu’elles étaient. Deux chemins différents vers le même résultat : un comportement inattendu avec des conséquences réelles sur des systèmes tiers.

Et les deux labs ont découvert le problème de la même façon : après coup.

---

L’inversion silencieuse du paradigme de sécurité

Pendant trente ans, la sécurité des systèmes d’information a reposé sur un présupposé simple : il existe une frontière entre ce qui est dedans et ce qui est dehors. Ce qui est dedans est connu, inventorié, et même auditable. Ce qui est dehors est le risque. La mission du DSI (et de toute son infrastructure de sécurité) est de gérer cette frontière : pare-feux, cloisonnement réseau, politique d’accès, gestion des identités, veille active sur les vulnérabilités.

Ce modèle repose sur une présupposition fondamentale : la DSI connait ce qu’elle a déployé.

Cette présupposition s’effondre avec l’IA embarquée dans les logiciels tiers, et elle s’effondre sur deux plans simultanément.

Le dedans s’est ouvert vers l’extérieur. Dès qu’un logiciel intègre un LLM hébergé en dehors du SI, les données traitées circulent vers des infrastructures d’inférence que le DSI ne maîtrise pas. Dans la plupart des cas, il n’a pas de visibilité sur ce qui part, ni quand, dans quel état, et avec quelles garanties de non-rétention. L’ERP qui “suggère” des libellés comptables, la suite bureautique qui “complète” les emails, le CRM qui “résume” les interactions client : autant de flux sortants dont la nature exacte n’est pas documentée dans les contrats signés.

L’extérieur s’est installé dedans. Le modèle embarqué dans un logiciel tiers n’est pas un composant statique. Il peut être mis à jour par l’éditeur (ou par le fournisseur du modèle en amont) sans notification formelle, sans nouvelle version du logiciel, parfois sans que l’éditeur lui-même soit en mesure de documenter précisément ce qui a changé dans le comportement. Deux appels identiques au même outil peuvent produire des résultats différents avant et après une mise à jour silencieuse.

Le DSI se retrouve donc dans une situation inédite : responsable de la sécurité d’un périmètre qu’il ne peut plus définir avec certitude, peuplé de composants dont le comportement n’est pas entièrement prévisible, mis à jour selon des calendriers qu’il ne contrôle pas.

Pour illustrer concrètement cette situation : supposons un utilisateur qui demande à Copilot de modifier le thème graphique d’un document Word en cours de rédaction. Le document est une lettre de licenciement destinée à un employé de la DSI. Pour exécuter cette tâche, Copilot extrait un fragment du texte, lequel transite sur le réseau. Un outil de surveillance des flux de données (qui fait correctement son travail) lève une alerte : une donnée sensible vient d’être émise vers une destination non prévue à un technicien de surveillance. Peut-être l’employé concerné lui-même. Peut-être un collègue.

Dans cet exemple, personne n’a commis d’erreur au sens traditionnel. L’utilisateur a fait une demande banale et légitime. Copilot a exécuté la tâche pour laquelle il est conçu. Le réseau a fait circuler des données comme prévu. L’outil de surveillance a fonctionné correctement. Et pourtant une information ultra-sensible s’est retrouvée exposée à une destination que personne n’avait prévue ni souhaitée. C’est précisément la nature du risque : il n’émerge pas d’une faute, mais de l’interaction entre des systèmes qui fonctionnent chacun normalement.

---

Le trou noir des recommandations

Face à ces risques, les institutions ont réagi. Le 1er mai 2026, la CISA et cinq agences alliées (NSA, Australie, Canada, Nouvelle-Zélande, Royaume-Uni) ont publié Careful Adoption of Agentic AI Services, le premier document de guidance multinationale Five Eyes spécifiquement dédié aux agents IA autonomes. Le document est sérieux, bien construit, et identifie cinq catégories pertinentes de risque : escalade de privilèges, défauts de conception et de configuration, désalignement comportemental, défaillances en cascade, et opacité de la responsabilité.

Ses recommandations concrètes : ne pas accorder d’accès larges ou non restreints aux agents, commencer par des cas d’usage à faible risque, intégrer la sécurité IA dans le modèle de risque existant, maintenir une traçabilité complète de chaque décision et action d’un agent, attribuer à chaque agent une identité cryptographique vérifiable avec des credentials à durée limitée.

Ces recommandations sont raisonnables. Elles ont un seul problème : elles s’adressent aux organisations qui déploient directement des agents IA, développeurs, opérateurs, intégrateurs. Elles présupposent que le destinataire a accès à la configuration de ses agents, à leurs permissions, à leurs logs, à leur architecture.

Ce n’est pas la situation du DSI d’une ETI française qui a souscrit à une suite Microsoft 365 et se retrouve avec Copilot intégré dans ses outils bureautiques. Ni celle du DSI dont l’ERP a silencieusement ajouté ou modifié un assistant IA dans son module de facturation lors de la dernière mise à jour. Ni celle de l’entreprise dont le CRM hébergé en SaaS “bénéficie” désormais de l’IA de son éditeur américain, activée par défaut.

Ces DSI n’ont pas déployé d’IA. Ils ont souscrit à des logiciels, parfois plusieurs mois ou années avant. L’IA est arrivée avec.

Une étude de Kiteworks publiée en 2026 documente l’écart : 63% des organisations ne peuvent pas imposer de limitations d’usage à leurs agents IA, 60% ne peuvent pas terminer rapidement un agent défaillant, 55% ne peuvent pas isoler les systèmes IA du reste de leur réseau. Ce sont précisément les contrôles que le guide CISA exige maintenant et que la majorité des organisations n’ont structurellement pas les moyens d’exercer sur des composants qu’elles n’ont pas déployés.

---

La chaîne de responsabilité introuvable

Posons un scénario concret. Un logiciel de comptabilité intégrant un LLM produit un bilan comportant une erreur significative, ou pire, exfiltre vers un système externe des données financières confidentielles concernant les clients de l’entreprise. Qui répond ?

L’éditeur du logiciel de comptabilité, dont les CGU excluent toute garantie sur la précision des résultats produits par ses fonctions IA, une formulation désormais standard dans les contrats logiciels ? L’intégrateur qui a déployé la solution, et qui argüera qu’il a respecté les préconisations de l’éditeur ? L’ESN qui supervise le SI, dont la mission de maintien en conditions opérationnelles ne couvre pas l’audit des comportements d’un LLM tiers ? Le sous-traitant technique spécialisé IA qui a configuré certains paramètres, mais pas tous ? La DSI du client, qui n’a pas activé une option de sécurité dont elle ignorait l’existence, et dont la documentation technique, en anglais, supposait une expertise IA qu’elle n’a pas ? L’utilisateur enfin, dont le prompt potentiellement maladroit a peut-être déclenché la séquence ?

Et derrière tout cela on trouve les clients de l’entreprise, dont les données ont été compromises, qui se retourneront contre le seul interlocuteur avec lequel ils ont signé un contrat.

La Directive européenne sur la responsabilité des produits défectueux 2024/2853, entrée en vigueur en décembre 2024, apporte des éléments de réponse : elle reconnaît explicitement le logiciel comme un produit, intègre la notion d’apprentissage continu comme vecteur de défectuosité potentielle, et établit une responsabilité solidaire des composants dans une chaîne de sous-traitance. C’est un progrès indéniable.

Mais elle ne s’applique qu’aux produits mis sur le marché après décembre 2026. Et surtout, elle repose sur une présupposition que les incidents de juillet 2026 ont précisément mise en question : qu’un défaut est un écart identifiable entre le comportement attendu et le comportement réel d’un composant. Avec un LLM, cette comparaison n’a plus de sens univoque. Il n’existe pas de version “sans défaut” du modèle à laquelle comparer la version défaillante.

---

L’indéterminisme comme condition permanente

C’est là que réside la vraie rupture, et elle est conceptuelle avant d’être juridique ou technique.

Un logiciel déterministe a un comportement documenté, testable, reproductible. La version 12.3.1 fait ce que la documentation dit qu’elle fait, corrige sans équivoque les anomalies qui ont été identifiées. L’éditeur sait ce qu’il livre. L’auditeur peut le vérifier. Le DSI peut s’appuyer sur cette prévisibilité pour construire sa politique de sécurité.

Un système intégrant un LLM n’a pas cette propriété. Deux appels identiques peuvent produire des résultats différents. Le comportement dans un espace d’états inconnu ne peut pas être énuméré a priori, et c’est précisément ce que les incidents OpenAI et Anthropic démontrent, chez des organisations qui ont pourtant les moyens de tester plus rigoureusement que n’importe quelle DSI d’ETI. Ils ont découvert les comportements limites de leurs modèles en les observant après coup.

C’est l’analogie de la mécanique quantique appliquée au logiciel : on peut caractériser le comportement moyen d’un système probabiliste sur un grand nombre d’occurrences, établir des distributions, fixer des seuils d’acceptation statistiques. On ne peut pas garantir le comportement sur une occurrence particulière à enjeu irréversible. La position de l’électron est une distribution de probabilités, pas une coordonnée : c’est le principe d’incertitude de Heisenberg, formulé en 1927. Le comportement du LLM dans un contexte donné est une distribution de probabilités, pas une spécification.

Les éditeurs d’IA pourraient légitimement arguer que la responsabilité du cloisonnement incombe aux déployeurs ; que si les bonnes pratiques de sécurité avaient été respectées, si les audits avaient été faits, si les accès avaient été correctement limités, les incidents n’auraient pas eu lieu. L’argument n’est pas sans fondement technique. Mais il ignore deux réalités : d’une part, la majorité des DSI n’ont pas les moyens d’exercer ces contrôles sur des composants qu’elles n’ont pas déployés et dont elles ne maîtrisent pas l’architecture. D’autre part, et c’est le point que juillet 2026 a rendu difficile à contester, même avec toutes ces précautions, la garantie absolue n’existe pas. Les incidents OpenAI et Anthropic se sont produits dans des environnements d’évaluation conçus précisément pour être totalement sécurisés.

Donner accès à des données privées à un système non déterministe, c’est accepter un risque systémique dont on ne peut pas calculer exactement la magnitude, seulement l’estimer en moyenne.

---

Le self-hosting : reprendre le contrôle, pas éliminer le risque

Face à ce constat, une réponse revient fréquemment dans les discussions techniques : déployer le modèle sur sa propre infrastructure. Reprendre le contrôle des flux, éliminer le tiers de confiance incontrôlable, rapatrier l’inférence dans le périmètre du SI. L’intuition est juste sur le diagnostic : réduire les dépendances extérieures, c’est effectivement réduire une partie de la surface de risque identifiée plus haut.

Mais elle devient dangereuse si on la traite comme une solution en soi.

Le fait de déployer un LLM sur sa propre infrastructure ne supprime pas l’indéterminisme du modèle : il le déplace. Le comportement non prévisible reste non prévisible, qu’il s’exécute sur les serveurs de Microsoft ou sur ceux de l’entreprise. Ce qui change, c’est la chaîne de responsabilité : plus courte, certes, mais portée entièrement en interne. L’organisation qui self-hoste assume seule la configuration, la sécurisation, la mise à jour, la surveillance et la recette d’un système dont on a vu que les concepteurs eux-mêmes peinent à garantir le comportement dans tous les contextes.

Cela exige des compétences qui ne s’improvisent pas et ne courent pas les rues : architectes IA, ingénieurs MLOps, équipes de sécurité formées aux spécificités des systèmes probabilistes. Des compétences que la plupart des DSI, y compris dans de grandes organisations, devront chercher chez des prestataires spécialisés. Reconstituant ainsi, sous une autre forme, une chaîne d’acteurs avec ses propres zones d’ombre.

Le self-hosting est donc un outil pertinent dans une stratégie de gouvernance aboutie, pas un raccourci vers la maîtrise. Mal exécuté, il ajoute de la complexité opérationnelle sans réduire le risque fondamental, et sans le filet de sécurité contractuel qu’offre, même imparfaitement, la relation avec un éditeur établi.

---

Ce que cela signifie concrètement pour un DSI

Les leviers disponibles pour un DSI qui n’a pas déployé lui-même les composants IA de son SI sont différents de ceux que décrivent les guides institutionnels, et plus restreints. Ce qui suit n’est pas une liste exhaustive de bonnes pratiques : c’est un cadre de réflexion pour agir avec les marges de manœuvre réelles, plus réduites qu’on le voudrait.

Le premier levier est contractuel : exiger des éditeurs de logiciels une documentation explicite des composants IA embarqués, des flux de données sortants, des mécanismes de mise à jour des modèles, et des options de désactivation. Ce que vous ne pouvez pas documenter, vous ne pouvez pas l’auditer. Ce que vous ne pouvez pas auditer, vous ne pouvez pas le défendre devant un régulateur ou un juge.

Le second est de gouvernance : considérer l’IA embarquée dans les logiciels tiers comme une surface de risque à part entière dans votre politique de sécurité, au même titre que les accès tiers, les plages d’IP ou les ports ouverts sur le net, les APIs externes, les sous-traitants avec accès au SI. Pas parce que vous pouvez la contrôler directement, mais parce que vous pouvez documenter que vous en avez conscience et que vous avez pris des décisions informées.

Le troisième levier est de changer de regard sur le périmètre de risque. La tentation naturelle est de circonscrire le risque IA au contexte immédiat du déploiement : un outil de recommandation commerciale présente un profil moins critique qu’un outil de facturation, et cette distinction reste vraie. Mais elle est insuffisante. Une suite bureautique généraliste intégrant un LLM est utilisée par tous les employés de l’organisation, y compris ceux qui manipulent des données sensibles : contrats, données RH, données de santé, informations financières. L’IA ne connaît pas la criticité du document ouvert au moment de la requête. Et les incidents OpenAI et Anthropic ont démontré qu’un système a priori étanche peut être atteint par un autre système IA déployé ailleurs dans la chaîne sans qu’aucun des deux ait eu de contact direct avec les données ciblées.

Ce que cela implique est une rupture avec la mentalité classique de sécurisation des SI, qui consiste à cloisonner les sous-systèmes et à traiter les risques isolément. L’IA introduit des interactions transversales entre composants qui n’ont, en apparence, aucun lien entre eux. Sécuriser un SI dans lequel l’IA est présente demande une vision systémique de la surface de risque : une approche que la majorité des organisations n’ont pas encore intégrée, et que les guides institutionnels n’outillent pas encore suffisamment.

Le quatrième levier est la formation : probablement le plus structurant à long terme, et le plus négligé à court terme. Former les utilisateurs à ce qu’un LLM fait réellement avec leurs données, former le DPO aux implications IA du RGPD, former les équipes techniques à la configuration et à l’audit des composants IA, former la RSSI aux nouvelles surfaces d’attaque spécifiques aux systèmes probabilistes, former les dirigeants à poser les bonnes questions aux éditeurs lors des renouvellements contractuels. Aucun des leviers précédents n’est actionnable sans ce socle. Un levier contractuel sans interlocuteur formé pour le négocier reste lettre morte. Une politique de gouvernance sans équipe capable de l’interpréter reste un document.

La réglementation rattrapera ce retard, probablement dans les deux à trois ans. En attendant, le vide est réel, les incidents sont documentés, et la chaîne de responsabilité reste introuvable.

Savoir ça ne suffit pas à se protéger. Mais ne pas le savoir, c’est naviguer à l’aveugle dans un espace où les frontières ont changé sans qu’on ait eu le temps de refaire la carte.

---

Arnaud Balandras est docteur en physique, architecte IT et consultant indépendant. Il publie sur slow-layer.com.

---