GitLab montre comment utiliser les capacités d’IA de Codex directement dans les workflows GitLab pour accélérer la correction de bugs, en s’appuyant sur les issues, les merge requests et le contexte du projet afin de proposer des correctifs plus pertinents et traçables. L’article insiste sur l’intérêt d’intégrer l’IA au cycle DevSecOps complet plutôt que de l’utiliser comme simple assistant de génération de code, avec des validations humaines et des pipelines CI/CD pour sécuriser les changements proposés. Il souligne aussi que les agents IA peuvent automatiser des tâches répétitives comme la création de correctifs ou l’analyse de vulnérabilités, tout en laissant le contrôle final aux développeurs.

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.

Le billet retrace la découverte de LoRa et de l’écosystème mesh autour de Meshtastic, en expliquant comment cette technologie permet de créer des réseaux de communication autonomes, peu coûteux et résilients, capables de fonctionner sans Internet ni infrastructure opérateur. L’auteur revient sur l’évolution historique de LoRa, de l’IoT industriel jusqu’aux usages communautaires et survivalistes, notamment après les inondations au Texas en 2025 où des particuliers ont maintenu des communications malgré la pannespe des réseaux classiques. Il détaille ensuite la création de son propre node à base d’ESP32, installé dans un boîtier IP67 pour environ 45 €, avec configuration via Bluetooth et application mobile, puis partage ses premiers retours d’expérience : découverte d’un maillage local très actif avec des nodes détectés jusqu’à 30 km, importance du positionnement extérieur pour améliorer le signal, et possibilités d’extensions futures comme l’ajout de batteries, panneaux solaires ou l’intégration domotique via MQTT.

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 relate son expérience avec une tablette Chuwi Hi10Go sous Linux, où l’écran tactile affichait systématiquement une image inversée à 180°, malgré les rotations physiques. Le problème provenait d’une mauvaise configuration de l’accéléromètre, dont la matrice de transformation était mal interprétée par le système. Après des recherches infructueuses en 2023, il a finalement trouvé une solution en modifiant une règle udev pour corriger l’orientation de l’écran.

La solution consiste à ajouter une règle spécifique dans le fichier /etc/udev/hwdb.d/61-sensor.hwdb afin d’inverser la matrice de l’accéléromètre, puis à mettre à jour la base de données matérielle et relancer udev. Cette manipulation, inspirée d’un dépôt GitHub de systemd, permet de rétablir l’affichage correct de l’écran après un redémarrage.

Cependant, un second problème est apparu : l’écran tactile (un composant Goodix) ne fonctionnait pas correctement, les coordonnées de toucher étant inversées. L’auteur n’a pas encore trouvé de solution définitive pour ce dysfonctionnement, mais son expérience illustre les défis liés à l’utilisation de matériel sous Linux.

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 Teddy Ferdinand souligne que l’intégration tardive de la cybersécurité dans un projet limite ses options à des mesures radicales, comme bloquer la mise en production ou imposer des corrections coûteuses, faute de pouvoir ajuster l’architecture ou les choix techniques en amont. L’auteur explique que cette approche brutale résulte souvent d’un manque de collaboration précoce, où les critères de sécurité ne sont pas définis dès le début, transformant une revue finale en révélateur de problèmes évitables.

Ferdinand illustre que les blocages en fin de projet sont rarement perçus comme des solutions, mais plutôt comme des échecs, car ils surviennent après que les engagements métiers, les budgets et les délais aient été figés. Il insiste sur l’importance d’intégrer la sécurité dès les phases clés, en amont, pour éviter des arbitrages douloureux et des tensions entre équipes projet, métier et management.

Enfin, l’auteur rappelle que la sécurité ne vise pas à freiner les projets, mais à les sécuriser de manière proactive, en clarifiant les règles, les responsabilités et les critères de validation avant que les choix ne deviennent irréversibles.

L’article de Thomas, développeur expérimenté, explore l’impact des outils d’IA comme les LLM sur sa pratique professionnelle et personnelle. Il décrit une perte progressive de motivation pour coder en dehors de son travail, passant d’une activité créative et gratifiante à une tâche de supervision technique, plus rapide mais moins épanouissante. Ce changement subtil, qu’il compare à un musicien délaissant son instrument, touche aussi d’autres développeurs expérimentés, bien que l’IA ait parallèlement démocratisé la programmation pour les non-initiés.

L’auteur souligne l’ironie de cette situation : si les LLM libèrent des profils non techniques en automatisant des tâches complexes, ils transforment le métier de développeur en une activité de contrôle qualité, éloignée de la création pure. Ce basculement, de l’artisanat à la révision, altère la nature même du plaisir lié au codage, centré désormais sur la validation plutôt que sur l’innovation ou la résolution de problèmes.

Enfin, Thomas évoque la nostalgie des moments de découverte et d’apprentissage, illustrant cette perte par des exemples concrets comme le débogage ou l’architecture logicielle. Son témoignage met en lumière un paradoxe générationnel : l’IA, outil de libération pour certains, devient pour d’autres une prison invisible, vidant le métier de sa dimension la plus humaine.

CrowdSec est un outil de défense réseau communautaire qui dépasse les limites de fail2ban en mutualisant les informations entre serveurs. Contrairement à fail2ban, isolé et réactif, CrowdSec permet à un serveur d’apprendre des attaques détectées ailleurs et d’appliquer des bannissements préventifs avant même qu’une IP malveillante n’atteigne son infrastructure. Le système repose sur trois composants : l’Agent, qui analyse les logs locaux et génère des décisions de blocage ; le Bouncer, qui applique ces décisions à différents niveaux (réseau, proxy ou application) ; et la CAPI, une API centrale qui agrège et redistribue les bannissements validés par consensus parmi la communauté.

Le modèle de CrowdSec répond à trois faiblesses majeures de fail2ban : l’isolement des serveurs, l’inefficacité face aux attaques distribuées (botnets utilisant des milliers d’IP) et le coût silencieux des attaques répétées sur les ressources. En partageant les signaux d’attaque et en appliquant des bannissements globaux, CrowdSec réduit la charge sur les infrastructures tout en améliorant la réactivité contre les menaces émergentes.

L’écosystème de CrowdSec permet une intégration flexible, avec des scénarios personnalisables et des mécanismes de consensus pour limiter les faux positifs. Prochainement, un billet détaillera son déploiement concret, illustrant comment cette approche communautaire transforme la sécurité des serveurs publics.

Ce billet du Google Testing Blog souligne l'importance d'ajouter du contexte dans les réponses aux commentaires de revue de code. Plutôt que des réponses minimalistes comme "Fait" ou "Corrigé", il recommande d'expliquer brièvement le pourquoi ou le comment derrière les modifications, surtout lorsque les changements ne sont pas immédiatement évidents.

L'article illustre cette pratique avec des exemples concrets, comme l'ajout de tests pour des cas limites ou l'explication d'un choix de bibliothèque en fonction des contraintes du projet. Ces précisions facilitent la compréhension des reviewers et laissent une trace claire pour les futurs lecteurs du code.

Enfin, il encourage à documenter les décisions prises lors de discussions hors ligne ou les compromis techniques, afin que tous les contributeurs puissent suivre la logique derrière les modifications. Un lien vers le guide de revue de code de Google est proposé pour approfondir ces bonnes pratiques.

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’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.

Ce billet présente le test de CKE (Clever Kubernetes Engine), l'offre Kubernetes managée de Clever Cloud, par l'auteur du blog. L'idée principale est de mettre en avant une solution Vanilla Kubernetes sans verrouillage propriétaire, avec des particularités comme une implémentation serverless de l'API etcd (Materia) et une infrastructure souveraine en France. L'activation de CKE, initialement cachée, nécessite un feature flag via la CLI ou l'onglet Labs de la console Clever Cloud.

L'auteur détaille ensuite la création d'un cluster, possible en ligne de commande ou via un formulaire intuitif, avec des options comme la version Kubernetes, la topologie (Essential, Business, Enterprise) ou le stockage persistant. Les topologies sont expliquées directement dans l'interface, et le déploiement est suivi en temps réel. La tarification et les performances (temps de boot, réseau, sécurité) sont également évoquées, avec des retours sur des bugs rencontrés en phase bêta.

L’auteur explore l’idée que notre époque pourrait déjà être une utopie, malgré une perception générale plus pessimiste. Il souligne un biais culturel où dystopies et mauvaises nouvelles dominent la fiction et l’actualité, car elles génèrent plus de conflits et d’intérêt que les récits utopiques ou positifs. Cette tendance reflète aussi notre nature humaine, naturellement centrée sur les problèmes et les menaces, ce qui nous pousse à ignorer les progrès accomplis.

Scott H. Young cite l’exemple de la "vibecession", où les indicateurs économiques sont bons mais où les gens restent pessimistes. Il attribue ce décalage à la médiatisation excessive des mauvaises nouvelles, qui influence la perception collective, même si les individus évaluent mieux leur situation personnelle. Ce phénomène s’explique par notre préférence évolutive pour les informations menaçantes, qui captent davantage l’attention que les nouvelles positives.

Enfin, l’auteur suggère que ce pessimisme systémique, observable dans les médias comme dans la fiction, pourrait être une caractéristique intrinsèque de l’être humain. Malgré des conditions de vie objectivement améliorées, notre tendance à nous focaliser sur les problèmes et à rechercher des récits conflictuels brouille notre capacité à reconnaître une utopie quand nous y sommes.

L’auteur explique comment les arguments booléens positionnels dans les appels de fonctions rendent le code difficile à lire et à comprendre. Il illustre ce problème avec des exemples comme createUser(user, true, false) où il est impossible de savoir ce que signifient les booléens sans consulter la définition de la fonction. Cette pratique, bien que pratique à écrire, force les développeurs à "décoder" plutôt qu'à lire le code, ce qui ralentit la compréhension.

Pour résoudre ce problème, l’auteur recommande d'utiliser des objets nommés à la place des booléens positionnels, comme createUser(user, { isAdmin: true, sendWelcomeEmail: false }), ce qui rend l'appel de fonction immédiatement compréhensible. Il suggère également de remplacer les booléens par des noms de fonctions plus explicites, comme createAdminUser(user) au lieu de createUser(user, true), lorsque cela est pertinent.

Enfin, l’auteur reconnaît que cette approche n'est pas toujours nécessaire pour des cas simples comme toggleMenu(true), mais devient indispensable dès qu'il y a plusieurs booléens ou que la signification n'est pas évidente. Il conclut que cette pratique améliore significativement la lisibilité du code, surtout dans des projets complexes où la maintenance et la compréhension sont cruciales.

Mise + Krew : gérer ses plugins kubectl de manière déclarative

L’article présente une solution combinant Mise et Krew pour versionner et configurer les plugins kubectl de façon reproductible. Mise, un gestionnaire d’outils en Rust, permet de déclarer les versions des plugins dans un fichier mise.toml, évitant ainsi les problèmes de synchronisation en équipe. Krew, le gestionnaire officiel de plugins kubectl, manque en effet de fonctionnalités de versionnage, ce que Mise comble grâce à son approche déclarative et ses backends multiples (GitHub, Aqua, etc.).

L’auteur explique comment Mise automatise l’activation des versions des outils dès l’entrée dans un répertoire contenant un fichier de configuration, simplifiant la gestion des environnements. Il souligne aussi l’avantage de Mise par rapport à des alternatives comme asdf, notamment pour son intégration avec des outils comme direnv et ses tâches intégrées. La solution proposée permet ainsi de standardiser les environnements Kubernetes en équipe, avec une configuration centralisée et versionnée.

Cette page de CSS-Tricks explore les différentes unités de longueur en CSS, essentielles pour dimensionner les éléments d'une page web. Elle distingue les unités absolues, comme le pixel (px), qui restent constantes quelle que soit la résolution de l'écran, des unités relatives, qui s'adaptent en fonction d'autres facteurs comme la taille de la police ou de l'écran. L'article détaille neuf types d'unités, couvrant les dimensions, l'espace, le temps et même le son, tout en expliquant leur utilité pour contrôler précisément le rendu visuel.

L’auteur revient sur son expérience de développement de k10s, un outil en Go pour surveiller les clusters Kubernetes avec des GPU NVIDIA, entièrement généré par IA via des sessions de vibe-coding. Après des débuts prometteurs où l’IA produisait rapidement des fonctionnalités fonctionnelles, des problèmes structurels majeurs sont apparus, notamment un god object (objet monolithique) de 1 690 lignes dans model.go, rendant le code ingérable et instable. L’auteur souligne que l’IA excelle pour écrire des fonctionnalités, mais échoue à concevoir une architecture cohérente sans intervention humaine.

L’expérience a révélé que le vibe-coding donne une fausse impression de productivité, masquant la dette technique accumulée. L’auteur explique que sans une planification humaine rigoureuse, le projet a rapidement dégénéré en un code spaghetti, malgré des démos impressionnantes. Il conclut que l’humain doit rester maître de l’architecture et imposer des contraintes pour éviter le chaos, même si cela ralentit temporairement le développement.

Le projet est désormais en cours de réécriture depuis zéro, avec une approche plus structurée. L’auteur partage ses leçons, comme l’importance de documenter des directives pour l’IA (AGENTS.md/CLAUDE.md) et de ne pas laisser l’outil dicter la conception. Le code initial est archivé, mais les enseignements tirés valent pour tout développeur utilisant l’IA de manière intensive.