Ce billet explique comment moderniser un firewall iptables vieillissant sans perturber Docker, en prenant l’exemple d’un serveur exposé directement sur Internet. L’auteur souligne que les règles doivent refléter le chemin réel des paquets, qui a évolué depuis 2017, notamment avec l’intégration de Docker. Il revient sur quatre articles précédents pour montrer comment Fail2ban, SYNPROXY, ipset et CrowdSec ont été adaptés, tout en corrigeant des pratiques obsolètes comme le filtrage sur eth0 ou l’absence de gestion des connexions Docker.

L’article détaille les pièges rencontrés, comme l’impact de conntrack et SYNPROXY sur les connexions SSH, ou la nécessité de réviser les règles pour éviter de bloquer l’accès aux ports 22, 80 et 443. L’auteur insiste sur l’importance de maintenir des outils comme Fail2ban, CrowdSec et AbuseIPDB de manière complémentaire, plutôt que redondante, et partage des bonnes pratiques pour sécuriser le serveur dans un environnement "à peine agressif".

Enfin, le texte propose une mise à jour des règles iptables pour 2026, en intégrant les évolutions récentes comme la gestion des ipset, la rotation des clés API et une meilleure validation des données externes. L’objectif est de concilier sécurité renforcée et compatibilité avec Docker, tout en évitant les erreurs d’architecture qui pourraient rendre le serveur inaccessible.

Parkinson’s Law, théorisé en 1955 par le historien britannique Cyril Northcote Parkinson, stipule que "le travail s’étend pour remplir le temps disponible pour son accomplissement". Cette observation, initialement une satire sur l’inefficacité bureaucratique, révèle un phénomène universel : plus une tâche dispose de temps, plus elle tend à occuper cet espace, souvent avec des ajustements superflus ou une procrastination déguisée en perfectionnisme.

L’auteur illustre ce principe par des exemples concrets, comme un courriel prenant une journée entière ou un projet de deux semaines réalisé en trois jours si le délai est serré. Cette expansion du travail s’explique par l’absence de pression initiale, qui encourage la lenteur, les micro-décisions et l’anxiété de dernière minute, transformant une tâche simple en un processus chronophage et souvent moins efficace.

À l’inverse, des contraintes temporelles strictes forcent une concentration accrue, éliminant les excès de perfectionnisme et accélérant la prise de décision. Le résultat est souvent une exécution plus directe et parfois même de meilleure qualité, car le manque de temps réduit les distractions inutiles.

Cette page propose neuf méthodes pour optimiser l’apprentissage grâce à l’IA, en s’appuyant sur des principes pédagogiques éprouvés comme la récupération active, l’espacement et la pratique exigeante. L’idée centrale est d’utiliser l’IA comme un coach plutôt que comme une simple machine à réponses, en évitant de déléguer entièrement le travail cognitif à l’outil. Par exemple, transformer l’IA en tuteur socratique, qui pose des questions et guide l’utilisateur vers la compréhension plutôt que de fournir des solutions toutes faites, maximise la rétention des connaissances.

L’article insiste sur une règle fondamentale : l’IA doit assister l’effort d’apprentissage sans le remplacer, car c’est l’effort personnel qui renforce la mémoire. Les techniques proposées, comme la création de flashcards automatisées suivies de révisions espacées, illustrent cette approche en combinant gain de temps et efficacité pédagogique. L’accent est mis sur l’interaction active avec le contenu, plutôt que sur la consommation passive d’informations.

Enfin, le texte met en garde contre les limites de l’IA, notamment ses erreurs potentielles, et recommande de croiser ses réponses avec d’autres sources pour éviter les biais. Destiné aux apprenants de tous niveaux, l’article encourage à appliquer ces méthodes immédiatement sur un sujet précis, en adaptant les prompts fournis pour une utilisation concrète.

L’auteur critique l’usage des chatbots, qu’il compare à une forme d’onanisme intellectuel ou de Guitar Hero créatif : amusant mais stérile, car il ne développe aucune compétence réelle. Il souligne que les utilisateurs, même en ayant la réponse sous les yeux, échouent à la restituer, illustrant l’absence d’apprentissage. L’analogie avec un plaisir solitaire et peu partageable renforce son rejet de cette pratique, qu’il juge à la fois inefficace et dénuée de valeur ajoutée.

Ploum admet avoir lui-même cédé à la tentation, en testant un chatbot pour générer des images, mais souligne l’absurdité de l’exercice : l’outil produit des résultats superficiels, comme une musculature exagérée imposée à un personnage, révélant ses biais. Il insiste sur le paradoxe où l’IA, présentée comme un gain de temps, exige en réalité un investissement disproportionné pour un résultat médiocre, à l’image d’un jardinier trop coûteux pour une petite pelouse.

Enfin, il généralise cette critique aux dynamiques managériales ou parentales, où déléguer une tâche simple à un "expert" (humain ou machine) s’avère contre-productif. Son ton mêle ironie et sérieux, dénonçant une mode technologique qui sacrifie l’effort personnel au profit d’une illusion de facilité, sans réel bénéfice durable.

L’article explique comment implémenter le pattern Unit of Work dans Symfony pour centraliser la gestion des opérations (création, mise à jour, suppression) sur différentes sources de données, y compris des services externes comme des API REST ou des files de messages. L’idée est de regrouper ces opérations dans une seule transaction logique, garantissant cohérence, clarté et testabilité, à l’image d’un panier d’achat où les modifications sont validées en une seule fois.

L’auteur propose une architecture en quatre composants : un objet Change pour représenter une opération, un service UnitOfWork pour collecter les changements, des Committer (interfaces) pour gérer l’écriture des données selon le backend, et des Repository modifiés pour enregistrer les changements au lieu de les exécuter immédiatement. Chaque Committer est spécialisé pour un type d’entité et un système de stockage.

L’implémentation repose sur une séparation claire des responsabilités, où le UnitOfWork agit comme un coordinateur central. Les changements sont regroupés par type d’entité avant d’être transmis aux Committer correspondants, permettant une intégration flexible avec Doctrine, des API ou d’autres services.