TinyJS permet de créer des applications de bureau pour macOS, Windows et Linux avec une taille de fichier minimale d'environ 6 Mo. Il utilise un backend JavaScript exécuté sur txiki.js pour un accès complet au système et une fenêtre native (WebView) déjà présente sur le système d'exploitation, évitant ainsi l'embarquement de navigateurs lourds comme Electron.

La plateforme offre un accès système complet via RPC sur un socket Unix, des mises à jour à chaud sans étape de compilation pour le développement, et l'intégration d'éléments d'interface natifs comme les menus ou les boîtes de dialogue. TinyJS se distingue par sa légèreté et son approche minimaliste par rapport à des solutions comme Electron ou Tauri, tout en offrant la possibilité d'intégrer facilement du HTML, CSS et JavaScript existant.

L'article explore le rôle de l'intelligence artificielle dans le développement logiciel, en s'opposant à son utilisation systématique pour "automatiser les parties ennuyeuses" du codage. L'auteur met en avant l'importance de conserver le processus de résolution de problèmes comme un "artisanat" personnel, une pratique qui permet un apprentissage et une croissance profonds.

Face à l'essor de l'IA, l'auteur préconise un retour aux fondamentaux du codage, comparant ce processus à l'entraînement dans un "vieux gymnase" à la Rocky Balboa. L'idée principale est que la lutte directe avec les défis de programmation, même frustrante, est essentielle au développement des compétences et à la maîtrise, un aspect que l'IA ne peut remplacer.

L'IA est reconnue pour son utilité dans des tâches répétitives comme la génération de code boilerplate ou la résumé de documentation. Cependant, le cœur du métier de développeur, impliquant la pensée critique, la conception architecturale et la prise de décisions nuancées, doit être préservé comme un espace de développement personnel, par analogie, à travers le "vieux gymnase" cognitif.

Le texte explore deux approches pour gérer les dépendances lors de tests locaux de services communiquant avec S3 dans une application Symfony. La première question technique concerne l'utilisation de class: versus alias: pour redéfinir un service. L'auteur illustre qu'un alias peut être préférable car il permet de pointer vers une autre définition de service sans pour autant le réinstancier directement, évitant ainsi des erreurs de construction comme le manque d'arguments.

La deuxième question aborde une décision d'architecture : privilégier un "double maison jetable" (un faux service temporaire redirigeant vers le système de fichiers local) plutôt qu'une solution comme MinIO (un conteneur S3-compatible). Cette approche est motivée par la simplicité et la réversibilité, rendant la modification facilement identifiable et supprimable après les tests, notamment grâce au bloc when@dev de Symfony qui permet de scoper la configuration à un environnement spécifique.

En résumé, le choix entre une configuration via class: ou alias: pour substituer un service en environnement de développement, et le type de fausse dépendance utilisé, sont des décisions d'ingénierie qui doivent être adaptées au contexte et aux besoins de réversibilité du processus de développement. L'utilisation de blocs de configuration conditionnels comme when@dev facilite l'intégration et la suppression temporaire de ces adaptations pour les besoins de recettes et de tests.

L'article soutient que la tendance actuelle à diviser les systèmes d'IA en de multiples agents spécialisés, à l'instar des microservices, peut être prématurée et coûteuse. Il souligne que de nombreux agents médiocres ne surpassent pas un seul agent performant, et que la complexité croissante d'un agent unique conduit à une dégradation progressive. Les problèmes majeurs incluent la difficulté de sélectionner le bon outil parmi une liste étendue, la contradiction des instructions dans un unique prompt, et la difficulté de modifier le système sans affecter l'ensemble.

Le moment idéal pour opérer une scission en agents multiples est lorsque ces difficultés deviennent mesurables et nuisibles, et non sur la base d'une esthétique ou d'une tendance. La solution proposée est le schéma "supervisor pattern", où un agent superviseur centralise la classification et le routage des requêtes vers des agents spécialisés. Chaque agent spécialiste est confiné à un domaine unique, disposant de son propre prompt clair, d'un ensemble d'outils limité et distinct, et gérant son propre état de conversation.

Ce modèle permet de retrouver la précision dans le choix des outils et d'éviter les conflits d'instructions, offrant ainsi une meilleure maintenabilité et évolutivité. L'idée principale est de ne pas commencer avec une architecture multi-agents avant que la nécessité ne soit clairement établie par des problèmes concrets liés à la complexité d'un agent unique, puis d'adopter une approche structurée avec un superviseur et des spécialistes.

L'article explore le concept de "Agentic Coding" en comparant le développement de composants graphiques personnalisés à l'aide de primitives D3 et de la librairie Recharts. L'auteur a découvert que l'approche basée sur les primitives D3 a permis de satisfaire pleinement les exigences de conception complexes, y compris les animations et les comportements spécifiques, sans nécessiter de contournements coûteux.

En contraste, la librairie Recharts, bien que plus rapide pour les cas courants, a rapidement montré ses limites pour atteindre les 20% de personnalisation restants, obligeant à coder du SVG personnalisé et à désactiver des fonctionnalités comme les animations pour contourner des problèmes de compatibilité avec la pile React du projet.

L'auteur redéfinit l'abstraction non pas comme un coût nul, mais comme un travail d'implémentation pré-payé qui offre de la flexibilité en échange. L'histoire du développement web est vue comme une ascension progressive de cette échelle d'abstraction, où chaque étape convertit du travail humain coûteux en dépendances moins chères, mais où les besoins spécifiques finissent par révéler les contraintes de ces abstractions de haut niveau.

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.

Graft est un outil open-source conçu pour améliorer les performances des agents de codage tels que Claude Code, Cursor, Codex et Gemini. Il vise à les rendre plus rapides, moins coûteux et à améliorer leur compréhension contextuelle de votre base de code, permettant ainsi des économies significatives en temps et en coût, tout en améliorant parfois la précision des résultats.

L'outil fonctionne en créant un graphe de votre base de code. Ce graphe permet aux agents d'accéder à des informations contextuelles pertinentes, réduisant ainsi le besoin de traiter l'intégralité du code à chaque requête. Graft s'intègre en douceur, notamment avec Claude Code, en ajoutant automatiquement des hooks et en gérant la génération du graphe en arrière-plan, rendant ainsi l'amélioration transparente pour l'utilisateur.

Une fonctionnalité notable de Graft est son application GitHub qui analyse automatiquement les pull requests, offrant des revues de code plus efficaces. Il supporte également une variété de langages de programmation et offre des outils en ligne de commande pour la recherche, la cartographie et la visualisation du graphe de code.

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.

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.

L’article de Romain Lanz explore une méthode pour utiliser efficacement l’IA dans le développement logiciel sans déléguer la réflexion stratégique. Il souligne que, contrairement à une idée reçue, déléguer l’écriture du code à l’IA ne signifie pas renoncer à la maîtrise du processus, à condition d’adopter une approche structurée.

L’auteur détaille trois concepts clés : le modèle (le LLM utilisé), le contexte (les informations fournies pour guider la réponse) et le harness (l’environnement technique qui encadre l’IA). Il insiste sur l’importance de limiter le contexte, car un excès d’informations dégrade la qualité des réponses, et sur le rôle du harness, qui agit comme un intermédiaire entre le modèle et les outils concrets (lecture/écriture de fichiers, exécution de commandes).

Enfin, Lanz rappelle que l’IA reste un outil prédictif, incapable d’agir sans ces extensions techniques. Sa méthode vise à optimiser l’interaction avec ces outils pour en tirer le meilleur parti tout en conservant le contrôle sur les décisions techniques.

L’article présente la création d’un assistant de code review basé sur l’IA, spécialisé dans le projet Symfony, en combinant PHP, Ollama et Qdrant. L’idée centrale est d’exploiter les milliers de retours historiques de la communauté Symfony pour générer des critiques de code plus pertinentes et adaptées, plutôt que des conseils génériques. L’auteur a développé un système utilisant une recherche sémantique (RAG) pour analyser les pull requests et les commentaires des contributeurs expérimentés, comme stof ou Nicolas Grekas, afin d’offrir des retours ciblés.

L’outil, nommé Symfony Reviewer MCP, repose sur une architecture en deux parties : un pipeline de génération de données vectorielles (à partir des archives GitHub) et un serveur MCP exposant ces données via une interface standardisée. L’indexation a été réalisée localement avec Ollama (modèle embeddinggemma-300m) et Qdrant, sans recourir à un GPU, au prix d’un temps de traitement long mais économiquement acceptable. L’application est développée en PHP 8.5 et Symfony 8.1, démontrant une approche pragmatique pour intégrer l’IA dans des workflows de développement existants.

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.

L’article explore l’impact de l’IA générative sur le métier de développeur, soulignant que son adoption massive est désormais incontournable sur le marché du travail. L’auteur, Stéphane Philippart, explique que refuser d’utiliser ces outils peut devenir un frein professionnel, tant pour les recherches d’emploi que dans les entreprises, où la pression pour livrer plus vite est forte. Il compare cette évolution à d’autres révolutions technologiques passées, comme l’arrivée du Web ou des smartphones, où l’adaptation était nécessaire pour rester compétitif.

Plutôt que de parler de déclin, il insiste sur la nécessité de s’adapter, en transformant les pratiques sans pour autant renoncer à la passion ou à la créativité. L’IA ne supprime pas le métier, mais le fait évoluer, comme l’automatisation a pu le faire pour d’autres professions, comme les ébénistes. Certains peuvent choisir de rester sur des méthodes traditionnelles, mais cela devient un choix assumé plutôt qu’une obligation.

Enfin, l’auteur nuance son propos en reconnaissant que l’IA pourrait réduire l’espace dédié à la créativité pure, mais estime que le métier reste viable à condition de se réinventer. Il conclut que l’enjeu n’est pas de lutter contre cette tendance, mais de l’intégrer pour en tirer parti, tout en préservant l’essence du développement.

Domenic Denicola partage son environnement de développement agentique optimisé pour l’IA, conçu pour permettre une collaboration fluide avec des modèles avancés comme Claude Code. Son objectif principal est de pouvoir corriger des bugs en production directement depuis un smartphone, même en déplacement, tout en garantissant une continuité de travail entre différents appareils. Pour cela, il utilise une machine virtuelle Linux dédiée et toujours active, couplée à Tailscale pour un accès sécurisé et transparent, ainsi que des outils comme Portless et chezmoi pour centraliser les configurations et préserver l’état des projets.

Son approche repose sur une VM Linux, indispensable pour éviter les limitations des environnements Windows, souvent incompatibles avec les outils en ligne de commande utilisés par les agents. Il insiste sur la nécessité de préserver les sessions, l’état des fichiers et les configurations globales, tout en permettant le lancement de serveurs de développement accessibles uniquement en local ou via HTTPS. La gestion des permissions est simplifiée pour minimiser les interruptions, autorisant même des modes de fonctionnement autonomes pour des tâches parallèles.

Chez Elao, l’article souligne le manque de collaboration entre designers et développeurs, souvent dû à des formations cloisonnées et à des outils incompatibles. Les designers, formés pour l’expérience utilisateur, négligent parfois la dimension technique des maquettes, tandis que les développeurs peinent à interpréter les livrables visuels. Pour y remédier, l’entreprise a intégré Storybook comme référence partagée, facilitant la communication et réduisant les itérations de correction. Cette approche vise à aligner les processus et à accélérer le développement des projets.

L’auteur, développeur de Writizzy, explore les dilemmes liés à l’ouverture du code de son produit, malgré son attachement à l’open source et ses avantages (contribution à l’écosystème, transparence, visibilité accrue). Il souligne que l’open source peut servir de levier marketing et favoriser une distribution plus large, comme en témoignent des plateformes comme Ghost, WordPress ou GitLab, où des acteurs économiques profitent de l’écosystème sans toujours contribuer en retour.

Cependant, il craint que Writizzy, s’il devient open source, ne subisse une exploitation commerciale disproportionnée par des tiers, captant une partie des revenus générés sans participer à la maintenance ou à l’amélioration du projet. Cette crainte s’appuie sur des exemples comme Substack ou Beehiiv, dont les modèles économiques reposent sur des logiciels non open source, tandis que Ghost, open source, génère une économie parallèle estimée entre 15 et 25 millions de dollars, dont une partie échappe à l’éditeur.

Face à ce dilemme entre éthique et viabilité économique, l’auteur envisage deux options : adopter une licence restrictive limitant l’usage commercial ou accepter cette dynamique sans garantie de retour sur investissement. Il souligne que Ghost, en tant qu’organisation sans actionnaires, peut se permettre cette approche, mais que pour un projet personnel, la question reste ouverte.

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.

L’article Why write code in 2026 défend l’idée que, malgré l’essor des agents IA et des outils automatisés, écrire du code reste essentiel pour les développeurs. L’auteur souligne que coder permet une compréhension directe de l’architecture logicielle, bien au-delà d’une simple lecture passive ou d’une supervision d’agents. Cette pratique favorise une meilleure attention aux détails, une réduction des erreurs et une amélioration de la qualité du code, évitant ainsi l’accumulation de "slop" (code bâclé) qui nuit aussi bien aux humains qu’aux agents.

L’auteur reconnaît que la plupart de son code est généré par IA, mais insiste sur le fait que l’écriture manuelle offre une expérience immersive et une maîtrise impossible à obtenir autrement. Il compare les agents IA à des stagiaires fraîchement embauchés, capables de suivre des instructions mais souvent limités par des descriptions imprécises ou des environnements mal structurés. Écrire du code permet de penser de manière algorithmique et de calibrer la précision nécessaire, contrairement à l’anglais, trop vague pour exprimer des computations complexes.

Enfin, l’article critique l’idée que les agents IA devraient être traités comme des compilateurs, ce qui justifierait la production de code médiocre. Au contraire, les développeurs doivent rester actifs dans le processus pour garantir la robustesse et la cohérence du logiciel. L’auteur cite l’exemple d’un choix d’architecture (local storage) qui, bien que fonctionnel, illustre comment une décision prise par un humain peut avoir des conséquences durables, soulignant l’importance d’une réflexion approfondie dans le développement.

Cette page explique le processus de correction des vulnérabilités de sécurité dans Symfony UX, depuis la détection jusqu’à la publication. L’auteur, membre de l’équipe Symfony UX Core Team, détaille les étapes clés : développement des correctifs dans un dépôt privé pour éviter les exploits anticipés, triage des rapports pour distinguer les vulnérabilités critiques (CVE) des améliorations de sécurité mineures, et création de correctifs ciblant d’abord les branches maintenues en mode security-fixes-only.

Deux exemples concrets illustrent ce processus : CVE-2026-55877, une faille XSS dans symfony/ux-icons due à l’injection de SVG non échappés, corrigée via une usine centralisée de nettoyage des éléments dangereux ; et CVE-2026-55878, une traversée de chemin dans symfony/ux-toolkit permettant l’accès à des fichiers arbitraires, résolue par un rejet explicite des chemins contenant ...

L’auteur souligne l’utilisation d’outils automatisés (comme un assistant IA pour analyser les rapports ou générer des advisories GitHub) pour accélérer les tâches répétitives, tout en insistant sur la nécessité d’un examen humain pour valider les correctifs et les scores CVSS avant publication.