Bienvenue sur mon blog on Arnaud Langlade

Vos équipes se marchent dessus ? Le problème vient peut-être de votre codebase

contact@arnaudlanglade.com (Arnaud Langlade) — Tue, 26 May 2026 00:00:00 +0000

Au début d’un projet, tout semble simple. L’équipe est petite, la codebase est unique, et les échanges sont rapides. On avance vite, sans trop de contraintes.

Comprendre le métier avant de coder (et éviter de ralentir votre équipe)

contact@arnaudlanglade.com (Arnaud Langlade) — Mon, 18 May 2026 00:00:00 +0000

Livrer vite et livrer souvent, c’est important.
Mais ça ne sert à rien si on ne comprend pas ce qu’on construit.

Merger du code ne veut pas dire livrer

contact@arnaudlanglade.com (Arnaud Langlade) — Tue, 05 May 2026 00:00:00 +0000

Au début, on ne se rend pas vraiment compte de ce que le passage au SaaS implique.

Sur le papier, cela ressemble surtout à un changement d’infrastructure. Mais en réalité, c’est un changement beaucoup plus profond. Le mindset évolue, les contraintes changent, et surtout la manière de livrer du logiciel n’est plus la même.

Pourquoi une mauvaise stratégie de tests ralentit le delivery

contact@arnaudlanglade.com (Arnaud Langlade) — Tue, 28 Apr 2026 00:00:00 +0000

Les tests sont censés aider les équipes à livrer plus sereinement.
Mais ils servent aussi à donner du feedback rapide aux développeurs pendant qu’ils travaillent.

Le déploiement du vendredi 17h : pourquoi les grosses releases sont risquées

contact@arnaudlanglade.com (Arnaud Langlade) — Tue, 21 Apr 2026 00:00:00 +0000

Il y a quelques années, j’ai attendu deux semaines avant de déployer une fonctionnalité.

Deux semaines de travail.
Deux semaines de commits.
Deux semaines sans mise en production.

Construire moins pour livrer mieux : le vrai coût des fonctionnalités inutiles

contact@arnaudlanglade.com (Arnaud Langlade) — Tue, 14 Apr 2026 00:00:00 +0000

Quand un produit grandit, les équipes pensent souvent que leur problème vient de la complexité technique.

On accuse souvent la dette technique, la complexité du code ou le manque de tests.

Faire du logiciel, ce n’est pas juste écrire du code

contact@arnaudlanglade.com (Arnaud Langlade) — Sun, 05 Apr 2026 00:00:00 +0000

J’ai vu beaucoup d’équipes produire du code, parfois de très bonne qualité, sans jamais vraiment livrer de valeur.

Pas par manque de compétences. Mais parce que les conditions pour livrer correctement n’étaient pas réunies : une fonctionnalité trop grosse, pas de feedback utilisateur, une base technique fragile ou des mises en production trop risquées.

Fullstack, c’est quelqu’un qui est expert en rien ?

contact@arnaudlanglade.com (Arnaud Langlade) — Sat, 28 Mar 2026 00:00:00 +0000

Vous avez sûrement déjà entendu cette phrase :

« Un développeur fullstack est expert en rien. »

Il y a quelques années, je le pensais moi aussi.

Symfony, Hexagonal architecture and CQRS

contact@arnaudlanglade.com (Arnaud Langlade) — Mon, 20 Jan 2025 00:00:00 +0000

Dans cet article, je vais expliquer comment j’ai organisé mes derniers projets Symfony. J’utilise principalement l’architecture hexagonale et CQRS. Gardez à l’esprit que je ne vise pas à appliquer ces architectures de manière stricte. Je me contente de reprendre les concepts qui m’aident à créer une base de code simple et bien organisée.

Le design pattern Command Bus

contact@arnaudlanglade.com (Arnaud Langlade) — Mon, 25 Nov 2024 00:00:00 +0000

Qu’est-ce qu’un bus ?

Commençons par les bases, qu’est-ce qu’un bus ? En informatique, un bus est un système qui connecte plusieurs composants et facilite le transfert de données entre eux. Dans le contexte logiciel, ces composants sont appelés middleware. Un middleware reçoit une requête, la traite, puis renvoie une réponse. Comme illustré dans le schéma ci-dessous, le principal avantage de l’utilisation d’un bus est qu’il est facilement personnalisable. Vous pouvez ajouter autant de middlewares que nécessaire.

Le design pattern Command and command handler

contact@arnaudlanglade.com (Arnaud Langlade) — Tue, 02 Apr 2024 00:00:00 +0000

Ce modèle est vraiment intéressant et peut vous aider à gérer vos cas d’utilisation (use cases). Une command représente l’intention de l’utilisateur, tandis que le command handler réalise les actions nécessaires pour accomplir le cas d’utilisation. Approfondissons un peu ces deux concepts.

Les principes SOLID : Comprendre le principe de responsabilité unique

contact@arnaudlanglade.com (Arnaud Langlade) — Mon, 25 Mar 2024 00:00:00 +0000

Le principe de responsabilité unique (Single Responsibility Principle) est le premier des cinq principes SOLID. Il peut être le principe SOLID le plus simple à comprendre, mais il n’est pas toujours facile à appliquer, surtout si vous êtes un développeur junior. Que dit ce principe ?