Blog
Notes d’un tech lead en temps partagé : architecture logicielle, revues de code, harnais IA, design systems et encadrement de petites équipes de dev.
Multi-tenant : les quatre niveaux de séparation des données
Un SaaS qui gère des données sensibles doit séparer celles de chaque client. Quatre niveaux, du tenant_id à l’infra dédiée, et celui que je choisis souvent.
Pourquoi je me lance à 100 % sur le développeur un jour par semaine
Cinq profils quasi identiques m’ont demandé la même chose : un développeur qui surveille leurs arrières, sans temps plein. J’en fais mon métier.
Le marché des développeurs est en pleine mutation
Les grosses équipes de dev se réduisent à cause de l’IA. Pendant ce temps, les PME créent leurs outils internes et auront besoin d’experts quelques jours par mois.
Un « Model », c'est quoi ? Deux choses qui n'ont rien à voir
« Model » désigne le Model d’un ORM comme le domain model du DDD. Les confondre fait croire qu’on a modélisé son métier alors qu’on a décrit ses tables.
Functional Core, Imperative Shell : la fin des mocks partout
Le talk Boundaries de Gary Bernhardt (2012) reste un des meilleurs conseils de testing : séparer décisions et actions, ne passer que des valeurs entre les deux.
Le TJM à l’expérience ne mesure plus rien
La grille de TJM reposait sur les années d’expérience parce que le clavier bornait l’écart entre bons et mauvais développeurs. Avec l’IA, ce goulot saute.
dependency-cruiser : un capteur computationnel pour vos agents IA
dependency-cruiser cartographie les imports et fait échouer la CI quand une frontière est violée. Un capteur pour l’IA, qui exige une architecture claire.
Harnais IA : guides et capteurs, les quatre cases à remplir
Un harnais, c’est tout ce qui, dans un agent, n’est pas le modèle. Deux axes, quatre cases, et une conclusion qui fait mal sur la harnessability d’une codebase.
Créer un produit est simple. La distribution, non.
Construire un produit dépend des développeurs. Vendre, onboarder et retenir des clients, non. Un plan simple pour les porteurs de projet tech.
Vos tests sont verts, mais ça ne prouve rien : le mutation testing
Le coverage mesure les lignes traversées, pas celles vérifiées. Le mutation testing mesure si vos tests détectent, vital quand des agents écrivent les tests.
Le développeur senior à mi-temps : un nouveau modèle de freelancing
Dans les boîtes où le produit n’est qu’un support au business, le vibe-coding atteint vite un mur. Un senior quelques jours par mois suffit souvent à le lever.
Vertical Slice Architecture : ranger le code par requête
Ajouter un champ touche six fichiers dans quatre dossiers ? La fonctionnalité n'est rangée nulle part. La VSA de Jimmy Bogard range le code par requête.
Le prochain goulot d’étranglement du développement, c’est la RAM
L’IA a déplacé le bottleneck de l’écriture vers la relecture. Le suivant est matériel : cinq agents en parallèle demandent une machine que peu auront.
Combien de vos règles d’architecture cassent le build ?
Avec l’IA, une architecture standardisée devient un atout : chaque règle vérifiable par une machine est une contrainte, les autres ne sont que des intentions.
Dummy, stub, spy, mock, fake : cinq doublures, une seule question
Les cinq types de doublures de test se confondent facilement. Une question posée à la doublure, tirée de Meszaros, suffit à les distinguer pour de bon.
Trois questions pour choisir le bon outil pour votre prochain test
Test unitaire pur, intégration, Fake ou doublure qui enregistre les appels : une stratégie simple en trois questions pour choisir sans hésiter.
« A dépend de B » : de quoi parle-t-on exactement ?
Une dépendance peut être vue par le compilateur, par un test, ou par personne. Trois questions pour rester précis, entre développeurs comme face à une IA.
Une « couche » en architecture logicielle, c'est quoi ?
Abstraction, technique, flux d'appel, dépendances, déploiement : « couche » désigne cinq découpages différents, et votre programme les a sans doute tous.
Clean Architecture : la Dependency Rule, et rien d'autre
Ce que Robert C. Martin extrait en 2012 des architectures Hexagonale, Onion et consorts : une seule règle vérifiable dans le code, la Dependency Rule.
L'Onion Architecture : le code métier au centre
Jeffrey Palermo, 2008 : une règle de dépendance unique pour que le code métier ne subisse plus les changements de technologie.