La dette technique, l’épée de Damoclès de l’éditeur logiciel

Le terme de dette technique est devenu monnaie courante dans le jargon de l’informatique. Et pour cause, c’est un enjeu important dans la vie de tout logiciel car c’est une menace omniprésente qui peut à tout moment mettre en péril un projet.

La notion de dette est une métaphore basée sur un parallèle avec la dette financière. Je trouve personnellement que ce parallèle avec le monde de la finance est particulièrement pertinent et cet article devrait permettre de le montrer.

C’est quoi la dette technique

La dette technique représente l’ensemble des menaces liées directement à la technique qui pèsent sur un logiciel.

D’une manière assez triviale, on peut caractériser la dette technique par l’absence de respect des bonnes pratiques de conception et de développement. On peut citer par exemple un code de mauvaise qualité, un manque plus ou moins marqué de tests, une mauvaise architecture logicielle, l’utilisation de technologies inappropriées ou encore une absence de vision d’ensemble.

Mais la dette technique peut aussi se présenter sous d’autres formes qui sont également assez fréquentes. On peut citer par exemple le cas d’un développeur qui travaille tout seul dans son coin sur des pans entiers d’un logiciel. La connaissance n’est alors pas du tout partagée. Il suffit que le développeur en question s’absente temporairement (ou pire, définitivement) pour semer la panique générale dans une équipe.

S’endetter pour réaliser ses objectifs

Généralement, la dette technique est intentionnelle, elle s’apparente à un emprunt financier. Les contraintes économiques et temporelles font qu’il est des fois nécessaire de s’affranchir ponctuellement des règles et des bonnes pratiques dans l’objectif de satisfaire une échéance importante. En d’autres termes, on doit parfois creuser la dette technique pour faire face à une difficulté locale. C’est un peu comme si on jouait la carte joker.

Parfois, la dette technique n’est pas intentionnelle, c’est-à-dire qu’elle n’a pas été créée dans l’objectif de résoudre un problème, et c’est vraiment dommage, car on ne profite pas de la souplesse qu’elle apporte, mais on s’expose quand même aux risques qu’elle engendre. C’est encore plus dangereux lorsqu’elle est inconsciente, c’est-à-dire que les développeurs ne mesurent pas son ampleur. Malheureusement ça arrive et c’est souvent dû à un manque de compétences ou de professionnalisme des équipes de développement. Dans de tels cas, la responsabilité repose entièrement sur les développeurs qui n’ont tout simplement pas bien fait leur travail.

La tentation du surendettement est grande

Le seul point sur lequel on peut faire une différence avec une dette financière se situe au niveau du remboursement. Lorsqu’on emprunte de l’argent, on s’engage à le rembourser. Avec la dette technique, on s’endette en quelques sortes auprès de soi-même, et du coup on croit pouvoir se permettre de ne pas rembourser.

Dans l’informatique, la dette technique est un phénomène qui ne parle généralement que très peu aux décideurs. Cela s’explique entre autres à mon avis par le fait qu’ils sont rares à connaître notre métier. Et c’est peut-être pire lorsqu’ils connaissent un petit peu notre métier. En effet, ils croient tout savoir mais n’ont qu’une vision superficielle du génie logiciel et ne comprennent pas forcément les enjeux, et ça déclenche une crise de confiance avec les développeurs.

Faisons un rapprochement avec un autre domaine de l’industrie comme les travaux publics. Intéressons-nous à une équipe qui construit un pont routier. Il ne reste plus qu’une portion de tablier à poser, et cela va prendre trois jours. Mais ça serait bien que demain le président du conseil régional qui subventionne les travaux puisse visiter l’infrastructure et ainsi emprunter le pont à pied. La décision est prise de poser quelques poutres et de faire une passerelle en bois de manière à permettre à cet événement de se dérouler dans la mesure où  ça ne nécessite qu’une demi journée de travail. Une fois l’événement passé, il va de soi que la passerelle temporaire sera remplacée par la portion définitive de tablier. Pourtant, en informatique, les décideurs prendraient à la grande majorité à mon avis la décision d’ouvrir le pont à la circulation avec la passerelle en bois pour s’attaquer rapidement à autre chose, quitte à la réparer et la renforcer à chaque fois qu’un véhicule l’empruntera, jusqu’au jour où elle s’effondrera complètement. Cela aura coûté dix ou cent fois le prix de la pose du tablier final et il faudra toujours faire la pose du tablier définitif et donc en payer le prix.

Je pense que l’aspect totalement dématérialisé de notre science est pour beaucoup dans ce genre de décisions. Mais nous, développeurs, avons bien entendu notre part de responsabilité là-dedans. Nous devons communiquer, être transparents et pédagogues pour expliquer les enjeux de telles décisions. Le plus difficile dans tout cela est de maintenir la relation de confiance qui est très importante pour le bon déroulement d’un projet.

La dette technique est donc un facteur largement négligé dans les décisions quand il n’est pas complètement ignoré. Très souvent dans notre métier, les décisions sont prises avec une vision très court terme, sans trop penser aux conséquences sur le long terme. Or, ce qui est intéressant sur du court terme l’est rarement sur du long terme, et ça s’exprime notamment à travers la dette technique.

Lorsque la pression économique nécessite de s’endetter, le bon sens voudrait que cette dette soit remboursée dès que la période critique est passée. On emploie souvent dans cette situation l’expression « nous le ferons plus tard ». Mais « plus tard » signifie bien souvent « jamais ». Les décideurs ont en effet toujours besoin de choses plus prioritaires (à leurs yeux en tout cas) que de rembourser la dette technique. C’est ainsi que la dette s’accumule, petit à petit.

La sanction finit toujours par tomber

La dette technique est une menace qui nous guette. Lorsqu’elle dépasse un certain stade, elle finit toujours par frapper en ayant des conséquences parfois très graves. Quand on est endetté, on finit toujours par devoir payer. Et plus on attend, plus on paie cher. Généralement, la crise liée à la dette technique frappe au mauvais moment. Et ce n’est pas anodin. Quand les choses ne vont pas bien, on a tendance à ne s’occuper que des priorités apparentes, et elle n’en fait pas partie. La dette augmente alors subitement et vient gangrener le logiciel.

Les symptômes sont généralement très embêtants. Les équipes de développement mettent des semaines à intégrer la moindre fonctionnalité. Pire, elles passent plus de temps à corriger des bugs qu’à créer de nouvelles fonctionnalités. La productivité diminue petit à petit et la qualité du produit se dégrade.

Le produit devient petit à petit un boulet qui pèse de plus en plus. Et, plus on attend de s’attaquer au problème à bras le corps, plus ça sera difficile. Le logiciel finit par être un monstre qu’on ne contrôle plus. Une fois parvenu à ce stade, il n’y a pas vraiment de solution satisfaisante. Parfois on arrête de toucher à une portion de code parce qu’à chaque fois qu’elle évolue les conséquences sont dramatiques. Mais des fois il faut bel et bien faire évoluer ce genre de morceaux de code. On finit alors souvent par réécrire tout le code. Cela demande un temps fou, la facture est souvent très salée, mais encore faut-il avoir les ressources nécessaires pour se permettre de le faire. Cela peut conduire un projet à la déroute, d’autant plus que c’est à ce moment-là que les meilleurs développeurs s’en vont, puisque leur travail devient de moins en moins intéressant et parfois même désagréable. Le comparatif avec la dette financière est très approprié ici si on s’en réfère à l’endettement des pays occidentaux. En France par exemple, le remboursement de la dette est, je crois, le premier poste de dépense de l’État ! Cette situation, si elle est pénalisante pour une grosse entreprise, peut être tout simplement fatale à une petite entreprise dont l’économie ne dépend que du produit qui s’enlise petit à petit.

Rester maître de sa dette

Dans le monde du développement informatique, maîtriser sa dette technique est quelque chose qui est indispensable si on veut pouvoir envisager sereinement le futur et ne pas vivre trop dangereusement. Ce n’est pas suffisant mais c’est bel et bien nécessaire. Et que les choses soient claires, c’est loin d’être impossible.

Maîtriser sa dette technique ne signifie pas nécessairement de ne pas avoir de dette technique, parce que les impératifs économiques font qu’on n’a parfois pas d’autre solution. Pour autant, il est primordial d’avoir une idée la plus précise possible de son état d’endettement. Il est impossible de maîtriser sa dette sans la connaître.

Connaître sa dette technique passe nécessairement par une remise en question et une prise de recul régulières, car la dette technique, n’est pas un ennemi qui frappe sans prévenir. Sa nuisance monte en puissance petit à petit et ne vient pas paralyser un projet d’un coup. Il y a des facteurs qui sont difficiles à voir comme le ralentissement progressif de la productivité dans le développement. Mais il existe des signaux d’alarme typiques qui sont révélateurs d’un niveau assez important de dette technique et qui nécessitent une réaction assez rapide. En voici des exemples :

• On croise les doigts à chaque mise à jour parce qu’en réalité, on n’a pas vraiment confiance en ce qu’on livre
• Les bugs sont très souvent découverts par les utilisateurs et pas en amont
• Pour une fonctionnalité ou une correction de bug ajoutée, une ou plusieurs régressions sont offertes

Maîtriser sa dette technique, c’est par exemple ne pas construire de nouvelles choses sur des bases qui sont déjà bien endettées. Même si il faut parfois s’endetter pour construire des choses rapidement, il ne faut surtout pas construire de nouvelles choses sur des fondations qui ne sont pas solides.

Maîtriser sa dette technique, c’est un combat de tous les instants. C’est un combat qui me tient personnellement à cœur et que je mène au quotidien. Mais c’est une mission difficile dont la réussite n’est pas toujours assurée. Il faut faire face à de nombreuses réticences, aussi bien de la part des développeurs que des décideurs qui ont du mal à nous comprendre. Cela conduit parfois à passer pour le pessimiste ou le rabat-joie de service, et parfois même l’emmerdeur. Personnellement, ça ne me dérange pas vraiment, et même au contraire, ça aurait peut-être tendance à m’encourager, parce que ça signifie que mon action est efficace, même si le but n’est pas d’embêter tout le monde. C’est quelque chose en quoi je crois profondément, et c’est d’ailleurs cela qui me permet d’y consacrer une grande énergie, au grand désespoir parfois de certains de ceux avec qui je travaille.

Amis développeurs, ne l’oublions pas. Rester maître de la dette technique des produits que nous développons fait partie de nos responsabilités. Le jour où l’épée de Damoclès tombera, c’est bien à nous que ce sera reproché. Assumer nos responsabilités signifie notamment de savoir dire non quand c’est nécessaire, quitte à s’attirer les foudres des décideurs.

En résumé, rester maître de sa dette technique, c’est tout simplement être professionnel !

Quelques liens

• Présentation du Software Craftsmanship par Sandro Mancuso à Devoxx France 2014
• The Start-Up Trap de Uncle Bob qui se termine par la phrase suivante : « The only way to go fast, is to go well »

L’image d’en-tête provient de Flickr et représente la Banque Centrale Européenne.