L’article explique la migration d’un outil de génération de PDF, wkhtmltopdf, vers Gotenberg dans une application Symfony legacy, en évitant de perturber les endpoints existants. L’idée principale est de découpler la génération de PDF du conteneur API pour améliorer les performances et la maintenabilité, car wkhtmltopdf consommait trop de ressources CPU et reposait sur des dépendances locales (fichiers, polices, images). Le processus a nécessité de refactoriser l’architecture pour externaliser le rendu HTML vers un conteneur dédié, tout en gérant les différences de rendu entre les moteurs (problèmes de polices, de mise en page ou de chemins d’accès).

La migration a révélé des défis techniques, comme la gestion des chemins de fichiers (remplacement des références locales par des URLs accessibles) et les écarts de rendu entre wkhtmltopdf et Chromium (Gotenberg), entraînant des modifications de mise en page inattendues. L’approche adoptée a consisté à migrer progressivement, type de document par type de document, pour limiter les risques et permettre des ajustements fins. L’objectif était de préserver la compatibilité des endpoints tout en améliorant l’infrastructure.

L’article propose une solution pour tester efficacement le JavaScript dans Symfony Asset Mapper, souvent confronté à des erreurs comme ERR_MODULE_NOT_FOUND en raison de l’incompatibilité entre l’importmap.php de Symfony et les outils Node.js. L’auteur suggère d’utiliser des liens symboliques pour faire correspondre les fichiers Symfony (dans assets/vendor ou vendor) avec la structure attendue par Node.js dans node_modules, évitant ainsi de dupliquer ou modifier les imports.

Un script PHP automatise la création de ces liens symboliques en analysant l’importmap.php, permettant à Node.js de résoudre les modules comme en production. Cette méthode s’intègre via un pretest dans le package.json, exécutant le script avant chaque test. L’approche privilégie le test runner natif de Node.js (depuis la version 20) pour sa simplicité, sa rapidité et son absence de configuration complexe, tout en testant les fichiers réels utilisés en production.

Twig 3.24.0, sorti avec Symfony 7.4, introduit des fonctionnalités avancées pour simplifier la création de composants UI réutilisables, répondant aux besoins des systèmes de design modernes et des frameworks comme Tailwind. Parmi les nouveautés, la fonction html_attr, la stratégie d'échappement html_attr_relaxed et les opérateurs null-safe améliorent la gestion des attributs HTML et des données dynamiques, réduisant ainsi la complexité des templates.

L'article explique comment abandonner les tableaux non structurés pour des DTOs strictement typés et validés, combinés à des attributs PHP 8.x et à Symfony 7.4's #[MapRequestPayload], afin de transmettre des données propres et validées directement aux templates Twig. Cela renforce la robustesse des applications tout en maintenant une bonne expérience de développement.

Pour utiliser ces fonctionnalités, il est nécessaire d'installer les packages twig/html-extra, symfony/serializer et symfony/validator, et de vérifier que Twig 3.24.0 ou supérieur est bien installé. L'article détaille également la configuration requise et présente un exemple concret de création d'un composant Button avec des DTOs stricts.

L’article d’Alan Norbauer présente 67 astuces méconnues pour exploiter pleinement les outils de débogage des navigateurs, destinées aux développeurs intermédiaires ou avancés. Il met en avant des techniques comme les logpoints (points de trace) pour afficher des logs sans interrompre l’exécution, ou l’utilisation de conditional breakpoints (points d’arrêt conditionnels) avec des expressions à effets de bord pour modifier le comportement du programme en temps réel.

Parmi les méthodes détaillées, on trouve le profilage de performance rapide via console.time et console.timeEnd, ou encore le traçage des appels de fonctions pour identifier des anomalies comme des appels non appariés. L’auteur explique aussi comment exploiter le watch pane pour surveiller des variables ou des états du DOM, ou encore contourner des chargements de page pour gagner du temps lors du débogage.

Enfin, l’article couvre des astuces spécifiques comme la pause sur changement d’URL, l’inspection du DOM avec JavaScript désactivé, ou la surveillance d’événements pour des éléments précis. Ces techniques permettent d’optimiser le débogage en exploitant des fonctionnalités souvent sous-utilisées des outils de développement.

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