Pour découvrir Go et Svelte/SvelteKit, Josh Sherman choisit d’utiliser un LLM comme tuteur plutôt que comme générateur de code. Il construit lui-même une application, pose des questions et exige des références vers une documentation à jour pour vérifier les réponses. Un tournant survient lorsqu’il écrit seul la migration inverse d’une base de données, puis demande au modèle de relire son travail. Après une semaine, il se sent capable de comprendre et de critiquer du code produit par l’IA, sans prétendre maîtriser ces technologies.

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.

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.

Une architecture logicielle réussie dépend autant des contraintes qu’on accepte d’abandonner que de celles qu’on respecte. Tolérer des données temporairement périmées, des écritures non transactionnelles ou quelques pertes de métriques peut simplifier fortement un système et améliorer ses performances. Ces arbitrages exigent un dialogue entre ingénieurs et responsables produit. Avec les agents de programmation, le risque s’accentue : les LLM ajoutent spontanément des vérifications, verrous et garanties non demandés, produisant une complexité inutile. La revue de code doit donc aussi supprimer ces exigences imaginaires.

Le problème majeur du code généré par IA n’est pas nécessairement sa qualité moyenne, mais la perte progressive de compréhension du système par les équipes. Quand spécifications, code, tests et décisions passent presque entièrement par des LLM, l’architecture, l’intention et les choix techniques deviennent opaques. L’auteur insiste sur l’importance des fondamentaux, du jugement humain et surtout de la maintenabilité : générer vite est facile, mais maintenir un système que personne ne comprend devient le véritable risque.

TypeSafe AI propose jev, un modèle d'intelligence artificielle spécialisé dans les décisions rapides et structurées, plutôt que la génération de texte. Ses réponses typées, accompagnées de probabilités, facilitent la classification, le routage et la validation des actions d'agents IA. Le modèle promet une latence et des coûts réduits, mais reste limité aux décisions fermées. Les performances annoncées demandent à être confirmées indépendamment.

Les modèles de langage permettent de repérer des vulnérabilités dans les logiciels libres sans être spécialiste en cybersécurité, mais la difficulté réside dans leur validation et leur signalement avant les autres chercheurs. Zwindler décrit une méthode associant analyse par composants, sous-agents, contre-expertise et reproduction sur des installations réelles. Il insiste sur la vérification humaine, l’évaluation réaliste de la gravité et la recherche de doublons pour éviter de saturer les mainteneurs de rapports inutiles. La connaissance des outils audités constitue un avantage décisif.

La fatigue liée à l'intelligence artificielle touche les équipes de développement, confrontées à une pression constante pour évaluer une multitude de nouvelles tendances et d'outils d'IA. Cette situation s'aggrave par la nécessité de gérer le code généré par l'IA aux côtés des systèmes existants, créant un sentiment de perte de contrôle similaire aux vagues technologiques précédentes, mais accéléré par la progression rapide des grands modèles de langage.

Une majorité d'experts en technologie, près de trois quarts, ressentent une pression significative pour explorer chaque nouvelle tendance en IA malgré des ressources limitées. Pour y faire face, il est conseillé de comprendre l'objectif métier derrière l'adoption d'une technologie d'IA, plutôt que de viser la maîtrise de chaque outil. Il est également acceptable d'admettre son ignorance d'un outil spécifique et de privilégier une veille générale des tendances pour sélectionner plus tard des outils prometteurs.

De plus, plus de la moitié des leaders technologiques éprouvent des difficultés à évaluer de manière cohérente les technologies d'IA selon des critères de gouvernance, de sécurité et opérationnels. Une approche consiste à appliquer les cadres d'évaluation existants pour les fournisseurs de services technologiques, notamment en matière de gestion des données et de conformité. Des tests à faible risque, tels que des études pilotes courtes dans des environnements isolés et avec des données simulées, permettent de comprendre le comportement, le coût et les compromis d'un outil avant une éventuelle adoption à plus grande échelle.

L'article aborde la question de l'acceptation des contributions générées par les LLM dans les projets open source, en la présentant comme un "pari pascal" moderne. Il distingue trois approches : l'acceptation majoritaire, le rejet strict, et une position intermédiaire jugée peu durable.

La position intermédiaire, telle que celle adoptée par Debian, est présentée comme une illusion de neutralité qui, à terme, conduit à une adoption inéluctable du code généré, sans en assumer la responsabilité. L'auteur soutient que rester dans cette zone grise équivaut, dans les faits, à une acceptation lente et non déclarée, qui peut être vue comme naïve ou hypocrite.

Face à ce dilemme, l'article suggère que chaque projet open source doit faire un choix urgent et clair entre accepter ou rejeter les contributions issues des LLM. Le rejet, bien qu'il puisse aliéner certains contributeurs, semble préférable car il évite de dépendre de technologies propriétaires et de perdre l'indépendance, tout en préservant la communauté des utilisateurs qui ne recherchent pas de logiciels spécifiquement "anti-IA".

La note aborde la problématique de l'autorisation légale pour analyser des données confidentielles, spécifiquement des secrets industriels, à l'aide d'un modèle linguistique de grande taille (LLM). L'objectif est de proposer des exemples de documents contractuels à faire signer par les clients, en fonction de cinq scénarios d'hébergement et d'accès au LLM, allant du SaaS hors UE à un serveur physique interne.

La distinction entre l'accès via une interface de chat et une API est soulignée, la note se concentrant exclusivement sur l'accès par API. Cette approche est motivée par la complexité et le coût d'hébergement des modèles LLM eux-mêmes, qui nécessitent une infrastructure matérielle spécifique comme des serveurs équipés de GPU, contrairement aux interfaces de chat plus légères.

Le contenu détaille ensuite les implications légales de chaque option, en classifiant les solutions par localisation du traitement des données, et non par juridiction du fournisseur. Cela permet de comparer les différentes approches et de comprendre leur impact sur la relation client, en identifiant celles qui pourraient potentiellement effrayer ou rassurer.

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.