Dettes techniques : les conséquences possibles d’un développement logiciel pris à la légère

Lorsqu’une équipe de développeurs opte pour la rentabilité et la rapidité dans le développement d’un logiciel ou dans la mise en place d’une infrastructure informatique, cette économie peut entraîner une dette technique. La dette technique désigne les conséquences de négligences, d’erreurs et de failles intentionnelles ou involontaires dans le code. Les corrections et les maintenances nécessaires a posteriori freinent la productivité et entraînent un travail supplémentaire coûteux. Comment éviter une dette technique dans le développement logiciel ?

La métaphore de la dette technique a été introduite en 1992 par le programmeur et co-auteur du manifeste pour le développement logiciel agile Ward Cunningham. Avec cette image, W. Cunningham souhaitait souligner à quel point le réusinage du code, c’est-à-dire la correction 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 fonctionnels et des failles structurelles toujours plus considé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 conséquence pour l’entreprise à l’initiative du projet. La dette technique se traduit non seulement par un travail supplémentaire et une baisse de productivité du fait des maintenances ultérieures mais aussi par des coûts supplémentaires. Plus la direction de l’équipe négligera la maintenance d’une infrastructure informatique ou d’une application défectueuse, plus les intérêts générés par la dette seront importants et plus les corrections du code se révéleront coûteuses.

Selon Ward Cunningham, une dette technique provient de négligences dans le code auxquelles on apportera des solutions rapides mais incomplè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 circonstances, les développeurs optent pour un code rapide afin de gagner du temps et se faciliter la tâche. Cette économie engendre des dettes.

Pour W. Cunningham, cet aspect économique de la programmation n’est pas inhabituel 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égulièrement optimisé, le développement devra s’interrompre ou s’arrêter pour payer ces intérêts métaphoriques.

Martin Fowler, auteur de Refactoring: Improving the Design of Existing Code, a étayé la métaphore de Cunningham et a divisé les dettes techniques en quatre types qu’il a représentés dans un quadrant de la dette technique :

Selon W. Cunningham et M. Fowler, les dettes techniques peuvent donc être intentionnelles ou involontaires. La technologie et la programmation font l’objet de révisions et d’améliorations constantes. Par conséquent, il est pratiquement impossible 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 techniques peuvent toutefois s’expliquer par des décisions économiques ou des erreurs de programmation intentionnelles ou involontaires.

Bien que les dettes techniques aient généralement des conséquences semblables sur le développement logiciel, leurs causes sont toutefois multiples.

• Gestion de la qualité défaillante : ici, les projets n’incluent pas de mécanismes de contrôle, de mesure et de test permettant de garantir la qualité ce qui se traduit par une accumulation de dettes en continu.
   
• Pression économique : les facteurs économiques et un développement rapide sont ici priorisés sur l’insistance des clients ou en raison de la pression de la concurrence et la rédaction d’un code propre est négligée.
   
• Manque de qualifications : les connaissances techniques de l’équipe de développeurs ne répondent pas aux exigences d’un code propre et élégant. Ce manque de connaissances se traduit par des codes smells ou une programmation spaghetti.
   
• Documentation/communication insuffisante : le processus de développement est réalisé sans documentation parallèle des extensions et des modifications du code. Par ailleurs, les modifications dans le code ne sont pas enregistrées ni communiquées aux programmeurs ultérieurs. Les possibilités de réusinage sont limitées, voire inexistantes.
   
• Réusinage différé : les dettes techniques délibérément acceptées ne sont pas corrigées dans les temps car le réusinage du code est négligé ou reporté.
   
• Développement d’application en parallèle : des étapes de développement parallèles rassemblées sans coordination entraînent une augmentation de la dette technique.
   
• Code trop complexe : les sections de code sont trop compliquées et illogiques. La moindre modification peut engendrer d’autres erreurs et augmenter les dettes. Dans le pire des cas, cette programmation peut également donner un code spaghetti.
   
• Processus de développement non structurés : le développement de l’application commence avant qu’un design ou des processus concrets n’aient été définis ou décidés.
   
• Externalisation du code : les étapes de développement sont délocalisées. Des erreurs font leur apparition dans le code lorsque les différentes sections sont rassemblées. Ces erreurs sont soit acceptées soit occultées par la direction de l’équipe.
   
• Des modifications à court terme au cours du processus : pour des raisons de délai, les modifications à court terme ne font l’objet d’aucun test.

Ward Cunningham ne s’est pas contenté de définir la métaphore de la dette technique. Il est également le co-auteur et le premier signataire du manifeste pour le développement logiciel agile. Cette philosophie de développement logiciel vise à favoriser un développement et une publication d’application plus productifs et plus flexibles à travers des principes directeurs.

Traditionnellement, l’équipe de développement restait liée à un projet sur une longue période. Dans la méthode agile, des équipes plus restreintes et plus indépendantes couvrent des phases de travail plus courtes et veillent à une publication plus rapide de projets moins volumineux comme des applications, des parties de programmes et des mises à jour.

Dans le développement logiciel agile, les équipes écrivent et modifient le code par petites étapes ce qui permet de mener plus rapidement à terme les différentes étapes de travail. Cette focalisation sur la rapidité et la productivité 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évitablement croître la dette technique.

Les conséquences des dettes techniques sont celles que l’on connaît pour les crédits financiers. Une dette qui n’est pas acquittée régulièrement et dans les temps entraîne des intérêts qui s’expriment dans un freinage du développement, une baisse de la productivité et une hausse des coûts.

Par conséquent, il est dans l’intérêt du client d’adjoindre au développement une gestion de la qualité complète et durable et de surveiller le développement pour qu’une réalisation et une publication plus rapide et moins coûteuse des produits ne se payent pas par des corrections d’erreurs ultérieures coûteuses ou par un arrêt du développement.

Du fait des nouvelles technologies et de l’évolution des approches dans le développement logiciel, les dettes techniques ne peuvent pas être entièrement exclues. Elles sont même tolérées si elles permettent de publier des programmes et des applications de façon rapide et régulière sans attacher des équipes durablement aux projets. Il existe toutefois des mesures préventives permettant d’éviter ou de réduire la formation et l’augmentation des dettes techniques :

• utiliser des processus de réusinage de code et de gestion de la qualité standardisés,
• utiliser des outils de détection et d’analyse des erreurs constamment actualisés,
• maintenir à jour les connaissances techniques par une formation continue ou définir la composition de l’équipe en fonction des qualifications,
• concevoir le code de façon claire en procédant à une division en classes et en utilisant des méthodes compréhensibles et écrire le code de façon lisible pour les nouveaux programmeurs intégrant le projet ou pour les programmeurs externes,
• attribuer des responsabilités claires et bien répartir les tâches entre les équipes pour éviter les doublons, les redondances et les étapes de travail contre-productives,
• maintenir à jour l’architecture informatique par une surveillance, une analyse et un contrôle de la qualité constants.