La dette technique, expliquée à un dirigeant qui ne code pas

À quoi elle ressemble, vue de votre chaise

Avant les définitions, les symptômes. La dette technique se reconnaît depuis le bureau du dirigeant à des scènes précises, et vous en avez peut-être vécu certaines cette année.

La demande simple au devis inexplicable. Vous demandez d'ajouter un champ sur un formulaire, une colonne sur un export, et le devis revient à huit jours de travail. Personne ne vous ment : dans un code embrouillé, la modification d'une ligne exige de comprendre tout ce qui s'y accroche, puis de vérifier à la main tout ce qu'elle aurait pu casser. Vous payez les intérêts d'emprunts contractés il y a des années, souvent par d'autres, et le devis est le premier document où ces intérêts deviennent visibles.

Le « on préfère ne pas y toucher ». Une partie du logiciel est devenue une zone interdite : elle marche, personne ne sait exactement pourquoi, et le consensus tacite est de ne pas la réveiller. Les évolutions se dessinent désormais autour de cette zone, comme une route qui contourne un marécage, et chaque détour ajoute sa propre complexité. Une entreprise qui contourne son propre outil a déjà commencé à le perdre.

La fonctionnalité fantôme. Quelqu'un demande « mais pourquoi le logiciel fait ça ? », et la réponse honnête est que personne ne le sait : la règle a été codée par quelqu'un de parti, pour une raison que personne n'a notée. Le logiciel applique des décisions dont l'entreprise a perdu la mémoire, et n'ose pas les changer faute de savoir ce qu'elles protègent.

Ces scènes ont un point commun : personne n'y est incompétent, personne n'y est de mauvaise foi, et pourtant l'entreprise paie. C'est la signature de la dette technique, et la raison pour laquelle elle se traite comme un sujet de gestion, pas comme une querelle de personnes.

D'où vient la dette technique

Aucun logiciel endetté n'a été saboté. La dette s'accumule par des mécanismes ordinaires, tous compréhensibles, et les connaître aide à ne pas chercher de coupable là où il n'y en a pas.

Les raccourcis du lancement

Au démarrage d'un outil, la vitesse compte plus que la propreté, et c'est normal : il faut prouver que l'idée tient avant de la peaufiner. Les raccourcis pris à cette époque sont les premières lignes de l'emprunt. Le piège est ailleurs : le prototype qui devait durer six mois fête ses huit ans, et personne n'est jamais repassé derrière.

Les départs et les pertes de mémoire

Le développeur qui a construit l'outil part, et son remplaçant hérite d'un code sans documentation, dont il ne comprend que la surface. Par prudence, il ajoute par-dessus au lieu de modifier dedans, et chaque génération pose sa couche. Au bout de trois départs, le logiciel est un mille-feuille dont personne ne connaît la recette complète.

Les urgences qui deviennent la norme

« On corrige vite pour le client, on nettoiera après. » Dit une fois, c'est de la réactivité. Devenu le mode de fonctionnement permanent, c'est une machine à dette : chaque correction posée en urgence sur la précédente rend la suivante plus risquée, et le « après » du nettoyage n'arrive jamais, parce qu'il y a toujours une urgence plus récente.

Les fondations qui vieillissent toutes seules

Même un code jamais retouché s'endette : les briques extérieures dont il dépend, langage, bibliothèques, système, vieillissent sans lui. Les mises à jour de sécurité repoussées s'empilent, jusqu'au jour où la version utilisée n'est plus corrigée du tout et où chaque mois de retard rend le saut plus risqué. C'est la dette la plus silencieuse, et la seule qui expose aussi à la panne et au piratage.

Le succès lui-même

Un outil conçu pour cinq utilisateurs en sert cinquante, un site prévu pour cent commandes par jour en traite mille. Rien n'a été mal fait : l'entreprise a juste grandi plus vite que ses fondations logicielles. La dette du succès est la plus honorable de toutes, et elle se paie comme les autres.

Ce que la dette technique vous coûte déjà

La dette ne figure sur aucune facture, et c'est ce qui la rend si confortable à ignorer. Elle se paie pourtant tous les mois, sur quatre postes, et le quatrième surprend toujours les dirigeants qui pensaient que le sujet ne concernait que leur équipe technique.

Chaque évolution coûte plus que la précédente

C'est le symptôme que les dirigeants remarquent en premier, sans le nommer : la modification qui prenait deux jours en prend dix, le devis du prestataire enfle sans explication claire, et l'écart se creuse à chaque demande. Les intérêts de l'emprunt sont là, dans la différence entre ce que l'évolution devrait coûter et ce qu'elle coûte.

Les pannes et les régressions

Dans un logiciel endetté, tout se tient par des fils invisibles : on corrige à un endroit, ça casse à un autre, et personne ne pouvait le prévoir puisque personne ne comprend plus l'ensemble. Les pannes tombent aux pires moments, parce que les pires moments sont ceux où l'outil est le plus sollicité.

La dépendance aux personnes

Quand un seul développeur ou un seul prestataire comprend le logiciel, son départ, ses congés ou sa mauvaise humeur deviennent des risques d'entreprise. La dette technique crée des otages : plus le code est illisible, plus celui qui le connaît est irremplaçable, et plus le prix de tout, prestation comme départ, monte.

La valeur de l'entreprise elle-même

Le sujet arrive sur la table au pire moment : une levée, une cession, une transmission. L'acheteur qui audite un logiciel critique et y trouve une dette massive révise son prix, ou exige une garantie. Un outil central sain est un actif ; le même outil endetté est un passif déguisé, et les auditeurs savent très bien faire la différence.

Mesurer la dette sans lire une ligne de code

Vous n'avez pas besoin d'être technique pour évaluer la dette de vos outils. Cinq questions, posées à votre équipe ou à votre prestataire, donnent un diagnostic étonnamment fiable. Notez les réponses, elles serviront de point de départ à toute discussion sérieuse. Et posez-les sur chaque outil dont votre activité dépend, pas seulement le plus visible : la dette la plus dangereuse vit souvent dans l'outil dont personne ne parle jamais, celui qui marche depuis dix ans.

Combien de temps pour un petit changement ?

Demandez le délai pour une modification objectivement simple : un libellé, un champ, une règle de calcul. Une réponse en heures ou en jours dit un logiciel sain ; une réponse en semaines, ou un soupir avant la réponse, dit la dette. Le soupir est une donnée.

Osez-vous faire les mises à jour ?

Demandez de quand date la dernière mise à jour des fondations, et ce qui empêche de faire la prochaine. « On évite d'y toucher, ça pourrait tout casser » est l'aveu d'une dette avancée, et d'un risque de sécurité qui grandit tout seul.

Combien de personnes comprennent le cœur du système ?

Une seule : vous avez un otage et un risque. Zéro, parce que celui qui savait est parti : vous avez une bombe à retardement. La bonne réponse est « au moins deux, et la documentation permettrait à un troisième de s'y mettre ».

Qu'est-ce qui vous prévient quand quelque chose casse ?

Un logiciel tenu a des tests automatisés qui sonnent l'alarme avant la mise en ligne, comme les 1 589 tests qui gardent la plateforme de l'AGFC. Si la réponse est « les utilisateurs nous appellent », vos clients sont votre système d'alerte, et c'est le plus coûteux du marché.

Que se passe-t-il si votre prestataire disparaît demain ?

Avez-vous le code, les accès, la documentation, et le droit contractuel de confier le tout à quelqu'un d'autre ? Cette question ne mesure pas seulement la dette technique : elle mesure votre dépendance, et les deux vont presque toujours ensemble.

Les trois fausses solutions

Face à la dette, trois réflexes reviennent, et les trois aggravent le problème qu'ils prétendent régler. Ils ont un point commun : chacun promet de régler le sujet une bonne fois pour toutes, alors que la dette est un sujet d'entretien, pas d'exorcisme.

Tout réécrire d'un coup. C'est le réflexe le plus séduisant et le plus dangereux : jeter l'ancien système, repartir de zéro, « bien faire cette fois ». Les réécritures totales durent toujours plus longtemps que prévu, et pendant ce temps l'ancien système continue de vivre, d'évoluer et de creuser l'écart avec sa copie en construction. Beaucoup ne rattrapent jamais leur cible. L'histoire de l'informatique en garde un exemple fameux : à la fin des années 90, l'éditeur du navigateur Netscape, alors dominant, a choisi de tout réécrire de zéro ; la réécriture a pris des années, le produit a cessé d'avancer pendant ce temps, et le marché est parti chez le concurrent. La réécriture se justifie parfois, la suite de cette page dit quand, mais jamais comme premier réflexe.

Ne rien faire, puisque ça marche encore. La dette a cette propriété de sembler indolore jusqu'à l'incident : la panne un jour de pointe, la faille exploitée, le départ de la seule personne qui savait. Attendre transforme un chantier planifiable en crise, et les crises se paient au prix fort, dans l'urgence, sans mise en concurrence et sans recul.

Changer de prestataire sans état des lieux. Le nouveau venu hérite d'un code qu'il ne connaît pas, le juge irrécupérable, préconise la réécriture complète, et le cycle recommence. Changer de mains peut être la bonne décision ; elle se prend après un état des lieux écrit, jamais sur la promesse qu'ailleurs l'herbe est plus verte.

Rembourser sans tout réécrire : la méthode

La dette technique se rembourse comme la dette financière : par échéances régulières, en commençant par les taux les plus élevés. La méthode tient en quatre mouvements, et elle ne suspend jamais la vie normale du logiciel : vos équipes continuent de travailler, les évolutions continuent de sortir, et le remboursement se glisse dans le rythme existant au lieu de le remplacer.

D'abord sécuriser : sauvegardes testées, mises à jour de sécurité critiques, accès repris en main. C'est la part non négociable, celle qui protège l'entreprise pendant tout le reste, et elle coûte peu.

Ensuite poser des tests autour des parties qui comptent : les tests automatisés sont le harnais qui permet de toucher au code sans peur de tout casser. On ne teste pas tout, on teste ce qui fait mal en cas de panne : la facturation avant la couleur des boutons.

Puis rembourser par tranches, à l'occasion des évolutions : chaque fois qu'une demande métier touche une zone endettée, on nettoie cette zone en même temps qu'on la modifie. L'évolution coûte un peu plus cher, la suivante coûte moins, et la dette fond là où le métier travaille, c'est-à-dire exactement là où elle gêne.

Enfin écrire ce qu'on découvre : chaque zone comprise est documentée, chaque règle métier exhumée du code est validée par quelqu'un du terrain. Le remboursement de la dette technique produit un sous-produit précieux : la connaissance de votre propre système revient dans l'entreprise.

Le vocabulaire pour suivre la conversation

Cinq mots reviennent dans toutes les discussions sur la dette, et les comprendre change le rapport de force : vous cessez de signer des devis sur parole.

Refactoring (ou remaniement)

Réorganiser le code sans changer ce que le logiciel fait : même comportement dehors, structure plus saine dedans. C'est l'acte de remboursement type. Un devis de refactoring n'ajoute aucune fonction visible, et c'est pourtant lui qui fait baisser le prix de toutes les évolutions suivantes.

Tests automatisés

Des programmes qui vérifient le logiciel à chaque modification : si une correction casse la facturation, l'alarme sonne avant la mise en ligne, pas chez le client. C'est le harnais de sécurité de tout le reste ; sans tests, chaque intervention sur un code endetté est de l'acrobatie sans filet.

Dépendances

Les briques extérieures dont votre logiciel se sert : langage, bibliothèques, composants. Elles vieillissent toutes seules, et « mettre à jour les dépendances » est l'entretien de base, l'équivalent de la vidange. Un prestataire qui ne vous en parle jamais n'en fait probablement pas.

Legacy (ou code hérité)

Le code ancien, écrit par d'autres, sans tests et souvent sans documentation. Le mot sonne comme une condamnation ; il décrit surtout un code qui a survécu assez longtemps pour devenir critique, ce qui est une forme de réussite. Le legacy ne se jette pas, il s'apprivoise, tests d'abord.

Documentation

Tout ce qui permet à quelqu'un de nouveau de comprendre le système sans archéologie : comment il est bâti, pourquoi ces choix, comment le faire tourner. C'est la mémoire externe de votre outil, et le premier livrable à exiger de toute mission de reprise, parce que c'est elle qui vous rend libre de changer de mains.

Sur un projet neuf : la prévenir au contrat

Si vous lisez cette page avant de faire construire un outil, vous avez une chance que les autres n'ont plus : la dette de demain se limite dans le contrat d'aujourd'hui. Quatre clauses font l'essentiel du travail.

Les tests automatisés comme livrable, pas comme option : le contrat précise que les parties critiques sont couvertes et que la suite de tests est livrée avec le code. La documentation comme livrable, pareillement : architecture, choix structurants, procédure d'installation. Ces deux lignes coûtent un peu à l'achat et changent tout à la revente.

La maintenance chiffrée dès le devis initial, entre 10 et 15 % du coût par an, mises à jour de dépendances incluses : un outil vendu sans son coût d'entretien est un prix d'appel, pas un prix. Et la propriété complète, code, documentation et accès, avec le droit écrit de confier la suite à quelqu'un d'autre : c'est la clause qui empêche la dette de se doubler d'une dépendance.

Ces exigences trient les prestataires mieux qu'aucun appel d'offres : celui qui les accepte sans se crisper travaille déjà comme ça. Le guide du logiciel sur mesure consacre une section entière à ce choix, questions à poser comprises.

Quand la réécriture s'impose quand même

Il existe des cas où rembourser coûterait plus cher que reconstruire, et prétendre le contraire serait malhonnête. Les critères qui font pencher vers la reconstruction : des fondations mortes, plus mises à jour ni corrigées par personne, ce qui transforme chaque mois d'attente en risque de sécurité ; un métier qui a tellement changé que l'outil décrit une entreprise disparue, et que le remboursement reviendrait à restaurer une maison qu'on veut démolir ; un code que plus aucun professionnel n'accepte de maintenir à un prix raisonnable, signe que le marché a déjà voté ; ou un volume d'activité que l'architecture d'origine ne peut structurellement plus porter, quand l'outil pensé pour dix personnes en sert deux cents.

Même dans ces cas, la reconstruction ne se fait pas d'un coup : elle se fait morceau par morceau, le nouveau système reprenant les fonctions une à une pendant que l'ancien continue de tourner, avec les données migrées et comptées à chaque étape. L'image qui aide : du lierre qui recouvre un mur, fonction après fonction, jusqu'au jour où le mur ne porte plus rien et peut tomber sans bruit. À aucun moment l'entreprise ne travaille sans outil, et à chaque étape le chantier peut s'arrêter sur un état stable. C'est le sujet de la page suivante de ce guide, consacrée à la refonte, et c'est un chantier qui se cadre avec un audit préalable, jamais sur un devis établi de loin.

Un exemple de reprise réussie, avec ses chiffres publiés : le site et l'arrière-boutique du Groupe des Arbitres Genevois, repris vieillissants, reconstruits, avec 557 inscrits et 1 355 pièces d'archives récupérés de l'ancien système, et depuis, zéro prestataire à rappeler pour changer un texte.

Reprendre l'outil d'un autre : notre quotidien

Une partie de notre travail consiste à reprendre des outils construits par d'autres : le prestataire a disparu, la relation s'est usée, ou l'agence d'origine ne fait plus de maintenance. Si vous êtes dans cette situation, deux choses méritent d'être dites.

La première : un code hérité n'est presque jamais aussi mauvais que le dit le premier professionnel qui le découvre. Juger le travail du prédécesseur est un réflexe de métier, et préconiser la réécriture est plus confortable que comprendre l'existant. Exigez un état des lieux écrit, avec la liste de ce qui va, de ce qui presse et de ce qui peut attendre, avant toute préconisation lourde.

La seconde : la reprise est le moment idéal pour corriger le vice d'origine, celui qui a rendu la dette possible. Le code passe en votre propriété, la documentation devient un livrable, les tests deviennent la règle, et la clause de réversibilité entre au contrat. La dette technique se rembourse ; la dépendance, elle, se résilie, et c'est le bon moment. Notre guide du logiciel sur mesure détaille ces clauses dans sa section sur le choix du prestataire.

La conversation à avoir avec votre prestataire

Reste à transformer cette page en action, et ça commence par une réunion, pas par un chantier. Convoquez-la sans accusation : la dette s'est accumulée par des mécanismes ordinaires, et le prestataire ou le développeur en face de vous en a probablement hérité autant qu'il en a produit. Une conversation qui cherche un coupable produit de la défense ; une conversation qui cherche un état des lieux produit un plan.

Posez les cinq questions de cette page, et écoutez autant la forme que le fond : les hésitations, les « c'est compliqué », les sujets évités disent où la dette se cache. Demandez ensuite trois listes écrites : ce qui est sain, ce qui presse (sécurité et sauvegardes d'abord), et ce qui peut se rembourser au fil des évolutions. Ces trois listes sont le vrai livrable de la réunion.

Fixez enfin deux règles pour la suite, et mettez-les par écrit dans le compte rendu : plus aucune évolution ne se fait sans son petit remboursement attenant, et la maintenance annuelle devient une ligne budgétaire assumée plutôt qu'une négociation récurrente. Prévoyez de reposer les cinq questions dans un an, même réunion, même format : la comparaison des réponses d'une année sur l'autre est le tableau de bord le plus simple qui existe pour ce sujet. Un bon prestataire accueille ces règles avec soulagement : elles lui donnent enfin le mandat de bien faire ce qu'il rognait faute de budget. Une réaction défensive ou évasive, elle, est une information qui vaut tous les audits.

Et si la conversation n'est pas possible, parce que le prestataire a disparu ou que la confiance est rompue, l'état des lieux se fait de l'extérieur : c'est exactement le format de reprise décrit plus haut, et il commence par un simple appel. Trente minutes suffisent en général pour savoir si votre situation relève de l'entretien, du plan de remboursement ou de la reconstruction, et vous repartez avec un avis posé dans les trois cas.

Combien coûte le remboursement

L'état des lieux d'abord : sur un outil central et un périmètre flou, un audit de 5 000 à 15 000 euros pose le diagnostic écrit, la liste des risques classés, et le plan de remboursement par tranches. Sur un outil plus simple, l'état des lieux tient parfois dans les cinq questions de cette page, posées lors d'un appel.

Le remboursement lui-même se fond ensuite dans la vie normale du logiciel : une part de chaque évolution, et le budget de maintenance annuel, de 10 à 15 % du coût de l'outil, qui cesse d'être une dépense subie pour devenir l'échéancier de l'emprunt. La sécurisation initiale, sauvegardes et mises à jour critiques, se chiffre à part et rarement cher ; c'est la meilleure première dépense de tout le chantier.

Le diagnostic en ligne permet de situer votre cas en huit questions, et un appel de trente minutes suffit en général pour dire si votre dette relève de l'entretien courant, du plan de remboursement, ou de la reconstruction morceau par morceau.