Les entretiens annuels d'évaluation, largement critiqués pour leur inefficacité, restent pourtant répandus dans les organisations malgré les preuves de leurs limites. Principalement axés sur le passé et les performances individuelles, ces dispositifs négligent souvent la collaboration, l'apprentissage continu et les réalités du travail moderne. Les recherches montrent qu'ils brouillent la frontière entre rémunération et amélioration de la performance, tout en offrant des retours trop tardifs pour être utiles.

Un décalage persistant existe entre la perception des dirigeants, qui jugent ces systèmes efficaces, et celle des salariés, dont une majorité les considère comme un échec. Les employés soulignent notamment leur caractère fastidieux et leur faible valeur ajoutée, préférant des retours en temps réel et des opportunités de développement continu plutôt que des évaluations annuelles rigides.

Malgré ces critiques, les entretiens annuels persistent, en partie à cause d'une illusion d'objectivité et d'une résistance au changement. Leur persistance s'explique aussi par des contraintes légales ou organisationnelles, bien que des alternatives plus adaptées aux besoins actuels du travail émergent progressivement.

Scott H. Young, auteur d’Ultralearning, exprime son scepticisme face aux propositions radicales de révolutionner l’école, malgré son expertise en apprentissage. Bien qu’il reconnaisse que des améliorations sont possibles (comme l’enseignement systématique de la phonétique ou la gestion de la charge cognitive), il souligne que les méthodes intuitivement séduisantes – comme privilégier les projets concrets ou l’apprentissage par la découverte – échouent souvent en pratique. Il s’appuie sur des études et des expériences passées, comme Project Follow Through, qui montrent que les approches structurées et directes obtiennent de meilleurs résultats que les méthodes constructivistes.

Young cite des exemples concrets où ces alternatives ont échoué, notamment en éducation médicale, où l’apprentissage par problèmes a conduit à des performances inférieures. Il rappelle aussi que les méthodes les plus efficaces pour enseigner la lecture reposent sur des exercices systématiques de décodage, plutôt que sur des approches centrées sur la motivation. Pour lui, les compétences générales en résolution de problèmes ne s’acquièrent pas spontanément, mais nécessitent un enseignement explicite et structuré.

Enfin, il critique l’idée que l’école devrait imiter la vie réelle ou abandonner les méthodes traditionnelles comme la mémorisation. Bien que ces propositions paraissent logiques, les preuves empiriques montrent qu’elles nuisent souvent à l’efficacité de l’apprentissage. Young invite à reconsidérer ces intuitions en s’appuyant sur des données solides plutôt que sur des croyances populaires.

Cet article explore les limites du contrôle d'accès basé sur les rôles (RBAC) et du chiffrement au repos pour répondre aux exigences SOC 2, soulignant que ces méthodes ne protègent pas contre les accès non autorisés une fois l'application ou les identifiants compromis. L'auteur propose une approche plus robuste avec le chiffrement au niveau applicatif, utilisant une stratégie hybride combinant chiffrement symétrique (AES-256-GCM) pour les données et asymétrique (RSA avec OAEP) pour les clés, afin d'isoler cryptographiquement les enregistrements.

L'architecture repose sur le modèle d'enveloppe, où chaque document est chiffré avec une clé unique (DEK), elle-même chiffrée avec la clé publique du destinataire. Ce système garantit que même en cas de fuite des identifiants de la base de données, les données restent inaccessibles sans la clé privée correspondante. L'article insiste sur l'importance des modes de chiffrement authentifiés (GCM) et des mécanismes de rembourrage sécurisés (OAEP) pour prévenir les attaques par modification ou oracle.

Enfin, l'auteur détaille la modélisation des données avec Symfony et Doctrine, où chaque utilisateur possède une paire de clés asymétriques, la clé privée étant gérée par un coffre-fort ou un HSM. Cette approche permet une isolation cryptographique au niveau des enregistrements, renforçant ainsi la conformité SOC 2 en matière de traçabilité et de protection des données.

L’auteur, développeur depuis 1983, partage son expérience de l’intégration de l’IA dans son workflow, notamment via le Markdown pour rédiger spécifications et architectures. Il critique à la fois le vibe coding (délégation aveugle à l’IA) et le rejet puriste de cette technologie, soulignant que la valeur réside désormais dans la conception et la supervision, pas dans la production de code brute.

Il utilise l’IA comme un outil collaboratif : pour des tâches simples, elle agit comme une exécutante rapide, tandis que pour les parties complexes, il supervise et valide, voire code lui-même. L’objectif est de maintenir une architecture compréhensible et maîtrisée, évitant ainsi les risques liés à des systèmes opaques ou dépendants de tarifs ou de disponibilités externes.

Enfin, il compare l’IA à un retour partiel du cycle en V, où la spécification redevient centrale. La confiance dans le code généré doit être proportionnelle à la capacité de le critiquer, et les rôles (spécification, validation, expertise) doivent rester clairs pour préserver la robustesse du système.

Le site EasyDMARC propose un outil de vérification et d'analyse des enregistrements DMARC, un protocole essentiel pour sécuriser les emails contre le phishing et le spoofing. L'outil permet de détecter les vulnérabilités des configurations DMARC, SPF et DKIM, offrant des rapports détaillés et des recommandations pour renforcer la sécurité des emails et la réputation des domaines.

EasyDMARC se distingue par son interface intuitive, adaptée aux utilisateurs de tous niveaux, et ses fonctionnalités avancées comme les alertes en temps réel et la gestion multi-domaines. La plateforme propose également des outils complémentaires (DKIM, SPF, BIMI) pour une sécurité email complète, tout en étant utilisée par des milliers d'organisations à travers le monde.

Le service met l'accent sur la simplicité d'utilisation, avec des guides et des visualisations claires pour faciliter l'analyse et la configuration, tout en s'adaptant aux besoins des entreprises et des fournisseurs de services gérés (MSP).

L’article SVG from Scratch explique que SVG n’est pas un simple format d’image, mais un système de coordonnées, une surface de style et une cible d’animation, comparable à un élément DOM. L’auteur souligne l’importance de comprendre le viewBox, qui définit un espace de coordonnées interne que le navigateur adapte à la taille d’affichage, permettant une conception flexible et scalable.

L’auteur présente les formes de base (cercle, rectangle, ligne, polygone, chemin) et leur syntaxe, en insistant sur la puissance du path, qui permet de créer des formes complexes. Il détaille aussi les commandes de base pour dessiner des courbes, lignes et arcs, en distinguant les coordonnées absolues et relatives.

Enfin, l’article aborde le style des SVG via CSS, où les propriétés comme fill, stroke ou opacity peuvent être contrôlées dynamiquement, avec une priorité sur les styles définis en CSS plutôt qu’en attributs SVG. L’auteur encourage à écrire manuellement le code SVG pour en exploiter pleinement les possibilités.

Ce site propose un tutoriel moderne et complet sur JavaScript, couvrant à la fois les bases du langage et ses aspects avancés, comme la programmation orientée objet ou les promesses. Il est structuré en trois parties : le langage JavaScript, la manipulation du navigateur (DOM, événements) et des articles thématiques supplémentaires. Le contenu est régulièrement mis à jour, avec la dernière version datant de mai 2026.

L’approche pédagogique mise sur des explications claires et détaillées, sans se perdre dans des détails spécifiques à un environnement particulier. Le tutoriel aborde aussi des outils comme les éditeurs de code, la console développeur et les tests automatisés, tout en intégrant des concepts modernes comme les modules, les classes ou l’asynchrone avec async/await.

Disponible en ligne gratuitement, le site propose également des versions payantes en EPUB/PDF. Il inclut des liens vers des ressources complémentaires comme un dépôt GitHub ou un chat Discord pour échanger avec la communauté.

Topgrade est un outil open source écrit en Rust qui automatise la mise à jour de multiples gestionnaires de paquets et logiciels sur un système. Il détecte les outils installés (comme apt, pacman, Homebrew, etc.) et exécute les commandes appropriées pour les mettre à jour, simplifiant ainsi la maintenance du système. Ce projet est un fork maintenu du logiciel original topgrade par r-darwish.

L'installation est possible sur diverses plateformes via des méthodes officielles (binaires auto-mis à jour, gestionnaires de paquets comme Homebrew ou APT) ou communautaires (Scoop, NixOS, etc.). Une fois installé, il suffit d'exécuter topgrade pour lancer la mise à jour globale. Une configuration personnalisable au format TOML permet d'ajuster son comportement.

Le projet suit une politique de versions stables (MSRV) et documente les changements majeurs dans ses notes de version. Les fichiers de configuration sont recherchés dans des emplacements standardisés selon le système d'exploitation, comme %APPDATA% sous Windows ou ~/.config sous Unix.

L’auteur partage sa stack frontend pour 2026, axée sur des outils éprouvés et efficaces. Il utilise Next.js pour les sites de contenu (SSR, optimisation d'images) et Vite 8 pour les applications internes (HMR instantané, builds rapides grâce à Rolldown). TypeScript en mode strict et pnpm (pour sa rapidité et son gestionnaire de dépendances optimisé) complètent les fondations.

Pour le design, Tailwind CSS simplifie le style tandis que shadcn/ui fournit des composants accessibles et personnalisables, évitant les dépendances externes. Storybook est intégré pour documenter et tester les composants, notamment en synergie avec shadcn/ui, offrant une vue claire des variantes et états.

L’article souligne l’importance d’une stack stable et productive, privilégiant des outils qui s’intègrent bien et réduisent les frictions, plutôt que les dernières tendances. L’auteur mentionne aussi des outils complémentaires comme TanStack Query, Zustand, Zod, ou Vitest pour les tests, reflétant une approche pragmatique et optimisée.

L’auteur explique comment configurer un RAID 0 manuellement sur Linux Mint Debian Edition (LMDE), l’installateur ne proposant pas cette option. Il détaille les étapes de préparation des disques (suppression des métadonnées RAID existantes, effacement des partitions) avant d’installer le système sur un seul disque, puis de configurer le RAID 0 ultérieurement.

Après l’installation, il sauvegarde le système et utilise des outils comme mdadm pour créer le RAID 0 à partir des deux disques identiques. La procédure, adaptable à d’autres distributions, nécessite des manipulations en ligne de commande et diffère selon que la machine utilise un BIOS ou un UEFI.

L’article souligne les précautions à prendre (sauvegardes, vérifications) et propose une solution pour optimiser les performances en lecture/écriture sur des disques SATA, sans recourir à un SSD. Les commandes et étapes sont présentées de manière concise pour une mise en œuvre pratique.

L’article explique ce qu’est l’alcool isopropylique (ou isopropanol), un composé chimique distinct de l’éthanol, l’alcool des boissons. Il clarifie la notion d’alcool, qui varie selon le contexte, et souligne que l’isopropanol est utilisé comme solvant, dégraissant et désinfectant grâce à son évaporation rapide et son absence de résidus.

L’auteur détaille ses applications pratiques, notamment en électronique pour nettoyer les composants sans les endommager, ou en mécanique pour dégraisser chaînes, disques de frein et jantes. Il insiste sur son efficacité et sa polyvalence par rapport à d’autres alcools.

Enfin, le texte aborde brièvement sa concentration, sa conservation et où se le procurer, tout en rappelant que sa composition diffère de celle de l’alcool éthylique, souvent confondu dans le langage courant.

L’article explique comment sécuriser une application via Envoy Gateway en utilisant OIDC (OpenID Connect) et JWT pour l’authentification, ainsi que l’autorisation par groupes. L’auteur montre comment configurer une SecurityPolicy dans un cluster Kubernetes pour appliquer une authentification centralisée avec Keycloak, sans avoir besoin d’un outil supplémentaire comme oauth2-proxy.

La configuration repose sur une HTTPRoute pour router le trafic vers l’application, avec une règle dédiée pour le callback OIDC. La SecurityPolicy est ensuite attachée à cette route, définissant l’URL du fournisseur OIDC, les identifiants du client et les chemins de callback et de déconnexion. L’autorisation par groupe est évoquée, mais son implémentation détaillée n’est pas abordée dans cet article.

L’exemple utilise un cluster Kubernetes sur Clever Cloud avec un add-on Keycloak, mais la configuration de Keycloak et l’exposition via Gateway API sont supposées déjà en place. L’approche simplifie la gestion de l’authentification en intégrant directement ces fonctionnalités dans Envoy Gateway.

Chris Shiflett décrit la création d’un serveur MCP (Model Context Protocol) pour son laboratoire personnel, un espace où il centralise ses projets et outils maison. Il explique comment il a rationalisé son répertoire ~/local, autrefois encombré de projets inaboutis, en relançant des outils comme Landice, Faculty ou Schoolcase, tout en adoptant progressivement l’IA malgré ses réticences initiales. Son approche progressive avec l’IA, passant de simple référence à collaborateur, l’a conduit à voir cette technologie comme un "robot" capable d’exécuter du code, bien que des limites persistent, comme l’interface de Claude ou la perte de contexte entre conversations.

Shiflett souligne deux obstacles majeurs dans son utilisation de l’IA : d’abord, l’asymétrie entre l’exécution manuelle du code et l’approche automatisée de Claude Code, qui réduit sa participation active. Ensuite, le manque de mémoire des assistants, obligeant à résumer manuellement l’historique des échanges dans des fichiers Markdown avant de recommencer une conversation. Ces contraintes l’ont poussé à concevoir un serveur MCP pour mieux contrôler l’interaction avec l’IA et intégrer ses outils existants.

L’objectif final est de fluidifier ce processus en créant une interface unifiée, où l’IA agit comme un véritable partenaire de développement plutôt qu’un simple exécutant. Ce projet reflète sa volonté de concilier innovation technologique et méthodes de travail personnelles, tout en résolvant les frictions rencontrées dans l’adoption de l’IA.

L’article propose une version optimisée de l’utilisation de PostgreSQL pour remplacer Redis, en corrigeant les erreurs d’une précédente publication. L’auteur souligne l’importance des valeurs par défaut dans PostgreSQL 18, comme les fonctions uuidv4() ou uuidv7() pour les identifiants, ou encore la génération automatique des dates d’expiration via des intervalles, simplifiant ainsi les opérations côté client. Il met aussi en avant l’utilisation de RETURNING pour récupérer les valeurs générées directement lors de l’insertion, évitant des requêtes supplémentaires.

L’auteur critique l’héritage de tables, une fonctionnalité de PostgreSQL souvent mal comprise, car les index ne sont pas hérités, ce qui peut impacter gravement les performances. Il illustre ce problème avec un exemple comparant une table classique et une table héritée, montrant que l’absence d’index sur la table parente rend les requêtes coûteuses, même sur de grandes volumétries (25 millions d’entrées).

Enfin, l’article aborde brièvement l’utilisation des index, recommandant d’éviter les index inutiles qui alourdissent les opérations d’écriture. L’auteur conclut en insistant sur l’importance de bien comprendre les mécanismes de PostgreSQL pour éviter des erreurs de conception coûteuses en performance.

L’auteur explique comment Domain-Driven Design (DDD) a révolutionné sa vision de l’architecture logicielle, notamment pour les agents IA. Après des années de routine en développement, il découvre ce concept en lisant Domain-Driven Design d’Eric Evans, ce qui transforme sa manière d’aborder la complexité des systèmes. Son expérience précédente avec des microservices mal conçus, où les services manquaient de sens métier, l’a poussé à chercher une approche plus structurée.

Le livre l’a confronté à une réflexion approfondie sur la modélisation du domaine, où chaque détail (noms de classes, relations, effets de bord) devient crucial. Cette approche l’a ramené aux fondamentaux de la programmation orientée objet, avec une attention accrue à la clarté et à la cohérence du code. Il souligne que DDD a comblé un vide entre le développement et la compréhension du métier, contrairement à sa vision initiale où ces deux aspects étaient dissociés.

L’AFUP Day 2026 à Paris a réuni des professionnels de l’écosystème PHP autour de conférences axées sur l’intelligence artificielle, l’architecture et la productivité. L’événement a mis en lumière l’intégration croissante de l’IA dans les outils comme Symfony, avec des présentations sur les embeddings pour des recherches sémantiques et l’utilisation de LLM comme GitHub Copilot pour optimiser les workflows de développement.

Loïck Piera a présenté Castor, un task runner open source développé par JoliCode, tandis que Nicolas Grekas a exploré les avantages de Caddy et FrankenPHP pour moderniser la gestion des applications PHP, proposant une alternative au traditionnel PHP-FPM. Ces outils visent à améliorer la productivité et la durabilité des projets.

Enfin, des discussions ont porté sur les bonnes pratiques en matière de qualité de code, notamment avec PHPStan, et sur la nécessité de concilier fonctionnalité, pérennité et collaboration humaine pour garantir des logiciels robustes et évolutifs.

L’article de Josh W. Comeau compare les performances des animations en CSS et en JavaScript, un sujet souvent abordé avec des idées reçues. L’auteur explique que, contrairement aux apparences, les animations JavaScript ne sont pas nécessairement plus lentes, mais leur exécution sur le fil principal (main thread) les rend vulnérables aux blocages causés par d’autres tâches JavaScript. À l’inverse, les animations CSS s’exécutent sur un fil dédié, ce qui les rend plus fluides dans des applications complexes.

L’analyse se concentre sur deux méthodes : les keyframes CSS et une boucle JavaScript utilisant requestAnimationFrame. Bien que le JavaScript moderne soit optimisé pour des calculs rapides, son exécution sur le fil principal le rend sensible aux interruptions, contrairement au CSS qui bénéficie d’un traitement séparé. L’auteur illustre ce point avec une démonstration où des blocages du fil principal perturbent davantage l’animation JavaScript que l’animation CSS.

Enfin, l’article souligne que le choix entre CSS et JavaScript dépend du contexte : le CSS est idéal pour des animations simples et performantes, tandis que le JavaScript offre plus de flexibilité pour des interactions dynamiques ou complexes, malgré les risques de latence liés au fil principal.

L’article explique comment gérer les options et arguments dans des scripts Bash afin de rendre les scripts plus flexibles et robustes, notamment via les commandes getopts, shift et les variables spéciales comme $1 ou $@. Il détaille la différence entre options courtes et longues, montre comment vérifier la présence d’arguments obligatoires et recommande des pratiques de développement plus sûres comme set -euo pipefail pour détecter rapidement les erreurs et éviter les comportements inattendus dans les scripts shell.

L’article explore les défis liés à la mise à l’échelle des View Transitions entre documents, notamment pour des pages affichant des centaines d’éléments comme une grille de produits. Après avoir résolu les problèmes initiaux (métadonnées obsolètes, délais de timeout, etc.), l’auteur souligne que les tutoriels classiques, conçus pour des transitions simples, échouent face à des cas complexes. La solution idéale, purement CSS, reposerait sur des fonctions comme ident() et sibling-index() pour générer automatiquement des noms uniques, mais cette approche n’est pas encore implémentée dans les navigateurs.

En attendant, les développeurs doivent recourir à des méthodes manuelles fastidieuses, comme des règles CSS répétitives pour chaque élément, ce qui devient ingérable avec un grand nombre d’items. L’article met en lumière l’écart entre les promesses futures des standards CSS et les contraintes actuelles, tout en soulignant l’importance de solutions évolutives pour des interfaces dynamiques.

L’article aborde les difficultés rencontrées avec les Cross-Document View Transitions, une fonctionnalité permettant d’animer les transitions entre pages HTML classiques sans framework. L’auteur explique que les tutoriels obsolètes, utilisant une balise <meta> désormais dépréciée, induisent en erreur, tandis que les solutions pour Single-Page Applications (SPA) ne s’appliquent pas aux sites multi-pages. Les problèmes courants incluent des transitions silencieusement bloquées par un délai de 4 secondes, des distorsions d’images ou des styles CSS complexes pour gérer les noms de transitions.

L’auteur souligne l’absence de documentation claire et actualisée, rendant l’implémentation ardue malgré des démos prometteuses. Il annonce une série en deux parties pour clarifier les bonnes pratiques, comme l’utilisation de l’API @view-transition en CSS, la gestion des événements pagereveal et pageswap, ou encore l’optimisation des noms de transitions pour éviter des fichiers CSS surchargés. La seconde partie promet des solutions pour les projets à grande échelle, notamment la gestion des animations avec prefers-reduced-motion.

L’article dénonce la standardisation d’Internet sous l’ère des réseaux sociaux, qui a remplacé la créativité individuelle et l’expression personnelle par des plateformes uniformes et optimisées. L’auteur évoque son expérience des années 2000, où des outils comme MySpace permettaient de personnaliser son espace web avec du code HTML, transformant chaque profil en une œuvre unique et chaotique. Cette époque, marquée par l’expérimentation et l’authenticité, a cédé la place à des interfaces standardisées et professionnelles, vidant le web de sa dimension humaine.

L’auteur souligne que cette transition n’était pas seulement technique, mais culturelle, réduisant la diversité des expressions en ligne à une « monoculture technologique ». Il cite une analyse de Maria Farrell et Robin Berjon, comparant cette uniformisation à la sylviculture scientifique, qui a remplacé un écosystème créatif par des structures rigides et identiques. Aujourd’hui, les réseaux sociaux, autrefois perçus comme des progrès, sont critiqués pour leur impact négatif sur la société, notamment en termes d’authenticité et de bien-être.

Face à ce constat, l’article appelle à une reconquête du web par ses utilisateurs, en encourageant le retour à des pratiques plus personnelles et créatives, comme le codage ou l’hébergement de sites indépendants. L’idée centrale est de « réensauvager » Internet, en restaurant sa diversité et son âme originelle, loin des algorithmes et des templates imposés.

European Alternatives propose une plateforme pour identifier des alternatives européennes à des services et produits numériques courants, comme les solutions cloud ou SaaS. Le site met en avant l'importance de soutenir les entreprises locales, soulignant les retombées économiques (emplois, taxes) et la conformité aux réglementations européennes, notamment le RGPD, la TVA et les normes juridiques harmonisées au sein de l'UE. Il recense des alternatives dans divers domaines (hébergement, messagerie, moteurs de recherche, etc.) et encourage les utilisateurs à contribuer en suggérant de nouveaux services.

L’auteur explique pourquoi il a attendu d’avoir Redis et un worker Messenger avant de migrer vers Symfony Scheduler en production. Selon lui, sans ces deux éléments, le Scheduler ne serait qu’un cron amélioré, sans les fonctionnalités avancées comme l’asynchronicité, la persistance des états ou la gestion des échecs. Il souligne que Symfony Scheduler ne remplace pas cron, mais s’appuie sur une infrastructure adaptée pour offrir des mécanismes de planification robustes.

L’article détaille trois prérequis essentiels avant d’utiliser le Scheduler : un worker Messenger consommant en continu le transport dédié, un transport asynchrone pour éviter les blocages (comme Redis), et un pool de cache non volatile pour stocker l’état des tâches. Sans ces éléments, l’auteur estime que l’on recréerait les limitations des scripts cron, mais avec une complexité inutile.

Enfin, l’auteur illustre son propos avec cinq jobs actuellement exécutés sur son site, montrant comment le Scheduler simplifie la gestion des tâches récurrentes une fois l’infrastructure en place. Il conclut que le Scheduler est pertinent uniquement si l’environnement technique le permet, évitant ainsi les solutions hybrides peu fiables.

ROM Finder est un outil en ligne permettant de trouver des ROM alternatives pour smartphones. Il référence 623 appareils compatibles issus de 27 constructeurs, avec 5 systèmes alternatifs disponibles. Les informations sont mises à jour régulièrement et proviennent des sources officielles des projets concernés.

L’auteur explique pourquoi une nouvelle YubiKey 5C ne pouvait plus déverrouiller sa base KeePassXC, alors qu’il utilisait auparavant une YubiKey configurée avec le même secret HMAC-SHA1. Le problème vient de la méthode de provisionnement : les anciens outils (YubiKey Personalization Tools) utilisaient des options avancées non documentées, tandis que les outils récents (ykman) standardisent le processus, générant des réponses différentes pour un même secret.

Il souligne la dépendance implicite au logiciel initial, désormais obsolète, qui pourrait devenir difficile à utiliser à l’avenir. Yubico a en effet abandonné ses outils graphiques au profit de ykman, rendant la compatibilité rétroactive problématique. L’auteur recommande de reprogrammer les clés avec ykman et de mettre à jour le challenge-response dans KeePassXC, tout en sauvegardant un accès alternatif à la base avant toute manipulation.

Enfin, il détaille brièvement la procédure pour recréer le challenge HMAC-SHA1 dans KeePassXC via les options de sécurité, en utilisant la ligne de commande (ykman) pour configurer le slot 2 de la YubiKey. Une migration proactive évitera des difficultés futures lors du remplacement d’une clé.

Ce billet de blog, deuxième partie d’un test sur CKE (Clever Cloud Kubernetes Engine), explore les fonctionnalités avancées de stockage sur ce service managé. L’auteur détaille notamment l’activation du Container Storage Interface (CSI) via une commande simple, permettant l’utilisation de Ceph RBD pour des volumes persistants, avec une StorageClass configurée par défaut et la possibilité d’étendre les volumes à chaud. Il illustre ensuite le déploiement d’un PersistentVolumeClaim (PVC) et son utilisation dans un pod, confirmant la persistance des données après redémarrage.

L’article aborde également des cas d’usage concrets comme le déploiement de vCluster, un cluster Kubernetes virtuel fonctionnant dans le cluster hôte, partageant son infrastructure de stockage. L’auteur teste cette solution, soulignant ses avantages potentiels pour l’isolation des environnements (comme des environnements CI) tout en partageant les ressources, bien qu’il reste sceptique sur certains aspects de sécurité.

Enfin, le billet conclut sur les fonctionnalités de gestion du cycle de vie des volumes, incluant les snapshots et la restauration de données, avec une procédure technique détaillée en plusieurs étapes. L’auteur résume son expérience en mettant en avant la simplicité de mise en œuvre et la flexibilité offerte par CKE pour des besoins de stockage avancés dans Kubernetes.

Cette page propose le transcript d’une conférence de Pascal Martin intitulée « Des structures de données qui vont vous étonner », donnée notamment lors de la PyConFR 2025. L’auteur y explore des structures de données méconnues mais utiles, soulignant leur importance pour optimiser les performances des applications. Il illustre son propos avec des exemples concrets, comme les éditeurs de texte, et rappelle les bases des complexités algorithmiques (notation grand O) pour justifier le choix des structures adaptées.

La conférence met en lumière la diversité des structures de données, souvent ignorées au profit de solutions classiques comme les tableaux ou les listes chaînées. Pascal Martin en présente trois particulièrement pertinentes pour des besoins quotidiens, tout en insistant sur l’intérêt de ne pas réinventer la roue. Le transcript, proche du style oral, inclut des précisions absentes des slides, enrichissant la compréhension des concepts abordés.

Destiné aux développeurs et développeuses, ce contenu vise à éveiller la curiosité sur des outils peu exploités, tout en rappelant l’importance de sélectionner la bonne structure en fonction des contraintes algorithmiques. Le document s’accompagne de liens vers les slides et d’archives pour approfondir.

L’article interroge la qualité croissante des logiciels et l’impact de l’IA sur leur fiabilité, dans un contexte marqué par des failles de sécurité fréquentes et des fuites de données. L’auteur souligne que les vulnérabilités (CVE) ont fortement augmenté depuis 2017, attribuant cette hausse à des facteurs comme la pression des mises à jour quotidiennes, l’expansion du numérique et l’intensification des cyberattaques, plutôt qu’à l’IA. Il relativise cependant ce lien, notant que les CVE reflètent aussi une meilleure détection des bugs et une industrie cyber en croissance.

L’auteur évoque des exemples concrets, comme des failles majeures chez GitHub ou des attaques contre des institutions françaises, pour illustrer la dégradation perçue de la qualité logicielle. Il critique l’idée selon laquelle l’IA serait la principale responsable, soulignant que la baisse de fiabilité précède son adoption massive et s’explique davantage par des enjeux économiques et géopolitiques.

Enfin, l’article aborde la perception selon laquelle l’IA accélérerait la production de "code de merde", une idée que l’auteur juge exagérée. Il conclut que la qualité des logiciels dépend davantage des pratiques de développement et des pressions du marché que de l’IA, tout en reconnaissant que cette dernière pourrait aggraver certains problèmes si mal utilisée.

L’article souligne que Symfony, souvent perçu comme un framework monolithique, peut être utilisé comme un simple adapter pour isoler la logique métier du code lié au framework. L’auteur explique que, malgré une architecture apparente propre (contrôleurs légers, services organisés), une application Symfony mature reste profondément couplée à Doctrine et Symfony, ce qui limite sa maintenabilité et sa portabilité. Il illustre ce problème par un exemple concret où l’entité Order gère directement des calculs de taxes via des annotations Doctrine, montrant ainsi une dépendance implicite au framework.

Pour résoudre ce couplage, l’auteur propose une architecture en trois couches : le Domain (PHP pur, sans dépendances externes), l’Application (cas d’utilisation et interfaces) et l’Infrastructure (adaptateurs Symfony/Doctrine). Cette séparation stricte permet de tester et faire évoluer le domaine indépendamment du framework. Un contrôle CI vérifie que le dossier Domain/ n’importe jamais de classes Symfony ou Doctrine, garantissant ainsi l’étanchéité de l’architecture.

Enfin, l’auteur compare cette approche à celle d’un projet Laravel, insistant sur le fait que Symfony, comme tout framework, doit être traité comme un outil d’infrastructure et non comme le cœur de l’application. L’objectif est de rendre le code plus résilient aux changements technologiques tout en conservant la puissance de Symfony pour les aspects HTTP, persistance ou messagerie.

L’article explique comment utiliser Symfony Messenger pour gérer les événements du domaine sans créer de couplage excessif. L’idée principale est de séparer clairement l’interface du domaine (ports) de l’implémentation technique (adaptateurs), en s’inspirant de l’architecture hexagonale. Ainsi, le domaine reste indépendant du framework, utilisant des interfaces comme DomainEvent et EventBus pour publier des événements sans dépendre de Symfony Messenger.

L’auteur illustre cette approche avec un exemple concret : un événement OrderPlaced est défini comme une classe PHP simple, sans annotations ni dépendances vers Messenger. Les agrégats du domaine enregistrent ces événements dans une collection interne, puis l’application les publie via une implémentation de EventBus qui utilise Messenger en arrière-plan. Cela permet de changer de transport (AMQP, Redis, etc.) sans modifier le code métier.

Enfin, l’article souligne l’importance de maintenir cette séparation pour éviter les problèmes de couplage, comme des noms de classes ou de namespaces qui briseraient le code en cas de modification du framework. L’objectif est de conserver une architecture propre et maintenable, où le domaine reste au centre et les détails techniques en périphérie.

L’article explique comment résoudre le problème des requêtes N+1 dans Symfony 8.1 avec Doctrine ORM, un fléau pour les performances des applications. Il détaille d’abord le mécanisme du N+1, où une requête initiale récupère N entités, puis N requêtes supplémentaires chargent leurs relations, dégradant fortement les performances en production.

L’auteur propose des stratégies avancées pour l’éviter, comme l’utilisation de DQL avec JOIN FETCH pour charger les entités et leurs relations en une seule requête, ou encore des modes de récupération précis et l’hydratation via des DTO. Ces méthodes, combinées à des outils comme le Symfony Web Profiler, permettent d’optimiser significativement les endpoints.

L’article explique comment configurer Symfony pour l’architecture hexagonale en utilisant l’autowiring, simplifiant ainsi la gestion des dépendances. L’idée principale est d’éviter les configurations XML complexes en exploitant les fonctionnalités modernes de Symfony (autowiring, autoconfigure et un bloc bind minimal), réduisant services.yaml à moins de vingt lignes pour un contexte métier entier. L’auteur illustre cette approche avec une structure de projet claire, où les interfaces (ports) définies dans la couche Domain sont automatiquement liées à leurs implémentations (adaptateurs) dans Infrastructure sans configuration explicite.

L’exemple montre comment une classe d’application comme PlaceOrder dépend uniquement d’interfaces (ex. OrderRepository, Clock, EventBus), laissant Symfony injecter les bonnes implémentations (ex. DoctrineOrderRepository, SystemClock) via l’autowiring. Trois paramètres dans services.yaml (autowire, autoconfigure et public) suffisent pour automatiser cette injection, tandis qu’un attribut PHP 8.3 gère les cas ambigus. L’article souligne que cette méthode élimine le besoin de fichiers de configuration verbeux, tout en respectant les principes de découplage de l’architecture hexagonale.

Ce dépôt GitHub propose un bundle Symfony natif en PHP pour instrumenter les applications avec OpenTelemetry, sans nécessiter d'extension C. Il permet un traçage automatique des requêtes HTTP, des commandes console, des appels HttpClient, des messages Messenger, des tâches Scheduler, des requêtes Doctrine DBAL, du cache, de Twig et des logs via Monolog, avec une corrélation des traces. Compatible avec divers backends comme Traceway, Jaeger ou Datadog, il supporte Symfony 6.4 à 8.x et garantit une propagation correcte des contextes de trace, même sous charge.

L'installation est simplifiée via Composer, avec une configuration minimale pour exporter les traces en OTLP. Le bundle gère automatiquement l'enregistrement des spans pour chaque composant Symfony, capturant des détails comme les routes, les codes HTTP, les exceptions ou les requêtes sortantes. Une version 2.0 améliore la configuration imbriquée tout en maintenant la rétrocompatibilité.

Le projet met l'accent sur la fiabilité et la performance, avec des tests CI couvrant Doctrine DBAL 3 et 4, et des garde-fous contre les récursions dans les exports. La documentation détaille les composants traçables et les options de configuration avancées, comme les métriques optionnelles pour Messenger ou DBAL.

Les fuites massives de données permettent aux escrocs de personnaliser leurs spams avec des informations précises (adresse, numéro de sécurité sociale, etc.), rendant les arnaques plus crédibles. Ils ciblent désormais des victimes spécifiques plutôt que d’envoyer des messages génériques, augmentant ainsi l’efficacité de leurs tentatives de fraude.

Pour éviter de tomber dans le piège, il est crucial de vérifier l’expéditeur des e-mails. Une adresse frauduleuse peut imiter une entreprise légitime (ex. : vinci-autoroute.com au lieu de vinci-autoroutes.com), ou utiliser un domaine inattendu (ex. : .fi pour une entreprise française). Même les détails subtils, comme une lettre modifiée (rnicrosoft.com au lieu de microsoft.com), doivent être examinés.

Enfin, la règle d’or reste de ne jamais cliquer sur les liens contenus dans un e-mail suspect. Un simple clic peut confirmer à l’escroc que l’adresse est active, même sans interaction supplémentaire. La prudence et la vérification systématique des sources sont essentielles pour se protéger.

L’article d’Alex Bespoyasov explore l’application de l’architecture propre (Clean Architecture) au développement frontend, en s’appuyant sur une présentation et des exemples concrets. L’idée centrale est de structurer le code en couches distinctes (domaine, application et adaptateurs) pour améliorer la maintenabilité et l’extensibilité des applications, même face à des changements fréquents. L’auteur illustre cette approche en concevant une boutique de cookies avec React et TypeScript, tout en soulignant que la méthode reste compatible avec d’autres frameworks ou bibliothèques.

L’architecture propre vise à séparer les responsabilités selon leur proximité avec le domaine métier, centralisant ainsi les règles métier et réduisant les dépendances externes. Bespoyasov insiste sur la composition des composants pour faciliter les modifications futures, en citant Rich Hickey pour appuyer cette philosophie. Bien que l’exemple utilise React et TypeScript, l’auteur précise que ces outils ne sont pas obligatoires, et que l’accent est mis sur les principes plutôt que sur une implémentation rigide.

Enfin, l’article propose des pistes pour approfondir, comme des méthodologies complémentaires adaptées à différents types de projets. Bespoyasov rappelle que l’objectif est de comprendre l’idée plutôt que de reproduire servilement les exemples, encourageant les développeurs à adapter ces principes à leurs besoins spécifiques.

designmd.sh est un registre public de fichiers DESIGN.md, des documents que les agents d'IA (comme Claude, Cursor ou GitHub Copilot) utilisent pour générer des interfaces utilisateur cohérentes. Le service permet d'ajouter facilement un DESIGN.md à un dépôt via une commande npx, facilitant ainsi l'intégration avec divers outils de développement et plateformes web.

Le site propose une liste de DESIGN.md populaires, classés par nombre d'installations et d'audits, avec des exemples couvrant des marques comme Nike, SpaceX ou BMW. Ces fichiers servent de référence pour les agents d'IA, leur indiquant comment structurer et styliser les interfaces en fonction des bonnes pratiques d'une marque ou d'un projet spécifique.

Développé par l'équipe VoltAgent, designmd.sh met à disposition des ressources pour standardiser la conception UI/UX via l'IA, tout en offrant des fonctionnalités de suivi et de gestion des fichiers DESIGN.md. Le projet inclut également des liens vers les conditions d'utilisation, la politique de confidentialité et un canal de feedback.

CodeGraph est un outil open source conçu pour optimiser l'analyse de code par des agents IA comme Claude Code ou Cursor. Il génère un graphe de connaissances pré-indexé (symboles, relations, appels de fonctions) permettant aux agents d'interroger instantanément la structure du code plutôt que de scanner les fichiers, réduisant ainsi les coûts et les appels d'outils.

L'installation est simplifiée avec des scripts dédiés pour macOS/Linux et Windows, ou via npm. CodeGraph s'intègre automatiquement aux agents configurés et fonctionne localement sans dépendances externes, tout en restant compatible avec des projets existants.

Les benchmarks sur sept bases de code réelles montrent une économie moyenne de 35 % des coûts, 59 % de tokens en moins et un gain de vitesse de 49 %, grâce à l'indexation sémantique qui évite les recherches coûteuses.

Cette page détaille le matériel nécessaire pour monter une imprimerie maison artisanale, partagé par un passionné après plusieurs mois de recherches et d’expérimentations. L’auteur y décrit son équipement de base, choisi pour son rapport qualité-prix et sa durabilité, comme une imprimante laser Brother HL-5350DN, des massicots Dahle 561 et Lamirel MC-380, une plieuse Fordifold manuelle, ainsi qu’une agrafeuse à bras long Skrebba pour la reliure.

Le texte insiste sur l’importance de la découpe et de la reliure, avec des outils comme des planches à découper, des cutters et des éléments de reliure (cartonnages, couvertures transparentes). L’auteur souligne aussi l’utilisation de logiciels libres (Gimp, LibreOffice, Scribus) pour la mise en page, privilégiant des solutions accessibles et modifiables.

Enfin, l’auteur invite les lecteurs à partager leurs propres retours et alternatives, précisant que sa liste n’est ni exhaustive ni figée. Le projet reste ouvert aux améliorations et aux contributions extérieures.

FastCopy est un outil gratuit permettant de supprimer rapidement des millions de fichiers sous Windows, évitant ainsi des lenteurs et une surcharge des ressources système, notamment utile pour les fichiers de logs ou applicatifs. Compatible avec les versions de Windows de 7 à 11 et des serveurs de 2012 à 2025, il gère les chemins UNICODE et dépassant 260 caractères, tout en proposant des fonctionnalités de copie, synchronisation et déplacement. Une version Pro est requise pour un usage en entreprise, et le logiciel peut être installé ou utilisé en mode portable.

L’article explique comment résoudre les problèmes de confiance des certificats HTTPS générés par Symfony CLI sous WSL2 lorsque ces certificats sont utilisés depuis un navigateur Windows. L’idée principale est que WSL2 et Windows gèrent séparément leurs magasins de certificats racines, ce qui empêche Windows de faire confiance aux certificats locaux créés dans WSL2. L’auteur détaille d’abord l’installation du certificat racine local via Symfony CLI dans WSL2, puis la méthode pour exporter ce certificat depuis WSL2 et l’importer dans le magasin de confiance de Windows. Cette solution permet d’éviter les avertissements de sécurité dans les navigateurs Windows tout en maintenant un environnement de développement sécurisé.

L’article aborde les trois problèmes courants rencontrés lors de la configuration d’un environnement de développement Symfony 7 avec Docker et WSL2 sous Windows. L’auteur partage des solutions pratiques pour éviter ces écueils, notamment un conflit de port avec PostgreSQL (résolu en mappant le port 5433 sur l’hôte au lieu de 5432) et des soucis de permissions avec le groupe Docker sous WSL2 (corrigés via newgrp docker ou un redémarrage de WSL2). Il évoque aussi l’absence de démarrage automatique du démon Docker au lancement de WSL2, suggérant d’activer systemd ou de lancer manuellement le service. L’auteur justifie enfin son choix d’Apache plutôt que Nginx pour des raisons de simplicité dans un contexte de développement.

L’auteur explique comment il a modernisé un projet legacy reposant sur Alice, Nelmio, Hautelook et Faker pour le rendre plus maintenable avec Doctrine. Après avoir réduit la dépendance à Faker et converti les fixtures Alice de YAML à PHP, il a évité un piège courant : migrer Alice vers Foundry sans résoudre les problèmes sous-jacents, ce qui aurait prolongé la dette technique. En créant une commande personnalisée pour charger toutes les fixtures en une seule fois, il a simplifié le processus et supprimé plusieurs dépendances, dont doctrine/doctrine-fixtures-bundle. Cette approche a permis une migration rapide et une meilleure maintenabilité, illustrant l’importance de privilégier des solutions simples et intuitives plutôt que des refontes coûteuses et peu efficaces.

L’auteur relate un problème rencontré dans son lab où le redémarrage de systemd-networkd provoquait la perte du lien entre Incus et une interface réseau, car l’index de cette dernière changeait. Une solution a été trouvée en utilisant l’option KeepMaster de systemd, qui maintient l’index de l’interface lors des rechargements ou redémarrages, évitant ainsi la rupture avec Incus.

Le billet mentionne également une commande alternative (ip link set vxlan5 parent br5) pour rattacher explicitement une interface à une parente, bien que cette méthode ne soit pas documentée de manière évidente dans les ressources systemd. L’auteur souligne l’efficacité de KeepMaster pour résoudre son problème récurrent, lié à la gestion des interfaces VXLAN dans son infrastructure.

Ce retour d’expérience s’inscrit dans une série de notes techniques autour de l’administration système et du DevOps, avec une approche pragmatique pour contourner des dysfonctionnements courants dans des environnements Linux modernes.

Symfony 8.1 modernise les commandes console en intégrant les value resolvers Doctrine, comme #[MapEntity], déjà disponibles pour les contrôleurs depuis Symfony 6.2. Cette évolution permet de simplifier la résolution des entités directement dans la signature de la méthode __invoke() d’une commande, réduisant ainsi le code boilerplate. Par exemple, la commande app:user:2fa-setup peut désormais injecter une entité User via #[MapEntity], éliminant les méthodes manuelles de recherche comme findUser().

L’article illustre cette amélioration avec un cas concret : avant Symfony 8.1, il fallait gérer manuellement la récupération de l’utilisateur via EntityManager, tandis qu’après, l’entité est résolue automatiquement grâce à #[MapEntity], qui mappe l’argument console à une propriété de l’entité. Cette approche standardise le comportement entre les commandes console et les contrôleurs HTTP, tout en réduisant la complexité du code.

Enfin, l’auteur souligne que cette modernisation, bien que mineure, révèle des commandes obsolètes encore présentes dans le codebase, rappelant l’importance de maintenir un code propre. Il note aussi un prérequis non documenté : #[MapEntity] nécessite une contrainte d’unicité sur la propriété mappée pour fonctionner correctement.

Scott H Young explique que pour lire de meilleurs livres, il faut d'abord lire davantage, car la quantité améliore la qualité. En accumulant des connaissances sur un sujet, on renforce sa capacité à comprendre des ouvrages plus complexes, comme illustré par son exemple avec The Fragility of Goodness de Martha Nussbaum, dont la lecture exige une familiarité préalable avec des concepts philosophiques. Ainsi, lire plus permet de mieux saisir des textes exigeants, même si la compréhension initiale reste partielle.

Cependant, cette approche comporte un risque : la dépendance au chemin parcouru. Plus on se spécialise dans un domaine, plus on devient compétent pour en lire les ouvrages, mais moins on perçoit les perspectives alternatives. Young en fait l'expérience avec ses propres livres, où ses recherches initiales sur le transfert d'apprentissage l'ont conduit à approfondir des théories spécifiques, limitant progressivement sa vision globale.

En résumé, Young recommande de diversifier ses lectures pour éviter de s'enfermer dans une seule perspective, tout en soulignant que la lecture intensive reste la clé pour progresser dans la compréhension des livres exigeants.

Bon à savoir - cette erreur est probablement due à la présence de modules kvm

L’article explique comment mutualiser la configuration de quatre CRUDs (Post, Page, Category, Series) dans EasyAdmin grâce à un trait PHP, évitant ainsi la duplication de code. Les entités partagent une structure commune (statut, slug, planification, SEO, Schema.org) mais nécessitent des adaptations mineures, gérées par des branches conditionnelles basées sur leur FQCN. Le code est structuré en onglets (tabs) et ensembles de champs (fieldsets) pour améliorer la lisibilité, tandis que des helpers de visibilité (comme onlyOnForms ou hideOnIndex) permettent d’ajuster l’affichage selon le contexte.

L’auteur détaille l’utilisation de FormField::addTab et FormField::addFieldset pour organiser les champs de manière claire, puis extrait les sections récurrentes dans un trait (ContentFieldsTrait). Une branche conditionnelle gère les champs spécifiques à certaines entités (par exemple, la catégorie pour un Post), tandis que des types de champs comme AssociationField ou ChoiceField avec des enum natifs simplifient les relations et les sélections. L’objectif est de maintenir un code DRY (Don’t Repeat Yourself) tout en restant flexible.

Enfin, l’article mentionne les limites du trait et propose d’extraire certaines logiques en services si la complexité augmente. Il s’inscrit dans une série de six billets sur EasyAdmin, après des épisodes consacrés à l’installation, à la construction d’un menu ou à la sécurisation d’un admin. La méthode vise à éviter la divergence des configurations tout en gardant un code maintenable et lisible.

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.

L’auteur partage sa méthode pour développer des produits avec l’IA tout en maîtrisant les coûts, en limitant la consommation de tokens à environ 20 € par mois. Il utilise principalement Claude pour coder, notamment pour ses projets Writizzy (une plateforme de newsletters) et Hakanai (blogs statiques), en appliquant une approche de context engineering pour guider l’IA et éviter les erreurs.

Pour structurer son travail, il s’appuie sur des fichiers Claude.md définissant les spécifications du projet et des règles conditionnelles (.claude/rules) qui imposent des bonnes pratiques (comme l’utilisation de Nuxt UI ou des vérifications de typage). Ces règles, affinées empiriquement, réduisent les explorations inutiles de l’IA et optimisent l’efficacité.

Enfin, l’auteur souligne que ces mesures ne sont pas infaillibles : il complète avec des contrôles automatisés (tests, linters, CI) pour limiter les risques d’erreurs. Il évoque aussi une possible transition vers un autre modèle, plus performant pour le code, tout en maintenant une approche budgétaire stricte.

L’article de Teddy Ferdinand souligne que l’intégration tardive de la cybersécurité dans un projet limite ses options à des mesures radicales, comme bloquer la mise en production ou imposer des corrections coûteuses, faute de pouvoir ajuster l’architecture ou les choix techniques en amont. L’auteur explique que cette approche brutale résulte souvent d’un manque de collaboration précoce, où les critères de sécurité ne sont pas définis dès le début, transformant une revue finale en révélateur de problèmes évitables.

Ferdinand illustre que les blocages en fin de projet sont rarement perçus comme des solutions, mais plutôt comme des échecs, car ils surviennent après que les engagements métiers, les budgets et les délais aient été figés. Il insiste sur l’importance d’intégrer la sécurité dès les phases clés, en amont, pour éviter des arbitrages douloureux et des tensions entre équipes projet, métier et management.

Enfin, l’auteur rappelle que la sécurité ne vise pas à freiner les projets, mais à les sécuriser de manière proactive, en clarifiant les règles, les responsabilités et les critères de validation avant que les choix ne deviennent irréversibles.

L’article de Thomas, développeur expérimenté, explore l’impact des outils d’IA comme les LLM sur sa pratique professionnelle et personnelle. Il décrit une perte progressive de motivation pour coder en dehors de son travail, passant d’une activité créative et gratifiante à une tâche de supervision technique, plus rapide mais moins épanouissante. Ce changement subtil, qu’il compare à un musicien délaissant son instrument, touche aussi d’autres développeurs expérimentés, bien que l’IA ait parallèlement démocratisé la programmation pour les non-initiés.

L’auteur souligne l’ironie de cette situation : si les LLM libèrent des profils non techniques en automatisant des tâches complexes, ils transforment le métier de développeur en une activité de contrôle qualité, éloignée de la création pure. Ce basculement, de l’artisanat à la révision, altère la nature même du plaisir lié au codage, centré désormais sur la validation plutôt que sur l’innovation ou la résolution de problèmes.

Enfin, Thomas évoque la nostalgie des moments de découverte et d’apprentissage, illustrant cette perte par des exemples concrets comme le débogage ou l’architecture logicielle. Son témoignage met en lumière un paradoxe générationnel : l’IA, outil de libération pour certains, devient pour d’autres une prison invisible, vidant le métier de sa dimension la plus humaine.

CrowdSec est un outil de défense réseau communautaire qui dépasse les limites de fail2ban en mutualisant les informations entre serveurs. Contrairement à fail2ban, isolé et réactif, CrowdSec permet à un serveur d’apprendre des attaques détectées ailleurs et d’appliquer des bannissements préventifs avant même qu’une IP malveillante n’atteigne son infrastructure. Le système repose sur trois composants : l’Agent, qui analyse les logs locaux et génère des décisions de blocage ; le Bouncer, qui applique ces décisions à différents niveaux (réseau, proxy ou application) ; et la CAPI, une API centrale qui agrège et redistribue les bannissements validés par consensus parmi la communauté.

Le modèle de CrowdSec répond à trois faiblesses majeures de fail2ban : l’isolement des serveurs, l’inefficacité face aux attaques distribuées (botnets utilisant des milliers d’IP) et le coût silencieux des attaques répétées sur les ressources. En partageant les signaux d’attaque et en appliquant des bannissements globaux, CrowdSec réduit la charge sur les infrastructures tout en améliorant la réactivité contre les menaces émergentes.

L’écosystème de CrowdSec permet une intégration flexible, avec des scénarios personnalisables et des mécanismes de consensus pour limiter les faux positifs. Prochainement, un billet détaillera son déploiement concret, illustrant comment cette approche communautaire transforme la sécurité des serveurs publics.

Ce billet du Google Testing Blog souligne l'importance d'ajouter du contexte dans les réponses aux commentaires de revue de code. Plutôt que des réponses minimalistes comme "Fait" ou "Corrigé", il recommande d'expliquer brièvement le pourquoi ou le comment derrière les modifications, surtout lorsque les changements ne sont pas immédiatement évidents.

L'article illustre cette pratique avec des exemples concrets, comme l'ajout de tests pour des cas limites ou l'explication d'un choix de bibliothèque en fonction des contraintes du projet. Ces précisions facilitent la compréhension des reviewers et laissent une trace claire pour les futurs lecteurs du code.

Enfin, il encourage à documenter les décisions prises lors de discussions hors ligne ou les compromis techniques, afin que tous les contributeurs puissent suivre la logique derrière les modifications. Un lien vers le guide de revue de code de Google est proposé pour approfondir ces bonnes pratiques.

Ce billet explique comment exécuter localement des grands modèles de langage (LLM) gratuitement avec Ollama, un outil simplifiant leur déploiement. L’auteur détaille l’installation via Docker, le téléchargement d’un modèle et son intégration dans une application Symfony grâce au Symfony AI Bundle, tout en évitant les pièges courants. L’objectif est de montrer qu’il est possible d’utiliser des LLM sans dépendre de fournisseurs externes payants, tout en maîtrisant les coûts et la confidentialité des données.

Ollama agit comme un runtime local, optimisant les modèles pour le matériel et exposant une API HTTP locale. Ses avantages principaux sont l’absence de coûts marginaux (seule l’électricité est consommée), la confidentialité des données (pas de transmission externe) et la portabilité (le même setup fonctionne en développement comme en production). Cependant, la qualité des réponses reste inférieure à celle des modèles cloud comme GPT-4, surtout pour des tâches complexes nécessitant une prose élaborée.

Le guide s’adresse aux développeurs PHP/Symfony et se concentre sur des cas d’usage concrets comme la génération de métadonnées SEO ou l’extraction de données structurées. Il mentionne aussi les prérequis matériels, soulignant que des modèles de plusieurs milliards de paramètres exigent une infrastructure adaptée, sans entrer dans des comparatifs techniques.

L’article de JoliCode explore l’intégration de l’IA dans les workflows UX/UI, soulignant que l’IA ne remplace pas les designers mais redéfinit leur rôle en optimisant certaines tâches et en nécessitant de nouvelles compétences, notamment la maîtrise des prompts. L’idée centrale est que la qualité des résultats dépend directement de la précision des demandes adressées à l’IA, comparée à un briefing détaillé pour un collaborateur humain. L’auteur illustre cette nécessité par des exemples concrets, opposant des requêtes vagues à des formulations structurées intégrant tâche, contexte, éléments clés, comportements attendus et contraintes.

L’IA s’avère particulièrement utile à différentes étapes du processus créatif : exploration des idées, conception de maquettes ou de parcours utilisateurs, et production de contenus ou de composants. L’article insiste sur l’importance d’adapter son utilisation de l’IA selon la phase du projet, en l’intégrant comme un outil collaboratif plutôt qu’un simple générateur automatique. Les métaphores et retours d’expérience illustrent comment une intégration réfléchie peut accélérer les itérations tout en maintenant une approche centrée utilisateur.

Enfin, l’auteur met en garde contre les pièges courants, comme les prompts trop génériques, et propose une méthodologie pour formuler des demandes efficaces. L’objectif n’est pas de déléguer aveuglément à l’IA, mais de l’utiliser comme un levier pour gagner du temps sur les tâches répétitives, tout en recentrant le travail des designers sur l’analyse, la validation et l’innovation.

Ce billet présente le test de CKE (Clever Kubernetes Engine), l'offre Kubernetes managée de Clever Cloud, par l'auteur du blog. L'idée principale est de mettre en avant une solution Vanilla Kubernetes sans verrouillage propriétaire, avec des particularités comme une implémentation serverless de l'API etcd (Materia) et une infrastructure souveraine en France. L'activation de CKE, initialement cachée, nécessite un feature flag via la CLI ou l'onglet Labs de la console Clever Cloud.

L'auteur détaille ensuite la création d'un cluster, possible en ligne de commande ou via un formulaire intuitif, avec des options comme la version Kubernetes, la topologie (Essential, Business, Enterprise) ou le stockage persistant. Les topologies sont expliquées directement dans l'interface, et le déploiement est suivi en temps réel. La tarification et les performances (temps de boot, réseau, sécurité) sont également évoquées, avec des retours sur des bugs rencontrés en phase bêta.

L’auteur explore l’idée que notre époque pourrait déjà être une utopie, malgré une perception générale plus pessimiste. Il souligne un biais culturel où dystopies et mauvaises nouvelles dominent la fiction et l’actualité, car elles génèrent plus de conflits et d’intérêt que les récits utopiques ou positifs. Cette tendance reflète aussi notre nature humaine, naturellement centrée sur les problèmes et les menaces, ce qui nous pousse à ignorer les progrès accomplis.

Scott H. Young cite l’exemple de la "vibecession", où les indicateurs économiques sont bons mais où les gens restent pessimistes. Il attribue ce décalage à la médiatisation excessive des mauvaises nouvelles, qui influence la perception collective, même si les individus évaluent mieux leur situation personnelle. Ce phénomène s’explique par notre préférence évolutive pour les informations menaçantes, qui captent davantage l’attention que les nouvelles positives.

Enfin, l’auteur suggère que ce pessimisme systémique, observable dans les médias comme dans la fiction, pourrait être une caractéristique intrinsèque de l’être humain. Malgré des conditions de vie objectivement améliorées, notre tendance à nous focaliser sur les problèmes et à rechercher des récits conflictuels brouille notre capacité à reconnaître une utopie quand nous y sommes.

L’auteur explique comment les arguments booléens positionnels dans les appels de fonctions rendent le code difficile à lire et à comprendre. Il illustre ce problème avec des exemples comme createUser(user, true, false) où il est impossible de savoir ce que signifient les booléens sans consulter la définition de la fonction. Cette pratique, bien que pratique à écrire, force les développeurs à "décoder" plutôt qu'à lire le code, ce qui ralentit la compréhension.

Pour résoudre ce problème, l’auteur recommande d'utiliser des objets nommés à la place des booléens positionnels, comme createUser(user, { isAdmin: true, sendWelcomeEmail: false }), ce qui rend l'appel de fonction immédiatement compréhensible. Il suggère également de remplacer les booléens par des noms de fonctions plus explicites, comme createAdminUser(user) au lieu de createUser(user, true), lorsque cela est pertinent.

Enfin, l’auteur reconnaît que cette approche n'est pas toujours nécessaire pour des cas simples comme toggleMenu(true), mais devient indispensable dès qu'il y a plusieurs booléens ou que la signification n'est pas évidente. Il conclut que cette pratique améliore significativement la lisibilité du code, surtout dans des projets complexes où la maintenance et la compréhension sont cruciales.

Mise + Krew : gérer ses plugins kubectl de manière déclarative

L’article présente une solution combinant Mise et Krew pour versionner et configurer les plugins kubectl de façon reproductible. Mise, un gestionnaire d’outils en Rust, permet de déclarer les versions des plugins dans un fichier mise.toml, évitant ainsi les problèmes de synchronisation en équipe. Krew, le gestionnaire officiel de plugins kubectl, manque en effet de fonctionnalités de versionnage, ce que Mise comble grâce à son approche déclarative et ses backends multiples (GitHub, Aqua, etc.).

L’auteur explique comment Mise automatise l’activation des versions des outils dès l’entrée dans un répertoire contenant un fichier de configuration, simplifiant la gestion des environnements. Il souligne aussi l’avantage de Mise par rapport à des alternatives comme asdf, notamment pour son intégration avec des outils comme direnv et ses tâches intégrées. La solution proposée permet ainsi de standardiser les environnements Kubernetes en équipe, avec une configuration centralisée et versionnée.

Cette page de CSS-Tricks explore les différentes unités de longueur en CSS, essentielles pour dimensionner les éléments d'une page web. Elle distingue les unités absolues, comme le pixel (px), qui restent constantes quelle que soit la résolution de l'écran, des unités relatives, qui s'adaptent en fonction d'autres facteurs comme la taille de la police ou de l'écran. L'article détaille neuf types d'unités, couvrant les dimensions, l'espace, le temps et même le son, tout en expliquant leur utilité pour contrôler précisément le rendu visuel.

L’auteur revient sur son expérience de développement de k10s, un outil en Go pour surveiller les clusters Kubernetes avec des GPU NVIDIA, entièrement généré par IA via des sessions de vibe-coding. Après des débuts prometteurs où l’IA produisait rapidement des fonctionnalités fonctionnelles, des problèmes structurels majeurs sont apparus, notamment un god object (objet monolithique) de 1 690 lignes dans model.go, rendant le code ingérable et instable. L’auteur souligne que l’IA excelle pour écrire des fonctionnalités, mais échoue à concevoir une architecture cohérente sans intervention humaine.

L’expérience a révélé que le vibe-coding donne une fausse impression de productivité, masquant la dette technique accumulée. L’auteur explique que sans une planification humaine rigoureuse, le projet a rapidement dégénéré en un code spaghetti, malgré des démos impressionnantes. Il conclut que l’humain doit rester maître de l’architecture et imposer des contraintes pour éviter le chaos, même si cela ralentit temporairement le développement.

Le projet est désormais en cours de réécriture depuis zéro, avec une approche plus structurée. L’auteur partage ses leçons, comme l’importance de documenter des directives pour l’IA (AGENTS.md/CLAUDE.md) et de ne pas laisser l’outil dicter la conception. Le code initial est archivé, mais les enseignements tirés valent pour tout développeur utilisant l’IA de manière intensive.

L’édition 2026 du Devoxx a mis en lumière l’impact croissant de l’IA sur l’ingénierie logicielle, notamment à travers des architectures multi-agents et des outils émergents comme l’informatique quantique. Les conférences ont souligné des avancées majeures, comme les design patterns agentiques, qui redéfinissent l’interaction avec les grands modèles de langage (LLM) en structurant des écosystèmes autour d’objectifs, de mémoire, d’outils et de planification.

Parmi les concepts clés, le Retrieval Augmented Generation (RAG) a été présenté comme une solution efficace pour connecter les IA à des données actualisées ou privées, en optimisant l’extraction ciblée d’informations plutôt que leur intégration massive. Une autre approche, le planning programmatique, a été évoquée pour les processus métiers nécessitant un contrôle précis, où le développeur code une séquence fixe d’appels aux LLM, limitant ainsi les risques d’hallucinations.

Enfin, l’événement a abordé des enjeux futurs comme la résilience de l’expertise technique au-delà de 2030 et les défis posés par la complexité croissante des outils, tout en explorant des solutions pour maintenir la qualité logicielle à l’ère de l’IA.

L’auteur partage son expérience avec l’outil Claude Code d’Anthropic pour réaliser des tests d’intrusion (pentests) de manière rapide et efficace, sous réserve d’avoir l’autorisation explicite du propriétaire du site et de son hébergeur. Il détaille un processus en trois étapes, commençant par l’installation du plugin claude-pentest pour générer un premier rapport de vulnérabilités, puis en affinant les résultats avec une approche multi-agents pour une analyse plus critique. Enfin, il propose une méthode avancée de chaînage conditionnel pour identifier des attaques combinant plusieurs vulnérabilités mineures en une chaîne critique, en limitant les requêtes et en structurant la méthodologie par étapes théoriques et conditionnelles.

L’article explore quatre nouvelles fonctionnalités CSS 2025 pour une gestion avancée des couleurs, permettant de créer des thèmes dynamiques sans dépendre de préprocesseurs ou de JavaScript. Il met en avant des espaces colorimétriques modernes comme color() pour exploiter des gamuts élargis (Display P3, Rec2020) et des modèles perceptuellement uniformes comme oklch(), offrant des dégradés de luminosité plus naturels que le traditionnel HSL.

Parmi les outils présentés, color-mix() permet de fusionner des couleurs de manière intelligente, tandis que les syntaxes relatives (comme from) facilitent la dérivation de palettes à partir d’une teinte de base. Le dark mode est simplifié via color-scheme et light-dark(), évitant les requêtes média complexes. Ces innovations visent à uniformiser l’affichage des couleurs tout en optimisant l’accessibilité et l’adaptabilité aux écrans modernes.

L’article souligne aussi des fonctionnalités complémentaires comme accent-color pour personnaliser les éléments natifs de formulaire et contrast-color() pour ajuster automatiquement le texte en fonction du fond. Ces évolutions marquent une rupture avec les méthodes traditionnelles, en intégrant nativement dans CSS des capacités autrefois réservées aux outils externes.

L’article explique comment créer un widget personnalisé pour Symfony Terminal afin d’afficher un GIF animé dans le terminal, en l’occurrence un chat dégoûté. L’auteur détaille les étapes techniques, comme l’extension de la classe AbstractWidget, l’implémentation de la méthode render() pour générer le rendu ligne par ligne, et l’utilisation du hook onAttach() pour animer l’image via le scheduler de Symfony. Le rendu repose sur des caractères demi-bloc ANSI (comme ▀) pour simuler une résolution verticale accrue, tout en restant compatible avec le système de composition de TUI.

L’auteur partage ensuite trois bugs rencontrés lors du développement, illustrant les défis techniques : un problème de transparence dans le GIF, une animation figée malgré des frames distinctes, et des difficultés liées à la gestion des couleurs. Ces obstacles sont résolus grâce à des ajustements comme la duplication correcte des frames ou la gestion des canaux alpha. Le billet souligne aussi l’importance de l’event loop de Symfony, qui permet d’animer l’image sans bloquer l’interactivité du terminal.

Enfin, l’article précise que ce widget reste expérimental et non optimisé pour une utilisation en production. Il s’agit avant tout d’une démonstration technique, sans prétention de performance ou de comparaison avec d’autres solutions TUI en Rust ou Python. L’auteur conclut en partageant un extrait de code et en mentionnant l’utilisation d’un hook Makefile pour automatiser les tests.

postmarketOS est une distribution Linux libre et open source conçue pour prolonger la durée de vie des appareils électroniques, notamment les smartphones, en évitant l'obsolescence programmée liée aux mises à jour logicielles limitées. Son objectif est de fournir un système maintenable sur le long terme grâce à des composants partagés et une approche collaborative, tout en offrant aux utilisateurs un contrôle total sur leurs appareils.

Le projet met l'accent sur la durabilité, la confidentialité et la liberté logicielle, en s'appuyant sur des technologies existantes comme le noyau Linux principal et Alpine Linux. Il collabore étroitement avec d'autres projets open source pour améliorer l'expérience mobile, tout en contribuant activement en amont.

Bien que postmarketOS ne soit pas encore prêt pour le grand public, il progresse rapidement et s'appuie sur une communauté active. Une conférence est prévue du 25 au 27 septembre à Aix-la-Chapelle (Allemagne) pour discuter de son développement.

L’article explique comment structurer une architecture logicielle en trois couches (Domaine, Application, Infrastructure) en respectant la règle d’or centripète et le principe d’inversion de dépendance (DIP). L’idée centrale est que les dépendances doivent toujours aller du plus concret (infrastructure) vers le plus abstrait (domaine), jamais l’inverse, afin de préserver l’indépendance et la testabilité de la logique métier.

Le domaine concentre les règles métier, les agrégats (unités cohérentes comme un dossier de demande de subvention) et les value objects (objets immuables sans identité propre). Il définit des ports (interfaces) pour les besoins externes, sans jamais dépendre d’outils comme Doctrine ou Symfony. La couche applicative gère les cas d’usage via des handlers qui orchestrent les flux, tandis que l’infrastructure implémente concrètement ces ports (ex : adaptateurs pour Doctrine ou S3), sans jamais être importée par les couches supérieures.

Cette approche garantit que le métier reste isolé des détails techniques. Par exemple, un handler utilise DepositRequestRepositoryInterface (port défini dans le domaine) sans connaître son implémentation (DoctrineDepositRequestRepository en infrastructure). Ainsi, les changements d’outils n’affectent pas la logique métier, et les imports PHP respectent strictement la hiérarchie des couches.

L’article explique pourquoi les architectures CRUD (Create, Read, Update, Delete) compliquent les tests unitaires et augmentent la charge cognitive des développeurs. L’auteur souligne que la logique métier, dispersée dans des contrôleurs, services, FormType ou événements Doctrine, devient difficile à identifier et à tester, favorisant la duplication de code et les erreurs. Les modifications nécessitent de comprendre des interactions complexes, ralentissant le développement et augmentant le risque de régressions.

L’auteur illustre ce problème avec des exemples concrets en Symfony, où des règles métiers se cachent dans des couches techniques variées (validations dans les formulaires, effets de bord dans les écouteurs Doctrine). Cette dispersion empêche une couverture de test efficace, car les tests doivent souvent simuler des dépendances externes (bases de données, envoi d’emails) plutôt que de se concentrer sur la logique pure.

Enfin, l’article critique l’illusion des services génériques, qui masquent la complexité sans résoudre le problème de fond. La solution proposée est de distinguer clairement les contrats d’entrée (validation des données) des invariants métiers (règles de transition), afin de structurer le code de manière plus testable et maintenable.

L’article de Nicolas Jourdan critique la pratique courante de lier directement les formulaires Symfony aux entités Doctrine, soulignant les problèmes d’architecture qui en découlent. L’auteur explique que cette approche crée un couplage implicite entre la couche de présentation (formulaire) et le modèle métier (entité), transformant cette dernière en simple transporteur de données HTTP. Bien que pratique à court terme, cette méthode introduit des tensions lorsque l’application évolue, notamment en mélangeant les responsabilités (validation, normalisation) et en rendant le code difficile à maintenir.

L’exemple concret d’un formulaire d’inscription à une conférence illustre ces limites. Les règles métier (comme la vérification de la capacité des sessions ou l’expiration des codes promo) finissent par être dispersées entre les contraintes du formulaire et celles de l’entité, complexifiant la logique et réduisant la clarté du code. L’auteur met en garde contre cette approche, qui semble initialement simple mais devient problématique sous la pression des évolutions produit.

Pour remédier à ces problèmes, Jourdan propose une séparation plus nette entre les formulaires et les entités, en utilisant des objets dédiés (DTO) pour capturer les données brutes de l’utilisateur avant de les transformer en entités métier. Cette méthode permet de préserver l’intégrité du domaine tout en gérant plus efficacement les interactions utilisateur, évitant ainsi les compromis architecturaux coûteux à long terme.

Cet article présente une approche optimisée pour le développement Symfony en utilisant des Dev Containers sans root, Xdebug 3.4 et PHP 8.4, afin d’améliorer l’expérience développeur (DX). L’auteur met en avant l’utilisation de FrankenPHP, un serveur d’applications performant en Go, remplaçant Nginx + PHP-FPM, pour des temps de réponse rapides. La solution repose sur des conteneurs isolés et sécurisés, évitant les problèmes de permissions classiques avec Docker.

L’accent est mis sur la compatibilité IDE (VS Code et PhpStorm) et la résolution des écueils courants, comme les conflits d’architecture ou les montages de volumes. Les conteneurs rootless résolvent les erreurs de permissions en mappant l’utilisateur du conteneur à l’utilisateur local, éliminant le besoin de commandes comme chmod -R 777.

Enfin, l’article détaille la création d’un projet Symfony 7.4 via un conteneur temporaire pour Composer, sans installation locale de PHP. Le choix de l’image Docker (Alpine vs Debian) est crucial pour éviter des incompatibilités avec certains IDE, comme les plantages de JetBrains.

En 2026, PHP et Symfony s’imposent comme une stack mature et performante pour les CTO, grâce à des évolutions majeures. PHP 8.5, avec ses fonctionnalités typées (property hooks, pipe operator) et son JIT optimisé, ainsi que Symfony 7 et son écosystème de plus de cinquante composants découplés, couvrent désormais tous les besoins modernes : API (API Platform), e-commerce (Sylius), back-office (EasyAdmin), temps réel (Mercure), interfaces réactives (Live Components) et même le mobile via Hotwire Native. L’outillage industriel (PHPStan, Rector, PHPUnit 13) garantit une qualité de code élevée, tandis que FrankenPHP révolutionne l’infrastructure avec un throughput 3 à 4 fois supérieur à PHP-FPM et une latence divisée par cinq en mode worker.

L’auteur, CTO freelance avec quatorze ans d’expérience, souligne que cette stack n’est plus un compromis nostalgique mais une option par défaut, adaptée aux SaaS, applications métiers complexes ou projets IA-first. L’écosystème Symfony, autrefois perçu comme fragmenté, s’est structuré pour offrir une solution cohérente, réduisant les délais de développement et simplifiant la maintenance grâce à une expertise accumulée.

L’article s’adresse aux CTO et lead tech en quête d’une vision actualisée, mettant en avant la maturité de PHP/Symfony en 2026 : un langage strict et performant, un framework complet et un outillage industriel, le tout sans nécessiter de superposer des technologies front-end ou mobiles.

L’article de LifeDev présente douze habitudes simples pour une productivité durable, s’opposant à la culture du hustle qui privilégie l’épuisement au travail. L’idée centrale est que des pratiques équilibrées, comme bien dormir ou planifier sa journée à l’avance, préservent la santé mentale et physique tout en maintenant une performance constante sur le long terme. Les études citées montrent que travailler excessivement réduit l’efficacité après 50 heures par semaine, soulignant l’importance de méthodes réalistes.

Parmi les habitudes recommandées, la priorité au sommeil (7 à 9 heures) est mise en avant comme outil clé pour la clarté mentale et la créativité, tandis que la planification nocturne permet d’aborder la journée avec plus de sérénité. D’autres pratiques incluent des pauses régulières, l’activité physique quotidienne et le single-tasking, évitant ainsi la surcharge cognitive.

L’auteur insiste sur l’adaptabilité de ces habitudes à tout mode de vie, les présentant comme des piliers pour éviter l’épuisement et maintenir une productivité stable, surtout dans un contexte de travail à distance et de sollicitations numériques constantes.

L’article explique comment réduire significativement la consommation de tokens de Claude Code, un outil d’IA coûteux, en optimisant son utilisation. L’auteur souligne que les coûts explosent rapidement, notamment sur des projets complexes, avec des factures pouvant atteindre plusieurs centaines d’euros par jour en cas de mauvaise gestion. Il détaille ensuite des astuces pour limiter cette dépense, comme l’exploitation du Prompt Caching, qui permet de réutiliser des contextes déjà analysés sans relire systématiquement l’intégralité du code.

L’idée centrale repose sur la compréhension du mécanisme de lecture systématique de Claude Code, qui charge inutilement des fichiers (README, configurations, dépendances) avant toute action, générant des milliers de tokens inutiles. L’auteur propose des solutions concrètes, inspirées de retours d’expérience partagés en ligne, pour cibler cette source de gaspillage. Parmi elles, la configuration d’un fichier CLAUDE.md pour guider l’IA et éviter les explorations redondantes.

Enfin, l’article compare les tarifs des modèles (Sonnet, Opus, Haiku) et insiste sur l’importance de choisir le bon modèle selon l’usage. Il mentionne aussi les alternatives comme LiteLLM pour suivre les coûts sur des plateformes comme AWS ou Google Cloud. L’objectif est clair : diviser par cinq la consommation de tokens sans sacrifier la qualité des résultats, en combinant optimisation technique et bonnes pratiques.

SysWatch est un outil en ligne de commande pour diagnostiquer les performances d'un système en temps réel, conçu pour remplacer des commandes comme htop, iostat ou nettop. Il propose douze onglets couvrant les principaux sous-systèmes (CPU, mémoire, disques, GPU, etc.) et affiche des informations claires en anglais, avec des alertes d'anomalies dans un onglet dédié.

L'outil se distingue par sa simplicité d'installation (via Rust) et son interface intuitive, permettant de naviguer entre les onglets, de trier les données ou de rembobiner une session pour analyser l'historique. Une fonction de détection heuristique signale les problèmes courants (surcharge mémoire, processus gourmands, etc.) avec des suggestions de correction.

SysWatch cible principalement les systèmes macOS et Linux, évitant les dépendances système inutiles et les requêtes sudo superflues. Il se positionne comme un complément à NetWatch, avec une approche minimaliste et transparente sur les limitations techniques.

Kula est un outil léger et autonome de monitoring pour serveurs Linux, conçu pour être simple à déployer. Il fonctionne sans dépendances externes ni bases de données, sous forme d'un binaire unique, et collecte des métriques système en temps réel via les interfaces /proc et /sys. Les données sont stockées dans un moteur de stockage intégré basé sur un buffer circulaire, permettant une rétention efficace des informations.

L'outil surveille un large éventail de paramètres, incluant l'utilisation du CPU, de la mémoire, du réseau, des disques, ainsi que des températures, l'état des batteries et des conteneurs. Les métriques sont accessibles via une interface web en temps réel ou un tableau de bord en terminal, avec une granularité allant jusqu'à la seconde. Kula prend également en charge le monitoring d'applications spécifiques comme PostgreSQL ou Nginx, ainsi que des métriques personnalisées.

Développé en Go, Kula est distribué sous licence AGPL-3.0 et propose des versions précompilées pour différentes architectures. Son architecture modulaire et son approche sans base de données externe en font une solution adaptée aux environnements où la simplicité et la légèreté sont prioritaires.

curl.md est un outil open source conçu pour convertir des pages web en markdown optimisé, réduisant ainsi le nombre de tokens utilisés par les agents IA. Son objectif principal est d'améliorer l'efficacité des interactions avec les modèles de langage en fournissant des données structurées et moins volumineuses.

Le projet propose plusieurs méthodes d'utilisation, notamment via une commande curl directe, une installation en ligne de commande (CLI) ou l'intégration avec des agents comme Claude ou OpenCode. Il est également compatible avec des SDK pour une utilisation programmatique dans des applications.

Développé sous licence MIT, curl.md est maintenu par la communauté et offre une documentation complète ainsi qu'un espace de discussion pour les contributions et les retours d'expérience.

Ce dépôt GitHub propose un outil open source nommé text-to-cad permettant de générer des modèles 3D via des agents de codage comme Codex ou Claude Code. L'idée centrale est de transformer des descriptions textuelles en fichiers CAD (STEP, STL, 3MF, DXF, etc.) et en descriptions robotiques (URDF), avec un workflow local et sans dépendance à un backend. L'outil inclut un explorateur intégré pour visualiser les modèles et des compétences prédéfinies pour la conception, la robotique et la fabrication.

Le projet se distingue par son approche modulaire, avec des compétences regroupées dans des dossiers dédiés (.agents/skills, .claude/skills) et une compatibilité avec les standards industriels. Les utilisateurs peuvent décrire un objet, laisser l'agent modifier les fichiers sources, puis régénérer les artefacts avant de les inspecter et de les valider. Le dépôt met l'accent sur la reproductibilité, avec des références stables (@cad[...]) pour des modifications précises.

En complément, le dépôt propose des benchmarks et des exemples pour évaluer les performances des agents, tout en optimisant les téléchargements via Git LFS pour éviter de charger des fichiers lourds inutilement. La licence MIT et la documentation détaillée facilitent l'adoption et l'extension du projet.

OpenWarp est un fork décentralisé et open source du terminal Warp, conçu pour intégrer des modèles d'IA directement dans un environnement terminal tout en garantissant la confidentialité des données. Contrairement à la version originale, OpenWarp conserve les données (identifiants, conversations, clés) localement sur la machine de l'utilisateur, sans passer par un serveur externe. Il propose six protocoles natifs (DeepSeek, Anthropic, OpenAI, etc.) et supporte les endpoints compatibles OpenAI, avec une configuration simplifiée via un fichier TOML.

Le fonctionnement repose sur trois étapes : capture des commandes sous forme de blocs contextuels (incluant le répertoire, l'environnement et la sortie), routage direct vers le fournisseur d'IA choisi sans intermédiaire, et retour des résultats dans une interface utilisateur familière. OpenWarp conserve l'ergonomie de Warp (Blocs, Workflows) tout en remplaçant le backend IA propriétaire par une architecture locale et modifiable.

L'outil s'adapte aux préférences de l'utilisateur en permettant de personnaliser les fournisseurs d'IA, les invites et les agents CLI, avec des modèles de prompts dynamiques rendus via minijinja. Disponible sous licence open source, il cible les développeurs souhaitant un terminal intelligent sans dépendre de services cloud externes.

Claude-Red est une bibliothèque organisée de compétences en sécurité offensive conçue pour le système Claude Skills, permettant de transformer l'IA en un acteur du red teaming. Chaque compétence est un fichier structuré SKILL.md couvrant des surfaces d'attaque variées, comme les injections SQL, le développement d'exploits, l'évasion d'EDR ou encore les attaques sans fil (Wi-Fi, WPA2/3).

Le projet, développé par SnailSploit, propose une approche modulaire où les compétences sont chargées dynamiquement selon les besoins, évitant ainsi une surcharge contextuelle. Il s'adresse aux professionnels pour des engagements autorisés, des recherches de vulnérabilités, des CTF ou des formations, avec une méthodologie experte intégrée.

L'installation est flexible : clone du dépôt, script dédié ou sélection de catégories spécifiques (web, Active Directory, etc.). Le dépôt inclut aussi des outils comme convert_skills.py pour adapter les compétences et une documentation complète pour contribuer ou exploiter les fichiers.

Cet article explique comment utiliser les CTE (Common Table Expressions) avec Doctrine ORM en PHP pour optimiser des requêtes SQL complexes. Les CTE permettent de structurer des requêtes récursives ou décomposées, évitant ainsi des traitements applicatifs coûteux comme le problème N+1. L’exemple illustre la récupération des catégories parentes d’une catégorie donnée via une CTE récursive, plus efficace qu’une approche PHP itérative.

Doctrine ne supportant pas nativement les CTE dans son QueryBuilder ou DQL, l’auteur propose une solution alternative en utilisant une requête SQL native avec un ResultSetMappingBuilder pour mapper les résultats sur des entités. La requête CTE commence par identifier la catégorie de départ, puis remonte récursivement via les relations parent_id, tout en triant les résultats par profondeur.

L’article souligne l’intérêt des CTE pour des cas comme les hiérarchies arborescentes, tout en reconnaissant leur rareté dans le code courant. La méthode proposée contourne les limitations de Doctrine pour exploiter pleinement les capacités des SGBD modernes.

L’article relate l’expérience de l’auteur avec Varnish 9 et son support natif du TLS, combiné à Let’s Encrypt pour sécuriser les connexions. Il détaille le déploiement d’une machine virtuelle Debian 13 sur Hetzner Cloud, où Varnish a été installé via un dépôt APT officiel, simplifiant ainsi le processus. L’auteur souligne l’absence de complications avec IPv6 et l’utilisation d’un sous-domaine dédié pour les tests.

Pour les tests, une application FastAPI minimaliste a été créée, simulant une réponse lente (2 secondes) pour évaluer les performances de mise en cache de Varnish. Les résultats montrent une réduction significative du temps de réponse après le premier appel, passant de 2,4 secondes à 230 millisecondes, illustrant l’efficacité du cache.

Enfin, l’auteur évoque brièvement le fichier de configuration VCL par défaut de Varnish, qui nécessite des ajustements pour une utilisation optimale, notamment pour la gestion du TLS et des certificats Let’s Encrypt, dont la configuration sera abordée dans un futur billet.