Dettes tech­niques : les con­sé­quences possibles d’un dé­ve­lop­pe­ment logiciel pris à la légère

Lorsqu’une équipe de dé­ve­lop­peurs opte pour la ren­ta­bi­lité et la rapidité dans le dé­ve­lop­pe­ment d’un logiciel ou dans la mise en place d’une in­fras­truc­ture in­for­ma­tique, cette économie peut entraîner une dette technique. La dette technique désigne les con­sé­quences de né­gli­gences, d’erreurs et de failles in­ten­tion­nelles ou in­vo­lon­taires dans le code. Les cor­rec­tions et les main­te­nances né­ces­saires a pos­te­riori freinent la pro­duc­ti­vité et en­traî­nent un travail sup­plé­men­taire coûteux. Comment éviter une dette technique dans le dé­ve­lop­pe­ment logiciel ?

La métaphore de la dette technique a été in­tro­duite en 1992 par le pro­gram­meur et co-auteur du manifeste pour le dé­ve­lop­pe­ment logiciel agile Ward Cun­nin­gham. Avec cette image, W. Cun­nin­gham sou­hai­tait souligner à quel point le réusinage du code, c’est-à-dire la cor­rec­tion régulière du code, était essentiel pour un logiciel. Ce réusinage est la seule façon d’éviter qu’un logiciel accumule des défauts fonc­tion­nels et des failles struc­tu­relles toujours plus con­si­dé­rables.

Le terme de « dettes » implique également des intérêts. En effet, d’un point de vue financier, la dette technique n’est pas sans con­sé­quence pour l’en­tre­prise à l’ini­tia­tive du projet. La dette technique se traduit non seulement par un travail sup­plé­men­taire et une baisse de pro­duc­ti­vité du fait des main­te­nances ul­té­rieures mais aussi par des coûts sup­plé­men­taires. Plus la direction de l’équipe négligera la main­te­nance d’une in­fras­truc­ture in­for­ma­tique ou d’une ap­pli­ca­tion dé­fec­tueuse, plus les intérêts générés par la dette seront im­por­tants et plus les cor­rec­tions du code se ré­vé­le­ront coûteuses.

Selon Ward Cun­nin­gham, une dette technique provient de né­gli­gences dans le code aux­quelles on apportera des solutions rapides mais in­com­plètes pour des raisons de délai et de budget. Écrire un code solide et sans faille demande du travail et du temps. C’est pourquoi, dans certaines cir­cons­tances, les dé­ve­lop­peurs optent pour un code rapide afin de gagner du temps et se faciliter la tâche. Cette économie engendre des dettes.

Pour W. Cun­nin­gham, cet aspect éco­no­mique de la pro­gram­ma­tion n’est pas in­ha­bi­tuel ni contre nature. En revanche, si la dette technique n’est pas compensée par un réusinage du code et si le code n’est pas ré­gu­liè­re­ment optimisé, le dé­ve­lop­pe­ment devra s’in­ter­rompre ou s’arrêter pour payer ces intérêts mé­ta­pho­riques.

Martin Fowler, auteur de Re­fac­to­ring: Improving the Design of Existing Code, a étayé la métaphore de Cun­nin­gham et a divisé les dettes tech­niques en quatre types qu’il a re­pré­sen­tés dans un quadrant de la dette technique :

Selon W. Cun­nin­gham et M. Fowler, les dettes tech­niques peuvent donc être in­ten­tion­nelles ou in­vo­lon­taires. La tech­no­lo­gie et la pro­gram­ma­tion font l’objet de révisions et d’amé­lio­ra­tions cons­tantes. Par con­sé­quent, il est pra­ti­que­ment im­pos­sible d’éviter les code smells et l’érosion du code. Sans mise à jour ni réusinage, un logiciel vieillit et accumule une dette technique. Dans la plupart des cas, ces dettes tech­niques peuvent toutefois s’expliquer par des décisions éco­no­miques ou des erreurs de pro­gram­ma­tion in­ten­tion­nelles ou in­vo­lon­taires.

Bien que les dettes tech­niques aient gé­né­ra­le­ment des con­sé­quences sem­blables sur le dé­ve­lop­pe­ment logiciel, leurs causes sont toutefois multiples.

• Gestion de la qualité dé­fail­lante : ici, les projets n’incluent pas de mé­ca­nismes de contrôle, de mesure et de test per­met­tant de garantir la qualité ce qui se traduit par une ac­cu­mu­la­tion de dettes en continu.
   
• Pression éco­no­mique : les facteurs éco­no­miques et un dé­ve­lop­pe­ment rapide sont ici priorisés sur l’in­sis­tance des clients ou en raison de la pression de la con­cur­rence et la rédaction d’un code propre est négligée.
   
• Manque de qua­li­fi­ca­tions : les con­nais­sances tech­niques de l’équipe de dé­ve­lop­peurs ne répondent pas aux exigences d’un code propre et élégant. Ce manque de con­nais­sances se traduit par des codes smells ou une pro­gram­ma­tion spaghetti.
   
• Do­cu­men­ta­tion/com­mu­ni­ca­tion in­suf­fi­sante : le processus de dé­ve­lop­pe­ment est réalisé sans do­cu­men­ta­tion parallèle des ex­ten­sions et des mo­di­fi­ca­tions du code. Par ailleurs, les mo­di­fi­ca­tions dans le code ne sont pas en­re­gis­trées ni com­mu­ni­quées aux pro­gram­meurs ul­té­rieurs. Les pos­si­bi­li­tés de réusinage sont limitées, voire inexis­tantes.
   
• Réusinage différé : les dettes tech­niques dé­li­bé­ré­ment acceptées ne sont pas corrigées dans les temps car le réusinage du code est négligé ou reporté.
   
• Dé­ve­lop­pe­ment d’ap­pli­ca­tion en parallèle : des étapes de dé­ve­lop­pe­ment pa­ral­lèles ras­sem­blées sans coor­di­na­tion en­traî­nent une aug­men­ta­tion de la dette technique.
   
• Code trop complexe : les sections de code sont trop com­pli­quées et il­lo­giques. La moindre mo­di­fi­ca­tion peut engendrer d’autres erreurs et augmenter les dettes. Dans le pire des cas, cette pro­gram­ma­tion peut également donner un code spaghetti.
   
• Processus de dé­ve­lop­pe­ment non struc­tu­rés : le dé­ve­lop­pe­ment de l’ap­pli­ca­tion commence avant qu’un design ou des processus concrets n’aient été définis ou décidés.
   
• Ex­ter­na­li­sa­tion du code : les étapes de dé­ve­lop­pe­ment sont dé­lo­ca­li­sées. Des erreurs font leur ap­pa­ri­tion dans le code lorsque les dif­fé­rentes sections sont ras­sem­blées. Ces erreurs sont soit acceptées soit occultées par la direction de l’équipe.
   
• Des mo­di­fi­ca­tions à court terme au cours du processus : pour des raisons de délai, les mo­di­fi­ca­tions à court terme ne font l’objet d’aucun test.

Ward Cun­nin­gham ne s’est pas contenté de définir la métaphore de la dette technique. Il est également le co-auteur et le premier sig­na­taire du manifeste pour le dé­ve­lop­pe­ment logiciel agile. Cette phi­lo­so­phie de dé­ve­lop­pe­ment logiciel vise à favoriser un dé­ve­lop­pe­ment et une pu­bli­ca­tion d’ap­pli­ca­tion plus pro­duc­tifs et plus flexibles à travers des principes di­rec­teurs.

Tra­di­tion­nel­le­ment, l’équipe de dé­ve­lop­pe­ment restait liée à un projet sur une longue période. Dans la méthode agile, des équipes plus res­treintes et plus in­dé­pen­dantes couvrent des phases de travail plus courtes et veillent à une pu­bli­ca­tion plus rapide de projets moins vo­lu­mi­neux comme des ap­pli­ca­tions, des parties de pro­grammes et des mises à jour.

Dans le dé­ve­lop­pe­ment logiciel agile, les équipes écrivent et modifient le code par petites étapes ce qui permet de mener plus ra­pi­de­ment à terme les dif­fé­rentes étapes de travail. Cette fo­ca­li­sa­tion sur la rapidité et la pro­duc­ti­vité augmente toutefois le risque de code sale de même que la dette technique. En l’absence de réusinage du code, la méthode agile fait iné­vi­ta­ble­ment croître la dette technique.

Les con­sé­quences des dettes tech­niques sont celles que l’on connaît pour les crédits fi­nan­ciers. Une dette qui n’est pas acquittée ré­gu­liè­re­ment et dans les temps entraîne des intérêts qui s’expriment dans un freinage du dé­ve­lop­pe­ment, une baisse de la pro­duc­ti­vité et une hausse des coûts.

Par con­sé­quent, il est dans l’intérêt du client d’adjoindre au dé­ve­lop­pe­ment une gestion de la qualité complète et durable et de sur­veil­ler le dé­ve­lop­pe­ment pour qu’une réa­li­sa­tion et une pu­bli­ca­tion plus rapide et moins coûteuse des produits ne se payent pas par des cor­rec­tions d’erreurs ul­té­rieures coûteuses ou par un arrêt du dé­ve­lop­pe­ment.

Du fait des nouvelles tech­no­lo­gies et de l’évolution des approches dans le dé­ve­lop­pe­ment logiciel, les dettes tech­niques ne peuvent pas être en­tiè­re­ment exclues. Elles sont même tolérées si elles per­met­tent de publier des pro­grammes et des ap­pli­ca­tions de façon rapide et régulière sans attacher des équipes du­ra­ble­ment aux projets. Il existe toutefois des mesures pré­ven­tives per­met­tant d’éviter ou de réduire la formation et l’aug­men­ta­tion des dettes tech­niques :

• utiliser des processus de réusinage de code et de gestion de la qualité stan­dar­di­sés,
• utiliser des outils de détection et d’analyse des erreurs cons­tam­ment ac­tua­li­sés,
• maintenir à jour les con­nais­sances tech­niques par une formation continue ou définir la com­po­si­tion de l’équipe en fonction des qua­li­fi­ca­tions,
• concevoir le code de façon claire en procédant à une division en classes et en utilisant des méthodes com­pré­hen­sibles et écrire le code de façon lisible pour les nouveaux pro­gram­meurs intégrant le projet ou pour les pro­gram­meurs externes,
• attribuer des res­pon­sa­bi­li­tés claires et bien répartir les tâches entre les équipes pour éviter les doublons, les re­don­dances et les étapes de travail contre-pro­duc­tives,
• maintenir à jour l’ar­chi­tec­ture in­for­ma­tique par une sur­veil­lance, une analyse et un contrôle de la qualité constants.