L’article explique comment faire tourner un modèle de langage (LLM) en local sur un GPU AMD, en utilisant la pile logicielle ROCm, le serveur Ollama et l’agent OpenCode. L’auteur détaille les étapes pour configurer ROCm, éviter les pièges courants (comme l’utilisation involontaire de l’iGPU) et optimiser l’utilisation de la VRAM, notamment sur une carte RX 7900 XTX dotée de 24 Go de mémoire.

Le texte aborde aussi les concepts clés comme ROCm (l’alternative open source à CUDA pour AMD), Ollama (qui gère automatiquement le backend GPU) et OpenCode (un agent de codage IA en ligne de commande). Il souligne les défis liés à la gestion du contexte et du KV-cache, ainsi que l’importance de choisir un modèle adapté à la VRAM disponible.

Enfin, l’auteur partage son expérience pratique, en insistant sur la maturité actuelle de ROCm et sa compatibilité avec les dépôts Arch/CachyOS, tout en mettant en garde contre les erreurs fréquentes lors de la configuration. L’objectif est de permettre une utilisation autonome et locale d’un agent de codage IA, sans dépendre de solutions cloud ou propriétaires.

Ce billet de blog résume les actualités technologiques de juin et juillet 2026, avec un focus sur les conférences et la veille. L’auteur y partage ses coups de cœur, notamment des conférences comme Sunny Tech 2026, et aborde des sujets variés : Cloud Native (PostgreSQL sur Kubernetes, projets CNCF), intelligence artificielle locale (LLM légers, context engineering), souveraineté numérique (Proton Lumo, open source), programmation (Rust vs Go, optimisations) et DevOps (self-hosting, bonnes pratiques).

L’article met en avant des retours d’expérience concrets, comme l’utilisation d’un LLM de 35 milliards de paramètres sur une carte graphique ancienne ou la refonte d’un opérateur Kubernetes pour résoudre des problèmes de scalabilité. Il souligne aussi l’importance de la souveraineté numérique et des outils open source dans un paysage technologique en évolution.

Enfin, l’auteur évoque ses projets futurs et son rythme de publication, tout en partageant des ressources utiles pour les développeurs et les passionnés de tech.

Comment réduire votre dépendance en JavaScript grâce à Baseline

L’article explique comment le projet Baseline, porté par le WebDX Community Group, permet d’alléger les applications JavaScript en remplaçant des bibliothèques tierces par des fonctionnalités natives du navigateur. Beaucoup de dépendances courantes (formatage de dates, requêtes HTTP, modales, etc.) sont désormais intégrées aux navigateurs modernes, réduisant ainsi le poids des applications de 60 à 90 Ko (minifié et compressé). L’auteur propose une méthode pour auditer ces dépendances en regroupant les fonctionnalités par niveau de maturité (Limited, Newly available, Widely available), afin d’identifier celles qui peuvent être supprimées sans risque.

Baseline fournit un cadre clair pour évaluer la compatibilité des fonctionnalités via des outils comme webstatus.dev ou MDN, qui indiquent leur statut (nouveau, stable ou en développement). L’article insiste sur l’importance de réévaluer régulièrement ses dépendances, car le web évolue rapidement. Une approche structurée permet de supprimer des bibliothèques obsolètes tout en maintenant la compatibilité avec les anciens navigateurs si nécessaire.

L’élément HTML <dialog> offre une solution native pour créer des fenêtres modales, introduisant une gestion simplifiée de leur ouverture, positionnement et fermeture. Contrairement à show(), la méthode showModal() génère automatiquement un arrière-plan, centre la fenêtre et permet de la fermer avec la touche Échap. La fermeture peut être gérée via JavaScript avec close() ou de manière déclarative en utilisant un formulaire avec method="dialog".

Le balisage de base repose sur un bouton pour déclencher l’ouverture et un élément <dialog> contenant le contenu. Pour une approche sans JavaScript, des attributs expérimentaux comme command et commandfor permettent de lier directement un bouton à une action (ouverture ou fermeture) sur une fenêtre spécifique, simplifiant ainsi l’intégration.

L’article souligne la polyvalence de cet élément, tout en notant certaines subtilités, comme l’absence de closeModal() au profit de close(), et l’évolution des fonctionnalités déclaratives pour réduire le besoin en scripts.

La formation d'une habitude prend en moyenne entre 59 et 66 jours, selon une étude de l'University College London, mais cette durée varie considérablement (de 4 jours à 335 jours). Contrairement à la croyance populaire des 21 jours, issue d'une observation non scientifique, cette fourchette reflète mieux la réalité. L'automaticité d'une habitude suit une courbe asymptotique, où l'effort perçu diminue rapidement au début, mais où la durabilité s'installe plus tardivement.

Trois facteurs influencent davantage la durée que l'effort fourni : la stabilité du contexte et du déclencheur, la complexité de l'action et son placement dans la journée. Une routine nécessite souvent plus de temps que prévu pour devenir naturelle, surtout dans un environnement chargé.

L'étude de référence, bien que souvent citée, présente des limites : ses participants étaient jeunes et en bonne santé, et les résultats extrapolés au-delà de la période d'observation. Ainsi, une estimation réaliste se situe entre deux et cinq mois pour la plupart des comportements liés à la santé.

La page explique pourquoi bloquer les publicités en ligne est essentiel, soulignant que ce modèle économique repose sur une collecte intrusive et souvent illégale de données personnelles. Les géants du web comme Google et Facebook tirent l’essentiel de leurs revenus de la publicité ciblée, nécessitant un espionnage massif des habitudes des utilisateurs via des traqueurs et des algorithmes. Ces pratiques, fréquemment en violation du RGPD, alourdissent les pages web, dégradent l’expérience de navigation et menacent la vie privée.

Elle met en lumière les méthodes trompeuses utilisées pour obtenir le consentement des utilisateurs, comme les dark patterns, et l’impact environnemental de ces technologies, gourmandes en énergie. La comparaison visuelle entre une page avec et sans bloqueur illustre concrètement l’ampleur du problème, réduisant à la fois la performance et l’accessibilité des sites.

Enfin, la page encourage à agir contre ce fléau en adoptant des bloqueurs de publicités, tout en abordant des cas spécifiques comme YouTube. Elle rappelle que la publicité en ligne, loin d’être neutre, participe à une dégradation globale du web, tant technique qu’éthique.

L’article explique pourquoi les IA comme Claude génèrent du code standard, souvent éloigné des conventions spécifiques d’une équipe, et propose une solution via les rules. Sans instructions précises, l’IA se base sur des pratiques moyennes en ligne, ce qui peut entraîner des incohérences dans une base de code. Les rules permettent d’intégrer les bonnes pratiques internes sous forme d’instructions claires, comme des conventions de nommage ou des principes architecturaux, afin d’harmoniser le code produit.

Les rules sont des directives écrites au format DO/DON’T, intégrées à la session de l’IA pour guider ses choix. Elles couvrent des aspects variés, des unités de mesure aux bonnes pratiques comme le debounce pour optimiser les performances. Ces règles, une fois formalisées, réduisent les corrections répétitives en revues de code et facilitent la transmission des savoir-faire techniques au sein de l’équipe.

L’ajout excessif de contexte dans les instructions ou spécifications pour les agents de codage peut nuire à leur performance plutôt que de l’améliorer. Au-delà d’un certain seuil, ces agents deviennent confus, mélangent des détails de différents documents et génèrent des réponses erronées, notamment lorsque les spécifications deviennent trop détaillées ou obsolètes. Par exemple, des fichiers de spécifications trop techniques ou volumineux, initialement conçus pour décrire des comportements, finissent par inclure des détails d’implémentation qui induisent en erreur l’agent.

La question centrale soulevée est celle de la source de vérité dans le développement logiciel assisté par IA. Ni les tests, ni le code, ni les spécifications ne suffisent à eux seuls à garantir une compréhension fiable, car chacun reflète une réalité différente : les tests valident le comportement actuel, le code représente l’implémentation réelle (y compris ses défauts), et les spécifications, si elles ne sont pas maintenues, deviennent rapidement obsolètes. Sans une source de vérité claire et à jour, les équipes et les agents se retrouvent à deviner les intentions initiales, ce qui conduit à des incohérences.

Pour résoudre ce problème, une distinction utile consiste à séparer deux types de vérité : d’une part, la vérité exécutable (le code et les tests), qui reflète l’état actuel du logiciel, et d’autre part, la vérité intentionnelle (les objectifs, les contraintes architecturales et les attentes fonctionnelles), qui guide les évolutions futures. Cette séparation permet d’éviter que les agents ne s’appuient sur des informations contradictoires ou obsolètes, et clarifie le rôle de chaque élément dans le processus de développement.

Ce guide s’adresse aux gestionnaires de produits et de projets non techniques (Product Owners, Chefs de Projet, Business Analysts) qui se sentent intimidés par la gestion de projets data, souvent perçue comme réservée aux experts techniques. L’auteure, initialement confrontée à des exigences techniques disproportionnées, y partage son expérience pour montrer qu’un bon PO Data n’a pas besoin de maîtriser le code ou l’architecture des données, mais doit avant tout savoir poser les bonnes questions, cadrer les besoins métiers et faciliter la collaboration entre équipes techniques et métiers.

L’article souligne que la valeur d’un PO Data réside dans sa capacité à recentrer les discussions sur l’essentiel, à prioriser les fonctionnalités impactantes et à construire un pont entre les attentes business et les contraintes techniques. Il déconstruit l’idée reçue selon laquelle il faudrait être expert en Python, SQL ou machine learning pour piloter un projet data, insistant sur l’importance de la vision produit et de la gestion de la valeur plutôt que sur les compétences purement techniques.

Enfin, le texte propose des repères concrets pour aborder sereinement ces projets, en s’appuyant sur des retours d’expérience et une approche pragmatique. L’objectif est de donner confiance aux profils non techniques en leur rappelant que leur rôle est complémentaire à celui des experts techniques, et que leur légitimité repose sur leur capacité à incarner les besoins utilisateurs et à maximiser l’impact des solutions développées.

La QA (Quality Assurance) désigne à la fois un métier dédié et une discipline outillée visant à prévenir les erreurs logicielles avant leur mise en production. Contrairement à une idée reçue, elle ne garantit pas l’absence totale de bugs, mais permet d’interdire des classes d’erreurs spécifiques, comme l’illustre le principe du typage strict ou des tests de non-régression. L’article compare cette approche à un filet de sécurité composé de plusieurs couches d’outils, chacun bloquant une catégorie de problèmes.

L’auteur illustre l’importance de la QA à travers quatre pannes majeures, dont celle de CrowdStrike en 2024, où un fichier mal validé a provoqué des écrans bleus sur des millions de machines. Ces exemples révèlent des garde-fous manquants, comme une validation insuffisante des données ou des déploiements non progressifs, soulignant que la QA doit s’appliquer autant au code qu’aux configurations.

Enfin, l’article annonce une série dédiée aux outils concrets de QA, en détaillant leur rôle dans la prévention des erreurs. L’objectif est de montrer comment construire un système de défense en couches, adapté même aux petites équipes, pour limiter les risques avant qu’ils n’atteignent les utilisateurs.

La propriété CSS scrollbar-gutter: stable est présentée comme une solution pour éviter les décalages de mise en page causés par l'apparition ou la disparition des barres de défilement. Elle permet de réserver un espace fixe pour ces barres, garantissant ainsi une largeur de page constante. Cette approche remplace les méthodes anciennes et peu élégantes comme overflow-y: scroll.

Cependant, l'auteur découvre un comportement inattendu sur macOS : lorsque l'utilisateur débranche sa souris, le système passe en mode overlay scrollbars, dessinant les barres par-dessus le contenu sans réserver d'espace. Résultat, la mise en page s'élargit soudainement de 15 pixels, malgré l'application de scrollbar-gutter: stable. Ce phénomène est observable dans Safari, Chrome et Firefox, suggérant une conformité à la spécification macOS plutôt qu'un bug des navigateurs.

Le problème réside dans l'interprétation trompeuse du terme stable. La propriété ne garantit une stabilité que si le système utilise des barres de défilement classiques. Dès qu'il bascule en mode overlay (par exemple, en débranchant une souris), l'espace réservé disparaît, invalidant l'effet recherché. La spécification précise que scrollbar-gutter: stable ne fonctionne que lorsque des barres classiques existent, ce qui n'est pas toujours le cas.

Ce billet de blog d’Evil Martians explique comment sécuriser la publication d’un package npm en 2026, face à la menace croissante des attaques par chaîne d’approvisionnement. L’auteur souligne l’importance de mesures comme les Trusted Publishers sur npmjs.com, la désactivation des tokens de publication et l’activation de la 2FA sur GitHub pour limiter les risques de vol de credentials. Ces pratiques améliorent aussi la visibilité et la crédibilité du projet.

L’article détaille des solutions techniques concrètes, comme l’utilisation de zizmor pour auditer les workflows CI, le pinning des actions GitHub par commit SHA, et la configuration d’un délai de 3 jours avant une nouvelle publication. Ces étapes visent à réduire les vulnérabilités tout en optimisant la maintenance des projets open source.

Enfin, il recommande de migrer vers des versions récentes de npm, pnpm, Yarn ou Bun pour éviter l’exécution automatique des scripts postinstall des dépendances, renforçant ainsi la sécurité globale. Ces bonnes pratiques s’inscrivent dans une tendance où la sécurité devient un critère différenciant pour les développeurs et les entreprises.

L’auteur partage son expérience d’achat d’un ebook hors plateformes comme Amazon, en optant pour un format sans DRM. Il décrit son parcours depuis l’utilisation d’une liseuse Kindle, jugée pratique mais dépendante d’Amazon, jusqu’à l’achat d’un livre via Les Libraires, un site proposant des ebooks sans restrictions. Il souligne l’importance de la synchronisation entre appareils pour suivre sa lecture, mais critique les solutions d’auto-hébergement complexes, comme celles reposant sur des bases de données lourdes (PostgreSQL), préférant des outils plus légers.

Il présente ensuite Kavita, une solution d’auto-hébergement utilisant SQLite, mais trouve son interface superflue pour un usage simple. Finalement, il se tourne vers Koreader, un lecteur ebook open source, et son intégration avec WebDav pour une synchronisation fluide et légère. L’auteur défend l’élégance de la simplicité, critiquant les solutions surchargées et prônant une approche minimaliste pour gérer sa bibliothèque numérique.

Le Manifeste Offpunk propose une réflexion sur la déconnexion volontaire face à l’hyperconnexion généralisée, où le numérique est devenu un environnement omniprésent, voire une prison. L’auteur souligne l’émergence d’un mouvement prônant le retour à des outils non connectés (dumb phones, appareils photo analogiques, presse papier) pour échapper à cette dépendance, illustrée par des exemples comme la résurgence des cassettes ou des machines à écrire. L’idée centrale est que la résistance ne passe pas par une rébellion technologique, mais par un rejet pur et simple de l’omniprésence du numérique.

Le texte met en lumière les risques géopolitiques de cette centralisation, où l’accès à Internet devient une arme de guerre, comme le montrent les coupures imposées par la Russie en Ukraine ou les sanctions américaines ciblant des magistrats internationaux. Cette fragilité expose les individus à des exclusions arbitraires, soulignant l’urgence de préserver des alternatives non numériques pour garantir une autonomie sociale et politique.

Enfin, le manifeste s’inscrit dans une critique plus large de la dépendance aux infrastructures propriétaires, illustrée par des pannes majeures (comme le bug Microsoft de 2024) qui paralysent des secteurs entiers. L’Offpunk, incarné par ceux qui rejettent les smartphones, incarne une forme de résistance passive mais radicale, défendant la liberté de se soustraire à un système perçu comme oppressif.

Ce billet relate la migration vers Pest 5 d’une suite de tests Symfony, révélant les failles cachées derrière une apparence de succès (suite "verte"). L’auteur découvre que des outils comme PHPStan ou Rector n’étaient pas correctement configurés, des fichiers de test exclus des analyses, et des attributs PHPUnit obsolètes ignorés. La migration a aussi mis en lumière des problèmes de dépendances entre tests, des violations d’accessibilité détectées par un vrai navigateur, et un ralentissement important causé par Xdebug activé dans le container de développement.

L’enquête montre que la fiabilité d’une suite de tests dépend fortement de son environnement d’exécution et de sa configuration, bien au-delà du simple passage des tests. Les outils modernes comme Pest 5 peuvent exposer des incohérences passées inaperçues, même dans des projets matures. L’auteur souligne l’importance de réévaluer régulièrement son infrastructure de test pour éviter les faux positifs.

Enfin, la migration a permis d’optimiser la suite en identifiant des goulots d’étranglement, comme des tests trop lents ou des dépendances mal gérées, améliorant ainsi la qualité globale du projet.

L’article critique l’opposition systématique entre écologie et souveraineté numérique, en comparant cette tendance à l’erreur stratégique passée de la sortie du nucléaire en Europe. L’auteur souligne que refuser les datacenters en France, par exemple, ne réduit pas la demande globale en calcul, mais déplace simplement cette consommation vers des régions où l’énergie est plus carbonée et moins régulée, aggravant ainsi l’impact écologique.

Bien que la croissance du numérique pose des défis environnementaux majeurs, avec une empreinte carbone en hausse (passée de 2,5 % à 4,4 % en France), l’auteur nuance son propos en rappelant les bénéfices potentiels de l’IA et du numérique pour optimiser les énergies renouvelables, la médecine ou la logistique. Il met en garde contre une opposition simpliste qui ignorerait ces avantages, tout en reconnaissant les risques liés à l’industrie des datacenters, comme la dépendance aux énergies fossiles ou l’épuisement des ressources minières.

L’auteur plaide pour une approche équilibrée, combinant sobriété numérique et maîtrise des infrastructures critiques, afin d’éviter de reproduire les erreurs du passé et de préserver à la fois la transition écologique et la souveraineté technologique.

L’article explore comment des choix de design bien intentionnés peuvent, malgré leur sophistication, complexifier l’expérience utilisateur (UX) en accumulant une charge cognitive invisible. Malgré des interfaces modernes et des micro-interactions soignées, les utilisateurs peinent parfois à naviguer ou accomplir leurs tâches, en raison d’une complexité croissante qui ralentit la prise de décision et génère de la frustration.

L’auteur souligne que l’esthétique d’une interface ne garantit pas une expérience fluide, car les améliorations visuelles (boutons, animations, couleurs) se concentrent sur la couche superficielle, masquant des processus sous-jacents souvent confus. Les utilisateurs privilégient avant tout l’efficacité pour atteindre leurs objectifs, sans se soucier de l’élégance des composants.

Enfin, l’excès d’options de personnalisation, bien que perçu comme un avantage, alourdit la charge mentale. Chaque choix supplémentaire impose un effort cognitif accru (comprendre, comparer, prédire), illustrant le Paradoxe du choix de Barry Schwartz. Des fonctionnalités comme le téléchargement de fichiers, enrichies de multiples options (cloud, partage, historique), en sont un exemple concret, transformant une tâche simple en parcours complexe.

L’article aborde le piège de la vitesse dans le développement logiciel, où l’utilisation d’outils comme les IA et les agents accélère la production de code, mais risque de compromettre la qualité architecturale. L’auteur met en garde contre la confiance aveugle dans les solutions générées, qui peuvent mener à des bases de code fragiles et difficiles à maintenir.

Il souligne que la valeur d’un développeur ne réside plus dans sa capacité à coder rapidement, mais dans son jugement d’architecte, capable d’évaluer la pérennité des solutions. Pour éviter les erreurs, il propose des méthodes comme le "test des six mois" ou la rédaction préalable de documentation pour valider la solidité des choix techniques.

Enfin, l’auteur rappelle que la vitesse n’a de sens que si elle s’accompagne d’une réflexion approfondie, sous peine de créer des dettes techniques coûteuses à long terme.

L’article explique comment concevoir des gestionnaires de messages idempotents dans Symfony Messenger pour éviter les effets indésirables lors de la réception de messages en double, notamment dans des environnements distribués comme Kubernetes avec des files SQS. L’idée centrale repose sur la création d’effets métiers "effectivement uniques" malgré des livraisons multiples, en s’appuyant sur des identifiants stables (comme eventId), des contraintes d’unicité dans la base de données et des mécanismes de déduplication. L’auteur souligne que la fiabilité ne peut être garantie par les simples configurations de tentatives de renvoi, mais nécessite une approche systémique intégrant la gestion des clés d’idempotence et des transactions atomiques.

L’analyse détaille les risques liés à l’absence de transaction atomique entre la validation en base de données et la suppression du message de la file, illustrant comment un crash peut entraîner des doublons ou des pertes. Pour y remédier, il propose des solutions comme l’utilisation de contraintes uniques PostgreSQL, de tables de déduplication ou du Outbox Pattern pour sécuriser la production des messages. Ces méthodes permettent de garantir que, même en cas de livraisons multiples, l’effet métier ne se produit qu’une seule fois, tout en reconnaissant que cette approche ne couvre pas les systèmes externes (API, paiements, etc.), qui nécessitent leurs propres mécanismes d’idempotence.

L’article propose une solution pour gérer les transactions en couche applicative dans une architecture hexagonale, sans dépendre de l’infrastructure comme Doctrine. L’idée centrale est d’introduire un port TransactionManagerInterface dans l’application, implémenté par un adaptateur Doctrine qui utilise wrapInTransaction() pour encapsuler les opérations dans une transaction unique. Cela permet d’éviter les problèmes de cohérence, comme des modifications partielles en cas d’échec, en regroupant plusieurs opérations (persistance, mise à jour) dans un bloc atomique.

L’auteur illustre le problème avec un cas concret : la création d’une commande et la mise à jour simultanée des stocks. Sans gestion centralisée, chaque appel à flush() (via add() ou update()) crée une transaction implicite, risquant des incohérences si une étape échoue. La solution repose sur un service applicatif (OrderService) qui dépend uniquement des interfaces de domaine et du TransactionManagerInterface, isolant ainsi la logique métier des détails d’infrastructure.

Enfin, l’implémentation montre comment le TransactionManager utilise les mécanismes natifs de Doctrine pour gérer les transactions de manière robuste, y compris les erreurs PHP, tout en maintenant une séparation claire des responsabilités. Les méthodes add() et update() des repositories doivent éviter d’appeler flush() directement pour préserver l’intégrité transactionnelle.