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.

CodeGraph est un outil open source conçu pour optimiser l'analyse de code par des agents IA comme Claude Code ou Cursor. Il génère un graphe de connaissances pré-indexé (symboles, relations, appels de fonctions) permettant aux agents d'interroger instantanément la structure du code plutôt que de scanner les fichiers, réduisant ainsi les coûts et les appels d'outils.

L'installation est simplifiée avec des scripts dédiés pour macOS/Linux et Windows, ou via npm. CodeGraph s'intègre automatiquement aux agents configurés et fonctionne localement sans dépendances externes, tout en restant compatible avec des projets existants.

Les benchmarks sur sept bases de code réelles montrent une économie moyenne de 35 % des coûts, 59 % de tokens en moins et un gain de vitesse de 49 %, grâce à l'indexation sémantique qui évite les recherches coûteuses.

Ce billet explique comment l'auteur utilise FrankenPHP en développement, mettant en avant son mode worker qui maintient une instance PHP active pour éviter les recharges coûteuses à chaque requête. Trois mécanismes de hot reload sont combinés : --watch pour les fichiers statiques, tailwind:build --watch pour les styles, et le worker lui-même, permettant un rechargement instantané du navigateur sans configuration complexe. L'article souligne aussi l'intégration d'un certificat HTTPS auto-signé, accessible via https://localhost:8443 sans modification du fichier hosts.

L'auteur détaille l'architecture de FrankenPHP, un binaire Go combinant le serveur Caddy et PHP-FPM, simplifiant l'infrastructure en un seul processus au lieu de Nginx + PHP-FPM. Le mode worker évite le redémarrage complet de l'application à chaque requête, améliorant les performances en développement comme en production. Le même fichier de configuration est utilisé pour les deux environnements, avec des variables d'environnement ajustant les comportements selon le contexte Docker.

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.

Ce billet explique comment exécuter localement des grands modèles de langage (LLM) gratuitement avec Ollama, un outil simplifiant leur déploiement. L’auteur détaille l’installation via Docker, le téléchargement d’un modèle et son intégration dans une application Symfony grâce au Symfony AI Bundle, tout en évitant les pièges courants. L’objectif est de montrer qu’il est possible d’utiliser des LLM sans dépendre de fournisseurs externes payants, tout en maîtrisant les coûts et la confidentialité des données.

Ollama agit comme un runtime local, optimisant les modèles pour le matériel et exposant une API HTTP locale. Ses avantages principaux sont l’absence de coûts marginaux (seule l’électricité est consommée), la confidentialité des données (pas de transmission externe) et la portabilité (le même setup fonctionne en développement comme en production). Cependant, la qualité des réponses reste inférieure à celle des modèles cloud comme GPT-4, surtout pour des tâches complexes nécessitant une prose élaborée.

Le guide s’adresse aux développeurs PHP/Symfony et se concentre sur des cas d’usage concrets comme la génération de métadonnées SEO ou l’extraction de données structurées. Il mentionne aussi les prérequis matériels, soulignant que des modèles de plusieurs milliards de paramètres exigent une infrastructure adaptée, sans entrer dans des comparatifs techniques.

L’auteur, développeur depuis plus d’une décennie, défend l’idée que se former à un nouveau langage de programmation reste essentiel à l’ère de l’IA, malgré ses capacités croissantes à générer du code. Il souligne que l’utilisation excessive de l’IA risque d’éroder les compétences fondamentales en programmation, comme la modélisation des problèmes ou l’évaluation critique du code produit. Apprendre un nouveau langage permet de préserver ces bases tout en découvrant d’autres philosophies et pratiques, enrichissant ainsi sa vision du développement.

Pour cette année, il a choisi C#, un langage en constante évolution mais souvent associé à tort à l’écosystème Microsoft. Son objectif est de dépasser les préjugés et d’explorer la culture "craft" de sa communauté, qu’il juge dynamique et inspirante. Cette démarche reflète sa volonté de maintenir un esprit critique face aux outils automatisés, en s’appuyant sur une maîtrise solide des concepts fondamentaux.

L’article met en lumière l’importance de l’apprentissage continu pour rester pertinent dans un domaine en mutation rapide, où l’IA devient un allié plutôt qu’un substitut à l’expertise humaine.

L’article souligne l’importance pour les développeurs de tester eux-mêmes leurs fonctionnalités avant livraison, plutôt que de se reposer uniquement sur des tests automatisés ou des équipes QA. Il illustre ce point par un exemple concret où une page fonctionnait techniquement mais était inaccessible aux utilisateurs standards, révélant un problème de permissions non détecté par les tests. L’auteur insiste sur le fait que les tests automatisés valident le code, mais c’est l’usage réel du produit qui en valide la pertinence.

L’auteur met en lumière l’effort supplémentaire que représente ce test manuel, nécessitant de se mettre à la place de l’utilisateur, d’explorer des parcours complets et d’anticiper des scénarios inattendus. Il critique la tendance à déléguer ces vérifications à d’autres équipes, ce qui crée une distance nuisible entre le développeur et le produit final, et retarde la détection de problèmes évidents.

Enfin, l’article défend l’idée que le travail d’un développeur ne s’arrête pas à l’écriture du code : il doit s’assurer que ce qu’il livre fonctionne réellement pour le client. Tester soi-même permet d’améliorer l’empathie produit, d’accélérer les revues de code et de réduire les coûts liés aux bugs visibles plus tard dans le cycle de développement. Les tests automatisés restent essentiels, mais ne remplacent pas une validation fonctionnelle manuelle.

L’auteur partage son expérience avec l’éditeur Zed, qu’il utilise depuis plus d’un an en remplacement de Sublime Text, saluant sa légèreté et sa polyvalence multiplateforme. Il critique vivement VS Code pour son manque d’optimisation, sa télémétrie imposée et ses licences ambiguës, préférant Zed, écrit en Rust, pour son approche plus moderne et ses fonctionnalités avancées comme le support des LSP, le développement à distance et un agent IA intégré.

Zed repose sur un écosystème d’extensions pour personnaliser l’expérience, gérées via un gestionnaire intégré, bien que certaines dépendances (comme les Language Servers) nécessitent une installation séparée. L’auteur souligne la maturité rapide de l’éditeur, avec des mises à jour hebdomadaires et des versions disponibles sur Linux, macOS et Windows, malgré sa relative jeunesse.

Enfin, il aborde l’intégration avec WSL pour un développement distant fluide, tout en évitant de lister ses extensions personnelles, préférant adapter ses outils à ses besoins spécifiques plutôt que de reproduire des configurations existantes.

L’article de WeScale présente l’évolution naturelle des métiers de développement et d’exploitation (Dev & Ops) vers une approche Augmented Dev & Ops, intégrant l’IA comme assistant plutôt que comme remplaçant. L’idée centrale repose sur une délégation progressive des tâches à l’IA selon leur position dans le cycle de travail, tout en maintenant l’humain dans la boucle décisionnelle. Par exemple, en phase de spécification, l’IA questionne et propose des pistes, mais la décision finale reste humaine, tandis que dans la réalisation du code, elle prend en charge la production sous supervision.

Le modèle distingue deux cycles : le développement, structuré en quatre étapes (Spécifier, Concevoir, Réaliser, Valider), et les opérations, en continu (Déployer, Observer, Remédier, Optimiser). L’IA automatise davantage les tâches en aval (comme la génération de code ou la détection d’anomalies), tandis que l’humain conserve le contrôle sur les choix stratégiques et les arbitrages complexes. La frontière entre délégation et intervention humaine est clairement définie pour éviter les risques liés aux décisions automatisées.

Enfin, l’article souligne que cette transformation repose sur une adoption massive de l’IA par les consultants (93 % l’utilisent quotidiennement) et une refonte des processus pour tirer parti de ses capacités. L’enjeu n’est pas de savoir si l’IA remplacera les professionnels, mais comment l’intégrer efficacement pour améliorer la productivité et la qualité, tout en préservant la responsabilité humaine.

L’auteur partage son workflow structuré pour intégrer l’IA dans le développement logiciel tout en maintenant la clarté et la maintenabilité du code. L’idée centrale est que le travail réel commence avant l’écriture du code, en privilégiant la réflexion écrite plutôt que l’implémentation directe.

Le processus se décompose en trois étapes : d’abord, un plan informel en langage naturel pour formaliser la pensée, puis la génération d’un PRD (Product Requirements Document) via un entretien structuré avec l’IA pour identifier les failles du plan initial. Enfin, la transformation du PRD en issues techniques, organisées en tranches verticales pour garantir une intégration complète et vérifiable.

L’objectif est de forcer une réflexion approfondie en amont, où l’IA sert à tester et affiner les hypothèses plutôt qu’à remplacer le raisonnement humain, évitant ainsi des solutions techniques floues ou mal adaptées.

L’article explique pourquoi le vibe coding (développement basé uniquement sur l’intuition et les prompts sans revue de code) a échoué en production, malgré son engouement initial. Andrej Karpathy, son inventeur, a récemment remplacé ce concept par l’agentic engineering : une approche où l’IA génère le code sous supervision humaine stricte, avec une responsabilité claire sur l’architecture, la qualité et la sécurité. L’auteur souligne que le problème n’était pas l’outil, mais l’absence de discipline, conduisant à du code non maintenable, des failles de sécurité et une dette cognitive accrue. Une lecture essentielle pour comprendre l’évolution des pratiques de développement assisté par IA en 2026.

Simon Willison partage ses réflexions après son passage dans le podcast de Lenny Rachitsky, abordant l’impact de l’IA sur l’ingénierie logicielle. Il évoque un point d’inflexion en novembre 2025, où les modèles comme GPT-5.1 et Claude Opus 4.5 ont franchi un seuil : leurs sorties de code sont désormais fiables sans besoin de relecture constante. Willison souligne que les développeurs servent de sonde pour les autres métiers intellectuels, confrontés aux mêmes défis (hallucinations, évaluation de la qualité). Il aborde aussi l’essor des coding agents (automatisation des tests), la productivité sur mobile, et les risques de la "vibe coding" (développement sans rigueur). Un débat riche sur l’avenir du travail assisté par IA.

Superpowers est un framework et une méthodologie de développement logiciel conçu pour les agents IA, basé sur des "compétences" modulables et des instructions initiales. Il guide les agents dans la création de logiciels en suivant une approche structurée : analyse des besoins, validation du design, planification d'implémentation (TDD, YAGNI, DRY), puis développement autonome par sous-agents. Le projet met l'accent sur l'autonomie et la qualité du code, avec des mises à jour régulières (ex. v5.0.7 avec support Copilot CLI). Open source sous licence MIT, il est disponible sur GitHub.

GitButler est un outil de gestion de modifications Git optimisé pour les workflows de développement modernes, notamment avec l'IA. Il permet de travailler sur plusieurs branches en parallèle ou empilées, offre un "undo" illimité, des intégrations d'agents IA pour automatiser les commits/PR, et une édition simplifiée des commits. Disponible en version desktop (Linux) et CLI, il se distingue par son interface intuitive et ses fonctionnalités collaboratives (intégration GitHub/GitLab, orchestration d'agents IA comme Claude). Les retours utilisateurs soulignent son efficacité pour éviter les maux de tête liés aux branches et aux workflows complexes.

L'auteur explique pourquoi Ruby on Rails est devenu, presque par hasard, le framework parfait pour travailler avec des LLM (Large Language Models). Grâce à ses conventions strictes (Convention over Configuration), sa structure prévisible et son langage Ruby proche du naturel, Rails permet aux IA de comprendre et modifier le code sans instructions détaillées. Un exemple concret montre comment un LLM a ajouté un champ à un modèle Rails en quelques minutes, simplement en suivant les conventions connues. L'auteur souligne aussi l'efficacité de Rails pour l'IA : centralisation du schéma de données dans schema.rb, code déclaratif et dense, et Hotwire pour une interactivité côté serveur simplifiée. En résumé, Rails amplifie l'expertise collective des développeurs tout en réduisant les risques d'erreurs pour les IA.

Portless est un outil open-source de Vercel Labs qui simplifie le développement local en remplaçant les numéros de port par des URLs stables et nommées (ex: https://myapp.localhost au lieu de http://localhost:3000). Il gère automatiquement les sous-domaines, les worktrees Git et les frameworks (Next.js, Vite, etc.), avec support HTTPS et TLD personnalisables (.localhost par défaut, .test recommandé). Installation globale via npm install -g portless, puis utilisation directe dans les scripts npm ("dev": "portless run next dev"). Idéal pour éviter les conflits de ports et fluidifier le workflow.

Cet article de Towards Data Science explore le problème de la "boîte noire" dans le code généré par l'IA. Bien que l'IA améliore initialement la productivité des équipes de développement, le code généré devient rapidement difficile à maintenir en raison de son manque de structure. Les principaux problèmes incluent la tendance à tout regrouper dans un seul module, les dépendances circulaires et implicites, l'absence de contrats explicites et une documentation qui explique l'implémentation plutôt que l'utilisation. Un exemple concret illustre comment une génération non structurée peut créer un système de notifications monolithique difficile à modifier, contrairement à une approche structurée qui décompose le système en composants indépendants. L'article souligne que le problème n'est pas l'IA en soi, mais plutôt l'architecture résultante.

Le Model Context Protocol (MCP) est un standard visant à intégrer des outils et scripts existants directement dans les IDE pour les agents IA. Actuellement, ces agents comprennent le code mais ne peuvent pas exécuter des actions réelles, souvent situées en dehors de l'IDE. MCP propose une solution en exposant ces capacités (CLI, API, services internes) via un contrat structuré, permettant aux agents de les utiliser sans nécessiter de plugins spécifiques. Contrairement aux API REST classiques, MCP standardise les actions et permet une découverte dynamique des capacités, facilitant ainsi l'orchestration par les agents IA.

Ce billet explore les implications de l'augmentation de la vitesse de codage, notamment grâce à l'IA, sur le métier de développeur. L'auteur, un entrepreneur technique, partage son expérience personnelle où le gain de temps lui permet de se concentrer sur la stratégie et l'amélioration du produit plutôt que sur la simple production de code. Il souligne que l'impact varie selon les contextes, comme les grandes entreprises ou les freelances, et que le gain de temps n'est pas toujours évident, comme le montre une étude récente. L'idée centrale est de se demander à quoi sert ce temps gagné et comment il peut être utilisé pour améliorer la qualité du produit et la réflexion stratégique.

Ce billet de blog explore les limites des grands modèles de langage (LLM) en matière de génération de code correct, en se concentrant sur un exemple concret : une réécriture en Rust d'une base de données SQLite générée par un LLM. Bien que le code compilé semble fonctionner et passe les tests, il s'avère être environ 20 000 fois plus lent que l'original pour des opérations de base. L'auteur souligne que les LLM optimisent pour la plausibilité plutôt que pour la correction, et souligne l'importance de définir des critères d'acceptation clairs avant de générer du code. L'article inclut des benchmarks détaillés et une analyse du code pour illustrer ces problèmes, tout en reconnaissant les avantages des LLM pour accélérer le développement d'idées.