La dette technique est un poison qui coûte un pognon de dingue
Quittons le monde merveilleux de l'innovation pour plonger dans les rouages de l'informatique. Celle qui fait tourner les banques, les gouvernements, le monde. On va causer, très tranquillement et très simplement, d'un poison qui paralyse tous les programmes. Un poison lent, inévitable et très souvent méconnu : la dette technique.
La dette technique paralyse l'économie
Et c'est important.
Vous n'êtes pas développeur ?
Vous n'êtes pas intéressé par l'informatique ?
Restez avec nous.
Ce billet a été écrit pour vous.
Accrochez-vous, ça vaut le coût.
Ah ah.
La dette technique
Écrire des programmes, c'est bien.
Les faire évoluer dans le temps, c'est mieux.
On va parler d'ingénierie logicielle.
Et plus précisément de dette technique.
C'est un sujet franchement complexe.
Mais vous allez tout comprendre :-)
Promis.
Programmer
Tous les programmes évoluent.
Les besoins se modifient, les bibliothèques se transforment, les formats de données changent.
Il est nécessaire de répercuter ces modifications sur les programmes.
Soit pour maintenir leur fonctionnement.
Soit pour l’améliorer.
C'est naturel.
Be quick or be dead
« Tu pourrais modifier ça pour demain ? ».
Tous les développeurs ont entendu cette phrase.
Et soupirés ...
Ils savent qu'aller vite est une mauvaise idée.
C'est contre-productif.
Les modifications rapides sont souvent l'assurance d'une future galère.
Aller vite amène à faire des choix sous-optimaux.
Complexité
Ajouter des fonctionnalités ou faire des corrections rapides, c'est ajouter du code ou de la complexité. Ou les deux.
Un développeur travaille mal quand il est sous la pression d'une deadline.
Code mal écrit, introduction de bugs, sauvegardes plantées, sécurité mise à mal, dépendances ou fichiers inutiles, documentation rarement mise à jour ...
Votre code évolue vite ?
La maintenance sera difficile.
Maintenance
Ce nouveau code pose problème.
Il ne s'intègre pas naturellement ?
Il casse certains fonctionnements ?
Il perturbe la logique interne du traitement ?
Les raisons peuvent être nombreuses.
La conséquence est limpide.
La maintenance du nouveau code sera plus difficile.
Cela signifie que les coûts seront plus élevés et les délais allongés.
« Sortir une première itération de code, c'est comme s'endetter. Une petite dette accélère le développement tant qu'elle est remboursée rapidement par une réécriture. Le danger survient lorsque la dette n'est pas remboursée. Chaque minute passée sur un code qui n'est pas tout à fait correct compte comme un intérêt sur cette dette. Des organisations entières peuvent être paralysées sous la charge de la dette d'une implémentation non consolidée. » Ward Cunningham (1992)
Ward Cunningham est un ponte en ingénierie logicielle.
La dette est inéluctable
Dépendances externes, évolution du langage, manque de développeurs compétents dans cette techno (FORTRAN, C, COBOL), spécifications qui changent etc.
La dette est inéluctable.
Elle s’accumule jusqu’à ce que ses intérêts paralysent le projet.
Elle doit donc être anticipée et gérée.
Il est alors nécessaire de réécrire le code partiellement.
En refactorisant, par exemple.
Voire en reprenant la conception ou les modèles de données.
Un équilibre délicat
Un programme, c'est un équilibre dynamique délicat.
Les trois mots sont importants.
Équilibre : le programme répond correctement aux besoins (=spécifications)
Dynamique : le programme peut être modifié de manière satisfaisante (temps, coûts).
Délicat : les conditions humaines, matérielles, informatiques évoluent en permanence (c'est la vie).
La zone de viabilité d'un programme est donc très restreinte.
Les modifications, même petites, menacent cet équilibre.
Chérir ses programmes
Il faut prendre soin de ses programmes.
C’est une nécessité économique et opérationnelle.
...
Vous ne me croyez pas ?
Prenons l'exemple du bug de l’an 2000.
Un unique langage est lié à un quart des dépenses.
On notait les dates XX au lieu de 19XX.
Cet exemple illustre bien l’impact de la dette technique.
On va donc parler du COmmon Business Oriented Language.
COBOL
COBOL est un vieux langage (1959).
Il date des débuts de l'informatique.
De nombreux programmes de traitement de données ont été initialement écrits en COBOL dans les années 60s et 70s.
Ils n'ont jamais été traduits vers des langages plus récents, pour différentes raisons trop longues à développer ici.
Ces logiciels sont encore massivement utilisés dans les grandes organisations, notamment dans le système bancaire ou les institutions gouvernementales.
Le Monde en parlait la semaine dernière [article payant].
800 000 000 000
On estime que plus de 800 milliards de lignes de COBOL sont encore en production.
Sur des ordinateurs centraux (mainframes).
La maintenance de ce type d’ancien système est difficile.
Les gens qui ont écrit ces programmes sont à la retraite ou décédés.
La dette technique est donc phénoménale.
Ces logiciels sont utilisés en production.
Leur maintenance doit être assurée.
Ça n'est déjà pas une mince affaire.
Pire : ces programmes antiques doivent parfois évoluer.
Il faut donc modifier des programmes parfois vieux de 60 ans.
Un cauchemar
Les coûts d'entretien sont faramineux !
Les coûts de réécriture sont prohibitifs.
Les intérêts de la dette continuent à courir.
Les entreprises se retrouvent ainsi bloquées, à devoir maintenir coûte que coûte des systèmes qu'elles savent dysfonctionnels.
C'est absurde.
Ca vous fait peur ?
Moi aussi.
Il y a de quoi.
La dette technique est un fléau.
Un mal nécessaire.
Qui peut et doit être traité.
Ne construisez pas vos nouveaux outils sans prendre en compte la dette technique.
La bonne nouvelle
Vous allez adorer. Les systèmes IA sont particulièrement sensibles à la dette technique.