Dettes technico-sociales et technico-organisationnelles, à l’origine de la dette technique

La dette technique est une problématique permanente lorsqu’on produit du logiciel. On cherche souvent à résorber cette dette, en expliquant notamment qu’il va falloir consacrer du temps à la technique (typiquement, une équipe de “nettoyeurs” pendant une semaine) pour rembourser cette dette. On va ainsi améliorer le code ici et là, afin de le rendre plus propre et plus facile à maintenir pour la suite.

Et si on essayait de comprendre la dette technique d’un point de vue “social”, en considérant les comportements des développeurs et les conséquences que cela peut avoir sur le code ?

Et si on allait même encore plus loin, en observant comment des décisions stratégiques prises en amont peuvent impacter la dette technique ?

C’est le but de cet article qui présente les concepts de dette technico-sociale et dette technico-organisationnelle. Je pense en effet qu’avant de s’attaquer à la dette technique, il faut d’abord étudier ces deux dettes.

 

La dette technico-sociale, ou l’impact de l’équipe sur le code

Pour comprendre où je veux en venir, imaginons que dans un logiciel, il n’y a aucun test automatisé sur un des composants, qui contient pourtant 2 000 lignes de code.

On suppose ainsi qu’une dette technique existe, qu’on envisagera de rembourser en rédigeant des tests unitaires pour ce composant.

Mais il y a probablement aussi une dette technico-sociale, qui explique en grande partie l’absence de tests sur ce composant. Je parie que vous avez déjà entendu ce genre de phrases :

• “C’est trop compliqué de tester ce code-là”
• “Je ne vois pas l’intérêt d’écrire de tests, j’ai lancé l’application ça fonctionnait bien”

Vous voyez la différence ? Si notre absence de tests s’explique ici par un désintérêt des développeurs pour le sujet, alors on a ici une dette technico-sociale. Il s’agit surtout de mentalités à faire évoluer. On peut trouver d’autre scénarios pour illustrer ce concept :

• Un Bus Factor [1] trop faible : une concentration d’expertise est un problème pour la suite du projet ;
• Un développeur qui préfère implémenter une solution à sa façon, sans tenir compte des directives globales, allant ainsi à l’encontre du concept de “programmation sans ego” ;
• Un développeur qui n’écrit pas de documentation car il “n’aime pas ça” ;
• Une majorité de développeurs qui ne veut pas faire de revue de code, empêchant ainsi la mise en place systématique de la pratique ;

La dette technico-sociale reflète donc les interactions entre des individus et le code.

 

La dette technico-organisationnelle, ou l’impact de l’entreprise sur le code

Allons maintenant encore plus loin. Reprenons le scénario précédent et imaginons désormais que pour expliquer une absence de tests, les propos suivants sont exprimés :

• “Rédiger des tests ça coûte cher, ça double le temps de développement ! “
• “On ne nous demande pas spécialement d’écrire des tests”

Ici, on remonte encore un niveau au-dessus dans l’organisation, là où les directives en termes de qualité sont définies. Si on considère qu’écrire des tests ça prends du temps, alors forcément derrière on risque de voir peu de tests.

On a ici une dette technico-organisationnelle. Ce choix assumé implique in fine une absence de tests unitaires automatisés. On peut là encore trouver d’autre scénarios pour illustrer cette idée :

• On fait pression sur les développeurs, en leur demandant de livrer à tout prix, tant pis pour l’état du code ;
• On veut diminuer la dette technique, mais on n’a aucun budget prévu pour les 12 mois qui viennent sur le sujet ;
• On n’a pas d’objectif précis quant à la gestion de notre dette technique (test rapide : prenez un développeur au hasard et posez-lui la question : “sais-tu s’il faut diminuer la dette sur ton projet ? ne pas l’augmenter ? ou bien on ne s’en préoccupe pas ?” ; s’il ne se prononce pas, c’est qu’il n’y a pas d’objectif ou que ce dernier est mal communiqué)

Finalement, on voit que les 3 dettes sont assez liées. Cela fait d’ailleurs penser à la méthode des 5 Pourquoi, exercice intéressant à faire lorsqu’on tombe sur un code impacté par la dette technique.

 

Si on résume

La dette technique concerne le code. On l’étudie souvent grâce aux outils de qualimétrie logicielle, avec des cartographies du code colorées de vert et de rouge ;

La dette technico-sociale concerne les comportements au niveau de l’équipe, les habitudes de travail des développeurs, les interactions entre eux et leur façon de travailler ensemble ;

La dette technico-organisationnelle concerne le “management” , la stratégie claire et partagée sur la qualité logicielle et les moyens mis en oeuvre ;

On pourrait presque ainsi dire que la dette technique, que l’on mesure via des outils, pourrait être estimée à partir de la dette technico-organisationnelle et technico-sociale. Imaginez en effet que vous arrivez dans la direction IT d’un éditeur de logiciels, qui n’a aucune idée de ce qu’est la dette technique et qui n’investit pas un euro dans la qualité logicielle. En plus de cela, dans les équipes de développement, chacun·e code à sa façon, il n’y a pas de conventions de rédaction, de bonnes pratiques établies… Allez, disons-le franchement, il y a peu de chance qu’on ait ici une faible dette technique ! Par contre, il y a de la dette technico-organisationnelle et technico-sociale à adresser avant toute chose : on aura beau nettoyer le code dans tous les sens, le problème reviendra dans quelques mois, pour les mêmes raisons qui expliquaient la précédente dette technique.

Note : si une équipe s’auto-gère, dispose de moyens financiers et humains, et décide elle-même de sa stratégie de dette technique, alors elle sera tout simplement la source des dettes technico-sociales et technico-organisationnelles.

 

Que peut-on faire pour rembourser ces dettes ?

Pour la dette technico-sociale, c’est principalement de la conduite du changement (qu’on préfère désormais nommer “pilotage de l’innovation”) à mener, pour déclencher un déclic auprès des équipes. Pour rappel, les 3 piliers de la conduite du changement sont :

• la participation : on se concerte au plus tôt avec toutes les personnes qui sont impliquées, afin d’établir ensemble une ligne directrice correspondant au mieux à leurs attentes. On consulte ainsi les personnes proches du code et de la technique, afin de ne pas présenter une feuille de route décorrélée de la réalité.
• la communication : tout au long de la mise en place du changement, on informe tous les acteurs et toutes les actrices concernés, facilitant ainsi l’acceptation et la compréhension du projet. On rappelle ainsi les bonnes pratiques et les objectifs de l’entreprise en termes de gestion de la dette technique, en mettant l’accent sur la sensibilisation.
• la formation : on travaille sur l’amélioration continue des équipes et la montée en compétences. Etape indispensable pour réussir, on pense y ici à l’organisation des sessions de formation, des ateliers Clean Code, des exercices pratiques de rédaction de tests ou de refactoring… on entretient la culture qualité dans l’équipe.

D’ailleurs, toute conduite du changement fera passer les individus dans un éventail de réactions émotionnelles bien identifiées : déni, colère, peur, négociation et résignation. Vous imaginez alors que l’accompagnement des acteurs est un critère clé de réussite.

Pour la dette technico-organisationnelle, il s’agit de bâtir un terreau favorable qui constituera le socle de la démarche :

• Clarifier une orientation stratégique : Quelles sont nos attentes en terme de dette technique ?
• Mettre à disposition des moyens : adopter une vision c’est une chose, la mettre en oeuvre en est une autre. Pour être crédible auprès de son organisation, l’entreprise doit mettre les moyens matériels et humains pour déployer sa stratégie.
• Ajuster les directives : on décide que lors d’une tâche de développement, il est normal de consacrer du temps à la rédaction de tests unitaires, à la documentation des choix techniques, et pourquoi pas à des opérations de refactoring.

 

Et si on va plus loin ?

Les dettes technico-organisationnelles et technico-sociales ont donc un effet sur la dette technique. Celle-ci a par ailleurs un effet direct sur la dette psychologique, concept récemment présenté dans cet article.

Celui-ci stipule que la dette technique a des effets nocifs non négligeables sur les individus qui œuvrent au quotidien sur le code : perte de motivation, envie de partir, baisse de créativité, tensions dans l’équipe… Bien entendu, d’autres facteurs non liés à la dette technique peuvent impacter la dette psychologique des équipes (climat dans l’entreprise, salaires, conditions de travail…).

Si les 4 types de dettes ont un impact direct sur l’entreprise, on pourrait aller jusqu’à dire qu’une orientation stratégique sur la qualité du code impacte indirectement la motivation des développeurs au quotidien !

Que retenir ?

Lorsqu’on prend le temps de regarder ses projets logiciels et d’évaluer leur dette technique, on cherche les symptômes pour mieux comprendre cette dette. A quels endroits le code est-il perfectible ? Quels composants mériteraient bien un refactoring ? On reste bien souvent proche de la technique, des choix d’implémentation faits par le passé… De mon point de vue, avant d’aller nettoyer votre code, essayez d’estimer vos dettes technico-organisationnelles et technico-sociales pour mieux comprendre les racines de votre dette technique. Un audit peut être une piste pour y arriver, ce sont des choses qu’on a déjà faites chez ProMyze. On peut ensuite attaquer le code, mais dans l’idéal, je préconise d’abord de s’attaquer à nos deux dettes avant de repasser sur la dette technique.

Dans un prochain article, nous aborderons plus précisément les influences que peuvent avoir ces 3 niveaux (organisation, individu et code) entre eux, si elles sont mono-directionnelles / bi-directionnelles…

Références

[1] https://en.wikipedia.org/wiki/Bus_factor : Nombre de personnes en deçà duquel votre projet ne peut se poursuivre de manière viable.