L'auteur partage son parcours personnel et professionnel avec Kubernetes, soulignant qu’il n’existe pas de réponse universelle. Il a découvert l’orchestration via Docker Swarm, puis Kubernetes à travers des services managés comme AKS (Azure) et GKE (Google Cloud), avant d’expérimenter des solutions plus légères comme K3S et Talos Linux. Chaque approche—services managés, déploiements "the hard way", ou outils simplifiés—offre des avantages et des limites, selon le contexte et les besoins. L’important est de choisir la méthode qui suscite la curiosité et permet d’apprendre en pratiquant, car Kubernetes et son écosystème évoluent constamment, offrant de multiples angles d’entrée. L’essentiel reste d’oser explorer et comparer, sans crainte de se tromper.

Un analyste confronté à une requête lente sur une table de 150 millions de transactions (2 minutes d’exécution, parfois des timeouts) a optimisé son code en utilisant une CTE (Common Table Expression) avec WITH. Au lieu de joindre d’abord les tables puis de filtrer, la CTE filtre d’abord les transactions récentes (20M de lignes au lieu de 150M), réduisant le temps d’exécution de 127 à 11 secondes. En allant plus loin et en agrégeant directement dans la CTE, il a même descendu ce temps à moins de 6 secondes. La clé ? Filtrer tôt pour alléger la charge de jointure, clarifier la logique, et exploiter les optimisations des moteurs modernes (PostgreSQL 12+, BigQuery). Attention toutefois : les performances varient selon le SGBD (risque de matérialisation en tables temporaires sous MySQL ancien). Une leçon simple : une requête bien structurée = des gains de performance majeurs.

L'auteur explique que les bons ingénieurs logiciels fonctionnent en boucle : ils construisent un modèle mental des besoins, écrivent du code, comparent le résultat avec leur modèle, puis ajustent le code ou les exigences. Les LLMs, bien qu’efficaces pour générer ou modifier du code, échouent à maintenir ces modèles mentaux cohérents. Ils se perdent face aux échecs de tests, hallucinent des détails, et peinent à gérer le contexte ou à zoomer entre le global et le local — des capacités essentielles pour résoudre des problèmes complexes. Même avec des avancées, ils restent des outils d’assistance, pas des développeurs autonomes : c’est à l’humain de garantir la justesse des exigences et du code, surtout sur des projets non triviaux. On préfèrera donc miser sur une collaboration humain-agent, mais le développeur reste aux commandes.

Cet article détaille la configuration d’un serveur rsyslog sous Ubuntu 24.04 avec authentification TLS, afin de centraliser et chiffrer les logs en transit sur le réseau. Il explique pourquoi utiliser rsyslog (notamment pour sa compatibilité avec divers équipements et sa simplicité d’intégration), puis présente les étapes clés : génération de certificats (PKI interne ou auto-signés), configuration du serveur avec gtls pour valider les clients via leur certificat (mode x509/name ou empreinte SHA256), et gestion des droits sur les fichiers de certificats. Plusieurs scénarios sont abordés : authentification mutuelle, chiffrement seul, ou utilisation de certificats publics pour l’exposition sur Internet. Des exemples de filtrage des logs (par IP, chaîne de caractères) et de tests de configuration sont aussi fournis, le tout sur le port 6514/TCP. Une ressource utile pour sécuriser la centralisation des logs en respectant les bonnes pratiques (ISO27001, HDS, etc.).

Dans cet article, Milan Milanović partage les cinq livres qui ont marqué sa carrière d’ingénieur et son évolution vers le poste de CTO. Il explique comment "The Pragmatic Programmer" lui a appris à écrire du code professionnel, durable et adaptable, en insistant sur l’importance de l’itération rapide et de la responsabilité collective. "Designing Data-Intensive Applications" a transformé sa vision de l’architecture des systèmes, en mettant l’accent sur les compromis entre cohérence, disponibilité et tolérance au partitionnement, ainsi que sur la rigueur dans le choix des bases de données. "A Philosophy of Software Design" l’a aidé à lutter contre la complexité du code en privilégiant des modules profonds et bien conçus, faciles à maintenir. "Thinking, Fast and Slow" de Daniel Kahneman lui a révélé l’impact des biais cognitifs sur la prise de décision, l’incitant à adopter une approche plus analytique et moins intuitive. Enfin, "The 7 Habits of Highly Effective People" a renforcé ses compétences en leadership, en lui apprenant à se concentrer sur ce qu’il peut contrôler, à écouter activement et à investir dans son développement personnel. Ces ouvrages, au-delà des compétences techniques, lui ont offert des modèles mentaux essentiels pour devenir un meilleur architecte, décideur et leader. Une lecture inspirante pour quiconque souhaite allier expertise technique et croissance personnelle.

Un mémo des actions à faire pour passer de Debian 12 à 13

L'auteur présente 3 techniques pour déclencher un téléchargement de fichier :

• un attribut introduit en HTML5
• la simulation d'un clic en JavaScript, par exemple suite à une action utilisateur
• dans le cas du téléchargement de données générées dynamiquement, les transformer en Blob et utiliser la méthode précédente

Le débat entre monolithe et microservices évolue vers un équilibre pragmatique : la simplicité, l’expérience développeur et la maintenabilité deviennent prioritaires. Les entreprises, après avoir expérimenté les coûts élevés et la complexité des microservices, se tournent de plus en plus vers des architectures modulaires ou des monolithes bien structurés, comme en témoignent des exemples comme Amazon Prime Video, qui a réduit ses coûts de 90 % en revenant à une approche monolithique. La culture du "vibecoding" (optimisation du bien-être et de la productivité des développeurs) favorise aussi les monorepos et les architectures centralisées, tout en intégrant des outils modernes pour garder une flexibilité. L’enjeu n’est plus de choisir un camp, mais d’adapter l’architecture au contexte, en privilégiant la clarté, la résilience et l’alignement d’équipe, avec la possibilité de basculer entre les deux approches selon les besoins. Les outils comme Terraform, les devcontainers ou les CI/CD avancées permettent désormais de repenser les choix architecturaux avec plus d’intention et moins de dogmatisme.

Les branches divergentes : source de conflits en push/pull
Erreurs classiques :

! [rejected] main -> main (non fast-forward)
fatal: Need to specify how to reconcile divergent branches.

Qu’est-ce qu’une branche divergente ?
Local et distant ont chacun des commits que l’autre n’a pas.

4 états possibles avec une branche distante :

1. À jour
2. Besoin de pull
3. Besoin de push
4. Divergée (il faut choisir comment résoudre le conflit)

Comment détecter une divergence ?

git fetch
git status
# Exemple de sortie :
# "Your branch and ‘origin/main’ have diverged, and have 1 and 1 different commits each."

Solution rapide :

git pull --rebase

(Mais il existe d’autres options, comme merge.)

À retenir :

• git fetch récupère les derniers commits.
• git pull = git fetch + git merge (ou rebase).

Git affiche constamment des diffs – mais parfois, ils semblent étranges.

Pourquoi ?

• Git ne comprend pas les intentions : un renommage (git mv old.py new.py) est traité comme une suppression + ajout.
• L’algorithme de diff compare simplement deux versions et essaie de résumer les changements de façon lisible… mais pas toujours avec succès.

Astuce :

• Git propose plusieurs algorithmes de diff. Par exemple, pour mieux gérer les réorganisations de code :

  git diff --histogram

Git utilise un processus de commit en 2 étapes :

1. Ajouter les modifications à la zone de staging (git add, git rm, git mv).
2. Valider avec git commit.

La zone de staging, 3 noms pour une seule chose :

• staged (--staged)
• cache (--cached)
• index (--keep-index)

Astuces :

• git add -p permet de commiter seulement certaines parties d’un fichier.
• git diff ne montre que les modifications non staged :
  • git diff HEAD → toutes les modifications non commitées.
  • git diff --cached → seulement les modifications staged.
• git commit -a ne prend pas en compte les nouveaux fichiers (il faut les add avant).

Git n’a pas de bouton "Annuler"
Pas de unadd, uncommit, unmerge ou unrebase. À la place, il y a git reset – puissant, mais dangereux.

Comment fonctionne git reset ?

• La plupart des commandes Git avancent la branche (git commit, git merge, git pull).
• git reset peut déplacer la branche n’importe où : en arrière, en avant, ou "de côté".
• Exemple : git reset HEAD^ force la branche à pointer sur le commit parent, et déstage les changements.

Options clés :

• Par défaut : conserve les modifications dans le répertoire de travail.
• --hard : supprime les modifications non commitées (attention, irréversible !).

Risques :

• Facile de "perdre" des commits en reculant une branche.
• Avec --hard, perte définitive des changements non commités.

Le reflog Git, c’est quoi ?
Un historique de tous les IDs de commit qu’une branche, un tag ou HEAD a déjà pointés. Utile pour retrouver des commits "perdus".

Différences avec git log :

• Le reflog est local (non partagé entre dépôts).
• Il montre l’état des branches avant un rebase (contrairement à git log).
• Les entrées de plus de 90 jours peuvent être supprimées par git gc.

Comment l’utiliser ?

1. Lancer git reflog (ou git reflog BRANCH pour moins de bruit).
2. Chercher un message de commit pertinent.
3. Inspecter le commit avec git show $COMMIT_ID ou git log $COMMIT_ID.
4. Récupérer le commit avec git reset --hard $COMMIT_ID ou git branch $NAME $COMMIT_ID.

Limites :

• Le reflog d’une branche est supprimé si la branche l’est.
• Inutile pour récupérer un stash supprimé (git stash drop).
• Les entrées ne correspondent pas toujours aux commandes Git exécutées.

Dernier recours :
Si le commit n’est plus dans le reflog, utiliser git fsck pour lister les commits non référencés.

Exposer son localhost sur internet est indispensable pour tester des webhooks, partager des démos en direct, ou tester sur des appareils mobiles réels. L’outil open source Tunnelmole permet de créer un tunnel sécurisé entre un serveur local et une URL publique en quelques secondes. Après avoir lancé son serveur local (ex: localhost:3000), il suffit d’installer Tunnelmole (npm install -g tunnelmole ou via un script d’installation), puis de lancer tmole 3000 pour obtenir une URL publique HTTPS accessible partout. Idéal pour le développement, le débogage ou la collaboration, Tunnelmole est transparent, open source et permet même l’auto-hébergement pour plus de contrôle. Une solution simple et efficace pour sortir de l’isolement de localhost.

Ce dépôt propose une collection d’agents personnalisés pour Claude Code, conçus pour assister les développeurs dans diverses tâches.

Installation

• Pour un projet spécifique : Copier les agents dans .claude/agents/ à la racine du projet.
• Pour une utilisation globale : Copier les agents dans ~/.claude/agents/.

Agents disponibles

• code-refactorer : Aide au refactoring de code
• content-writer : Rédaction de contenu
• frontend-designer : Assistance en design frontend
• prd-writer : Rédaction de documents de spécifications produit
• project-task-planner : Planification de projets et découpage des tâches
• security-auditor : Audit de sécurité
• vibe-coding-coach : Coaching et guidance en codage

Utilisation
Une fois installés, Claude Code détecte et utilise automatiquement ces agents selon les besoins.

Symfony 7 utilise les attributes PHP (syntaxe #[...]) pour remplacer les annotations et déclarer des métadonnées directement dans le code. L’article montre comment créer des attributes sur mesure (ex : #[Audit] pour le logging, #[FeatureToggle] pour gérer des fonctionnalités, #[RequiresRole] pour la sécurité, #[Throttle] pour limiter les requêtes) et les exploiter via des event listeners. Ces outils simplifient la maintenance, évitent la duplication de code et rendent le comportement du code plus explicite. Les attributes peuvent aussi cibler des classes et être packagés en bundles réutilisables. Une fonctionnalité puissante pour structurer vos applications Symfony de manière déclarative et élégante.

L'auteur explique pourquoi repenser les architectures logicielles en privilégiant les événements plutôt que les requêtes synchrones. Au lieu de s’appuyer sur le modèle classique « demande/réponse », l’approche event-driven (EDA) émet des faits immuables (ex : UserSignedUp, OrderPlaced) via des brokers (Kafka, RabbitMQ, etc.), permettant un découplage total, une scalabilité asynchrone et une observabilité native. Les avantages sont majeurs : flexibilité, extensibilité sans modifier les sources, et traçabilité des actions. Des géants comme Shopify, Netflix ou Stripe l’utilisent pour synchroniser des services, déclencher des workflows ou alimenter l’analytics. Attention cependant aux pièges : surcharge des payloads, absence d’idempotence, ou manque de versioning. L’EDA n’est pas une solution universelle (coûts, complexité accrue), mais elle transforme la résilience et l’évolutivité des systèmes — à condition d’adopter une discipline rigoureuse et de traiter les événements comme des contrats versionnés.

6 semaines avec Claude Code : Orta Therox (Puzzmo) raconte comment cet outil d’IA a révolutionné sa productivité, lui permettant de réaliser en solo des mois de tech debt (migrations, tests, refactoring, etc.) en quelques semaines, sans surcharge. Claude Code agit comme un pair programmer ultra-rapide, accélérant prototypage et maintenance, tout en laissant l’humain garder le contrôle et la responsabilité finale. Une avancée majeure, mais qui pose question sur l’évolution du métier de dev.

Balises <strong>, <b>, <em>, <i> : quand et pourquoi les utiliser ?
En HTML, le choix entre ces balises dépend avant tout de la sémantique : <strong> et <em> apportent du sens (importance ou emphase, utiles pour les lecteurs d’écran), tandis que <b> et <i> servent à une distinction visuelle ou typographique sans valeur sémantique. <strong> souligne un contenu crucial (avertissements, instructions), <em> modifie le sens d’une phrase par l’emphase. <b> attire l’attention sans importance particulière, et <i> s’emploie pour des termes techniques, noms d’œuvres ou mots étrangers. Pour un style purement décoratif, privilégiez le CSS avec <span>. L’objectif : séparer structure (HTML) et présentation (CSS) pour un code propre et accessible.

Points clés

1. L’internationalisation, bien plus que la traduction

L’i18n ne se limite pas à traduire du texte : elle inclut aussi le formatage des dates, des nombres, des listes, la pluralisation, etc., selon les attentes culturelles de chaque locale. L’API Intl de JavaScript offre une solution native, performante et standardisée pour gérer ces aspects, sans dépendre de bibliothèques tierces lourdes.

2. Qu’est-ce qu’une locale ?

Une locale (en-US, fr-FR, ja-JP, etc.) définit non seulement la langue, mais aussi la région, le script, et d’autres préférences culturelles. Elle permet d’adapter finement l’affichage des données.

3. Les principaux outils de l’API Intl

• Intl.DateTimeFormat : Formate les dates et heures selon les conventions locales (ex. : 27/06/2025 vs June 27, 2025).
• Intl.NumberFormat : Affiche les nombres, devises et unités avec les séparateurs et symboles locaux (ex. : 123,456.79 $ vs 123.456,79 €).
• Intl.ListFormat : Génère des listes naturelles avec les conjonctions adaptées (ex. : « pommes, oranges et bananes » vs « apples, oranges, and bananas »).
• Intl.RelativeTimeFormat : Affiche des expressions temporelles relatives (« hier », « dans 3 mois ») de manière localisée.
• Intl.PluralRules : Détermine la catégorie de pluralisation (singulier/pluriel, mais aussi « zero », « one », « two », etc. pour l’arabe).
• Intl.DisplayNames : Fournit les noms localisés des langues, régions ou scripts (ex. : « French » vs « français »).

4. Avantages

• Natif : Intégré à tous les navigateurs modernes, sans besoin de polyfills.
• Performant : Réduit la taille des bundles et améliore les performances.
• Flexible : Permet de surcharger la locale par défaut (via navigator.language ou un attribut lang en HTML).

5. Cas d’usage

• Afficher des prix, dates ou listes adaptés à l’utilisateur.
• Gérer la pluralisation complexe (ex. : arabe, russe).
• Éviter les solutions maison ou les bibliothèques externes.

6. Limites

L’API Intl gère le formatage des données, mais pas la traduction de contenu, la typographie RTL/LTR, ou les nuances culturelles profondes.

7. Ressources utiles

• Documentation MDN sur Intl
• Spécification ECMA-402

Pourquoi l’utiliser ?
L’API Intl simplifie l’internationalisation tout en respectant les standards du web. Idéal pour des applications multilingues légères et maintenables.