Goose est un agent IA open source et extensible conçu pour aller au-delà des simples suggestions de code. Il permet d'installer, d'exécuter, d'éditer et de tester avec n'importe quel grand modèle de langage (LLM), offrant ainsi une interaction plus complète et automatisée.
Le projet se distingue par sa capacité à interagir dynamiquement avec des environnements de développement, en intégrant des outils pour manipuler des fichiers, exécuter des commandes et même interagir avec des plateformes comme Databricks. Il prend en charge Docker et propose des instructions détaillées pour la compilation et l'exécution sur différentes plateformes.
Goose est activement maintenu avec une communauté importante, comptant plus de 48 000 étoiles et 5 200 forks sur GitHub. Le projet inclut également des évaluations de performance, des exemples d'utilisation et une documentation complète pour faciliter la contribution et l'adoption.
L’idée principale de l’article est de proposer une méthode de travail avec deux agents IA pour améliorer la programmation assistée par IA. L’un écrit le code dans un espace de travail dédié, tandis que l’autre, en parallèle, le révise systématiquement après chaque cycle de développement (TDD). Ce second agent, qualifié de « porteur de la lampe », maintient la vision globale du projet et évite que le premier agent ne s’éloigne des objectifs initiaux en se perdant dans les détails techniques.
L’auteur souligne que cette approche simple mais efficace permet de corriger deux problèmes majeurs : d’une part, l’agent codeur peut dériver de la mission initiale en accumulant des décisions localement optimales, et d’autre part, le réviseur identifie les erreurs structurelles ou les choix qui compliquent les étapes suivantes. Contrairement aux sous-agents de révision intégrés, ce réviseur dédié conserve une vision cohérente de l’objectif final tout au long du projet.
Enfin, l’article précise que cette méthode s’ajoute aux outils existants (comme les sous-agents de révision ponctuels) sans les remplacer, car ils remplissent des rôles complémentaires : les sous-agents gèrent les problèmes immédiats, tandis que le réviseur dédié préserve la cohérence globale. Cette coordination entre agents représente une évolution naturelle pour les utilisateurs maîtrisant déjà un agent unique.
L’auteur partage son parcours progressif dans l’utilisation de l’intelligence artificielle, depuis les outils grand public jusqu’à des solutions plus techniques et locales. Il décrit cinq niveaux d’apprentissage, commençant par l’usage basique de ChatGPT dans un navigateur, où l’outil a montré ses limites, notamment en générant des réponses incorrectes ou en tournant en rond malgré des demandes précises. Cette première étape, bien que limitée, permet de saisir le potentiel des modèles de langage.
Il aborde ensuite l’installation de modèles locaux via des outils comme Ollama ou Hugging Face, soulignant l’importance de paramètres comme la taille du contexte (limitant les hallucinations) et la température (contrôlant la créativité). Bien que ces solutions offrent une alternative aux services externes, elles restent moins performantes en rapidité et en qualité, mais permettent une meilleure maîtrise des ressources et des coûts. L’auteur mentionne aussi l’achat d’une carte graphique dédiée pour améliorer les performances, un investissement justifié par son intérêt pour l’autonomie technologique.
L’article aborde la notion de « bon code » dans un contexte où l’IA facilite la génération de code, tout en soulignant que sa qualité reste un enjeu majeur. L’auteur s’appuie sur les travaux de Simon Willison pour définir un code efficace : il doit fonctionner correctement, être validé par des tests et des vérifications, et résoudre un problème réel plutôt qu’un besoin technique mal ciblé. La robustesse face aux erreurs, la simplicité, la documentation à jour et l’évolutivité sont également mises en avant.
L’auteur insiste sur l’importance de gérer les cas d’échec avec des messages exploitables et d’éviter la complexité inutile, tout en respectant des critères non fonctionnels comme la sécurité ou la maintenabilité. Ces principes, valables avant l’ère de l’IA, deviennent encore plus cruciaux avec l’automatisation, car ils garantissent la fiabilité et la pérennité des solutions produites.
Ce dépôt GitHub propose Caveman, un plugin pour Claude Code (et autres outils d'IA) qui réduit drastiquement la taille des réponses en adoptant un langage minimaliste, inspiré du "parler caveman". L'idée centrale est de conserver la précision technique tout en diminuant jusqu'à 75 % des tokens utilisés, ce qui optimise les coûts et la rapidité des interactions.
Le projet inclut des exemples concrets comparant les réponses standard et celles compressées, comme une explication sur les re-rendus de composants React passant de 69 à 19 tokens. Il propose également des benchmarks, des guides d'installation et une documentation détaillée pour une intégration facile avec plus de 30 outils compatibles.
Développé sous licence MIT, Caveman s'appuie sur des scripts d'installation automatisés et une structure modulaire pour faciliter son déploiement et ses contributions. Le dépôt met en avant des améliorations continues, comme la consolidation des fichiers de configuration et des correctifs pour les scripts d'installation.
Ce dépôt GitHub, soutenu par les équipes de Google Chrome et Microsoft Edge, propose un guide moderne pour le développement web destiné aux agents d'IA. Il vise à les orienter vers des API modernes, performantes et sécurisées plutôt que des solutions obsolètes, en comblant le fossé entre les connaissances des modèles et les bonnes pratiques actuelles.
L'outil, disponible via une commande CLI (npx modern-web-guidance@latest install), fournit des recommandations ciblées et optimisées pour le contexte des agents, couvrant des disciplines comme l'UX, le CSS, les performances ou l'accessibilité. Il inclut 102 fonctionnalités web modernes et 128 cas d'usage concrets, avec des évaluations pour éviter les contenus redondants.
Le projet, encore en version préliminaire, encourage les contributions et retours via GitHub pour enrichir ses guides, notamment sur l'adoption progressive des fonctionnalités et les stratégies de fallback.
Hallmark est un outil conçu pour améliorer les designs générés par IA en évitant l’aspect artificiel et répétitif. Il propose trois fonctionnalités principales : Build pour créer des pages structurées et variées à partir d’une demande, Study pour analyser et extraire la structure d’un design existant, et Audit pour identifier et corriger les anti-patterns courants comme les dégradés de couleurs ou les polices mal assorties.
L’outil se distingue par son approche anti-slop, refusant les solutions génériques et imposant une diversité structurelle grâce à un système de thèmes et de vérifications automatisées. Il permet aussi de redesigner des pages en conservant leur contenu mais en changeant leur structure, pour éviter les répétitions.
Hallmark cible les développeurs et designers utilisant des agents IA comme Claude Code ou Cursor, en offrant une alternative plus qualitative aux générations standardisées. Son catalogue d’anti-patterns et ses exemples concrets illustrent son ambition de produire des designs plus humains et moins reconnaissables comme générés par IA.
L’article The Intent Debt d’Addy Osmani explore trois types de dettes techniques dans le développement logiciel : technique, cognitive et intentionnelle. La dette intentionnelle, distincte des deux autres, désigne l’absence de documentation claire des objectifs, contraintes et justifications derrière un système, ce qui rend son évolution difficile à comprendre pour les nouveaux membres ou les outils automatisés. Contrairement à la dette technique (liée au code) ou cognitive (liée à la compréhension humaine), la dette intentionnelle ne peut être résolue par des agents IA, car elle repose sur des décisions humaines non formalisées.
L’auteur souligne que ces dettes sont indépendantes : un code propre peut cacher une dette intentionnelle élevée si son contexte n’est pas documenté. Les agents IA peuvent aider à réduire la dette technique ou cognitive (en expliquant du code), mais ils ne peuvent pas restituer une intention non écrite, risquant même d’inventer des justifications plausibles mais erronées. Cette limite devient critique avec l’automatisation croissante, car les équipes ne peuvent plus compter sur la transmission orale des connaissances pour combler ce vide.
Enfin, Osmani met en garde contre l’aggravation de la dette intentionnelle avec l’essor des outils automatisés. Historiquement, les équipes compensaient ce manque par des échanges informels, mais cette approche devient insoutenable à l’ère de l’IA, où la documentation explicite des intentions devient indispensable pour éviter des dérives coûteuses et difficiles à corriger.
Les équipes d'ingénierie en 2026 constatent que les agents IA échouent rarement à cause du modèle lui-même, mais en raison de problèmes d'infrastructure invisibles, comme des appels d'outils malformés, des changements de prompts non suivis ou des latences imprévisibles dans des workflows multi-étapes. Les systèmes traditionnels de monitoring backend, conçus pour des API classiques, ne suffisent pas à détecter ces défaillances, car un serveur sain peut produire des résultats erronés sans alerte.
Parmi les principaux modes de défaillance, les appels d'outils silencieux posent un défi majeur : les agents continuent souvent leur exécution malgré des données corrompues, rendant les erreurs difficiles à identifier avant que les utilisateurs ne les signalent. De même, les dérives de prompts ou de schémas, souvent perçues comme mineures, peuvent entraîner une dégradation progressive de la qualité des sorties, nécessitant une gestion versionnée et traçable des prompts comme une infrastructure critique.
Enfin, les workflows multi-étapes, combinant plusieurs appels de modèles, APIs externes et outils, sont particulièrement vulnérables aux latences explosives, où la source d'un problème devient difficile à isoler. Les équipes se tournent donc vers des solutions d'observabilité spécifiques aux agents IA pour rendre ces systèmes plus fiables et maintenables.
L’article explique comment rendre une application Symfony prête pour l’ère des agents IA, en abordant des améliorations comme la négociation Markdown, les signaux de contenu, l’exposition d’API, la documentation OpenAPI et les bases du SEO. L’idée principale est d’adapter les sites web aux interactions avec les agents IA, tout en soulignant que les bonnes pratiques SEO (sécurité, balises, données structurées, etc.) servent de base commune aux deux objectifs.
L’auteur présente ensuite les content signals, une directive robots.txt proposée pour contrôler l’usage du contenu par les IA (entraînement, indexation, entrée pour les modèles). Par défaut, il recommande d’autoriser l’indexation et l’utilisation en entrée pour les outils de recherche, tout en laissant le choix pour l’entraînement, selon les besoins du projet.
Enfin, l’article mentionne des ressources comme isitagentready.com pour évaluer les progrès et propose des outils complémentaires, comme un bundle Symfony et des prompts d’implémentation, bien que l’explication reste générale pour couvrir plusieurs aspects sans entrer dans les détails techniques.
L’auteur, développeur depuis 1983, partage son expérience de l’intégration de l’IA dans son workflow, notamment via le Markdown pour rédiger spécifications et architectures. Il critique à la fois le vibe coding (délégation aveugle à l’IA) et le rejet puriste de cette technologie, soulignant que la valeur réside désormais dans la conception et la supervision, pas dans la production de code brute.
Il utilise l’IA comme un outil collaboratif : pour des tâches simples, elle agit comme une exécutante rapide, tandis que pour les parties complexes, il supervise et valide, voire code lui-même. L’objectif est de maintenir une architecture compréhensible et maîtrisée, évitant ainsi les risques liés à des systèmes opaques ou dépendants de tarifs ou de disponibilités externes.
Enfin, il compare l’IA à un retour partiel du cycle en V, où la spécification redevient centrale. La confiance dans le code généré doit être proportionnelle à la capacité de le critiquer, et les rôles (spécification, validation, expertise) doivent rester clairs pour préserver la robustesse du système.
Chris Shiflett décrit la création d’un serveur MCP (Model Context Protocol) pour son laboratoire personnel, un espace où il centralise ses projets et outils maison. Il explique comment il a rationalisé son répertoire ~/local, autrefois encombré de projets inaboutis, en relançant des outils comme Landice, Faculty ou Schoolcase, tout en adoptant progressivement l’IA malgré ses réticences initiales. Son approche progressive avec l’IA, passant de simple référence à collaborateur, l’a conduit à voir cette technologie comme un "robot" capable d’exécuter du code, bien que des limites persistent, comme l’interface de Claude ou la perte de contexte entre conversations.
Shiflett souligne deux obstacles majeurs dans son utilisation de l’IA : d’abord, l’asymétrie entre l’exécution manuelle du code et l’approche automatisée de Claude Code, qui réduit sa participation active. Ensuite, le manque de mémoire des assistants, obligeant à résumer manuellement l’historique des échanges dans des fichiers Markdown avant de recommencer une conversation. Ces contraintes l’ont poussé à concevoir un serveur MCP pour mieux contrôler l’interaction avec l’IA et intégrer ses outils existants.
L’objectif final est de fluidifier ce processus en créant une interface unifiée, où l’IA agit comme un véritable partenaire de développement plutôt qu’un simple exécutant. Ce projet reflète sa volonté de concilier innovation technologique et méthodes de travail personnelles, tout en résolvant les frictions rencontrées dans l’adoption de l’IA.
L’article interroge la qualité croissante des logiciels et l’impact de l’IA sur leur fiabilité, dans un contexte marqué par des failles de sécurité fréquentes et des fuites de données. L’auteur souligne que les vulnérabilités (CVE) ont fortement augmenté depuis 2017, attribuant cette hausse à des facteurs comme la pression des mises à jour quotidiennes, l’expansion du numérique et l’intensification des cyberattaques, plutôt qu’à l’IA. Il relativise cependant ce lien, notant que les CVE reflètent aussi une meilleure détection des bugs et une industrie cyber en croissance.
L’auteur évoque des exemples concrets, comme des failles majeures chez GitHub ou des attaques contre des institutions françaises, pour illustrer la dégradation perçue de la qualité logicielle. Il critique l’idée selon laquelle l’IA serait la principale responsable, soulignant que la baisse de fiabilité précède son adoption massive et s’explique davantage par des enjeux économiques et géopolitiques.
Enfin, l’article aborde la perception selon laquelle l’IA accélérerait la production de "code de merde", une idée que l’auteur juge exagérée. Il conclut que la qualité des logiciels dépend davantage des pratiques de développement et des pressions du marché que de l’IA, tout en reconnaissant que cette dernière pourrait aggraver certains problèmes si mal utilisée.
Le journal décrit une infrastructure personnelle d’IA auto-hébergée basée sur des composants compatibles OpenAI afin de pouvoir utiliser localement des LLM et des outils de génération d’images sans dépendre de services cloud propriétaires. L’auteur s’appuie notamment sur llama-swap, qui permet de basculer dynamiquement entre différents modèles et moteurs d’inférence, y compris stable-diffusion.cpp, avec une configuration adaptée à une machine équipée de plusieurs GPU Nvidia. Le texte insiste sur l’intérêt de standardiser les API pour orchestrer plusieurs IA locales, sur la maîtrise des ressources matérielles (VRAM, chargement/déchargement des modèles) et sur les avantages en matière de souveraineté, de confidentialité et de flexibilité pour expérimenter différents modèles open source directement sur sa propre infrastructure.
Sean Goedecke explique qu’en 2026 il utilise désormais les LLMs comme de véritables agents capables de produire des pull requests complètes, y compris dans des zones de code qu’il maîtrise bien, avec une simple passe de revue finale avant validation. Il décrit un changement majeur par rapport à 2025 : les agents récupèrent beaucoup mieux de leurs erreurs, vont plus vite et nécessitent moins de supervision en temps réel, ce qui l’a amené à passer d’un workflow centré sur VSCode à des outils orientés terminal et agents comme GitHub Copilot App. Il insiste cependant sur le fait que son travail s’est déplacé vers l’évaluation rapide des propositions générées, le tri des mauvaises approches et la revue approfondie des changements acceptés, notamment pour supprimer les “LLM-isms” comme le sur-commentaire ou certaines décisions de conception discutables. L’auteur continue aussi d’utiliser les LLMs pour apprendre de nouveaux domaines, produire du code jetable de recherche ou explorer des bases de code inconnues, mais souligne qu’ils restent moins fiables pour le jugement architectural, les ADRs ou les décisions techniques engageantes à long terme.
Addy Osmani explique que l’usage actuel des assistants IA en développement logiciel favorise la résolution rapide des tâches au détriment de la compréhension profonde : le bug est corrigé, mais le modèle mental du développeur ne progresse plus. Il décrit une forme de « dette de compréhension » où l’on délègue progressivement le raisonnement à l’IA, jusqu’à perdre la capacité de reconstruire ou faire évoluer un système sans assistance. L’auteur ne rejette pas l’IA — qu’il utilise massivement — mais insiste sur la différence entre utiliser un modèle comme accélérateur d’apprentissage ou comme distributeur automatique de solutions. Il recommande notamment de formuler une hypothèse avant de solliciter l’IA, de demander des explications plutôt que du code prêt à l’emploi, et de traiter les réponses comme une revue de code d’un développeur junior. Il s’appuie aussi sur plusieurs études récentes montrant que les développeurs qui utilisent l’IA passivement comprennent moins bien leur propre code, alors que ceux qui l’emploient comme outil pédagogique conservent un niveau de compréhension comparable à un travail sans IA.
L’article analyse un paradoxe créé par l’IA : contrairement aux précédentes révolutions technologiques qui valorisaient surtout les profils juniors et exécutants, l’intelligence artificielle renforce désormais la valeur de l’expérience et de l’expertise humaine. Les professionnels expérimentés deviennent essentiels car ils savent contextualiser les demandes, formuler les bonnes hypothèses et surtout exercer un discernement critique sur les réponses produites par les modèles. Le texte insiste aussi sur le risque d’une adoption trop rapide et insuffisamment comprise de ces outils, rappelant que l’enjeu n’est pas de ralentir le progrès mais de conserver une maîtrise consciente de ses usages afin que l’IA reste un levier au service des capacités humaines plutôt qu’un mécanisme subi.
L’auteur partage sa méthode pour développer des produits avec l’IA tout en maîtrisant les coûts, en limitant la consommation de tokens à environ 20 € par mois. Il utilise principalement Claude pour coder, notamment pour ses projets Writizzy (une plateforme de newsletters) et Hakanai (blogs statiques), en appliquant une approche de context engineering pour guider l’IA et éviter les erreurs.
Pour structurer son travail, il s’appuie sur des fichiers Claude.md définissant les spécifications du projet et des règles conditionnelles (.claude/rules) qui imposent des bonnes pratiques (comme l’utilisation de Nuxt UI ou des vérifications de typage). Ces règles, affinées empiriquement, réduisent les explorations inutiles de l’IA et optimisent l’efficacité.
Enfin, l’auteur souligne que ces mesures ne sont pas infaillibles : il complète avec des contrôles automatisés (tests, linters, CI) pour limiter les risques d’erreurs. Il évoque aussi une possible transition vers un autre modèle, plus performant pour le code, tout en maintenant une approche budgétaire stricte.
L’article de JoliCode explore l’intégration de l’IA dans les workflows UX/UI, soulignant que l’IA ne remplace pas les designers mais redéfinit leur rôle en optimisant certaines tâches et en nécessitant de nouvelles compétences, notamment la maîtrise des prompts. L’idée centrale est que la qualité des résultats dépend directement de la précision des demandes adressées à l’IA, comparée à un briefing détaillé pour un collaborateur humain. L’auteur illustre cette nécessité par des exemples concrets, opposant des requêtes vagues à des formulations structurées intégrant tâche, contexte, éléments clés, comportements attendus et contraintes.
L’IA s’avère particulièrement utile à différentes étapes du processus créatif : exploration des idées, conception de maquettes ou de parcours utilisateurs, et production de contenus ou de composants. L’article insiste sur l’importance d’adapter son utilisation de l’IA selon la phase du projet, en l’intégrant comme un outil collaboratif plutôt qu’un simple générateur automatique. Les métaphores et retours d’expérience illustrent comment une intégration réfléchie peut accélérer les itérations tout en maintenant une approche centrée utilisateur.
Enfin, l’auteur met en garde contre les pièges courants, comme les prompts trop génériques, et propose une méthodologie pour formuler des demandes efficaces. L’objectif n’est pas de déléguer aveuglément à l’IA, mais de l’utiliser comme un levier pour gagner du temps sur les tâches répétitives, tout en recentrant le travail des designers sur l’analyse, la validation et l’innovation.
L’édition 2026 du Devoxx a mis en lumière l’impact croissant de l’IA sur l’ingénierie logicielle, notamment à travers des architectures multi-agents et des outils émergents comme l’informatique quantique. Les conférences ont souligné des avancées majeures, comme les design patterns agentiques, qui redéfinissent l’interaction avec les grands modèles de langage (LLM) en structurant des écosystèmes autour d’objectifs, de mémoire, d’outils et de planification.
Parmi les concepts clés, le Retrieval Augmented Generation (RAG) a été présenté comme une solution efficace pour connecter les IA à des données actualisées ou privées, en optimisant l’extraction ciblée d’informations plutôt que leur intégration massive. Une autre approche, le planning programmatique, a été évoquée pour les processus métiers nécessitant un contrôle précis, où le développeur code une séquence fixe d’appels aux LLM, limitant ainsi les risques d’hallucinations.
Enfin, l’événement a abordé des enjeux futurs comme la résilience de l’expertise technique au-delà de 2030 et les défis posés par la complexité croissante des outils, tout en explorant des solutions pour maintenir la qualité logicielle à l’ère de l’IA.