Rançongiciel et IA : l’alerte britannique pour 2028
Le NCSC britannique juge très probable une attaque par rançongiciel assistée par l’IA d’ici 2028. Ce que les entreprises doivent renforcer dès maintenant.
Rançongiciel et IA : pourquoi les infrastructures critiques doivent se préparer à 2028
Une attaque par rançongiciel contre une infrastructure critique, en partie facilitée par l'intelligence artificielle, est jugée « hautement probable » d'ici 2028 par le Centre national britannique de cybersécurité, le NCSC. Cette anticipation ne veut pas dire que l'IA aurait créé une nouvelle forme d'attaque. Elle pointe surtout un changement d'échelle : des failles déjà connues (et parfois trop longtemps tolérées) peuvent être repérées et exploitées plus vite.
Pour les entreprises, l'enjeu n'est pas de courir après chaque nouvel outil d'IA que des attaquants pourraient utiliser. La vraie question est plus simple (et plus dure) : est-ce que vos systèmes peuvent empêcher une intrusion de se transformer en incident majeur ? Est-ce qu'ils peuvent limiter la propagation et maintenir les services essentiels quand ça tourne mal ? Le risque vise en premier les opérateurs d'énergie, de transport, de santé et de télécommunications, mais il retombe aussi sur leurs fournisseurs et sur toutes les organisations qui dépendent de leurs services. Voici ce que dit l'alerte britannique, pourquoi elle mérite l'attention, et comment la traduire en décisions de sécurité concrètes - sans confondre prévision et certitude.
Que signifie l'alerte du NCSC sur l'IA et les rançongiciels ?
Dans son rapport annuel 2026 sur l'état de la cybermenace, le NCSC britannique estime qu'il est « hautement probable » que, dans les deux années à venir, des acteurs hostiles utilisent davantage l'IA pour augmenter l'échelle et l'efficacité de leurs opérations. L'agence cite les rançongiciels, l'ingénierie sociale et l'exploitation de vulnérabilités logicielles. Le NCSC est rattaché au GCHQ, le service britannique de renseignement électromagnétique.
La nuance est essentielle. Le NCSC ne prédit pas une attaque précise à une date donnée, ni un scénario où une IA piloterait seule une opération de bout en bout. Il décrit plutôt une évolution probable des capacités des attaquants et insiste sur la préparation. « Hautement probable » reste donc une appréciation du risque, pas une certitude opérationnelle.
Le problème central : des failles déjà présentes
Le directeur général du NCSC, Richard Horne, l'a dit clairement : l'IA ne crée pas forcément de nouvelles méthodes d'attaque. Elle peut rendre plus rapide la découverte de faiblesses existantes, puis faciliter leur exploitation à une échelle difficile à atteindre sans moyens humains importants. Il a aussi pointé des années d'investissements insuffisants - résumées par l'expression « la technologie à bas coût ».
Cette distinction évite une erreur de diagnostic. Si un service exposé sur Internet utilise un composant vulnérable, si les accès sont trop permissifs ou si les systèmes ne sont pas segmentés, le problème de fond n'est pas « l'IA ». L'IA peut néanmoins accélérer la reconnaissance des cibles, automatiser certaines tâches et aider à trouver des chemins d'accès exploitables.
Une prévision à prendre au sérieux, pas au pied de la lettre
Une alerte de menace sert à orienter les investissements et les scénarios de préparation. Elle ne permet pas de conclure qu'une attaque majeure est inévitable, ni que toutes les entreprises seront exposées de la même façon. Le niveau de risque dépend de la valeur des services, de l'exposition réelle, de la qualité des protections et de la capacité à rétablir l'activité.
Le gouvernement britannique a annoncé 60 millions de livres pour la première phase d'un Cyber Shield national et 70 millions pour créer un centre dédié à l'identification des vulnérabilités dans les systèmes critiques. Il est aussi question d'installer à Manchester un centre d'excellence en cybersécurité de l'IA. Ces mesures montrent que le sujet est traité comme une question de résilience nationale, pas uniquement comme un problème de logiciels malveillants.
Pour les organisations françaises et européennes, la leçon n'est pas de copier mot pour mot les dispositifs britanniques. Elle consiste plutôt à vérifier que la sécurité des systèmes indispensables à l'activité a un responsable, un budget, et surtout un plan de continuité vraiment testé.
Pourquoi les infrastructures critiques sont-elles vulnérables ?
Une infrastructure critique ne se limite pas à un grand centre de données. Elle peut inclure des systèmes industriels, des réseaux de distribution, des plateformes de gestion et des prestataires indispensables. L'interruption d'un service numérique peut provoquer des conséquences physiques ou économiques : retards de transport, difficulté d'accès aux soins, rupture de production ou perturbation d'un service public.
La complexité est souvent héritée. Les organisations font fonctionner des équipements conçus à des périodes différentes, maintiennent des systèmes difficiles à arrêter et coordonnent plusieurs fournisseurs. Sur le papier, une mise à jour de sécurité paraît simple. En pratique, elle peut exiger des tests, une fenêtre d'arrêt, une validation métier et un plan de retour arrière.
Les connexions inutiles élargissent la surface d'attaque
Le NCSC recommande notamment d'éviter de connecter inutilement des systèmes à Internet. C'est particulièrement vrai quand des équipements opérationnels, des interfaces d'administration ou des environnements de test sont accessibles depuis l'extérieur sans justification claire.
Cela ne veut pas dire que tout doit être déconnecté. La maintenance à distance, la supervision et les échanges avec des partenaires répondent à des besoins réels. Mais chaque connexion doit avoir un propriétaire, une finalité, une authentification solide et un mécanisme de révocation. Une exception temporaire pour dépanner un équipement ne doit pas devenir une porte d'entrée durable faute de suivi.
La dépendance aux fournisseurs fait partie du risque
Même avec de bonnes pratiques internes, une entreprise peut rester exposée à cause d'un prestataire qui administre ses systèmes, héberge une application ou fournit un composant largement utilisé. Le risque dépend alors de la façon dont les accès tiers sont accordés, surveillés et supprimés, ainsi que de la rapidité de correction des vulnérabilités.
Pour les opérateurs, ce sujet ne s'arrête pas aux contrats. Il faut savoir quels services essentiels dépendent de quels fournisseurs et quelles solutions existent si l'un d'eux ne répond plus. Une cartographie parfaite est rarement réaliste. En revanche, une cartographie des dépendances les plus critiques, tenue à jour, aide déjà à mieux décider pendant un incident.
La conformité est un seuil, pas une garantie
Le NCSC recommande de considérer la certification Cyber Essentials comme un point de départ, pas comme une fin. Côté entreprises françaises, le message est le même : passer un cadre ou réussir un audit ne prouve pas, à lui seul, que l'activité peut continuer après une attaque.
Le RGPD impose des obligations importantes pour protéger les données, mais il ne remplace pas un plan de réponse aux rançongiciels. De la même façon, une politique de sécurité bien rédigée ne suffit pas sans vérification des sauvegardes, exercices de crise et capacité à opérer en mode dégradé. La conformité structure le travail ; elle ne garantit pas le résultat.
Que doivent faire les organisations dès maintenant ?
Le plus utile consiste à traiter la menace comme un sujet de continuité d'activité. Il ne s'agit pas de deviner exactement la prochaine technique d'attaque. Il s'agit de réduire ce qui rend une intrusion rentable et de limiter les dégâts si elle réussit.
Commencez par les services dont l'arrêt coûterait le plus cher : production, paiement, relation client, données de santé, logistique, ou fonctions de sécurité. Cette priorisation évite de disperser le budget dans des listes interminables de risques sans ordre de priorité.
1. Identifier les systèmes qui ne peuvent pas s'arrêter
Établissez une liste courte des services indispensables, avec leurs propriétaires, leurs dépendances techniques et les équipes capables de les remettre en état. Pour chaque service, posez trois questions : combien de temps d'indisponibilité est acceptable ? Quelles données doivent être récupérées en priorité ? Quelles procédures manuelles ou dégradées peuvent prendre le relais ?
Ne cherchez pas d'abord l'inventaire parfait de tout le système d'information. Une vue fiable des fonctions critiques et de leurs dépendances vaut mieux qu'un catalogue exhaustif que personne ne maintient. Elle aide à décider où appliquer des contrôles plus stricts et qui mobiliser en premier.
2. Réduire les accès et l'exposition
Passez en revue les services accessibles depuis Internet, les comptes d'administration, les accès à distance et les privilèges accordés aux prestataires. Supprimez les comptes inutilisés, renforcez l'authentification pour les accès sensibles et limitez les droits à ce qui est nécessaire.
La segmentation des réseaux doit empêcher qu'une compromission locale donne immédiatement accès à tout l'environnement. Cette approche demande souvent un travail d'architecture et des arbitrages avec les équipes opérationnelles. Elle reste plus efficace qu'une simple séparation "sur le papier", sans contrôle technique ni tests réguliers.
3. Rendre les sauvegardes réellement exploitables
Une sauvegarde n'est utile que si elle peut être restaurée et si l'attaquant ne peut pas la supprimer avec les mêmes identifiants que ceux utilisés pour compromettre le réseau. Protégez les copies, séparez les accès et testez la restauration des services prioritaires - pas uniquement la récupération d'un fichier isolé.
Mesurez aussi le temps nécessaire pour remettre en service un processus important. Si l'entreprise vise une reprise en quelques heures mais découvre, lors d'un exercice, que les dépendances et validations prennent plusieurs jours, cette réalité doit remonter à la direction. Ce n'est pas un détail technique : c'est un arbitrage de continuité.
4. Répéter la réponse à incident
Organisez un exercice réunissant les équipes informatique, sécurité, juridique, communication et les métiers. Le scénario doit inclure des décisions concrètes : qui isole un réseau, qui prévient les clients, comment les opérations continuent et qui valide une communication publique.
Un bon exercice met en évidence les dépendances et les zones de responsabilité floues. Il ne sert pas à prouver que le plan "fonctionne déjà". Après l'exercice, attribuez chaque action à un responsable avec une échéance, puis vérifiez que les corrections ont été faites.
5. Financer les risques visibles, pas seulement de nouveaux outils
L'appel du NCSC à mettre fin à la « technologie à bas coût » ne veut pas dire acheter plus de produits de sécurité. Il veut dire financer correctement les fonctions de base : mises à jour, maintenance, surveillance, compétences, segmentation et capacité de restauration.
Pour chaque investissement, formulez le risque réduit et la preuve attendue. Par exemple : moins de services exposés à Internet doit conduire à une liste vérifiée des services réellement exposés ; des sauvegardes renforcées doivent être validées par un test de restauration réussi. Cette façon de faire aide la direction à arbitrer, et évite de confondre dépense logicielle et réduction effective du risque.
Conclusion : traiter la résilience comme une décision de direction
L'alerte britannique ne dit pas que l'intelligence artificielle rendrait les cyberattaques impossibles à contenir. Elle souligne plutôt qu'avec des outils plus efficaces, des faiblesses tolérées depuis longtemps peuvent devenir des risques plus immédiats. Dans la pratique, ce qui pèse le plus reste souvent l'état réel des systèmes, la gestion des accès et la capacité à contenir puis réparer une compromission.
Pour une organisation française ou européenne, la priorité est donc de relier cybersécurité et continuité d'activité : identifier les services essentiels, réduire les expositions inutiles, protéger les sauvegardes et tester les scénarios de crise. La question à poser au comité de direction n'est pas seulement « sommes-nous conformes ? ». C'est « que pouvons-nous encore faire si un système critique est indisponible demain ? »
Comment l'IA peut-elle accélérer une cyberattaque ?
L'IA peut automatiser des tâches qui prenaient avant du temps, demandaient des compétences spécifiques ou mobilisaient beaucoup de ressources. Dans une attaque, cela peut concerner la collecte et le tri d'informations, la rédaction de messages de phishing adaptés au contexte et au destinataire, ou l'analyse de logiciels pour repérer des erreurs exploitables. Ces usages ne rendent pas automatiquement une attaque « plus avancée » au sens technique, mais ils peuvent diminuer son coût et accélérer certaines étapes.
Un rançongiciel n'est pas un événement unique : c'est une chaîne de phases. D'abord obtenir un accès, puis étendre les privilèges, atteindre les systèmes importants, perturber ou chiffrer les données, et enfin tenter d'obtenir une rançon. L'IA peut contribuer à plusieurs de ces étapes. La défense doit donc couvrir l'ensemble du parcours, pas chercher une solution unique façon « antivirus IA ».
Phishing plus convaincant, mais pas infaillible
Les outils génératifs peuvent produire rapidement des messages dans une langue fluide, ajuster le ton à un contexte professionnel et décliner un même scénario à grande échelle. Résultat : repérer un courriel frauduleux uniquement sur des fautes ou des formulations maladroites devient moins fiable.
Mais l'IA ne supprime pas les signaux de fraude. Une demande inhabituelle de paiement, un changement de coordonnées bancaires, une urgence destinée à contourner les validations : tout cela doit rester des déclencheurs de vérification via un canal indépendant. Les procédures internes priment sur des consignes vagues du type « faites attention ».
Recherche de vulnérabilités et automatisation
Le NCSC s'inquiète notamment de la capacité des acteurs hostiles à trouver et exploiter plus efficacement des failles logicielles. En mai, le Threat Intelligence Group de Google a indiqué avoir observé l'utilisation d'un modèle d'IA par des cybercriminels pour identifier et exploiter une vulnérabilité inconnue dans un outil d'administration open source, avec contournement de l'authentification à deux facteurs. Le groupe a présenté cet épisode comme un premier cas confirmé de zero-day « assisté par IA » dans la nature.
Ce signal mérite attention, mais il ne faut pas le transformer en conclusion générale : on n'a pas la preuve que chaque groupe criminel dispose déjà de capacités très avancées. À la même période, une étude de l'université de Cambridge, fondée sur plus de 90 000 discussions de forums cybercriminels, indiquait que la majorité des usages observés concernaient surtout du spam et du phishing plutôt que des attaques particulièrement sophistiquées.
Ces éléments ne se contredisent pas. Ils dessinent un paysage où les usages courants restent souvent simples, tout en voyant apparaître des cas plus avancés. Pour un responsable sécurité, cela plaide pour une préparation proportionnée : réduire les vulnérabilités connues et rendre les attaques plus difficiles à industrialiser.
L'IA défensive ne remplace pas une architecture solide
Les équipes de sécurité peuvent aussi utiliser l'IA pour trier les alertes, analyser des événements et accélérer certaines investigations. Cela peut réduire des délais. Mais ces outils ne remplacent ni la qualité des journaux, ni la séparation des environnements, ni la capacité à isoler un système compromis.
Un outil d'IA défensif mal intégré peut même créer de la dépendance, générer des alertes difficiles à vérifier ou exposer des données sensibles. La question utile n'est pas « avons-nous adopté l'IA ? ». C'est plutôt : « est-ce que cette utilisation réduit vraiment un délai ou un risque - et comment vérifie-t-on que ça marche ? »