TL; DR
Tous les conseils d'administration s'interrogent désormais sur les risques liés à l'IA, et la plupart des équipes de sécurité répondent par des adjectifs plutôt que par des chiffres. Les cadres de gouvernance définissent ce qu'il faut gouverner, et non ce qu'il faut comptabiliser. Ces indicateurs de risque liés à l'IA proviennent tous de la même source : le code que votre organisation déploie déjà.
- Une stratégie d'IA agentique comporte trois couches, dont une seule est le modèle. Ce que l'agent écrit, ce à quoi il est connecté et ce qu'il reçoit : la plupart des programmes mesurent le premier point et ignorent les deux autres.
- Le rayon de l'explosion n'est pas pris en compte dans le modèle. Cela se trouve dans le fichier de compétences, la configuration MCP, le périmètre de l'outil et les informations d'identification sous lesquelles l'agent s'exécute. Une évaluation de modèle sans problème et un agent surprivilégié peuvent coexister sans difficulté.
- Neuf indicateurs de risque liés à l'IA, chacun étant un nombre plutôt qu'un adjectif. Ressources d'IA non approuvées, chemins d'injection rapide menant à un outil de destination, secrets dans
.mcp/servers.json, les dépendances ajoutées par l'agent ont été signalées avant même qu'une signature n'existe. - Si vous n'êtes pas en mesure d'atteindre ce chiffre ce trimestre, le problème ne vient pas de l'indicateur. L'inventaire est fait. Commencez par trois comptages, pas par un programme.
Que signifie concrètement le risque lié à l'IA lorsque c'est vous qui distribuez le logiciel ?
Demandez à dix personnes ce que signifie le risque lié à l'IA, et vous obtiendrez dix réponses. Biais de modélisation. Hallucinations. Fuites de données. Risques réglementaires. Déclassements d'emplois. Tous ces risques sont réels, tous méritent notre attention, et aucune équipe de sécurité ne pourra y répondre un mardi après-midi.
Il existe une version plus restreinte de la question qui peut être prise en charge par une équipe de sécurité : Quelle IA est exécutée au sein des logiciels que nous développons, jusqu'où peut-elle aller et que se passe-t-il lorsqu'elle est manipulée ? Cette version contient une réponse, et cette réponse se trouve dans vos dépôts et pipelineplutôt que dans un document de politique.
C’est de cette version du risque lié à l’IA dont il est question dans cet article. Non pas que les questions de gouvernance soient sans importance, mais parce qu’on ne pourra y répondre tant que celle-ci ne le sera pas. Un cadre de référence vous invite à inventorier vos systèmes d’IA. Il ne vous indique pas que cet inventaire se trouve dans un… .mcp/servers.json fichier que personne n'a ouvert depuis sa création commitTed.
Pourquoi la plupart des programmes de gestion des risques liés à l'IA mesurent-ils la mauvaise chose ?
Il existe trois schémas de défaillance, et la plupart des organisations en présentent au moins deux.
- Mesurer l'adoption plutôt que l'exposition. « 72 % de nos développeurs utilisent des outils d’IA » est un indicateur de productivité qui se pare d’un vernis de sécurité. Il ne vous dit rien sur les capacités réelles de ces outils.
- Mesurer le modèle plutôt que le système. L'analyse d'un point d'accès par une équipe rouge permet de déterminer si un modèle peut être amené à dire quelque chose d'inapproprié. Elle ne permet pas de prédire la suite des événements, car les conséquences dépendent du périmètre de l'outil, des identifiants sous lesquels l'agent s'exécute et des fichiers de configuration qui définissent ces éléments. Une évaluation correcte du modèle et un agent aux privilèges excessivement élevés peuvent coexister sans problème.
- Mesurer ce qui est facile à compter. Nombre de politiques relatives à l'IA publiées. Nombre d'employés ayant suivi une formation en IA. Ces chiffres augmentent de façon constante et ne présentent aucune corrélation.
Le Cadre de gestion des risques NIST AI Il est clairement indiqué que la mesure est l'une de ses quatre fonctions essentielles, aux côtés de la gouvernance, de la cartographie et de la gestion. Le cadre est délibérément axé sur les résultats plutôt que prescriptif, ce qui est approprié pour un standard et peu utile un mardi. Il vous reste encore à décider ce qu'il faut prendre en compte.
Quelles sont les métriques de risque liées à l'IA qui sont réellement informatives ?
Neuf indicateurs. Chacun est un nombre, chacun change en fonction de votre exposition, et chacun peut être généré par du code plutôt que par une enquête.
| Métrique | Pourquoi cela compte | D'où vient ce nombre ? |
|---|---|---|
| 01Nombre total d'actifs d'IA découverts et évolution depuis le mois dernier | On ne peut pas parler de risques liés à l'IA sans les avoir recensés. La tendance importe plus que le nombre absolu. | Découverte continue des modèles, des frameworks, des ensembles de données, des points d'accès d'inférence, des agents, des serveurs MCP, des compétences et des outils de programmation d'IA |
| 02Actifs d'IA non approuvés en pourcentage du total | Voici votre taux d'IA fantôme. C'est l'indicateur de risque IA le plus souvent cité par un conseil d'administration. | État d'approbation suivi par actif par rapport à votre police d'assurance |
| 03Actifs d'IA sans propriétaire identifié | Un actif que personne ne possède est un actif que personne ne réparera. Généralement, c'est le chiffre le plus problématique de l'ensemble. | Le suivi de la propriété est lié à l'actif. |
| 04Indiquez les chemins d'injection rapides qui atteignent un point d'entrée d'outil. | Les données non fiables qui parviennent à l'invite système n'ont d'importance que si un élément dangereux se trouve à l'autre extrémité. | Détection des risques par IA cartographiée sur Top 10 de l'OWASP pour les candidatures au LLM |
| 05Serveurs MCP en service et nombre de serveurs contenant des données de recherche | La configuration MCP est l'endroit où l'agent reçoit ses instructions. C'est également là que s'accumulent les identifiants. | Configuration du serveur MCP analysée en tant qu'artefact de sécurité |
| 06Des secrets découverts dans les fichiers de configuration de l'IA | Des recherches menées en 2026 ont révélé la présence de plus de 24 000 secrets dans des fichiers de configuration MCP hébergés sur GitHub public, dont plus de 2 000 étaient encore valides. | Détection de secrets à travers le code, les configurations, les conteneurs et pipelines |
| 07Dépendances ajoutées par l'agent signalées avant l'existence d'une signature publique | Les agents récupèrent rapidement les paquets, et le nom que votre modèle a inventé désigne une surface d'attaque exploitable. | Alerte précoce contre les logiciels malveillants, détection des preuves suivie d'une validation par IA |
| 08Part des découvertes en IA accessibles et faisant l'objet d'un développement actif. | Permet de distinguer les tâches en attente que vous ne rattraperez jamais du travail qui modifie votre exposition | L'entonnoir de priorisation de l'IA |
| 09Pourcentage de textes rédigés par des agents pull requests fusionné avec une approbation humaine | L’indicateur de gouvernance qu’un régulateur demandera, et celui que personne ne suit. | Pull request analyse et les portes d'approbation |
Si vous ne devez en retenir qu'un, choisissez l'indicateur 02. Le ratio entre les actifs d'IA non approuvés et le total correspond au chiffre qui passe le test de l'équipe de sécurité lors de l'audit. commitLe tee, et il bouge quand vous faites quelque chose.
Que doit couvrir une stratégie d'IA agentielle ?
Trois couches. L'erreur que presque tout le monde commet est de commencer par la première et de s'arrêter là.
- Couche 1 : ce que l'agent écrit. Le code généré présente les mêmes vulnérabilités que le code écrit par des humains, et des recherches menées depuis 2022 ont systématiquement démontré qu'une part importante des programmes générés par l'IA contient des failles de sécurité. Cette couche est la plus connue, ce qui explique précisément pourquoi elle concentre toute l'attention.
- Deuxième couche : ce à quoi l'agent est connecté. Fichiers de compétences, fichiers de règles, configurations du serveur MCP, étendues des outils, identifiants d'exécution de l'agent : cette couche détermine la portée d'une attaque réussie et reste invisible pour tout système testant le modèle via son point de terminaison. ATLAS MITRE Ce terrain est directement documenté : l’étude de cas AML.CS0041, relative à la porte dérobée dans les fichiers de règles, décrit comment des caractères de largeur nulle dans un fichier de règles transforment la documentation en instructions qu’un agent exécute silencieusement. Un examinateur lisant le pull request ne voit rien.
- Troisième couche : ce que l'agent attire. Dépendances, modèles, jeux de données, outils externes. Une étude présentée à USENIX Security en 2025 a généré 2.23 millions d'échantillons de code répartis sur 16 modèles et a révélé que 19.7 % des paquets recommandés étaient inexistants, produisant ainsi plus de 205 000 noms fictifs uniques. Les attaquants n'ont plus besoin de compromettre un responsable de la maintenance. Ils enregistrent le nom inventé par votre agent et attendent.
Une stratégie d'IA agentielle qui ne couvre que la première couche produit un rapport vierge et un profil de risque IA inchangé. Top 10 de l'OWASP pour les candidatures au LLM Cela se reflète dans sa propre structure : l'excès d'interventionnisme figure en tête de liste.cisParce qu'il s'agit d'un problème de câblage, et non d'un problème de modèle.
Comment mettre cela en œuvre sans ralentir les agents ?
L'instinct pousse à tout contrôler. Cela ne fonctionne pas car l'objectif principal de l'agent est le débit, et un contrôle qui le divise par deux est supprimé en moins d'un quart.
Trois principes de mise en œuvre qui résistent à l'épreuve du temps :
- Mesure en continu, sélection sélective par porte. Les neuf indicateurs de risque liés à l'IA peuvent être collectés à chaque analyse sans aucun blocage. Réservez les barrières strictes aux rares cas où la défaillance est irrémédiable : dépendance malveillante, secret actif, modèle non approuvé traitant des données réglementées.
- Installez la sécurité là où l'agent se trouve déjà. Un agent connecté via MCP interroge la plateforme de sécurité pendant la génération du code, analyse ce dernier et applique les corrections jusqu'à ce que le code réponde aux critères définis. Aucune intervention humaine n'est requise à ce stade, et aucune installation n'est nécessaire sur le serveur de l'agent. Il s'agit du seul point d'intervention dont l'efficacité est proportionnelle au débit de l'agent.
- Gardez l'humain à la fin. pull request. Tout élément intégré au code de production doit être approuvé par une personne. Il ne s'agit pas d'une simple précaution, mais d'une exigence de conception imposée par la réglementation européenne sur l'IA. De plus, il est bien plus économique de l'intégrer dès le départ que de devoir s'y conformer a posteriori sous la pression d'un audit. C'est également l'indicateur 09, d'où l'importance de le suivre dès le début.
Dans la plupart des organisations, la deuxième ligne reste souvent sans attribution. Les fichiers de configuration se situent à la croisée de la sécurité applicative, qui les considère comme de l'infrastructure, et de l'ingénierie de la plateforme, qui les perçoit comme de la documentation. C'est dans cet espace que les attaques les plus intéressantes trouvent leur cible.
Comment commencer à mesurer les risques liés à l'IA ce trimestre ?
Ne détaillez pas l'intégralité du programme. Concentrez-vous sur trois chiffres : le nombre de vos ressources en IA, celui des ressources non approuvées et le nombre de secrets contenus dans les fichiers de configuration. Ces trois éléments tiennent sur une seule diapositive ; ils sont tous justifiables et seront pires que ce que leur auteur imagine.
Ensuite, choisissez le problème le plus grave et corrigez-le avant la prochaine réunion du conseil d'administration. Voilà un programme de gestion des risques liés à l'IA qui fonctionne. Le reste n'est que du superflu.
Les organisations qui auront du mal à gérer les risques liés à l'IA en 2027 ne sont pas celles qui ont agi rapidement. Ce sont celles qui ont passé l'année 2026 à rédiger des politiques en matière d'IA sans jamais en mesurer l'impact. Une politique dont l'efficacité est impossible à évaluer reste un document. Seuls les indicateurs de risque liés à l'IA permettent de la transformer en outil de contrôle.
Consultez vos propres chiffres. Connectez un référentiel et Xygeni vous renvoie votre inventaire d'IA, les actifs non approuvés, les risques cartographiés selon les cadres utilisés par vos auditeurs, ainsi qu'une nomenclature d'IA que vous pouvez exporter. Commencer gratuitement or réserver une démo.
QFP
Quelle est la différence entre les risques liés à l'IA et la sécurité de l'IA ?
La sécurité de l'IA concerne principalement le fonctionnement d'un modèle : son comportement est-il conforme aux attentes, ses résultats sont-ils nuisibles et peut-il être manipulé pour lui faire faire ce qu'il devrait refuser ? Le risque lié à l'IA, dans un contexte de sécurité, concerne l'impact potentiel d'un système d'IA compromis ou dysfonctionnel au sein de votre environnement. Ces deux aspects se recoupent, mais relèvent d'équipes différentes et sont mesurés avec des outils distincts. Une équipe de sécurité peut agir dès aujourd'hui sur le second risque.
Combien d'indicateurs de risques liés à l'IA devons-nous présenter au conseil d'administration ?
Trois à cinq. Un conseil d'administration ne peut pas se prononcer sur neuf chiffres, et un jeu de neuf cartes a tendance à masquer celle qui compte vraiment. Indiquez le nombre total de vos actifs d'IA, le pourcentage non approuvé et un indicateur d'exposition, comme les résultats d'IA accessibles en cours de développement. Conservez le reste pour l'analyse opérationnelle.
Avons-nous besoin d'une nomenclature automatisée (AI-BOM) si aucune réglementation ne l'exige encore ?
Aucune réglementation n'impose actuellement de nomenclature d'inventaire automatisée (AI-BOM), ce qui explique pourquoi sa génération est peu coûteuse aujourd'hui et onéreuse par la suite. Deux formats lisibles par machine existent et un auditeur acceptera l'un ou l'autre. L'intérêt ne réside pas dans la conformité, mais dans le fait que la production du fichier vous oblige à disposer de l'inventaire, et cet inventaire est essentiel à toute mesure de risque liée à l'IA.
Nos développeurs utilisent des outils d'IA que nous n'avons jamais approuvés. Par où commencer ?
Faites le recensement avant de sanctionner. Annoncer une politique interdisant des outils invisibles les pousse à les utiliser clandestinement et nuit à la visibilité nécessaire. Commencez par un recensement, publiez le nombre d'outils en interne sans mentionner l'auteur, et utilisez-le pour établir une liste approuvée qui reflète les besoins réels des utilisateurs. L'application de la loi est bien plus efficace lorsqu'elle s'appuie sur des preuves que lorsqu'elle les précède.
