Avertissement : si vous êtes développeur(se) ou directeur(trice) technique, vous n’avez peut-être pas envie de lire cet article.
En revanche, si vous êtes directeur(trice) marketing, chef de projet Web, product owner, cela pourrait vous intéresser.
J’avais envie de vous parler de ce petit sujet : celui de la dette technique d’une application. C’est quelque chose qui touche tous les projets informatiques ou web, et qui est la résultante naturelle du développement informatique.
A partir du moment où du code est créé, de la dette technique est générée. Plus ou moins, mais de manière certaine, dépendant entièrement de la manière dont un projet est géré et de quels choix stratégiques sont faits au-dessus de ce projet technique.
Qu’est-ce que la dette technique ?
Prenons un exemple simple pour bien comprendre. Mettons que vous soyez un constructeur automobile (j’aime bien les métaphores avec les voitures) et que vous souhaitiez lancer sur le marché une nouvelle catégorie de voitures. Mettons des véhicules électriques 🙂
Vous savez que le temps vous est compté. Que vous n’êtes pas le seul à vouloir lancer un véhicule électrique et que d’autres constructeurs sont aussi sur le coup. Et vous savez aussi qu’il y aura une prime au premier constructeur mettant sur le marché son nouveau véhicule.
La tentation est alors très forte d’accélérer son développement et sa fabrication. Mais comment faire ? Eh bien, si vous êtes un constructeur automobile, vous pouvez décider simplement d’accélérer certains processus de fabrication ou d’utiliser des matières premières de moindre qualité, accessibles rapidement, mais qui vous permettront de doubler vos concurrents. C’est un choix stratégique à faire, qui vous permettra de prendre des parts de marché, mais vous laissera avec une dette technique : vous prendrez le risque de devoir peut-être rappeler certains véhicules pour modifier des pièces, la réputation de qualité de votre marque pourrait être dégradée. Votre chaîne de production sera peut-être efficace à court terme, mais vous devrez l’améliorer rapidement si vous voulez qu’elle tienne ensuite la montée en puissance. Bref, si vous gagnez du temps en dégradant la qualité de votre production, vous créez également une charge que vous devrez payer plus tard. C’est cela, la dette technique.
Développer un site web ou une application pose exactement le même genre de questions. Jusqu’à quel point, jusqu’à où pouvez-vous dégrader la qualité de ce qui est produit pour gagner du temps ?
Comme je le disais en début d’article : quel que soit le projet et quelle que soit la manière dont il est traité, de la dette technique est créée. C’est inéluctable. Pour une raison simple : parce qu’il existe deux manières de créer de la dette technique. Volontairement ou involontairement.
Deux manières de créer de la dette technique
Volontairement
Faire le choix de mal développer ou de développer avec des choix qui ne respectent pas les règles de l’art peut avoir du sens ou, disons, une unique raison, celle que j’ai citée plus haut : gagner du temps. Arriver le plus vite possible sur le marché. C’est une démarche risquée, car la dette technique risque de s’accumuler. Et elle fait même partie de la stratégie inhérente de certaines entreprises. C’était le cas de LinkedIn jusqu’à une certaine époque.
Toute autre raison n’est pas vraiment justifiable.
Involontairement
Créer de la dette technique involontairement arrive sur tous les projets. Pour deux raisons spécifiques :
- Par un manque de connaissances de vos équipes IT. Elles ne maîtrisent pas suffisamment bien un langage et font des choix qui impactent négativement la qualité du code.
- A cause de la dépréciation rapide du code généré. C’est le cas le plus fréquent : les évolutions technologiques vont si vite que le code “se périme” et handicape le développement de l’application
Il faut donc refaire à plus ou moins long terme ce qui a été fait. Et cela, évidemment, ralentit aussi les développements et impacte négativement la qualité du code d’une application.
Quel est le risque de la dette technique ?
Il est de créer la nécessité de revenir sur ce qui a déjà été fait, d’une part. Et d’autre part, si le choix n’est pas fait de revenir sur cette dette technique, de créer une application de plus en plus chère à maintenir, et même parfois, une application qu’il n’est plus possible de faire évoluer et qui peut finir par entraîner des blocages dans la production du service que doit délivrer l’application.
La dette technique n’est pas un problème de développeurs. Si vous êtes directeur ou directrice marketing, si vous êtes dirigeant d’entreprise, vous devez vraiment être conscient de son existence, et vous devez absolument être capable de pouvoir y faire attention. La dette technique peut réellement mettre en danger une entreprise.
Quelles solutions ?
Inutile de vous dire, évidemment, qu’il est important que votre équipe technique soit la plus expérimentée possible. Mais cela est une question de ressources humaines. Et de recrutement. Mais au delà de cet aspect, il semble également primordial qu’en tant que responsable d’un produit digital (site web ou application), vous vous assureriez que ces équipes mettent aussi en place les bonnes méthodes pour pouvoir limiter les effets négatifs de la dette technique.
La meilleure des solutions sont pour les équipes IT d’adopter des modes de développement qui leur donnent le plus de souplesse. C’est à dire qui leur permettent d’activer et de réactiver des fonctionnalités rapidement. Ou bien même de revenir rapidement à une fonctionnalité précédemment développée.
Si on vous parle, par exemple, d’environnement CI/CD, sachez que cela va dans le bon sens. Un tel environnement de développement permet très facilement de faire évoluer une application sans passer par des processus de mise en production lourds (C’est quelque chose que nous faisons systématiquement chez WEX IT).
Renseignez-vous aussi sur les Feature Flags qui sont des sortes de mécanismes qui permettent d’activer ou de désactiver des fonctionnalités en parallèle du corps principal d’une application. En quelque sorte, c’est une manière de mettre en production des caractéristiques comme si l’on faisait des tests A/B. Par exemple, plutôt que de développer dans le coeur d’un système des fonctionnalités critiques, permettez de les développer de manière à les désactiver rapidement lorsqu’elles sont obsolètes et qu’elles nécessitent d’être remplacées par du meilleur code. Cette manière de procéder rejoint la problématique de la dette technique et permet de mieux la gérer.
Voilà, c’est tout pour aujourd’hui ! J’espère que ce court article vous aura été instructif et que vous aurez compris comment mieux gérer votre production informatique dans le cadre d’un projet digital.
Excellente journée !
Photo by Dylan Gillis
