L'essentiel en bref
- La gestion des risques par l'IA change ce qu'une fonction sécurité peut voir, pas qui en est responsable. Les chapitres 6.1.2 et 6.1.3 de l'ISO/IEC 27001:2022 exigent toujours des critères définis et une personne nommément responsable pour chaque décision de traitement.
- FIRST prévoit environ 66 000 CVE pour 2026, la première année en passe d'approcher les 70 000. Le catalogue des vulnérabilités activement exploitées de la CISA comptait 1 587 entrées au 1er mai 2026. Le goulot d'étranglement est la priorisation, pas la détection.
- L'ENISA a recensé 4 875 incidents dans l'UE entre le 1er juillet 2024 et le 30 juin 2025. Le hameçonnage constituait la voie d'accès dans 60 % des cas observés et l'exploitation d'une vulnérabilité dans 21,3 %.
- Dès le début de 2025, les campagnes de hameçonnage assistées par l'IA représentaient plus de 80 % de l'activité d'ingénierie sociale observée dans le monde. Les attaquants ont adopté l'IA plus vite que la plupart des fonctions de gestion des risques.
- L'article 9, paragraphe 2, du règlement européen sur l'IA définit le système de gestion des risques comme un processus itératif continu mené sur l'ensemble du cycle de vie d'un système d'IA à haut risque. Utiliser l'IA pour gérer le risque place ce système lui-même sous gouvernance.
Les limites de la gestion des risques traditionnelle
La gestion des risques traditionnelle est un exercice de calendrier. Une équipe rassemble des informations, les note selon la probabilité et l'impact, consigne le résultat, puis y revient six ou douze mois plus tard. Entre ces deux dates, les systèmes changent, les droits d'accès s'accumulent sans qu'on le remarque, des prestataires arrivent, et le paysage des menaces continue d'évoluer sans attendre le prochain cycle de revue.
La gestion des risques classique repose en général sur des évaluations annuelles ou trimestrielles, une collecte manuelle des données, une notation subjective appuyée sur quelques facteurs, un registre des risques statique et des réactions déclenchées une fois le problème survenu. Chacun de ces choix se défendait quand l'infrastructure évoluait lentement. Aucun ne résiste à un environnement qui change chaque semaine.
Les chiffres donnent la mesure de l'écart. Dans son panorama des menaces pour la période de juillet 2024 à juin 2025, l'Agence de l'Union européenne pour la cybersécurité a recensé 4 875 incidents dans l'UE. Le hameçonnage était la voie d'accès dans 60 % des cas observés, l'exploitation d'une vulnérabilité dans 21,3 %. Et 53,7 % des incidents concernaient des entités relevant du champ d'application de NIS2.
Aucune de ces trois valeurs ne se pilote sur un rythme annuel. Une vulnérabilité publiée en mars et exploitée en avril ne figure tout simplement pas dans un registre revu pour la dernière fois en janvier.
Une idée reçue mérite d'être corrigée ici, car elle structure beaucoup de discussions budgétaires : l'appréciation annuelle des risques n'est pas une exigence de la norme. Le chapitre 8.2 de l'ISO/IEC 27001:2022 demande des appréciations à intervalles planifiés et dès que des changements importants surviennent ou sont prévus. La seconde condition est la plus exigeante, et c'est elle qui justifie réellement un travail continu sur le risque. Les auditeurs lisent les deux moitiés de ce chapitre, même quand les entreprises n'en budgètent qu'une.
La gestion des risques par l'IA : un nouveau paradigme
La gestion des risques par l'IA déplace le travail de la collecte vers la décision. Cinq capacités expliquent l'essentiel de la différence, et elles se renforcent mutuellement : chacune est plus utile quand les autres sont en place.
Analyse automatisée des informations sur les menaces
Les informations sur les menaces arrivent dispersées : bases de vulnérabilités, avis d'éditeurs, journaux d'événements et état de configuration de vos propres systèmes. Un modèle peut rapprocher ces sources en continu et répondre à la seule question qui compte sur le plan opérationnel : cet avis concerne-t-il un système présent dans notre inventaire ? C'est sur cette corrélation que les procédures manuelles échouent, pas sur la notation qui suit.
L'asymétrie est réelle et joue actuellement contre les défenseurs. L'ENISA a constaté qu'au début de 2025, les campagnes de hameçonnage assistées par l'IA représentaient plus de 80 % de l'activité d'ingénierie sociale observée dans le monde. Les attaquants ont industrialisé l'IA avant que la plupart des fonctions sécurité aient terminé de l'évaluer.
Détection prédictive des risques
Les incidents passés, l'efficacité actuelle des mesures et les données de menace en temps réel permettent ensemble d'énoncer de façon défendable où la prochaine défaillance est probable. La valeur ne réside pas dans la prévision elle-même, souvent fausse au niveau d'un cas particulier. Elle réside dans l'ordre de traitement : savoir laquelle des 93 mesures de l'annexe A renforcer en premier quand vous ne pouvez en financer que trois.
Traitez les prévisions comme des hypothèses dotées d'un responsable et d'une date de revue, non comme des constats. Un risque prévu que personne n'a évalué n'est pas du renseignement sur le risque, c'est une file d'attente.
Surveillance continue des mesures
Au lieu de tests manuels périodiques, l'état des mesures est comparé en permanence à la configuration attendue :
- les configurations et les réglages des mesures sont vérifiés en continu, non par échantillonnage
- une mesure qui dévie apparaît au moment où elle dévie, non à la revue suivante
- les mesures techniques sont testées automatiquement partout où le test peut l'être
- l'état des mesures est consultable à la demande, non en fin de trimestre
C'est aussi le mécanisme qui fait des preuves d'audit un sous-produit de l'exploitation. Des preuves constituées en continu n'ont pas à être reconstituées la semaine précédant une évaluation, or c'est précisément là que passait jusqu'ici l'essentiel de l'effort de préparation d'un audit externe.
Analyse quantitative des risques
L'appréciation traditionnelle s'appuie sur des étiquettes qualitatives : élevé, moyen, faible. Ces étiquettes sont peu coûteuses à produire et presque impossibles à agréger, à comparer entre équipes ou à défendre devant une direction financière. Une base de données plus riche permet la modélisation des probabilités, des estimations d'impact fondées sur la criticité réelle des systèmes, une notation sur plusieurs facteurs pondérés et l'analyse de scénarios le long des chemins d'attaque.
La réserve honnête : la quantification hérite de la qualité de ses entrées. Un chiffre affirmatif tiré d'un inventaire obsolète est plus dangereux qu'un "moyen" assumé, parce qu'il survit à une objection en réunion là où une réserve n'y survivrait pas.
Priorisation dynamique des risques
Un registre statique vieillit par construction. La repriorisation continue tient compte de l'exploitabilité qui évolue, du contexte métier qui se déplace à chaque lancement produit, et d'une allocation de ressources qui suit le haut de liste actuel plutôt que celui du trimestre précédent. Les différents rôles ont besoin de vues différentes sur les mêmes données : une direction veut la tendance de l'exposition globale, un responsable ingénierie la file de ce sprint.
Applications pratiques de l'IA dans la gestion des risques
Ces capacités se traduisent en quatre applications où le gain opérationnel est mesurable et pas seulement théorique.
Gestion des vulnérabilités renforcée
C'est le cas le plus net, parce que les volumes bruts ont dépassé depuis longtemps le tri humain. La prévision de mi-année 2026 de FIRST annonce environ 66 000 CVE pour l'année, révisée à la hausse depuis une estimation de 59 427 en février, soit la première année en passe d'approcher les 70 000 publications. L'exploitabilité réelle, elle, ne progresse pas à ce rythme : le catalogue des vulnérabilités activement exploitées de la CISA comptait 1 587 entrées au 1er mai 2026.
Cet écart entre environ 66 000 publications et 1 587 vulnérabilités dont l'exploitation est confirmée constitue tout l'argument en faveur d'une priorisation intelligente. Trois signaux publics font l'essentiel du travail, et ils répondent à des questions différentes.
| Signal | Question à laquelle il répond | Ce qu'il ne dit pas |
|---|---|---|
| CVSS | Quelle serait la gravité d'une exploitation, dans l'abstrait ? | Si quelqu'un l'exploite, et si vous êtes exposé |
| EPSS | Quelle est la probabilité d'exploitation dans les 30 prochains jours ? | Quel serait l'impact pour votre activité |
| CISA KEV | L'exploitation est-elle déjà confirmée et observée ? | Tout ce qui concerne les vulnérabilités non encore répertoriées |
| Votre inventaire | Exploitons-nous réellement le composant concerné, et où ? | Rien, et c'est le signal qui manque le plus souvent |
EPSS, maintenu par FIRST, est un modèle d'apprentissage automatique qui estime la probabilité qu'une CVE publiée soit exploitée dans la nature au cours des 30 jours suivants, avec une note quotidienne de 0 à 1. Combiné au statut KEV et à votre propre inventaire, il transforme un flux de 66 000 entrées en une liste qu'une équipe peut réellement traiter. L'erreur que commettent la plupart des équipes est de s'arrêter au CVSS, qui décrit la gravité dans le vide et ne dit rien sur l'usage réel de la vulnérabilité ni sur le fait que vous exploitiez ou non le logiciel concerné.
Analyse du comportement des utilisateurs
L'analyse comportementale traite les risques qu'une appréciation fondée sur les mesures capte mal : un identifiant valide utilisé par la mauvaise personne, un compte compromis via l'une de ces campagnes de hameçonnage, des privilèges accumulés discrètement au fil des changements de poste.
- modélisation d'une référence pour établir ce qui est normal par compte utilisateur et compte de service
- détection d'anomalies par rapport à cette référence plutôt qu'à des règles génériques
- authentification adaptative qui relève les exigences en cas de comportement inhabituel
- surveillance renforcée des accès privilégiés, où un seul abus a des conséquences disproportionnées
Une mise en garde propre à cette application. La surveillance comportementale des salariés est un traitement de données à caractère personnel et implique, dans l'UE, des obligations de consultation des représentants du personnel et des obligations au titre du RGPD qu'une équipe sécurité ne peut pas régler seule. Associez votre fonction protection des données avant le déploiement, pas après. L'article 88 du RGPD et le droit du travail national déterminent ensemble ce qui est admissible ici.
Renseignement sur le risque fournisseurs
NIS2 rend le risque tiers explicitement obligatoire plutôt qu'optionnel : l'article 21, paragraphe 2, point d), exige des mesures relatives à la sécurité de la chaîne d'approvisionnement, y compris les aspects de sécurité des relations avec les fournisseurs directs. Cette obligation se satisfait difficilement au moyen d'un questionnaire annuel, puisque la posture d'un fournisseur change entre deux questionnaires.
La surveillance continue des fournisseurs, la cartographie des dépendances pour faire apparaître les risques de concentration et les indicateurs précoces de compromission deviennent traitables dès lors que l'évaluation s'appuie sur des données et non sur des déclarations. Le détail des obligations figure dans notre guide des exigences NIS2.
Gestion automatisée du risque de conformité
Pour les organisations qui mènent plusieurs référentiels, le coût récurrent ne vient pas de l'appréciation mais de la mise en correspondance. L'annexe A de l'ISO/IEC 27001:2022 contient 93 mesures réparties en quatre thèmes : 37 organisationnelles, 8 liées aux personnes, 14 physiques et 34 technologiques. NIS2 exige, à l'article 21, paragraphe 2, point a), des politiques d'analyse des risques et de sécurité des systèmes d'information. Un rapport SOC 2 s'appuie pour l'essentiel sur les mêmes mesures.
Ces jeux de mesures se recoupent largement. Les entretenir séparément revient à faire trois fois le même travail, et c'est tout l'intérêt de mener ISO 27001, RGPD et SOC 2 sur un seul jeu de mesures. La mise en correspondance automatisée identifie quelle mesure unique satisfait plusieurs exigences à la fois et, plus utile encore, où subsiste un écart réel une fois tous les recoupements déduits.
Stratégie de déploiement : du traditionnel à la gestion des risques par l'IA
La transition se fait par étapes. Douze mois constituent un horizon réaliste dès lors qu'une personne porte le résultat et peut y consacrer au moins un demi-équivalent temps plein. Comprimer ce délai produit généralement de l'outillage sans processus.
Phase 1 : poser les bases, mois 1 à 3
Documentez la méthode existante, critères de notation et seuils d'acceptation du risque compris, car l'IA amplifiera toutes les définitions dont elle hérite. Recensez où vivent aujourd'hui les données de risque. Fixez des valeurs de référence sur lesquelles vous accepterez d'être mesuré ensuite : combien de risques sont ouverts, quelle est l'ancienneté de l'entrée la plus récente, combien de temps prend un cycle complet et combien de constats a produits le dernier audit.
L'évaluation de la qualité des données appartient à cette phase et non à une phase ultérieure. Un inventaire complété à 70 % impose un plafond dur à tout ce qui se construit au-dessus, et aucun modèle ne corrige un inventaire qui n'existe pas.
Phase 2 : première mise en œuvre, mois 3 à 6
Commencez par un seul référentiel et par les systèmes dont le besoin de protection est le plus élevé. Connectez les sources qui produisent déjà les preuves : gestion des identités et des accès, gestion des terminaux, configuration cloud et l'outil de tickets où la remédiation a réellement lieu. Un référentiel traité de bout en bout vaut mieux que trois traités à moitié, pour la confiance de l'équipe comme pour l'audit.
Phase 3 : capacités avancées, mois 6 à 12
La corrélation entre domaines, les modèles prédictifs et les recommandations automatisées appartiennent à cette phase, une fois les définitions sous-jacentes stabilisées. Cette étape révèle si la phase 1 a été menée honnêtement. Sans critères convenus et responsables nommés, la surveillance continue produit surtout des alertes que personne n'évalue, et le programme acquiert un arriéré au lieu d'une capacité.
Une remarque sur les coûts, puisque la question arrive d'ordinaire trop tôt. Le prix de licence d'une plateforme en est rarement le facteur déterminant. Ce qui pèse sur le total, c'est le nombre de systèmes à intégrer, le nombre de référentiels menés en parallèle et la capacité interne disponible pour les décisions d'appréciation, qui ne s'automatisent pas du tout.
Considérations éthiques et supervision humaine
Utiliser l'IA pour gérer le risque, c'est exploiter un système qui a lui-même besoin de gouvernance. L'article 9, paragraphe 2, du règlement sur l'IA décrit le système de gestion des risques pour l'IA à haut risque comme un processus itératif continu mené sur l'ensemble du cycle de vie, avec revue systématique régulière, couvrant l'identification et l'analyse des risques prévisibles, l'estimation dans le cadre de l'usage prévu et d'un mésusage raisonnablement prévisible, l'évaluation des risques issus de la surveillance après commercialisation et l'adoption de mesures appropriées. Que votre cas d'usage soit ou non classé à haut risque, cette description reste une bonne définition d'une exploitation responsable. Les systèmes qui entrent dans cette classification sont traités dans notre guide sur les systèmes d'IA à haut risque au sens de l'AI Act.
Atténuation des biais
Un modèle de risque entraîné sur des données d'incidents passés apprend vos angles morts passés en même temps que votre histoire. Si une unité opérationnelle n'a jamais été surveillée de près, elle a produit peu d'incidents enregistrés, et le modèle en déduira qu'elle présente un faible risque. Testez les résultats de notation pour détecter les écarts systématiques entre unités, zones géographiques et types de systèmes, et documentez la façon dont les conclusions sont atteintes. Retestez après chaque réentraînement, pas seulement au lancement.
Explicabilité et transparence
Dans ce contexte, l'explicabilité n'est pas une préférence philosophique mais une exigence d'audit. Un évaluateur qui demande pourquoi un risque a été noté ainsi n'acceptera pas le modèle comme réponse. Conservez les facteurs de décision, les niveaux de confiance et les données d'entrée derrière chaque résultat, et assurez-vous qu'un humain puisse reconstituer le raisonnement sans l'aide du fournisseur.
Collaboration entre l'humain et l'IA
Définissez précisément où le système conseille et où une personne décide. En pratique la ligne passe par la décision de traitement : les modèles savent identifier, corréler et classer, mais accepter, réduire ou transférer un risque est un acte imputable que l'ISO/IEC 27001:2022 attribue à un propriétaire du risque au chapitre 6.1.3. Prévoyez le traitement des exceptions pour les cas où le modèle se trompe, et réinjectez les corrections humaines comme signal d'apprentissage plutôt que de les perdre dans un ticket.
« En audit, on ne demande jamais si votre outillage est sophistiqué. On demande qui a accepté ce risque, sur quelle base et à quelle date. Une automatisation incapable de répondre à cela a ajouté du débit sans ajouter d'assurance, et les équipes s'en aperçoivent tard, en général dans la salle avec l'auditeur. »
Kutluhan Abut, Information Security and AI Governance Specialist chez Kertos
Mesurer les résultats : les indicateurs à suivre
Trois familles d'indicateurs suffisent. Les trois ont besoin des valeurs de référence de la phase 1 pour signifier quoi que ce soit, et c'est précisément pourquoi ce travail de base n'est pas optionnel.
| Dimension | Indicateur | Pourquoi c'est le bon |
|---|---|---|
| Détection | Délai moyen entre l'apparition d'un risque et son appréciation documentée | Mesure en jours l'écart que crée le cycle annuel |
| Détection | Part des risques prévus ensuite confirmés comme réels | Maintient les modèles prédictifs honnêtes et pas seulement productifs |
| Efficience | Heures de travail par cycle d'appréciation | Le chiffre qui finance le programme la deuxième année |
| Efficience | Temps nécessaire pour projeter un nouveau référentiel sur le jeu de mesures existant | Isole le coût de mise en correspondance, qui est la vraie charge additionnelle |
| Effet sur l'activité | Constats d'audit par rapport à l'année précédente | Le résultat auquel une direction s'intéresse déjà |
| Effet sur l'activité | Délai de traitement des questionnaires de sécurité clients entrants | Relie directement le travail sur le risque à la vitesse des cycles de vente |
Un indicateur mérite plus d'attention qu'il n'en reçoit d'ordinaire : l'ancienneté du plus vieux risque ouvert sans décision de traitement. Il est peu flatteur, difficile à manipuler, et il vous dit si le programme clôt des risques ou se contente de les trouver plus vite.
Pour l'ordre de grandeur, un calcul illustratif plutôt qu'une moyenne sectorielle. Une entreprise logicielle de 300 personnes mène l'ISO 27001 en parallèle d'un rapport SOC 2, avec 640 systèmes et applications à l'inventaire. À raison d'une revue semestrielle et de 15 minutes par actif, cela représente 160 heures par cycle, donc 320 heures par an, avant qu'une seule décision de traitement ne soit prise. Les chiffres sont illustratifs, le rapport ne l'est pas : la charge croît avec l'inventaire, pas avec les effectifs.
Conclusion : ce que l'IA change réellement dans la gestion des risques
L'IA déplace la frontière entre ce qu'une équipe doit collecter et ce qu'elle doit décider. La collecte devient nettement moins coûteuse. La décision non, et les organisations qui peinent dans cette transition sont en général celles qui avaient budgété comme si elle allait l'être.
Ce qui change en pratique : l'état du risque est à jour au lieu d'être annuel, la priorisation suit l'exploitabilité réelle plutôt que la gravité abstraite, la mise en correspondance entre référentiels devient traitable, et les preuves d'audit se constituent pendant l'exploitation plutôt que dans la panique qui précède une évaluation.
Ce qui ne change pas : une personne responsable doit toujours décider quoi faire de chaque risque, et pouvoir expliquer cette décision un an plus tard.
La gestion des risques avec la plateforme Kertos
Kertos met cela en œuvre dans trois domaines complémentaires de la plateforme. Le cœur est la gestion des risques, où risques, mesures et décisions de traitement se trouvent au même endroit et conservent leur historique d'appréciation. C'est cet historique qui répond en audit à la question de l'imputabilité, sans que personne n'ait à reconstituer des tableaux après coup.
La base est fournie par l'Asset Management, qui rattache risques et mesures aux systèmes réellement concernés. Ce rattachement est la condition pour transformer un flux de vulnérabilités en file de travail plutôt qu'en rapport, et c'est la pièce que la plupart des projets sous-estiment.
Le risque tiers passe par le Vendor Management, où l'obligation NIS2 sur la chaîne d'approvisionnement devient opérationnelle au lieu d'être sondée une fois par an. Les risques nés de l'usage de systèmes d'IA eux-mêmes disposent d'un parcours d'évaluation propre avec l'AI Risk Assessment, aligné sur l'ISO 42001 et le règlement européen sur l'IA.
Les questions qui surgissent en exploitation vont à KAIA, l'assistant conformité de la plateforme, qui rattache une exigence à une mesure et explique quelle preuve est attendue. Des experts certifiés prennent les décisions d'appréciation avec vous plutôt que de vous remettre des modèles. Selon les chiffres publiés par Kertos, le taux de réussite en audit atteint 100 % pour une satisfaction client de 97 %, dans plus de dix secteurs.
Ce que les clients décrivent le plus souvent, c'est la consolidation plutôt que l'automatisation :
« Kertos a nettement amélioré notre gestion des risques, auparavant complexe et confuse. »
Daniela, Head of Sales & Marketing, Netstream AG
Questions fréquentes
Qu'est-ce que la gestion des risques par l'IA ?
Il s'agit du recours à l'apprentissage automatique pour automatiser la collecte de données, la corrélation et la pré-appréciation au sein d'un processus de gestion des risques. Les systèmes connectés fournissent des données de configuration, d'accès et de vulnérabilités, et un modèle les relie à l'inventaire et au jeu de mesures. La notation selon des critères définis et la décision de traitement restent du ressort de l'entreprise.
L'IA remplace-t-elle l'appréciation du risque exigée par l'ISO 27001 ?
Non. L'ISO/IEC 27001:2022 exige au chapitre 6.1.2 une procédure définie avec des critères établis et au chapitre 6.1.3 une décision de traitement documentée, imputable à un propriétaire du risque nommément désigné. L'IA peut fournir la base de cette décision, pas la décision elle-même, et un audit contrôle précisément cette imputabilité.
À quelle fréquence faut-il réaliser une appréciation des risques ?
Le chapitre 8.2 de l'ISO/IEC 27001:2022 ne fixe aucune périodicité. Il exige des appréciations à intervalles planifiés et, en plus, dès que des changements importants surviennent ou sont prévus. En pratique, cette seconde condition fait qu'un cycle annuel seul ne suffit pas dès que le parc de systèmes évolue régulièrement.
Comment prioriser les vulnérabilités avec l'IA ?
Combinez quatre signaux au lieu de vous fier à la seule gravité : CVSS pour la gravité abstraite, EPSS pour la probabilité d'exploitation dans les 30 jours, le catalogue KEV de la CISA pour l'exploitation confirmée, et votre propre inventaire pour savoir si vous exploitez le composant concerné. Avec environ 66 000 CVE prévues pour 2026 et 1 587 entrées KEV en mai 2026, le simple recoupement avec l'inventaire retire déjà l'essentiel du volume.
Le règlement européen sur l'IA s'applique-t-il à l'IA utilisée pour la gestion des risques ?
Cela dépend de la classification, et la question relève de votre fonction conformité plutôt que d'une réponse générale. L'article 9 du règlement fixe les obligations de système de gestion des risques pour l'IA à haut risque, et l'annexe III définit les cas d'usage qui entrent dans cette catégorie. Indépendamment de la classification, l'article 9, paragraphe 2, décrit un processus continu sur le cycle de vie avec revue systématique qui constitue une norme d'exploitation raisonnable pour toute IA sur laquelle vous fondez des décisions de sécurité.
