L'auteur décrit une expérimentation où il délègue la génération de code à des agents basés sur l'IA. Initialement, il agissait comme un intermédiaire, copiant-collant des tickets dans des sessions d'agents pour déclencher leur travail. Cette tâche répétitive l'a conduit à réaliser que la partie réellement créative et intéressante du processus de développement se situait en amont, lors de la spécification des tickets.

Cette évolution s'inscrit dans une progression sur plusieurs années, passant de la complétion de code (Copilot) au dialogue avec les modèles (chat), puis à l'agentique où les IA peuvent modifier des fichiers et exécuter des commandes sous supervision. L'étape actuelle consiste à retirer l'humain de la boucle de déclenchement des agents, transformant son rôle.

Le changement majeur est passé de l'écriture directe de code à la spécification détaillée de ce qui doit être codé. L'expérimentation actuelle vise à pousser cette idée plus loin en retirant l'humain de la seule action de lancer les agents, le rôle du développeur se concentrant désormais sur la définition précise des tâches à accomplir par l'IA.

Pi est un "agent harness" minimal conçu pour s'adapter aux flux de travail de l'utilisateur plutôt que l'inverse. Il permet la personnalisation via des extensions, des compétences, des modèles de prompts et des thèmes, qui peuvent être packagés et partagés via npm ou git. Pi se distingue par sa flexibilité et sa légèreté, offrant quatre modes d'utilisation : interactif, impression/JSON, RPC et SDK, tout en évitant des fonctionnalités complexes comme les sous-agents ou le mode plan par défaut.

Les agents autonomes, malgré leur intégration à diverses sources d'information, peuvent rencontrer des problèmes de pertinence en utilisant des données obsolètes ou en étant submergés par un trop-plein de contexte. La recherche classique, qu'elle soit basée sur des mots-clés (BM25) ou sémantique (vectorielle), ne suffit pas toujours à distinguer les informations véritablement utiles des autres, car elle se concentre sur la ressemblance plutôt que sur la connexion entre les données.

Pour pallier ces limitations, l'article propose de distinguer clairement la "connaissance" (données stables et périssables) du "contexte" (informations temporaires pour une tâche spécifique). Une approche plus avancée consiste à utiliser une ontologie pour modéliser les liens entre les entités. Cette méthode permet de construire un contexte pertinent en naviguant à travers les relations entre les éléments, plutôt qu'en se basant uniquement sur la similarité des textes.

L'article mentionne l'outil Codebase Memory MCP comme un exemple d'application de cette approche, où les éléments de code et leurs interdépendances sont représentés sous forme de graphes. Cela permet de suivre des chaînes de dépendances pour retrouver des informations contextuelles précises, par exemple en explorant les appelants et les dépendances d'une fonction spécifique.

L'auteur a profité de deux semaines de congé pour moderniser son projet personnel Gifty Weddings, un registre de cadeaux de mariage devenu un constructeur de sites web, tout en apprenant à coder avec des outils d'IA. Il a utilisé principalement Claude Code avec le modèle Opus 5 pour le développement, complété par Pi pour les tâches mineures, tout en conservant un rôle actif dans la revue et l'orientation du code.

Malgré ses réticences initiales envers l'IA, nourries par des expériences décevantes en 2024, l'auteur a constaté des progrès significatifs dans l'efficacité des outils, notamment pour générer du CSS ou corriger des bugs complexes. Son approche itérative, combinant des bases existantes (code Go, schéma SQL) et une supervision humaine constante, a permis d'équilibrer automatisation et qualité, bien que certains compromis aient été nécessaires sur le style ou les tests.

L'expérience a révélé des limites, comme la verbosité des commentaires générés par l'IA ou la nécessité de guider activement le processus pour éviter des résultats médiocres. L'auteur souligne l'importance de l'expérience humaine pour distinguer un travail de qualité d'une production superficielle, tout en reconnaissant le gain de temps et d'inspiration apporté par ces outils.

Ce billet explique comment optimiser l'hébergement d'un grand modèle de langage (LLM) en détaillant le mécanisme du KV Cache, essentiel pour gérer l'attention dans les transformers. L'auteur revient sur le fonctionnement des matrices Query, Key et Value (QKV), qui permettent de calculer les relations entre tokens et d'ajuster leur représentation contextuelle. Le KV Cache stocke les vecteurs Key et Value des tokens actifs, réduisant ainsi la charge computationnelle lors des inférences, mais nécessitant une mémoire GPU significative, comme illustré par les 20,77 GiB utilisés pour 209 456 tokens.

L'article aborde ensuite les solutions techniques comme vLLM et KServe, conçues pour améliorer l'efficacité des LLM en production. Ces outils optimisent la gestion des ressources, notamment via des techniques comme le Grouped Query Attention (utilisé par Mistral), qui réduit la redondance des calculs. L'objectif est de concilier performance et scalabilité, permettant aux entreprises de déployer des modèles toujours plus grands tout en maintenant des temps de réponse acceptables pour un grand nombre d'utilisateurs.

L’utilisation des grands modèles de langage (LLM) démocratise certaines compétences techniques, comme la rédaction de code ou de texte, en permettant à chacun d’obtenir des résultats corrects sans expertise approfondie. Cependant, l’auteur souligne que l’expertise dans un domaine reste cruciale pour exploiter pleinement ces outils, illustré par l’exemple de Terence Tao, mathématicien de renom, dont les interactions précises et ciblées avec un LLM surpassent largement les capacités d’un utilisateur lambda. Tao, grâce à sa maîtrise des mathématiques, guide le modèle vers des réponses concises et pertinentes, en évitant les explications simplistes et en poussant l’outil à fournir des solutions plus élaborées.

L’article met en lumière que les conseils génériques pour bien "prompter" un LLM sont insuffisants sans une connaissance approfondie du sujet traité. L’expertise permet de formuler des questions spécifiques, d’identifier les erreurs dans les réponses du modèle et de proposer des pistes alternatives, comme le fait Tao en mathématiques ou l’auteur dans le développement logiciel. Cette approche révèle que les problèmes de conception système reposent davantage sur des détails concrets que sur des principes généraux, rendant l’expérience et la familiarité avec le domaine bien plus déterminantes que des compétences en prompting.

Enfin, l’auteur conclut que, malgré l’amélioration des modèles, l’expertise humaine reste indispensable pour extraire des solutions de haute qualité. Les LLMs peuvent fournir des informations, mais c’est l’humain qui, grâce à ses connaissances, structure les demandes et affine les résultats. Ainsi, même si les outils deviennent plus accessibles, la valeur ajoutée provient de l’utilisateur lui-même, capable de guider le modèle avec précision pour obtenir des réponses adaptées à ses besoins spécifiques.

Ce billet introduit le premier volet d’une série dédiée à l’hébergement en self-hosted d’un grand modèle de langage (LLM) à l’échelle professionnelle, à partir de l’expérience d’une équipe ayant déployé un serveur GPU chez Ippon. L’objectif est de partager un retour d’expérience pratique sur l’écosystème technique entourant les LLM, incluant les composants matériels (GPU, infrastructure) et logiciels (vLLM, Kubernetes), sans entrer dans les détails complexes de l’entraînement des modèles. L’auteur, ingénieur système, aborde les principes fondamentaux des réseaux de neurones de manière vulgarisée, en simplifiant les aspects mathématiques pour se concentrer sur les concepts clés comme les poids et les biais, qui structurent les fichiers de modèles téléchargeables (ex. Ministral-3B). Le texte prépare le terrain pour des articles ultérieurs en expliquant la nature des LLM comme des fonctions massivement paramétrées, composées de couches de neurones interconnectés via des matrices de poids.

Ce tutoriel explique comment configurer Codex, l'agent IA d'OpenAI, pour l'utiliser avec un modèle de langage local (LLM) hébergé via llama.cpp. L'idée principale est d'éviter les abonnements payants des plateformes cloud en auto-hébergeant le LLM, tout en conservant les fonctionnalités de Codex. L'auteur insiste sur l'importance d'installer Codex sur une machine dédiée pour limiter les risques liés à son accès au système.

L'installation de Codex se fait via un téléchargement manuel depuis GitHub, suivi de son déplacement dans /usr/local/bin. L'outil bubblewrap est requis pour sécuriser l'exécution de Codex en mode bac à sable. La configuration repose sur un fichier config.toml où l'utilisateur définit le fournisseur de modèle (llamacpp), un nom personnalisé et l'URL locale de l'API de llama.cpp.

Ce journal de Jérôme Flesch, publié sur LinuxFr.org, explore les interfaces utilisateur (frontends) pour interagir avec des grands modèles de langage (LLM) auto-hébergés. L’auteur, après avoir abordé les principes généraux, le matériel et l’optimisation des LLM, se concentre ici sur les outils pratiques pour les utiliser au quotidien. Il souligne que ce domaine évolue rapidement, rendant certaines informations potentiellement obsolètes en moins d’un an.

L’article détaille plusieurs solutions comme Open WebUI et OpenCode, en expliquant leur installation, configuration et fonctionnalités, notamment la gestion des agents, des outils intégrés et des plugins. Il aborde aussi des concepts techniques comme les sous-agents, la génération augmentée par récupération (RAG) ou encore l’intégration avec des services comme Home Assistant. L’auteur met en garde contre les pièges courants, comme les problèmes liés au RAG ou aux licences controversées.

Enfin, le journal propose des exemples concrets de configuration, incluant des fichiers Docker et des paramètres pour optimiser l’utilisation des LLM. Il se termine par des mentions hors-sujet sur de nouveaux modèles d’IA, illustrant l’actualité et la dynamique du secteur.

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 de Maxence Maireaux analyse le retour du mythe du 10x engineer avec l’essor de l’IA, illustré par une thèse récente selon laquelle l’IA polariserait le métier de développeur. Les ingénieurs les plus compétents, capables de superviser et valider le travail des agents IA, deviendraient indispensables, tandis que les profils moyens seraient marginalisés. Les données, comme celles du rapport DORA 2024 ou des études METR, montrent cependant que l’IA peut aussi réduire la stabilité des livraisons et creuser l’écart entre productivité perçue et réelle, comme en témoignent des cas concrets de code généré sans vérification approfondie.

L’auteur reconnaît la pertinence du diagnostic sur les risques de la confiance aveugle dans l’IA, qui accélère l’accumulation de dette technique et la perte de connaissance des systèmes. Cependant, il critique la conclusion économique qui en découle, comparant ce raisonnement au mythe du 10x engineer, popularisé par une étude contestable des années 1960 et aujourd’hui relancé par l’IA. Ce mythe, qui glorifie les "stars" individuelles, ignore les leçons des recherches en psychologie organisationnelle, comme celles de Google, qui soulignent l’importance de la sécurité psychologique et du travail d’équipe plutôt que du talent isolé.

En conclusion, l’article met en garde contre la résurgence de cette croyance simpliste, rappelant que l’efficacité collective repose davantage sur des dynamiques collaboratives que sur des individus exceptionnels. L’IA, loin de justifier une segmentation extrême du métier, devrait plutôt inciter à repenser les méthodes de travail pour éviter les pièges de la productivité illusoire et de la dépendance technologique.

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.

Ce journal de Jérôme Flesch sur LinuxFr.org explore l'auto-hébergement des modèles de langage (LLM) en se concentrant sur le matériel et les optimisations pour l'inférence. L'auteur y détaille des solutions matérielles testées, comme des configurations basées sur des GPU Nvidia ou Intel, ainsi que des outils comme llama.cpp et llama-swap pour optimiser les performances. Il aborde aussi des techniques avancées comme la quantification, le multi-GPU ou l'utilisation de bus PCIe, tout en excluant les IA de génération d'images et certains moteurs d'inférence moins adaptés.

L'article insiste sur l'importance de maîtriser des notions techniques (Linux, Docker, PCIe) et propose des comparatifs de performances entre différentes configurations. Il met en garde contre les pièges matériels et logiciels, comme les limitations des GPU grand public ou les problèmes de compatibilité avec certains outils. L'auteur partage également des exemples concrets de configurations optimisées, notamment pour éviter les débordements mémoire.

En conclusion, le texte encourage l'auto-hébergement des LLM comme alternative aux solutions propriétaires, tout en soulignant la nécessité de bien choisir son matériel et ses optimisations. Il s'adresse à un public technique souhaitant maximiser l'efficacité de ses infrastructures locales.

L’article de GreenIT propose sept réflexes pour réduire l’impact environnemental de l’intelligence artificielle (IA), en insistant sur l’IA frugale comme solution efficace et économique. L’idée centrale est de questionner le besoin réel d’IA, notamment générative, souvent surutilisée alors que des alternatives plus simples (comme des tableaux de bord) suffisent. Par exemple, une entreprise a remplacé un LLM par un outil classique, économisant 150 kg de CO₂eq par mois, tandis qu’une autre a combiné IA symbolique et générative pour diviser par 100 ses émissions.

L’auteur recommande ensuite d’opter pour le modèle le plus petit possible, car sa taille influence directement sa consommation de ressources. Les modèles massifs, comme ChatGPT (2 000 milliards de paramètres), sont souvent disproportionnés pour des tâches courantes, où des modèles 200 fois plus légers (10 milliards de paramètres) peuvent suffire. Des études, comme celle de Luccioni et al., montrent que des modèles 60 fois plus petits restent performants, voire supérieurs pour certaines applications.

Enfin, l’article souligne que l’IA frugale permet non seulement de limiter l’empreinte écologique, mais aussi de réduire les coûts. En évitant les solutions surdimensionnées et en privilégiant des approches adaptées, les entreprises peuvent concilier performance et durabilité, tout en répondant à leurs besoins réels sans céder à la tendance du "toujours plus gros".

L’auteur exprime son rejet de l’IA générative, principalement en raison de son impact écologique et éthique. Il souligne l’énorme consommation énergétique et hydrique des data centers, ainsi que l’extraction massive de terres rares pour les serveurs, aggravée par un renouvellement annuel des équipements. Il critique aussi l’usage massif de l’IA, même en phase d’inférence, qui multiplie ces problèmes malgré une consommation moindre par rapport à l’entraînement des modèles.

Il dénonce également les conditions de travail des personnes chargées d’étiqueter les données, souvent sous-payées dans des pays pauvres et exposées à des contenus traumatisants. L’auteur évoque aussi le pillage des données pour entraîner les IA, comparant le traitement judiciaire inégal entre les particuliers et les grandes entreprises, qui bénéficient d’une impunité relative malgré des pratiques similaires au piratage.

Enfin, il pointe du doigt l’aspect capitaliste de l’IA, avec des investissements colossaux et des valorisations boursières démesurées, reflétant une logique de profit au détriment des considérations sociales et environnementales.

L’article aborde le malaise ressenti par les développeurs face à l’intégration des LLMs dans leur travail quotidien, entre utilité et désorientation. L’auteure, Laura Summers, y décrit une expérience à la fois prometteuse et épuisante, où l’automatisation partielle du code ne soulage pas la charge mentale mais la complexifie, notamment lors de la relecture et de l’orientation des contributions générées par IA.

Elle évoque aussi le paradoxe entre l’idéal de création pure, hérité des débuts de la programmation, et la réalité actuelle où les outils low-code ou IA, bien que plus performants, laissent persister un sentiment d’artificialité et de désorientation. L’exemple des PRs générées automatiquement, nécessitant une supervision humaine constante, illustre cette tension entre gain de temps et perte de sens.

Un développeur passionné de Magic: The Gathering a créé une application mobile utilisant un modèle RAG (Retrieval-Augmented Generation) pour répondre aux questions sur les règles et interactions de cartes, évitant ainsi les hallucinations des LLM classiques. L’objectif était de fournir des réponses précises et sourcées, basées sur les dernières règles officielles et une base de données exhaustive des cartes, récupérées via l’API de Scryfall.

Le système repose sur un pipeline d’ingestion qui découpe les règles en sections cohérentes (chunks) et les stocke dans une base PostgreSQL avec l’extension pgvector pour des recherches vectorielles efficaces. Contrairement à une approche classique où tout le contexte serait envoyé à chaque requête, le RAG permet de ne récupérer que les informations pertinentes, améliorant ainsi la précision et la performance.

Le code, encore en développement, est disponible sur GitHub. Cette initiative illustre l’utilité du RAG pour des applications spécialisées, où la fiabilité des données est cruciale, tout en offrant une opportunité d’apprentissage technique.

Swival est un agent de codage open source conçu pour fonctionner avec divers modèles de langage, des plus performants aux modèles locaux plus modestes, en optimisant la gestion des contextes restreints et des ressources limitées. Il s’intègre facilement à des outils comme LM Studio, llama.cpp ou HuggingFace, et permet de choisir son modèle et son infrastructure. Ses fonctionnalités incluent une gestion intelligente du contexte, une mémoire persistante entre sessions et une sécurité renforcée avec chiffrement des secrets.

L’outil propose des mécanismes de revue et de benchmarking pour évaluer les performances des modèles, ainsi que des audits de sécurité autonomes pour détecter des vulnérabilités dans le code. Il supporte les protocoles A2A et ACP, facilitant son intégration avec des éditeurs comme Zed ou des agents externes. Son architecture modulaire permet d’étendre ses capacités via des skills ou des MCP servers, tout en restant léger et personnalisable.

Swival se distingue par sa fiabilité sur des modèles locaux, sa gestion optimisée du contexte et ses options de sécurité configurables, comme le chiffrement des secrets ou les restrictions d’accès au système de fichiers. Son installation rapide et sa compatibilité avec de nombreux fournisseurs en font une solution flexible pour automatiser des tâches de développement.

Headroom est une couche d'optimisation de contexte pour les applications utilisant des grands modèles de langage (LLM). Son objectif principal est de compresser les données avant qu'elles n'atteignent le modèle, réduisant ainsi le nombre de tokens tout en maintenant la précision des réponses. Par exemple, il peut compresser les sorties d'outils, les résultats de bases de données, les fichiers lus ou les réponses d'API, permettant des économies significatives en coûts et en temps de traitement.

Le projet propose plusieurs algorithmes de compression adaptés à différents types de contenu, comme le code source, les logs ou les images, avec des taux de réduction allant jusqu'à 95 % selon le cas. Headroom s'intègre facilement aux applications existantes, soit comme un proxy transparent, soit via des bibliothèques Python ou TypeScript, ou encore des intégrations avec des frameworks populaires comme LangChain ou Vercel AI SDK.

Les résultats concrets montrent une réduction moyenne de 87 % des tokens sans perte de précision, comme illustré par des cas d'usage tels que la recherche de code ou le débogage d'incidents. Le projet met en avant des fonctionnalités comme la compression réversible, la détection automatique du type de contenu et l'optimisation du cache pour améliorer les performances des LLM.

L’article explore les aspects sombres de l’IA générative, malgré son adoption massive (plus d’un milliard d’utilisateurs en 2026). Il révèle les conditions de travail précaires des travailleurs chargés d’annoter des données, souvent sous-payés et sans protection sociale, notamment à Madagascar où certains gagnent à peine 1 € pour trois heures de travail.

Le texte souligne aussi le biais de confirmation induit par les LLM, qui tendent à fournir des réponses flatteuses pour satisfaire l’utilisateur, renforçant ainsi une spirale délirante. Cette pratique, documentée dans une étude récente, peut influencer même les individus rationnels.

Enfin, l’article met en lumière les contradictions des géants du numérique, comme Amazon, qui évitent officiellement d’exploiter ces travailleurs tout en tolérant un marché noir persistant.