Ce journal de Jérôme Flesch explore les défis techniques et les limites de l’auto-hébergement de grands modèles de langage (LLM) sur du matériel grand public, notamment face aux contraintes de CPU et RAM. L’auteur remet en cause les affirmations simplistes selon lesquelles des cartes graphiques modestes (comme une Nvidia GTX 1060 de 6 Go) suffiraient pour faire tourner des LLM efficacement, soulignant que ces démonstrations se limitent souvent à des tests basiques sans contexte réel. Il aborde aussi les modèles Mixture-of-Experts (MoE), censés optimiser les ressources, mais dont les gains dépendent fortement du matériel et des paramètres utilisés.

L’article détaille une méthodologie de tests comparatifs sur plusieurs GPU (Nvidia RTX 3060, AMD RX 9070 XT, Intel Arc Pro B60), analysant les performances en prédiction de tokens et en préremplissage selon la taille du contexte. Les résultats montrent des dégradations significatives des vitesses d’inférence dès que la mémoire vive est saturée, même avec des techniques comme le swap ou des optimisations logicielles. L’auteur souligne que les benchmarks superficiels, souvent partagés par des influenceurs, ignorent ces réalités matérielles, donnant une fausse impression de faisabilité.

En conclusion, Flesch conclut que l’auto-hébergement de LLM reste complexe et coûteux en ressources, surtout pour des usages intensifs. Il critique les solutions marketing qui minimisent ces contraintes, rappelant que les développeurs privilégient des GPU haut de gamme pour des raisons de performance et de stabilité. Le journal se veut un plaidoyer pour une approche pragmatique, loin des promesses exagérées circulant sur les réseaux.

Léa Verou défend l'usage d'un interrupteur à deux états pour basculer entre les modes clair et sombre, plutôt qu'un système à trois options (clair, sombre, système). Elle argue que la plupart des utilisateurs n'ont pas besoin de cette troisième option, qui complique l'interface sans réel bénéfice, car leur objectif principal n'est pas de configurer le thème mais d'utiliser le site. Un interrupteur simple permet de répondre aux besoins réels des utilisateurs tout en évitant une surcharge cognitive.

L'auteure explique que les interrupteurs à trois états sont souvent motivés par la structure technique sous-jacente plutôt que par les besoins utilisateurs. Bien que le modèle de données puisse nécessiter trois états, seul l'un d'eux est pertinent à un moment donné. Elle illustre ce point en comparant avec un robinet mélangeur, où l'interface simplifiée correspond mieux à l'objectif de l'utilisateur que la complexité technique sous-jacente.

Enfin, Verou souligne que les interrupteurs à deux états sont plus intuitifs et évitent de confronter l'utilisateur à des choix sans différence visible, ce qui va à l'encontre du principe de feedback en UX. Elle reconnaît que des exceptions existent, notamment dans les paramètres dédiés où trois états peuvent être justifiés, mais pour la majorité des cas, une solution plus simple et efficace est préférable.

La page explique que la récupération du burnout ne se mesure pas en semaines de repos, mais en phases distinctes correspondant au retour des capacités perdues. L’auteur distingue quatre étapes : d’abord l’arrêt des efforts inutiles, puis le retour de l’énergie, suivi plus tard de l’attention et enfin de l’engagement, qui ne revient qu’en cas de changement réel des conditions de travail.

Elle souligne que le repos seul ne suffit pas, car les trois dimensions du burnout (épuisement, cynisme et baisse d’efficacité) ne se résolvent pas à la même vitesse. Les études citées montrent que les effets bénéfiques d’une pause s’estompent rapidement après le retour au travail, même après des congés prolongés.

Pour avancer, l’article propose d’identifier sa phase actuelle et d’agir en conséquence, plutôt que de compter sur une solution temporaire. La clé réside dans une approche progressive, adaptée à l’évolution réelle des capacités, plutôt que dans une attente passive de guérison.

L’article de LifeDev explique comment refuser poliment une demande pour mieux protéger son temps, en présentant cette compétence comme un outil de productivité plutôt qu’une question de personnalité. Il souligne que chaque "oui" engage des heures irremplaçables et que savoir dire "non" permet d’éviter l’épuisement, d’améliorer les relations et de se concentrer sur ses priorités. La peur de nuire aux relations en refusant est souvent infondée, car les demandeurs prennent rarement le rejet personnellement, contrairement aux conséquences d’un "oui" forcé.

L’auteur propose une structure en trois parties pour un refus poli : exprimer de l’appréciation pour la demande, formuler un "non" clair sans excuses superflues, et conclure avec bienveillance pour préserver la relation. Cette méthode évite les justifications longues, qui peuvent être exploitées pour relancer la négociation, et repose sur la simplicité et la fermeté.

Enfin, neuf exemples concrets de refus sont fournis, adaptés à des situations courantes comme les réunions inutiles ou les demandes de faveurs. Chaque script inclut une explication de sa logique, permettant de les personnaliser tout en conservant leur efficacité.

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.