Google Cloud face à la guerre de l’IA : défendre sans tout automatiser

Les cyberattaques ne deviennent pas toutes, du jour au lendemain, des opérations pilotées par des intelligences artificielles autonomes. Pourtant, l’IA change déjà les conditions de la défense : elle aide à trier des alertes par milliers, à examiner du code et à résumer un incident. Dans le même temps, elle peut faciliter la rédaction de messages d’hameçonnage plus convaincants ou l’automatisation de tâches malveillantes. Pour Google Cloud, l’enjeu n’est donc pas simplement d’ajouter de l’IA à la cybersécurité, mais de savoir à quelles décisions elle peut contribuer sans devenir elle-même une nouvelle faille.

Lors d’une conférence à Singapour, Mark Johnston, directeur du bureau du CISO de Google Cloud pour la région Asie-Pacifique, a dressé un constat sévère. Malgré des décennies de progrès en informatique, nombre d’organisations découvrent encore leurs incidents de sécurité par l’intermédiaire d’un tiers : un client, un partenaire, un chercheur, un média ou parfois un attaquant. Cette difficulté à voir ses propres failles est au cœur de ce que les spécialistes appellent le dilemme du défenseur.

Des incidents souvent détectés trop tard

Le chiffre mis en avant par Mark Johnston concerne l’Asie et le Japon : 69 % des incidents de violation de données y sont signalés par des entités extérieures. Le périmètre précis et la période de collecte n’ont pas été détaillés dans cette présentation, mais ce constat illustre un problème fondamental : un dispositif de protection ne vaut pas seulement par sa capacité à bloquer une attaque. Il doit aussi permettre à une entreprise de repérer rapidement ce qui a échappé à ses contrôles.

L’autre donnée citée est tout aussi révélatrice. Plus de 76 % des violations débutent par des erreurs de configuration ou des compromissions de données d’identification. Une erreur de configuration peut, par exemple, rendre un service accessible alors qu’il devait rester interne, accorder des droits trop étendus ou laisser une option de sécurité inactive. La compromission d’identifiants recouvre quant à elle le vol d’un mot de passe, d’un jeton d’accès ou d’une session utilisateur.

Ces causes ne sont pas nouvelles. Mark Johnston rappelle un constat formulé dès 1972 par le spécialiste américain James B. Anderson : les systèmes informatiques ne se protègent pas eux-mêmes. Plus d’un demi-siècle plus tard, les logiciels, les services cloud et les appareils connectés se sont multipliés, mais la difficulté reste similaire. Les équipes de sécurité doivent savoir exactement quels actifs elles protègent, qui y accède et quels changements peuvent fragiliser l’ensemble.

Comment l’IA change-t-elle l’affrontement entre attaquants et défenseurs ?

Kevin Curran, membre senior de l’IEEE, décrit le contexte comme une course aux armements technologique. Les deux camps disposent d’outils d’IA, mais ne les emploient pas nécessairement de la même façon.

Côté défense, l’intérêt est d’abord une question d’échelle. Les infrastructures numériques génèrent des journaux d’activité en continu : connexions, transferts de fichiers, changements de privilèges, exécutions de programmes, alertes réseau. Aucun analyste ne peut lire manuellement tous ces signaux. Un système entraîné à repérer des anomalies peut aider à faire remonter les événements qui méritent une enquête, à relier plusieurs alertes entre elles et à accélérer la rédaction d’un rapport d’incident.

Côté attaque, les mêmes gains de productivité peuvent être détournés. L’IA générative peut assister la production de contenus d’hameçonnage plus personnalisés, réduire les barrières linguistiques ou automatiser certaines étapes de création de logiciels malveillants. Un courriel frauduleux bien formulé, adapté au vocabulaire d’une entreprise et envoyé au bon moment a davantage de chances de tromper son destinataire qu’un message générique mal écrit.

Pour autant, Mark Johnston précise qu’aucune attaque innovante utilisant l’IA n’avait été observée dans le cadre évoqué lors de son intervention. Ce point invite à distinguer deux réalités. L’IA peut déjà augmenter la vitesse, le volume ou la qualité apparente d’opérations existantes. Cela ne signifie pas automatiquement que les attaquants disposent d’une méthode entièrement inédite, capable de contourner seule toutes les protections.

Big Sleep, l’IA appliquée à la recherche de vulnérabilités

L’une des promesses les plus concrètes avancées par Google concerne la découverte de failles dans le code. Le projet Big Sleep utilise des modèles de langage à grande échelle pour examiner des logiciels et identifier des vulnérabilités potentielles. Selon les éléments présentés par Google, l’initiative a récemment permis de découvrir plus de 47 vulnérabilités.

La recherche de vulnérabilités est un travail long. Il consiste à comprendre comment un programme traite les données qu’il reçoit, quelles vérifications il réalise et dans quelles circonstances il peut se comporter de façon inattendue. Une faille peut permettre de provoquer un blocage, de contourner une restriction ou, dans les cas les plus graves, d’exécuter du code non autorisé. Les outils fondés sur l’IA peuvent assister l’examen de très grands volumes de code, proposer des pistes d’analyse et repérer des combinaisons que les équipes n’auraient pas priorisées.

Mais une vulnérabilité trouvée par un modèle n’est pas automatiquement une vulnérabilité exploitable. Elle doit être vérifiée, comprise, reproduite dans des conditions sûres puis corrigée. C’est pourquoi l’IA s’inscrit davantage comme un accélérateur du travail des équipes de sécurité que comme un remplacement du chercheur ou de l’ingénieur.

Google Cloud voit également des usages dans le tri des alertes, la détection d’anomalies, l’investigation et la réponse aux incidents. Le bénéfice attendu est particulièrement clair pour les organisations confrontées à des contraintes budgétaires et à une pénurie de temps : faire accomplir aux machines les tâches répétitives afin que les spécialistes se concentrent sur les décisions les plus délicates.

Une automatisation en quatre étapes, pas un basculement immédiat

La feuille de route décrite par Google Cloud découpe l’évolution des opérations de cybersécurité en quatre niveaux. Elle ne présente pas l’autonomie comme un état binaire, mais comme une progression qui exige de nouveaux garde-fous à chaque palier.

Dans la phase semi-autonome, une IA pourrait par exemple contribuer à regrouper des alertes similaires, préparer un compte rendu ou mener des vérifications préliminaires. En revanche, désactiver un service essentiel, bloquer un compte stratégique ou modifier des règles d’accès à grande échelle sont des actions susceptibles de perturber une activité. Elles nécessitent un contexte métier qu’un système automatisé ne possède pas toujours.

Pourquoi les outils d’IA doivent aussi être sécurisés

Le paradoxe est au centre de la stratégie. Un assistant de sécurité peut aider à protéger une entreprise, mais il devient aussi un composant à protéger. S’il est manipulé, mal paramétré ou alimenté avec des données inadaptées, il peut produire une réponse erronée, divulguer une information sensible ou orienter une action dans la mauvaise direction.

Mark Johnston souligne notamment le risque d’une dépendance excessive aux systèmes automatisés. Une organisation qui accepterait sans vérification toutes les recommandations d’un outil d’IA s’exposerait à des erreurs de jugement, y compris lorsque le système semble très convaincant. Dans le domaine de la sécurité, une réponse rapide mais inexacte peut avoir un coût élevé : effacement de preuves, interruption inutile d’un service ou oubli d’un véritable indicateur de compromission.

Google Cloud cite Model Armor comme une couche de filtrage destinée à contrôler les entrées et les sorties des systèmes d’IA. L’objectif est de repérer des informations sensibles et de maintenir les réponses dans le cadre attendu par l’entreprise. Mark Johnston donne l’exemple d’un magasin de détail qui recevrait des conseils médicaux de la part de son système : même si le contenu n’est pas nécessairement malveillant, il est hors sujet, potentiellement risqué et inadapté à l’activité concernée.

Cette question de pertinence compte autant que la détection de contenus dangereux. Une IA intégrée à un environnement professionnel doit répondre à une tâche définie, avec des données autorisées et des règles explicites. Elle ne doit pas devenir une porte d’entrée vers des informations qu’un utilisateur n’aurait pas dû consulter, ni un canal capable d’exécuter une action sans contrôle suffisant.

La pression économique pousse à rechercher des gains rapides

Les responsables de la sécurité des systèmes d’information de la région Asie-Pacifique font face à une équation difficile : les attaques se multiplient, les volumes d’alertes augmentent et les budgets ne suivent pas toujours la même trajectoire. Recruter massivement des experts n’est pas une réponse disponible pour toutes les organisations.

C’est dans ce contexte que les fournisseurs de cloud mettent en avant l’IA. L’ambition est d’accélérer les tâches de surveillance et d’enquête sans augmenter proportionnellement les effectifs. Une assistance efficace peut réduire le temps consacré à la rédaction de rapports d’incident ou à la recherche d’informations dispersées dans différents outils.

Mark Johnston relève néanmoins une limite importante : la vitesse obtenue ne garantit pas la précision. Un résumé d’incident rédigé plus vite reste inutile, voire dangereux, s’il contient une interprétation inexacte. Les indicateurs produits par l’IA doivent donc être confrontés aux données techniques, au contexte de l’entreprise et à l’expérience des analystes.

La réussite ne se mesurera pas au nombre de fonctionnalités d’IA déployées. Elle dépendra de critères plus concrets : diminution du délai de détection, réduction du temps de réponse, qualité des investigations, maîtrise des faux positifs et capacité à éviter les interruptions inutiles. Une automatisation qui génère davantage d’alertes imprécises peut au contraire épuiser les équipes qu’elle devait aider.

La cryptographie post-quantique, une préparation pour le long terme

Google Cloud prépare aussi une menace qui ne relève pas directement de l’IA générative : l’informatique quantique. Les ordinateurs quantiques suffisamment puissants pourraient, à terme, fragiliser certains mécanismes cryptographiques utilisés aujourd’hui pour protéger des échanges et des données.

La réponse envisagée est la cryptographie post-quantique, c’est-à-dire l’adoption d’algorithmes conçus pour résister à ce risque potentiel. Mark Johnston indique que Google Cloud a déjà déployé, à grande échelle, des protocoles de cryptographie post-quantique entre ses centres de données.

Cette anticipation obéit à une logique de prudence. Certaines données doivent rester confidentielles pendant longtemps : informations industrielles, données personnelles, contrats ou secrets commerciaux. Même sans menace quantique immédiate connue, des données chiffrées aujourd’hui pourraient intéresser un acteur capable de les conserver en espérant les déchiffrer à l’avenir. Préparer les infrastructures prend du temps, car la cryptographie est intégrée à de nombreux logiciels, équipements et procédures.

Ce qu’il faut surveiller

La promesse de Google Cloud est claire : rendre aux défenseurs une partie de l’avantage perdu face à l’ampleur des systèmes à surveiller. Big Sleep illustre le potentiel de l’IA dans la recherche de vulnérabilités, tandis que Model Armor cherche à limiter certains risques propres aux modèles génératifs. L’automatisation peut également alléger une charge opérationnelle devenue difficile à absorber.

Mais les fondamentaux ne disparaissent pas. Les chiffres cités par Mark Johnston rappellent que les erreurs de configuration et les identifiants compromis demeurent des points d’entrée majeurs. Avant d’envisager une cybersécurité autonome, les organisations doivent maîtriser leurs accès, mettre à jour leurs systèmes, vérifier leurs réglages et savoir détecter elles-mêmes un incident.

La question décisive n’est donc pas de savoir si l’IA remplacera les équipes de cybersécurité. Elle est de déterminer quelles tâches lui confier, quelles données elle peut consulter, quelles actions elle peut entreprendre et à quel moment un humain doit reprendre la main. Dans cette guerre technologique, la meilleure défense ne sera pas l’automatisation maximale, mais une automatisation mesurée, vérifiable et intégrée à une gouvernance solide.