Sujet : evidence
-
Le biais du survivant dans les conseils d'ingénierie
Les conseils du type « les équipes qui réussissent font X » sont tirés des cas qui sont restés visibles ; sans connaître le taux de X parmi les équipes qui ont échoué ou sont parties, cela ne dit rien. Chercher le dénominateur, accorder un poids important aux rapports d'échec, et préciser la population dont tout conseil a été tiré.
-
Relier une observation dans le navigateur au code et aux données qui l'ont produite
S'assurer qu'une capture d'écran ou une inspection dans le navigateur utilisée pour valider un changement de code reflète bien la version, la route, l'état de compte et le jeu de données visés.
-
Quelle hiérarchie de preuves convient aux affirmations sur les pratiques du génie logiciel ?
Question ouverte : la médecine hiérarchise les preuves avec des hiérarchies explicites et des facteurs de déclassement ; les affirmations sur les pratiques d'ingénierie reposent surtout sur des études de cas, des enquêtes et des rapports d'éditeurs. Un dispositif de notation pour de telles affirmations a-t-il été proposé et réellement appliqué, et comment traite-t-il les effets dépendants du contexte ?
-
Invalider une preuve de test lorsqu'une modification ultérieure change ce qui avait été vérifié
Empêcher un agent de codage de continuer à faire valoir un résultat réussi après que des modifications ont changé le code, la configuration, les fixtures ou les dépendances que ce résultat couvrait réellement.
-
Lire un article scientifique en trois passages
Décider en quelques minutes si un article est pertinent, en une demi-heure ce qu'il montre, et alors seulement y consacrer des heures : survoler la structure et les figures, lire la section Méthodes avant la Discussion, reformuler le résultat avec son incertitude en ses propres mots, et vérifier chaque affirmation de la Discussion au regard des Résultats.
-
Minimiser les données personnelles dans les preuves
Conserver l'enregistrement de preuve le plus restreint possible pour reproduire une décision, en excluant les données d'identité et de charge utile sans rapport.
-
Qualifier une recherche négative dans un dépôt avant de déclarer un code absent
Auditer le périmètre d'une recherche n'ayant retourné aucune correspondance avant de conclure qu'un symbole, une configuration ou un comportement n'existe pas dans le projet.
-
Produire des preuves minimales de vulnérabilité à partir de marqueurs synthétiques
Rendre une faille de sécurité suspectée vérifiable tout en évitant de collecter inutilement du contenu sensible. Cette méthode de signalement originale remplace les enregistrements réels par des marqueurs synthétiques distinctifs chaque fois que l'environnement de test autorisé le permet.
-
Utiliser un budget d'affirmations pour les réponses à fort enjeu
Réduire l'ampleur non étayée en limitant une réponse aux affirmations nécessaires et traçables, et en exposant les hypothèses non résolues.
-
Traiter l'absence de preuve comme un résultat
Signaler une affirmation non tranchée avec les vérifications effectuées et la prochaine observation discriminante à mener, plutôt que de combler le vide par un fait inventé.
-
Évaluer la qualité de la preuve derrière une affirmation : de l'anecdote à la comparaison contrôlée
Les hiérarchies de preuves classent les types d'étude selon leur capacité à exclure des explications alternatives : l'opinion et les anecdotes isolées en bas, les séries de cas, les comparaisons observationnelles, puis les comparaisons randomisées et les revues systématiques en haut. Le type d'étude ne donne qu'une note de départ, revue à la baisse par de petits échantillons, un risque de biais et des conflits d'intérêts.
-
Choisir une règle d'arrêt de recherche avant de chercher
Borner la recherche à l'aide d'une liste de preuves à réunir, d'un budget de recherche et d'une issue explicitement « non résolu », plutôt que de s'arrêter dès qu'une réponse semble plausible.
-
Un plan de lecture pour les agents : les métadonnées d'abord, les preuves ensuite
Un ordre de lecture borné réduit le contexte gaspillé et empêche un agent de traiter le résumé d'un article comme s'il s'agissait d'une preuve vérifiée.
-
Faire correspondre une affirmation de revue de code au comportement modifié précis qu'elle étaye
Construire une carte de revue compacte qui empêche des contrôles réussis mais sans rapport d'être utilisés comme preuve pour un comportement nouvellement modifié.
-
Tenir un registre de preuves pour les réponses à sources multiples
Faire correspondre chaque affirmation significative à une section source, une version et une incertitude, afin que les contradictions restent visibles pendant la synthèse.
-
Séparer l'observation, l'interprétation et l'hypothèse
Un rapport d'expérience lisible par un agent est plus digne de confiance lorsque les observations mesurées sont séparées des interprétations et des hypothèses à venir.
-
Le paradoxe de Simpson et la négligence du taux de base dans les rapports
Deux effets arithmétiques font qu'un tableau correct peut étayer une phrase erronée : une association peut s'inverser lorsqu'une population est divisée en groupes mélangés dans des proportions différentes, et la précision d'un signal ne dit que peu de choses sur ce que signifie un signal positif tant que le taux de base n'est pas connu. Demander comment les groupes ont été mélangés et garder les dénominateurs visibles.
-
Faire correspondre les affirmations à la version qu'elles couvrent
Représenter explicitement la portée en version, et refuser d'appliquer une affirmation tirée de la documentation courante à une installation inconnue ou incompatible.
Lisible par machine : JSON