L'auteur détaille sa migration d’infrastructure en 2025, marquée par l’abandon de Proxmox au profit d’Hyper-V, principalement pour des raisons de performances et de gestion des sauvegardes : ZFS et PBS (Proxmox Backup Server) étaient devenus inadaptés à ses besoins, avec des vitesses de backup limitées à 100-150 Mbps contre 2 Gbps avec Hyper-V et Veeam, essentiel pour ses 7-8 To de données quotidiennes. Son infrastructure repose désormais sur deux serveurs sous Windows Server 2022 : un Supermicro X10SDV-4C-TLN4F (stockage NVMe et HDD en RAID 1) pour l’hyperviseur et un vieux HP MicroServer Gen8 (mis à niveau réseau et stockage) pour les backups, le tout protégé par un UPS APC reconditionné. Les VM, majoritairement sous Debian 12, incluent Ansible (avec Semaphore), LibreNMS, Home Assistant, Paperless-ngx, Jellyfin, Passbolt, Proton-backup, Wazuh et un serveur web. Le réseau est entièrement en 10 Gbps (catégorie 6 STP), avec un firewall OPNsense sur un NUC Intel N100. L’automatisation via Ansible/Semaphore gère mises à jour, backups (local, disques externes rotatifs, Backblaze B2 chiffré) et monitoring, respectant la règle 3-2-1. Il évoque aussi son wiki technique (xWiki) et son désengagement partiel du blog, critiquant l’impact des IA (comme Gemini) sur la visibilité des contenus humains, tout en reconnaissant leur utilité ponctuelle pour la veille ou l’écriture de scripts. Enfin, il souligne la désaffection des blogs au profit des réseaux sociaux et de l’IA, sans pour autant fermer son espace.
Encore un texte passionnant de Ploum qui fait réfléchir (et sourcé, toutes les sources lui permettant d'alimenter sa réflexion).
L'espionnage de masse est bien pire que ce que l'on imagine mais l'Europe protège un tout petit peu ses citoyens.
On est saturés d'indignation sans rien faire mais il y a quelques actions très concrètes (comme supprimer Whatsapp) : il faut accepter la difficulté, l'inconfort et le fait que ces actions ne seront jamais reconnues ou applaudies.
La merdification est à l'oeuvre de partout, même sur des applications qui paraissaient sûres puisque les fondateurs s'y étaient engagés... jusqu'à l'arrivée d'un gros chèque. Seul le logiciel libre peut lutter, à condition de ne pas chercher l'ajout de fonctionnalités superflues.
Ploum nous encourage aussi à ralentir et prendre du recul (cf son dernier échange avec Chris Brannons)
Enfin il nous encourage aussi à faire du vélo, comme symbole d'indépendance et de liberté.
L’article explique comment transformer sa to-do list en un outil efficace et anti-stress, en s’appuyant sur la psychologie du cerveau (effet Zeigarnik, dopamine) et 7 règles clés. L’idée centrale : le cerveau est obsédé par les tâches inachevées, ce qui génère du stress et réduit la concentration. Pour y remédier, il propose de planifier le matin (après avoir vérifié ses mails), de commencer par les tâches faciles pour créer un élan de motivation (« boule de neige »), de découper les projets en actions concrètes (règle des 25 minutes), et de regrouper les tâches similaires (« batching »). Autres astuces : noter chaque soirée les tâches accomplies (« Done List ») pour analyser son temps réel, gérer les imprévus en notant la prochaine micro-étape avant de s’interrompre, et choisir un outil simple (comme Google Tasks) qui permet de déléguer la mémoire à un système externe. L’objectif n’est pas de tout retenir, mais de libérer son esprit pour se concentrer sur l’essentiel.
Une méthode pour passer de la surcharge à la sérénité !
L’article propose un exercice simple pour identifier et réduire la charge mentale au travail, souvent source d’angoisse et de fatigue invisible. L’idée est de noter pendant une semaine toutes les petites contrariétés du quotidien (tâches répétitives, interruptions, demandes hors périmètre) sans les juger, afin de dresser un « relevé brut » de ce qui grignote temps et énergie. À l’issue de cette observation, trois questions clés permettent d’agir : automatiser les tâches répétitives, déléguer ce qui ne relève pas de son expertise, ou supprimer ce qui n’est plus nécessaire. L’objectif n’est pas une solution miracle, mais une prise de recul concrète pour reprendre le contrôle et alléger son quotidien, en se concentrant sur l’essentiel plutôt que sur l’accumulation de détails épuisants.
Un outil utile pour ceux qui se sentent débordés sans raison apparente !
Le 17 août 2025, le blog de l’auteur a subi un incident informatique : environ 179 000 requêtes web en 14 heures, ciblant uniquement trois fichiers sitemap.xml, provenant de 168 000 adresses IP uniques (majoritairement IPv4). L’attaque, jugée naïve et peu sophistiquée, a permis à l’auteur de réviser ses connaissances sur nftables et fail2ban. Après avoir bloqué l’accès aux fichiers ciblés via Apache, il a tenté de filtrer les requêtes avec fail2ban, mais a dû ajuster sa stratégie face à la charge : bannissement par grands blocs d’IP (/8 puis /16 en IPv4), limitation du trafic entrant, et enfin blocage par pays (sauf France). Malgré des erreurs initiales (rechargement intempestif de fail2ban, lecture complète des logs), l’incident a été maîtrisé en combinant ces outils et en nettoyant les logs pour éviter d’alourdir les sauvegardes. L’auteur souligne l’importance de bien connaître ses outils avant un incident et partage des commandes utiles pour nftables et fail2ban.
Un retour d’expérience technique et pédagogique sur la gestion d’un flux massif de requêtes indésirables.
Ce tutoriel détaillé explique comment mettre en place une solution de supervision complète de vos serveurs avec Prometheus (pour la collecte et le stockage des métriques système) et Grafana (pour leur visualisation sous forme de tableaux de bord interactifs).
Il couvre l’installation et la configuration de Prometheus et Grafana via Docker sur un serveur dédié, ainsi que le déploiement d’exporters comme node_exporter (métriques système), cAdvisor (métriques containers Docker), process_exporter (métriques processus), et blackbox_exporter (tests de disponibilité des services). Le guide aborde aussi la sécurisation des interfaces, la création d’alertes, et l’intégration d’Alert Manager pour la gestion des notifications. Idéal pour surveiller en temps réel l’état de votre infrastructure et recevoir des alertes en cas de dépassement de seuils, avec des exemples concrets et des tableaux de bord Grafana prêts à l’emploi.
Un super outil à auto héberger qui permet de convertir des fichiers dans plein de formats
Ce tutoriel explique comment déployer Longhorn, une solution de stockage distribué, sur un cluster K3s (Kubernetes léger).
Il détaille les prérequis (Kubernetes 1.28+, 2 Go de RAM, open-iscsi installé), la préparation d’un dossier dédié (/opt/longhorn), puis l’installation via un manifest YAML personnalisé pour spécifier le chemin de stockage. Après déploiement, il montre comment vérifier l’état des pods, corriger une mauvaise configuration via un patch, et tester le stockage avec un PVC de 1 Go. Des astuces pour la mise à jour, la vérification de l’état du service et le redimensionnement des volumes sont aussi partagées. Idéal pour ajouter du stockage persistant et résilient à un cluster K3s avec peu de ressources.
Ce guide explique comment optimiser le chargement des polices web pour éviter de ralentir un site : privilégiez le format WOFF2 (le plus efficace et universel), hébergez vos polices vous-même pour améliorer les performances et la vie privée, et utilisez font-display: swap pour afficher immédiatement un texte de repli avant le chargement de la police personnalisée. Pensez à pré-charger les polices critiques avec <link rel="preload" as="font" ...>, à sous-ensembliser les polices (unicode-range) et à éviter les formats obsolètes (TTF, OTF, etc.). Intégrez les déclarations @font-face directement dans le <head>, choisissez des polices de repli système bien adaptées, et utilisez size-adjust ou font-size-adjust pour limiter les décalages de mise en page (CLS). Enfin, testez sur des réseaux lents et surveillez l’impact des polices sur les performances, en limitant le nombre de variantes et en évitant les polices d’icônes au profit des SVG. L’objectif : allier design et rapidité sans compromis.
L'auteur montre qu’il n’est pas nécessaire de migrer vers TypeScript pour bénéficier de sa rigueur : PHP 8.1+, couplé à des outils d’analyse statique (Psalm, PHPStan) et à des bibliothèques idiomatiques, permet d’obtenir des garanties similaires en typage, validation et maintenabilité. L’article détaille des équivalences concrètes : DTOs (classes typées + validation runtime), énumérations (PHP enums + match), génériques (via docblocks et analyse statique), métadonnées (attributs PHP), validation (Symfony Validator), gestion des erreurs (objets Result ou exceptions), et asynchrone (queues ou Fibers). L’approche est incrémentale, avec des exemples prêts à l’emploi, et met en avant les forces de PHP (écosystème mature, performances) tout en comblant l’écart avec TypeScript sur la sécurité et l’ergonomie. À retenir : combiner typage statique, validation aux frontières et design explicite pour un code PHP aussi robuste et maintenable qu’une base TypeScript, sans tout réécrire.
L’article explique comment gérer la traduction de contenu statique (menus, titres, boutons) dans Symfony à l’aide du composant Translation. Il détaille les étapes clés : installation via symfony composer require translation, configuration des locales dans translation.yaml et routes.yaml, utilisation de clés (ex: about_us) dans des fichiers YAML par langue (messages.en.yaml, messages.fr.yaml), et intégration dans Twig avec le filtre |trans et un sélecteur de langue dynamique. Il aborde aussi le débogage avec debug:translation et l’extraction automatique des clés manquantes, tout en évoquant l’option d’utiliser des services externes comme Crowdin pour une gestion collaborative. Une approche simple et efficace pour internationaliser une application Symfony.
L’article explique la différence fondamentale entre les DTO (Data Transfer Object) et les Entities dans Symfony, deux concepts clés pour structurer proprement une application. Les Entities représentent les objets métiers persistés en base de données, liés à Doctrine et souvent chargés de logique complexe, tandis que les DTO sont des objets légers, dédiés au transfert de données entre les couches (API, formulaires, services), sans logique métier ni persistance. Utiliser des DTO permet de découpler la validation, la sérialisation et la manipulation des données des Entities, améliorant ainsi la maintenabilité, la sécurité (en évitant d’exposer directement les Entities) et la clarté du code. L’auteur souligne que les DTO sont particulièrement utiles pour gérer les entrées/sorties des contrôleurs ou des services externes, tandis que les Entities restent le cœur du modèle de données. En résumé, bien distinguer les deux optimise l’architecture et réduit les risques d’incohérences ou de fuites de données sensibles.
L'auteur partage son parcours personnel et professionnel avec Kubernetes, soulignant qu’il n’existe pas de réponse universelle. Il a découvert l’orchestration via Docker Swarm, puis Kubernetes à travers des services managés comme AKS (Azure) et GKE (Google Cloud), avant d’expérimenter des solutions plus légères comme K3S et Talos Linux. Chaque approche—services managés, déploiements "the hard way", ou outils simplifiés—offre des avantages et des limites, selon le contexte et les besoins. L’important est de choisir la méthode qui suscite la curiosité et permet d’apprendre en pratiquant, car Kubernetes et son écosystème évoluent constamment, offrant de multiples angles d’entrée. L’essentiel reste d’oser explorer et comparer, sans crainte de se tromper.
Un analyste confronté à une requête lente sur une table de 150 millions de transactions (2 minutes d’exécution, parfois des timeouts) a optimisé son code en utilisant une CTE (Common Table Expression) avec WITH. Au lieu de joindre d’abord les tables puis de filtrer, la CTE filtre d’abord les transactions récentes (20M de lignes au lieu de 150M), réduisant le temps d’exécution de 127 à 11 secondes. En allant plus loin et en agrégeant directement dans la CTE, il a même descendu ce temps à moins de 6 secondes. La clé ? Filtrer tôt pour alléger la charge de jointure, clarifier la logique, et exploiter les optimisations des moteurs modernes (PostgreSQL 12+, BigQuery). Attention toutefois : les performances varient selon le SGBD (risque de matérialisation en tables temporaires sous MySQL ancien). Une leçon simple : une requête bien structurée = des gains de performance majeurs.
L'auteur explique que les bons ingénieurs logiciels fonctionnent en boucle : ils construisent un modèle mental des besoins, écrivent du code, comparent le résultat avec leur modèle, puis ajustent le code ou les exigences. Les LLMs, bien qu’efficaces pour générer ou modifier du code, échouent à maintenir ces modèles mentaux cohérents. Ils se perdent face aux échecs de tests, hallucinent des détails, et peinent à gérer le contexte ou à zoomer entre le global et le local — des capacités essentielles pour résoudre des problèmes complexes. Même avec des avancées, ils restent des outils d’assistance, pas des développeurs autonomes : c’est à l’humain de garantir la justesse des exigences et du code, surtout sur des projets non triviaux. On préfèrera donc miser sur une collaboration humain-agent, mais le développeur reste aux commandes.
Cet article détaille la configuration d’un serveur rsyslog sous Ubuntu 24.04 avec authentification TLS, afin de centraliser et chiffrer les logs en transit sur le réseau. Il explique pourquoi utiliser rsyslog (notamment pour sa compatibilité avec divers équipements et sa simplicité d’intégration), puis présente les étapes clés : génération de certificats (PKI interne ou auto-signés), configuration du serveur avec gtls pour valider les clients via leur certificat (mode x509/name ou empreinte SHA256), et gestion des droits sur les fichiers de certificats. Plusieurs scénarios sont abordés : authentification mutuelle, chiffrement seul, ou utilisation de certificats publics pour l’exposition sur Internet. Des exemples de filtrage des logs (par IP, chaîne de caractères) et de tests de configuration sont aussi fournis, le tout sur le port 6514/TCP. Une ressource utile pour sécuriser la centralisation des logs en respectant les bonnes pratiques (ISO27001, HDS, etc.).
Dans cet article, Milan Milanović partage les cinq livres qui ont marqué sa carrière d’ingénieur et son évolution vers le poste de CTO. Il explique comment "The Pragmatic Programmer" lui a appris à écrire du code professionnel, durable et adaptable, en insistant sur l’importance de l’itération rapide et de la responsabilité collective. "Designing Data-Intensive Applications" a transformé sa vision de l’architecture des systèmes, en mettant l’accent sur les compromis entre cohérence, disponibilité et tolérance au partitionnement, ainsi que sur la rigueur dans le choix des bases de données. "A Philosophy of Software Design" l’a aidé à lutter contre la complexité du code en privilégiant des modules profonds et bien conçus, faciles à maintenir. "Thinking, Fast and Slow" de Daniel Kahneman lui a révélé l’impact des biais cognitifs sur la prise de décision, l’incitant à adopter une approche plus analytique et moins intuitive. Enfin, "The 7 Habits of Highly Effective People" a renforcé ses compétences en leadership, en lui apprenant à se concentrer sur ce qu’il peut contrôler, à écouter activement et à investir dans son développement personnel. Ces ouvrages, au-delà des compétences techniques, lui ont offert des modèles mentaux essentiels pour devenir un meilleur architecte, décideur et leader. Une lecture inspirante pour quiconque souhaite allier expertise technique et croissance personnelle.
Un mémo des actions à faire pour passer de Debian 12 à 13
L'auteur présente 3 techniques pour déclencher un téléchargement de fichier :
- un attribut introduit en HTML5
- la simulation d'un clic en JavaScript, par exemple suite à une action utilisateur
- dans le cas du téléchargement de données générées dynamiquement, les transformer en Blob et utiliser la méthode précédente
Le débat entre monolithe et microservices évolue vers un équilibre pragmatique : la simplicité, l’expérience développeur et la maintenabilité deviennent prioritaires. Les entreprises, après avoir expérimenté les coûts élevés et la complexité des microservices, se tournent de plus en plus vers des architectures modulaires ou des monolithes bien structurés, comme en témoignent des exemples comme Amazon Prime Video, qui a réduit ses coûts de 90 % en revenant à une approche monolithique. La culture du "vibecoding" (optimisation du bien-être et de la productivité des développeurs) favorise aussi les monorepos et les architectures centralisées, tout en intégrant des outils modernes pour garder une flexibilité. L’enjeu n’est plus de choisir un camp, mais d’adapter l’architecture au contexte, en privilégiant la clarté, la résilience et l’alignement d’équipe, avec la possibilité de basculer entre les deux approches selon les besoins. Les outils comme Terraform, les devcontainers ou les CI/CD avancées permettent désormais de repenser les choix architecturaux avec plus d’intention et moins de dogmatisme.