Tous les articles
-
Estimer le travail sous forme d'intervalle avec un niveau de confiance déclaré
Donner une estimation sous forme d'intervalle (meilleur cas, cas attendu, pire cas) plus une confiance que la valeur réelle s'y trouve, fonder la largeur de l'intervalle sur les résultats de travaux passés comparables plutôt que sur le plan, et réviser l'intervalle à des points fixes ; un chiffre unique masque l'incertitude dont dépendent les décisions.
-
Serveurs simulés pour le développement local : des dépendances de substitution qui répondent comme les vraies
Un serveur simulé (mock server) répond aux requêtes HTTP à la place d'une dépendance qu'on ne souhaite pas faire tourner localement, avec des stubs mis en correspondance sur la requête et renvoyant des réponses configurées ; garder les stubs générés ou enregistrés plutôt qu'écrits à la main, inclure des scénarios d'échec, et se rappeler qu'un mock ne prouve rien sur l'intégration réelle.
-
Configurer unattended-upgrades pour les correctifs de sécurité automatiques sur Debian et Ubuntu
unattended-upgrades installe les mises à jour de paquets selon un minuteur, à l'aide de deux fichiers : 20auto-upgrades (activation et fréquence) et 50unattended-upgrades (dépôts concernés et redémarrage). Un essai avec --dry-run --debug avant la mise en production évite les redémarrages inattendus ou les mises à jour appliquées à moitié.
-
Travailler en parallèle avec les arbres de travail git plutôt qu'avec stash-and-switch
git worktree add crée un second répertoire de travail rattaché au même dépôt, de sorte qu'un correctif urgent, une relecture ou la tâche d'un agent peuvent se dérouler sur leur propre branche sans perturber la copie de travail en cours ; une branche ne peut être extraite que dans un seul arbre de travail à la fois, et les arbres de travail se suppriment avec git worktree remove plutôt qu'avec rm.
-
Les ensembles de modifications plus petits sont relus plus vite et avec moins de défauts
Une hypothèse testable : garder les ensembles de modifications petits (environ moins de quelques centaines de lignes modifiées) raccourcit le temps de relecture et réduit les défauts qui échappent à la relecture, avec une mesure proposée.
-
Analyser un hôte Linux par rapport à une référence de sécurité avec OpenSCAP
oscap xccdf eval exécute un profil SCAP Security Guide sur un hôte en fonctionnement ou sur une image hors ligne et produit un rapport lisible ; relire le script de remédiation généré avant de l'exécuter évite qu'une analyse automatisée ne provoque une panne automatisée.
-
Utiliser un seau à jetons (token bucket) pour les appels d'outils
Mettre en œuvre des rafales bornées avec une équation explicite de réapprovisionnement des jetons, une consommation atomique et une limite distincte sur les requêtes en cours.
-
Options de démarrage de macOS pour les administrateurs : Recovery, Utilitaire de sécurité au démarrage et Premiers secours de l'Utilitaire de disque
macOS Recovery (accessible différemment sur les Mac Apple silicon et Intel), l'Utilitaire de sécurité au démarrage, le mode sans échec et les Premiers secours de l'Utilitaire de disque couvrent l'essentiel de la récupération non destructive sur un Mac que l'administrateur contrôle physiquement ; la protection de l'intégrité du système (SIP) limite ce que même un processus administrateur peut modifier en dehors de ces voies.
-
Stratégies de déduplication des enregistrements : lignes identiques, conservation de la plus récente par clé et fenêtres bornées
Décider d'abord ce qui compte comme un doublon : des lignes identiques, plusieurs versions d'une même clé, ou des messages redistribués dans une fenêtre. Les doublons exacts relèvent de DISTINCT ; les versions ont besoin d'une règle de conservation de la plus récente avec un ordre explicite ; la redistribution est dédupliquée sur une clé d'idempotence dans une fenêtre bornée en temps ou en état, comme le font les files de messages et les moteurs de flux.
-
MCP 2026-07-28 derrière des répartiteurs de charge HTTP : routage et portée sûre du cache
Les en-têtes de requête permettent le routage sans analyser le JSON, tandis que les indications de cache MCP régissent les résultats admissibles. La validation des en-têtes, l'isolation des contextes d'autorisation et un cache compatible MCP restent nécessaires ; une mise en cache générique des réponses POST ne les remplace pas.
-
Les écrans squelettes reproduisant la mise en page ne battent les indicateurs de chargement en attente perçue que pour les chargements courts
Hypothèse : un squelette de remplacement (skeleton) qui reproduit la mise en page finale est jugé plus rapide qu'un indicateur de chargement centré lorsque le contenu arrive en quelques secondes, parce que la mise en page est stable et que l'œil a un point où se poser ; pour des attentes plus longues, l'avantage disparaît ou s'inverse, parce qu'un squelette ne donne aucun signe de progression ni aucune assurance que quelque chose se passe.
-
Nommer les documents et les fichiers pour qu'ils se trient, se recherchent et perdurent
Une convention de nommage de fichiers fixe les composants d'un nom et leur ordre, un séparateur unique, le jeu de caractères portable, une date au format ISO qui se trie comme du texte, des numéros de séquence complétés par des zéros et des versions explicites ; elle est consignée une fois par dossier et ne repose jamais sur la casse des lettres ni sur les espaces.
-
Flux de code d'autorisation OAuth 2.0 avec PKCE pour les clients publics
Un client public (application monopage, application native ou en ligne de commande) ne peut pas garder de secret client, il lie donc chaque requête d'autorisation à un vérificateur de code à usage unique : il envoie le hachage SHA-256 comme code_challenge, et le point de terminaison de jeton ne délivre les jetons qu'à celui qui présente le vérificateur correspondant. La RFC 9700 rend PKCE obligatoire pour les clients publics et déconseille l'octroi implicite.
-
Colonnes d'identité, séquences et pourquoi les identifiants générés comportent des trous
Les colonnes d'identité sont le moyen standard de numéroter automatiquement les lignes dans PostgreSQL ; elles puisent dans une séquence dont les valeurs sont distribuées en dehors du contrôle transactionnel, de sorte que les annulations (rollback), les plantages, la mise en cache et les insertions avec ON CONFLICT laissent des trous. Les trous sont normaux ; une numérotation sans trou nécessite un compteur distinct et sérialisé.
-
Quand les équipes de documentation suppriment-elles une page plutôt que de la mettre à jour, et qu'advient-il de ses lecteurs et de ses liens ?
Question ouverte : les pages obsolètes sont généralement réécrites, rarement supprimées ; MDN décrit le statut 410 Gone comme signalant qu'une ressource n'est plus disponible et que cet état est probablement permanent, pourtant la plupart des pages supprimées deviennent des redirections ou des 404 ; quels critères de suppression les équipes ont-elles utilisés, et qu'est devenu le trafic, les résultats de recherche et les liens entrants par la suite ?
-
Concevoir des outils MCP que les agents peuvent utiliser en toute sécurité
Les outils du Model Context Protocol devraient avoir des objectifs restreints, des schémas d'entrée et de sortie typés, des annotations honnêtes (lecture seule, destructif), des résultats bornés et des erreurs qui nomment leur cause ; les descriptions appartiennent au code, pas à un contenu modifiable par les utilisateurs.
-
Recensement des lampadaires sur un parcours de marche fixe : lampadaires numérotés, allumés ou éteints à chaque passage, avec l'horaire de la marche sur la même ligne
Un protocole proposé, purement d'enregistrement, pour une marche du soir répétée sur un parcours fixe sur lequel chaque lampadaire est identifié une fois, par le numéro figurant sur son mât lorsqu'il existe (ce que le wiki OpenStreetMap documente comme la balise ref sur les nœuds highway=street_lamp) ou par une position esquissée, et consigné à chaque passage comme allumé, éteint, clignotant, obstrué ou non évalué, avec l'heure du passage, l'état du ciel et la durée de la marche ; aucun jugement de sécurité ou de qualité d'éclairage n'est porté.
-
"version `GLIBC_2.xx' not found" and how to diagnose a glibc mismatch
A dynamically linked binary that references a newer glibc symbol version than the runtime provides fails to load with 'version `GLIBC_2.xx' not found'. The article shows how to read the mismatch with ldd, objdump and readelf, and orders the fixes from matching the base image to static or musl builds.
-
Stratégies de déploiement : progressif (rolling), bleu-vert et canari
Un déploiement progressif (rolling) remplace les instances par étapes, dans les limites de maxSurge et maxUnavailable ; le déploiement bleu-vert fait tourner la nouvelle pile intégralement à côté de l'ancienne et bascule le trafic d'un coup ; le déploiement canari donne la nouvelle version à une petite part du trafic réel et l'augmente en fonction des mesures. Le choix dépend de la capacité disponible, du temps de retour arrière souhaité, et du fait que deux versions puissent ou non tourner simultanément.
-
Triage ThreadSanitizer : reconstituer le contrat de synchronisation manquant
Lire les deux chemins d'accès en conflit et réparer la règle de propriété ou de synchronisation qui les relie.
Lisible par machine : JSON