Swival est un agent de codage open source conçu pour fonctionner avec divers modèles de langage, des plus performants aux modèles locaux plus modestes, en optimisant la gestion des contextes restreints et des ressources limitées. Il s’intègre facilement à des outils comme LM Studio, llama.cpp ou HuggingFace, et permet de choisir son modèle et son infrastructure. Ses fonctionnalités incluent une gestion intelligente du contexte, une mémoire persistante entre sessions et une sécurité renforcée avec chiffrement des secrets.

L’outil propose des mécanismes de revue et de benchmarking pour évaluer les performances des modèles, ainsi que des audits de sécurité autonomes pour détecter des vulnérabilités dans le code. Il supporte les protocoles A2A et ACP, facilitant son intégration avec des éditeurs comme Zed ou des agents externes. Son architecture modulaire permet d’étendre ses capacités via des skills ou des MCP servers, tout en restant léger et personnalisable.

Swival se distingue par sa fiabilité sur des modèles locaux, sa gestion optimisée du contexte et ses options de sécurité configurables, comme le chiffrement des secrets ou les restrictions d’accès au système de fichiers. Son installation rapide et sa compatibilité avec de nombreux fournisseurs en font une solution flexible pour automatiser des tâches de développement.

Lea Verou défend l’utilité des polyfills dans un billet de blog, face à des critiques récentes suggérant qu’ils seraient néfastes pour le développement web. Elle rappelle que ces outils permettent de découpler la conception des API de leur implémentation, offrant ainsi une flexibilité essentielle aux développeurs tout en maintenant la compatibilité avec les standards émergents. Verou, experte en standards web et auteure de bibliothèques open source, souligne que les polyfills favorisent un écosystème plus robuste, inclusif et performant, malgré quelques cas problématiques où leur adoption prématurée a pu restreindre l’évolution des API natives.

Elle répond aux inquiétudes de certains éditeurs de spécifications, comme Anne van Kesteren (WHATWG), qui voient les polyfills comme un frein à la flexibilité des API. Verou argue que ces préoccupations, bien que légitimes, ignorent souvent les réalités pratiques du développement web, où les développeurs privilégient les solutions natives lorsqu’elles existent. Selon elle, les risques liés aux polyfills (comme les incompatibilités futures) sont comparables à ceux d’autres techniques de fallback, et leur interdiction totale serait contre-productive.

Enfin, Verou insiste sur l’importance de ne pas confondre les polyfills avec le problème sous-jacent : l’échec des processus de standardisation à anticiper les besoins des développeurs. Elle conclut que, plutôt que de chercher à éliminer les polyfills, il faudrait améliorer les mécanismes de collaboration entre éditeurs de spécifications et auteurs de bibliothèques pour éviter les conflits de conception.

Ce guide complet explique le câble RJ45, souvent mal compris malgré son rôle central dans les réseaux. L’idée principale est que la majorité des pannes réseau proviennent d’une mauvaise terminaison du câble (sertissage, détorsion ou mauvais branchement) plutôt que d’un équipement défectueux. L’article détaille son anatomie, les normes de câblage (Cat5e à Cat8), et les différences entre câbles droits et croisés, essentiels pour éviter les erreurs de connexion.

Il clarifie aussi la terminologie : le RJ45 désigne le connecteur, pas le câble, composé de 4 paires torsadées en cuivre, d’une gaine (PVC ou LSZH) et éventuellement d’un blindage (UTP, FTP, S/FTP). Les schémas de câblage T568A et T568B, bien que similaires, déterminent si le câble est droit ou croisé, selon l’uniformité des deux extrémités.

Enfin, le guide replace le RJ45 dans le modèle OSI (couche physique) et souligne son rôle passif : il transmet des signaux électriques sans interpréter les données, contrairement aux couches supérieures. Une vérification de la couche physique (câble, connecteur, port) est donc cruciale avant toute investigation logicielle.

L’auteur présente son dépôt de dotfiles, un ensemble de configurations et d’outils pour personnaliser son terminal et optimiser son workflow. Ces fichiers, stockés dans un dépôt Git, permettent de recréer rapidement un environnement de travail sur une nouvelle machine en quelques minutes. L’idée centrale est de centraliser et versionner ces configurations pour une gestion efficace et reproductible.

Parmi les outils modernes utilisés, on trouve des alternatives performantes aux commandes Unix classiques : eza pour un affichage enrichi de ls, bat pour la coloration syntaxique de cat, ripgrep pour des recherches rapides, fd pour simplifier find, zoxide pour naviguer entre dossiers avec des fragments de noms, et delta pour améliorer la lisibilité des différences Git. Ces outils, souvent écrits en Rust, offrent des performances supérieures et une expérience utilisateur plus intuitive.

L’auteur souligne particulièrement zoxide, qui remplace avantageusement cd en mémorisant les chemins visités et en permettant des déplacements rapides via des mots-clés. Cette solution s’intègre parfaitement à son flux de travail, notamment en déclenchant automatiquement des actions comme le changement de version Node.js via fnm lors de la navigation.

L’article explique comment configurer un remote Git multi-cibles pour publier simultanément sur plusieurs plateformes, comme GitHub et Codeberg, afin de réduire la dépendance à une seule forge. L’auteur détaille la distinction entre les URLs de fetch (récupération) et de push (envoi), et montre comment ajouter plusieurs destinations de push avec la commande git remote set-url --add --push.

La méthode permet de synchroniser automatiquement les modifications sur plusieurs dépôts avec un simple git push, tout en conservant une seule URL de récupération. Cependant, cette approche reste un miroir unidirectionnel : les changements poussés directement sur Codeberg ne seront pas récupérés automatiquement, ce qui limite son usage en contexte collaboratif.

La page explique comment rédiger une user story efficace, une méthode simple pour décrire un besoin logiciel du point de vue de l’utilisateur. Elle se structure en une phrase : « En tant que [utilisateur], je veux [action], afin de [bénéfice] », mettant l’accent sur le quoi et le pourquoi plutôt que le comment. Les critères d’acceptation et le cadre INVEST (indépendante, négociable, etc.) permettent de la rendre vérifiable et exploitable.

L’article illustre son utilité avec un exemple concret : un client a remplacé un cahier des charges classique par 90 pages de user stories, recueillies auprès des utilisateurs finaux. Cette approche favorise une collaboration plus précise et ouverte, évitant les malentendus et permettant aux équipes techniques de proposer des solutions optimisées dès le départ.

Enfin, les user stories servent de base de travail collaborative, recentrant les équipes sur les besoins réels plutôt que sur des spécifications techniques figées. Leur taille réduite et leur flexibilité en font un outil agile, idéal pour des projets complexes où l’itération et l’adaptation sont essentielles.

Le Cyber Resilience Act (CRA) européen impose de nouvelles obligations de signalement à partir du 11 septembre 2026, notamment l’article 14, qui exige de notifier les vulnérabilités exploitées ou incidents graves sous 24h à 14 jours selon les cas. Contrairement à une idée reçue, cette date ne déclenche pas l’ensemble du règlement, qui s’appliquera pleinement en décembre 2027. Les signalements doivent être transmis via une plateforme unique (Single Reporting Platform) vers les autorités compétentes (CSIRT et ENISA).

La notion d’activité commerciale est déterminante pour savoir si un développeur est concerné. Un logiciel open source non monétisé par ses auteurs échappe aux obligations, même s’il est hébergé publiquement ou soutenu par des entreprises. En revanche, toute intention de profit, comme des dons excédant les coûts ou des services payants de support, peut basculer un projet dans le champ du CRA. Le texte distingue clairement la publication de la vente.

Trois profils se dégagent : le fabricant (celui qui met le logiciel sur le marché), le steward (mainteneur influent, souvent une organisation) et le passant (utilisateur ou contributeur occasionnel). Les obligations pèsent surtout sur les deux premiers, tandis que les simples contributeurs ou utilisateurs sont généralement exemptés, sauf si leur activité relève d’une commercialisation indirecte.

L’article explore l’intégration de Karpenter avec Cluster API (CAPI) pour automatiser l’autoscaling des nœuds Kubernetes, notamment sur OVH. L’auteur compare deux solutions : Cluster Autoscaler, qui gère des groupes de machines prédéfinis, et Karpenter, qui provisionne dynamiquement des nœuds en fonction des besoins des pods, sans nécessiter de configuration manuelle de groupes. Karpenter, initialement conçu pour AWS, est désormais agnostique grâce à sa donation à la CNCF, avec des providers tiers comme karpenter-provider-cluster-api pour CAPI, permettant une intégration avec des clouds comme OVH.

L’auteur détaille le fonctionnement de Karpenter, notamment ses ressources clés comme les NodePools, qui définissent les règles de provisionnement, et son approche par pods en attente (Pending). Contrairement à son mode natif (standalone), l’utilisation avec CAPI impose un cluster de management supplémentaire, ce qui complexifie légèrement l’architecture. Le texte souligne aussi les différences philosophiques entre les deux outils : Karpenter optimise les coûts en choisissant des instances adaptées (y compris Spot), tandis que Cluster Autoscaler se base sur des groupes de nœuds préconfigurés.

Enfin, l’article présente un retour d’expérience pratique avec des tests de scale-up et scale-down, mettant en lumière les défis rencontrés, comme la gestion des taints ou les limites du scale-to-zero. L’auteur conclut en comparant Karpenter et Cluster Autoscaler, soulignant les avantages de Karpenter pour les charges irrégulières, tout en notant les contraintes liées à son intégration avec CAPI.

L’article de Mat Marquis sur Piccalilli explore l’utilisation des Proxy et Reflect en JavaScript, des outils puissants pour intercepter et modifier les opérations internes sur les objets. L’auteur explique comment ces mécanismes permettent de mieux comprendre le fonctionnement profond du langage, un atout pour les développeurs souhaitant progresser vers un niveau senior. Il illustre leur utilité en montrant comment un Proxy agit comme intermédiaire entre un objet cible et les opérations qui lui sont appliquées, tout en soulignant leur rôle dans l’apprentissage des mécanismes internes de JavaScript.

L’article s’inscrit dans le cadre du cours JavaScript for Everyone de Piccalilli, bien que présenté comme un extrait non listé, laissant planer un mystère sur son intégration future. Marquis aborde ensuite la structure des objets JavaScript, détaillant les étapes internes déclenchées par l’accès à une propriété (comme la recherche dans la chaîne de prototypes ou l’invocation d’un accesseur), avant d’introduire le Proxy comme moyen de personnaliser ces comportements.

Enfin, l’auteur propose un exemple concret de création d’un Proxy, avec un objet cible et un gestionnaire vide, montrant comment l’objet proxy résultant encapsule à la fois la cible et le gestionnaire via des slots internes. L’article se termine sur une note engageante, invitant le lecteur à explorer davantage ces fonctionnalités pour maîtriser JavaScript au-delà de la syntaxe.

L’article explique comment appliquer correctement le pattern MVC en Symfony pour séparer la logique métier des contrôleurs et des vues, afin d’améliorer la maintenabilité du code. Il souligne que le Model ne se résume pas à une seule classe, mais se répartit entre entités, repositories et services, chacun ayant un rôle précis : les entités définissent la structure des données, les repositories gèrent les requêtes à la base de données, et les services encapsulent la logique métier.

L’auteur illustre cette séparation avec un exemple concret de contrôleur Symfony qui délègue la récupération d’un article à un repository et affiche les données via une vue Twig. Il met en garde contre l’illusion d’un MVC "propre" en rappelant que la logique métier ne doit pas être dispersée dans les contrôleurs ou les templates, mais centralisée dans des services dédiés.

Enfin, le billet insiste sur l’importance de cette discipline pour éviter un code désorganisé, tout en reconnaissant que la séparation idéale est souvent compromise dans la pratique. Il conclut que le MVC est davantage un vocabulaire commun qu’un plan rigide, et que sa mise en œuvre repose sur une réflexion constante sur l’architecture.

Un développeur explique comment il a utilisé un système RAG (Retrieval-Augmented Generation) sur son propre blog pour l'aider à écrire, plutôt que de générer du contenu à sa place. L'objectif était de vérifier si des idées similaires avaient déjà été abordées ou si des contradictions existaient dans ses anciens billets, en s'appuyant sur une recherche dans son corpus plutôt que sur la mémoire d'un modèle d'IA.

Le RAG fonctionne en deux étapes : d'abord, les documents sont transformés en vecteurs (embeddings) et stockés dans une base de données vectorielle ; ensuite, lors d'une requête, la question est également vectorisée et les documents les plus proches sont récupérés pour enrichir le prompt du modèle. L'auteur détaille une implémentation concrète avec Symfony AI, utilisant PostgreSQL avec pgvector, un vectorizer pour calculer les embeddings, et un indexeur qui découpe les articles en morceaux pour une recherche plus précise.

L'auteur rejette l'idée d'un chatbot public pour son blog, principalement pour des raisons économiques (coût des appels au modèle) et parce qu'il préfère utiliser le RAG comme outil personnel pour relire et vérifier ses écrits, plutôt que comme un générateur de contenu pour les visiteurs.

Ce tutoriel explique comment concevoir un load balancer ICMP (ping) en utilisant XDP (eXpress Data Path) avec le framework Rust Aya. L’objectif est de rediriger les requêtes ICMP vers différents serveurs backends en modifiant l’adresse IP de destination, illustrant ainsi les principes de base des load balancers réseau. L’auteur justifie le choix de l’ICMP par sa simplicité pédagogique, bien que moins courant que TCP/UDP, tout en soulignant que les concepts abordés s’appliquent aussi à ces protocoles.

L’article détaille la création d’un environnement de développement via des namespaces réseau, la génération d’un programme XDP minimal avec Aya, et l’intégration de dépendances comme network-types pour manipuler les en-têtes réseau. Il montre ensuite comment tester le load balancer en pingant une IP virtuelle (10.0.0.10) qui redirige le trafic vers un backend (10.0.0.2 ou 10.0.0.3), avec une approche progressive pour résoudre les problèmes de checksum et de répartition de charge.

Enfin, le billet s’inscrit dans une série dédiée à XDP, après des articles sur les firewalls et la mitigation de DDoS, et annonce une suite pour améliorer ce load balancer. L’auteur invite les lecteurs à approfondir avec des ressources externes et à explorer des cas plus complexes comme TCP/UDP.