Docker Bake est un outil qui simplifie et optimise la construction d'images Docker en offrant une approche déclarative et standardisée. Il s'appuie sur BuildKit et Buildx pour paralléliser les builds, gérer efficacement le cache et les dépendances, tout en évitant les scripts shell complexes et fragiles. Contrairement aux méthodes traditionnelles, souvent limitées par des dépendances aux systèmes d'exploitation et des séquences de builds séquentielles, Docker Bake sépare clairement la configuration des variables (dans des fichiers HCL ou YAML) et la définition des builds, facilitant ainsi la maintenance et l'évolutivité.

L'outil permet de définir des targets (cibles de build) avec leurs paramètres, plateformes et dépendances, tout en exploitant des fonctionnalités avancées comme le matrix build pour générer plusieurs variantes d'images en une seule commande. Par exemple, il est possible de construire simultanément des images pour différentes architectures (amd64, arm64) ou versions de langage, tout en optimisant le cache et les layers réutilisables. Cette approche réduit significativement le temps d'exécution et améliore la reproductibilité des builds.

Enfin, Docker Bake intègre des mécanismes de validation et de configuration centralisée, évitant les erreurs liées aux scripts shell et aux variables d'environnement mal gérées. Les fichiers de configuration (comme vars.hcl et docker-bake.hcl) permettent une gestion modulaire et collaborative, similaire à des outils comme Terraform. L'exécution des builds se fait via des commandes simples (docker buildx bake), avec des options de dry-run pour le débogage, rendant le processus plus robuste et adapté aux environnements DevOps modernes.

Dans cet épisode du podcast de Tim Ferriss, plusieurs invités proposent des stratégies concrètes pour réduire la complexité du quotidien et protéger son attention. Claire Hughes Johnson insiste sur l’importance de définir des règles personnelles et professionnelles explicites afin d’éviter la surcharge décisionnelle et les interruptions permanentes, tandis que Diana Chapman met l’accent sur la responsabilité individuelle, la réduction du “drama” relationnel et l’identification des comportements automatiques qui compliquent inutilement la vie. Anne Lamott défend une approche plus émotionnelle et spirituelle fondée sur le ralentissement, l’acceptation de l’imperfection et le recentrage sur quelques relations ou activités essentielles, alors que David Yarrow évoque l’importance de protéger son temps et de dire plus souvent non afin de préserver sa créativité et son énergie. L’ensemble converge vers une même idée : simplifier sa vie passe moins par des outils ou hacks de productivité que par des choix délibérés sur ce à quoi l’on accorde son temps, son attention et son engagement.

Les détecteurs de dioxyde de carbone (CO₂) se sont popularisés pendant la pandémie de Covid-19, car ils permettent d’évaluer indirectement le risque de présence de pathogènes dans l’air en mesurant la concentration de CO₂, liée à l’expiration humaine. Bien que moins dangereux que le monoxyde de carbone, un taux élevé de CO₂ (dès 2 %) peut provoquer fatigue et maux de tête, tandis qu’un seuil critique de 5 % devient dangereux.

La détection repose principalement sur la spectrométrie infrarouge non dispersive (NDIR), exploitant l’absorption spécifique du CO₂ dans l’infrarouge à 4 260 nm. Une source lumineuse infrarouge traverse une cavité exposée à l’air, et un filtre optique isole la bande d’absorption du CO₂ avant qu’un capteur (comme une thermopile) mesure la variation de température induite par les infrarouges.

D’autres méthodes existent, mais le choix dépend du coût, de la sensibilité et de l’usage (industriel, domestique, etc.). Contrairement au monoxyde de carbone, le CO₂ ne se détecte pas par des réactions chimiques, évitant ainsi les interférences et les faux positifs.

Ce guide des agences de cybersécurité australienne, américaine, canadienne, néo-zélandaise et britannique met en garde contre les risques spécifiques des systèmes d'IA agentique, de plus en plus utilisés dans les infrastructures critiques. Bien qu'ils automatisent des tâches répétitives, ces outils peuvent être détournés, causant des perturbations, des pertes de productivité ou des fuites de données, nécessitant une évaluation rigoureuse des scénarios à risque.

Les auteurs recommandent d'intégrer ces systèmes dans les modèles de sécurité existants, en limitant strictement leurs accès, notamment aux données sensibles ou systèmes critiques. L'IA agentique ne devrait être employée que pour des tâches à faible risque, avec une supervision constante pour maintenir la confiance dans ces technologies.

Destiné aux grandes organisations et gouvernements, ce document propose des bonnes pratiques pour sécuriser ces systèmes, depuis leur conception jusqu'à leur déploiement, en passant par une analyse des vulnérabilités potentielles et des comportements à risque.

Ce billet explique comment concevoir un menu d'administration efficace avec EasyAdmin dans Symfony, en s'appuyant sur l'expérience de l'auteur qui a retravaillé quatre fois son menu en deux ans pour éviter une dette d'usage quotidienne. L'objectif est de structurer un menu robuste et maintenable, en se concentrant sur la méthode configureMenuItems() du DashboardController, qui génère dynamiquement le menu sans configuration externe. L'article met en avant trois bonnes pratiques : organiser le menu pour qu'il résiste à la croissance, distinguer les trois types de liens (linkTo, linkToUrl, linkToDashboard), et conditionner l'affichage des éléments en fonction des rôles utilisateurs.

L'auteur détaille les trois familles de constructeurs de MenuItem : linkTo pour les CRUD, linkToUrl pour les liens externes ou personnalisés, et linkToDashboard pour le tableau de bord. Il souligne l'importance de la lisibilité et de la simplicité, en évitant la sur-organisation qui alourdit la navigation. Le billet aborde aussi des astuces comme l'utilisation de yield pour une génération dynamique du menu et l'ajout d'icônes compréhensibles en un coup d'œil. Enfin, il met en garde contre l'usage inutile de setPermission(), préférant une gestion des rôles plus intuitive.

Maigret est un outil open source conçu pour collecter des informations sur une personne à partir de son pseudonyme en scrutant plus de 3 000 sites web. Il ne nécessite pas de clés API et permet d'extraire des données disponibles publiquement, comme les profils et liens vers d'autres comptes, tout en gérant les restrictions comme les CAPTCHA ou les blocages.

L'outil propose des fonctionnalités avancées comme une recherche récursive, un filtrage par catégories ou pays, et une intégration dans des projets Python. Il inclut aussi un mode web pour visualiser les résultats sous forme de graphes et exporter des rapports, ainsi qu'une option d'analyse par IA pour synthétiser les données.

Disponible en ligne de commande, via une interface web ou un bot Telegram, Maigret fonctionne avec Tor et I2P, et met à jour automatiquement sa base de sites. Son code est hébergé sur GitHub sous licence MIT.

Dependency Cooldowns propose une solution simple pour réduire les risques liés aux attaques par dépendances malveillantes dans les écosystèmes de gestion de paquets. L’idée centrale est d’imposer un délai minimal (cooldown) avant qu’une nouvelle version d’une dépendance ne soit installée, limitant ainsi l’exposition aux attaques rapides. Par exemple, un cooldown de trois jours aurait bloqué 80 à 90 % des attaques analysées, dont des compromissions comme LiteLLM ou axios, où les fenêtres d’exploitation étaient de quelques heures seulement.

Le site détaille les implémentations par écosystème, comme uv pour Python (avec des commandes comme uv pip install --exclude-newer '3 days' foo) ou npm (via des outils comme cooldowns.sh). Bien que certains gestionnaires comme pip ne supportent pas encore les durées relatives, des contournements existent. La méthode s’applique aussi aux dépendances transitives, renforçant la sécurité globale.

Enfin, l’article souligne l’efficacité des cooldowns, même réduits à un jour, et fournit des exemples de configuration pour divers outils (pnpm, Yarn, Cargo, etc.). Une approche pragmatique pour limiter les risques sans complexité majeure.

GTFOBins est une liste curated d'exécutables Unix-like permettant de contourner les restrictions de sécurité locales dans des systèmes mal configurés. Le projet recense des fonctions légitimes de ces outils pouvant être détournées pour échapper à des shells restreints, élever des privilèges, transférer des fichiers ou établir des connexions inversées, sans exploiter de vulnérabilités spécifiques.

Développé par Emilio Pinna et Andrea Cardaci avec la contribution de nombreux autres, GTFOBins se concentre sur l'exploitation des outils natifs disponibles ("living off the land"). Il ne s'agit pas d'une liste d'exploits, mais d'un guide pratique pour les professionnels de la sécurité ou les administrateurs système.

Le site propose également une API JSON et des liens vers des ressources complémentaires comme LOLBAS pour les binaires Windows. Les utilisateurs peuvent contribuer en soumettant de nouvelles entrées ou techniques.

Obscura est un navigateur headless open source écrit en Rust, conçu pour l'automatisation à grande échelle et le web scraping. Il se distingue par sa légèreté (30 Mo de mémoire contre 200+ Mo pour Chrome headless), sa rapidité (démarrage instantané et chargement de page en 85 ms) et ses fonctionnalités anti-détection intégrées. Compatible avec les outils comme Puppeteer et Playwright via le protocole Chrome DevTools, il permet d'exécuter du JavaScript via V8 et propose des modes de stealth pour contourner les blocages.

Le projet propose des binaires prêts à l'emploi pour Linux, macOS et Windows, ainsi qu'une version cloud en développement pour une utilisation managée. Obscura est distribué sous licence Apache 2.0, sans fonctionnalités restreintes, et peut être compilé depuis les sources avec des options comme le mode stealth pour bloquer les trackers. Les performances et la simplicité d'installation en font une alternative intéressante aux solutions existantes.

Le dépôt GitHub inclut une documentation détaillée pour l'installation, l'utilisation en ligne de commande et l'intégration avec des outils comme Puppeteer, ainsi qu'un système de scraping parallèle pour traiter plusieurs URLs simultanément.

ImageWhisperer est un outil d'analyse d'images utilisant l'IA, conçu pour aider journalistes et chercheurs à détecter les manipulations, les contenus générés artificiellement ou les profils frauduleux. Il propose 41 vérifications automatiques en environ 25 secondes, avec des rapports clairs et des preuves en langage simple, tout en excluant explicitement les contenus illégaux comme la CSAM.

Le site met en avant des exemples concrets de fausses images et de deepfakes, issus d'une base de données régulièrement mise à jour, illustrant son utilité pour le fact-checking. Il se distingue par une approche plus précise que les détecteurs classiques, capable d'identifier des anomalies anatomiques ou des traces forensiques d'IA.

Développé par Henk van Ess et soutenu par Digital Digging, ImageWhisperer propose aussi des solutions pour les entreprises via une API ou des plans dédiés, tout en garantissant une utilisation encadrée par une politique stricte contre les abus.

Cette page explique le fonctionnement des grands modèles de langage (LLM) comme ChatGPT, depuis la collecte des données jusqu’à leur utilisation finale. Elle détaille notamment la phase de pré-entraînement, où des milliards de pages web sont filtrées pour constituer un jeu de données de haute qualité, comme FineWeb (44 To, 15 000 milliards de tokens). L’étape clé de ce processus est la qualité et la diversité des données, qui influencent davantage les performances du modèle que d’autres paramètres.

Le texte aborde ensuite la tokenisation, une étape essentielle où le texte brut est transformé en unités numériques (tokens) via des algorithmes comme Byte Pair Encoding (BPE). Cette méthode permet de compresser efficacement le texte tout en gérant les variations linguistiques, comme les conjugaisons ou les mots composés. Les modèles modernes utilisent des vocabulaires de plusieurs dizaines de milliers de tokens pour couvrir un large éventail de contenus.

Enfin, la page souligne l’ampleur des ressources nécessaires à l’entraînement des LLM, avec des chiffres représentatifs des modèles de pointe en 2024 (15 000 milliards de tokens, 405 milliards de paramètres). Elle met en lumière l’importance des pipelines de traitement automatisés, comme celui de Common Crawl, qui nettoient et structurent des pétaoctets de données brutes avant leur utilisation.

Le fine-tuning est une technique permettant de spécialiser un grand modèle de langage pré-entraîné sur des données spécifiques, évitant ainsi un entraînement coûteux depuis zéro. En 2026, des méthodes comme LoRA et QLoRA ont démocratisé cette pratique, réduisant les besoins matériels à une simple carte graphique grand public et un budget modeste. Le guide explique en détail leur fonctionnement, leurs avantages par rapport au RAG (Retrieval-Augmented Generation), et les outils adaptés (Unsloth, Axolotl, TRL).

L’article détaille les différentes approches de fine-tuning, des méthodes classiques comme le full fine-tuning aux techniques plus efficaces comme PEFT, LoRA et QLoRA, qui optimisent les ressources en ciblant uniquement une fraction des paramètres. Il aborde aussi les critères d’évaluation, les coûts réels, et les pièges à éviter, comme l’overfitting ou la confusion avec le RAG.

Enfin, le guide propose des cas concrets (assistant client, extraction juridique, modèle médical) et des recommandations pour préparer un jeu de données de qualité, essentiel pour des résultats performants. Il souligne l’importance croissante du fine-tuning en 2026 pour les entreprises souhaitant adapter les LLM à leurs besoins métiers.

L’article de Marcos F. Lobo identifie quatre signes révélateurs d’un mauvais design logiciel et propose des solutions pour y remédier. Parmi ces symptômes, la rigidité, qui se manifeste par un système difficile à modifier sans déclencher des réactions en chaîne, est souvent causée par un couplage excessif entre les modules. L’auteur illustre ce problème avec un exemple concret où une classe monolithique gère les frais de livraison via des instructions conditionnelles, rendant toute modification complexe et coûteuse.

Un autre problème abordé est la fragilité du code, où une modification dans un module peut entraîner des dysfonctionnements imprévus dans d’autres parties du système. Cette situation résulte généralement de dépendances cachées ou d’une logique trop interconnectée, comme l’utilisation de variables globales ou de singletons partagés entre modules. La solution proposée repose sur l’encapsulation et la séparation des interfaces pour limiter l’impact des changements.

Enfin, l’immobilité désigne l’incapacité à réutiliser des composants logiciels dans d’autres projets ou contextes, en raison d’un design trop lié à son environnement. L’auteur souligne que cette rigidité empêche une extraction efficace des fonctionnalités, souvent parce que le code mêle règles métier et détails d’implémentation.

L’article de Teddy Ferdinand critique l’idée reçue selon laquelle la cybersécurité serait le principal frein aux projets, soulignant que le vrai problème réside plutôt dans le flou organisationnel. Les règles imprécises, les responsabilités mal définies et les processus opaques créent une dette organisationnelle, où chaque équipe interprète différemment les attentes, menant à des blocages tardifs. Par exemple, des critères vagues comme "les accès doivent être sécurisés" sans détails concrets (MFA, gestion des droits, etc.) génèrent des incompréhensions et des risques non anticipés.

L’auteur explique que la sécurité n’est souvent que le révélateur de ces dysfonctionnements, intervenant trop tard dans un projet déjà mal maîtrisé. Les équipes découvrent alors des lacunes critiques (architecture non documentée, données sensibles exposées) qui auraient dû être identifiées en amont. Le manque de clarté dans les processus de validation et l’absence de SLA (accords de niveau de service) sapent la confiance et ralentissent in fine l’ensemble des parties prenantes.

En conclusion, Ferdinand plaide pour des règles explicites, des responsabilités attribuées et des critères de validation transparents, afin d’éviter que la sécurité ne soit perçue comme un obstacle alors qu’elle devrait être un garde-fou intégré dès la conception des projets.

L’article compare les solutions d’admission Kubernetes en 2026, un mécanisme crucial pour valider et modifier les requêtes avant leur persistance dans le cluster. Avec Kubernetes 1.36, les politiques natives (VAP pour la validation et MAP pour la mutation) deviennent viables, réduisant la dépendance aux solutions externes comme Kyverno ou OPA Gatekeeper. Ces dernières évoluent aussi, notamment Kyverno 1.17 qui adopte CEL comme moteur principal, aligné sur les politiques natives, mais conserve des avantages comme la génération de ressources.

Le choix entre ces solutions impacte la sécurité, la fiabilité et la maintenabilité du cluster. L’article évalue chaque option selon des critères concrets : complexité opérationnelle, dépendance externe, expressivité des politiques, capacité de mutation, et outils de test (audit, dry-run). Les politiques natives offrent une intégration directe à l’API server, limitant les risques de fail-open et les latences, tandis que Kyverno ou Gatekeeper proposent des fonctionnalités avancées comme la génération automatique de ressources.

L’objectif est d’aider les équipes à sélectionner la solution la plus adaptée à leurs besoins, en fonction de leur maturité opérationnelle et des exigences de leur environnement.

Curlie est un annuaire web collaboratif proposant une vaste collection de sites classés par catégories, couvrant des domaines variés comme l'actualité, les arts, l'informatique, les sciences ou encore les loisirs. L'outil permet à la fois une recherche ciblée et une exploration par thèmes, avec plus de 2,9 millions de sites référencés dans 92 langues. Le projet repose sur une communauté d'éditeurs bénévoles qui maintiennent et enrichissent les quelque 1,03 million de catégories disponibles.

En mai 2026, le portail moncompte.ants.gouv.fr a subi une faille IDOR (Insecure Direct Object Reference) ayant exposé les données de 11,7 millions de Français. L’exploitation, qualifiée de « vraiment stupide » par son auteur, consistait simplement à modifier un identifiant numérique dans une URL pour accéder aux comptes d’autres utilisateurs, faute de vérification d’autorisation entre l’authentification et la récupération des données.

L’article explique que cette vulnérabilité, courante mais critique, survient lorsque les applications ne contrôlent pas si un utilisateur a le droit d’accéder à une ressource spécifique, même après s’être authentifié. L’exemple donné illustre un endpoint /api/account/{id} où seule la session est validée, sans vérification que l’identifiant {id} correspond bien au compte de l’utilisateur connecté.

Pour éviter ce type de faille, l’auteur propose des solutions techniques avec Symfony et PHP, comme l’utilisation de Voters pour gérer les autorisations, l’absence d’IDs exposés dans les URLs, ou des tests automatisés pour détecter les accès non autorisés. Le problème ne dépend pas du framework utilisé, mais de l’absence d’une couche d’autorisation explicite.

Les fonctions CSS natives avec la règle @function permettent de créer des outils de calcul personnalisés directement dans le navigateur, évitant ainsi l'usage de préprocesseurs comme SASS ou de JavaScript pour des opérations complexes. Leur principal avantage réside dans la performance : les calculs sont exécutés nativement par le moteur du navigateur (en C++), ce qui améliore la vitesse de rendu et réduit les dépendances externes. Par exemple, une fonction peut encapsuler des calculs répétitifs, comme des espacements ou des tailles, pour un code plus maintenable.

La syntaxe des @function repose sur des règles strictes, notamment un typage explicite pour garantir la cohérence des données. Les types (<number>, <length>, <color>, etc.) permettent au navigateur de valider les entrées et d'optimiser les calculs. Le polymorphisme, via l'opérateur |, offre une flexibilité supplémentaire en autorisant une fonction à accepter plusieurs types de données, comme une taille absolue ou un pourcentage, pour des designs plus adaptables.

Enfin, ces fonctions simplifient la création de designs fluides en combinant des calculs mathématiques (comme clamp()) avec des règles dynamiques, réduisant le besoin de media queries. Leur adoption est particulièrement pertinente pour les projets axés sur la performance, où chaque milliseconde compte.

L’article partage des découvertes techniques récentes, notamment l’opérateur PHP match introduit dans la version 8.1, qui simplifie les correspondances de valeurs par rapport à un switch traditionnel, améliorant ainsi la lisibilité du code. L’auteure explore aussi des concepts TypeScript comme la différence entre as et satisfies, illustrant comment ce dernier offre une meilleure vérification des types à la compilation. Elle aborde également des réflexions sur les limites de TypeScript, soulignant l’importance de la validation des données au runtime et la pratique du parsing plutôt que de la simple validation pour renforcer la robustesse du code.

L’article explique comment configurer un backend HTTPS avec un certificat auto-signé dans Kubernetes en utilisant Gateway API et trust-manager, en remplacement des annotations simplistes d’Ingress-NGINX. L’auteur détaille la migration d’une ressource Ingress vers une HTTPRoute couplée à une BackendTLSPolicy, qui impose une validation stricte du certificat backend, contrairement à NGINX qui permet de désactiver cette vérification. La solution repose sur l’intégration d’une autorité de certification (CA) interne dans un ConfigMap, référencée par la BackendTLSPolicy pour valider le certificat auto-signé.

L’auteur souligne que Gateway API, bien que plus sécurisé et déclaratif, ne propose pas d’option pour ignorer la validation du certificat backend, contrairement à NGINX. La méthode proposée utilise trust-manager pour injecter automatiquement la CA dans le cluster, simplifiant ainsi la gestion des certificats auto-signés. Cette approche garantit une configuration cohérente et sécurisée, alignée sur les bonnes pratiques Kubernetes.