Cto

Situation réelle “Je démissionne, je suis cramé.” Cette phrase arrive rarement sans avertissement. Les signaux étaient là depuis des mois. Mais personne n’a regardé, ou su les interpréter. Ce que j’ai observé : le burn-out est rarement soudain. C’est une dégradation progressive avec des signaux détectables. Le problème n’est pas l’absence de signaux, c’est l’absence de regard. Le faux problème Le faux problème serait de croire que burn-out = faiblesse individuelle. En réalité, c’est souvent un symptôme de dysfonctionnement systémique (charge excessive, manque de sens, absence de contrôle). ...

Situation réelle L’année 2024 a marqué un tournant dans l’adoption de l’IA générative par les développeurs. GitHub Copilot, ChatGPT, Claude, et tant d’autres outils promettent de révolutionner notre façon de coder. Après une année d’utilisation intensive de ces technologies, il est temps de faire le bilan : où sont les vrais gains de productivité, et quels sont les pièges à éviter ? Ce que j’ai observé : au-delà de l’effet “waouh” des premières générations de code, l’IA générative transforme bien plus profondément la façon de travailler qu’on ne l’imagine. Mais cette transformation nécessite une adoption raisonnée et un cadre d’utilisation clair. Sans ce cadre, l’IA peut créer plus de problèmes qu’elle n’en résout. ...

Situation réelle 15h de réunions rituelles par semaine. Standup 45min, retro 2h, planning 3h, review 2h, sync multiples. L’équipe croule sous les cérémonies censées l’aider. Ce que j’ai observé : les rituels peuvent créer cohésion et efficacité, ou bureaucratie et épuisement. La différence tient à leur design et leur discipline. Le faux problème Le faux problème serait de croire que plus de rituels = meilleure collaboration. En réalité, trop de rituels tuent les rituels et détruisent le temps de faire. ...

Situation réelle Dans le monde du développement logiciel, il existe une tentation récurrente : celle de tout jeter pour recommencer à zéro. Face à une application devenue difficile à maintenir, truffée de bugs ou dont le code ressemble à un plat de spaghetti, la solution de la refonte complète apparaît souvent comme la panacée. Ce que j’ai observé : la dette technique s’accumule inexorablement au fil des années dans les applications. Le code devient de plus en plus difficile à maintenir, les correctifs s’empilent sans réelle cohérence, et la documentation, quand elle existe, ne reflète plus la réalité du système. Les tests automatisés, s’ils ont été mis en place, ne couvrent souvent qu’une partie minime des fonctionnalités ou sont devenus obsolètes. ...

Situation réelle “Alice est en vacances ? On attend son retour, elle est la seule à comprendre ce système.” Alice n’est pas valorisée, elle est prisonnière. Et l’organisation est fragile. Ce que j’ai observé : les organisations créent involontairement des prisonniers de la connaissance. “Expert indispensable” sonne comme une valorisation, c’est souvent une cage. Le faux problème Le faux problème serait de croire que l’expertise concentrée est un atout. En réalité, c’est un risque majeur (bus factor = 1) et une injustice pour l’expert. ...

Situation réelle Je me souviens encore de ma première rencontre avec Astro. “C’est déjà rapide par défaut”, me disait-on. Et c’est vrai ! Mais après avoir optimisé plusieurs sites en production, je peux vous affirmer qu’Astro recèle encore de nombreux secrets de performance. Ce que j’ai observé : Astro est déjà rapide par défaut, mais il existe encore des opportunités d’optimisation significatives. Après application de toutes ces optimisations sur un site e-commerce récent, nous avons obtenu : ...

Situation réelle “On va faire du pair programming systématique.” Six mois plus tard : équipe épuisée, vélocité divisée par deux, talents partent. Le pair programming imposé sans discernement peut détruire autant qu’il peut aider. Ce que j’ai observé : le pair programming est un outil puissant dans certains contextes, contre-productif dans d’autres. Le problème n’est pas l’outil, c’est l’usage dogmatique. Le faux problème Le faux problème serait de croire que pair programming = toujours mieux. En réalité, c’est un outil à utiliser dans des situations spécifiques, pas une religion. ...

Situation réelle En tant que développeurs, nous sommes nombreux à être animés par une quête constante de perfection technique. Cette recherche d’excellence nous pousse à explorer les dernières technologies, à optimiser chaque ligne de code et à rêver d’une architecture parfaite. Ce que j’ai observé : cette obsession de la perfection technique peut se manifester de nombreuses manières. L’over-engineering : j’ai eu l’occasion de travailler sur un projet où nous avions mis en place une architecture en microservices ultra-sophistiquée pour une entreprise qui démarrait à peine. Six mois plus tard, la maintenance de cette infrastructure complexe consommait plus de ressources que le développement de nouvelles fonctionnalités. Une architecture monolithique bien pensée aurait été largement suffisante pour les premiers mois, voire les premières années. ...

Situation réelle Après avoir passé plusieurs années à accompagner des équipes dans leur transition vers l’open source, j’ai constaté une idée reçue persistante : “Il suffit de mettre son code sur GitHub pour faire de l’open source”. Cette vision simpliste cache une réalité bien plus complexe et passionnante. Ce que j’ai observé : la décision d’ouvrir son code n’est pas anodine et doit répondre à des objectifs clairs : partager votre expertise avec la communauté, bénéficier des contributions externes pour améliorer le projet, accroître la visibilité de votre entreprise dans l’écosystème tech, faciliter le recrutement de talents passionnés, améliorer la qualité du code grâce à l’examen public. ...

Situation réelle Commentaire sur une pull request : “Ça, c’est du code de junior. Refais tout.” Le développeur ne contribuera plus jamais avec la même confiance. La code review vient de passer d’outil de qualité à arme de destruction. Ce que j’ai observé : la code review est l’un des rituels les plus puissants pour la qualité ET la culture. Elle peut construire ou détruire. Rarement neutre. Le faux problème Le faux problème serait de croire que la code review sert uniquement à trouver des bugs. En réalité, elle sert à partager connaissance, aligner standards, et renforcer culture. ...