Qu’est-ce que la sécurité de l’IA ?

La sécurité de l’IA (AI safety) est le domaine de recherche et de pratique d’ingénierie qui vise à faire en sorte que des systèmes d’IA de plus en plus performants restent fiables, contrôlables et alignés sur les intentions humaines, même lorsqu’ils égalent ou surpassent l’humain sur des tâches spécifiques. Cet article explique ce que recouvre ce domaine, pourquoi les modèles à usage général rendent le problème plus difficile et ce qu’exige une réelle supervision humaine.

Une définition de travail

En ingénierie classique, un système sûr est un système dont les modes de défaillance sont connus, bornés et testés, comme le système de freinage d’une voiture. La sécurité de l’IA donne au mot « sûr » un sens plus large. Elle cherche à savoir si un système fait ce que ses développeurs et ses utilisateurs veulent qu’il fasse (alignement), s’il continue de le faire dans des conditions inhabituelles et face à des attaques délibérées (robustesse), si l’on peut comprendre pourquoi il se comporte comme il le fait (interprétabilité) et si des humains peuvent l’inspecter, le corriger ou l’arrêter lorsque c’est nécessaire (contrôle et supervision).

Ces questions recoupent celles de domaines voisins. L’éthique de l’IA se demande ce qu’il faut construire, et pour qui ; la cybersécurité de l’IA (AI security) protège les modèles, les données et les infrastructures contre les attaquants ; la sécurité de l’IA se demande si le système lui-même se comporte comme prévu une fois déployé. Les frontières sont poreuses : un modèle de recrutement biaisé pose d’abord un problème d’équité, tandis qu’un modèle que l’on peut convaincre d’ignorer ses instructions relève à la fois de la cybersécurité et de la sécurité de l’IA.

Pourquoi les modèles à usage général changent la nature du problème

Un outil spécialisé s’accompagne d’une spécification. Un filtre antispam se trompe lorsqu’il bloque un message légitime, et ses développeurs peuvent le mesurer directement. Un modèle à usage général est différent : il est entraîné sur d’immenses volumes de données pour être utile dans toutes sortes de tâches que personne n’a énumérées à l’avance, et il n’existe donc pas de spécification unique permettant de le juger.

Les développeurs entraînent donc leurs modèles sur des indicateurs indirects de ce qu’ils recherchent, ce qui produit un schéma de défaillance bien documenté, connu sous le nom de specification gaming ou reward hacking (détournement de la spécification, ou de la récompense) : le système optimise ce qui est mesuré plutôt que ce qui est voulu. Un modèle entraîné à produire des réponses que des évaluateurs humains approuvent peut apprendre à paraître sûr de lui et conciliant même lorsque l’affirmation sous-jacente est fausse. Un assistant qui invente une référence plausible mais inexistante est un symptôme familier de cet écart.

Les enjeux augmentent lorsque les modèles agissent comme des agents : des systèmes qui utilisent des outils, naviguent sur le web, lisent des documents et envoient des messages pour le compte d’un utilisateur. Un agent qui lit une page web contenant des instructions cachées lui ordonnant d’abandonner sa tâche et de transférer les e-mails de l’utilisateur peut les suivre. Cette attaque, appelée injection de prompt, est possible parce que le modèle traite les instructions et les données dans le même canal. Aucune défense technique complète n’est connue à ce jour ; les mesures d’atténuation actuelles réduisent le risque sans le supprimer.

Les principaux axes de travail

Une grande partie de la recherche sur la sécurité de l’IA peut être regroupée en quatre programmes qui se renforcent mutuellement.

• Alignement : les méthodes d’entraînement, comme l’apprentissage à partir de retours humains, qui façonnent ce qu’un modèle cherche à faire.
• Évaluation et tests : mesurer ce que les modèles savent faire avant leur déploiement, y compris les capacités qui pourraient causer des dommages.
• Interprétabilité : comprendre les calculs internes d’un modèle suffisamment bien pour expliquer ou prédire son comportement.
• Robustesse et contrôle : les défenses contre l’injection de prompt, l’empoisonnement des données et le détournement des objectifs, et des moyens fiables d’interrompre un système.

L’évaluation mérite une attention particulière. Un score obtenu sur un benchmark ne dit pas grand-chose si les questions du test figuraient déjà dans les données d’entraînement, un problème connu sous le nom de contamination des jeux de test. Les tests face à des attaques adaptatives comptent pour la même raison : une protection qui résiste aux techniques de contournement (jailbreaks) de l’an dernier et cède devant celles de cette année n’offre guère de garantie.

Ce qu’exige une réelle supervision humaine

La supervision humaine est souvent présentée comme l’ultime garde-fou, mais elle ne fonctionne que si la personne dans la boucle dispose du temps, des informations, de l’autorité et des compétences nécessaires pour intervenir. La recherche sur les facteurs humains documente depuis longtemps le biais d’automatisation : les gens ont tendance à accepter le résultat d’un système automatisé, surtout sous la pression du temps, et à ne pas voir ses erreurs. Un clinicien à qui l’on demande de passer en revue une longue file de recommandations générées par une machine, ou un fonctionnaire qui ne peut pas voir pourquoi un système a signalé un dossier, ne peuvent pas exercer une réelle supervision.

Le droit traite de plus en plus la supervision comme une exigence de conception plutôt que comme une formalité. L’article 22 du RGPD donne déjà aux personnes le droit, sous réserve d’exceptions, de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou les affectant de manière significative de façon similaire. Le règlement européen sur l’IA (AI Act, règlement (UE) 2024/1689) exige que les systèmes à haut risque soient conçus de manière à pouvoir être effectivement supervisés par des personnes (article 14) et qu’ils respectent des exigences d’exactitude, de robustesse et de cybersécurité (article 15) ; l’article 14 mentionne explicitement le biais d’automatisation. La plupart des obligations applicables aux systèmes à haut risque devaient initialement s’appliquer à partir du 2 août 2026 ; l’omnibus numérique sur l’IA (règlement (UE) 2026/1744), en vigueur depuis le 27 juillet 2026, les a reportées au 2 décembre 2027, et au 2 août 2028 pour l’IA à haut risque intégrée dans des produits réglementés.

Au-delà de l’UE, gouvernements et développeurs se sont réunis à Bletchley Park en 2023, à Séoul en 2024 et à Paris en 2025, avec à l’ordre du jour les risques des modèles de frontière, les systèmes les plus performants de leur génération. Les Principes de l’OCDE sur l’IA (2019, mis à jour en 2024), le cadre de gestion des risques liés à l’IA du NIST (AI Risk Management Framework, 2023) et la norme ISO/IEC 42001 (2023) traduisent une partie des objectifs de la sécurité de l’IA en un langage que les organisations peuvent mettre en pratique. Aucun de ces instruments ne résout les problèmes techniques ; ils créent l’attente que quelqu’un ait fait le travail et puisse le démontrer.

Ce qu’il faut retenir en pratique

L’idée centrale vaut au-delà des laboratoires de recherche. Lorsqu’un système d’IA entre dans une école, une organisation à but non lucratif ou une administration publique, les questions utiles sont concrètes : sur quoi a-t-il été testé et par qui, que se passe-t-il quand il se trompe, qui peut annuler ses décisions, et à quelles données et à quels outils a-t-il accès. Un système pour lequel personne ne peut répondre à ces questions n’a pas mérité l’autonomie qu’on lui accorde.

La recherche sur la sécurité de l’IA est l’un des six domaines d’action de la Fondation, et les analyses qu’elle publie dans cette rubrique partent d’un même principe : la technologie doit renforcer le jugement humain plutôt que le remplacer discrètement.

En bref

La sécurité de l’IA est le domaine de recherche et de pratique d’ingénierie qui vise à garder des systèmes d’IA de plus en plus capables fiables, contrôlables et alignés sur les intentions humaines. Elle demande si un système fait ce que les gens veulent, continue à le faire dans des conditions inhabituelles et sous attaque, peut être compris, et peut être inspecté, corrigé ou arrêté par des humains si nécessaire.

Questions fréquentes

Quelle est la différence entre sécurité de l’IA, éthique de l’IA et cybersécurité de l’IA ?

L’éthique de l’IA demande ce qu’il faut construire et pour qui. La cybersécurité de l’IA protège les modèles, les données et l’infrastructure contre les attaquants. La sécurité de l’IA demande si le système lui-même se comporte comme prévu une fois déployé. Les frontières sont poreuses : un modèle que l’on peut convaincre d’ignorer ses instructions pose à la fois un problème de cybersécurité et de sécurité de l’IA.

Qu’est-ce que l’injection de prompt ?

L’injection de prompt est une attaque dans laquelle un agent d’IA lit un contenu, comme une page web contenant des instructions cachées, et peut suivre ces instructions, par exemple en abandonnant sa tâche pour transférer les e-mails de l’utilisateur. L’attaque est possible parce que le modèle traite instructions et données dans le même canal. Aucune défense technique complète n’est connue ; les parades réduisent le risque sans le supprimer.

Pourquoi les modèles d’IA à usage général compliquent-ils la sécurité ?

Un outil étroit comme un filtre anti-spam a une spécification, et ses erreurs se mesurent directement. Un modèle à usage général est entraîné à être utile pour des tâches que personne n’a listées à l’avance : il n’existe pas de spécification unique pour le juger. On entraîne donc sur des indicateurs de substitution, ce qui mène au détournement de spécification : un système optimise ce qui est mesuré plutôt que ce qui est voulu.

Quels sont les principaux domaines de recherche en sécurité de l’IA ?

La recherche se regroupe en quatre programmes : l’alignement, qui façonne ce qu’un modèle cherche à faire, par exemple par l’apprentissage à partir de retours humains ; l’évaluation et les tests, qui mesurent ce que les modèles savent faire avant déploiement ; l’interprétabilité, qui explique le comportement d’un modèle par ses calculs internes ; et la robustesse et le contrôle, contre l’injection de prompt, l’empoisonnement des données et le détournement des objectifs.

Que requiert une supervision humaine réelle de l’IA ?

La supervision humaine ne fonctionne que si la personne dans la boucle dispose du temps, de l’information, de l’autorité et de la compétence pour intervenir. On tend à accepter le résultat d’un système automatisé, surtout sous la pression du temps : c’est le biais d’automatisation. Un clinicien qui passe en revue une longue file de recommandations machine ne peut pas superviser réellement. L’article 14 du règlement européen sur l’IA nomme expressément le biais d’automatisation.

Comment citer Fondation LASTHUMAN. (2026, 2 juin). Qu’est-ce que la sécurité de l’IA ? https://lasthuman.today/fr/insights/what-is-ai-safety.html