Sécuriser l'IA : Au-delà de l'illusion de contrôle
Vous ne pouvez pas ignorer la sécurité de l'IA
Le monde change à une vitesse vertigineuse. Au-delà des jalons historiques - tels que la publication de « Attention Is All You Need » ou les débuts de ChatGPT - nous naviguons désormais dans un concert de discours sur l'IA. Ce qui ressemblait autrefois à des nouvelles révolutionnaires s'est dissout dans un bourdonnement incessant et assourdissant, qui s'amplifie chaque jour.
Grâce aux tours de magie des spécialistes du marketing, une grande substitution des concepts - consistant à appeler les grands modèles de langage (LLM) l’intelligence artificielle - a complètement bouleversé la perception du sujet. L'humanité a reçu un outil merveilleux et complexe, mais aucun manuel d'utilisation n'a été fourni.
Il n'est donc pas surprenant que beaucoup aient mésinterprété l’outil, se ruant sur ce nouveau jouet avec une ingéniosité aussi enfantine que sincère et téméraire. Un ardeur porteur d’espoirs, certes, bien que les recherches de McClain, C. et al. soulignent un fossé notable entre le grand public américain et les experts en IA concernant l’impact sociétal de cette technologie : là où le premier le perçoit de façon modérée, les seconds anticipent une transformation d’une bien plus grande envergure. Néanmoins, diverses manières imprévues d'utiliser les LLM ont sûrement dû amuser leurs créateurs, et cet enthousiasme fervent des utilisateurs et des nouveaux développeurs d'IA a marqué le début de l'ère des startups « vibe-codées ». Et ce sont elles qui bousculent les règles du marché quitte à en pervertir complètement le potentiel initial du concept d'IA : la facilité et le coût faible de production croissants obligent automatiquement les entreprises à mettre en œuvre de plus en plus d'« IA », malgré le manque de… un manque de tant de choses en fait !
Car la menace va au delà d’acteurs malveillants utilisant l'IA comme une arme pour corrompre des services ou exfiltrer des données , elle englobe l'échec des géants de l'industrie à sécuriser leurs propres environnements et vous, personnellement, n'étant pas prêt à réinventer vos “fondations numériques”.
Régularisation - être ou ne pas être conforme
Nous sommes, indéniablement, dans la précipitation. Selon l’étude McKinsey de 2025 (menée auprès de 1 993 participants à tous les échelons des organisations), si 88 % des répondants utilisent régulièrement l’IA dans au moins une fonction métier, à peine 1 % d’entre eux considèrent leurs déploiements d’IA générative comme matures. Cela se traduit essentiellement par un manque de compréhension et, par voie de conséquence, de maîtrise, sans même parler d'une gouvernance adaptée. Cette situation laisse aux techniciens une certaine liberté d'action, mais elle s'accompagne de risques importants.
D'autre part, les gouvernements commencent à élaborer des politiques de conformité si contraignantes que même les experts peinent à transformer ces bonnes intentions en réalité opérationnelle. Une telle législation non seulement ralentit l'intégration de l'innovation mais elle instaure des sanctions lourdes, à l'image de l'AI Act qui prévoit des amendes pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel d'une entreprise. Face à des menaces liées à l'IA en perpétuelle mutation - comme nous l'avons abordé et le détaillerons plus loin -, les règles juridiques s'adapteront inévitablement avec un temps de retard.
Si la plupart des pays disposent désormais de premiers cadres législatifs, la confiance envers ces réglementations demeure contrastée. Selon l’Ipsos AI Monitor (2025), relayé par le 2026 AI Index Report du Stanford HAI, les entreprises occidentales se montrent nettement plus sceptiques (42 % en France, 31 % aux États-Unis) que leurs homologues asiatiques (81 % à Singapour, 76 % en Indonésie).
Il est crucial de distinguer ici la conformité rigide imposée par la loi - qui peut parfois brider l'agilité - de l'adoption proactive de référentiels de bonnes pratiques. Si la première est une contrainte parfois lente, la seconde est un levier de sécurité indispensable. Alors, cela soulève finalement la question : quelles politiques sont les meilleures ? La réponse communément admise aujourd'hui consiste à viser une conformité la plus exhaustive possible. Même pour une entreprise basée en France, sans ambitions sur les marchés internationaux, l'adoption volontaire de normes ISO/IEC relatives à la gouvernance et à la gestion des risques de l'IA constitue une démarche de prudence salutaire. Si certaines offrent une certification et d’autres non, l’objectif n’est pas ici d’obtenir un label, mais de garantir une maîtrise réelle, plutôt qu'une simple conformité théorique.
Surface d'attaque - Comment vous pouvez être piraté
Rembrandt La Leçon d'anatomie du docteur Nicolaes Tulp
Application d'IA typique et son exposition
Au-delà des politiques, comment la surface d'attaque a-t-elle évolué à l'ère de l'IA ? Prenons l'exemple le plus courant : le chatbot basé sur le RAG. Dans sa forme élémentaire, il s'agit d'une application classique, avec son front-end et son back-end, exposée aux vulnérabilités habituelles que nous savons déjà sécuriser. Toutefois, l'ajout des fonctions de chat et de RAG introduit de nouvelles dépendances, des sources de données inédites et des bases vectorielles spécialisées. Cette complexité architecturale est le moteur même de l'avantage des LLM : une flexibilité qui rompt avec le développement rigide et déterministe d'autrefois. En abandonnant le code en dur, nous gagnons en agilité, mais nous héritons d'un périmètre d'exposition plus vaste et plus subtil.
Les menaces sont protéiformes. Via l’interface de chat, les attaquants peuvent exploiter des fuites de prompt pour révéler la logique interne, récolter des clés API ou manipuler le comportement du bot pour contourner les politiques de sécurité. Le RAG, lui, expose directement des données confidentielles, des informations personnelles (PII) ou des secrets industriels. Quant aux modèles et données sous-jacentes, ils sont vulnérables à la corruption : désinformation, biais ou backdoors cachées viennent miner la confiance accordée au système. Le coût d’une telle attaque est dérisoire : Anthropic estime que 0,00016 % de documents altérés suffisent à empoisonner un modèle, quelle que soit sa taille. Autre exemple, une étude sur un chatbot médical a montré qu’à peine 0,001 % de données modifiées augmente de 4 % le taux de réponses dangereuses.
Incontournable en cybersécurité traditionnelle, le risque de chaîne d’approvisionnement (supply chain) s’est désormais immiscé dans l’écosystème de l’IA. Une compromission des dépendances ouvre la voie à une prise de contrôle totale de votre infrastructure backend et au vol d’identifiants ou de secrets d’authentification critiques.
Enfin, l’excessive agency - ou l'usage abusif de la faculté d'exécution autonome de l'IA - génère des risques critiques : exécution d'actions non autorisées (comme des code commits ou la suppression de ressources), fuites de données inter-systèmes, voire préjudices juridiques et réputationnels consécutifs à des manipulations malveillantes ou à des arrêts de service.
Menaces de l'IA agentique - comment les agents se contaminent et se comportent mal
L'ère des agents modifie radicalement notre chaîne de confiance : moins l'humain est impliqué, plus la prudence s'impose. En misant sur la collaboration entre agents (A2A), les architectures agentiques multiplient les risques systémiques. En communiquant à la vitesse de la machine, ces agents peuvent propager des instructions malveillantes, contaminer le contexte ou la mémoire partagée, et générer des escalades de privilèges indirectes : un agent faiblement privilégié peut manipuler un pair plus puissant pour effectuer des actions non autorisées (le problème classique du « Député Confus » : si l'Agent A accède à une base de données et l'Agent B à une API de messagerie, un Agent A compromis peut forcer l'Agent B à exfiltrer les données).
Les entités IA qui s'écartent de leur objectif prévu ou de leur périmètre d'autorisation sont qualifiées d' Agents Rogues. Ils représentent une menace sévère pour l'intégrité opérationnelle, rendant l'identification de l'origine d'une compromission particulièrement complexe. L'atténuation de ces risques ne repose plus sur une simple surveillance des sorties, mais sur une observabilité profonde des trajectoires de raisonnement et des chaînes d'exécution pour détecter toute dérive comportementale. Enfin, une gestion stricte du cycle de vie est indispensable pour prévenir l'émergence d'agents zombies : ces entités abandonnées, conservant des droits d'accès valides, deviennent des points d'entrée durables pour les attaquants bien après leur fin d'utilité.
Menaces de “Pair-Clauding” - piratage de votre assistant de codage
Au-delà de l'environnement d'exécution et de la phase post-mortem, le processus de développement initial introduit lui-même des risques critiques. Les applications modernes alimentées par l'IA sont de plus en plus construites par des “développeurs augmentés par l'IA” qui s'appuient sur des assistants de codage tout au long du cycle de vie du logiciel. Bien que ces outils accélèrent sans aucun doute la productivité, ils étendent également la surface d'attaque au-delà de l'application déployée c’est à dire jusqu'au poste de travail du développeur et à l'environnement d'ingénierie. En plus de cibler le chatbot, les attaquants peuvent désormais influencer ou compromettre les systèmes utilisés pour le construire, le maintenir et le déployer. Les assistants de codage d'IA opèrent souvent avec un large accès à l'environnement local du développeur, créant des opportunités de fuite de secrets impliquant des variables d'environnement, des jetons API, des clés SSH, des configurations Kubernetes, des identifiants cloud ou d'autres actifs sensibles. La propriété intellectuelle - y compris le code source propriétaire, les décisions architecturales et les fonctionnalités non publiées - peut également être exposée par un partage de contexte involontaire ou une manipulation malveillante.
Les risques s'étendent davantage lorsqu'un attaquant réussit à influencer l'assistant de code lui-même. Des instructions cachées intégrées dans des repositories de code sources, de la documentation ou des fichiers apparemment anodins peuvent manipuler l'assistant pour qu'il génère du code dangereux ou exécute des actions imprévues. Dans des scénarios plus graves, cela ouvre la porte à l'exécution de code arbitraire, permettant aux attaquants de prendre le contrôle de la machine du développeur, d'exécuter des commandes, de modifier des projets locaux ou d'établir une persistance au sein de l'environnement de développement.
Parce que ces assistants possèdent fréquemment une connectivité réseau, les interactions compromises peuvent également permettre une exfiltration continue des données, transmettant silencieusement le code source, les identifiants, la documentation interne ou d'autres informations sensibles vers des systèmes externes. Alors que les assistants d'IA s'intègrent dans les processus d'ingénierie logicielle, la sécurisation de l'environnement de développement devient tout aussi essentielle que la protection de l'application d'IA elle-même, car la compromission de l'un ou l'autre peut finalement saper l'intégrité de l'ensemble du système.
Shadow AI - gagner ou perdre le contrôle ? (Ne vous tirez pas une balle dans le pied)
Inversement, une politique restrictive de “zéro tolérance” produit souvent l'effet opposé à celui recherché, poussant l'adoption de l'IA dans la clandestinité et créant un risque omniprésent de “Shadow AI”. Lorsque les développeurs se voient refuser l'accès aux assistants d'IA approuvés par l'entreprise, ils se tournent inévitablement vers des alternatives non approuvées - telles que des abonnements web personnels, des extensions de navigateur non autorisées ou des outils tiers ad hoc - pour maintenir leur productivité.
Cela crée un angle mort en matière de sécurité. En l'absence d'une gouvernance centralisée, d'une intégration de l'authentification unique (SSO) ou de mécanismes de prévention des fuites de données (DLP), les données sensibles de l'entreprise, les algorithmes propriétaires et la documentation interne sont intégrés aux ensembles de données d'entraînement de modèles publics, sans aucun contrôle ni supervision. Parce que ces outils “shadow” fonctionnent entièrement en dehors du périmètre de sécurité de l'organisation, les équipes de sécurité perdent toute visibilité sur les informations partagées, la provenance du code généré et le niveau de conformité des services externes utilisés. En définitive, interdire ces outils ne supprime pas le risque ; cela remplace simplement un risque visible et maîtrisable par un risque invisible et incontrôlable. Les organisations devraient donc abandonner les interdictions systématiques au profit de solutions d'IA sécurisées et approuvées, afin que la recherche d'une plus grande productivité des développeurs ne compromette pas, de manière involontaire, la posture de sécurité de l'entreprise.
Dépendance au fournisseur
Cercle vicieux de la manipulation mentale
Au-delà des menaces tangibles d'agents malveillants et le pillage de données d'entreprise, nous devons faire face à une réalité plus sombre : les modèles d'IA propriétaires sont des boîtes noires. Nous ne nous contentons pas de confier notre infrastructure à ces fournisseurs ; nous leur déléguons le pouvoir de structurer les flux d'informations qui orientent nos décisions stratégiques. Cette influence est profonde, façonnant subtilement les processus de pensée d'une manière que nous peinons à comprendre. Des études révèlent que le choix des mots affecte considérablement les opinions des gens et leur façon d'agir comme l'illustre la célèbre expérience sur les métaphores du crime (“bête” vs “virus”) : une simple substitution lexicale suffit à faire varier les approches proposées par les participants pour résoudre un problème complexe, sans même qu'ils s'en rendent compte.
Le discours humain étant plein de couleurs et de saveurs, et à l'exception des extrêmes de la communication scientifique “aride” qui troquent le plaisir pour la certitude, une expérience conversationnelle naturellement agréable est inatteignable sans que l'IA n'imite cette créativité linguistique. Pourtant, au sein d'un LLM, chaque mot choisi repose sur des poids probabilistes opaques. Par conséquent, ni un individu ni une multinationale ne peuvent discerner si ces paramètres restent structurellement vierges ou s'ils ont été subtilement calibrés par les fournisseurs pour servir un agenda non divulgué. Cela nous amène à l'un des points de douleur les plus pertinents d'aujourd'hui - la souveraineté de l'IA, dont nous avons discuté dans d'autres articles du blog OCTO.
Certains d'entre nous sont plus égaux que d'autres
Pourtant, il y a un autre problème dont il faut s'inquiéter. Outre l'accélération du rythme d'adoption, il y a aussi un taux d'obsolescence dû à l'émergence de modèles plus récents, plus grands et plus puissants, combinés à l'absence d'accès égalitaire. Je parie que vous avez entendu parler du Projet Glasswing n'offrant qu'à un nombre limité d'utilisateurs l'accès aux derniers modèles d'Anthropic. L'excuse générale est liée à la sécurité : des tiers de confiance sont chargés de tester les capacités de ces modèles avant que les pirates n'arrivent à en abuser, mais la question reste spéculative et crée un précédent troublant.
Et si les modèles sur lesquels vous comptez sont corrompus par conception ou si, pour une raison quelconque, votre fournisseur restreint votre accès ? La vigilance est de mise : privilégiez une approche aussi prudente que agnostique vis-à-vis des fournisseurs. Quelques réflexes essentiels : concevez des systèmes interopérables, facilitant la migration d'une infrastructure à une autre, et doublez vos garde-fous de tests comportementaux rigoureux. Gardez à l'esprit que les modèles open-source pourraient très prochainement égaler, voire dépasser, les solutions propriétaires.
À qui la responsabilité ?
Am, stram, gram
Comme évoqué dans notre analyse sur la surface d'attaque, la sécurité de l'IA représente plus qu'une évolution standard de la cybersécurité conventionnelle ; elle nécessite un passage de la programmation déterministe vers une expertise multidisciplinaire qui englobe la science des données, l'architecture LLM et l'agilité opérationnelle requise pour naviguer dans un paysage de menaces qui s'accélère. Est-ce que cela signifierait qu'un data scientist senior, ou ce que nous appelons aujourd'hui un expert en IA, pourrait garantir votre tranquillité ? La réponse est que ni un expert en cybersécurité ni un expert en IA ne peut servir de garde-fou contre les risques liés à l'IA. Mais à qui pourriez-vous déléguer ce fardeau ?
En même temps, personne ne semble vouloir endosser la responsabilité, les conséquences potentielles d'un échec sont tout simplement trop graves. Vous ne pouvez pas attendre de votre personnel technique qu'il accepte une telle responsabilité immense quand tant de choses pourraient mal tourner - parieriez-vous votre propre carrière là-dessus ? Le défi principal est donc d'aider vos équipes à surmonter leur appréhension et à transformer cela en un engagement collectif.
Manque de compréhension et mauvaise utilisation
Il est probable que la plupart de vos développeurs les plus brillants ne soient toujours pas à l'aise avec de la GenAI, peut-être même l'évitent-ils activement, alors que l'exploitation de son potentiel est le seul moyen de rester pertinent dans une ère de perturbations incessantes. Néanmoins, elle reste, à la base, un outil puissant. Comme un marteau, elle peut soit construire une maison, soit causer une blessure auto-infligée, selon la compétence de l'utilisateur. Ou, si vous préférez, voyez-la comme un avion : l'humanité a appris à voler, même si n’importe quel individu ne peut pas en piloter un - bien que ce soit une compétence qui peut être acquise. Renforcer l'expertise de votre équipe en matière de sécurité de l'IA par de petites étapes délibérées est bien préférable à rester sans défense face à ces risques.
Par quoi vous pourriez commencer aujourd'hui
Initier des audits récurrents :
Partenariat avec des consultants spécialisés pour obtenir une vue objective et de haut niveau de votre surface d'attaque - une première étape critique dans la définition de votre profil de risque.
Cultiver l'expertise interne :
Élever la compétence de votre équipe grâce à des formations pratiques et des bootcamps intensifs. Notre expérience avec des missions clients récentes montre que combler le déficit de compétences est le moyen le plus efficace de transformer l'appréhension en confiance opérationnelle.
Tirer parti de solutions commerciales matures :
Évaluer les garde-fous de sécurité existants pour déterminer comment ils s'alignent efficacement avec vos besoins architecturaux spécifiques. Pourtant, évitez une dépendance excessive : aucune solution unique ne peut traiter l'ensemble du terrain périlleux, et le rythme vif de l'innovation en IA rend les outils obsolètes presque aussi rapidement qu'ils sont déployés.
Concevoir une sécurité sur mesure :
Pour les infrastructures complexes et à enjeux élevés, collaborez avec des équipes d'ingénierie expérimentées pour développer des modules de sécurité sur mesure qui évoluent aux côtés de vos produits d'IA.
Maintenir la vigilance :
Consacrer des ressources pour rester au fait de l'évolution galopante du paysage des menaces - l'innovation en IA n'attend personne.
Intégrer la sécurité dès la conception :
Accélérer la maturité de votre équipe en adoptant tôt dans votre cycle de vie de développement des cadres de meilleures pratiques éprouvés, soutenus par des missions dirigées par des experts qui vous guident à travers la mise en œuvre.
Être proactif remplace l'anxiété par la capacité ; ces premières étapes garantissent que vos développeurs ne se contentent pas de s'adapter à la nouvelle réalité, mais la maîtrisent.
Points à retenir
Dépasser les frontières traditionnelles :
La sécurité de l'IA n'est pas seulement une extension de la cybersécurité classique. La transition d'applications déterministes vers des systèmes agentiques basés sur le RAG élargit fondamentalement votre surface d'attaque, nécessitant un passage vers une observabilité profonde et une analyse comportementale.
L'habilitation l'emporte sur l'interdiction :
La mise en œuvre de politiques de “zéro tolérance” restrictives se retourne souvent contre elles, obligeant les développeurs à contourner les contrôles de sécurité et créant des risques de “Shadow IA” incontrôlables. Des canaux sécurisés et gouvernés sont le seul moyen de maintenir la visibilité.
La sécurité est un engagement collectif :
Les risques associés à la GenAI sont trop complexes et à enjeux trop élevés pour être délégués à une seule équipe ou un seul individu. Le succès nécessite de favoriser une culture de responsabilité partagée au sein de votre organisation, des développeurs jusqu'à la direction.
Naviguer dans la boîte noire avec confiance :
Avec la dépendance croissante aux fournisseurs et les cadres législatifs changeants, la meilleure stratégie est de rester agnostique vis-à-vis du fournisseur et résilient. Construisez des systèmes conçus pour la migration et l'auditabilité.
Maîtriser la nouvelle réalité :
L'anxiété provient d'un manque de contrôle et de compréhension. Le moyen le plus efficace de sécuriser votre avenir en IA est de commencer à faire de petits pas délibérés - par des audits réguliers, une formation ciblée et une architecture de sécurité sur mesure - pour transformer l'appréhension de votre équipe en capacité opérationnelle.