Sur Geekeries.org, une optimisation de WordPress menée à partir des requêtes réellement effectuées par le navigateur, plutôt que par l’ajout de plugins, améliore sensiblement les performances. Après vérification des caches Redis et HTTPS, l’auteur corrige le décalage du logo, adapte les images en WebP, retire Bootstrap inutilisé et remplace quatre icônes Font Awesome par des SVG. Les modifications sont testées une par une et conservées dans un thème enfant. Le score PageSpeed passe de 72 à 93 sur mobile et de 73 à 100 sur ordinateur, avec un CLS nul.

Dans son application de rétrospectives d’équipe développée avec l’aide de l’IA, Jérémy Decool mise sur des contrôles déterministes pour sécuriser le code généré. Sa batterie combine linters, analyse statique PHPStan, tests PHPUnit unitaires, fonctionnels et d’intégration, tests de mutation Infection et vérifications d’architecture. Des scripts contrôlent aussi les dépendances, la documentation, les traductions, les contrastes et le changelog. Tous ces contrôles passent en intégration continue, avec suivi de la couverture et du score de mutation. Le code de test dépasse en volume le code de production.

La documentation produite par IA peut paraître impeccable tout en étant inutilisable : commandes non expliquées, décisions absentes et procédures impossibles à vérifier. L’article propose une méthode de contrôle dans la CI : imposer quatre sections (objectif, synthèse accessible, commandes commentées et vérification), ajouter une checklist aux pull requests et combiner Vale pour la lisibilité avec un script Bash pour la structure. Un workflow GitHub Actions bloque les documents non conformes. La vérification humaine des procédures reste indispensable, et les scripts fournis doivent être adaptés avant production.

Après près de deux mois d’utilisation de LeanCTX avec Codex sur un serveur, l’auteur mesure environ 11,7 millions de tokens nets évités et 34,5 % de compression sur les sorties traitées, sans prétendre à une réduction équivalente de la facture globale. L’outil filtre les logs, structure les lectures et évite les relectures redondantes, tout en permettant l’accès aux données brutes. L’article examine aussi le coût des outils MCP, les alternatives RTK et TOON, ainsi que les précautions de sécurité : cache local, restriction des chemins, télémétrie et proxy désactivés.

Kevin Wenger recommande de remplacer les accès ambigus à $request->get() par une lecture explicite des paramètres de route (attributes), de l’URL (query) et du corps (request). Dépréciée dans Symfony 7.4, cette méthode disparaît en Symfony 8. Les accesseurs typés (getString(), getInt(), getBoolean(), getEnum()) évitent les conversions silencieuses et rejettent les valeurs invalides. Avec PHP 8.4, Symfony 7.4 prend aussi en charge l’analyse des corps de formulaires envoyés en PUT, PATCH ou DELETE, y compris les fichiers.

Réutiliser une sauvegarde de production dans un environnement Symfony de préproduction expose des données personnelles à des contrôles souvent moins stricts. L’auteur propose une chaîne automatisée : restaurer la base dans un espace isolé, masquer les champs sensibles avec Doctrine DBAL et des substitutions déterministes, vérifier l’absence de données résiduelles, puis seulement publier la copie. Les relations entre enregistrements restent exploitables pour reproduire les bugs. Cette méthode produit toutefois des données pseudonymisées, non anonymes : accès, conservation et finalité restent soumis au RGPD. Pour le développement courant, privilégier des données synthétiques.

Esther Weidauer défend un refus de l’IA générative, qu’elle distingue des autres usages de l’apprentissage automatique. Elle conteste les arguments de son utilité et de sa prétendue neutralité, en soulignant la dépendance à des infrastructures et à du travail souvent invisibles. Elle pointe ses coûts énergétiques et économiques, les risques de dépendance cognitive et de désinformation, ainsi que la concentration du pouvoir sur l’accès au savoir. Sa critique s’étend aux biais politiques et à la culture des entreprises du secteur.

Dans ce deuxième volet consacré à son application de rétrospectives, Jérémy Decool décrit le « harness » qui encadre le travail des agents de développement utilisant Claude Code. Il s’appuie sur des règles ciblées, des décisions d’architecture, un glossaire et des fichiers AGENTS.md propres à chaque contexte. Pour éviter de saturer la fenêtre de contexte, les instructions sont chargées de façon conditionnelle et auditées par une compétence dédiée ainsi que des tests. L’auteur souligne toutefois que ces consignes restent non déterministes et doivent être complétées par des contrôles automatisés.

Jérémy Decool détaille l’architecture de Team Retrospective, une application de rétrospectives d’équipe développée avec PHP, Symfony et Symfony UX. Le projet est organisé en dix contextes métier selon les principes du DDD et de la Clean Architecture, avec des bus de commandes, requêtes et événements, du temps réel via Mercure et une infrastructure conteneurisée. Une documentation structurée encadre également le développement. L’auteur souligne que les agents IA produisent l’essentiel du code, tandis qu’il reste responsable de la conception architecturale.

En JavaScript, String.prototype.replace() avec une expression régulière globale et une fonction de rappel peut servir à parcourir les correspondances sans utiliser la chaîne produite. Cette technique permet de filtrer, extraire des données et même alimenter un analyseur lexical ; renvoyer une chaîne vide limite la mémoire gaspillée. Des benchmarks montrent toutefois que, sur V8, elle est généralement plus lente que exec() et se dégrade sur les gros textes. Pour du code neuf, l’auteur privilégie matchAll(), plus lisible et réellement itératif.

Avec Proxy, JavaScript peut intercepter la lecture, l’écriture ou l’énumération des propriétés d’un objet, au point de rendre son comportement trompeur : une méthode reste appelable alors qu’elle n’apparaît ni dans console.log, ni dans Object.keys ou Reflect.ownKeys. Bryan Gillespie illustre aussi une affectation qui semble réussir mais est aussitôt neutralisée. Ce mécanisme lui sert à dissimuler des fonctionnalités dans son jeu Pragma Twice. L’article rappelle enfin des usages légitimes des proxies, notamment la réactivité de Vue et la journalisation.

Pour documenter un processus métier de façon réellement réutilisable, l’auteur recommande de remplir une fiche pendant l’exécution d’un cas réel plutôt que de reconstituer les étapes de mémoire. Son modèle comporte huit rubriques : nom et déclencheur, responsable, prérequis, étapes avec durées et attentes, règles de décision, exceptions et solutions, résultat attendu et date de révision. Les décisions implicites et les imprévus constituent l’information la plus précieuse pour transmettre une tâche. Il conseille de commencer par une activité récurrente, puis de réviser la fiche après trois exécutions ou 90 jours.

Depuis plus de dix ans, GNOME empêche la mise en veille d’un ordinateur portable à la fermeture du capot lorsqu’un écran externe est connecté, sans proposer d’option pour changer ce comportement. L’auteur retrace les interactions entre gsd-power, UPower et systemd-logind, ainsi que la disparition successive des contournements après GNOME 50. Il propose flozz-lid-closed-suspend, un petit service Python déclenchant la veille malgré l’écran externe, installable via un script. En parallèle, il tente d’obtenir un correctif durable directement dans GNOME.

Face aux failles PHP2shell (CVE-2026-109618 et CVE-2026-109619), l’auteur détaille la mise à jour sécurisée de PHP-FPM dans une stack Docker. Il conseille de vérifier la disponibilité réelle de l’image corrigée et son digest avec Buildx, plutôt que de se fier au tag. En attendant l’image officielle, il a placé le site en maintenance et compilé provisoirement PHP corrigé. Le retour à l’image officielle passe par la sauvegarde, la conservation des extensions, les contrôles de version et de modules, puis des tests avant réouverture, avec possibilité de retour arrière.

Pour mener à terme un projet d’apprentissage court, Scott H. Young recommande trois étapes : cartographier la compétence à acquérir et les ressources disponibles, choisir un périmètre réaliste en décidant aussi de ce qu’on laissera de côté, puis établir un planning compatible avec son temps et son énergie habituels. Ses expériences en dessin, en langues et en mécanique quantique montrent l’importance des bonnes méthodes, des prérequis et d’objectifs ajustés. Progresser rapidement jusqu’à un niveau « suffisant » peut être plus utile que viser systématiquement la maîtrise.

En appliquant le principe de Peter au développement assisté par IA, Baldur Bjarnason estime que les développeurs sont devenus, sans formation, des gestionnaires d’agents imprévisibles. Au lieu de programmer, ils doivent coordonner, surveiller et corriger des processus difficiles à maîtriser. Cela favoriserait le travail inutile, les retards et le stress, sans garantir davantage de valeur. L’auteur souligne aussi le paradoxe de l’automatisation : moins on pratique le code, plus les compétences et les modèles mentaux nécessaires pour contrôler la qualité risquent de s’éroder.

À partir d’un témoignage publié sur Reddit, Matoo rassemble des réactions de développeurs face à la généralisation des agents de codage comme Claude. Certains décrivent une perte de sens, de plaisir et de maîtrise technique : ils ne codent presque plus et se limitent à superviser l’IA. D’autres y voient une libération des tâches répétitives, permettant de se concentrer sur la conception, l’architecture et les besoins utilisateurs. Ces échanges soulignent les différences de rapport au métier, ainsi que les inquiétudes sur la qualité du code, la dépendance aux fournisseurs et l’avenir professionnel.

À partir du concept de « merdification » popularisé par Cory Doctorow, l’auteur décrit la dégradation progressive des plateformes et services après avoir rendu leurs utilisateurs dépendants : publicité accrue, abonnements, restrictions et perte de contrôle. Il étend cette critique aux réseaux sociaux, aux logiciels, aux objets connectés et à l’IA, accusée d’appauvrir le Web et d’accentuer la captation des usages. Pour reprendre la main, il recommande de réduire les services superflus, de privilégier les alternatives libres et l’auto-hébergement, et de soutenir des modèles numériques plus durables.

xtool est un outil open source visant à remplacer une partie des fonctions de Xcode pour développer des applications iOS depuis Linux, Windows (via WSL) ou macOS. À partir de projets Swift Package Manager (SwiftPM), il permet de construire une application, de la signer et de l’installer sur un appareil iOS. Son interface en ligne de commande inclut la création de projets, la gestion des appareils et l’authentification aux services Apple Developer. Le projet fournit également la bibliothèque XKit pour intégrer ces fonctions dans d’autres applications.

Olivier Dossmann explique comment enrichir les liseuses Xteink compatibles avec le firmware alternatif CrossPoint grâce aux « SD plugins », sans recompiler le pilote. Après installation d’une version Nightly et du Plugin Store sur carte SD, le module WebDAV permet d’accéder en Wi-Fi à des livres hébergés sur Nextcloud, OpenCloud ou un autre serveur compatible. L’auteur décrit la configuration et les limites rencontrées, notamment les erreurs au-delà de 100 fichiers et l’affichage des noms. Il présente aussi le plugin wallabag pour lire des articles sauvegardés.