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

Le mythe du side project obligatoire

Thu, 10 Sep 2026 00:00:00 +0200

Il y a un mythe fortement ancré dans la tête des développeurs, sur l’importance d’avoir des side projects. Cassons-le immédiatement. Non, il n’est pas obligatoire d’avoir un side project pour être un bon développeur.

C’est une injonction que j’entends régulièrement: avoir un profil Github vide serait le signe d’un manque de passion ou d’implication. On voit même parfois passer des offres d’emploi où il est fortement recommandé d’avoir un side project.

Bien entendu, quand l’envie est là, un side project apporte quelque chose qu’il n’est pas toujours facile d’avoir en entreprise: un terrain de jeu et d’expérimentation où l’erreur n’a aucune conséquence. Pas de client, pas de contrainte de production, pas d’échéance. Il est alors plus facile de pouvoir tester une architecture, un nouveau framework, une nouvelle bibliothèque. Faire, défaire et recommencer autant de fois qu’on le souhaite.

Durant ma carrière, j’ai connu des entreprises qui l’avaient très bien compris et qui avaient intégré cette idée dans le cadre du travail. Des projets annexes, sur le temps de l’équipe. Cela peut prendre la forme de prototypes, de preuves de concept (POC) ou d’applications plus fun et créatives. C’est d’ailleurs gagnant-gagnant: les collaborateurs montent en compétence, et ce sont souvent des moments agréables qui valorisent l’entreprise.

Les side projects ne sont en aucun cas une obligation et ne devraient certainement pas être une exigence de recrutement. C’est un espace d’apprentissage utile, que l’entreprise a tout intérêt à créer elle-même.

L'IA déplace les frontières de chaque métier

Wed, 02 Sep 2026 00:00:00 +0200

J’aborde régulièrement l’IA sous l’angle du développeur et du bouleversement que cela représente dans notre métier. Mais nous ne sommes pas les seuls concernés. C’est l’ensemble des métiers du logiciel qui évolue.

Puisque l’écriture du code occupe moins de place, les développeurs se recentrent sur le produit. Ils questionnent davantage les besoins, challengent les spécifications, proposent des alternatives fonctionnelles. Autrement dit, ils font dorénavant une partie du travail qui était autrefois réservé aux product owners.

Certains PO et PM vivent mal cette évolution, comme certains développeurs vivent mal la leur. Pourtant, si le développeur peut se recentrer sur les problèmes à résoudre, le PO peut lui aussi passer plus de temps sur la découverte utilisateur, la vision, la priorisation et la relation avec le métier.

Le fond du problème n’est pas lié à l’IA, il est organisationnel. Les périmètres se chevauchent et les organisations ne les ont pas forcément explicitement redéfinis. C’est ainsi que les frictions apparaissent.

L’IA est en train de déplacer les frontières de chaque métier. Il est important que chacun puisse prendre le temps de les redéfinir.

Filtrer une collection Doctrine

Sat, 29 Aug 2026 00:00:00 +0200

Quand on doit filtrer une collection Doctrine, le premier réflexe est d’utiliser la méthode filter(). Simple et pratique, le code est plus court et lisible qu’une boucle traditionnelle.

#[ORM\Entity]
class Project
{
    #[ORM\OneToMany(targetEntity: Task::class)]
    private Collection $tasks;

    public function getPendingTasks(): Collection
    {
        return $this->tasks->filter(
            static fn (Task $task): bool => !$task->isDone(),
        );
    }
}

Néanmoins cette méthode de filtrage peut ne pas être sans conséquences.

Les collections Doctrine sont rarement utilisées comme bibliothèques de collections. Elles sont généralement utilisées avec le composant ORM pour manipuler la base de données. Si l’on reprend le code précédent, $project est une entité Doctrine qui possède une relation avec une entité Task. Or si un projet est associé à de nombreuses tâches, la méthode filter() peut être inefficace car elle va nécessiter la récupération et l’hydratation de toutes les données (potentiellement des milliers) avant de les parcourir une à une pour filtrer les tâches non terminées. Cela peut s’avérer être un désastre pour les performances.

C’est un des problèmes de gestion des collections de données avec les ORM bien moins connu que le problème N+1 car il est plus discret puisqu’il n’y a qu’une seule requête SQL qui est exécutée. Le reste se passe en mémoire.

Il est alors tentant d’extraire cette logique de filtrage dans une méthode de repository pour éviter de charger toutes les tâches en mémoire et de le faire via une requête SQL. C’est dommage, surtout lorsque l’on souhaite conserver la sémantique objet de notre appel et permettre de récupérer toutes les tâches non terminées d’un projet à partir de l’objet Project lui-même.

Il existe pourtant une seconde méthode des collections Doctrine (si la collection implémente l’interface Doctrine\Common\Collections\Selectable) permettant de filtrer les éléments, mais qui elle est bien moins connue : la méthode matching. Cette dernière prend en paramètre un objet Doctrine\Common\Collections\Criteria qui permet de définir les conditions de filtrage.

use Doctrine\Common\Collections\Criteria;

public function getPendingTasks(): Collection
{
    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('done', false));
    
    return $this->tasks->matching($criteria);
}

La différence est que Criteria n’est pas du code exécutable, mais la description d’un filtre. De ce fait, si l’on utilise une collection mémoire de type Doctrine\Common\Collections\ArrayCollection, la méthode matching va fonctionner de la même manière que la méthode filter. Par contre, dans un contexte ORM, les collections sont généralement des objets de type Doctrine\Common\Collections\PersistentCollection, la méthode matching va exécuter une requête SQL pour filtrer les éléments directement depuis la base de données.

Il y a néanmoins quelques points d’attention à avoir en utilisant matching avec PersistentCollection :

l’exécution SQL ne sera déclenchée que si la collection Project::$tasks n’a pas encore été initialisée. Dans le cas contraire, la méthode matching itérera sur la collection en mémoire,
la méthode matching retournera une nouvelle collection détachée.

Maintenant, vous vous demandez peut-être s’il est encore utile d’utiliser filter ? La réponse que j’ai envie de donner est : “ça dépend”. Tout dépendra de la donnée qui est manipulée. Faire un matching avec la légère complexité que cela implique est pertinent sur des grosses collections gérées par Doctrine ORM. Sur des collections hors ORM ou sur des petites collections persistées filter pourra faire l’affaire.

Penser problème avant de penser solution

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

En tant que développeur, quand on démarre une tâche ou un projet, on pense facilement au framework que l’on va utiliser, à la base de données, aux patterns que l’on va pouvoir mettre en place. Et si c’était une erreur ?

Car en réfléchissant de la sorte, on prend déjà des décisions avant même que le problème ne soit posé. On choisit une solution, une architecture, un outil, et ensuite on cherche la justification. N’est-ce pas penser à l’envers ?

Penser problème avant de penser solution, c’est d’abord clarifier le besoin auquel on doit répondre. Quelle est la douleur, pour qui, et dans quel but ? Ce n’est pas en pensant technique, à la manière dont on va l’implémenter dans le code et dans le produit, que l’on trouvera ces réponses.

L’IA amplifie aujourd’hui ce phénomène. Elle produit une implémentation pour n’importe quelle demande. Le coût de mise en place d’une solution a drastiquement diminué, mais celui de se tromper de problème n’a pas bougé.

Poser le problème, c’est déjà la moitié du chemin de fait. C’est du problème que découle la solution, et de la solution que découlent les outils à mettre en place. Pas l’inverse.

Écrire du code avec l'IA, c'est la partie facile

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

On parle de plus en plus de dépendance à l’IA : du code produit “trop vite” et en trop grande quantité, que l’on ne comprend pas ou que l’on ne sait plus maintenir. Mais est-ce vraiment un problème d’IA ?

Avant elle, on copiait déjà du code trouvé sur StackOverflow sans le comprendre. On reprenait déjà des projets dont plus personne ne connaissait les choix d’architecture. On livrait déjà des fonctionnalités sans test. Depuis des années, nous avons les mêmes problèmes, seuls le volume et la vitesse d’apparition ont explosé.

Ce que je vois le plus passer en revue de code, ce n’est pas “du code IA”. C’est de la logique métier dispersée, des responsabilités mélangées, des abstractions manquantes, des tests qui vérifient les implémentations plutôt que les comportements. Ce que je vois, ce sont des équipes qui ne respectent pas les bonnes pratiques d’ingénierie informatique.

Alors, quand on se pose la question de la “dépendance à l’IA”, on devrait plutôt réfléchir à ce qui est produit. Pensez pratiques et architectures logicielles. Pensez niveau d’abstraction, stratégie de tests, découplage et responsabilités métier.

Écrire du code avec l’IA ne suffit pas, c’est la “partie facile”. Écrire du code de qualité, c’est-à-dire du code maintenable et qui sait évoluer facilement avec le temps, c’est là le vrai défi à relever, que le code soit écrit avec l’IA ou non.

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.