L’IA générative n’est pas en train de rendre les attaques totalement autonomes. En revanche, elle change déjà quelque chose de très concret : la vitesse, l’échelle et l’accessibilité de certaines opérations offensives. Elle change aussi la manière dont les entreprises exposent leurs données, ouvrent des connecteurs, distribuent des droits et ajoutent de nouvelles couches à leur système d’information.
Pour les équipes techniques, le sujet n’est donc plus seulement “faut-il utiliser l’IA générative ?”, mais “où l’utiliser, sur quel périmètre, et avec quels garde-fous d’architecture et d’exploitation ?”.
Le mauvais diagnostic serait de surestimer la magie
La synthèse publiée par l’ANSSI début février 2026 est utile parce qu’elle évite deux excès. Le premier serait de considérer l’IA générative comme un gadget sans impact réel sur la menace. Le second serait de croire qu’elle permet déjà à elle seule de mener des cyberattaques complètes, de bout en bout, sans compétence humaine.
La situation actuelle est plus simple, et plus intéressante.
L’IA générative n’a pas supprimé le besoin d’expertise chez les attaquants. En revanche, elle leur apporte un gain clair sur plusieurs étapes : profilage de cibles, production de contenus d’ingénierie sociale, génération ou adaptation de code, industrialisation de certaines tâches, apprentissage accéléré pour les profils moins expérimentés.
Autrement dit, elle ne remplace pas la maîtrise offensive. Elle améliore la productivité de ceux qui l’ont déjà, et abaisse partiellement le seuil d’entrée pour d’autres.
Ce qui change vraiment, au-delà du seul sujet cyber
Pour les équipes techniques, il faut éviter de penser “attaque autonome” et raisonner plutôt en “attaque augmentée”. Aujourd’hui, l’IA générative sert surtout à produire plus vite des variantes de messages d’hameçonnage adaptées à un secteur, une fonction ou un contexte précis. Elle aide à écrire, relire ou transformer du code offensif. Elle accélère le tri et l’exploitation d’informations collectées en amont. Elle fait gagner du temps à des acteurs déjà organisés.
Ce point est important, parce qu’il déplace la réponse technique.
Si l’on croit que la menace principale est un “robot pirate autonome”, on prépare mal l’organisation. Si l’on comprend que le vrai sujet est l’accélération, la personnalisation et le passage à l’échelle, on commence à poser de meilleures questions d’architecture et de gouvernance. Qu’est-ce qui permet à un attaquant de personnaliser rapidement ses approches chez nous ? Quelles données exposons-nous trop facilement ? Où notre traçabilité est-elle insuffisante ? Et surtout, quels usages internes de l’IA pourraient créer une nouvelle voie d’exfiltration ou de compromission ?
L’IA devient aussi une nouvelle couche du SI à maîtriser
C’est l’autre intérêt de la synthèse de l’ANSSI. L’IA générative n’est pas seulement un outil que les attaquants peuvent détourner. Elle devient aussi, en tant que système, une nouvelle couche à gouverner dans le SI.
Dès qu’une entreprise déploie un assistant interne, un copilote de code, un moteur de recherche enrichi par un LLM ou un agent connecté à des bases documentaires, elle ajoute une couche nouvelle dans son système d’information. Et cette couche doit être pensée comme le reste : droits, flux, journalisation, responsabilités, maintien en condition.
Concrètement, les risques ne se limitent pas à une “mauvaise réponse” du modèle. Ils portent aussi sur :
- l’exfiltration de données via les prompts, les sorties ou les connecteurs ;
- l’empoisonnement de données ou de connaissances injectées dans le système ;
- la compromission de la chaîne logicielle du modèle, de ses dépendances ou de ses composants d’orchestration ;
- les contournements de garde-fous ;
- l’accès excessif d’un assistant à des ressources qu’il ne devrait jamais voir ;
- les effets de bord d’une automatisation trop rapide sur des périmètres mal cartographiés.
Le point clé est là : un système d’IA générative n’est pas “hors SI”. Il est dans le SI. Il hérite donc des fragilités existantes, et il peut en créer de nouvelles. Ce n’est pas seulement un sujet de protection. C’est un sujet de lisibilité et de maîtrise de l’existant.
Là où beaucoup d’équipes se trompent
Dans la pratique, l’erreur la plus fréquente n’est pas technique au départ. Elle est architecturale.
Beaucoup d’organisations introduisent l’IA générative par l’usage : un assistant de rédaction ici, un copilote de code là, une base documentaire augmentée pour le support, un chatbot orienté client. Ces projets démarrent vite, souvent avec un POC convaincant en quelques jours.
Puis les équipes découvrent que ces usages supposent en réalité des décisions de fond. Quelles données l’outil peut-il voir ? Avec quels droits ? Sur quels environnements ? Avec quelle journalisation ? Avec quelle validation humaine ? Comment cloisonner les données publiques, internes, sensibles et réglementées quand un même assistant peut potentiellement accéder à toutes ?
Si ces questions sont traitées trop tard, le projet avance vite au début, puis ralentit brutalement dès que la sécurité, la conformité, l’exploitation ou l’architecture reprennent la main. C’est la même logique que sur la dette technique : ce qui paraît fluide au départ devient coûteux quand l’architecture n’a pas été pensée.
Le vrai sujet : ne pas ajouter une couche opaque de plus
Pour beaucoup d’organisations, le risque principal n’est pas de “rater l’IA”. C’est d’ajouter une couche supplémentaire à un SI déjà difficile à lire.
Un assistant connecté à trop de sources, un copilote branché sur une base de code mal testée, un moteur de recherche transverse sans séparation claire des droits : tout cela peut donner une impression de gain rapide, tout en augmentant la dépendance, la confusion et le coût futur.
De ce point de vue, l’IA générative ne pose pas seulement un problème de sécurité. Elle révèle un niveau de maturité. La qualité de la cartographie, la propreté des droits, la séparation des périmètres, la qualité des journaux, la capacité à borner les usages et à reprendre la main quand le système se trompe : tout cela existait comme enjeu avant l’IA. L’IA le rend simplement plus visible et plus urgent.
Ce que les équipes techniques devraient faire maintenant
Le bon réflexe n’est pas de bloquer l’IA générative partout. Le bon réflexe est de classer les usages et de mettre les garde-fous au bon niveau.
1. Distinguer les cas d’usage par niveau de sensibilité
Tous les usages ne se valent pas. Un assistant de reformulation sur du contenu public n’a pas le même niveau de risque qu’un copilote branché sur du code propriétaire, qu’un moteur de recherche relié à des documents internes ou qu’un assistant connecté à des données clients.
La première décision n’est donc pas “quel modèle choisir ?”. C’est “quel usage autoriser sur quel périmètre ?”. En pratique, cela suppose de classifier les cas d’usage en niveaux (public, interne, confidentiel, réglementé) et de définir pour chaque niveau les conditions d’accès, de journalisation et de validation.
2. Cartographier les connecteurs et les données exposées
Dans beaucoup de projets, le risque n’est pas le modèle lui-même. Ce sont les ponts qu’on lui ouvre. Une GED, un wiki interne, des dépôts de code, un système de tickets, un CRM, des bases documentaires, des APIs métier : chaque connecteur est un chemin potentiel d’accès à des données sensibles. Une cartographie claire des sources consultées, des droits associés et des flux sortants devient indispensable dès le premier cas d’usage non trivial.
3. Encadrer les usages liés au code et à l’administration
Les assistants de code et les assistants opérationnels donnent vite un sentiment de gain. Mais sur un périmètre mal testé ou mal documenté, ils peuvent aussi accélérer la propagation de mauvais patterns, de configurations fragiles ou de décisions prises sans recul suffisant.
Le bon niveau d’usage n’est pas “laisser faire” ni “interdire”. C’est l’assistance sur des périmètres bornés, avec revue humaine systématique, journalisation des interactions, et séparation claire entre suggestion, validation et exécution. Sur du code, cela signifie par exemple autoriser la complétion et la documentation, mais imposer une revue humaine avant tout merge, et interdire l’exécution automatique de commandes système.
4. Traiter la chaîne logicielle de l’IA comme une vraie supply chain
Modèles, bibliothèques, frameworks d’orchestration, plugins, connecteurs, couches d’inférence, services tiers : tout cela constitue une chaîne logicielle. Elle doit être gouvernée comme telle, avec un inventaire à jour, un suivi des dépendances et de leur provenance, une politique de mises à jour, une surveillance des vulnérabilités et un plan de remplacement en cas de défaillance d’un composant critique.
5. Tester des scénarios d’abus, pas seulement la qualité des réponses
Beaucoup d’équipes testent la pertinence des réponses, le taux d’hallucination, la qualité de la recherche et la satisfaction utilisateur. C’est nécessaire, mais insuffisant.
Il faut aussi tester la remontée d’informations non autorisées (un utilisateur standard peut-il obtenir des données auxquelles il n’a normalement pas accès via l’assistant ?), les contournements de garde-fous par injection de prompt, les effets d’un corpus empoisonné, les entrées malveillantes injectées dans des documents récupérés par le système, et les comportements inattendus quand l’agent agit via un connecteur ou un outil externe.
6. Prévoir des zones interdites
Certaines données, certains actes ou certaines fonctions ne devraient tout simplement pas être exposés à un système d’IA générative, même avec des garde-fous.
Le plus dur, dans beaucoup d’organisations, n’est pas de définir ce qu’on veut faire avec l’IA. C’est de définir clairement ce qu’on refuse de lui confier.
Ce que cela change pour les décideurs techniques
Pour un CTO, un RSSI, un responsable architecture ou plateforme, la question n’est plus seulement “avons-nous une stratégie IA ?”. La bonne question est plutôt : notre usage de l’IA générative est-il classé, borné et gouverné ? Savons-nous quels systèmes, quelles données et quels connecteurs sont réellement exposés ? Avons-nous défini des cas d’usage interdits ? Avons-nous prévu des revues de sécurité spécifiques aux composants IA ?
En 2026, la maturité ne se verra pas au nombre de copilotes déployés. Elle se verra dans la capacité à utiliser l’IA générative là où elle crée vraiment de la valeur, sans l’introduire comme une couche opaque de plus dans un SI déjà difficile à maîtriser.
Conclusion
L’IA générative ne rend pas les fondamentaux obsolètes. Elle les rend plus visibles. Architecture, cartographie, droits, traçabilité, cloisonnement : tout ce qui était déjà nécessaire devient critique quand un nouveau composant autonome entre dans le SI.
Les équipes qui maîtrisent déjà leur existant intégreront l’IA plus vite et plus sûrement que celles qui empilent une couche de plus sur un système qu’elles ne lisent déjà plus.
Vous déployez de l’IA générative en interne et vous voulez structurer les garde-fous dès le départ ? Nous accompagnons les équipes techniques sur ces sujets : confiance numérique et développement logiciel. Parlons-en.