Pendant longtemps, la cybersécurité reposait sur un déséquilibre assez simple : pour attaquer, il fallait des compétences rares, alors que les défenseurs pouvaient s'appuyer sur des équipes spécialisées, des correctifs et des procédures rodées. Avec l'IA, cette mécanique bouge. Elle peut aider à relire du code, à repérer des vulnérabilités et à automatiser certaines étapes d'une attaque. Elle peut aussi accélérer l'analyse des alertes et la correction de certaines failles. Le point clé, c'est que ces gains ne se traduisent pas automatiquement par une protection mieux répartie, ou plus efficace, partout.
Dans un entretien, Alex Stamos (spécialiste de la cybersécurité) décrit une période de transition où, très concrètement, les capacités offensives progressent plus vite que les moyens de défense de beaucoup d'organisations. Pas question, donc, d'imaginer un basculement immédiat vers des attaques « sans humains ». Le risque tient plutôt à trois choses : l'accélération du rythme, la baisse du niveau de compétence nécessaire pour certaines manœuvres, et le fait que des faiblesses déjà présentes dans les logiciels et les chaînes d'approvisionnement peuvent être exploitées plus vite.
Voici comment lire ce changement, où se situent les risques pour les entreprises françaises et européennes, et quelles décisions prendre - sans tomber dans le catastrophisme ni dans la promesse d'une défense automatique.
Ce que l'IA change réellement dans une cyberattaque
L'IA ne transforme pas automatiquement chaque attaquant en expert. Elle réduit surtout le temps et l'effort nécessaires pour certaines tâches, et elle permet à un opérateur de tester plus de pistes. Autrement dit : les intrusions ne deviennent pas « entièrement autonomes » partout, mais ce qui dépendait de la lenteur des adversaires ou de la rareté de certaines compétences devient moins fiable.
Une chaîne d'attaque qui s'accélère
Une attaque informatique suit souvent plusieurs étapes : trouver une cible, repérer une faiblesse, obtenir un accès, se déplacer dans le système, puis voler des données, perturber un service ou extorquer de l'argent. Cet enchaînement, on l'appelle souvent une chaîne d'attaque.
Avant l'IA générative, une partie du travail préparatoire consistait à fabriquer à l'avance des outils, puis à les déployer sur des cibles choisies. Les modèles d'IA peuvent aujourd'hui assister plusieurs étapes : analyse de code, reformulation d'informations techniques, génération de scripts, adaptation d'une tentative à un système particulier. Dans certains cas, des « agents » enchaînent des actions avec moins d'intervention humaine.
Cela ne veut pas dire que le modèle « comprend le monde » comme un professionnel chevronné. Ça veut surtout dire qu'une partie des opérations répétitives peut coûter moins cher et qu'il y a davantage d'essais possibles.
Pour une entreprise, le sujet revient souvent à une question de délai. Si une faille est repérée puis exploitée vite, le cycle classique - alerte, évaluation du risque, validation, déploiement d'un correctif - peut devenir trop lent. Un plan de mise à jour qui semblait acceptable il y a quelques années ne l'est pas forcément quand un attaquant peut tenter la faille dès sa publication.
Des compétences autrefois rares deviennent plus accessibles
La cybersécurité s'est organisée en niveaux de compétence : des utilisateurs d'outils existants, des développeurs capables de modifier des scripts, puis des spécialistes très pointus sur des vulnérabilités. L'IA « compresse » une partie de cette hiérarchie. Un opérateur moins expérimenté peut demander de l'aide pour comprendre un logiciel, ajuster un script ou interpréter une erreur.
La compétence ne disparaît pas pour autant. Les résultats demandent d'être vérifiés, les environnements sont rarement identiques, et une attaque réussie exige presque toujours un mélange de persévérance, de compréhension de la cible et d'erreurs humaines, parfois très banales. Mais il devient plus simple d'atteindre un niveau intermédiaire - et donc, le nombre d'acteurs capables de tenter des opérations autrefois réservées à des équipes spécialisées peut augmenter.
Et il faut aussi distinguer les profils. Une campagne de rançongiciel, une fraude par ingénierie sociale et une attaque contre une plateforme d'IA ne s'appuient pas forcément sur les mêmes acteurs ni sur les mêmes méthodes. L'IA est un accélérateur : elle n'explique pas à elle seule chaque incident.
Les fournisseurs peuvent transformer une faille locale en risque collectif
Les entreprises s'appuient sur des prestataires cloud, des bibliothèques open source, des services d'authentification, des outils de développement et des fournisseurs spécialisés. Une faiblesse chez un seul maillon peut avoir des effets en cascade, surtout si des clés d'API ou des identifiants sont réutilisés.
Le risque est particulièrement concret pour les PME et les entreprises de taille intermédiaire. Elles utilisent souvent les mêmes briques que les grands groupes, mais avec moins de spécialistes pour suivre les alertes, vérifier les dépendances et réagir en continu. Dans ce contexte, une intrusion chez un fournisseur peut finir par devenir un problème « chez vous », même si votre propre logiciel n'est pas à l'origine de la faille.
Pourquoi l'économie de la défense devient le vrai problème
Une attaque automatisée peut être répétée contre beaucoup de cibles. La défense, elle, doit tenir compte du contexte de chaque entreprise : quelles données sont sensibles, quels systèmes peuvent être stoppés, quels comptes sont légitimes, et quelles conséquences peut avoir une réponse trop brutale. Cet écart - attaque « massifiable » contre défense « contextuelle » - pèse lourd dans la cybersécurité assistée par l'IA.
La détection ne suffit pas : il faut aussi enquêter et agir
On investit souvent dans l'IA de sécurité pour détecter des signaux et corriger des vulnérabilités dans le code. C'est utile, mais la sécurité d'une organisation ne se résume pas à la qualité logicielle. Il faut aussi surveiller les journaux, décider si une alerte est réelle, contenir une intrusion et éviter qu'une réponse précipitée ne casse l'activité.
Dans beaucoup d'organisations, un SOC reçoit des volumes de données que les analystes ne peuvent pas examiner ligne par ligne. L'automatisation existe déjà : filtres, règles, modèles statistiques pour réduire le bruit. Les modèles de langage peuvent ensuite aider à résumer un incident ou à suggérer des pistes d'enquête.
Mais envoyer toutes les données vers un grand modèle a un coût, et ce n'est pas toujours pertinent techniquement. Le plus souvent, une architecture « raisonnable » combine plusieurs niveaux : des outils rapides trient les événements, puis un modèle plus avancé analyse les alertes jugées importantes. Et un analyste humain valide les décisions qui ont un fort impact. L'idée n'est pas de traiter chaque journal comme s'il fallait une conversation avec un modèle de premier rang : c'est de réserver les ressources coûteuses aux cas qui le méritent.
L'automatisation défensive doit avoir des limites explicites
Laisser un agent agir dans un réseau sans garde-fous, ce n'est pas une stratégie. Un outil qui désactive un compte ou bloque une machine peut limiter une intrusion, mais peut aussi interrompre une activité légitime. Dans un hôpital, une usine ou un service public, une mesure de confinement mal calibrée peut avoir des conséquences très concrètes.
Il faut donc définir à l'avance ce que le système peut faire seul. Par exemple : suspendre un compte suspect dans une limite donnée, mais demander l'accord d'un responsable avant de désactiver un grand nombre d'accès. Une fois le seuil atteint, l'outil doit passer la main à un humain au lieu de continuer. Ces limites doivent être testées, consignées dans des journaux, puis ajustées après chaque incident.
En pratique, cela implique un arbitrage : plus d'autonomie, c'est parfois plus de vitesse - mais aussi plus de risque d'erreur à grande échelle. L'autonomie est logique pour des actions réversibles et bien circonscrites. Pour les actions qui peuvent arrêter la production, effacer des données ou couper des services critiques, une validation humaine reste généralement nécessaire.
La cybersécurité est aussi une question de budget et de gouvernance
Le coût d'une solution de défense ne se résume pas au prix de la licence. Il faut compter la mise en place, la gestion des faux positifs, la supervision, et le temps nécessaire pour interpréter correctement les résultats. Une solution très performante mais trop chère à déployer partout ne protège pas réellement l'ensemble du parc.
Les dirigeants doivent aussi comparer le coût de la prévention au coût probable d'un incident : interruption de service, perte de revenus, frais de remise en état, obligations liées au RGPD, et atteinte à la confiance des clients. Cette comparaison n'efface pas l'incertitude, mais elle donne un cadre de décision. Attendre qu'un incident survienne pour financer une mesure, c'est souvent accepter un risque sans l'avoir vraiment évalué.
Faut-il corriger ou reconstruire les logiciels vulnérables ?
Corriger reste indispensable, mais ce n'est pas toujours l'option la plus économique pour un logiciel ancien. Un système qui cumule des milliers de vulnérabilités, manque de documentation et se teste mal peut coûter plus cher à maintenir que de le reconstruire. Avec l'IA, le calcul peut évoluer : elle peut réduire le temps nécessaire pour analyser et réécrire une partie du code. Mais elle ne rend pas une refonte « sans risque ». Il faut garder la même exigence de validation.
Comparer le coût du correctif au coût de la refonte
Avant de trancher, mesurez la fréquence des incidents, la gravité des failles, la disponibilité des compétences et la possibilité de vérifier le comportement actuel du logiciel. Une reconstruction devient crédible si l'équipe sait définir ce que le système doit faire, peut mettre en place des tests fiables et migrer par étapes, sans interrompre le service.
Vous pouvez aussi avancer par paliers : documenter les usages réels, écrire des tests autour des fonctions critiques, reconstruire un composant à la fois, puis comparer les résultats à l'ancien système. Certains langages plus « sûrs » (gestion de mémoire, vérifications de types) réduisent certaines catégories d'erreurs. Ils ne préviennent toutefois ni les failles logiques, ni les erreurs de configuration.
Un point souvent sous-estimé : le code hérité dont personne ne connaît vraiment toutes les dépendances. Réécrire sans tests ni plan de retour arrière peut remplacer des vulnérabilités visibles par des défauts nouveaux, parfois plus difficiles à détecter. L'IA peut aider à produire du code et à accélérer l'analyse, mais la responsabilité de définir le comportement attendu reste à l'organisation.
Mesurer les progrès avec des indicateurs utiles
Le nombre de correctifs publiés ne suffit pas pour dire que la sécurité s'améliore. Il faut suivre le délai entre la découverte d'une faille et son traitement, la durée pendant laquelle des vulnérabilités restent exposées, le temps de détection d'une intrusion et le temps de restauration d'un service. Il vaut aussi la peine de suivre la fréquence des incidents chez les fournisseurs critiques.
Côté technique, un indicateur utile est la part des systèmes critiques couverts par des tests de restauration récents. Côté direction, on peut regarder le nombre de services essentiels pour lesquels un responsable et un plan de continuité sont clairement identifiés. L'objectif est de relier la sécurité à la capacité réelle de l'entreprise à continuer à fonctionner.
Et il faut éviter une fausse bonne nouvelle : une hausse temporaire des vulnérabilités détectées ne signifie pas forcément une dégradation. De meilleurs outils peuvent simplement révéler des failles jusque-là invisibles. À l'inverse, une baisse des alertes peut refléter une surveillance moins efficace. Les tendances ont besoin de contexte : périmètre, volume de code et vitesse de correction.
À retenir : le gain ne revient pas à l'organisation qui « automatise tout », mais à celle qui réduit le temps entre la détection d'un problème, une décision fiable et une correction vérifiée.
Conclusion
L'IA ne rend pas la cybersécurité inutile : elle rend obsolètes certaines hypothèses de défense. Compter sur la rareté des compétences adverses, corriger à un rythme trop lent ou traiter chaque alerte manuellement devient de moins en moins viable. Dans le même temps, une défense entièrement autonome peut aussi créer ses propres incidents si les permissions ne sont pas clairement bornées.
La priorité, elle, reste très concrète : connaître ses actifs et ses dépendances, réduire les délais de correction, automatiser les tâches répétitives avec des garde-fous, et tester dans un périmètre maîtrisé. Pour des logiciels anciens, il faut parfois envisager une reconstruction, mais uniquement avec des tests et un plan de migration. L'objectif n'est pas d'atteindre une sécurité parfaite. C'est de rendre l'attaque plus difficile, la détection plus rapide et la reprise suffisamment fiable pour protéger l'activité.
Comment une entreprise peut adapter sa défense
Non, il ne suffit pas d'acheter un outil d'IA de plus et de considérer que le sujet est « réglé ». La démarche commence par comprendre ce qui est exposé, réduire les délais de réaction, puis vérifier si l'organisation résiste à une attaque réaliste. Pour une entreprise française ou européenne, il faut en plus tenir compte de la protection des données et de la continuité d'activité.
Commencer par les actifs et les dépendances
Un inventaire exploitable vaut mieux qu'une liste abstraite. Identifiez les services accessibles depuis Internet, les applications oubliées, les comptes privilégiés, les clés d'API et les fournisseurs dont l'indisponibilité bloquerait votre activité. Pour chaque élément, précisez qui en est responsable et comment le remettre en état.
Pour prioriser, quatre questions simples fonctionnent bien :
Les réponses orientent les efforts. Une application de test exposée par erreur, un administrateur partagé et une sauvegarde connectée en permanence ne créent pas les mêmes risques. Mais dans les trois cas, il y a un point commun : sans responsable identifié, rien ne sera traité sérieusement.
Organiser un test offensif encadré
Tester ses propres systèmes permet de repérer des faiblesses avant qu'un tiers ne les exploite. L'IA peut accélérer certains aspects des tests, mais elle ne supprime pas le risque d'interruption ni le risque de tomber sur des données réelles.
Avant un exercice de red team ou un test d'intrusion assisté par IA, fixez un périmètre précis : systèmes autorisés, plages horaires, données à ne pas toucher, procédure d'arrêt d'urgence, et contacts joignables. Si possible, lancez un premier essai en préproduction. Vérifiez aussi les clauses contractuelles, la conservation des données et la localisation des traitements. Le RGPD ne « s'efface » pas parce que le test est mené pour se défendre.
Le test doit aboutir à des actions : corriger une vulnérabilité, désactiver un accès, améliorer une alerte, ou revoir une procédure. Accumuler des rapports sans capacité de remédiation, au final, crée surtout une file d'attente.
Automatiser les tâches répétitives, pas le jugement entier
L'IA aide à résumer une alerte, rapprocher des événements, proposer une requête pour explorer des journaux ou générer une première version d'un correctif. Le résultat doit être vérifiable. Pour le code, ça implique des tests automatisés et une revue adaptée au niveau de risque. Pour les opérations de sécurité, ça implique une trace des décisions et un mécanisme de retour arrière.
Une règle pratique consiste à augmenter l'autonomie progressivement :
Cette progression permet de mesurer les faux positifs et les effets secondaires avant d'élargir les permissions. C'est plus lent qu'une activation globale, mais beaucoup moins risqué qu'un agent disposant d'un accès étendu à l'ensemble du réseau.