La dette technique : quand un système qui fonctionne devient difficile à faire évoluer

Tout le monde le sait : la dette technique, c'est mauvais. Et pourtant, Franck ouvre cet épisode du podcast Orbeet par un aveu assumé : « La dette technique, ça marche. » Sur le court terme du moins. Car rester avec un système qui fonctionne coûte moins cher que d'investir dans une migration dont on ne perçoit pas l'intérêt immédiat. Le problème, c'est quand la facture finit par tomber — et qu'elle tombe d'un coup. À travers plusieurs cas vécus, Franck et Florent montrent pourquoi la dette technique n'est pas une fatalité, et comment s'organiser pour qu'elle ne s'accumule jamais.

Dix ans de tranquillité, une migration au prix fort

Premier récit : un client démarré sur OpenERP 7, soit dix versions de retard au moment d'Odoo 17. 250 utilisateurs satisfaits, des écrans custom stables, aucun incident. « Pourquoi je paierais pour migrer ? » demandait-il régulièrement — et Franck concède que de ce point de vue, la question est légitime : pour un processus métier stable et sur mesure, la nouvelle version n'apportait rien.

Puis un jour, le point de bascule est arrivé d'un endroit inattendu : le navigateur. En dix ans, les navigateurs avaient monté de version et le JavaScript ne se comportait plus pareil. Les écrans de saisie en ligne commençaient à bugger, y compris sur des Firefox ESR gelés au maximum. Trop de monde impacté, trop de support : le client a rendu les armes. « D'accord, j'avoue, on va migrer. »

Le parallèle est celui de la copropriété : « il faudrait ravaler la façade », repoussé année après année pendant que les prix des matériaux montent, jusqu'au devis doublé — et au jour où ce n'est plus vous qui décidez, mais la mairie qui le rend obligatoire. Passer d'OpenERP 7 à Odoo 17, il y avait du travail.

Phase deux, moins visible mais tout aussi décisive : les audits de sécurité du groupe sont devenus réguliers et ont remonté des CVE présentes dans les vieilles versions. Le client a alors complètement changé de fusil d'épaule : migration tous les deux ans, inscrite au planning, l'objectif étant d'afficher une courbe « flatline, tout est vert » à chaque audit. Contre-intuitif mais vérifié : la migration biennale coûte beaucoup moins cher que la grande migration décennale. On la connaît mieux, les développeurs travaillent sur la version en cours et non sur un framework d'il y a dix ans, et la répétition permet de l'industrialiser. Cerise sur le gâteau : les équipes du client ont été formées et prennent une partie de la migration à leur charge, Orbeet assurant la code review et les grands axes. Autonomie accrue, coûts diminués, et un directeur informatique qui « dort beaucoup mieux maintenant ».

L'effacement progressif de la dette : du spécifique vers le standard

Autre cas, à l'autre extrémité du spectre : une utilisatrice unique, sur Odoo 8, avec du développement spécifique — car le spécifique qui fait gagner dix heures par semaine se justifie pleinement, même pour une TPE. Premier incident, la base perdue ; premier allègement, le passage sur Odoo SH qui embarque l'hébergement. Puis, à chaque migration, la dure loi du portage : il faut porter les modules, les devis, les commandes — « tout ce que tu as touché ». L'analogie de Franck est parlante : c'est la 205 dans laquelle tu as scié le tableau de bord pour installer un GPS ; pour passer à la 206, il faut choisir entre le GPS d'origine ou rescier la planche.

La sortie du piège s'est faite par étapes : d'abord la conversion du spécifique en Odoo Studio — champs, vues, automatisations sans code métier —, qui a rendu les montées de version nettement plus économiques ; puis l'installation de Redner pour les rapports PDF, cette dernière pièce des personnalisations qui restait en développement. Bilan : passer de dix jours de migration tous les deux ans à une demi-journée de tests. Démonstration qu'effacer sa dette technique est possible, à condition de choisir des briques maintenues par un éditeur qui les porte régulièrement — car un module complémentaire qui n'est plus porté, c'est une dette technique en devenir, parmi les 70 000 modules disponibles sur apps.odoo.com, qu'un client final n'a pas les moyens d'auditer seul.

« On vous le fait en trois jours » : les coûts cachés de l'offre pas chère

Franck et Florent pointent une difficulté commerciale réelle : face à des concurrents qui promettent l'adaptation « en trois jours », l'intégrateur qui annonce les coûts de long terme — documentation, tests unitaires, provisions pour la migration — paraît plus cher. L'arnaque de la dette technique non annoncée, c'est exactement cela : « nous, on fait ça en trois jours », en réalité « on met de la dette technique jusqu'au plafond, on sera partis au moment de la migration ». Florent a vu un client hésiter entre une proposition à 3 000 € et une à 30 000 € — impossible de faire le grand écart.

La règle de lucidité posée dans l'épisode : le développement spécifique coûte vite cher, et pour une TPE/PME, il devrait devenir envisageable seulement à partir de budgets de l'ordre de 50 000 à 100 000 €. L'honnêteté fait parfois perdre des affaires, « puis à un moment donné, le client prend un coup de bambou ».

Lasagnes, bus factor et bibliothèques disparues

Parmi les autres figures de la dette technique évoquées : le « développement lasagne », ces couches de personnalisations ajoutées au fil des demandes quotidiennes, qui deviennent critiques le jour où le développeur qui les maintenait part — en retraite, ou fâché. C'est le bus factor : une seule personne, et si elle disparaît, le système ne tourne plus. La parade : du code commenté, des projets documentés, des tests unitaires. Le prototype rapide est légitime en phase d'exploration ; mais dès que l'outil devient l'outil de production de l'entreprise, « on n'a pas le choix », il doit être refait proprement — car le temporaire qui devient permanent, « on connaît tous ».

Les dépendances technologies frappent parfois plus bas que prévu : un autre client d'OpenERP 7 resté sur Python 2 s'est retrouvé dans une impasse quand les distributions ont abandonné le support du langage — plus de librairies trouvables, des VM de vieilles Ubuntu qu'on recopiait d'un PC à l'autre, des dépôts introuvables, « un enfer ». Autre cas : sorti d'Odoo SH pour figer ses versions sur un serveur OVH, un client n'était même plus capable de recompiler les librairies le jour où il a fallu débugger — de l'« archéologie ». Quant à Docker, il ne résout rien sur le temps long si personne ne garantit la disponibilité des images dans dix ans.

La dette technique ne se cache pas toujours où on la croit

Deux nuances finales qui bousculent les idées reçues. D'abord, un Odoo Studio bien maîtrisé et bien documenté, sans Python disséminé partout, est préférable à vingt-cinq modules téléchargés au hasard sur Internet et posés sur le serveur — avec un risque de rupture moindre à la migration. Ensuite, le paradoxe du full-spé : des clients qui utilisent Odoo comme une brique technique et construisent leur application par-dessus migrent plus facilement et plus sereinement que ceux qui ont greffé de petites adaptations fonctionnelles complexes au cœur des processus standards — splitter des lignes de devis d'une certaine façon, par exemple. Moins on s'insère entre le standard et son évolution, moins on risque que ça casse.

Faire du jetable peut être un choix conscient et valable — une société événementielle destinée à fermer dans deux ans n'a pas à provisionner des migrations. Mais si votre système d'information doit être là dans dix ou quinze ans, la conclusion est sans appel : intégrer la notion de migration dès la conception, dans le code comme dans le paramétrage. La dette technique n'est pas une fatalité — c'est un choix, et il se pilote.

Retrouvez l'intégralité de cet échange dans le podcast Orbeet :

https://www.youtube.com/watch?v=KjN0hyP4NDE