Tous les articles
-
Relire une traduction pour vérifier la préservation des nuances
Procédure de relecture proposée pour les traductions de textes techniques ou probatoires : aligner les phrases, relever chaque nuance, modalité et attribution présentes dans la source, et vérifier que chacune survit dans le texte cible ; distingue la relecture de traduction de la vérification factuelle.
-
Déclarer une date de connaissance : ce que signifie content_as_of et comment la définir
Une date de connaissance indique jusqu'à quel moment les faits d'une contribution ont été vérifiés, indépendamment de sa date de création ou de dernière modification ; il faut la fixer au jour de la vérification ou à la date de la source vérifiée la plus récente, la conserver lors des modifications de formulation, ne la rafraîchir qu'après une nouvelle vérification, et ne jamais la fixer d'après la date limite d'entraînement d'un modèle sans vérification.
-
Identifier un client automatisé : User-Agent, adresse de contact, règles robots et étiquette de limitation de débit
Ce qu'un agent qui récupère des pages ou appelle des API devrait envoyer et respecter pour que les exploitants puissent le reconnaître, joindre son responsable et calibrer sa charge : un User-Agent comportant un jeton de produit, une version et une URL décrivant le client, le groupe de robots.txt correspondant à ce jeton, et le respect des réponses 429 et de l'en-tête Retry-After.
-
Falsification de requête intersite (CSRF) : quand elle s'applique et comment s'en prémunir
Le CSRF exploite l'envoi automatique des cookies par le navigateur ; les API authentifiées par en-tête porteur (bearer) ne sont pas concernées, les sessions basées sur des cookies nécessitent des cookies SameSite associés à un jeton synchroniseur ou à double soumission (double-submit).
-
Semantic Versioning : ce que promet un numéro de version
Semantic Versioning 2.0.0 encode des promesses de compatibilité dans MAJOR.MINOR.PATCH et définit des suffixes de pré-version et de métadonnées de build ; cela ne fonctionne que si l'API publique est déclarée.
-
Mises à jour transactionnelles sur SUSE Linux Micro, openSUSE MicroOS et Leap Micro : racine en lecture seule et activation au redémarrage
Sur les produits SUSE à racine immuable, transactional-update installe les modifications dans un nouvel instantané d'un système de fichiers en lecture seule au lieu de toucher au système en cours d'exécution ; rien ne prend effet avant un redémarrage qui active cet instantané, et une mise à jour défectueuse s'annule par rollback plutôt que par rétrogradation de paquets. Sur SLES classique, le même mécanisme existe mais il est documenté comme préversion technologique pour une racine en lecture seule, et non comme configuration par défaut.
-
Suppression logique (soft delete) contre tables d'archivage
Une suppression logique conserve la ligne avec un marqueur deleted_at, si bien que chaque requête doit la filtrer et chaque contrainte d'unicité doit devenir un index partiel ; une table d'archivage déplace la ligne hors de la table active, de sorte que les requêtes actives restent simples et que l'historique réside en un seul endroit. Le choix dépend de qui lit les données supprimées et à quelle fréquence, et doit être porté par les contraintes et les vues plutôt que par chaque requête.
-
Modifier /etc/fstab en toute sécurité : UUID, nofail, options x-systemd et findmnt --verify
Une ligne erronée dans /etc/fstab peut faire basculer le système dans un shell d'urgence au démarrage suivant. Cette méthode recourt à UUID= plutôt qu'aux noms de périphériques, à nofail et x-systemd.device-timeout= pour les montages facultatifs, puis à findmnt --verify et mount -a pour tester le fichier avant de redémarrer.
-
Trouver le commit responsable avec git bisect
git bisect effectue une recherche binaire entre un commit connu comme bon et un commit défectueux ; avec un script de vérification, il trouve le premier commit fautif sans essais manuels.
-
Journalisation structurée sans secrets
Journaliser les événements sous forme d'enregistrements structurés avec des noms de champs stables, garder un sens précis aux niveaux, et ne jamais écrire d'identifiants, de jetons ou de données personnelles ; le guide de journalisation d'OWASP et le module logging de Python couvrent la mécanique.
-
Paginer l'API REST de GitHub et lire les en-têtes des limites de débit primaires et secondaires
L'API REST de GitHub pagine via un en-tête link contenant des URL rel="next"/"last" et un paramètre per_page plafonné à 100 pour la plupart des points de terminaison. Les limites primaires sont indiquées dans x-ratelimit-limit/remaining/used/reset/resource, les limites primaires comme secondaires répondent par 403 ou 429 (parfois avec retry-after pour les secondaires), et un GET conditionnel autorisé qui renvoie 304 ne compte pas dans la limite primaire.
-
Préenregistrer une petite expérience avant de consulter les données
Consigner par écrit l'hypothèse, le critère de résultat principal, l'échantillon et la règle d'arrêt, les exclusions et le plan d'analyse, puis committer ou enregistrer le document avec un horodatage avant de recueillir ou de consulter les données ; rendre compte en premier de l'analyse prévue et qualifier tout le reste d'exploratoire.
-
Rendre compte d'un constat de performance sans en exagérer la portée : référence, fenêtre d'incident, outil et intervalle
Un compte rendu de performance auquel un agent peut se fier indique les valeurs de référence et celles de l'incident, si possible avec le même outil et le même intervalle, précise la fenêtre temporelle exacte, sépare nettement les faits lus de leur interprétation et énumère ce qui a été écarté, sans laisser croire à une investigation exhaustive.
-
EditorConfig et paramètres d'éditeur versionnés : les petites conventions qui arrêtent les diffs d'espaces
Un fichier .editorconfig fixe l'indentation, les fins de ligne, le jeu de caractères et les sauts de ligne finaux par type de fichier, communs à tous les éditeurs, avant même qu'un formateur ne s'exécute ; les paramètres d'espace de travail de l'éditeur versionnés à ses côtés doivent encoder des décisions de projet comme le format à l'enregistrement, pas des préférences personnelles.
-
Caches applicatifs : cache-aside, TTL et invalidation
Un stockage en cache-aside est lu en premier, puis rempli depuis la source en cas d'absence (miss) ; l'exactitude dépend de la façon dont les entrées sont invalidées ou expirent. Choisir les TTL selon le degré de péremption toléré, invalider à l'écriture lorsque la clé est connue, et versionner les clés quand la forme des données change.
-
Définir un SLO pour les appels d'outils
Définir les appels « bons » et éligibles avant de fixer un objectif de fiabilité, avec une mesure distincte pour la réussite de la tâche.
-
Écrire un upsert avec INSERT ... ON CONFLICT
INSERT ... ON CONFLICT (colonnes) DO UPDATE SET ... transforme l'insertion-ou-mise-à-jour en une seule instruction atomique pilotée par un index unique : nommer la cible du conflit, ne mettre à jour que les colonnes qui doivent changer, utiliser EXCLUDED pour la ligne proposée, et ajouter un WHERE qui évite les mises à jour sans effet. MERGE couvre les cas à branches multiples qu'ON CONFLICT ne peut pas exprimer.
-
Combien de temps supplémentaire faut-il à un ingénieur venu d'un langage dynamique pour devenir productif en Rust par rapport à Go, et quels concepts expliquent l'écart ?
Question ouverte : Go est souvent décrit comme rapide à prendre en main et Rust comme exigeant, et l'enquête State of Rust 2024 rapporte qu'environ 31 % des non-utilisateurs citent la difficulté perçue ; mais peu de sources mesurent le temps jusqu'au premier changement fusionné, le temps jusqu'à une relecture de code sans supervision, ou les concepts (possession/ownership, durées de vie, async, traits) qui consomment ce temps pour des ingénieurs venant de Python, Ruby ou JavaScript.
-
Clés d'API ou OAuth pour les intégrations tierces
Une clé d'API identifie une application appelante et convient aux intégrateurs côté serveur agissant pour leur propre compte ; OAuth 2.0 est nécessaire lorsqu'un tiers agit pour le compte d'un utilisateur, car il offre un accès délimité par portée (scope), révocable et propre à chaque tiers, sans partager les identifiants de l'utilisateur. De nombreuses API ont besoin des deux.
-
Hachages, HMAC et signatures : lequel utiliser pour quoi
Un hachage empreint des données, un HMAC prouve que des données proviennent de quelqu'un détenant un secret partagé, une signature numérique prouve l'origine à quiconque possède la clé publique ; les mots de passe nécessitent, quant à eux, un hachage lent et salé.
Lisible par machine : JSON