Jérémy DECOOL (@jdecool), Ingénieur Etudes et Développement à Lyon

L'IA n'a pas votre vécu

Wed, 12 Aug 2026 00:00:00 +0200

J’ai évoqué dans une publication précédente, l’usage de l’IA par les leaders pour construire leurs arguments, et la perte d’authenticité que cela entraîne. J’ai exactement le même sentiment côté technique.

De plus en plus, je vois des développeurs avancer des arguments qu’ils n’ont pas construits. Des réponses générées, structurées, bien tournées, mais qui ne sont pas les leurs. Et tout comme pour les leaders, cela désincarne les propos et leur fait perdre en crédibilité.

La discussion s’engage alors, on tente de comprendre pourquoi une approche plutôt qu’une autre dans le contexte en question. À l’écrit, on a une réponse générique, qui va dans le sens du développeur, qui a du sens, mais qui manque d’intention. C’est une réponse qui a du mal à convaincre. Et lorsque la discussion passe à l’oral, les échanges se vident souvent de leurs arguments car le sujet n’est pas maitrisé.

Une décision technique ne se défend pas avec des arguments génériques. Elle se défend avec du contexte et de l’expérience: la maturité du projet, les compétences de l’équipe en place, l’historique des choix précédents, les échéances. En un mot: le vécu. L’IA et les LLMs n’ont pas ce contexte.

Les meilleures idées ne viennent pas devant l'écran

Mon, 10 Aug 2026 00:00:00 +0200

Je vais régulièrement courir. Pas pour la performance, juste pour m’aérer l’esprit et être un minimum mobile, plutôt que de camper devant mon écran. Paradoxalement, c’est à ce moment que j’ai les meilleures idées qui me viennent à l’esprit.

Je pense que tous les développeurs ont connu cette situation où l’on n’arrive pas à résoudre un bug incompréhensible, ou celle où l’on tourne en rond sur une décision technique à prendre. Souvent, plus on s’acharne et moins on avance. On refait les mêmes raisonnements et on s’enferme dans une logique dont on n’arrive plus à sortir.

Pour sortir de cette boucle infernale, je vais courir. Une heure ou deux sans écran, sans notification, sans intention particulière. Juste moi et moi-même. Je pars pour me libérer l’esprit et prendre l’air, pour lâcher prise. Et c’est précisément à ce moment-là que les idées arrivent. La solution que je cherchais, l’approche que je n’avais pas envisagée et parfois même la remise en question du problème lui-même.

Tant que l’on reste en mode exécution, la tête dans le guidon, l’esprit reste enfermé dans le chemin qu’il a déjà emprunté. Lâcher prise, c’est le meilleur moyen d’explorer autre chose. Pour moi c’est courir, mais chacun a sa propre manière de s’aérer.

Prendre du recul, c’est rarement du temps perdu. C’est souvent du temps gagné.

Ce n'est pas le titre qui définit le poste, c'est ce qu'on en fait

Wed, 29 Jul 2026 00:00:00 +0200

Il y a quelque temps, je faisais passer des entretiens pour un poste. J’ai pu rencontrer de nombreux profils: développeur, “lead dev” ou “architecte” et derrière ces titres des réalités bien différentes (même à titre équivalent).

Certains pouvaient passer leurs journées à écrire du code, d’autres ne pouvaient faire que des revues. Parfois, ils ne codaient pas du tout et ils devaient gérer des plannings. Les intitulés de postes sont souvent équivalent, mais les métiers exercés n’ont parfois rien en commun.

Pourtant, on utilise souvent ces titres comme des repères pour se situer, se comparer et parfois se valoriser. J’ai croisé des développeurs qui portaient un rôle de tech lead sans en avoir le titre. À l’inverse, j’ai vu des architectes qui n’ont jamais eu la main sur des décisions structurantes.

Au final ce qui compte, ce n’est pas la ligne sur son CV. Ce sont les responsabilités que l’on porte au quotidien. Est-ce que j’ai de l’impact ? Les décisions techniques que je prends sont-elles structurantes ? Est-ce que je participe à la montée en compétence des autres développeurs ? Ce sont ces questions qui permettent de définir un poste, bien plus que son intitulé.

C’est d’ailleurs ce que l’on creuse généralement lors d’un entretien. Un titre apprend peu de chose. C’est ce que la personne a réellement fait, et qui arrive à le communiquer, qui en apprend le plus.

Ce n’est pas le titre qui définit le poste, c’est ce que l’on en fait.

Convaincre ne se délègue pas à l'IA

Wed, 22 Jul 2026 00:00:00 +0200

Depuis quelques mois, je repère de plus en plus de documents et de présentations de leads et de directeurs rédigés à coups d’IA. Ce n’est pas forcément gênant, mais le problème, c’est quand ça se voit de trop.

Il y a un style d’écriture qui trahit l’outil. Une certaine structure et des types de tournures qui se remarquent. Le texte est cohérent, mais il est désincarné.

Selon le type de document, cela ne me dérange pas. Documenter une procédure, résumer une architecture, formaliser un compte-rendu: l’IA fait ça très bien, plus rapidement et parfois mieux qu’un humain.

Le problème, c’est quand le document a pour but de convaincre, de faire adhérer une équipe à une vision ou un choix structurant. Là, ce n’est pas uniquement le contenu qui fait la force du propos, c’est la conviction de celui ou celle qui le porte.

Les convictions se nourrissent d’expériences vécues, des prises de position assumées, même si elles peuvent être imparfaites. Or, l’IA a tendance à lisser les textes et tout ça s’estompe. On reconnait le ton, le style et la forme de l’IA. C’est toute la personnalité de l’auteur du propos qui s’évapore.

Quand on souhaite transmettre une idée, partager une conviction, il est important d’utiliser ses propres mots. C’est ce qui fait tout le charisme d’un leader et sa capacité à embarquer les autres avec lui.

Attention au bruit documentaire généré par l'IA

Wed, 15 Jul 2026 00:00:00 +0200

Avec l’IA, on parle beaucoup de la rapidité et de la vitesse de génération de code. Mais, tout comme le code, générer de la documentation n’a jamais été aussi simple et rapide. En quelques secondes, l’IA produit des pages entières décrivant un projet. Mais attention à cette abondance.

Comme beaucoup, je suis convaincu de l’importance de documenter: choix d’architecture, standard d’équipe, historique et choix des décisions. La documentation est primordiale pour maintenir la connaissance au fil du temps.

Mais une documentation générée automatiquement décrit généralement le “quoi” et le “comment”. Elle dresse un état des lieux de ce qui existe, mais elle ne permet pas d’avoir le “pourquoi”.

Pourquoi cette architecture plutôt qu’une autre ? Quel compromis a été accepté, dans quel contexte et avec quelles contraintes ? Quels ont été les autres choix étudiés.

Toutes ces informations n’existent pas dans le code, elles existent dans la tête de ceux qui ont fait les choix ou qui étaient présents. Ce n’est pas pérenne.

De plus, le risque de la génération automatique, c’est de passer d’un extrême à un autre. C’est passer d’une documentation pauvre ou inexistante à un bruit documentaire où tout est écrit, mais derrière l’abondance pas d’informations significatives.

C’est aussi une quantité de documentation que personne n’a relue, que personne ne s’est appropriées et que personne ne souhaite réellement maintenir.

Une documentation n’a de valeur que si elle porte une intention. L’IA peut aider à la rédaction, à la structuration et à sa maintenance. Mais la décision de ce qui mérite d’être documenté, et surtout de conserver l’historique de ce qui a mené aux différents choix restent de la responsabilité humaine.

L’IA peut générer des pages en quelques secondes. Mais une réflexion, elle, ne se génère pas. Elle se transmet.

Push once, publish everywhere: the multi-target Git remote

Tue, 14 Jul 2026 00:00:00 +0200

Github remains the go-to forge for hosting Git projects today. But as a French guy who lives in Europe, I don’t want to depend on only one foreign platform. So, to reduce that dependency, I decided to mirror all of my repositories (public and private) on Codeberg, a European, non-profit forge.

Usually, people think a Git remote is a simple association with a URL (one remote = one destination). In reality, a remote is two things: a URL for fetching data and another one for pushing data. Using the git remote -v command, it’s possible to visualize a repository configuration:

$ git remote -v
origin  https://github.com/jdecool/repo.git (fetch)
origin  https://github.com/jdecool/repo.git (push)

Git allows to configure multiple push URLs to a remote. It’s what I do to push repository changes to Github and the Codeberg mirror:

To declare the push URLs, use the git remote set-url command with the --add and --push options:

$ git remote set-url --add --push origin git@github.com:jdecool/repo.git
$ git remote set-url --add --push origin ssh://git@codeberg.org/jdecool/repo.git

It produces the following result:

$ git remote -v
origin  https://github.com/jdecool/repo.git (fetch)
origin  https://github.com/jdecool/repo.git (push)
origin  ssh://git@codeberg.org/jdecool/repo.git (push)

Now the origin remote still fetches data from Github, but it also pushes data on two destinations. The Git configuration is stored in the .git/config file:

[remote "origin"]
    url = git@github.com:jdecool/repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    pushurl = git@github.com:jdecool/repo.git
    pushurl = ssh://git@codeberg.org/jdecool/repo.git

Now, when I push changes with git push origin main, Git will send commits to both Github and Codeberg. Both repository instances stay up to date.

But there are some important things to notice.

Fist, by default, Git uses the fetch URL for pushing as well. But after you add a first pushurl, the implicit fetch URL is no longer used, it will be replaced. So make sure to declare the original URL alongside the new one.

Secondly, this technique remains a one-way mirror. The fetch URL still contains only one URL. If some code is directly pushed to a secondly instance, those changes won’t be pulled back automatically. In a team context, prefer using the Git mirror feature from the forge server-side.

Pousser une fois, publier partout: le remote Git multi-cibles

Tue, 14 Jul 2026 00:00:00 +0200

Bien que cela commence à changer, Github reste aujourd’hui la forge de référence pour l’hébergement de projet autour de Git. Néanmoins, dans une démarche d’autonomie numérique, je ne souhaite pas dépendre uniquement de cette plateforme. Pour réduire cette dépendance, j’ai décidé de dupliquer et “mirrorer” l’ensemble de mes dépôts (publics et privés) sur Codeberg, une forge européenne et associative.

On a l’habitude de voir un remote Git comme étant une simple association avec une URL (un remote = une destination). Un remote Git distingue en réalité deux choses: une URL pour récupérer les données (fetch) et une autre pour envoyer les données (push). Vous pouvez, par exemple, les visualiser avec la commande git remote -v dans n’importe quel dépôt Git:

$ git remote -v
origin  https://github.com/jdecool/repo.git (fetch)
origin  https://github.com/jdecool/repo.git (push)

Et rien n’oblige un remote à ne posséder qu’une seule URL de push, il est possible d’en déclarer plusieurs. C’est ce que je fais pour pouvoir pousser les modifications de mes différents dépôts à la fois sur Github et le miroir Codeberg.

Pour déclarer les URLs de push, il faut utiliser la commande git remote set-url avec les options --add et --push:

$ git remote set-url --add --push origin git@github.com:jdecool/repo.git
$ git remote set-url --add --push origin ssh://git@codeberg.org/jdecool/repo.git

Le résultat sera le suivant:

$ git remote -v
origin  https://github.com/jdecool/repo.git (fetch)
origin  https://github.com/jdecool/repo.git (push)
origin  ssh://git@codeberg.org/jdecool/repo.git (push)

Le remote origin continue de récupérer les données depuis Github, mais il dispose désormais de deux destinations de push. Cela se traduit par la configuration ci-dessous dans le fichier .git/config:

[remote "origin"]
    url = git@github.com:jdecool/repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    pushurl = git@github.com:jdecool/repo.git
    pushurl = ssh://git@codeberg.org/jdecool/repo.git

Désormais, lorsque je pousse mes modifications via git push origin main, Git envoie mes commits à la fois vers Github et Codeberg. Les deux instances de mon dépôt restent synchronisées.

Il faudra faire attention lors de la configuration initiale. Par défaut, Git utilise l’URL de fetch pour l’envoi des données. Mais dès que l’on ajoute un premier pushurl, l’URL de fetch ne sera plus utilisée. Il faut donc bien penser à redéclarer l’URL d’origine en plus de la nouvelle.

Autre point important, cette technique reste un miroir unidirectionnel. La récupération des modifications continue de se faire via une seule URL. Si du code est poussé directement sur Codeberg, les changements ne seront pas récupérés automatiquement. Dans le cas présent, je ne le fais que sur mes dépôts personnels dont je suis le principal contributeur. Dans un contexte d’équipe, la configuration n’existant que localement sur les machines, mieux vaut se tourner vers un miroir Git configuré côté forge.

Courir après la fonctionnalité n'est pas un objectif

Wed, 08 Jul 2026 00:00:00 +0200

L’IA permet à de nombreux éditeurs logiciels de livrer de nouvelles fonctionnalités toujours plus rapidement. Elle a augmenté la vitesse de production logicielle. La tentation de toujours aller plus vite est alors grande. Les nouvelles fonctionnalités d’un logiciel étant souvent perçu comme un avantage concurrentiel. Plus il en propose, plus il semble riche et plus il paraît compétitif.

Le problème, c’est que livrer des fonctionnalités rapidement et fréquemment est compliqué. Cela se fait régulièrement au détriment de la qualité et de la stabilité. On accumule du code, les fonctionnalités s’empilent et la dette (technique et fonctionnelle) s’installe, fragilisant les fondations de l’outil.

Au milieu de tout ça, on retrouve l’utilisateur. Pour lui aussi, cela peut être difficile. Les nouveautés impliquent des changements de l’outil, et potentiellement de ses habitudes d’utilisation. Il doit alors assimiler les nouvelles fonctionnalités, les comprendre et les intégrer dans ses usages. Et à vouloir aller trop vite, on finit par le perdre en route.

Aller plus vite et courir après la fonctionnalité n’est pas un objectif en soi. Le plus important est de trouver l’équilibre entre rythme, qualité et adoption utilisateur pour construire un produit pérenne.

La Clean Architecture ne se résume pas à une arborescence de dossiers

Fri, 03 Jul 2026 00:00:00 +0200

Pour beaucoup, la Clean Architecture se résume à un découpage du code en 3 couches: Domain, Application et Infrastructure (avec éventuellement une couche de présentation). Pourtant, si l’on regarde le livre de référence sur le sujet, “Clean Architecture” de Robert C. Martin, ce découpage ne représente qu’une dizaine de pages sur les 400 que compte le livre.

L’organisation du projet est certainement la partie la plus visible de la Clean Architecture. C’est d’ailleurs ce qui en a fait son succès: une organisation claire, bien définie, où chacun sait où ranger son code. Mais la Clean Architecture ne se limite pas à une organisation de fichiers, c’est bien plus que cela.

L’ouvrage de référence aborde de nombreux autres sujets: on y retrouve les principes SOLID, des notions de cohésion et de couplage du code, la définition des frontières entre modules, la gestion des règles métier, l’isolation de la base de données et la séparation des frameworks. Autant de concepts qui, mis bout à bout, représentent ce qu’est vraiment la Clean Architecture.

Lorsque l’on se concentre sur les dossiers Domain, Application et Infrastructure, on reproduit le plus facile en oubliant le “pourquoi”. Comme toujours, il est essentiel de comprendre les principes fondamentaux, sans quoi impossible d’adapter et d’utiliser cette architecture à bon escient.

Domain Driven Design: l'essentiel est avant le code

Sat, 27 Jun 2026 00:00:00 +0200

Pour beaucoup de développeurs, voir un dossier “Domain” dans le code source d’un projet, visant à isoler la partie métier, et avoir des objets riches avec un nommage cohérent, c’est faire du DDD (Domain Driven Design). C’est certes un bon début, mais réduire le Domain Driven Design à une structure de dossier, c’est passer à côté de l’essentiel.

Le DDD, ce n’est pas qu’une affaire de découpage et d’organisation technique. C’est avant tout une approche stratégique. Identifier les différents sous-domaines, comprendre lesquels portent réellement la valeur de l’entreprise, construire un langage commun entre développeurs et experts métier. Tout cela se passe bien avant d’écrire la moindre ligne de code.

Les patterns tactiques ne sont que la partie émergée de l’iceberg. La vraie force du DDD réside dans le travail en amont: aligner le modèle de code sur la réalité du métier et faire en sorte que tout le monde parle le même langage.

Je n’ai que trop rarement vu des équipes embrasser les patterns stratégiques du DDD: définition et mise en place du langage commun (Ubiquitous Language), atelier de “context mapping” (cartographie des domaines et sous-domaines) ou d’“event storming” (modélisation d’un domaine métier en identifiant les événements clés). Au-delà de la technique, c’est pour moi ce qui fait la valeur de la conception pilotée par le domaine.

Parce que ranger son code dans un dossier “Domain” sans faire un travail de fond sur le métier, c’est confondre la technique avec la méthode.