LANXAS White, Blind Benchmark v2.0, liasse v2-091 à v2-100

Liasse de consultation : copie conforme, octet pour octet, des exécutions gelées du 21 août 2026. Les pages individuelles test-v2-NNN.html restent la référence opposable, chaque réponse est vérifiable par son SHA-256. Aucune ré-exécution, aucune modification.

Index des 12 liasses · Registre officiel

Copie v2-091

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q091 — TLS protège-t-il un mot de passe contre une base de données serveur compromise après son stockage ?

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question précise, qui touche à la distinction fondamentale entre le transport et le stockage des données.

La réponse est non. TLS (Transport Layer Security) protège uniquement le canal de communication entre le client et le serveur, c'est-à-dire le moment où le mot de passe transite sur le réseau. Une fois le mot de passe reçu par le serveur et stocké dans sa base de données, TLS n'exerce plus aucune protection sur lui.

Concrètement, TLS chiffre les données en transit : un attaquant qui intercepte le trafic réseau ne peut pas lire le mot de passe. Mais dès que le serveur a déchiffré la requête pour la traiter, le mot de passe se retrouve en clair dans la mémoire du serveur, puis est traité pour être stocké. Si la base de données est ensuite compromise, TLS ne peut rien contre cela, car il n'intervient plus à ce stade.

La protection du mot de passe au repos repose sur d'autres mécanismes, indépendants de TLS :

D'abord, le hachage avec sel et fonction de dérivation lente (comme bcrypt, scrypt, Argon2) : le mot de passe n'est jamais stocké en clair, mais sous forme d'un condensat non réversible. Ensuite, le chiffrement de la base de données elle-même (chiffrement au repos), qui protège les données stockées si le support physique est volé. Enfin, la gestion des clés et le cloisonnement des accès, qui limitent ce qu'un attaquant peut faire une fois dans le système.

Il faut donc bien distinguer deux menaces distinctes : l'interception du trafic, que TLS neutralise, et la compromission du stockage, que TLS ne couvre pas. Un mot de passe correctement protégé au repos l'est par le hachage salé et non par TLS.

Je précise que cette analyse repose sur des principes de sécurité bien établis et documentés dans la littérature technique (notamment les recommandations du NIST et de l'OWASP sur le stockage des mots de passe). Ma confiance dans cette réponse est de 97 %, car il s'agit d'un fait technique standard et vérifiable, mais je ne peux exclure une nuance marginale dans des architectures très particulières.

En résumé : TLS protège le voyage, pas la destination. Pour la base de données compromise, la défense se joue ailleurs, dans le choix du hachage et la sécurité du stockage.

Copie v2-092

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q092 — Une requête préparée protège-t-elle contre toute forme d’injection dans tous les contextes, y compris les identifiants SQL dynamiques ?

Réponse intégrale (verbatim, hachée ci-dessus)

Votre question porte sur les limites réelles des requêtes préparées face aux injections SQL. Je vais vous répondre avec précision.

**Réponse**

Non. Une requête préparée ne protège pas contre toute forme d'injection dans tous les contextes. Elle protège efficacement contre l'injection dans les valeurs (les paramètres), mais elle ne protège pas, en elle-même, contre l'injection dans les identifiants dynamiques (noms de tables, de colonnes, clauses ORDER BY, etc.).

**Justification**

Une requête préparée fonctionne en séparant la structure SQL (le squelette) des valeurs. Le serveur compile le squelette une fois, puis les paramètres sont transmis séparément, comme des données et non comme du code. C'est pourquoi une valeur paramétrée ne peut pas modifier la structure de la requête : c'est un mécanisme robuste contre l'injection dans les valeurs.

Cependant, ce mécanisme a une limite structurelle : il ne peut paramétrer que des valeurs scalaires (chaînes, nombres, dates). Les identifiants SQL — noms de tables, de colonnes, de schémas, ou encore les clauses dynamiques comme ORDER BY, LIMIT, ou les fragments de requête — ne sont pas des valeurs : ce sont des éléments de structure. La plupart des moteurs SQL refusent de les accepter comme paramètres liés. Par conséquent, si un développeur concatène un identifiant dans le squelette de la requête, la protection de la requête préparée ne s'applique plus du tout à cette partie.

**Contre-exemple concret**

Considérons une application qui trie des résultats selon une colonne choisie par l'utilisateur :

```
SELECT nom, prix FROM produits ORDER BY {colonne}
```

Si le code construit la requête ainsi :

```
"SELECT nom, prix FROM produits ORDER BY " + colonneUtilisateur
```

alors même si le reste de la requête est préparé, la variable `colonneUtilisateur` est insérée dans la structure. Un attaquant pourrait fournir :

```
prix; DROP TABLE produits; --
```

La requête préparée ne peut rien y faire, car l'identifiant n'est pas passé comme paramètre lié. La seule défense correcte est une liste blanche (whitelist) : vérifier que l'identifiant correspond exactement à une valeur autorisée, jamais le concaténer directement.

**Autres limites à signaler**

D'abord, les requêtes préparées ne protègent pas contre les injections dans les procédures stockées qui construisent elles-mêmes du SQL dynamique en interne. Ensuite, elles ne couvrent pas les contextes où le SQL est généré par des ORM de façon non paramétrée, ni les injections de second ordre (une valeur stockée en base puis réutilisée dans une autre requête non préparée). Enfin, une requête préparée ne protège pas contre les autres classes de vulnérabilités (XSS, CSRF, etc.).

**Confiance : 96 %**

Cette confiance est élevée car le raisonnement repose sur le fonctionnement standard et documenté des requêtes préparées dans les principaux moteurs SQL (PostgreSQL, MySQL, SQL Server, Oracle). Je laisse une petite marge car les comportements exacts de paramétrage des identifiants peuvent varier légèrement selon les moteurs et leurs versions, mais le principe général — les identifiants ne sont pas paramétrables — est stable et bien établi.

En résumé, la requête préparée est un rempart excellent pour les valeurs, mais elle n'est ni universelle ni suffisante seule : toute partie structurelle de la requête doit être traitée par validation stricte, idéalement une liste blanche.

Copie v2-093

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q093 — Définir CSRF et expliquer pourquoi SameSite peut réduire le risque sans constituer à lui seul une garantie universelle.

Réponse intégrale (verbatim, hachée ci-dessus)

Madame, Monsieur,

Je vous remercie pour cette question portant sur la sécurité des applications web. Voici une réponse détaillée.

**Définition de CSRF**

CSRF, acronyme de Cross-Site Request Forgery, désigne une attaque dans laquelle un site malveillant amène le navigateur d'une victime authentifiée à envoyer, à son insu, une requête vers un site légitime de confiance. Comme le navigateur joint automatiquement les cookies de session, la requête forgée arrive avec les identifiants valides, et le serveur ne peut pas distinguer cette requête d'une action légitime de l'utilisateur. L'impact typique est l'exécution d'actions sensibles, telles qu'un changement de mot de passe, un virement bancaire ou une modification de profil, sans le consentement de la victime.

Le mécanisme de défense classique repose sur des jetons anti-CSRF, des valeurs aléatoires liées à la session que le serveur exige dans chaque requête modifiante, et que le site attaquant ne peut pas connaître. L'attribut SameSite du cookie de session vient compléter cette défense au niveau du navigateur.

**Fonctionnement de SameSite**

SameSite restreint l'envoi du cookie selon le contexte de la requête. Avec la valeur Strict, le cookie n'est jamais envoyé pour une requête provenant d'un autre site, ce qui neutralise la grande majorité des requêtes CSRF. Avec la valeur Lax, le cookie est envoyé pour les navigations de premier niveau, comme les clics sur un lien ou la saisie d'une URL, mais pas pour les requêtes en arrière-plan telles que les appels fetch, XMLHttpRequest ou les soumissions de formulaires via POST. Cela couvre déjà la plupart des vecteurs d'attaque.

**Limites de SameSite**

Cependant, SameSite ne constitue pas une garantie universelle, pour plusieurs raisons. D'abord, la valeur Lax laisse passer les requêtes GET de premier niveau : une attaque par navigation directe, ou un site qui déclenche une action sensible par simple GET, reste possible. Ensuite, le navigateur est le garant du comportement : un navigateur ancien, non conforme, ou une configuration qui force SameSite=None, nécessaire pour certains usages d'intégration tierce, supprime la protection. Par ailleurs, SameSite ne protège pas contre les attaques qui ne reposent pas sur les cookies, comme celles exploitant d'autres mécanismes d'authentification, par exemple des jetons dans l'URL, une authentification par en-tête personnalisé ou une authentification mutuelle TLS. Enfin, la défense en profondeur reste de mise : un jeton anti-CSRF côté serveur, la vérification de l'en-tête Origin ou Referer, et la validation des méthodes HTTP demeurent des compléments indispensables.

**Conclusion**

En résumé, SameSite réduit fortement la surface d'attaque CSRF en limitant l'envoi automatique des cookies, mais sa portée dépend de la valeur choisie, du navigateur et du contexte d'authentification. Il doit donc être combiné à d'autres contrôles plutôt que considéré comme une protection suffisante à lui seul.

Confiance : 94 %. Cette définition et cette analyse reposent sur des notions standard et bien documentées de la sécurité web, notamment les spécifications des cookies et les recommandations de l'OWASP, que je restitue de mémoire avec une bonne assurance. La marge restante tient à la variabilité des implémentations de navigateurs et aux évolutions récentes des spécifications, que je ne peux pas vérifier ici sans accès à Internet.

Je reste à votre disposition pour toute précision complémentaire.

Cordialement.

Copie v2-094

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q094 — Définir XSS réfléchi, stocké et DOM-based.

Réponse intégrale (verbatim, hachée ci-dessus)

Merci pour cette question portant sur la sécurité des applications web. Voici une définition précise des trois grandes familles de failles XSS (Cross-Site Scripting).

XSS réfléchi (reflected XSS)

Le XSS réfléchi se produit lorsque des données non fiables, généralement issues de la requête HTTP (paramètres d'URL, champs de formulaire), sont renvoyées par le serveur dans la réponse sans avoir été correctement neutralisées. L'attaque est dite réfléchie car le script malveillant fait l'aller-retour : il est envoyé au serveur, qui le renvoie immédiatement dans la page. L'utilisateur doit être piégé pour cliquer sur un lien spécialement construit, souvent via un courriel d'hameçonnage. Le script s'exécute alors dans le contexte de la victime, avec les privilèges de la page légitime.

XSS stocké (stored XSS)

Le XSS stocké, aussi appelé XSS persistant, survient lorsque le script malveillant est enregistré durablement sur le serveur, par exemple dans une base de données, un forum, un champ de commentaire ou un profil utilisateur. À chaque consultation de la page concernée, le script est rejoué et s'exécute chez tous les visiteurs. C'est la variante la plus dangereuse : elle ne nécessite pas de piéger individuellement chaque victime, et elle peut toucher un très grand nombre d'utilisateurs sur une longue période.

XSS DOM-based

Le XSS basé sur le DOM se distingue des deux précédents par le fait que le serveur n'est pas impliqué dans l'injection. Ici, la vulnérabilité réside dans le code JavaScript exécuté côté client, qui lit une source non fiable (par exemple la propriété location.search, location.hash, document.referrer ou document.cookie) et l'écrit dans une destination sensible du DOM (innerHTML, document.write, eval, etc.) sans validation. Le script malveillant est donc construit et exécuté entièrement dans le navigateur de la victime, sans que le serveur ne voie jamais la charge utile.

Éléments de comparaison

La distinction essentielle entre les trois formes tient au lieu où se produit l'injection et à sa persistance. Le XSS réfléchi et le XSS stocké sont des failles côté serveur, la différence étant la persistance (éphémère pour le réfléchi, durable pour le stocké). Le XSS DOM-based est une faille purement côté client, indépendante du traitement serveur. Toutes trois partagent le même objectif final : exécuter du code arbitraire dans le contexte de confiance de la victime, ce qui peut conduire au vol de session, à la capture de données sensibles ou à la compromission de la page.

Confiance : 92 %. Cette définition repose sur des notions standard et bien établies de la sécurité des applications web, que je connais avec une grande fiabilité. La marge restante tient au fait que je l'énonce de mémoire, sans source consultable dans cette conversation, et que les frontières entre ces catégories peuvent parfois se recouper dans des cas pratiques complexes.

Je reste à votre disposition pour approfondir les mécanismes de détection ou les contre-mesures associées à chacune de ces failles.

Copie v2-095

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q095 — Une CSP HTTP (Content-Security-Policy) correctement configurée peut-elle réduire l’impact des XSS ? Peut-elle remplacer l’encodage contextuel ?

Réponse intégrale (verbatim, hachée ci-dessus)

Oui, une CSP correctement configurée peut réduire significativement l’impact des XSS, mais elle ne peut pas remplacer l’encodage contextuel.

Une CSP agit comme une couche de défense en profondeur. Elle ne supprime pas la vulnérabilité elle-même, mais elle limite ce qu’un attaquant peut faire une fois qu’un script malveillant a réussi à s’exécuter. Concrètement, une politique stricte comme `default-src 'self'` ou `script-src 'self'` empêche l’exécution de scripts inline et de scripts provenant de domaines tiers, ce qui neutralise la plupart des payloads XSS classiques, notamment les balises `<script>`, les gestionnaires d’événements inline et les URLs `javascript:`. C’est pourquoi la CSP est considérée comme un contrepoids efficace : elle réduit la surface d’exploitation et la portée des dégâts.

Cependant, elle ne peut pas remplacer l’encodage contextuel, et ce pour plusieurs raisons.

D’abord, la CSP n’est pas une garantie absolue. Des failles de contournement ont été documentées, par exemple via des gadgets de type JSONP sur des domaines autorisés, ou des injections dans des attributs non couverts par la politique. Une politique trop permissive, ou mal écrite, peut laisser passer des vecteurs d’attaque.

Ensuite, et c’est le point décisif, la CSP ne traite pas la cause du XSS. L’encodage contextuel, lui, s’applique au point d’émission : il transforme les données utilisateur selon le contexte précis où elles sont insérées, qu’il s’agisse de HTML, d’un attribut, de JavaScript, de CSS ou d’une URL, de sorte que les caractères dangereux ne puissent jamais être interprétés comme du code. C’est la seule mesure qui rend l’injection structurellement impossible, indépendamment de la politique de sécurité.

Enfin, la CSP ne couvre pas tous les contextes d’injection. Par exemple, une injection dans un attribut `href` ou dans un contexte CSS peut parfois échapper à la politique. L’encodage contextuel, lui, est exhaustif par construction.

La CSP est donc un complément précieux, voire indispensable, mais elle relève de la défense en profondeur. L’encodage contextuel reste la défense primaire et non négociable contre les XSS. Les deux mesures sont complémentaires, jamais substituables.

Confiance : 92 %. Cette réponse repose sur des principes de sécurité web bien établis et documentés, notamment par l’OWASP et les recommandations du W3C sur la CSP. La confiance n’est pas à 100 % car je ne peux pas vérifier ici chaque cas de contournement historique ni chaque nuance des spécifications, mais le fondement conceptuel, à savoir la CSP comme mesure de mitigation et non de prévention structurelle, est solidement établi.

Copie v2-096

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q096 — Un modèle obtient log-loss meilleure mais accuracy légèrement inférieure à un autre. Peut-on déclarer un gagnant universel ?

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui touche à un point délicat de l'évaluation des modèles de classification.

La réponse est non : on ne peut pas déclarer de gagnant universel sur la seule base de ces deux métriques, et voici pourquoi.

D'abord, le log-loss et l'accuracy mesurent des choses différentes. Le log-loss (ou perte logarithmique) évalue la qualité des probabilités prédites : il pénalise d'autant plus une prédiction qu'elle est confiante et fausse. L'accuracy, elle, ne compte que le nombre de prédictions dont l'étiquette la plus probable est correcte, sans tenir compte de la confiance. Un modèle peut donc avoir un meilleur log-loss parce qu'il est mieux calibré ou plus prudent, tout en se trompant sur un peu plus d'échantillons marginaux.

Ensuite, ces deux métriques ne sont pas nécessairement concordantes. Il est tout à fait possible qu'un modèle A ait un log-loss inférieur à B tout en ayant une accuracy inférieure. Cela arrive notamment quand A produit des probabilités plus fines et mieux calibrées, mais que B, plus grossier, gagne sur les cas proches du seuil de décision. Aucune des deux métriques ne domine l'autre en général.

Enfin, le choix du « gagnant » dépend de l'usage. Si l'application exige des probabilités fiables (par exemple pour un tri par risque, une décision économique ou un système de recommandation), le log-loss est le critère pertinent. Si l'application ne retient que l'étiquette finale (par exemple un classement binaire simple), l'accuracy peut être plus parlante. Il faudrait aussi considérer d'autres métriques selon le contexte : précision, rappel, F1, AUC, coût d'erreur asymétrique, etc.

Il faut par ailleurs signaler une prémiesse implicite : on compare deux modèles sur un même jeu de test. Si les jeux diffèrent, la comparaison n'a aucun sens. Et une différence d'accuracy très faible peut n'être pas statistiquement significative ; il conviendrait de vérifier par un test approprié (par exemple un test de McNemar sur les paires d'erreurs).

En résumé, sans préciser l'objectif applicatif, la métrique prioritaire et la significativité statistique, aucun gagnant universel ne peut être déclaré. La réponse honnête est : cela dépend du critère de décision retenu.

Confiance : 96 %. Cette conclusion repose sur des propriétés bien établies des fonctions de perte et des métriques de classification, mais le chiffre exact de confiance reflète que le choix final reste toujours contextuel et qu'aucune règle mathématique ne tranche universellement entre deux métriques non concordantes.

Copie v2-097

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q097 — Définir Expected Calibration Error et citer au moins une limite de cette métrique.

Réponse intégrale (verbatim, hachée ci-dessus)

Madame, Monsieur,

Je vous remercie pour cette question portant sur l'Expected Calibration Error, une métrique centrale en apprentissage automatique pour évaluer la fiabilité des probabilités prédites.

**Définition de l'Expected Calibration Error (ECE)**

L'Expected Calibration Error mesure l'écart moyen entre la confiance qu'un modèle de classification attribue à ses prédictions et sa précision effective. Pour la calculer, on partitionne l'intervalle de confiance [0, 1] en M intervalles de même largeur, appelés bins. Pour chaque bin B_m, on détermine deux quantités : la confiance moyenne des prédictions qui y sont associées, notée conf(B_m), et la précision réelle, c'est-à-dire la proportion de prédictions correctes parmi ces mêmes exemples, notée acc(B_m). L'ECE est alors la moyenne pondérée des écarts absolus entre ces deux valeurs :

ECE = Σ_{m=1}^{M} (|B_m| / N) × |acc(B_m) − conf(B_m)|

où N désigne le nombre total d'exemples et |B_m| le nombre d'exemples dans le bin m. Une ECE nulle correspond à un calibrage parfait, où la confiance prédite coïncide exactement avec la fréquence de correction.

**Limites de la métrique**

Plusieurs limites sont documentées dans la littérature, notamment par Guo et al. (2017) et par des travaux ultérieurs sur les métriques de calibrage.

D'abord, le choix du nombre de bins M influence fortement la valeur de l'ECE. Avec peu de bins, on lisse les écarts et on sous-estime la miscalibration ; avec beaucoup de bins, l'estimation devient bruitée, surtout si certains bins contiennent peu d'exemples. La métrique n'est donc pas stable d'un réglage à l'autre.

Ensuite, l'ECE utilise une valeur absolue, ce qui masque le signe de l'erreur de calibrage : un modèle qui surestime systématiquement sa confiance et un modèle qui la sous-estime peuvent produire la même ECE, alors que leurs comportements sont très différents en pratique.

Par ailleurs, l'ECE est sensible à la distribution des prédictions. Un modèle qui concentre ses prédictions dans une zone de confiance étroite peut afficher une ECE faible simplement parce que les bins extrêmes sont vides, sans que cela reflète un bon calibrage global.

Enfin, la métrique ne distingue pas les classes : en classification multi-classe, elle agrège les erreurs de toutes les classes, ce qui peut masquer une miscalibration sévère sur une classe minoritaire.

**Confiance : 92 %.** La définition et les limites énoncées correspondent à la formulation standard de l'ECE telle qu'introduite par Naeini et al. (2015) et popularisée par Guo et al. (2017) ; je reste légèrement en deçà de la certitude totale car je récite ces éléments de mémoire, sans pouvoir vérifier ici les formulations exactes des articles cités.

Je vous prie d'agréer, Madame, Monsieur, l'expression de ma considération distinguée.

Copie v2-098

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q098 — Pourquoi l’AUROC peut-elle être trompeuse sur un problème extrêmement déséquilibré ?

Réponse intégrale (verbatim, hachée ci-dessus)

Madame, Monsieur,

Vous avez tout à fait raison de souligner que l’AUROC peut être trompeuse sur un problème extrêmement déséquilibré. Permettez-moi de développer ce point avec précision.

L’AUROC, ou aire sous la courbe ROC, mesure la capacité d’un modèle à classer correctement les individus positifs par rapport aux négatifs, indépendamment du seuil de décision choisi. Elle est en effet insensible à la prévalence, c’est-à-dire à la proportion réelle de la classe minoritaire dans la population. Cette insensibilité constitue la source principale de son caractère trompeur dans les contextes fortement déséquilibrés.

Pour comprendre le problème, examinons la construction de la courbe ROC. Celle-ci trace le taux de vrais positifs, c’est-à-dire le rappel, en fonction du taux de faux positifs. Or, le taux de faux positifs est calculé en divisant le nombre de faux positifs par le nombre total de négatifs. Lorsque les négatifs sont extrêmement nombreux, un modèle peut produire un très grand nombre absolu de faux positifs tout en conservant un taux de faux positifs faible, simplement parce que le dénominateur est immense. L’AUROC, qui agrège ces taux sur tous les seuils possibles, ne reflète alors pas la qualité pratique des prédictions.

Prenons un exemple chiffré pour illustrer ce phénomène. Supposons un jeu de données de un million d’échantillons, dont mille positifs et neuf cent quatre-vingt-dix-neuf mille négatifs. Un modèle qui classe correctement les mille positifs mais produit quarante-neuf mille neuf cent cinquante faux positifs, soit cinq pour cent des négatifs, obtient un taux de vrais positifs de un et un taux de faux positifs de zéro virgule zéro cinq. Son AUROC peut être très élevé, de l’ordre de zéro virgule quatre-vingt-dix-sept ou plus. Pourtant, en pratique, ce modèle génère cinquante mille neuf cent cinquante prédictions positives, dont seulement mille sont correctes. La précision, c’est-à-dire la proportion de vrais positifs parmi les prédictions positives, est alors de mille divisé par cinquante mille neuf cent cinquante, soit environ deux pour cent. Autrement dit, un utilisateur qui suivrait les prédictions positives du modèle se tromperait dans environ quatre-vingt-dix-huit pour cent des cas. L’AUROC, qui paraît excellent, masque totalement cette réalité.

La raison profonde de cette tromperie réside dans le fait que l’AUROC mesure uniquement la capacité de classement relatif : elle évalue si un positif tiré au hasard a un score plus élevé qu’un négatif tiré au hasard. Elle ne dit rien sur la valeur absolue des prédictions ni sur la proportion de vrais positifs parmi les prédictions positives. Elle ne pondère jamais les performances par la prévalence, ce qui la rend inadaptée pour juger de l’utilité pratique d’un modèle sur un problème fortement déséquilibré.

Pour de tels problèmes, des métriques plus pertinentes sont la précision, le rappel, le F1-score, la courbe précision-rappel et son aire, ainsi que le score de Brier. La courbe précision-rappel est particulièrement adaptée car elle intègre directement la prévalence dans son calcul, en mettant l’accent sur la performance du modèle sur la classe minoritaire.

Il convient toutefois de nuancer. L’AUROC n’est pas fausse en soi ; elle répond à une question précise, celle du classement relatif. Elle devient trompeuse lorsqu’on l’interprète comme une mesure de la qualité pratique des prédictions sur un problème déséquilibré, ce qui constitue une erreur d’interprétation fréquente. En conclusion, l’AUROC doit être utilisée avec prudence et complétée par des métriques adaptées au contexte déséquilibré.

Confiance : 95 pour cent. La démonstration repose sur des définitions standard de l’AUROC et de la précision, et l’exemple chiffré est vérifiable : avec mille vrais positifs et quarante-neuf mille neuf cent cinquante faux positifs, la précision vaut mille divisé par cinquante mille neuf cent cinquante, soit environ deux pour cent, ce qui illustre bien le décalage entre un AUROC élevé et une utilité pratique médiocre.

Je vous prie d’agréer, Madame, Monsieur, l’expression de mes salutations distinguées.

Copie v2-099

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q099 — Une température softmax plus faible améliore-t-elle nécessairement la calibration ?

Réponse intégrale (verbatim, hachée ci-dessus)

Merci pour cette question, qui touche à un point essentiel de la pratique des modèles de langage.

La réponse est non : une température softmax plus faible n'améliore pas nécessairement la calibration, et peut même la dégrader dans certains cas. Il faut distinguer deux notions que l'on confond souvent.

D'abord, la température modifie la forme de la distribution de probabilité : une température inférieure à 1 resserre la distribution autour de son maximum, rendant le modèle plus confiant, tandis qu'une température supérieure à 1 l'aplatit, rendant le modèle plus hésitant. La calibration, elle, mesure l'adéquation entre la confiance déclarée et la fréquence réelle de correction : un modèle est bien calibré si, parmi toutes les prédictions auxquelles il attribue une probabilité de 80 %, environ 80 % sont effectivement correctes.

Le point essentiel est que la température est un paramètre de post-traitement qui ne modifie pas l'ordre des logits ni la capacité intrinsèque du modèle. Elle ne peut donc pas corriger une mauvaise calibration de fond : elle ne fait que déplacer la courbe de confiance. Si le modèle est déjà surconfiant, baisser la température aggrave le problème en le rendant encore plus confiant. Si le modèle est sous-confiant, baisser la température peut au contraire l'aider. Autrement dit, l'effet dépend entièrement du signe du biais initial, et il n'existe pas de valeur de température qui soit universellement bonne.

On peut le voir par un exemple simple. Supposons un modèle dont les logits donnent, pour une classe correcte, une probabilité softmax de 0,6 alors que le taux de correction réel est de 0,8 : le modèle est sous-confiant. En abaissant la température, on peut amener la probabilité déclarée vers 0,8 et améliorer la calibration. En revanche, si le modèle déclare 0,9 alors que le taux réel est de 0,7, il est surconfiant, et abaisser la température éloigne encore la confiance déclarée de la fréquence réelle : la calibration se dégrade.

La littérature sur le sujet confirme cette analyse. Le travail de Guo et ses collègues sur la calibration des réseaux de neurones, publié en 2017, montre précisément que la température optimale doit être apprise sur un ensemble de validation et qu'elle peut être supérieure ou inférieure à 1 selon le modèle et la tâche. Une température de 1 n'est pas optimale en général, et une température inférieure à 1 n'est pas non plus systématiquement bénéfique. La bonne pratique consiste à estimer la température qui minimise une mesure de calibration, comme l'erreur de calibration attendue, sur des données de validation.

Il faut aussi noter que la température a des effets secondaires : une température très basse dégrade la diversité et la qualité des échantillons générés, et peut conduire à des répétitions ou à des sorties trop déterministes. La calibration n'est donc qu'un critère parmi d'autres dans le choix de ce paramètre.

En résumé, la température est un outil de recalibrage utile, mais son effet est conditionnel au biais initial du modèle. Elle ne garantit jamais une amélioration, et son réglage doit être validé empiriquement sur des données de validation plutôt que supposé par principe.

Confiance : 92 %. Cette réponse repose sur des résultats établis de la littérature sur la calibration, notamment le travail de Guo et al. de 2017, et sur un raisonnement formellement vérifiable concernant l'effet de la température sur la distribution softmax. Je n'ai pas vérifié ici les valeurs numériques exactes des expériences publiées, d'où une confiance légèrement inférieure à la certitude. Le principe général, lui, est robuste : la température ne corrige pas un biais de calibration dont le signe lui est défavorable.

Copie v2-100

Question (verbatim)

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire.

Q100 — Une baisse de perplexité garantit-elle une baisse du taux d’hallucination factuelle ?

Réponse intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui touche à un point délicat de l'évaluation des modèles de langue.

Réponse : Non, une baisse de perplexité ne garantit pas une baisse du taux d'hallucination factuelle.

Justification.

La perplexité mesure la capacité d'un modèle à prédire correctement la suite d'un texte, c'est-à-dire sa fluidité et sa vraisemblance locale. Elle est calculée comme l'exponentielle de l'entropie croisée moyenne sur une séquence. Or l'hallucination factuelle est un défaut de véracité : le modèle produit une affirmation fausse, non étayée ou inventée, avec une grande fluidité.

Ces deux grandeurs ne sont pas corrélées de façon monotone. Un modèle peut voir sa perplexité baisser, c'est-à-dire devenir plus fluide et plus confiant dans ses prédictions, tout en hallucinant davantage, précisément parce que la fluidité accrue rend les affirmations fausses plus plausibles et plus difficiles à détecter. À l'inverse, un modèle plus prudent, qui refuse de répondre ou qui hésite, peut avoir une perplexité plus élevée tout en produisant moins d'hallucinations factuelles.

On peut illustrer cela par un contre-exemple conceptuel : un modèle entraîné à imiter parfaitement le style d'un texte contenant des affirmations fausses répétées aura une perplexité très basse sur ce texte, tout en reproduisant fidèlement les erreurs factuelles. La perplexité optimise la vraisemblance, pas la vérité.

Précision importante. La perplexité est une mesure intrinsèque, qui ne dépend que du modèle et du texte, tandis que l'hallucination factuelle est une mesure extrinsèque, qui exige une référence externe, comme une base de connaissances ou une vérification humaine ou automatique. Il n'existe donc aucun lien formel, démontrable, entre les deux. Les études empiriques montrent d'ailleurs que des modèles à perplexité comparable peuvent avoir des taux d'hallucination très différents, et que des techniques réduisant l'hallucination, comme la génération contrainte ou la vérification externe, n'améliorent pas nécessairement la perplexité.

Confiance : 92 %. Ce résultat est un fait bien établi de la littérature sur l'évaluation des modèles de langue, mais je ne peux pas citer ici une référence précise sans risque d'en inventer une, et la formulation exacte des études empiriques varie. La conclusion logique, à savoir l'absence de lien formel entre vraisemblance et véracité, est, elle, certaine à un niveau plus élevé, mais je préfère calibrer l'ensemble à 92 % en raison de la part empirique de l'affirmation.

En résumé : la perplexité mesure la fluidité, l'hallucination mesure la vérité ; ce sont deux dimensions orthogonales, et rien ne garantit qu'améliorer l'une améliore l'autre.