Bienvenue dans ce premier épisode de Handzone, le podcast où les développeurs « mettent les mains dedans ». Le sujet du jour : Passion vs Raison. Faut-il suivre son cœur ou sa tête dans les décisions techniques ? Trois professionnels du développement livrent un échange dense, sincère et sans langue de bois.
Tour de table des intervenants
Gabriel, développeur fullstack depuis l’enfance, curieux, touche-à-tout, passionné de tech, désormais attiré par les enjeux métier et business.
Khalid, bientôt 40 ans, développeur web depuis 16 ans, impliqué dans les communautés open source et les meetups parisiens. Aujourd’hui Engineering Manager, il encadre et accompagne les devs dans leur progression.
Thomas, lead backend chez Minsft, mainteneur open source, consultant aux multiples expériences (monitoring, jeux vidéo, API, etc.). Il dirige une équipe de huit développeurs backend et reste très proche de la production.
Qu’est-ce que la qualité logicielle ?
Gabriel ouvre le bal : pour lui, il y a deux types de qualité — technique (architecture, tests) et fonctionnelle (fit avec le besoin). Il insiste sur la simplicité et l’efficacité.
Khalid nuance : la vraie qualité, c’est la satisfaction continue des utilisateurs. Le code « propre » n’a de valeur que s’il permet de livrer efficacement sur la durée.
Thomas rappelle que les critères varient selon les contextes. Dans certains projets, écrire des tests peut être contre-productif. Il cite des expériences en ligne de commande où les tests n’étaient pas pertinents.
Pratiques idéales vs réalité : clean architecture, TDD…
Les trois invités s’accordent : il n’existe pas de solution unique. Clean Architecture ou TDD ne sont pas des prérequis universels à la qualité.
Khalid cite l’exemple du kernel Linux : inutile d’y imposer une architecture « clean ». Certains domaines exigent la performance avant tout — et dans ces cas-là, les abstractions nuisent plus qu’elles n’aident.
Thomas ajoute un exemple concret de trading haute fréquence où le code est optimisé au cycle CPU près : impossible de faire du TDD ou de l’architecture propre dans ce contexte.
Passion contre raison : quand la passion nuit-elle ?
Gabriel identifie un point de bascule : la passion devient néfaste quand elle aveugle, empêche de prendre du recul ou d’adapter ses choix au contexte.
Thomas et Khalid partagent cette crainte des développeurs « dogmatiques », persuadés qu’un outil ou un langage est la solution à tout.
Khalid souligne que le métier évolue avec l’expérience : il faut dix ans pour comprendre profondément ce que signifie être développeur. La passion doit s’accompagner d’ouverture et de communication.
Fullstack : mythe ou réalité ?
Gabriel estime qu’un bon dev sait naviguer dans tout type de code, même s’il n’est pas expert partout.
Khalid nuance : être fullstack dans une stack donnée (React + Node par exemple), oui. Mais les expertises pointues (DBA, perf, systèmes distribués) ne peuvent pas être remplacées par un généraliste.
Thomas souligne que la frontière front/back est de plus en plus floue avec les outils modernes (Next.js, etc.), mais regrette que certains juniors ne sachent plus ce qu’est du templating classique.
C’est quoi un bon développeur ?
Gabriel : curieux, polyvalent, conscient du contexte, capable d’ajuster son approche en fonction de l’enjeu.
Khalid : quelqu’un qui sait écouter, poser les bonnes questions, communiquer, progresser.
Thomas : quelqu’un qui comprend les objectifs business, l’environnement, et qui sait s’intégrer humainement dans une équipe.
Tous s’accordent sur un point : il n’y a pas de profil universel. Le bon développeur dépend du besoin du moment, du type d’équipe, du type de produit. La communication est une compétence clé, quel que soit le profil.
En tant que lead, faut-il privilégier la qualité technique ou la cohésion d’équipe ?
Thomas : il laisse ses devs prendre des décisions, mais attend qu’ils prennent leurs responsabilités. Si une décision mauvaise est assumée et ratée, il intervient fermement.
Khalid : la cohésion est fondamentale, mais l’entreprise prime. Si une décision met le projet en péril, il tranche et fait de la pédagogie pour faire accepter son choix.
Gabriel : si tu ne convaincs pas ton équipe, c’est que tu as échoué à expliquer. Il faut préserver la cohésion tout en assumant son rôle de leader.
