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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Ce tutoriel explique comment créer un filtre personnalisé pour EasyAdmin dans Symfony, lorsque les filtres natifs ne suffisent pas. L'auteur prend l'exemple concret d'un filtre "À la une" pour les billets d'un blog, qui nécessite une logique complexe (plage de dates active avec opérateurs combinés). Il détaille le processus en deux étapes : d'abord l'implémentation de l'interface FilterInterface avec la méthode apply() pour construire la requête SQL, puis la création d'un FilterType pour le formulaire.

L'article souligne que les filtres natifs (comme ChoiceFilter ou NullFilter) couvrent la plupart des cas simples, mais qu'un filtre custom devient nécessaire pour des conditions SQL avancées. Il montre comment structurer la classe du filtre en utilisant le FilterTrait et une méthode statique new() pour la configuration, tout en illustrant avec un exemple complet de filtre gérant à la fois des états binaires et des plages de dates.

Ce billet explique comment sécuriser un back-office EasyAdmin sans utiliser setPermission(), en s'appuyant sur trois couches de sécurité natives à Symfony. L'approche combine access_control par host, l'attribut #[IsGranted] au niveau des contrôleurs et des gardes personnalisées dans les actions sensibles, offrant une sécurité robuste et indépendante d'EasyAdmin.

La première couche repose sur access_control dans la configuration Symfony, restreignant l'accès à l'admin via un sous-domaine dédié (ex: admin.lecodeestdanslepre.fr) avec le rôle ROLE_ADMIN. Cette méthode agit comme un premier filet de sécurité avant même l'arrivée de la requête au contrôleur. La deuxième couche utilise #[IsGranted('ROLE_ADMIN')] sur chaque contrôleur pour doubler la vérification côté Symfony, garantissant que seules les actions autorisées sont exécutées.

Enfin, une troisième couche de sécurité est implémentée directement dans les actions métier pour des contrôles plus fins, comme la validation CSRF ou la vérification de l'état d'une entité. Ces trois niveaux de sécurité, tous issus de Symfony, assurent une protection complète tout en restant modulaires et adaptables à d'autres solutions que EasyAdmin.

L’article défend l’idée que dans les grands systèmes logiciels, une compréhension partielle de la base de code est non seulement inévitable, mais aussi suffisante pour travailler efficacement. L’auteur conteste la vision de Peter Naur, qui prône une maîtrise totale du code via une "théorie du programme", arguant que cette approche est irréaliste pour les systèmes complexes et à forte rotation d’équipes. Il souligne que les grands systèmes accumulent des cas particuliers impossibles à recréer de zéro, et que leur maintenance repose souvent sur une reconstruction progressive plutôt que sur une refonte complète.

L’auteur illustre son propos en expliquant que les équipes doivent souvent reprendre des bases de code abandonnées, en partant d’une compréhension locale avant d’étendre leur maîtrise. Il insiste sur le fait que la culture du "tout comprendre" est davantage valorisée dans les discussions en ligne, alors qu’elle est inadaptée aux environnements industriels à grande échelle. Selon lui, l’efficacité repose davantage sur la capacité à naviguer et modifier localement le code que sur une vision globale inaccessible.

EmojiDB est une base de données en ligne dédiée aux emojis, encore en version bêta. Le site permet de rechercher des emojis par mots-clés ou thèmes, offrant ainsi une interface pratique pour trouver le symbole adapté à ses besoins. Bien que le projet soit en construction, il propose déjà une vaste sélection d'emojis classés par catégories ou par recherche intuitive.

L'outil se distingue par sa simplicité et son accessibilité, avec une barre de recherche centrale facilitant la découverte d'emojis spécifiques. Il inclut également des emojis variés, allant des symboles classiques aux plus récents ou spécialisés, comme des drapeaux ou des expressions faciales stylisées.

EmojiDB pourrait intéresser les utilisateurs cherchant à enrichir leurs messages, réseaux sociaux ou documents avec des emojis, ainsi que les développeurs souhaitant intégrer ces symboles dans leurs projets. Le site reste évolutif, avec des mises à jour régulières pour élargir son catalogue.

DossierFacile est un service public numérique gratuit, développé par l'État, qui aide les locataires à constituer un dossier de location solide et sécurisé pour faciliter leur recherche de logement. Le processus repose sur trois étapes : téléchargement des pièces justificatives (identité, revenus, etc.), validation par des agents pour corriger d'éventuelles erreurs, et obtention d'un dossier labellisé sous forme de lien ou PDF prêt à être envoyé aux propriétaires. Le service protège aussi les données personnelles grâce à des filigranes anti-fraude et permet de supprimer le lien à tout moment.

Le site met en avant la réactivité et la clarté du dossier comme atouts majeurs pour se démarquer dans un marché locatif compétitif. Plus de 1,8 million de dossiers ont déjà été labellisés, avec des témoignages soulignant son efficacité, notamment pour les étudiants ou les personnes avec des dossiers étrangers. Une alerte rappelle de vérifier l'URL officielle (.gouv.fr) pour éviter les sites frauduleux.

Porté par la direction générale de l'aménagement, du logement et de la nature, DossierFacile est open source et s'appuie sur des partenaires institutionnels. Il propose aussi des espaces dédiés aux propriétaires et aux partenaires, ainsi qu'un blog pour guider les utilisateurs.

L’article explique comment configurer Mimir, le backend de stockage long terme pour les métriques Prometheus développé par Grafana, afin d’améliorer l’observabilité dans un environnement Kubernetes. Il détaille d’abord l’installation locale de Mimir sur le même serveur que Grafana et Prometheus, avec une authentification basic auth et un certificat TLS pour sécuriser l’accès au port 9009. La configuration repose sur un fichier YAML simplifié, où les données sont stockées localement et les composants (ingester, querier, etc.) sont définis pour une instance unique.

Ensuite, l’auteur décrit le déploiement de Grafana Alloy sur Kubernetes pour collecter les métriques et les logs, en s’appuyant sur une infrastructure existante. Un namespace monitoring est créé, ainsi qu’un secret pour l’authentification, tandis qu’un fichier Helm (alloy-values.yml) configure Alloy en tant que daemonset avec des volumes spécifiques pour accéder aux métriques système des nœuds Kubernetes. La configuration inclut aussi le relabeling des cibles Prometheus pour identifier correctement les instances.

Enfin, l’article souligne l’intégration entre Alloy et Mimir, où Alloy scrappe les métriques des nœuds et les envoie vers Mimir via remote_write, permettant ainsi une observabilité centralisée. La solution est présentée comme une alternative pour remplacer ou compléter des outils comme Prometheus en stockage long terme, tout en garantissant une configuration sécurisée et adaptée à Kubernetes.

L’article explique comment générer des fichiers Excel volumineux avec Airflow sans dépasser la mémoire disponible, en évitant les erreurs OOM (Out Of Memory). L’idée principale repose sur l’utilisation du streaming pour lire les données depuis MySQL et du mode write-only d’openpyxl pour écrire le fichier Excel sans tout charger en mémoire. Cette approche permet de stabiliser la consommation mémoire, contrairement à une méthode naïve qui charge l’intégralité des données en mémoire avant de les exporter.

L’auteur souligne que les solutions classiques, comme l’utilisation de pandas avec un chunksize, ne suffisent pas, car elles ne réduisent pas la mémoire utilisée lors de la lecture initiale. En revanche, un curseur non bufferisé pour MySQL et une écriture progressive avec openpyxl permettent de traiter les données par lots, limitant ainsi l’empreinte mémoire.

Enfin, l’article met en garde contre les coûts élevés liés à l’augmentation de la mémoire dans le cloud et propose une solution efficace pour des environnements contraints, comme AWS ECS Fargate. Cette méthode est particulièrement utile pour les pipelines de data engineering où les ressources sont optimisées pour réduire les dépenses.

L’article explique comment générer des images Open Graph personnalisées en PHP, sans dépendre de Chromium ou d’outils externes comme les IA. L’auteur détaille la création d’images originales, alignées sur l’identité visuelle de son site (couleurs, typographie, point rose), pour illustrer les liens partagés sur les réseaux sociaux. Ces visuels, au format 1200 × 630 pixels, sont dessinés dynamiquement par le serveur à l’aide des bibliothèques GD et Imagick, offrant une alternative aux solutions standardisées ou peu personnalisables.

L’auteur décrit l’architecture technique mise en place, combinant GD pour les opérations d’encodage (via Glide) et Imagick pour le rendu précis du texte. Il aborde aussi la gestion du cache, la signature des URLs pour le redimensionnement à la volée, et les défis rencontrés, comme les fuites mémoire avec FrankenPHP ou les limitations d’ImageMagick dans un environnement Docker léger. L’objectif n’est pas le SEO, mais la cohérence visuelle et l’authenticité des aperçus de liens.

Enfin, l’article souligne l’importance de l’image OG comme "affiche" du contenu, souvent plus visible que le billet lui-même. L’auteur partage son code et ses retours d’expérience, tout en insistant sur le fait que cette approche permet de maîtriser entièrement le rendu, contrairement aux solutions automatisées ou externalisées.