L’auteur partage son expérience pour rendre Raspberry Pi OS utilisable sur un Raspberry Pi 0 W, une machine ancienne mais toujours pratique pour des tâches légères. Il critique l’évolution de l’écosystème Raspberry Pi, désormais axé sur les interfaces desktop et les services cloud, au détriment des utilisateurs avancés. L’installation via Raspberry Pi Imager est jugée peu intuitive, avec des options de téléchargement et de configuration mal optimisées pour les versions Lite.

Le premier démarrage révèle des lenteurs importantes, avec un temps de boot dépassant trois minutes, principalement à cause de services inutiles comme cloud-final.service ou NetworkManager.service. L’auteur souligne que ces services, conçus pour des configurations desktop ou cloud, alourdissent inutilement le système sur un matériel limité comme le Pi 0 W. Il déplore aussi l’absence de mise à jour propre via apt full-upgrade, une pratique autrefois possible.

Enfin, l’article met en lumière un décalage entre les besoins des utilisateurs expérimentés et les choix de la fondation Raspberry Pi, qui privilégie désormais une approche grand public. L’auteur, visiblement agacé, partage ses solutions techniques tout en critiquant ouvertement cette orientation, tout en reconnaissant l’utilité persistante de ces nano-ordinateurs pour des usages spécifiques comme la supervision d’onduleurs.

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’article d’Ugo Dimini explore l’importance de la documentation comme actif stratégique, tout en dénonçant ses dérives. Il critique notamment le "théâtre de la documentation", où des équipes produisent des documents superflus ou obsolètes, comme des docstrings génériques ou des README surchargés, qui alourdissent sans apporter de valeur. L’auteur illustre ce problème avec l’exemple d’un README de 500 lignes inutilisable, car non mis à jour et incapable de permettre le lancement d’un projet.

Il souligne que la documentation pertinente doit se concentrer sur l’asymétrie de la connaissance : expliquer le pourquoi plutôt que le comment, ce que le code ne peut pas transmettre. Une documentation efficace réduit la charge cognitive en clarifiant les intentions, les limites et les décisions stratégiques, comme les problèmes clients résolus ou les choix techniques abandonnés.

Enfin, Dimini propose un cadre de décision basé sur le retour sur investissement (ROI) pour évaluer la documentation. Il distingue notamment la documentation fonctionnelle, qui décrit le problème et la vision à long terme, comme un actif à ROI infini, car elle aligne les équipes techniques, produit et marketing et évite les dérives futures.

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. L’auteur illustre ce point par un exemple où une page fonctionnait techniquement mais était inaccessible aux utilisateurs standards, un problème non détecté par les tests classiques. Il met en avant que les tests automatisés valident le code, mais c’est l’usage réel qui valide le produit, exigeant une approche plus empathique et concrète.

L’auteur explique que tester soi-même le produit permet de détecter des problèmes évidents, d’améliorer la compréhension des parcours utilisateurs et d’accélérer les revues de code. Il critique la tendance à déléguer ces vérifications, ce qui crée une distance entre les développeurs et le produit final. Selon lui, un développeur ne devrait considérer son travail comme terminé qu’une fois la fonctionnalité validée en conditions réelles.

Enfin, il insiste sur le fait que les tests automatisés restent essentiels pour la stabilité, mais ne remplacent pas les tests fonctionnels manuels. Les bugs visibles en production coûtent plus cher à corriger, d’où l’importance d’une boucle de feedback immédiate pour améliorer la qualité et l’expérience utilisateur.

L’article souligne les risques de l’anticipation excessive dans le développement logiciel, où la complexité naît souvent de besoins hypothétiques plutôt que réels. L’auteur illustre ce propos avec un exemple concret : une fonctionnalité rendue paramétrable par prudence, mais jamais utilisée, entraînant deux ans de maintenance inutile. Cette approche, bien que courante, alourdit inutilement les systèmes en augmentant le temps de développement, les risques de bugs et la difficulté de maintenance.

L’auteur explique que les abstractions prématurées, comme des interfaces génériques ou des systèmes de configuration superflus, compliquent le code sans apporter de valeur réelle. Ces choix, motivés par une anticipation incertaine, rendent souvent le logiciel plus difficile à comprendre et à faire évoluer. De plus, la solution imaginée pour un besoin hypothétique peut s’avérer inadaptée, forçant des adaptations coûteuses plutôt qu’une refonte optimale.

Pour éviter ces écueils, l’auteur prône un principe simple : construire uniquement ce qui est nécessaire aujourd’hui, en se basant sur des besoins avérés plutôt que sur des scénarios futurs incertains. Cette approche réduit la complexité, facilite la maintenance et permet d’adapter le code plus efficacement lorsque les besoins réels se présentent.

Scott H Young explore dans cet article les obstacles psychologiques qui entravent la motivation pour accomplir des tâches ou adopter des habitudes, qu’il s’agisse de sport, d’apprentissage ou de projets personnels. L’idée centrale est que la procrastination et le manque de motivation découlent souvent de trois problèmes principaux : l’aversion immédiate pour l’effort, la peur irrationnelle de l’échec, ou l’ignorance des méthodes à suivre.

L’auteur détaille d’abord l’aversion pour l’effort, où le présent pèse plus lourd que les bénéfices futurs, comme dans le cas d’une visite chez le dentiste. Il souligne que certaines tâches deviennent moins pénibles avec l’habitude, tandis que d’autres peuvent être rendues plus agréables en modifiant leur contexte ou en les associant à des récompenses. Ensuite, il aborde la peur, qui fausse notre perception des risques et paralyse l’action, proposant comme solution une exposition progressive pour désamorcer ces craintes irrationnelles.

Enfin, Young évoque l’ignorance des méthodes nécessaires, qui peut fausser notre évaluation de l’effort requis et nous décourager avant même d’avoir commencé. Bien que la connaissance ne suffise pas à elle seule, elle joue un rôle clé pour ajuster nos attentes et faciliter l’action. L’article insiste sur l’importance de diagnostiquer ces blocages pour adapter des solutions concrètes.

LLMFit est un outil open source en ligne de commande, écrit en Rust, qui aide à choisir un modèle de langage (LLM) adapté à son matériel pour une utilisation locale. Il analyse automatiquement la configuration de l'ordinateur (RAM, CPU, GPU/VRAM, compatibilité CUDA/Metal/ROCm) et recommande des modèles compatibles parmi plus de 157 options issues de 30 fournisseurs, en tenant compte de critères comme la qualité, la vitesse d'inférence, la mémoire requise et la longueur de contexte. L'outil propose aussi des filtres par usage (chat, coding, raisonnement, etc.) et s'intègre avec des solutions comme Ollama, llama.cpp ou LM Studio.

L'auteur partage son expérience avec LLMFit sur un MacBook Pro M2, illustrant comment l'outil simplifie le choix des modèles en évitant les essais infructueux. Il souligne les fonctionnalités avancées comme la sélection automatique de la quantization optimale, la gestion des architectures MoE et des configurations multi-GPU, ainsi que la possibilité de planifier l'achat de matériel en fonction des besoins d'un modèle spécifique. L'interface, disponible en mode TUI interactif ou en ligne de commande, facilite l'automatisation et l'intégration dans des workflows existants.

Enfin, LLMFit propose un mode "plan" pour inverser le processus : en entrant un modèle précis, il indique la configuration matérielle idéale, la quantization recommandée et une estimation des performances selon le backend utilisé. Cet outil répond ainsi à un besoin croissant avec l'essor des assistants de codage locaux, comme GitHub Copilot en mode offline, en permettant une utilisation efficace des ressources disponibles.

Ce billet de blog résume le troisième et dernier jour de la conférence DevoxxFR 2026, marqué par la présentation d’une session sur le scheduling dans Kubernetes par l’auteur. L’intervention, axée sur la simplification de concepts comme les requests, limits, QoS et PriorityClasses, a été saluée pour sa clarté, son humour et ses démos techniques réussies, avec une note moyenne de 4,91/5. L’auteur évoque aussi son expérience sur scène, entre stress et satisfaction, ainsi qu’un enregistrement au Studio Devoxx où il a discuté de Kubernetes et de son livre.

La journée a également inclus une conférence sur l’optimisation de la JVM dans Kubernetes, abordant des thèmes comme le warmup, la compilation tiered, l’impact des ressources CPU sur le démarrage des applications Java, et les évolutions récentes de Java pour mieux s’adapter aux conteneurs. L’auteur souligne l’importance des fondamentaux et des démonstrations pratiques pour illustrer ces concepts.

Enfin, le billet reflète l’épuisement post-conférence et la satisfaction d’avoir partagé des connaissances techniques de manière accessible, tout en notant l’engagement positif du public et des retours encourageants.

Deuxième journée orientée vers des retours d’expérience concrets autour de l’IA et de son industrialisation, avec un fil conducteur clair : privilégier des approches pragmatiques, bien dimensionnées et intégrées à l’écosystème existant plutôt que des solutions “tout gros modèle”. Un exemple marquant est l’usage de petits modèles spécialisés (SLM/TLM) combinés à du RAG et une orchestration légère pour gérer un support client efficacement sans explosion des coûts.

Un autre point fort concerne l’“agentic coding” vu comme un sujet de platform engineering : son adoption à grande échelle impose de repenser workflows, gestion du contexte et standardisation via des outils ou marketplaces internes, avec une approche spec-driven (spécifications versionnées lisibles par humains et machines).

La journée aborde aussi des problématiques d’infrastructure à grande échelle (ex. gestion de centaines de millions d’emails) et des réflexions plus larges sur le rôle politique de la tech, tout en restant ancrée dans des retours terrain et des outils concrets pour les devs et ops.

Jujutsu (jj) est présenté comme une alternative moderne à Git, conçue pour simplifier la gestion des commits, des branches et des opérations complexes comme le rebase. L’outil se distingue par sa capacité à fonctionner en parallèle de Git, permettant aux développeurs de l’adopter sans impacter leur équipe. L’auteur partage son expérience de présentation à Devoxx France, illustrant les fonctionnalités clés de jj à travers des démos pratiques.

Le clonage d’un dépôt avec jj est détaillé, montrant comment initialiser un projet en mode "colocated" pour combiner les avantages des deux systèmes. Les revsets, équivalents des commits Git, sont mis en avant avec une visualisation claire de l’historique, incluant identifiants, auteurs, dates et messages. L’outil introduit aussi des concepts comme les bookmarks (remplaçant les branches) et l’operation log pour suivre les modifications.

Enfin, l’article aborde des fonctionnalités avancées comme l’absorption automatique des changements (absorb), le rebase simplifié et la gestion des conflits, tout en proposant des astuces de configuration pour optimiser l’expérience utilisateur. Des ressources complémentaires sont suggérées pour approfondir l’apprentissage.

Retour d’expérience du DevFest Nantes 2025 décrivant un événement dense et stimulant, marqué par une forte participation des équipes et une grande diversité de formats (conférences, ateliers, Unconference favorisant les échanges ouverts). L’accent est mis sur la richesse des discussions techniques et humaines, ainsi que sur l’intérêt de ces formats interactifs pour partager des retours concrets et confronter les pratiques entre professionnels.

Parmi les sujets abordés, plusieurs thématiques ressortent : l’observabilité avec OpenTelemetry, les enjeux d’architecture logicielle (scalabilité, résilience, sécurité), l’impact environnemental du numérique et les pratiques de sobriété, ainsi que des retours d’expérience sur l’organisation des équipes et les méthodes de travail. Certaines conférences utilisent des analogies issues du jeu vidéo pour vulgariser des concepts complexes d’architecture ou de monitoring, rendant ces sujets plus accessibles et concrets.

L’ensemble est perçu comme inspirant et directement applicable, avec des idées réutilisables en entreprise, aussi bien sur le plan technique que sur les dimensions organisationnelles et sociétales du développement logiciel.

L’article de Rahul Garg, ingénieur principal chez Thoughtworks, propose d’encapsuler les standards d’une équipe sous forme d’instructions versionnées et partagées, afin d’améliorer la cohérence des résultats générés par les assistants IA. L’idée centrale est de transformer les connaissances tacites des équipes (conventions de code, bonnes pratiques de sécurité, etc.) en artefacts exécutables, réduisant ainsi la dépendance aux experts et les variations de qualité selon les utilisateurs.

L’auteur souligne que les pratiques informelles, acquises par l’expérience, créent des disparités dans l’utilisation de l’IA, même au sein d’une même équipe. Sans cadre formalisé, les prompts varient selon les individus, ce qui nuit à la standardisation des livrables. La solution envisagée consiste à externaliser ces règles dans des documents versionnés, accessibles à tous, pour garantir une application uniforme des standards.

Enfin, Garg illustre ce problème avec des exemples concrets : un développeur senior inclut des détails précis dans ses requêtes (style fonctionnel, gestion des erreurs, conventions de nommage), tandis qu’un junior se contente de demandes vagues, produisant des résultats moins alignés avec les attentes de l’équipe. L’objectif est donc de systématiser ces instructions pour fluidifier le travail collaboratif avec l’IA.

Compte-rendu du premier jour de DevoxxFR 2026 marqué par une forte présence de l’IA le matin, puis des sujets plus variés l’après-midi, mêlant technique, retours d’expérience et thématiques humaines. La keynote d’ouverture insiste sur une approche critique de l’IA : elle amplifie les capacités humaines mais reste biaisée, coûteuse et dépendante du jugement humain, loin d’une intelligence générale autonome.

Plusieurs interventions montrent l’impact concret de l’IA sur les pratiques : dans les échecs, elle devient un outil d’apprentissage qui élève le niveau global plutôt qu’un simple adversaire ; dans le développement, elle permet d’explorer des approches “spec-driven”, même si les formats pratiques peuvent être victimes de leur succès. Un talk technique sur une base de données analytique détaille la chaîne complète d’exécution (parsing, optimisation, planification), illustrant la complexité et les gains de performance des moteurs modernes.

Les sessions plus transverses apportent des réflexions utiles sur le travail et l’organisation : une intervention sur le rapport au temps souligne les effets négatifs de l’accélération et du multitâche, ainsi que le paradoxe d’une IA censée faire gagner du temps mais qui tend à augmenter la charge de travail. D’autres formats, comme un quiz Kubernetes, rappellent l’importance de revisiter ses connaissances, même sur des sujets maîtrisés.

Enfin, des sujets humains et organisationnels sont abordés, notamment la maternité dans la tech, avec des pistes concrètes pour améliorer l’inclusion et les conditions de travail. L’événement met aussi en avant l’importance des échanges informels (“hallway track”) et des discussions entre pairs, considérés comme une part essentielle de la valeur de la conférence. (

Dockman est un gestionnaire Docker Compose conçu pour simplifier l'administration des conteneurs tout en conservant une approche native et légère. Contrairement à des outils comme Portainer ou Dockge, il permet de gérer non seulement les stacks, mais aussi les images, volumes et réseaux associés, le tout via une interface web épurée. L'outil se distingue par son respect des fichiers locaux, évitant de les enfermer dans une base de données ou un dossier caché, et par sa légèreté, idéale pour les homelabs.

L'auteur souligne que Dockman répond à un besoin précis : éviter la complexité des interfaces surchargées ou des fonctionnalités superflues, tout en offrant un contrôle direct sur les configurations Docker Compose. Cependant, certaines limites sont à noter, comme l'absence de multi-facteur natif pour l'authentification ou une gestion multi-hôtes encore en version bêta. L'installation repose sur un fichier compose simple, avec des variables d'environnement pour activer la sécurité de base.

Disponible sur GitHub, Dockman se positionne comme une alternative pragmatique pour les utilisateurs souhaitant une solution minimaliste et efficace, tout en restant conscient de ses contraintes actuelles.

L’article explore la question de l’espace réellement occupé par un fichier sur un disque, au-delà de sa taille brute. L’auteur explique que la place dépend de plusieurs facteurs : les métadonnées du système de fichiers, l’allocation par blocs (clusters) indivisibles, et la fragmentation. Par exemple, un fichier d’1 octet peut occuper plusieurs kilo-octets en raison de ces contraintes techniques.

L’auteur détaille aussi les unités de mesure en informatique, distinguant les préfixes binaires (kibi-octet, mébi-octet) des préfixes décimaux (kilo-octet, méga-octet), et souligne les différences de calcul selon les systèmes de fichiers comme NTFS. Il illustre ces concepts avec des exemples concrets et une expérience pratique pour estimer l’espace réel d’un dossier.

Enfin, l’article aborde l’application concrète de ces notions dans un projet de création d’images disque, où la taille optimale doit être calculée avec précision. L’auteur partage des chiffres réels et des méthodes pour estimer l’espace occupé, tout en invitant à approfondir le sujet.

Web-Check est un outil open source d'OSINT (Open Source Intelligence) conçu pour analyser en profondeur n'importe quel site web. Il permet d'obtenir des informations détaillées sur l'infrastructure, la sécurité et les technologies utilisées par un site, comme les adresses IP, les certificats SSL, les en-têtes HTTP, les cookies, les ports ouverts ou encore les extensions DNS sécurisées.

L'outil propose une interface centralisée affichant des données techniques variées, utiles pour évaluer la performance, la sécurité ou l'empreinte carbone d'un site. Une version hébergée est accessible via web-check.as93.net, et le projet peut être déployé localement via Docker ou des plateformes comme Netlify et Vercel.

Email.md simplifie la création d’emails responsive en utilisant le Markdown, évitant ainsi la complexité du HTML traditionnel. L’outil propose des templates prédéfinis et un éditeur visuel pour générer rapidement des emails adaptés aux mobiles.

Un exemple concret est fourni avec un modèle de confirmation d’email, incluant un préheader, un thème sombre et des blocs structurés (en-tête, contenu, appel à l’action, pied de page). Les utilisateurs peuvent personnaliser facilement le texte et les éléments visuels.

Le projet est open source, disponible sur GitHub, et s’installe via npm pour une intégration fluide dans les workflows de développement.

Proxelar est un proxy MITM (Man-in-the-Middle) programmable écrit en Rust, conçu pour intercepter, inspecter et modifier le trafic HTTP/HTTPS. Il permet de transformer les requêtes et réponses en temps réel via des scripts Lua, offrant ainsi un outil puissant pour le débogage d'API, l'analyse de services tiers ou le test d'applications mobiles. Le projet propose plusieurs modes de fonctionnement (proxy avant/arrière) et des interfaces variées (terminal, TUI interactive, interface web).

Parmi ses fonctionnalités clés, Proxelar inclut l'interception automatique des connexions HTTPS grâce à une autorité de certification intégrée, ainsi qu'un système de filtrage avancé pour analyser les requêtes. Il prend en charge l'inspection des flux WebSocket et permet une installation simplifiée du certificat racine via une page dédiée. Le projet est distribué sous licence MIT et peut être installé via Cargo, Homebrew ou Docker.

Le dépôt GitHub du projet met en avant des contributions actives, avec des mises à jour régulières et une documentation en constante amélioration, incluant des exemples de scripts Lua pour personnaliser le comportement du proxy.

Algorithm Visualizer est une plateforme interactive en ligne qui permet de visualiser et comprendre des algorithmes grâce à des représentations graphiques. Le site propose des démonstrations en temps réel d'algorithmes classés par catégories (comme le backtracking ou la programmation dynamique), facilitant leur apprentissage pour les étudiants, enseignants ou professionnels.

L'outil s'appuie sur des bibliothèques de visualisation en plusieurs langages de programmation, extraites directement du code source. Des ressources complémentaires, comme des tutoriels et des articles, sont également disponibles pour approfondir les concepts.

Le projet est open source et collaboratif, avec plusieurs dépôts GitHub dédiés à l'application web (développée en React), au serveur backend et aux algorithmes visualisés. Les contributions sont encouragées pour enrichir la base de données ou améliorer les fonctionnalités.

CodeBurn est un outil en ligne de commande qui permet de visualiser et analyser l'utilisation des tokens par les IA de codage comme Claude Code, Codex ou Cursor. Il offre un tableau de bord interactif en TUI avec des graphiques et des données détaillées par modèle, tâche ou projet, incluant le taux de réussite en une seule tentative et les coûts associés. L'outil se distingue par son approche sans wrapper ni proxy, en lisant directement les données de session depuis le disque, et supporte l'export en CSV ou JSON.

Disponible sous forme d'application macOS native ou via npm, CodeBurn fonctionne sans clé API et s'appuie sur LiteLLM pour la tarification. Il permet des analyses sur différentes périodes (aujourd'hui, 7 jours, mois, etc.) et inclut des fonctionnalités comme l'optimisation pour identifier les gaspillages ou la comparaison de modèles. Les commandes simples comme codeburn today ou codeburn report -p 30days facilitent son utilisation.