Résumé
Cet article est né de trois conversations. Un CTO avait déployé Sonar et GitLab à l’échelle, à un coût réel, et ne pouvait démontrer à sa direction ni l’utilité de son travail ni son retour sur investissement. Un directeur technique avait mis en place le pair programming et les revues de code et butait exactement sur le même mur. Et un DSI ne connaissait ni les objectifs ni les enjeux de son propre chantier DevOps. Je voulais parler des bénéfices des bonnes pratiques de développement, de l’excellence technique, dans des termes qui survivent à cette conversation.
Le problème n’est pas que les pratiques soient mauvaises. C’est qu’on les vend avec les mauvais arguments. La complexité cyclomatique, un algorithme passé du quadratique au linéaire: pour un décideur, cela ne porte aucune valeur métier visible. Une bonne pratique hors contexte devient une mauvaise pratique; avant d’en déployer ou d’en défendre une, il faut demander pourquoi, et quel problème elle résout.
Ma proposition tient à deux niveaux de mesure. Un niveau tactique, pour l’équipe, avec des indicateurs opérationnels; un niveau stratégique, pour le management, avec des indicateurs de performance et de création de valeur. Et accepter que toute pratique ne convient pas à tout contexte: une équipe de maintenance n’a pas forcément besoin de TDD quand du clean code bien appliqué suffit, et quand la dette est massive, décommissionner progressivement pour repartir sur des bases saines peut être le choix le plus sage. Imposer un outil ou une méthode à tous les projets au nom de la standardisation est une erreur fatale; une matrice des cas d’usage, par complexité, compétence requise, courbe d’apprentissage et criticité métier, est ma façon de choisir.
Le Craftsmanship ne se vend pas avec des outils ou des dogmes. Son retour n’est pas dans le TDD, Sonar ou GitLab, mais dans ce que ces pratiques rendent possible: un logiciel plus fiable, une équipe plus autonome, une vélocité plus prévisible, et au bout du compte un métier mieux servi.
Idées clés
- Toute bonne pratique hors contexte devient une mauvaise pratique: avant d’en déployer ou d’en défendre une, demander pourquoi, et quel problème elle résout.
- Les arguments techniques n’atteignent pas les décideurs; mesurer à deux niveaux, des indicateurs tactiques pour l’équipe et des indicateurs de valeur pour le management.
- Toute pratique ne convient pas à tout contexte: une équipe de maintenance peut se passer de TDD, et une dette massive appelle parfois le décommissionnement progressif plutôt que la réparation.
- Imposer un outil ou une méthode à tous les projets au nom de la standardisation est une erreur fatale; choisir avec une matrice des cas d’usage.
- Le retour n’est pas dans le TDD, Sonar ou GitLab, mais dans ce qu’ils rendent possible: fiabilité, autonomie de l’équipe, vélocité prévisible, métier mieux servi.
Pourquoi j’ai écrit cet article
Un CTO m’a expliqué qu’il avait déployé à l’échelle des outils comme Sonar et GitLab, à un coût non négligeable, sans pouvoir démontrer à sa direction ni l’utilité de son travail ni le retour sur investissement. Un autre directeur technique m’a détaillé la mise en place du pair programming et des revues de code, avec exactement la même difficulté. J’ai même rencontré un DSI qui ne connaissait ni les objectifs ni les enjeux de son chantier DevOps. Je voulais me concentrer sur les bénéfices des bonnes pratiques de développement, et plus précisément de l’excellence technique.