La faille IDOR (Insecure Direct Object Reference) est une vulnérabilité de sécurité classée parmi les plus courantes par l'OWASP, où une application expose des identifiants directs (comme un numéro de commande ou un ID utilisateur) dans des URLs, formulaires ou APIs, sans vérifier les droits d'accès. Un attaquant peut ainsi modifier manuellement ces identifiants pour accéder aux données d'autres utilisateurs, comme illustré par l'exemple d'une URL ?id=1042 où remplacer 1042 par 1041 donne accès à une facture étrangère.
Cette faille est fréquente car elle est simple à implémenter et souvent négligée lors du développement, notamment avec des identifiants numériques prévisibles (auto-incrémentés). Elle ne se limite pas aux URLs mais peut aussi toucher les paramètres POST, les APIs ou les cookies, rendant le risque encore plus diffus. L'article souligne que même des développeurs expérimentés peuvent omettre de vérifier les permissions côté serveur, exposant ainsi des données sensibles.
Ce billet explique comment l'auteur utilise FrankenPHP en développement, mettant en avant son mode worker qui maintient une instance PHP active pour éviter les recharges coûteuses à chaque requête. Trois mécanismes de hot reload sont combinés : --watch pour les fichiers statiques, tailwind:build --watch pour les styles, et le worker lui-même, permettant un rechargement instantané du navigateur sans configuration complexe. L'article souligne aussi l'intégration d'un certificat HTTPS auto-signé, accessible via https://localhost:8443 sans modification du fichier hosts.
L'auteur détaille l'architecture de FrankenPHP, un binaire Go combinant le serveur Caddy et PHP-FPM, simplifiant l'infrastructure en un seul processus au lieu de Nginx + PHP-FPM. Le mode worker évite le redémarrage complet de l'application à chaque requête, améliorant les performances en développement comme en production. Le même fichier de configuration est utilisé pour les deux environnements, avec des variables d'environnement ajustant les comportements selon le contexte Docker.
FrankenPHP simplifie l’infrastructure PHP en remplaçant Nginx et PHP-FPM par un seul binaire, combinant serveur HTTP (Caddy) et exécution PHP. L’auteur partage son expérience en production depuis octobre 2025, où quatre sous-domaines sont servis depuis un unique processus, réduisant la complexité DevOps tout en maintenant Symfony. Le mode worker permet de charger l’application une seule fois au démarrage, améliorant les performances, mais impose une vigilance accrue sur les variables statiques ou états persistants, autrefois effacés à chaque requête sous PHP-FPM.
L’optimisation repose aussi sur opcache preload, qui précharge les classes Symfony en mémoire avant l’exécution du worker, accélérant ainsi le démarrage. La configuration se résume à quelques lignes, et l’absence de reverse proxy externe ou de pools FPM par site simplifie la maintenance. Cependant, cette approche déplace plutôt qu’elle n’élimine la complexité, notamment en matière de gestion des états applicatifs.
L’article détaille les gains concrets (un seul binaire, une seule configuration) tout en soulignant les pièges potentiels, comme les fuites de mémoire ou les variables globales persistantes, autrefois neutralisées par le redémarrage fréquent des workers PHP-FPM.
L’article présente deux nouvelles fonctions CSS, sibling-index() et sibling-count(), issues du module CSS Values and Units Level 5, permettant de simplifier la création d’effets de cascade décalée (staggered animations) sans recourir à des boucles Sass ou à du JavaScript. Ces fonctions exploitent des données déjà connues du navigateur, comme la position d’un élément parmi ses frères ou le nombre total de ses frères, pour appliquer des animations dynamiques en une seule ligne de CSS, sans limite de taille de liste.
L’auteur explique que les méthodes traditionnelles (comme les sélecteurs :nth-child() ou les manipulations JavaScript) sont lourdes et peu maintenables, surtout pour des listes dynamiques. À l’inverse, sibling-index() et sibling-count() offrent une solution élégante et performante, fonctionnant aussi bien pour 5 éléments que pour 5 000, sans générer de code superflu ni dépendre de variables injectées dynamiquement.
Ces fonctions, déjà approuvées par le CSS Working Group, résolvent un problème récurrent en CSS en donnant accès à des informations structurelles du DOM directement dans les styles, ouvrant la voie à des mises en page plus dynamiques et maintenables.
L’auteur partage ses expériences récentes avec des "bizarreries" rencontrées lors de la migration vers Ubuntu 26. Il évoque des dysfonctionnements après la mise à jour, notamment la réinstallation forcée de Firefox en version Snap malgré ses préférences pour le .deb, des problèmes avec KeepassXC et Rygel, ainsi que des incompatibilités liées au passage à sudo-rs, qui ont perturbé ses scripts Ansible.
Il aborde ensuite les difficultés liées aux webcams modernes, en particulier celles utilisant le protocole Mipi, qu’il a tenté de configurer sans succès pendant des mois. Après des essais infructueux avec DroidCam, il découvre scrcpy, un outil sous Linux qui lui permet enfin d’utiliser sa webcam et d’accéder à des fonctionnalités avancées de son smartphone depuis son ordinateur, comme la gestion de Signal ou la lecture de musique.
Enfin, il évoque les défis liés à Wayland et aux claviers alternatifs, critiquant notamment l’absence de fonctionnalités comme l’autotype dans KeepassXC sous Wayland. Il s’intéresse aux outils comme kanata et ydotool pour simuler ou afficher des couches de clavier, tout en regrettant l’absence d’un affichage visuel en temps réel pour faciliter l’apprentissage des nouvelles dispositions.
L’article illustre les conséquences des interruptions fréquentes en entreprise, comme les visites horaires d’un manager surnommées « le bocal des geeks », qui empêchent la concentration profonde. Selon des recherches, une interruption coûte en moyenne 23 minutes de regain de concentration, et dans une équipe de 10 personnes, cela représente jusqu’à 63 journées de travail cognitif perdues par mois. L’auteur souligne que le problème ne relève pas d’un manque de discipline individuelle, mais d’une mauvaise organisation, où le management par le contrôle prime sur l’efficacité réelle.
Le concept de Deep Work, popularisé par Cal Newport, est présenté comme une solution : il s’agit de réaliser des tâches exigeantes sans interruption, créatrices de valeur, plutôt que de se contenter d’une pseudo-productivité (réponses rapides, agitation visible). L’exemple d’Éric montre comment une méthode de suivi intrusive, bien que bien intentionnée, peut nuire à la productivité globale en empêchant les employés d’atteindre un état de travail optimal.
L’auteur propose une alternative simple : remplacer les interruptions par un canal d’information partagé, réduisant ainsi les perturbations tout en maintenant une communication efficace. L’enjeu est de repenser l’organisation du travail pour privilégier la qualité et la profondeur des tâches plutôt que leur apparence.
Cette faille critique dans Kubernetes, révélée en janvier 2026, exploite la permission RBAC nodes/proxy GET pour exécuter du code à distance dans n’importe quel Pod du cluster, sans laisser de trace dans les logs d’audit. Cette vulnérabilité repose sur un contournement des vérifications d’autorisation : le Kubelet, via une connexion WebSocket, autorise l’exécution de commandes (/exec) en validant uniquement un GET initial, sans exiger le verbe CREATE normalement requis. L’absence de logs d’audit côté Kubelet aggrave le risque, permettant des attaques discrètes, notamment sur des composants système comme etcd ou kube-apiserver.
L’article souligne que des ServiceAccounts aux noms évocateurs, comme rook-ceph-system, combinés à des permissions étendues (accès en lecture aux Secrets), constituent des cibles privilégiées pour une élévation de privilèges. Une analyse des Roles et ClusterRoles est recommandée, avec des outils comme le script de détection du chercheur Graham Helton. Parmi les composants vulnérables figurent des outils courants comme l’OpenTelemetry Collector, dont les ServiceAccounts associés pourraient être exploités pour compromettre l’ensemble du cluster.
Pour atténuer ce risque, l’auteur propose plusieurs correctifs et mesures préventives, comme l’activation de la feature gate KEP-2862 pour un contrôle granulaire des autorisations Kubelet, l’utilisation de CiliumNetworkPolicy pour bloquer l’accès au port 10250, ou encore l’application de politiques Kyverno pour interdire la création de Roles incluant nodes/proxy. La surveillance des audit logs et la mise à jour des composants (comme Rook-Ceph) sont également essentielles, bien que Kubernetes ait classé cette faille comme un "comportement intentionnel" non corrigé en l’état.
Cet article explique comment configurer un réseau interne pour des machines virtuelles (VM) sous Proxmox dans un homelab monoserveur. L'auteur détaille une solution adaptée aux petits budgets, sans équipement réseau intermédiaire comme des switchs gérant les VLAN. La configuration repose sur un routeur virtuel (conteneur LXC) et des VLAN dédiés directement gérés par Proxmox, simplifiant ainsi l'infrastructure.
La configuration réseau repose sur un schéma en étoile où le serveur Proxmox centralise les VLAN 121 (192.168.121.0/24) et 221 (192.168.221.0/24), connectés au LAN principal (192.168.21.0/24). Le routeur virtuel, intégré au serveur, gère les routes statiques pour permettre l'accès aux sous-réseaux depuis le réseau local ou externe via la box/FAI.
L'approche proposée est idéale pour un usage domestique et pédagogique, mais n'est pas conçue pour des environnements professionnels exigeants. L'auteur partage sa configuration complète, incluant les adresses IP et la topologie, pour faciliter la reproduction par d'autres utilisateurs.
L'auteur décrit la refonte de son infrastructure DNS pour éliminer les points de défaillance uniques (SPOF) et améliorer la résilience. Son ancien setup, basé sur un seul conteneur LXC combinant AdGuard Home et NPM, souffrait d'un manque de redondance et d'une résolution inefficace des noms de domaine locaux, générant du trafic inutile via le NAT (hairpin). La nouvelle architecture sépare les rôles en quatre composants : Technitium DNS Server pour la gestion des zones DNS locales et la haute disponibilité, AdGuard Home pour le filtrage avancé des requêtes, NextDNS comme résolveur chiffré en amont, et NPM pour la gestion des proxy inverses.
Technitium assure la synchronisation automatique entre deux instances, permettant une continuité de service immédiate en cas de panne d'un nœud Proxmox. AdGuard Home, déployé dans un conteneur dédié, applique des règles de filtrage personnalisées par client ou groupe, tandis que NextDNS prend le relais pour les requêtes publiques et offre une protection renforcée hors réseau. NPM, isolé dans son propre conteneur, gère les redirections des noms de domaine locaux et publics sans conflit.
Cette refonte élimine les inefficacités du hairpin NAT et garantit un filtrage cohérent, que ce soit en local ou à distance, tout en assurant une haute disponibilité grâce à la redondance des composants.
L’article explique comment éviter les pertes ou corruptions de données lors des déploiements en utilisant des graceful shutdowns avec Symfony Messenger. L’idée principale est que les processus de consommation de messages doivent terminer le traitement en cours avant de s’arrêter, évitant ainsi des incohérences (comme des transactions bancaires incomplètes ou des fichiers orphelins). Symfony Messenger gère automatiquement les signaux de terminaison (SIGTERM, SIGINT) et propose des options comme des limites de temps ou de mémoire pour contrôler l’arrêt propre des consommateurs.
L’auteur détaille l’implémentation de base via la commande messenger:consume, avec des exemples de code et des flags comme --limit ou --time-limit pour limiter le nombre de messages ou la durée d’exécution. Il souligne aussi l’importance des limites mémoire (--memory-limit) pour éviter les fuites de mémoire, tout en permettant au processus de finir sa tâche avant de s’éteindre. Le système est conçu pour être robuste, même lors de redémarrages ou de déploiements, grâce à une gestion native des signaux par Symfony.
L’article explique comment sortir les outils de qualité de code PHP du vendor/ d’un projet Symfony en utilisant l’image Docker jakzal/phpqa, afin d’éviter les conflits de dépendances, les composer update plus lents et les divergences entre environnement local et CI. L’auteur remplace les dépendances require-dev classiques (PHPStan, Rector, PHP-CS-Fixer, Deptrac, etc.) par des exécutions one-shot dans un conteneur Docker contenant les binaires .phar, avec un tag d’image figé pour garantir la reproductibilité et un cache partagé /tmp pour accélérer fortement les analyses. Le workflow repose sur un Makefile séparant des contrôles rapides avant commit et des vérifications plus lourdes avant release, avec des cibles atomiques réutilisables individuellement. Certains cas restent toutefois hors du périmètre de jakzal/phpqa, notamment lint:container de Symfony, composer audit et Biome pour JS/TS. L’article souligne aussi les limites des outils non maintenus embarquant une ancienne version de nikic/php-parser, comme PHPMetrics ou PDepend, devenus incompatibles avec certaines nouveautés de PHP 8.4/8.5.
L’auteur explique comment son passage d’un Raspberry Pi 3 à un mini PC x86 plus puissant l’amène à envisager la conteneurisation de son serveur domestique afin d’héberger ses propres services liés à la lecture de mangas, BD et ebooks sur tablette. Il décrit l’intérêt d’outils comme Docker pour isoler et déployer facilement différentes applications auto-hébergées, notamment dans un contexte où les usages personnels évoluent et nécessitent davantage de souplesse et de ressources matérielles. Le billet met aussi en avant les avantages pratiques d’une machine disposant de davantage de RAM et d’une architecture x86-64, ouvrant la porte à des solutions d’hébergement plus modernes et modulaires. Il donne quelques conseils, notamment sur l'utilisation de Traefik
L’article explique comment un clavier programmable et ergonomique peut améliorer durablement la productivité des développeurs tout en réduisant la fatigue physique liée à une utilisation intensive. Il insiste sur l’intérêt des claviers séparés et des couches de touches (“layers”) permettant de limiter les déplacements des mains, d’accéder rapidement aux raccourcis et d’adapter totalement le clavier à son usage personnel. L’auteur montre aussi que cette approche demande un investissement initial important — apprentissage, personnalisation et perte temporaire de vitesse — mais qu’elle devient rentable à long terme grâce à une meilleure fluidité de travail et une réduction des douleurs liées aux gestes répétitifs.
GitLab montre comment utiliser les capacités d’IA de Codex directement dans les workflows GitLab pour accélérer la correction de bugs, en s’appuyant sur les issues, les merge requests et le contexte du projet afin de proposer des correctifs plus pertinents et traçables. L’article insiste sur l’intérêt d’intégrer l’IA au cycle DevSecOps complet plutôt que de l’utiliser comme simple assistant de génération de code, avec des validations humaines et des pipelines CI/CD pour sécuriser les changements proposés. Il souligne aussi que les agents IA peuvent automatiser des tâches répétitives comme la création de correctifs ou l’analyse de vulnérabilités, tout en laissant le contrôle final aux développeurs.
Le journal décrit une infrastructure personnelle d’IA auto-hébergée basée sur des composants compatibles OpenAI afin de pouvoir utiliser localement des LLM et des outils de génération d’images sans dépendre de services cloud propriétaires. L’auteur s’appuie notamment sur llama-swap, qui permet de basculer dynamiquement entre différents modèles et moteurs d’inférence, y compris stable-diffusion.cpp, avec une configuration adaptée à une machine équipée de plusieurs GPU Nvidia. Le texte insiste sur l’intérêt de standardiser les API pour orchestrer plusieurs IA locales, sur la maîtrise des ressources matérielles (VRAM, chargement/déchargement des modèles) et sur les avantages en matière de souveraineté, de confidentialité et de flexibilité pour expérimenter différents modèles open source directement sur sa propre infrastructure.
Le billet retrace la découverte de LoRa et de l’écosystème mesh autour de Meshtastic, en expliquant comment cette technologie permet de créer des réseaux de communication autonomes, peu coûteux et résilients, capables de fonctionner sans Internet ni infrastructure opérateur. L’auteur revient sur l’évolution historique de LoRa, de l’IoT industriel jusqu’aux usages communautaires et survivalistes, notamment après les inondations au Texas en 2025 où des particuliers ont maintenu des communications malgré la pannespe des réseaux classiques. Il détaille ensuite la création de son propre node à base d’ESP32, installé dans un boîtier IP67 pour environ 45 €, avec configuration via Bluetooth et application mobile, puis partage ses premiers retours d’expérience : découverte d’un maillage local très actif avec des nodes détectés jusqu’à 30 km, importance du positionnement extérieur pour améliorer le signal, et possibilités d’extensions futures comme l’ajout de batteries, panneaux solaires ou l’intégration domotique via MQTT.
Sean Goedecke explique qu’en 2026 il utilise désormais les LLMs comme de véritables agents capables de produire des pull requests complètes, y compris dans des zones de code qu’il maîtrise bien, avec une simple passe de revue finale avant validation. Il décrit un changement majeur par rapport à 2025 : les agents récupèrent beaucoup mieux de leurs erreurs, vont plus vite et nécessitent moins de supervision en temps réel, ce qui l’a amené à passer d’un workflow centré sur VSCode à des outils orientés terminal et agents comme GitHub Copilot App. Il insiste cependant sur le fait que son travail s’est déplacé vers l’évaluation rapide des propositions générées, le tri des mauvaises approches et la revue approfondie des changements acceptés, notamment pour supprimer les “LLM-isms” comme le sur-commentaire ou certaines décisions de conception discutables. L’auteur continue aussi d’utiliser les LLMs pour apprendre de nouveaux domaines, produire du code jetable de recherche ou explorer des bases de code inconnues, mais souligne qu’ils restent moins fiables pour le jugement architectural, les ADRs ou les décisions techniques engageantes à long terme.
Addy Osmani explique que l’usage actuel des assistants IA en développement logiciel favorise la résolution rapide des tâches au détriment de la compréhension profonde : le bug est corrigé, mais le modèle mental du développeur ne progresse plus. Il décrit une forme de « dette de compréhension » où l’on délègue progressivement le raisonnement à l’IA, jusqu’à perdre la capacité de reconstruire ou faire évoluer un système sans assistance. L’auteur ne rejette pas l’IA — qu’il utilise massivement — mais insiste sur la différence entre utiliser un modèle comme accélérateur d’apprentissage ou comme distributeur automatique de solutions. Il recommande notamment de formuler une hypothèse avant de solliciter l’IA, de demander des explications plutôt que du code prêt à l’emploi, et de traiter les réponses comme une revue de code d’un développeur junior. Il s’appuie aussi sur plusieurs études récentes montrant que les développeurs qui utilisent l’IA passivement comprennent moins bien leur propre code, alors que ceux qui l’emploient comme outil pédagogique conservent un niveau de compréhension comparable à un travail sans IA.
L’article analyse un paradoxe créé par l’IA : contrairement aux précédentes révolutions technologiques qui valorisaient surtout les profils juniors et exécutants, l’intelligence artificielle renforce désormais la valeur de l’expérience et de l’expertise humaine. Les professionnels expérimentés deviennent essentiels car ils savent contextualiser les demandes, formuler les bonnes hypothèses et surtout exercer un discernement critique sur les réponses produites par les modèles. Le texte insiste aussi sur le risque d’une adoption trop rapide et insuffisamment comprise de ces outils, rappelant que l’enjeu n’est pas de ralentir le progrès mais de conserver une maîtrise consciente de ses usages afin que l’IA reste un levier au service des capacités humaines plutôt qu’un mécanisme subi.
L’auteur relate son expérience avec une tablette Chuwi Hi10Go sous Linux, où l’écran tactile affichait systématiquement une image inversée à 180°, malgré les rotations physiques. Le problème provenait d’une mauvaise configuration de l’accéléromètre, dont la matrice de transformation était mal interprétée par le système. Après des recherches infructueuses en 2023, il a finalement trouvé une solution en modifiant une règle udev pour corriger l’orientation de l’écran.
La solution consiste à ajouter une règle spécifique dans le fichier /etc/udev/hwdb.d/61-sensor.hwdb afin d’inverser la matrice de l’accéléromètre, puis à mettre à jour la base de données matérielle et relancer udev. Cette manipulation, inspirée d’un dépôt GitHub de systemd, permet de rétablir l’affichage correct de l’écran après un redémarrage.
Cependant, un second problème est apparu : l’écran tactile (un composant Goodix) ne fonctionnait pas correctement, les coordonnées de toucher étant inversées. L’auteur n’a pas encore trouvé de solution définitive pour ce dysfonctionnement, mais son expérience illustre les défis liés à l’utilisation de matériel sous Linux.