Liasse v2-091 à v2-100

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 : Non. Justification : Le protocole TLS (Transport Layer Security) assure la confidentialité et l'intégrité des données uniquement pendant leur transit entre un client et un serveur. Dès que le mot de passe est réceptionné par le serveur et écrit dans la base de données, la session TLS se termine et n'a plus aucun effet sur les données stockées. La protection d'un mot de passe après son enregistrement relève exclusivement des mécanismes de sécurité au repos, tels que le hachage cryptographique irréversible avec sel, le chiffrement des bases de données, la gestion fine des privilèges d'accès, la journalisation et les sauvegardes sécurisées. Une base de données compromise expose directement les informations qu'elle contient, indépendamment de l'utilisation de TLS lors de la transmission. La prémisse selon laquelle TLS protégerait un mot de passe une fois stocké est donc fausse. Confiance : 100 %

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 : Non. Justification : La prémisse selon laquelle une requête préparée protège contre toute forme d'injection dans tous les contextes est fausse. Les requêtes préparées neutralisent efficacement les injections SQL classiques en séparant strictement la structure de la requête des données saisies. Les paramètres sont traités exclusivement comme des valeurs littérales, ce qui empêche leur interprétation comme du code exécutable. Cette protection présente cependant des limites techniques et contextuelles avérées. Premièrement, les identifiants SQL dynamiques (noms de tables, noms de colonnes, clauses ORDER BY, LIMIT, OFFSET) ne peuvent pas être paramétrés dans le standard SQL. Si ces éléments sont construits par concaténation de chaînes à partir d'entrées utilisateur non validées, une injection reste directement possible. Deuxièmement, les requêtes préparées ne protègent pas contre les injections du second ordre, qui surviennent lorsque des données précédemment stockées sont réinjectées dans une requête reconstruite dynamiquement sans mécanisme de préparation. Troisièmement, elles n'offrent aucune défense contre d'autres familles d'injection (injection de commandes, injection NoSQL, injection XML, injection LDAP, etc.). Une défense robuste repose sur l'association des requêtes préparées pour les données avec une validation stricte par liste blanche pour les identifiants dynamiques, ainsi que sur l'écriture de requêtes statiques chaque fois que le langage et le moteur de base de données le permettent. Confiance : 100 %.

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.

**Définition de CSRF** CSRF signifie Cross-Site Request Forgery. Il s'agit d'une attaque web par laquelle un site tiers contraint un navigateur à exécuter une action non désirée auprès d'un site cible sur lequel l'utilisateur possède une session active. L'attaquant ne cherche pas à voler les identifiants de la victime, mais à exploiter la confiance du site cible envers la session existante. Le mécanisme repose sur l'envoi automatique de requêtes incluant les cookies d'authentification, les en-têtes de session ou les jetons persistants, sans interaction consciente de l'utilisateur. **Effet de l'attribut SameSite sur la réduction du risque** L'attribut HTTP SameSite s'applique aux cookies et indique au navigateur s'il doit les transmettre lors de requêtes provenant d'un contexte différent. Les valeurs Strict et Lax restreignent l'envoi des cookies aux seuls appels initiés par le même site ou, pour Lax, aux navigations de premier niveau. En empêchant le navigateur d'associer automatiquement les cookies de session à des requêtes cross-origin générées par un site malveillant, SameSite supprime le vecteur d'exécution principal du CSRF. Le serveur cible ne reçoit plus les identifiants nécessaires pour valider la demande frauduleuse, ce qui bloque la plupart des scénarios classiques. **Limites empêchant SameSite d'être une garantie universelle** Premièrement, SameSite ne protège que les cookies. Les applications qui utilisent d'autres mécanismes de liaison de session, tels que les en-têtes Authorization, les paramètres d'URL ou des cookies personnalisés mal configurés, restent exposées si ces vecteurs ne sont pas également restreints. Deuxièmement, la compatibilité et le comportement par défaut varient selon les navigateurs et les versions. Certains environnements anciens ignorent l'attribut, appliquent des interprétations différentes ou comportent des anomalies d'implémentation qui rétablissent implicitement l'envoi cross-origin. Troisièmement, une configuration incorrecte annule la protection. La valeur SameSite=None réactive explicitement le partage de cookies inter-sites, tandis que le mode Lax autorise les requêtes GET de premier niveau cross-origin. Si le serveur accepte des actions modifiant l'état via GET, ce vecteur peut être abusé malgré la présence de l'attribut. Quatrièmement, l'attaque peut contourner la restriction par d'autres moyens. Des erreurs de configuration CORS, l'exploitation de fonctionnalités navigateur spécifiques, ou l'usage de techniques de contournement comme les formulaires auto-remplis ou les redirections multipartites peuvent permettre l'envoi de requêtes sans cookies, voire avec des mécanismes alternatifs non protégés par SameSite. Enfin, la sécurité informatique exige une approche défensive en profondeur. Se reposer sur un seul mécanisme crée un point de défaillance unique. Les bonnes pratiques recommandent de combiner SameSite avec des jetons CSRF synchrones, la vérification des en-têtes Origin et Referer, la restriction stricte des méthodes HTTP sécurisées, et la validation rigoureuse des entrées. **Justification** La réponse découle directement du fonctionnement des cookies HTTP, du modèle de menace CSRF et des spécifications techniques relatives aux attributs de session. Aucun chiffre, référence externe, DOI ou résultat expérimental n'est inventé. Les limites identifiées correspondent aux contraintes techniques réelles de l'attribut et aux réalités d'implémentation navigateur. L'hypothèse selon laquelle SameSite alone garantirait une protection complète constitue une prémisse fausse, explicitement signalée ci-dessus. Aucune donnée insuffisante n'a été rencontrée, et le cas est entièrement déterminable sur la base des mécanismes web standards. **Confiance : 95 %**

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 :** 1. XSS réfléchi : Le code malveillant est transmis par le client au serveur via une requête HTTP. Le serveur intègre cette entrée directement dans la réponse sans la conserver. Le script s'exécute lorsque le navigateur du destinataire analyse la réponse non validée. 2. XSS stocké : Le code malveillant est enregistré de manière persistante sur le serveur cible, par exemple dans une base de données ou un champ de formulaire. Toute requête ultérieure pour afficher la page concernée entraîne l'insertion du script dans la réponse serveur et son exécution dans le navigateur de chaque utilisateur concerné. 3. XSS DOM-based : La vulnérabilité réside exclusivement dans le code JavaScript côté client. Le vecteur provient d'une source du DOM (telles que location.hash, document.referrer, URLSearchParams ou document.cookie). Une fonction cliente interprète cette donnée non fiable pour modifier le DOM sans désinfection préalable. Le payload n'est pas nécessairement envoyé au serveur. **Justification :** La classification technique repose sur trois critères architecturaux : le trajet des données, la persistance du vecteur et l'emplacement du point d'exécution. Le XSS réfléchi correspond à un parcours immédiat client serveur client sans conservation persistante. Le XSS stocké implique une persistance côté serveur et une exposition récurrente à tous les consommateurs de la ressource. Le XSS DOM-based se définit par l'absence de traversée du serveur et par l'exécution déclenchée par une manipulation unsafe du DOM en JavaScript, où la source du vecteur est une propriété du document ou de la fenêtre courante. Ces définitions correspondent aux mécanismes établis dans les standards de sécurité web applicative. Aucune donnée, référence, DOI ou résultat n'est inventé ; les descriptions reposent sur les principes architecturaux reconnus des navigateurs et des serveurs web. Les prémisses sont valides et les informations sont suffisantes pour une définition technique précise. **Confiance :** 100 %

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 : Oui, une CSP correctement configurée peut réduire significativement l'impact des attaques XSS. Non, elle ne peut pas remplacer l'encodage contextuel. Justification : La Content-Security-Policy opère comme une mesure de défense en profondeur. En restreignant les sources autorisées pour le chargement de ressources, en bloquant par défaut les scripts en ligne et en limitant certaines expressions JavaScript, elle réduit la surface d'exploitation d'une vulnérabilité XSS. Lorsqu'une injection parvient à injecter du code dans la page, la CSP empêche souvent son exécution ou confine ses effets à des domaines non sensibles, diminuant ainsi le risque de vol de données, de takeover de session ou de propagation malware. Cependant, la CSP ne constitue pas un substitut à l'encodage contextuel. L'encodage contextuel est une mesure préventive primaire qui transforme les données entrées ou stockées à la sortie en fonction du contexte de rendu spécifique (texte HTML, attribut, bloc JavaScript, style CSS, URL). Il neutralise les caractères réservés avant que le navigateur ne les interprète, traitant ainsi le problème à la racine. La CSP intervient en aval et repose sur des règles d'analyse qui présentent des limites structurelles : nécessité d'exceptions pour certaines architectures complexes, impossibilité de garantir une couverture exhaustive des vecteurs DOM-based XSS, et sensibilité aux contournements liés aux algorithmes de parsing du navigateur ou à des extensions tierces. Les standards et guides de sécurité web reconnus indiquent que la CSP complète l'encodage de sortie sans jamais le remplacer. Une application dont la sécurité reposerait uniquement sur la CSP exposerait des failles résiduelles, notamment lorsque les données utilisateur sont insérées dans des contextes non couverts par les directives de la politique ou lorsque des mécanismes de désérialisation ou de manipulation directe du DOM contournent les restrictions statiques. Prémisse signalée : La prémisse selon laquelle une CSP pourrait remplacer l'encodage contextuel est fausse. La réduction d'impact est validée, mais la substitution est impossible en raison de différences fondamentales de positionnement dans la chaîne de sécurité et de mécanismes d'action. Confiance : 98 %.

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 : Non, il est impossible de déclarer un gagnant universel dans cette situation. Justification : La log-loss et l'accuracy mesurent des propriétés mathématiquement distinctes d'un modèle de classification probabiliste. La log-loss, ou entropie croisée, évalue la fidélité des probabilités prédites par rapport aux étiquettes réelles. Elle pénalise de manière logarithmique les erreurs de calibration et récompense les modèles qui quantifient correctement leurs incertitudes. L'accuracy, en revanche, ne retient que la classe prédite après application d'un seuil de décision fixe, généralement 0,5, et ignore totalement la confiance associée à chaque sortie. Un modèle peut obtenir une log-loss supérieure tout en présentant une accuracy légèrement inférieure lorsque ses probabilités sont mieux calibrées mais que la répartition des seuils optimaux diffère, ou lorsque le jeu de données présente un déséquilibre de classes, une distribution de risque asymétrique, ou une complexité qui rend le seuil 0,5 sous-optimal. Aucune métrique n'est universellement supérieure. Le choix d'un modèle doit reposer sur la fonction de coût réelle du déploiement, la tolérance aux fausses alertes ou aux manques de détection, la criticité de la calibration probabiliste, et les contraintes opérationnelles. Dans un contexte où les probabilités alimentent un système de prise de décision séquentielle, un calcul de risque actuariel, ou une politique de seuillage dynamique, la log-loss prime. Dans un contexte où seule la décision binaire compte et où les erreurs sont symétriquement pénalisées, l'accuracy peut suffire. Sans préciser ces éléments, toute affirmation de gagnant universel repose sur une prémisse fausse : l'idée qu'une seule mesure résume à elle seule la performance opérationnelle. Les informations fournies sont par ailleurs insuffisantes pour trancher, car elles omettent la distribution des classes, la matrice de coût, le niveau de déséquilibre, et l'usage final du modèle. Confiance : 95 %

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.

**Définition** L'Expected Calibration Error (ECE) est une métrique évaluant la calibration d'un classifieur probabiliste. Elle quantifie l'écart moyen entre la confiance prédite par le modèle et la fréquence empirique de succès des prédictions. Dans sa formulation la plus répandue, l'ECE s'exprime comme la moyenne pondérée des écarts absolus entre l'accuracy et la confiance moyenne dans chaque intervalle de confiance : ECE = Σ (|S_k|/N) × |acc_k − conf_k| où N désigne le nombre total d'échantillons, S_k l'ensemble des échantillons du k-ième intervalle, acc_k la proportion de prédictions correctes dans cet intervalle, et conf_k la moyenne des probabilités prédites pour ces échantillons. **Limite** Une limite fondamentale de cette métrique réside dans sa dépendance au schéma de binning. Le nombre d'intervalles, leur largeur et leur méthode de construction (fixe, par quantiles ou adaptative) modifient significativement la valeur calculée. Cette sensibilité rend les comparaisons objectives entre modèles ou entre études peu robustes, car une même distribution de prédictions peut produire des scores ECE très différents selon le paramétrage retenu. **Justification** La discrétisation permet d'approximer l'espérance mathématique de l'écart entre confiance et réalité, mais elle introduit une approximation qui masque les variations locales. Deux modèles peuvent afficher le même ECE global tout en présentant des comportements de calibration divergents au sein d'un même intervalle. Cette propriété est documentée dans les travaux sur l'évaluation des probabilités calibrées et a motivé l'émergence de variantes (comme l'Adaptive ECE ou les méthodes basées sur la régression isotone) qui cherchent à atténuer l'artefact induit par le choix arbitraire des bornes. **Confiance** 95 % (la définition standard est bien établie en apprentissage automatique, mais plusieurs variantes algorithmiques coexistent dans la littérature, ce qui justifie une marge de prudence sur la valeur exacte sans préciser la variante retenue).

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 : L’AUROC peut être trompeuse sur un problème extrêmement déséquilibré car elle repose sur le taux de fausses alarmes, qui est normalisé par le nombre total d’instances négatives. Dans un jeu de données fortement déséquilibré, ce dénominateur est très élevé, ce qui rend le taux artificiellement faible même en présence d’un nombre important de fausses classifications positives. L’aire sous la courbe reflète alors une capacité de classement apparente sans tenir compte de la distribution réelle des classes ni de la précision des prédictions positives. Justification : L’AUROC mesure la probabilité qu’un classifieur attribue un score plus élevé à une instance positive tirée au hasard qu’à une instance négative tirée au hasard. La courbe ROC est tracée en faisant varier le seuil de décision et en représentant le taux de vrais positifs en fonction du taux de fausses alarmes. Ce dernier est défini par la relation FPR = FP / (FP + TN), où FP désigne les fausses positives et TN les vrais négatifs. Sur un problème extrêmement déséquilibré, le nombre de vrais négatifs TN est dominant. Par conséquent, une quantité non négligeable de fausses positives peut entraîner un FPR extrêmement faible, car FP est divisé par une somme très grande. La courbe ROC monte rapidement vers le coin supérieur gauche, ce qui génère une aire proche de 1,00 et suggère une performance excellente. Cette métrique ignore cependant complètement la proportion de prédictions positives parmi toutes les prédictions positives (précision) et la rareté effective des positives. La métrique AUPRC est généralement plus révélatrice dans ce contexte, car elle ne dépend pas du nombre d’instances négatives et se concentre sur la capacité du modèle à identifier correctement les rares positives sans générer excessivement de fausses alarmes. Vérification numérique : considérons un jeu de données avec N = 10 000 instances négatives et P = 10 instances positives. Si un modèle classe 50 instances comme positives dont 40 sont effectivement fausses, alors FP = 40 et TN = 9 950. Le calcul donne FPR = 40 / 10 000 = 0,004. Le taux de fausses alarmes reste très faible, l’AUROC sera élevée, mais la précision sera de 10 / 50 = 0,20. Une précision de 20 % est généralement inacceptable pour la plupart des applications pratiques, ce qui confirme que l’AUROC masque ici une performance réelle médiocre. Niveau de confiance : 95 %. Signalisation des consignes : aucune prémisse fausse n’est identifiée dans la question. Les informations fournies sont suffisantes pour une réponse théorique standard. Le cas n’est pas indéterminable.

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 : Non, une température softmax plus faible n’améliore pas nécessairement la calibration. Justification : La calibration correspond à la concordance entre les probabilités prédites et les fréquences empiriques observées. L’ajustement de la température T transforme les logits z en z/T avant l’application de la fonction softmax. Une température inférieure à 1 rend la distribution de probabilité plus pointue, ce qui augmente la confiance des prédictions. À l’inverse, une température supérieure à 1 aplatit la distribution et réduit la confiance. Les réseaux de neurones profonds modernes présentent presque systématiquement un biais de surconfiance : leurs probabilités prédites dépassent les accuracies empiriques. Dans ce contexte répandu, abaisser la température amplifie la surconfiance et détériore la calibration. Une température plus faible n’améliore la calibration que si le modèle est initialement sous-confiant, situation beaucoup plus rare. La direction de l’amélioration dépend donc de l’état calibrationnel initial, et non d’une règle universelle. La prémisse selon laquelle une température plus faible améliore systématiquement la calibration est fausse. Vérification symbolique d’un contre-exemple : considérons des logits z = [2; 0]. Pour T = 1, la probabilité de la première classe vaut exp(2) / (exp(2) + exp(0)) ≈ 0,881. Si la fréquence réelle de cette classe est de 0,60, le modèle est sous-confiant. Avec T = 0,5, la probabilité devient exp(4) / (exp(4) + exp(0)) ≈ 0,982. L’écart à la fréquence réelle augmente, ce qui dégrade la calibration. Inversement, si la fréquence réelle était de 0,02, le modèle serait surconfiant ; abaisser la température aggraverait l’erreur, tandis que l’augmenter la réduirait. Confiance : 98 %

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 : Non. Justification : La perplexité est une mesure statistique de l’incertitude d’un modèle de langage sur la distribution des données d’entraînement. Une baisse de perplexité indique que le modèle attribue une probabilité plus élevée aux séquences observées, mais elle n’évalue en rien la véracité ou l’ancrage factuel des énoncés générés. L’hallucination factuelle correspond à la production d’informations plausibles linguistiquement mais incorrectes sur le plan factuel. Ces deux grandeurs opèrent dans des espaces conceptuels distincts : la perplexité relève de la modélisation probabiliste des tokens, tandis que l’exactitude factuelle dépend de la capacité du modèle à aligner ses sorties avec la réalité ou des connaissances vérifiables. Aucune relation de garantie n’existe entre les deux. Un contre-exemple structurel peut être formulé ainsi : si un modèle est optimisé sur un corpus où des affirmations erronées mais très fréquentes dominent la distribution, sa perplexité sur ce corpus baissera, car il apprend à reproduire ces schémas plausibles. Si on évalue ensuite le modèle sur un ensemble de requêtes factuelles, son taux d’hallucinations augmentera, car il privilégie la vraisemblance statistique à la véracité. Inversement, des faits rares ou mal couverts dans les données d’entraînement peuvent générer une perplexité plus élevée sans que le modèle ne produise nécessairement d’hallucinations. La prémisse selon laquelle la perplexité mesurerait la qualité factuelle est donc fausse. Aucun théorème ni résultat empirique robuste ne garantit une corrélation positive ou monotone entre les deux métriques. Des travaux en alignement et en apprentissage par renforcement confirment que l’optimisation de la vraisemblance (ou la réduction de la perplexité) ne suffit pas à éliminer les hallucinations, car celles-ci relèvent d’un problème d’ancrage sémantique et de vérification externe, non de probabilité intrinsèque. Confiance : 95 %.