Évaluation et sécurité des systèmes d’IA : comment mesurer et comment surveiller

Les benchmarks et l’incertitude de mesure, comment la sélection d’après le jeu de test gonfle les résultats, la contamination des données sur une expérience, les types de risques, le filtre de commandes d’un agent comme interdiction contre autorisation, et la défense en profondeur.

12 minutes Matěj Žalmánek 2026-10-16

Série Bases de l’IA Partie 52 sur 52

1. Carte de l’intelligence artificielle : qu’est-ce qui est quoi et comment tout s’emboîte
2. Brève histoire de l’intelligence artificielle : de Turing aux modèles de langage
3. Données, modèle, entraînement, inférence : les notions de base sur un seul exemple
4. Lire la notation mathématique : symboles, indices, sommes et quantificateurs
5. Ensembles et relations : les briques dont sont faites les définitions en IA
6. Fonctions et applications : pourquoi tout modèle d’IA est une fonction
7. Logique et démonstrations : les règles selon lesquelles on raisonne en IA
8. Graphes et arbres : la structure sur laquelle reposent la recherche et les réseaux de neurones
9. Algèbre linéaire pour l’apprentissage automatique : vecteurs, matrices et pourquoi l’IA multiplie surtout
10. Dérivées, gradient et règle de dérivation en chaîne : comment un modèle sait dans quelle direction apprendre
11. Descente de gradient : comment un modèle apprend
12. Qu’est-ce que la probabilité : du lancer de dé aux axiomes de Kolmogorov
13. Probabilité conditionnelle et théorème de Bayes : comment réviser une estimation quand on apprend du nouveau
14. Variable aléatoire et fonction de répartition : une seule fonction qui dit tout de la loi
15. Fonction de densité et fonction de masse : pourquoi une variable continue a une probabilité nulle en chaque point
16. Espérance, variance et covariance : où se situe une loi, quelle est sa largeur et ce qui varie avec quoi
17. Panorama des lois de probabilité : Bernoulli, binomiale, Poisson, uniforme, normale et exponentielle
18. Loi des grands nombres et théorème central limite : pourquoi les moyennes sont si prévisibles
19. Statistique et estimation de paramètres : maximum de vraisemblance, MAP et intervalles de confiance
20. Théorie de l’information : entropie, entropie croisée et divergence KL — d’où viennent les fonctions de perte
21. Recherche dans l’espace d’états : BFS, DFS, UCS et A* en animations
22. Jeux et adversaires : minimax, élagage alpha-bêta et Monte Carlo tree search
23. Satisfaction de contraintes : backtracking, propagation de contraintes et AC-3 sur un sudoku et une carte des régions tchèques
24. Logique et systèmes à base de connaissances : chaînage avant et arrière, résolution et systèmes experts
25. Planification : STRIPS, monde des blocs, heuristiques par relaxation et planification dans les agents IA
26. Recherche locale et recuit simulé : un voyageur de commerce à travers les chefs-lieux de région tchèques
27. Algorithmes génétiques : population, croisement, mutation et sélection sur un sac à dos de randonnée
28. Stratégies d’évolution et programmation génétique : de la règle du cinquième à la loi de Kepler
29. Optimisation par colonies de fourmis : comment une piste de phéromone trouve un chemin court
30. Optimisation par essaim de particules : inertie, expérience propre et expérience de l’essaim
31. Neuroévolution : faire évoluer les poids et la forme des réseaux de neurones, et l’algorithme NEAT
32. Ensembles flous et fonctions d’appartenance : comment écrire « un peu chaud »
33. Logique floue et probabilité : pourquoi « un peu chaud » ne veut pas dire « probablement chaud »
34. Logique floue : t-normes, implications et règles SI–ALORS
35. Commande floue : Mamdani et Sugeno, du ventilateur au pendule inversé sur un chariot
36. Clustering flou : l’algorithme fuzzy c-means et les points entre les clusters
37. Systèmes neuro-flous (ANFIS) : des règles floues qui apprennent à partir des données
38. Chaînes de Markov : matrice de transition, distribution stationnaire et PageRank
39. Modèles de Markov cachés : l’algorithme de Viterbi et le casino malhonnête
40. Réseaux bayésiens : pourquoi l’herbe est mouillée et ce que cela implique pour l’arroseur
41. Le filtre de Kalman : comment estimer, à partir de mesures imprécises, où se trouve une voiture et à quelle vitesse elle roule
42. Types d’apprentissage automatique : supervisé, non supervisé, semi-supervisé et plus
43. Prompts, contexte et RAG : comment donner au modèle les bonnes informations
44. Autoencodeurs variationnels (VAE) : de nouvelles images à partir d’un espace latent continu
45. Réseaux antagonistes génératifs (GAN) : le faussaire contre le détective
46. Modèles de diffusion : comment une image naît du bruit pur
47. Processus de décision markoviens : états, actions, récompenses et équations de Bellman
48. Q-learning et DQN : apprendre la valeur des actions, du tableau au réseau de neurones
49. Policy gradient et PPO : apprendre directement la politique
50. Comment fonctionne un agent IA : un modèle de langage en boucle avec des outils
51. Programmer avec des agents IA : consigne, tests et vérification
52. Évaluation et sécurité des systèmes d’IA : comment mesurer et comment surveiller

Programme complet de la série 52 sur 83 sujets publiés

« Le nouveau modèle est meilleur de 3 points. » « L’agent est sûr, les commandes dangereuses lui sont interdites. » Les deux phrases ont l’air rassurantes, et les deux peuvent être fausses sans que personne ne mente. La première à cause de la façon dont on mesure, la seconde à cause de la façon dont on interdit. Dans la dernière partie consacrée aux agents, nous examinons les deux questions que l’on pose le plus souvent à propos des systèmes d’IA : comment savoir ce qu’ils savent vraiment faire, et comment faire en sorte qu’ils ne fassent pas ce qu’ils ne doivent pas faire.

Cette partie fait suite aux parties Évaluation des modèles, Comment fonctionne un agent IA et Programmer avec des agents IA.

1. Comment mesurer ce que sait faire un modèle

Définition — benchmark

Un benchmark est un ensemble fixe de tâches dont les bonnes réponses et la règle de notation sont connues, sur lequel on compare les modèles : des questions à choix multiple dans de nombreux domaines (MMLU), des problèmes de mathématiques rédigés (GSM8K), des corrections de vrais bogues dans des projets open source vérifiées par des tests (SWE-bench). Le résultat est généralement la part des tâches résolues correctement. On y ajoute des comparaisons par des humains (des personnes votent pour la meilleure de deux réponses anonymes) et ses propres tests sur les tâches qui comptent pour vous.

Même une interrogation honnête n’a qu’une précision limitée. Un modèle qui résout 82 % de 200 tâches a un intervalle de confiance à 95 % de 76,1 à 86,7 % ; un modèle à 85 % a 79,4 à 89,3 %. Les intervalles se recouvrent en grande partie — une telle mesure ne permet pas de dire lequel est meilleur. Sur 2 000 tâches, l’intervalle pour 82 % ne serait plus que de 80,3 à 83,6 %. Chaque fois que vous voyez un écart de quelques points de pourcentage, demandez sur combien de tâches il a été mesuré.

Définition — intervalle de confiance à 95 %

Le modèle résout chaque tâche avec une probabilité inconnue p ; sur n tâches, nous mesurons la proportion p̂. Un intervalle de confiance à 95 % est une méthode qui, à partir de p̂ et de n, calcule un intervalle tel que, si l’on répétait la mesure sur de nouveaux ensembles, il contiendrait le vrai p dans 95 % des cas. Ce n’est pas l’affirmation « p se trouve dans l’intervalle avec une probabilité de 95 % » — c’est l’intervalle qui est aléatoire, pas p.

Dans cette partie, nous calculons les intervalles avec la formule de Wilson (Edwin B. Wilson, 1927). Contrairement au simple p̂ ± 1,96 · √(p̂(1 − p̂) / n), elle ne sort pas de l’intervalle de 0 à 100 % et fonctionne aussi pour des proportions proches des bords :

( p̂ + z² / 2n ± z √( p̂(1 − p̂) / n + z² / 4n² ) ) / ( 1 + z² / n )

p̂

la proportion mesurée de bonnes réponses — le point de départ autour duquel on construit l’intervalle

z² / 2n

un décalage vers le centre : comme si l’on ajoutait aux résultats z²/2 ≈ 2 bonnes et 2 mauvaises réponses. Un petit ensemble ne peut ainsi pas prétendre « 100 %, intervalle de largeur nulle »

z √(…)

la demi-largeur de l’intervalle ; le premier terme sous la racine est la variance de la proportion mesurée, qui diminue avec n — c’est pourquoi quatre fois plus de tâches ne donnent qu’un intervalle deux fois plus étroit

1 + z² / n

le dénominateur ramène le centre décalé et la largeur à la bonne échelle ; pour un grand n, il vaut presque 1 et la formule devient le simple p̂ ± z · √(p̂(1 − p̂) / n)

Exemple — intervalle pour 82 % de 200 tâches et écart entre deux modèles

z² = 1,96² = 3,8416. Centre : 0,82 + 3,8416 / 400 = 0,8296. Demi-largeur : 1,96 · √(0,82 · 0,18 / 200 + 3,8416 / 160 000) = 1,96 · √(0,000738 + 0,000024) = 0,0541. Dénominateur : 1 + 3,8416 / 200 = 1,0192.

Intervalle : (0,8296 − 0,0541) / 1,0192 = 0,7609 à (0,8296 + 0,0541) / 1,0192 = 0,8671, soit 76,1 à 86,7 %.

L’écart entre 85 % et 82 % est-il réel ? L’erreur type de la différence de deux proportions indépendantes vaut √(0,82 · 0,18 / 200 + 0,85 · 0,15 / 200) = 0,0371, donc l’intervalle de confiance à 95 % de la différence est 3 ± 1,96 · 3,71 = 3 ± 7,3 points. Il contient zéro — l’écart ne se distingue pas du hasard. (Quand les deux modèles résolvent les mêmes tâches, on peut mesurer plus finement par paires, uniquement sur les tâches où ils diffèrent.)

Combien de tâches faut-il pour que la demi-largeur soit de 1 point ? De z √(p(1 − p) / n) ≤ 0,01, on tire n ≥ z² p(1 − p) / 0,01² = 3,8416 · 0,82 · 0,18 / 0,0001 ≈ 5 671 tâches.

2. Le jeu de test s’use

Définition — surapprentissage adaptatif sur le jeu de test

Quand on sélectionne à répétition d’après les résultats sur le même jeu de test — la meilleure de nombreuses variantes, réglages, prompts —, le résultat cesse d’être une estimation impartiale. La variante choisie n’est en partie la meilleure que parce que le hasard l’a favorisée sur ce jeu-là. Sur de nouvelles données, elle s’en sortira moins bien. De façon plus générale, c’est ce que résume la loi de Goodhart : quand une mesure devient un objectif, elle cesse d’être une bonne mesure.

Expérience : K variantes d’un modèle, toutes avec une précision réelle de 70 %, sont mesurées sur le même jeu, et l’on annonce le résultat de la meilleure. Moyenne sur 300 répétitions :

Sur un jeu de 100 tâches, la sélection parmi 100 variantes annonce en moyenne 81,1 % et parmi 500 variantes 83,2 % — 13 points de plus que ce que n’importe laquelle sait réellement faire. Un jeu plus grand aide (avec 1 000 tâches, 73,6 %), mais le problème ne disparaît pas. Les variantes de l’expérience se trompent indépendamment ; les vraies variantes d’un même modèle font des erreurs semblables, si bien que l’effet est souvent plus faible — mais il va dans le même sens. Protection : sélectionner sur un jeu (de validation) et mesurer le chiffre final une seule fois sur un autre jeu, intact.

Pourquoi on obtient ces valeurs se calcule exactement. Le nombre de tâches X que résout une variante suit une loi binomiale Bin(n, 0,7). La meilleure de K variantes atteint au moins t tâches si au moins l’une d’elles y parvient :

P(max ≥ t) = 1 − ( 1 − P(X ≥ t) )^K

P(X ≥ t)

la probabilité qu’une variante résolve par hasard au moins t tâches ; pour t au-dessus du niveau réel, elle est faible — et c’est précisément d’elle que vit la sélection

K

le nombre de variantes essayées ; en exposant, parce que (1 − P)^K est la probabilité qu’aucune des variantes indépendantes n’y parvienne

P(max ≥ t)

la probabilité que le résultat annoncé (le meilleur) atteigne t ; quand K augmente, elle s’approche de un, même pour un t élevé

Exemple — 80 % de 100 tâches

Une variante : X ~ Bin(100; 0,7) a une espérance de 70 et un écart type de √(100 · 0,7 · 0,3) = 4,58 tâches. Elle résout au moins 80 tâches avec la probabilité P(X ≥ 80) = 0,0165, soit dans environ 1,6 % des cas — plus de deux écarts types au-dessus de la moyenne.

Parmi 100 variantes : P(max ≥ 80) = 1 − (1 − 0,0165)¹⁰⁰ = 0,810. Le résultat « 80 % ou plus », rare pour une seule variante, sera annoncé dans quatre expériences sur cinq.

L’espérance du meilleur résultat se calcule à partir de la formule sans simulation : E[max] = ∑_t=1ⁿ P(max ≥ t). On obtient 81,1 % pour 100 variantes, 83,2 % pour 500 variantes et 73,6 % pour 100 variantes sur un jeu de 1 000 tâches — la même chose que la simulation avec 300 répétitions (81,1, 83,2 et 73,6 %).

3. Contamination : le modèle a vu les réponses

Définition — contamination des données

La contamination se produit quand les tâches de test (ou leurs copies proches) se retrouvent dans les données d’entraînement. Pour les grands modèles de langage, entraînés sur une grande partie d’Internet, c’est un problème sérieux : les benchmarks sont publics, souvent avec leurs solutions, et le modèle a pu les mémoriser. Le résultat mesuré mesure alors la mémoire, pas la capacité.

Une expérience sur les chiffres 8 × 8 de la partie sur le clustering : un classifieur du plus proche voisin n’apprend qu’à partir de trois exemples de chaque chiffre, si bien que sur 200 chiffres de test il atteint honnêtement 60 %. Puis une partie des chiffres de test « fuit » dans les données d’entraînement :

ŷ(x) = y_i*,   i* = argmin_{i ∈ entraînement} ∑_j=1⁶⁴ (x_j − x_i,j)²

∑ (x_j − x_i,j)²

le carré de la distance euclidienne entre deux images de 64 pixels ; petit quand les images se ressemblent

argmin_{i ∈ entraînement}

quel exemple d’entraînement est le plus proche — on ne cherche que parmi ce que le modèle a « vu » ; c’est pourquoi la fuite de données de test change directement les réponses

y_i*

la réponse est le chiffre du plus proche voisin ; aucune généralisation, juste « ça ressemble à ça »

Avec une fuite de 10 %, la précision bondit à 69 %, avec 25 % à 79 %, avec la moitié à 92 % et avec tout le jeu de test à 100 %. Fait intéressant, même les chiffres qui n’ont pas fui s’améliorent (avec une fuite de la moitié, 86 % au lieu de 60 %) : les exemples qui ont fui ressemblent aux autres exemples de test et aident donc aussi pour eux. C’est pourquoi il ne suffit pas de vérifier si le modèle a vu exactement la même question — il suffit qu’il en ait vu de semblables. Défense : des jeux de test non publics, de nouvelles tâches créées seulement après la fin de l’entraînement du modèle, et la vérification que le modèle ne sait pas « compléter » la tâche de mémoire.

4. Ce qui peut mal tourner

La sécurité des systèmes d’IA n’est pas une seule chose. Il est utile de distinguer d’où vient le dommage :

• Erreurs — le modèle se trompe ou invente (hallucinations) et une personne le croit.
• Usage abusif — quelqu’un utilise le modèle pour nuire : e-mails frauduleux, aide à une attaque, désinformation.
• Attaques contre le système — une prompt injection dans un document ou sur le web prend le contrôle de l’agent ; un « jailbreak » contourne les règles du modèle.
• Actions dangereuses — un agent ayant accès à un ordinateur ou à des comptes fait quelque chose d’irréversible, même si personne ne le voulait.
• Désalignement des objectifs — le système optimise exactement ce que nous lui avons donné, au lieu de ce que nous voulions (suroptimisation de la récompense). À mesure que les systèmes gagnent en autonomie, c’est un sujet de recherche comme de régulation.

5. Interdire ou autoriser

Un exemple concret tiré de la pratique des agents : l’agent peut exécuter des commandes dans le terminal. Comment l’empêcher de lancer quelque chose de dangereux ? Comparons deux filtres sur 28 commandes — 12 courantes (tests, git, liste de fichiers) et 16 dangereuses (suppression, envoi de données vers l’extérieur, exécution d’un script étranger).

Définition — liste d’interdictions et liste d’autorisations

Une liste d’interdictions (denylist) bloque les motifs dangereux énumérés et laisse passer tout le reste. Une liste d’autorisations (allowlist) ne laisse passer que les commandes sûres énumérées et arrête tout le reste — pour un agent, typiquement en demandant l’accord d’une personne. Le principe de sécurité du moindre privilège recommande la seconde.

L’interdiction contient les motifs « rm -rf », « curl | sh », « DROP TABLE », « --force », « .ssh ». L’autorisation ne laisse passer que la liste et la lecture de fichiers, git sans écriture, le lancement des tests et la création d’un dossier, et cela sans tubes ni points-virgules.

l’interdiction laisse passer c ⇔ ¬ ∃ z ∈ Z : z est une sous-chaîne de c
l’autorisation laisse passer c ⇔ ∃ a ∈ A : c commence par a ∧ c ne contient pas | ; & ` $

¬ ∃ z ∈ Z

interdiction : laisse passer tout ce où elle ne trouve aucun des motifs interdits. La réponse par défaut est « oui » — toute écriture à laquelle l’auteur n’a pas pensé passe

∃ a ∈ A : c commence par a

autorisation : ne laisse passer qu’une commande qui commence par l’un des préfixes autorisés. La réponse par défaut est « non » — une commande inconnue attend une personne

sans | ; & ` $

sans cela, un début autorisé pourrait être « prolongé » : git status; rm -rf ~ commence par le git status autorisé

L’interdiction n’a arrêté que 5 des 16 commandes dangereuses. Il suffit d’écrire rm -r -f au lieu de rm -rf, de supprimer les fichiers avec find -delete ou avec Python, de télécharger le script avec wget au lieu de curl, ou d’encoder la commande en base64. Une liste d’interdictions a toujours un temps de retard sur l’ingéniosité — et un modèle de langage est ingénieux, même s’il ne veut nuire à personne ; il cherche simplement un autre moyen d’accomplir la tâche. L’autorisation les a arrêtées toutes les 16. Le prix : 3 des 12 commandes courantes (installation d’une bibliothèque, commit, suppression d’un fichier temporaire) doivent être approuvées par une personne. C’est exactement le rôle de l’humain dans la supervision d’un agent : décider dans les cas que les règles ne couvrent pas.

Exemple — les filtres comme classifieurs

Un filtre est un classifieur dont la classe positive est « dangereuse », on peut donc le décrire avec les nombres de la partie sur l’évaluation. Le rappel (TPR, la part des commandes dangereuses arrêtées) et le taux de fausses alertes (FPR, la part des commandes courantes arrêtées) :

Interdiction : TPR = 5 / 16 = 0,313, FPR = 0 / 12 = 0,00. Autorisation : TPR = 16 / 16 = 1,00, FPR = 3 / 12 = 0,25.

Ici, une fausse alerte coûte quelques secondes à une personne qui clique sur « approuver » ; une commande dangereuse passée inaperçue peut coûter tout le projet. Avec des coûts aussi asymétriques, il vaut mieux un filtre au rappel élevé, même au prix de fausses alertes — autrement dit l’autorisation.

6. La défense en profondeur

Aucune couche ne suffit à elle seule — on peut convaincre le modèle, contourner le filtre, la personne se fatigue. C’est pourquoi on empile les couches :

• Le modèle — un ajustement pour qu’il refuse les demandes nuisibles et admette son incertitude (la partie sur le RLHF).
• Instructions et séparation des données — un prompt système, les textes du web et des documents marqués comme des données, pas comme des commandes.
• Permissions — des outils avec les droits strictement nécessaires, des listes d’autorisations, des comptes et des clés séparés.
• Isolation — l’agent tourne dans un conteneur ou une machine virtuelle, sans accès à ce dont il n’a pas besoin.
• Humain dans la boucle — l’approbation des étapes irréversibles et inhabituelles.
• Journalisation et contrôle — ce que l’agent a fait peut être retrouvé après coup et annulé (git, sauvegardes, journaux).

P_dommage = p₁ · p₂ · … · p_m

p₁

la probabilité que la première couche laisse passer l’action nuisible (par exemple, le modèle ne la refuse pas)

p₂

la probabilité que la deuxième couche la laisse passer (le filtre de commandes) — on multiplie, car l’action doit franchir toutes les couches

p_m

la dernière couche (isolation, sauvegarde) ; chaque couche supplémentaire avec p < 1 réduit le résultat, même si elle est faible en elle-même

P_dommage

la probabilité que l’action nuisible passe jusqu’au bout

Quatre couches qui laissent chacune passer 10 % des actions nuisibles donnent 0,1⁴ = 0,0001 — une sur dix mille. Mais les couches ne sont généralement pas indépendantes : une prompt injection qui convainc le modèle convainc souvent aussi la personne qui approuve d’après l’explication du modèle. Si les couches deux à quatre se laissaient tromper chaque fois que la première l’est, il resterait P_dommage = 0,1. C’est pourquoi les couches doivent reposer sur des principes différents : le modèle sur le contenu, le filtre sur la syntaxe de la commande, l’isolation sur ce à quoi le processus a accès tout court.

Définition — red teaming et évaluation des capacités dangereuses

Le red teaming est une recherche ciblée des défaillances : des personnes (et de plus en plus souvent d’autres modèles) tentent d’amener le système à faire ce qu’il ne doit pas faire, et les faiblesses trouvées sont corrigées. L’évaluation des capacités dangereuses mesure si le modèle maîtrise des tâches qui pourraient conduire à un dommage grave (par exemple, aider à une cyberattaque), et les grands développeurs renforcent les protections en fonction des résultats avant de publier le modèle.

Aux mesures techniques s’ajoute la régulation. Le règlement européen sur l’intelligence artificielle (AI Act, en vigueur depuis 2024 et appliqué progressivement) classe les systèmes selon le risque : il interdit purement et simplement certaines pratiques et impose des obligations détaillées aux systèmes à haut risque qui décident à propos de personnes — lors d’un recrutement, d’un crédit ou dans la santé.

7. Résumé

• Un benchmark est une interrogation écrite : utile pour comparer, mais d’une précision limitée. Sur 200 tâches, 82 % a un intervalle de 76,1 à 86,7 %.
• Sélectionner d’après le même jeu de test gonfle le résultat : la sélection parmi 100 variantes d’une précision réelle de 70 % annonce 81,1 %.
• La contamination mesure la mémoire au lieu de la capacité ; la fuite de la moitié du test a fait passer la précision de 60 % à 92 %.
• Risques : erreurs, usage abusif, attaques contre le système, actions dangereuses et désalignement des objectifs.
• La liste d’interdictions a arrêté 5 des 16 commandes dangereuses, la liste d’autorisations toutes les 16 — au prix des approbations.
• La sécurité repose sur des couches : modèle, séparation des données, permissions, isolation, humain dans la boucle et journalisation.

Envie de mettre la main à la pâte ? Rédigez dix tâches tirées de votre travail avec leurs bons résultats et demandez à un agent IA de comparer deux modèles dessus — et d’ajouter un intervalle de confiance au résultat. Essayez ensuite d’imaginer trois commandes qui contourneraient le filtre d’interdictions de votre agent.

Vous voyez les choses autrement ? Écrivez à support@coden-app.com.