Cet article donne une illustration du mode urgence chez un éditeur logiciel. L’une de ses conséquences les plus frappantes est la création accélérée de la dette technique.
Prenons un éditeur de solutions numériques : son existence dépend totalement de la monétisation de son produit logiciel. C’est justement pour cela qu’il est probable qu’à un moment, il glisse sur la pente savonneuse qui le fait sombrer dans l’enfer.
Il suffit d’un évènement déclencheur pour faire basculer cet éditeur. Par exemple, ce sera la perte d’une ressource critique (départ du développeur qui avait tout en tête). Cela pourra être liée à un rôle critique (un CTO défaillant). Ou encore, une brusque surcharge de travail se présentera (une grosse opportunité commerciale nécessite rapidement un module additionnel). En réalité, l’évènement déclencheur est une simple mèche qui déclenche le potentiel ravageur de dysfonctionnements importants non traités. Par exemple, dans le cas du départ d’une ressource critique, on se retrouvera avec une documentation insuffisante et une absence de gestion de la ressource rare.
Parfois, il s’agit simplement d’un cumul de micro-dysfonctionnements au fil des années, sans même nécessiter un évènement déclencheur.
Toujours est-il qu’à un moment, quelqu’un dit à l’équipe développeurs : « il faut se débrouiller pour que ça sorte pour telle date ». Et c’est là le début des ennuis.
Généralement, devant une pression forte de délai, les développeurs identifient des raccourcis et réalisent des aménagements temporaires, en coordonnant plus ou moins leurs choix.
Quand les urgences deviennent une dette technique
A côté de possibles raccourcis par rapport aux bonnes pratiques de développement logiciel, la qualité de la conception sera aussi dégradée. Pourquoi ? Pour la simple raison qu’une bonne conception nécessite du temps, de l’intelligence collective, et de la maturation. Et lorsque ce temps n’est pas disponible, la conception est de moindre qualité. Cela limitera par exemple l’évolutivité du logiciel.
Il s’agit donc d’effets purement mécaniques. Les développeurs ne souhaitent pas “mal travailler”, mais ils n’ont simplement pas le temps de “bien travailler”. Cela concerne notamment la production de code suffisamment modulaire, bien documenté et qui respecte les bonnes pratiques de gestion de configuration, de codage, etc.
Et le plus souvent, les libertés par rapport aux bonnes pratiques de développement ont été prises. Même si les équipes projettent sincèrement de remettre au propre le code, dès que l’urgence sera passée.
Ce qui advient rarement dans les faits.
Plusieurs phénomènes empêcheront cette remise au carré. Par exemple, d’autres urgences arriveront. Et la capacité réelle de produire sera probablement devenue inférieure à sa capacité théorique (car diminuée par les effets de dysfonctionnements non traités).
Parmi les dysfonctionnements non traités, il y a notamment la dette technique. Si elle n’est pas soldée, elle va en effet commencer à « coûter » cher en intérêts.
Le code « legacy »
Ce processus relève en effet de la descente aux enfers. Chaque pas supplémentaire vers les tréfonds enrichit le cercle vicieux avec de nouveaux dysfonctionnements.
Dès lors que cette dette technique dépasse un niveau significatif, elle va en effet influer sur la capacité de production et la qualité du produit. C’est un facteur de constitution accélérée de ce qui est appelé un code “legacy”.
En résumé, un code legacy résulte du “désordre” inhérent à tout codage de nouvelles fonctionnalités (sans pression spécifique de délai) si on ne fait rien pour vérifier et nettoyer au fur et à mesure. Cela est comparable à l’utilisation d’un lieu de vie. On le garde propre et rangé par de petits gestes au cours des différents usages. Il serait évidemment vite en désordre et sale sans cette attention.
La transformation de la base de code en un code legacy va subir un effet d’accélération incontrôlé avec une pression spécifique de délai, avec la multiplication de petites dettes techniques. Cette accumulation de dégradations crée un phénomène si massif que l’on parle de “dette technique’. C’est-à-dire que cela devient un paramètre à part entière qui impacte désormais la vie du produit logiciel.
Comment reconnaître le code « legacy » ?
Ce code legacy se reconnait facilement par la difficulté à utiliser ce code et à le maintenir en condition opérationnelle. L’application insuffisante de bonnes pratiques de développement et d’entretien l’ont rendu de moins en moins compréhensible. Les développeurs n’ont plus les moyens de relier le code et le comportement applicatif réel. Parfois, cette corruption profonde dépasse le champ du développement. Il touche tout le système d’information. Par exemple, plus personne ne sait ce qu’était le comportement applicatif attendu dans certaines situations. Ou à quel besoin correspondait tel comportement applicatif attendu.
La caractéristique majeure d’un code legacy est son imprédictibilité. Les développeurs n’ont plus les moyens d’estimer le temps que prendra une intervention sur le code. Généralement, le couplage fort entre les composants internes combiné au manque de clarté du code fait de n’importe quelle intervention mineure une potentielle aventure de plusieurs jours ou semaines. Un langage permissif va par exemple permettre de créer des objets aberrants ou invisibles. Un bouton Windev peut ainsi abriter du code, qui est de facto caché.
La conséquence de la dette technique sur les équipes
Il n’y a ainsi plus de lien entre la complexité fonctionnelle et la complexité du code (et du travail associé).
Cette équipe de développement est alors en incapacité de donner des estimations fiables. Elle ne peut plus respecter sa propre planification, voire même proposer une planification.
Le tableau final est une équipe de développement démotivée, voire épuisée. Elle compose au mieux avec un code legacy qu’elle peine à faire évoluer et à maintenir en condition opérationnelle. Et pour cause : à chaque mise en production d’un correctif logiciel, « les murs tremblent ». La survenue d’effets de bords surprenants, d’anomalies majeures ou critiques, et une explosion des appels client en sont la conséquence.
Le reste de l’entreprise considère généralement l’équipe de développement comme incompétente. En particulier les instances client (centre d’appel…), qui subissent les effets de l’insatisfaction client. Et la direction produit (ou métiers) qui subit la difficulté de faire évoluer le produit.
Pour résumer, l’équipe de développement est prise en otage par une dette technique devenue incontrôlable. Elle est accusée par le reste de l’entreprise d’incompétence crasse ou de mauvaise volonté.
Pourtant la cause des limitations subies par l’entreprise est bien d’ordre technique. Elle ne relève pas de responsabilité actuelle de l’équipe de développement. Celle-ci fait du mieux qu’elle peut le plus souvent, dans une situation où elle n’a pas de pouvoir d’action en l’état.
Alors que faire pour contrer le phénomène de dette technique ?
A côté d’une stratégie spécifique pour traiter la dette technique (le symptôme, devenu une cause d’inefficience) et chercher à retrouver une capacité réelle de production, il faudra aussi traiter la cause originelle à l’origine de ce glissement dans un mode urgence qui a créé de la dette technique.
Ainsi il y aura ainsi deux types d’approche (et deux expertises spécialisées) à mobiliser. Une approche technique de résolution de situation de dette. Et une compétence organisationnelle plus large, qui inclut l’organisation processus comme managériale.
Cette remédiation organisationnelle est l’objet de notre article Comment l’agilité peut aider à se libérer de la tyrannie du mode urgence.
