L’idée principale de l’article est de proposer une méthode de travail avec deux agents IA pour améliorer la programmation assistée par IA. L’un écrit le code dans un espace de travail dédié, tandis que l’autre, en parallèle, le révise systématiquement après chaque cycle de développement (TDD). Ce second agent, qualifié de « porteur de la lampe », maintient la vision globale du projet et évite que le premier agent ne s’éloigne des objectifs initiaux en se perdant dans les détails techniques.

L’auteur souligne que cette approche simple mais efficace permet de corriger deux problèmes majeurs : d’une part, l’agent codeur peut dériver de la mission initiale en accumulant des décisions localement optimales, et d’autre part, le réviseur identifie les erreurs structurelles ou les choix qui compliquent les étapes suivantes. Contrairement aux sous-agents de révision intégrés, ce réviseur dédié conserve une vision cohérente de l’objectif final tout au long du projet.

Enfin, l’article précise que cette méthode s’ajoute aux outils existants (comme les sous-agents de révision ponctuels) sans les remplacer, car ils remplissent des rôles complémentaires : les sous-agents gèrent les problèmes immédiats, tandis que le réviseur dédié préserve la cohérence globale. Cette coordination entre agents représente une évolution naturelle pour les utilisateurs maîtrisant déjà un agent unique.

Cette page introduit les bases de données orientées colonnes, comme ClickHouse, conçues pour analyser des flux d'événements horodatés (timeseries) à grande échelle, que ce soit pour des analyses historiques ou en temps réel. Leur principal avantage réside dans une compression et un traitement optimisés grâce à la structure en colonnes, contrairement aux bases relationnelles classiques (OLTP) qui privilégient les transactions et la cohérence. Les colonnes permettent des lectures séquentielles efficaces, une meilleure parallélisation et une compression adaptée aux gros volumes de données.

L'auteur compare ce modèle aux bases OLTP, soulignant que les bases orientées colonnes (comme celles utilisées pour la télémétrie ou l'observabilité) excelling en débit d'écriture et en scalabilité, mais au prix de transactions moins atomiques et de modifications plus lourdes. Contrairement aux systèmes comme Prometheus, qui gèrent mal la diversité des labels, les solutions modernes s'appuient sur des technologies éprouvées pour se concentrer sur la couche applicative. Le texte annonce ClickHouse comme solution dans un prochain article.

L’article explique comment exploiter les attributs PHP dans Symfony pour automatiser des comportements comme le logging sur les contrôleurs. Il détaille la création d’un attribut personnalisé, son application sur une classe ou une méthode, et l’implémentation d’un listener pour déclencher l’action associée. Les exemples montrent l’évolution de la syntaxe entre Symfony 6.2 et 8.1, simplifiant l’intégration des attributs dans les workflows.

L’article présente grep, sed et awk, trois commandes Linux essentielles pour le traitement de texte en ligne de commande, souvent utilisées sans toujours en maîtriser le fonctionnement. Grep permet de filtrer des lignes selon un motif, avec des options comme la recherche insensible à la casse (-i) ou récursive (-r), et s’enchaîne facilement avec d’autres commandes via le pipe. Sed modifie le contenu ligne par ligne, notamment pour des substitutions (s/ancien/nouveau/) ou des suppressions, avec l’option -i pour appliquer les changements directement dans le fichier. Awk, plus complexe, analyse et structure les données en champs, idéal pour extraire des colonnes, effectuer des calculs ou agréger des informations, comme compter des occurrences ou sommer des valeurs.

Let’s Encrypt a révolutionné la sécurisation du web en démocratisant les certificats HTTPS gratuits, rendant le chiffrement accessible à tous, notamment aux blogs et sites communautaires autrefois majoritairement en clair. L’article souligne que cette initiative a comblé un vide historique, où HTTPS était réservé aux sites commerciaux, laissant les données sensibles des utilisateurs vulnérables. Cependant, l’auteur critique l’absence de véritable alternative souveraine à Let’s Encrypt, malgré les discours sur l’autonomie numérique, soulignant que les rares solutions proposées restent limitées face à l’hégémonie du service.

L’auteur partage son expérience pour déployer un cluster Kubernetes managé (MKS) avec Cilium sur OVH Cloud, en comparant les approches CLI et interface web. Il explique que la version gratuite utilise Calico par défaut, tandis que Cilium n’est disponible qu’avec le plan standard payant, nécessitant aussi une gateway. L’interface graphique simplifie la création du réseau privé et du cluster, contrairement à la CLI qui s’avère complexe pour cette configuration.

Le tutoriel détaille ensuite les étapes techniques : configuration de l’authentification via la CLI OVH, récupération du Kubeconfig, et création d’un cluster avec un nodepool de deux nœuds. L’auteur souligne l’importance de bien préparer l’environnement (région compatible, réseau privé, gateway) avant de procéder à l’installation, et recommande des outils comme Terraform pour des déploiements plus sérieux.

Enfin, il explore les fonctionnalités de Cilium, comme l’observation du réseau, la gestion des Pods et des CRD, ainsi que la configuration avancée via CiliumNodeConfig, incluant l’activation de WireGuard pour le chiffrement. L’article sert de guide pratique pour intégrer Cilium dans un cluster OVH, avec des conseils concrets pour surmonter les défis techniques.

Les sourcemaps sont des fichiers JSON qui permettent de faire le lien entre le code minifié et exécuté par le navigateur et le code source original, facilitant ainsi le débogage en production. Elles contiennent des informations comme les chemins des fichiers sources, les noms des variables et fonctions d'origine, ainsi que des mappings précis pour retrouver la position exacte dans le code original. Ces outils sont essentiels pour les développeurs, mais ils exposent aussi la structure et le contenu du code source, posant des risques de sécurité.

L'auteur explique leur fonctionnement technique, notamment les champs clés comme sources, names et mappings, qui assurent la correspondance entre le code minifié et le code original. Les sourcemaps peuvent inclure même le contenu complet des fichiers sources (sourcesContent), ce qui simplifie le débogage mais augmente l'exposition des données. Leur format compact (base64 VLQ) optimise leur taille pour le transfert.

Enfin, l'article souligne l'importance de bien configurer les sourcemaps pour éviter de divulguer des informations sensibles, tout en profitant de leurs avantages pour le développement et le diagnostic d'erreurs. Une gestion prudente est recommandée pour concilier observabilité et sécurité.

L’article explique comment améliorer la maintenance et la sécurité des workflows GitHub, un enjeu crucial pour les projets open source comme Castor. Il présente zizmor, un outil d’analyse statique qui détecte les vulnérabilités dans les fichiers de configuration CI, similaire à PHPStan pour le code. L’outil identifie des erreurs courantes comme des références non verrouillées à des actions ou des risques de fuite de credentials, et propose des correctifs automatiques.

Les exemples de rapports générés par zizmor illustrent des problèmes spécifiques, comme l’absence de hachage pour une action ou l’utilisation dangereuse de GITHUB_ENV. La commande zizmor . --fix=all permet de corriger automatiquement certaines erreurs, mais nécessite un token GitHub pour accéder aux hashes des commits associés aux tags.

Enfin, l’article mentionne que zizmor ne gère pas les mises à jour majeures des actions, nécessitant d’autres méthodes pour ces cas. L’outil s’intègre ainsi dans une démarche globale de sécurisation et de maintenance des pipelines CI/CD.

Une faille de sécurité a été revendiquée sur Tchap, la messagerie souveraine de l’État français, avec des volumes de données exposées spectaculaires. Cependant, la DINUM a confirmé qu’il ne s’agissait pas d’une compromission du chiffrement de bout en bout, mais d’un compte légitime compromis via une attaque par ingénierie sociale, utilisé pour accéder à des espaces publics non chiffrés. Les données sensibles, protégées par le chiffrement, n’ont pas été exposées.

L’incident illustre l’importance de la gestion des identités et des accès, plutôt que de la seule cryptographie. La DINUM a bloqué rapidement le compte compromis et lancé des investigations, tout en notifiant la CNIL pour les données personnelles potentiellement exposées dans les salons publics. Les chiffres avancés par l’attaquant restent non vérifiés.

L’article souligne que même une messagerie chiffrée de bout en bout peut être vulnérable si les comptes utilisateurs ne sont pas correctement protégés. Il met en garde les organisations sur la nécessité de renforcer les politiques de sécurité des identités et de sensibiliser les utilisateurs aux risques d’ingénierie sociale.

ROM Finder est un outil en ligne permettant de trouver des ROM alternatives pour smartphones. Il référence 624 appareils compatibles issus de 27 constructeurs, avec 5 systèmes alternatifs disponibles. Les informations sont mises à jour régulièrement, la dernière en date étant le 7 juin 2026, et proviennent des sources officielles des projets concernés. Le site propose également des liens vers des ressources complémentaires et une page dédiée aux contributions.

L’auteur, Filipe Silva, défend PHP après 15 ans d’expérience, soulignant que les critiques courantes (incohérence de la bibliothèque standard, modèle stateless, absence d’asynchrone) sont souvent dépassées. Il rappelle que PHP a évolué depuis 1994, avec des versions majeures (PHP 7, 8) ayant introduit des performances accrues, des fonctionnalités modernes (typage, JIT) et une meilleure compatibilité avec les bonnes pratiques architecturales.

Concernant la bibliothèque standard, Silva reconnaît son manque d’uniformité historique, mais note que les incohérences sont progressivement corrigées, malgré la priorité donnée à la rétrocompatibilité pour éviter de perturber l’écosystème web. Le modèle stateless, bien que limitant pour certaines architectures, élimine par conception des erreurs courantes liées à la mémoire, offrant ainsi une stabilité structurelle.

L'auteur critique le format Conventional Commits, un standard populaire pour structurer les messages de commit Git, qu'il juge inefficace et contre-productif. Selon lui, ce format met l'accent sur le type de commit (comme fix ou feat) au détriment du scope (la partie du code concernée), alors que ce dernier est bien plus utile pour les développeurs, les débogueurs ou les équipes en réponse aux incidents. Le scope permet de localiser rapidement les changements pertinents dans l'historique, contrairement au type, souvent redondant ou trop restrictif.

L'article souligne que le scope devrait être obligatoire et placé en tête du message, car il répond aux besoins concrets des contributeurs, des débogueurs et des équipes de maintenance. À l'inverse, le type est jugé superflu, car le libellé du commit suffit généralement à en déduire la nature. L'auteur dénonce ainsi une priorisation inversée dans le standard, qui complique plutôt que simplifie la compréhension de l'historique des modifications.

L’article explique comment vérifier l’état de santé d’un disque dur sous Linux à l’aide de l’outil smartctl, intégré au paquet smartmontools. L’auteur détaille la procédure sur un système live (comme GRML), en utilisant des commandes comme lsblk pour identifier le disque et smartctl pour exploiter les données SMART, un système de surveillance embarqué dans la plupart des disques.

L’auteur illustre la méthode avec un exemple concret : après avoir repéré le disque (/dev/sda), il vérifie d’abord sa compatibilité SMART avec smartctl --health --info, puis lance un test rapide (--test short) dont la durée est estimée via --capabilities. Les résultats, affichés avec --log selftest, permettent de confirmer l’absence d’erreurs avant une éventuelle utilisation.

Si les tests courts sont concluants, un test long (--test long) peut être effectué pour une analyse plus approfondie, bien que plus longue (jusqu’à 56 minutes). L’article souligne l’utilité de privilégier les options longues (--health au lieu de -H) pour une meilleure lisibilité des commandes.

Ce tutoriel explique comment réinitialiser intégralement les disques d’une machine Linux avant une réinstallation ou un reconditionnement. L’auteur détaille d’abord l’identification des disques et partitions avec lsblk, puis la suppression des configurations RAID résiduelles via mdadm et sgdisk. Il souligne que wipefs ne supprime que les métadonnées, laissant les données accessibles, contrairement à shred qui les efface définitivement en plusieurs passes aléatoires.

Win11Debloat est un script PowerShell léger conçu pour simplifier la personnalisation et l'optimisation de Windows 10 et 11. Il permet de supprimer les applications préinstallées (bloatware), désactiver la télémétrie, les services de localisation et les fonctionnalités intrusives comme les suggestions ou les publicités intégrées. Le script offre aussi des options avancées pour les administrateurs système, comme un contrôle via ligne de commande ou la gestion des paramètres pour d'autres utilisateurs.

Disponible sur GitHub, il propose plusieurs méthodes d'exécution, allant d'une installation automatique via PowerShell à un téléchargement manuel pour les utilisateurs expérimentés. Une documentation détaillée est accessible via le wiki du projet, et la plupart des modifications peuvent être annulées si nécessaire.

Le projet est open source sous licence MIT et encourage les contributions. Une option de soutien financier est proposée pour l'auteur. L'utilisation se fait sous la responsabilité de l'utilisateur, avec un avertissement sur les risques potentiels pour le système.

L’auteur partage son parcours progressif dans l’utilisation de l’intelligence artificielle, depuis les outils grand public jusqu’à des solutions plus techniques et locales. Il décrit cinq niveaux d’apprentissage, commençant par l’usage basique de ChatGPT dans un navigateur, où l’outil a montré ses limites, notamment en générant des réponses incorrectes ou en tournant en rond malgré des demandes précises. Cette première étape, bien que limitée, permet de saisir le potentiel des modèles de langage.

Il aborde ensuite l’installation de modèles locaux via des outils comme Ollama ou Hugging Face, soulignant l’importance de paramètres comme la taille du contexte (limitant les hallucinations) et la température (contrôlant la créativité). Bien que ces solutions offrent une alternative aux services externes, elles restent moins performantes en rapidité et en qualité, mais permettent une meilleure maîtrise des ressources et des coûts. L’auteur mentionne aussi l’achat d’une carte graphique dédiée pour améliorer les performances, un investissement justifié par son intérêt pour l’autonomie technologique.

L’audit d’un projet Symfony legacy nécessite une stratégie pour éviter les modifications répétées. L’auteur illustre ce problème avec un exemple concret : un champ broadcast stocké en chaîne de caractères ("Y"/"N") dans la base, mais utilisé comme booléen dans le code, entraînant des incohérences entre contrôleurs et entités. Corriger d’abord le contrôleur puis l’entité implique un double travail, ce qu’il faut anticiper.

Trois approches d’audit sont comparées. L’approche top-down (contrôleurs en premier) est intuitive mais inefficace, car elle révèle des problèmes d’entités sans pouvoir les résoudre immédiatement. L’approche verticale (par fonctionnalité) est cohérente mais risquée sur un projet legacy, car les règles transverses (comme les conventions de nommage) émergent progressivement, rendant l’audit fragmenté et sujet à débats.

L’auteur recommande une approche bottom-up (entités en premier) : uniformiser d’abord le modèle de données (types, conventions, traits Doctrine), puis remonter vers les contrôleurs. Bien que moins visible, cette méthode évite les incohérences et permet un audit propre des couches supérieures, sans retouches ultérieures.

Ce billet de blog, deuxième partie d’une série, explique comment renforcer la sécurité d’une application au-delà du contrôle d’accès (RBAC) pour répondre aux exigences SOC 2. L’auteur propose une architecture à trois bases de données distinctes (données, audit et clés) pour isoler physiquement les informations sensibles, garantissant ainsi l’intégrité des logs et une gestion sécurisée des clés de chiffrement. L’isolation physique et logique des bases de données limite les risques de compromission globale en cas d’attaque ciblée.

Pour assurer l’intégrité des logs, l’auteur recommande l’utilisation du Outbox Pattern combiné à Symfony Messenger. Cette méthode enregistre les intentions de journalisation dans une table dédiée au sein de la base de données principale, puis les transfère de manière asynchrone vers la base de logs (audit.db) via un worker. Cela résout les problèmes de performance et d’atomicité, évitant les incohérences entre les actions enregistrées et les logs.

Enfin, la gestion des clés de chiffrement est externalisée via un Key Management Service (KMS) avec un système de Master Key Sharding. Les clés maîtresses sont chiffrées et stockées séparément, et leur rotation est gérée de manière à limiter l’impact d’une éventuelle compromission. Cette approche renforce la sécurité de l’infrastructure tout en respectant les principes de SOC 2.

L’article aborde la notion de « bon code » dans un contexte où l’IA facilite la génération de code, tout en soulignant que sa qualité reste un enjeu majeur. L’auteur s’appuie sur les travaux de Simon Willison pour définir un code efficace : il doit fonctionner correctement, être validé par des tests et des vérifications, et résoudre un problème réel plutôt qu’un besoin technique mal ciblé. La robustesse face aux erreurs, la simplicité, la documentation à jour et l’évolutivité sont également mises en avant.

L’auteur insiste sur l’importance de gérer les cas d’échec avec des messages exploitables et d’éviter la complexité inutile, tout en respectant des critères non fonctionnels comme la sécurité ou la maintenabilité. Ces principes, valables avant l’ère de l’IA, deviennent encore plus cruciaux avec l’automatisation, car ils garantissent la fiabilité et la pérennité des solutions produites.

Le pattern Transactional Outbox est présenté comme une solution élégante pour synchroniser une base de données PostgreSQL et un message broker comme RabbitMQ, évitant les problèmes des transactions distribuées (2PC). Contrairement à l'approche classique qui risque de publier un message sans que la transaction SQL ne soit validée, ce pattern repose sur l'écriture d'un événement dans une table dédiée au sein de la base de données, garantissant ainsi l'atomicité. Un job asynchrone se charge ensuite de publier le message dans RabbitMQ une fois la transaction principale réussie.

L'auteur souligne les limites des transactions distribuées (2PC), notamment l'absence de support XA pour RabbitMQ, les pénalités de performance et la dégradation de la disponibilité globale du système. Le pattern Transactional Outbox contourne ces problèmes en centralisant la fiabilité sur la base de données, simplifiant ainsi l'architecture tout en maintenant la cohérence des données.

La mise en œuvre pratique implique une transaction unique pour sauvegarder l'entité et l'événement dans la base, suivie d'un processus asynchrone pour publier le message. L'utilisation d'un verrou distribué (SchedulerLock) permet d'éviter les doublons dans un environnement multi-instances, offrant une solution robuste et performante pour les systèmes distribués.