Ross Wintle explore l’idée que le logiciel peut être « terminé », en proposant une définition simple : un logiciel est fini lorsqu’il est fonctionnellement complet et que rien ne doit y être ajouté, même si des évolutions restent possibles. Il souligne que des changements externes (matériel, plateformes, API, outils de build) peuvent rendre un logiciel obsolète, mais que cela ne dépend pas toujours des développeurs. Plutôt que de viser absolument la « finition », il invite à réfléchir aux leçons que cette approche peut apporter, comme la valeur de la stabilité et de la maintenance contrôlée. Il illustre son propos avec l’exemple du Gameboy, dont le logiciel embarqué fonctionne toujours des décennies plus tard, et rappelle que beaucoup d’entreprises reposent sur des mises à jour continues plutôt que sur des produits figés. Une réflexion stimulante sur la durabilité et les limites du contrôle en développement logiciel.
Dans cet article un peu décousu, l'auteur expose ses réflexions sur l'IA dans le développement. Ayant connu l'explosion de la bulle des années 2000, il essaye de relativiser un peu ce que nous vivons ces derniers temps : beaucoup d'emballement. Il poursuit en rappelant que certains devs sont avant tout des passionnés, même si le monde du travail tend à rendre le dev moins excitant en cherchant à tout prix la rentabilité. En particulier, l'automatisation permise par l'IA peut faire gagner du temps, mais gomme l'apprentissage de la résolution de problème par soi-même. Il rappelle aussi qu'il y a 10 ans, la grande mode était de délocaliser le développement à l'étranger... et qu'on en est bien revenus ! Il finit par conclure que l'IA est un outil intéressant pour les profils comme le sien : senior et qui sait ce qu'il fait... mais qu'il demande à voir ce que ça donnera avec des juniors qui n'auront que ça.
Devstral est un modèle LLM agentique open source développé par Mistral AI, spécialement optimisé pour les tâches de développement logiciel. Il se distingue par sa capacité à résoudre des problèmes complexes de programmation, comme la navigation dans de grandes bases de code, la modification de plusieurs fichiers et la correction de bugs, en agissant de manière autonome. Avec seulement 24 milliards de paramètres, il surpasse certains modèles fermés et open source plus volumineux sur le benchmark SWE-Bench Verified, tout en restant léger et utilisable en local sur des machines avec 32 Go de RAM ou une RTX 4090. Sous licence Apache 2.0, il s’intègre facilement à des frameworks comme OpenHands ou SWE-Agent.
L’article détaille son installation (via Ollama, plugins IDE ou OpenHands) et ses cas d’usage : génération de documentation, refactoring de code, création de projets structurés (ex. Spring Boot en DDD), ou amélioration de projets existants. Bien que performant, son efficacité dépend de la qualité des prompts et de l’environnement fourni. Devstral représente une solution prometteuse pour les développeurs souhaitant un assistant local, sécurisé et puissant, malgré quelques limites comme la génération occasionnelle de code inutile ou trop complexe. Une version "Large" est annoncée pour l’avenir.
L’auteur, développeur expérimenté, partage son retour sur l’utilisation de la GenAI (Claude Code) au quotidien. Il distingue trois usages principaux : le "vibe coding" (génération complète de scripts ou interfaces simples, gain de temps énorme), le "mode chirurgien" (résolution ciblée de bugs complexes ou manipulation de SDK obscurs), et l’assistance pour du code de production (génération de couches techniques répétitives, reviews, agents automatisés). Selon lui, la GenAI ne remplace pas les développeurs — elle libère du temps pour se concentrer sur la réflexion architecturale, l’intégration système et les bonnes pratiques, domaines où l’expertise humaine reste indispensable. Un outil à adopter pour booster sa productivité, mais sans illusions sur la disparition du métier.
L'auteur compare le développement logiciel à la création d’un mandala : un travail minutieux, parfois éphémère, où l’essentiel réside dans le processus plutôt que dans le résultat final. Comme les moines bouddhistes qui effacent leurs mandalas de sable après des jours de travail, les développeurs voient parfois leurs fonctionnalités abandonnées ou modifiées, non par manque de qualité, mais parce que les besoins évoluent. L’article souligne que la valeur du code ne se limite pas à ce qui est déployé, mais aussi à l’apprentissage, aux échanges en équipe et à la compréhension des besoins. Développer, c’est accepter l’impermanence tout en s’investissant pleinement, car c’est dans la démarche collaborative et la qualité du processus que réside la véritable richesse du métier. Une belle métaphore pour rappeler que coder, c’est aussi savoir lâcher prise.
Wojtek Jurkowlaniec explique comment il maintient un projet de 10 000+ lignes de code en combinant design manuel, documentation vivante (fichiers DESIGN et ARCHITECTURE), et itérations courtes et indépendantes. Le processus repose sur une séparation claire des rôles : l’humain définit la vision et l’architecture, tandis que le LLM génère du code, propose des refactors et accélère l’implémentation, toujours guidé par des documents à jour. Chaque feature est développée par étapes, testée et committée, avec une trace écrite des corrections dans un CODING-GUIDELINES.md pour éviter la dette technique. La clé ? Traiter le LLM comme un outil de transformation de texte, pas comme un co-développeur, et garder le code toujours dans un état fonctionnel. L’auteur insiste sur l’importance de documenter systématiquement et de refactorer régulièrement pour éviter l’accumulation de chaos, tout en limitant le contexte fourni au LLM pour éviter les hallucinations. Une méthode qui privilégie la consistance à la vitesse, et qui permet de scalabiliser l’usage des LLM même sur des codebases complexes.
Pour intercepter le trafic réseau d’une application Android, deux approches principales existent : l’inspection via Android Studio (réservée aux apps en développement) et l’utilisation d’un proxy HTTPS (comme Proxyman) pour les apps tierces. En développement, Android Studio exploite le flag android:debuggable="true" et le protocole JDWP pour rediriger les flux réseau via ADB, permettant d’analyser les requêtes HTTP(S) sans déchiffrement direct, mais en interceptant les objets mémoire des bibliothèques comme OkHttp. Pour les apps en production, non debuggables, la solution passe par un proxy HTTPS (ex : Proxyman) : il faut rediriger le trafic de l’émulateur/device vers le proxy, installer son certificat root dans le magasin système (nécessitant souvent un accès root ou un émulateur non-production), puis activer le déchiffrement HTTPS pour les domaines cibles. Cette méthode contourne les restrictions d’Android 7+ sur les certificats utilisateur, mais exige des manipulations avancées (injection de certificats via adb, configuration de SELinux, etc.). L’article détaille aussi le rôle clé de Zygote dans l’initialisation des apps et propose des scripts pour automatiser l’installation des certificats. Une alternative comme Frida est évoquée pour des cas plus complexes.
Cet article explore des techniques avancées pour personnaliser les Dev Containers, allant au-delà de la simple configuration de base. L’auteur illustre comment installer un outil comme SliDesk via différentes méthodes : en utilisant postCreateCommand (simple mais répétitif), en créant une feature (réutilisable et versionnable, idéale pour partager des configurations), ou en construisant une image Docker custom (pour un environnement sur mesure et optimisé). Il aborde aussi l’utilisation de Docker in Docker pour construire des images directement depuis le conteneur, et de Docker Compose pour gérer des environnements complexes incluant des bases de données ou d’autres services. Enfin, il présente les templates, qui permettent de pré-configurer des Dev Containers pour des projets similaires, évitant ainsi la duplication de code. Une lecture essentielle pour qui veut industrialiser et standardiser ses environnements de développement avec flexibilité et efficacité !
L’article relate l’expérience d’un ingénieur utilisant Claude Code pour automatiser des tâches de développement (refactoring, correction de bugs, écriture de tests). Si l’outil excelle pour des corrections ponctuelles, il génère souvent des PRs volumineuses et illisibles, rendant la revue de code difficile. La solution trouvée : apprendre à Claude à structurer son travail en "stacked PRs" (séries de petites PRs ciblées et indépendantes), comme le feraient des humains expérimentés. En guidant l’IA avec des instructions précises et en utilisant l’outil GT MCP de Graphite, l’auteur parvient à obtenir des PRs claires, testables et faciles à relire. Résultat : une intégration plus fluide de l’IA dans le workflow, permettant de construire des fonctionnalités complètes, de corriger des bugs complexes et d’ajouter des tests, tout en gardant un code maintenable et collaboratif.
L’IA est un outil puissant pour accélérer et optimiser le développement, pas pour remplacer les devs. L’article illustre comment intégrer l’IA à chaque étape d’un projet (ex. : un site de location de voitures) : planification (génération de briefs et wireframes en quelques minutes), design (création d’interfaces et de code HTML/CSS via des outils comme v0.dev), boilerplate (conversion rapide en React/TypeScript avec des prompts précis), et amélioration (refactoring collaboratif pour rendre le code scalable et propre). L’IA automatise les tâches répétitives (recherche, design, code basique), mais c’est au développeur de superviser, architecturer et corriger les imperfections (logique métier, réutilisabilité). L’enjeu ? Travailler plus intelligemment, en utilisant l’IA comme un "pair programmer" pour se concentrer sur les défis complexes (architecture, UX, performance). À condition de rester critique : l’IA génère du code, mais c’est à vous d’en garantir la qualité et l’éthique. "Un dev qui maîtrise l’IA aura toujours un avantage."
L'auteur partage son expérience approfondie de l'utilisation des Large Language Models (LLMs) pour le codage. Il souligne que l'utilisation des LLMs pour le codage est complexe et nécessite de fixer des attentes raisonnables. Il insiste sur l'importance de comprendre les dates de coupure d'entraînement des modèles et de gérer efficacement le contexte. Il partage des conseils pratiques tels que demander des options aux LLMs, fournir des instructions détaillées et itérer sur le code généré. Il discute également des avantages d'utiliser des outils capables d'exécuter et de tester le code, et introduit le concept de "vibe-coding" comme moyen d'apprentissage et d'expérimentation avec les LLMs. Il conclut que les LLMs accélèrent considérablement le développement et amplifient l'expertise existante, facilitant ainsi la mise en œuvre des idées et l'apprentissage de nouvelles choses.
L'article traite d'un phénomène courant dans le développement logiciel où des outils complexes ou peu familiers ne sont pas utilisés de novo, mais plutôt copiés et ajustés à partir d'exemples précédents. Ce phénomène, qu'il baptise « l'effet Makefile », est observé chez les ingénieurs de tous niveaux d'expérience. Par exemple, au lieu d'écrire un nouveau Makefile, un ingénieur copie souvent un Makefile existant d'un projet antérieur et le modifie jusqu'à ce qu'il fonctionne dans le nouveau contexte. Bien que cela puisse sembler efficace à court terme, cela indique que l'outil est trop compliqué ou ennuyeux à utiliser de zéro. Ce phénomène est également observé dans d'autres domaines comme les configurations CI/CD et les systèmes de build. L'auteur souligne que les outils qui encouragent ce comportement peuvent avoir des diagnostics ou un support de débogage moins qu'idéaux, décourager l'apprentissage approfondi, et être plus difficiles à utiliser de manière sécurisée. Il suggère que les concepteurs d'outils devraient viser à minimiser cet effet en rendant les outils plus intuitifs et faciles à utiliser dès le départ.
Une astuce géniale :)
L'article explore diverses stratégies pour réduire les coûts associés à l'utilisation des Coding Agents tout en améliorant leurs performances. Il présente plusieurs options, allant des modèles gratuits comme OpenRouter et Gemini Flash 2.0, aux abonnements avec plans gratuits, en passant par l'hébergement de modèles open-source. L'article souligne l'importance de choisir le bon modèle en fonction des tâches spécifiques pour optimiser les coûts et les performances. Il met également en avant des techniques comme l'optimisation du contexte, l'utilisation de fichiers de configuration et de Memory Bank pour améliorer l'efficacité des agents. Enfin, il insiste sur la nécessité de rester informé des évolutions rapides dans ce domaine pour maintenir la compétitivité.
L'article explore les défis et les considérations pour sélectionner le bon modèle de Coding Agent afin d'optimiser les projets de développement. Il souligne que bien que les Coding Agents accélèrent les projets, il est crucial de comprendre leurs implications sur la qualité et les coûts. L'auteur discute des différents modèles disponibles, comme Claude Sonnet 3.7 et Deepseek R1, en mettant en lumière leurs performances et leurs limitations respectives. Il insiste sur l'importance de métriques telles que le nombre de tokens, la taille de la fenêtre de contexte, le coût par token, et la latence pour faire un choix éclairé. Enfin, il mentionne l'importance de la communauté et des "vibes" dans la sélection d'un modèle, tout en soulignant que la maîtrise des outils associés est essentielle pour une utilisation optimale des Coding Agents.
L'article explore comment intégrer l'IA dans le développement logiciel tout en maintenant des normes de qualité élevées. Il souligne que bien que l'IA puisse générer du code rapidement, la qualité, la cohérence architecturale et la maintenance à long terme restent des défis.
L'article propose d'utiliser des tests comme contrats pour guider l'IA, en s'inspirant du Test-Driven Development (TDD) et de l'architecture hexagonale. Les tests fournissent un langage formel et sans ambiguïté, permettant à l'IA de mieux comprendre les attentes. En intégrant ces tests dans le processus de développement, l'IA peut itérer sur le code jusqu'à ce que tous les tests soient réussis, assurant ainsi une meilleure qualité du produit final.
L'article conclut que l'expertise humaine reste cruciale pour utiliser efficacement l'IA dans le développement logiciel, notamment en matière de principes algorithmiques et de gestion de projet.
Zara liste ses bonnes pratiques pour le développement
Takeout est un outil en ligne de commande qui permet de lancer des petits conteneurs Docker pour chaque dépendance de l'environnement de développement. Il s'installait avec composer (PHP) mais il s'installe à présent avec Docker
Tout est dans le titre