X
Bastien Lion / vendredi 12 juin 2020 / Thèmes: Dossier, Dev

Le lourd poids de la dette technique

Prévisible et bien souvent inévitable, la dette technique continue cependant de donner des sueurs froides aux développeurs. Le problème ne vient pourtant pas toujours du code, mais plutôt de la prise de décision.

En mars 2019, un consultant en sécurité logicielle du nom d’Éric Higgins rédigeait un billet sur la plate-forme Medium à propos de la dette technique. Selon lui, celle-ci serait comparable au jeu Tetris : « Vous ne pouvez pas gagner, vous ne pouvez que contrôler la vitesse à laquelle vous perdez. » En toute logique, ce phénomène propre au monde du code et tout ce qui en découle a vu sa notoriété considérablement augmenter ces dernières années. HTML, CSS, PHP, JavaScript, les premiers langages de programmation web, popularisés dès le début des années 2000, ont largement dépassé leur vingtième anniversaire. À mesure qu’ils évoluent et voient fleurir autour d’eux des dizaines d’autres langages, certaines structures développées dans leurs premières années ont elles aussi vieilli, provoquant d’importants décalages avec les besoins et normes modernes.

C’est à Ward Cunningham, par ailleurs à l’origine du concept des “Wiki”, que l’on attribue la paternité du concept de dette technique. Dans un rapport rédigé en 1992 à l’occasion d’une conférence de développeurs, il théorise : « Écrire la première version d’un code, c’est un peu comme s’endetter. Un léger endettement accélère le développement à condition d’être remboursé rapidement via une réécriture. Le danger survient lorsque la dette n’est pas remboursée. Chaque minute passée sur du code qui n’est pas correct compte comme des intérêts sur cette dette. » Au fil du temps, la dette technique est devenue ce fardeau laissé à leurs successeurs par des développeurs peu consciencieux ou simplement pressés par le temps. Code basé sur des technologies vieillissantes, lignes bricolées à la va-vite pour résoudre un problème à un instant précis sans penser à la suite, structure opaque voire parfois illisible… Il y a différentes manières d’accumuler de la dette technique, mais toutes donnent lieu à une réflexion inévitable : comment rattraper les dégâts et limiter la casse ?

Le rôle crucial de la veille

Dans un ouvrage publié en 2015 (La Dette Technique, Ed. Les Contrôleurs du train de 13h37), Bastien Jaillot, cofondateur de l’ESN JoliCode, définit la dette technique comme « l’accumulation des risques pris lors des différentes phases techniques tout au long de la vie d’un projet ». Selon lui, le phénomène se divise en quatre catégories : la dette involontaire, due à de mauvaises pratiques et un manque de communication, la « dette par négligence volontaire » ou fonctionnement « à la rustine », la dette assumée, souvent créée pour répondre à des contraintes de temps, avec l’intention de rapidement corriger ce qui peut l’être, et la dette inévitable, qui résulte de la « sédimentation naturelle du code ».

Sur ce dernier point, une veille assidue sur le marché jouera un rôle crucial. Développeur indépendant basé dans la région lyonnaise, Valentin Jeudy donne un exemple : « Pour le typage en JavaScript, jusqu’à très récemment, il y avait deux solutions : TypeScript, un outil développé par Microsoft, et Flow, créé par Facebook. Il se trouve que le premier a gagné la guerre entre les deux et il y a de fortes chances qu’à terme, Flow ne soit plus supporté. Ce n’est pourtant pas une technologie spécialement vieille. Cela illustre bien à quel point il est parfois compliqué pour les développeurs de faire des choix, car il faut penser en termes de tendances. » Un constat qui paraît évident aujourd’hui, mais qui l’était beaucoup moins il y a 10, 15 ou 20 ans.

Régis Massé, DSI de l’Afnic

Tabula rasa

Récemment partie à la conquête de sa dette technique, l’Association française pour le nommage Internet en coopération (Afnic) est une parfaite illustration de cette problématique. Avec l’entrée en vigueur du RGPD, ainsi que l’accession à des normes de sécurité de plus en plus exigeantes, il devenait urgent pour l’organisation de revoir de fond en comble son SI. Problème, celui-ci était en place depuis deux décennies, avec toutes les contraintes que cela implique. « Même si le système fonctionnait bien, il été bâti sur des fondations qui avaient plus de vingt ans et sur lesquelles on avait rajouté plusieurs couches supplémentaires au fur et à mesure, détaille Régis Massé, DSI de l’Afnic; On s’est retrouvés avec des besoins de compétences plus présentes dans l’entreprise, des langages vieillissants, avec notamment une grande partie de l’architecture écrite en Perl, et d’autres éléments techniques qui freinaient notre volonté de pouvoir livrer plus rapidement de nouveaux services à nos clients. »

Après une étude menée en profondeur sur l’état du SI, la direction opte pour une refonte complète en repartant de zéro. En 2016, un programme de trois ans est initié à cet effet, avec une équipe d’une trentaine de personnes dédiée au projet dont la moitié travaille sur le développement logiciel, et l’autre sur l’infrastructure, elle aussi refondue. Là où la dette technique complexifie le processus, c’est dans la recherche dans le code des corner cases, ces fonctions propres à un client spécifique qu’il faut pouvoir reproduire dans le nouveau système pour ne pénaliser personne. « On se retrouve à faire de l’archéologie dans la documentation d’un vieux logiciel maison pour en comprendre certains points précis », s’agace M. Massé.

Une dette contextuelle

Qui dit refonte totale ne dit bien évidemment pas anéantissement de la dette technique. « On sait que notre système va continuer à vivre en récupérant au passage un peu de dette technique année après année, confirme le DSI de l’Afnic. Mais la nouveauté après cette refonte, c’est qu’on a mis en place une véritable usine logicielle faite de principes, de processus et d’outils d’intégration continue qui nous permettent de générer de la documentation, de faire des contrôles sur le code pour être sûr de bien respecter l’évolution des normes, de réécrire plus facilement… Ça a demandé de l’appropriation par les équipes au départ. Il fallait monter en compétence aussi bien sur la technique que la méthode agile. On a eu un peu de retard au début, le temps de mettre tout ça en place, mais on sent maintenant toute la valeur ajoutée amenée par cette décision. »

Bien entendu, si l’idée d’une refonte complète est réaliste pour une entreprise comme l’Afnic, avec des moyens financiers et humains, et une large majorité de logiciels internes, elle le sera beaucoup moins pour une entreprise modeste, qui plus est connectée à de nombreux services externalisés. Le contexte est un élément central du concept de dette technique. De même, si l’obsolescence des langages et autres outils de développement est inévitable, la dette technique n’est pas toujours mesurable comme une donnée objective. Selon sa formation, son expérience ou ses habitudes de travail, une équipe de développeurs débarquant sur un nouveau projet peut tout à fait fustiger l’approche des anciens employés en désignant telle ou telle partie du code comme de la dette technique.

Quentin Adam, fondateur et directeur de Clever Cloud.

La technique, seule coupable ?

Dans ce cas-là, le concept est-il vraiment adapté à toutes les situations ? Pour Quentin Adam, fondateur et directeur de Clever Cloud, une ESN spécialisée dans l’automatisation des infrastructures, la réponse est catégoriquement négative. Il réfute d’une part le mot dette, puisqu’il n’y a pas de créancier. D’autre part, le terme reflète selon lui très mal la réalité du marché. « Le code peut avoir vieilli, ne plus être à jour, ne plus correspondre aux besoins de l’entreprise. Mais il n’existe pas de bon code, qui sera bon pour toujours, et de mauvais code qui serait déjà mauvais au moment où on l’écrit, uniquement des investissements contextuels. »

La dette technique serait par ailleurs un moyen de fustiger les développeurs sur des décisions devant de toutes façons être prises. « On a des scènes surréalistes où le directeur technique va voir la direction en s’auto-flagellant à l’avance pour avoir accumulé de la dette technique comme si c’était une faute. Il se retrouve dans la position d’un consommateur de ressources qui doit négocier chaque décision, alors que logiquement, la prod devrait être le centre de profits. » Une critique que partage Bastien Jaillot, qui note que ce phénomène fait un choix « impliquant le risque de voir apparaître des erreurs plus tard, ce qui existe dans tous les domaines, mais chez nous il a un nom et il est mal vu ». Dans son livre, il dénonce d’ailleurs des situations « invivables » menant au surmenage, parfois même à la démission de l’équipe technique. Pas surprenant, donc, de voir le mouvement DevOps s’emparer de la question. Dernièrement, c’est d’ailleurs chez Microsoft que le sujet a resurgi, au détour d’un billet de blog. Silviano Blea, responsable du développement d’applications à Mountain View, y affirmait que la vision classique de la dette technique pouvait nuire à l’adoption et la transformation d’une entreprise qui suivrait la méthode DevOps. Dans cette « culture Anti-DevOps », la dette technique « s’insère dans un projet ou un environnement au fil du temps sans tenir compte de la conception, de l’architecture ou de la mise en œuvre globale », écrit-il, ajoutant qu’il faut « courir vers elle plutôt que s’en éloigner ». Plus d’anticipation, une meilleure conciliation entre la prise de décision et la technique pure, voilà les ingrédients permettant non pas d’éliminer la dette technique, mais plutôt de cohabiter avec elle.

2229

x
Rechercher dans les dossiers

Actuellement à la Une...
Oracle étend son offre Cloud@customer, sa mouture pour le Cloud privé, avec l’accès à Autonomous Database dans Exadata@customer et crée des « régions » dédiées pour offrir les services de cloud d’Oracle dans les centres de données des clients.

HYCU, spécialisé dans la protection des données dans les environnements hyper-convergents et multicloud étend ses solutions vers les fournisseurs de services managés et intègre sa solution avec Azure

Fondée en 2014, Pavilion Data tient une place particulière dans le secteur du stockage qui provient de sa conception originale qui vise à fournir des performances en temps réel à l’échelle des très grands comptes. 

L’éditeur de solutions pour les PME unifie ses outils dans une plate-forme et vise une entrée en bourse l’année prochaine.

La plateforme de cryptomonnaies planifierait une introduction en bourse, ce pour quoi elle privilégierait une cotation directe plutôt qu’une traditionnelle IPO. Si la SEC devait accepter le dossier de Coinbase, cette arrivée sur les marchés financiers représenterait un pas de géant dans la reconnaissance de la légitimité des devises virtuelles. 

Toutes les autres News
LIVRES BLANCS

Actuellement, il existe un gouffre entre les environnements informatiques traditionnels des entreprises et le cloud public. Tout diffère : les modèles de gestion, de consommation, les architectures applicatives, le stockage, les services de données.


Les avantages de l’architecture hyperconvergée étant de plus en plus reconnus, de nombreuses entreprises souhaitent l’utiliser pour des types d’applications variés. Cependant, son manque de souplesse pour une mise à niveau des ressources de calcul indépendantes de celles de stockage ne lui permet pas d’être utilisée plus largement.

Au cours de l’événement HPE Discover qui s’est tenu en juin 2019, HPE a répondu à cette préoccupation en présentant la plateforme HPE Nimble Storage dHCI.

Ce Livre Blanc IDC se penche sur les exigences du marché ayant stimulé le besoin de solutions HCI plus flexibles, puis il examine brièvement la solution HPE Nimble Storage dHCI en expliquant pourquoi elle répond à ce besoin.


Malgré des investissements massifs dans le développement à hauteur de près de 4 milliards de dollars l'année dernière, près de la moitié du temps consacré au DevOps est perdu dans la répétition des tâches et dans la logistique. Ceci fait que 90% des entreprises qui ont adopté ces pratiques sont déçues par les résultats, selon une étude publiée par le Gartner.


Découvrez dans ce livre blanc, les avantages des toutes nouvelles solutions NETGEAR, pour simplifier et rentabiliser vos déploiements, et gérer votre réseau à distance, où que vous soyez, au bureau ou en télé-travail.


OneTrust est une plateforme logicielle innovante de gestion de la confidentialité, de la sécurité des données personnelles et des risques fournisseurs. Plus de 4 000 entreprises ont choisi de faire confiance à cette solution pour se conformer au RGPD, au CCPA, aux normes ISO 27001 et à différentes législations internationales de confidentialité et de sécurité des données personnelles.

OneTrust vous propose de télécharger le texte officiel du Règlement Général sur la Protection des Données (RGPD). Vous aurez également la possibilité de recevoir la version imprimée de ce texte, sous forme de guide pratique au format A5, spiralé, en complétant le formulaire.


Tous les Livres Blancs
0123movie