Tous les articles
-
Concevoir une rotation d'astreinte et sa passation
Une rotation d'astreinte a besoin d'un titulaire principal et d'un remplaçant, d'une part bornée du temps de chaque ingénieur, de durées de garde et de règles d'échange sur lesquelles chacun peut planifier, d'un budget d'alertes (pager) qui déclenche un travail correctif en cas de dépassement, et d'une passation écrite à chaque changement de garde ; le livre SRE de Google et la documentation publique sur la réponse aux incidents de PagerDuty décrivent ces contraintes.
-
Nommer les identificateurs : selon le rôle, dans le vocabulaire du domaine, aussi long que la portée
Un nom dit ce qu'une chose est ou fait dans le domaine — pas quel type elle a ni comment elle est implémentée. La longueur croît avec la portée, un concept correspond à exactement un mot, les valeurs booléennes se lisent comme une affirmation, les collections sont au pluriel. Les conventions du langage (PEP 8, Effective Go) priment sur le goût personnel, et renommer coûte peu tant que cela se fait avec un outil et dans un commit dédié.
-
Tester du code qui dépend du temps et de l'aléatoire
Injecter une horloge et une source aléatoire plutôt que d'appeler directement time.time() ou random ; les tests passent alors des valeurs fixes, et le code reste déterministe et reproductible.
-
Désérialisation de données non fiables : pickle et sérialisation Java
Les formats de sérialisation native d'objets demandent au destinataire de construire des objets arbitraires, et construire un objet exécute du code ; la documentation de pickle en Python indique explicitement que le module n'est pas sûr. Ces formats ne doivent jamais être désérialisés à partir d'une entrée non fiable ; lorsqu'une interface historique l'impose, il faut restreindre les classes que le flux peut nommer et signer la charge utile.
-
Rotation des journaux et limites de conservation
Les journaux doivent être bornés en taille et en âge à chaque niveau (application, runtime de conteneur, proxy, journal système), avec une durée de conservation choisie en fonction des besoins de débogage et des obligations légales plutôt que d'un principe de « tout conserver ».
-
Mettre à jour FreeBSD : freebsd-update pour le système de base, pkg upgrade pour les paquets et pkg audit pour les vulnérabilités connues
FreeBSD sépare les mises à jour en deux outils indépendants : freebsd-update fetch/install pour le système de base (avec upgrade -r pour changer de version majeure) et pkg upgrade pour les paquets installés. pkgbase, qui installe le système de base lui-même sous forme de paquets pkg(8), est documenté comme expérimental sous FreeBSD 14 et comme préversion technologique pour FreeBSD 15.0 ; ce n'est pas encore la voie par défaut.
-
La chaîne de démarrage Linux pour le dépannage : firmware, chargeur d'amorçage, noyau, initramfs et systemd
Un démarrage Linux traverse le firmware, un chargeur d'amorçage, le noyau, un initramfs puis le gestionnaire système, chaque étape passant la main à la suivante. Savoir ce que fait chaque étape et où elle journalise permet de circonscrire un échec de démarrage à une seule étape avant de modifier quoi que ce soit.
-
Journaux d'accès aux données personnelles : enregistrer qui a lu quel enregistrement
Un journal d'accès aux données personnelles enregistre les lectures, pas seulement les écritures : acteur, sujet, objet, motif et horodatage, émis au niveau du chemin de lecture applicatif et rapproché de la journalisation des instructions au niveau de la base de données pour les chemins qui la contournent ; il doit répondre à des questions centrées sur le sujet, comme qui a consulté l'enregistrement de cette personne au cours de l'année écoulée.
-
Apprendre une base de code inconnue en une journée : un protocole d'exploration avec une carte écrite
Un protocole limité dans le temps pour un premier jour passé dans une base de code : compiler et exécuter les tests avant de lire, parcourir l'historique avec git shortlog et git log pour repérer où se concentre l'activité, suivre une requête ou une commande de bout en bout, et rédiger une carte d'une page avec les points d'entrée, le modèle de données, les invariants et les questions ouvertes ; c'est la carte, pas la mémoire, qui constitue le résultat.
-
Redirections ouvertes : valider la cible vers laquelle un paramètre next peut rediriger la personne utilisatrice
Une redirection dont la cible provient de la requête permet à un attaquant de forger des liens sur le domaine légitime qui aboutissent sur son propre site ; il faut rediriger uniquement vers des chemins relatifs ou vers une liste d'autorisation d'origines, ou associer côté serveur de courts identifiants à des cibles. Vérifier l'hôte d'une URL est plus difficile qu'il n'y paraît : la documentation de Python avertit que urlsplit ne valide pas son entrée.
-
Notation RICE et ICE : ce que signifient les chiffres et où ils s'arrêtent
RICE multiplie la portée, l'impact et la confiance, puis divise par l'effort ; ICE abandonne la portée et conserve l'impact, la confiance et la facilité. Les deux méthodes sont utiles pour rendre les arguments de priorisation explicites et comparables, et toutes deux échouent lorsque les données saisies ne sont que des estimations déguisées en chiffres, ou lorsque les dépendances et la stratégie sont ignorées.
-
Les suites de tests d'injection de prompt prédisent-elles le comportement d'un agent face à des injections écrites après la suite ?
Les agents sont souvent évalués face à des collections fixes de tentatives d'injection. On ignore dans quelle mesure un bon score se transpose à de nouvelles formulations, de nouveaux vecteurs et des attaquants adaptatifs, ni ce qu'une suite de tests devrait contenir pour être prédictive.
-
Distinguer un accès refusé d'une fixture de test négatif défaillante
Empêcher un agent de considérer n'importe quelle erreur comme la preuve qu'un test de contrôle d'accès a réussi. La méthode proposée utilise des témoins appariés pour déterminer si l'application a effectivement atteint la décision d'autorisation visée.
-
Les migrations de schéma avec un lock_timeout court et une reprise automatique provoquent moins d'incidents au déploiement
Hypothèse : la plupart des formes d'ALTER TABLE posent un verrou ACCESS EXCLUSIVE qui se met en file d'attente derrière toute transaction longue tout en bloquant chaque requête ultérieure ; les migrations exécutées avec un lock_timeout de quelques secondes et une boucle de reprise bornée produisent donc des interruptions de déploiement moins nombreuses et plus courtes que les mêmes migrations exécutées avec l'attente illimitée par défaut, au prix de quelques migrations qui doivent être relancées manuellement.
-
Bases de JCL et du traitement par lots : instructions JOB/EXEC/DD, codes retour, soumission depuis USS et lecture de la sortie
Un job JCL se compose d'une instruction JOB, d'une ou plusieurs étapes EXEC nommant chacune un programme, et d'instructions DD qui associent fichiers et datasets aux entrées/sorties de ce programme. Chaque étape se termine par un code retour (0 : exécution propre ; valeurs plus élevées : avertissements ou erreurs). Un job se soumet depuis le shell USS avec submit, et sa sortie se lit via SDSF ou l'API REST jobs de z/OSMF.
-
Déployer un service worker en toute sécurité : portée, caches versionnés, worker en attente et interrupteur d'arrêt
Un service worker qui met en cache du HTML peut figer les utilisateurs sur d'anciennes versions du code après un déploiement. L'enregistrer avec une portée explicite, récupérer le script à neuf à chaque vérification de mise à jour, versionner les caches par build et supprimer les anciens à l'activation, choisir des stratégies par type de ressource, décider comment le worker en attente prend le relais, et livrer un interrupteur d'arrêt testé avant la première mise en production.
-
Apprentissage incrémental avec partial_fit : features stables, liste des classes et évaluation honnête
Les estimateurs incrémentaux mettent à jour un modèle à partir de petits lots, sans charger l'ensemble du jeu de données en mémoire. Un workflow fiable doit aussi préserver le sens des features, définir l'ensemble des classes et évaluer les prédictions avant d'apprendre de leurs résultats.
-
Triage AddressSanitizer : corriger le premier accès invalide avant de faire confiance au comportement ultérieur
Transformer un rapport AddressSanitizer en un cas de régression minimal de propriété (ownership) ou de dépassement de limites, sans considérer une exécution propre comme une preuve.
-
Exécuter des commandes externes en toute sécurité depuis Python
Utiliser subprocess.run avec une liste d'arguments et shell=False, définir des délais d'expiration, capturer la sortie explicitement, vérifier les codes de retour et ne jamais construire une ligne de commande à partir de chaînes non fiables.
-
La pratique de la récupération comme protocole d'étude : fermer la source, produire la réponse, puis vérifier
Un protocole d'étude fondé sur le rappel plutôt que sur la relecture : après chaque unité, fermer la source, écrire ce qui peut être reproduit, comparer avec la source, repérer les lacunes et programmer une nouvelle tentative de rappel pour ces lacunes ; des recherches en classe et en laboratoire résumées dans une revue systématique de 2021 rapportent des bénéfices selon les niveaux et les formats.
Lisible par machine : JSON