La dette technique en exemple

Openweb.eu.org > Blog  > La dette technique en exemple

Abstract

De nombreux articles évoquent le concept de dette technique concernant les sites Web. Toutefois, plutôt qu’un long cours théorique, je vous propose… un retour d’expérience.

Article

Le concept de dette technique peut se résumer ainsi : toute erreur de conception implique des coûts supplémentaires dans le futur. Ces coûts, par analogie avec la dette financière, sont appelés les intérêts. Toute la gestion de la dette technique se résume en une question : souhaite-t-on continuer de rembourser des intérêts ou faut-il solder sa dette une bonne fois pour toutes ?

La réponse à cette question n’est pas aussi simple que l’on pourrait croire. Entendons-nous bien : même s’il est aisé de chercher des personnes coupables ou de dire que les solutions étaient évidentes a posteriori, ces problèmes sont loin d’être manichéens. La pression pour mettre en ligne rapidement, les temps de développement, les connaissances manquantes et/ou incomplètes d’un sujet, l’emploi du temps chargé, etc. peuvent vous amener à créer de la dette technique très rapidement.

Une fois ces éléments posés, laissons de côté la théorie et venons-en à une histoire bien concrète tirée d’un cas réel. Et comme toute sombre histoire policière, nous avons des acteurs, une association de malfaiteurs, un crime… et des nettoyeurs.

Ironie du sort (en tout cas du mien), le sujet principal de cette histoire m’est bien connu, car j’ai moi-même écrit un article ici sur le sujet !

Une sombre histoire

Notre client a un site Web d’une certaine importance, ce dernier est en langue anglaise. Propulsé par un CMS de bonne facture, il gère plutôt bien son activité, peu de problèmes sont à relever. Nous sommes il y a un peu plus de huit ans.

Il y a bien quelques modules qui gèrent quelques aspects particuliers, comme de complexes formulaires, mais peu de bugs sortent. Remise en perspective, la qualité du site Web est plutôt bonne.

Trois années passent, le site a beaucoup grandi, l’activité s’est intensifiée. Le site a été connecté la première fois à un CRM avec succès, les différents modules remplissent bien leurs bases de données respectives. Il y a bien quelques curiosités quand il faut faire un export d’une base de données, mais cela se règle en deux clics sous un bon éditeur de code.

Trois années passent encore, une refonte de grande ampleur est lancée, et j’ai fait mon entrée dans cette histoire il y a quelques mois. Un existant conséquent est là, et il faut traiter avec. Les bases continuent de grandir et ne sont déjà plus manœuvrables à la main : comprenez par là qu’il n’est pas possible de patcher un par un les enregistrements si un problème est détecté, en tout cas, pas dans un temps acceptable.

De très nombreux modules sont conçus afin de rendre le client de plus en plus indépendant, et surtout pour garantir une bonne qualité : bon nombre de parties seront ainsi plus prédictibles, et ce afin d’éviter le côté « gestion à la main » de l’ancien site.

Entre temps, le site doit discuter avec un nouveau CRM. L’équipe est constamment sollicitée et – doux euphémisme – ne chôme pas. Croulant sous le travail, l’équipe développe le site de la même manière qu’il a toujours été développé.

C’est là qu’entrent en scène nos méchants.

L’association de malfaiteurs

Il y a bien toujours cette bizarrerie quand est demandé un export d’une base de données. Mais comme on arrive à le gérer à moindre frais, il n’y a aucune raison d’aller s’embêter à gratter ces points de détails.

En fait, en guise de premier malfaiteur, nous avons affaire à un problème dormant : le site étant en anglais, les erreurs de codage ne sautent pas aux yeux. Elles sont même très rares.

Ce problème technique est jugé mineur, et, au vu de la charge dantesque de travail, systématiquement remis à plus tard. Voici notre deuxième malfaiteur.

Troisième malfaiteur, le site (en tout cas ses modules) se développe de la même manière. Jamais au grand jamais, les erreurs ou étrangetés ne sont prises à la source. De toute manière, certaines bases sont devenues si lourdes qu’il n’est pas envisageable d’aller secouer l’arbre sous peine de recevoir de lourds fruits sur la tête.

Dernier malfaiteur pourtant bien innocent, le site a de nombreux modules très interdépendants. Le module « a » se base sur le « b », tel plugin agrège de nombreuses bases pour permettre des vues avancées sur les données, toute la chaîne discute avec le CRM et inversement, etc.

Le crime

L’activité de notre site a explosé, même s’il rayonnait déjà au niveau mondial, il s’implante dans divers pays très sympathiques, comme la France, l’Allemagne, la Suède ou l’Espagne (vous comprenez pourquoi j’évoque ces pays, avec des alphabets si… accentués). Des personnes dans ces pays s’impliquent. L’activité grandit et se diversifie.

Et là, les problèmes dormants commencent à se réveiller : on aperçoit de plus en plus des problèmes de codage, assez imprévisibles. Comment expliquer que parfois les caractères allemands soient bien affichés là où certains caractères français ou suédois sont rendus bizarrement par exemple ? Qui plus est, les pages sont pour la plupart rendues correctement sur PC, là où elles ne le sont pas du tout sur Mac. Et quid de ce bug bizarre : il suffit de rafraîchir la page pour que les erreurs de codage disparaissent miraculeusement sous Internet Explorer (?!).

Il est bien demandé à l’équipe de régler ce problème, toutefois elle se retrouve rapidement bloquée : comment patcher un module utilisé par un autre sans qu’il y ait de la casse dans l’un des deux à l’affichage ?

Les faux-« bons réflexes » viennent rapidement :

  • incriminer un copié/collé depuis Word dans une zone d’édition riche (qui apporte son lot de code non standard, il est vrai) ;
  • utiliser à tort et à travers des fonctions comme utf8_encode() ou utf8_decode() pour cacher la poussière sous le tapis ;
  • incriminer les navigateurs, vu que certains arrivent à afficher correctement les pages, etc.

Certaines tables « autonomes » sont bien patchées rapidement, mais elles sont rares. Le problème s’envenime quand certains clients du site voient leur nom mal affiché (Álexandrò von Öttø Åñdrõß). La tension monte et le site multiplie les erreurs d’affichage dans divers modules. Curieusement, le problème donne l’impression de se propager comme une épidémie, les signalements de problèmes ne font qu’augmenter au point d’entacher la crédibilité du site, et du client par la même occasion.

Le colosse se retrouve… avec des pieds d’argile.

La traque

L’équipe est sommée de régler ce problème au plus vite, tous les développements sont arrêtés : impossible de continuer dans ces conditions. Les mauvaises nouvelles ne venant jamais seules, il est impossible d’utiliser le serveur de développement pour préparer une contre-attaque : ce dernier contient trop de développements en cours, impossible de l’utiliser pour régler ces problèmes !

Dans son malheur, l’équipe a une chance : le site a un troisième serveur, normalement prévu pour faire des essais chez le client. Il est possible de le mettre à contribution. Immédiatement le serveur de production est dupliqué intégralement sur ce serveur de secours. L’équipe cherche une solution globale, toutefois elle doit vite se rendre à l’évidence : la magie n’existe pas, il faudra étudier chaque maillon de la chaîne, et il n’y a aucun moyen de résoudre tout d’un coup.

L’équipe cherche une procédure pour chaque maillon de la chaîne, les essais vont bon train. Elle constate que la fonction utilisée pour échapper les caractères dans les requêtes SQL est défaillante. La base de données a également des problèmes d’interclassement, les fonctions d’import depuis le CRM sont également prises en défaut. Toutes ces fonctions généraient des erreurs qui se compensaient plus ou moins entre elles, d’où le temps constaté pour que le problème « explose ».

Les procédures vont bon train, l’équipe a une chance, les problèmes du site ont une certaine constance. L’équipe se prend même une bonne dose d’optimisme : les solutions arrivent et certaines opérations pourront être effectuées automatiquement. La dose d’optimisme retombe aussi vite, un problème de taille arrive.

Si patcher quelques fichiers n’est pas excessivement dur à déployer, un problème monstrueux se profile : s’il peut être acceptable de dire au client que le flux de données du CRM sera fermé temporairement, que le(s) système(s) de gestion du site seront également bloqués temporairement, comment patcher des bases très lourdes en production sans couper l’accès, sans perte d’information, et surtout sans perte d’activité pour le site ? (car évidemment de nombreux modules rapportent de l’argent, il n’est pas envisageable de les couper)

Toutes les options sont envisagées : travail la nuit, le week-end, etc. L’expert en Analytics cherche même des créneaux horaires propices. Espoir vite oublié : le rayonnement international du site interdit tout créneau acceptable. Il faudra faire sans.

L’équipe cherche alors à minimiser le plus possible l’impact. Il faudra patcher vite et bien en direct sur les bases en production. Les bases les plus lourdes seront patchées en priorité, et une fois que la machine sera lancée, il ne sera pas envisageable de s’arrêter ou même de faire une pause ! Certaines parties non critiques seront fermées temporairement, d’autres seront laissées en production.

… cette stratégie risquée a fonctionné, la quasi-majorité du site a pu être rattrapée.

Les leçons à en tirer

Même si les solutions peuvent sembler évidentes a posteriori, rien n’est manichéen : la gestion d’un historique et d’un existant peut vous amener à faire de mauvais choix, et il n’y aura pas nécessairement de coupable direct : par exemple, la pression du client combinée aux erreurs (même minimes) de l’équipe au début du projet il y a huit ans peuvent dans certaines conditions créer des bombes à retardement.

Ces problèmes dormants sont les pires, ils peuvent subitement vous exploser à la figure, alors qu’ils auraient pu rester en sommeil à jamais. Idéalement, quand ce genre de monstre sort de sa tanière, n’attendez pas : tranchez-lui la tête le plus vite possible, n’attendez surtout pas que le phénomène prenne une trop grande ampleur.

Évidemment, a posteriori, il est simple de remarquer que si l’équipe avait fait une simple vérification il y a huit ans en utilisant des caractères accentués, ce problème aurait pu être résolu en amont. Toutefois, cet aspect restera dans le passé, car nous n’avons aucun moyen de connaître les conditions qui ont généré cette petite erreur aux grandes conséquences.

Dans le plus extrême des cas (et j’insiste bien sur le mot « extrême »), si vous constatez une erreur et qu’on ne vous donne pas du tout la possibilité de la corriger, documentez-la et essayez « au pire » de la garder constante, ainsi, la résoudre à l’avenir sera plus facile.

En tout cas, quand le choix est fait de rembourser la dette, dites-vous bien qu’il ne faut pas lésiner sur les moyens. Répétition générale, serveur dédié, essais, procédures, stratégie, tous les moyens sont bons.

Compléments

À propos de cet article

  • Openweb.eu.org
  • Thème : Qualité, Études de cas
  • Auteur :
  • Publié le :
  • Mise à jour : 17 avril 2013
  • 8 commentaires

Vos commentaires

  • Mem’s Le 17 avril 2013 à 11:20

    Tous les problèmes n’ont pas le même impact, ceux touchant au données sont les plus importants (surtout dans la situation présenté).

    D’autres problèmes qui peuvent aboutir à une dette technique sont des fonctionnalités qui sont utilisés autrement que ce pour quoi elle ont été prévues. Sur du front-end, par exemple, on utilise le user-agent pour détecter si c’est IE, Firefox ou Safari iOS et produire du code (HTML/CSS/JS) adéquate pour contourner les bugs actuels. Seulement ces tests ne prennent pas en compte le forward compatibility, le cas où le bug à été réparé dans une version ultérieur ou qu’une version plus récente d’un navigateur ne s’identifie pas de la même façon que les version antérieurs (cf. IE 11 vs. IE 10-).
    D’autres exemples existent comme l’utilisation de propriétés/fonctionnalités CSS/JS préfixés sans prendre en compte une version non préfixé. Ex. : -webkit-transform: rotateX(120deg); nécéssite aussi qu’on utilise transform: rotateX(120deg); pour les navigateur implémentant le Standart REC (Recommendation).

  • Nicolas Chevallier Le 27 avril 2013 à 21:27

    Très bon article qui part d’une histoire vraie. C’est évident q’un projet évolue au fil des années et qu’il vaut mieux batir le site sur des fondations solides pour éviter que l’on s’arrache les cheveux (ou que d’autres se les arrachent après nous le plus souvent).

    Mais il ne faut pas oublier l’inverse que j’ai vécu : un entrepreneur qui a une bonne idée et qui décide de se lancer sur le net. Comme il se projette à moyen/long terme, il décide de gérer dès le lancement plusieurs langues, plusieurs monnaies... Un an après le site est lancé mais il est lent, mal référencé et au final inutilisable en l’état. C’est là ou j’interviens et qu’une décision radicale est prise pour "simplifier" le tout quitte à casser et à rendre le site moins évolutif sur le long terme. Au final le site décolle.

    Je pense qu’on ne peut prévoir de telles évolutions (à l’international) et qu’il est difficile d. J’imagine qu’en 8 ans aussi les outils ont changé, les technos, les bibliothèques... Bref une refonte globale était peut être même nécessaire et n’était pas prévisible au lancement.

    Nicolas Chevallier

  • Nicolas Hoffmann Le 29 avril 2013 à 12:35

    > Très bon article qui part d’une histoire vraie.

    Qui est une histoire vraie, certifiée vécue par l’auteur sourire

  • Arnaud LEMAIRE Le 30 mai 2014 à 11:03

    Au delà du concept de dette logiciel, j’aime beaucoup l’idée de l’entropie appliquée au logiciel.

    Ce principe exprime qu’un système ne peux qu’évoluer que vers plus de désorganisation ce qui implique que la dette logicielle est quelque chose de "naturel" dans le cycle de vie d’un logiciel.

    Il faut donc avoir une attention de tous les instants pour lutter contre la production de dette.

    J’explique plus en détail cette réflexion dans un article http://lilobase.wordpress.com/2014/...

  • Alexeo Le 11 juillet 2014 à 16:07

    Bonjour,
    Je ne connaissais pas cette notion de dette technique et je la découvre au travers de votre article. C’est un très très bon exemple que vous nous proposez.
    En revanche, il s’applique à de très grosses structures car je ne pense pas qu’on puisse se retrouver dans ce genre de situation au sein d’une PME. Sauf bien entendu si l’activité explose et implique de mettre en place de gros moyens.
    Merci pour cette lecture.

  • Nicolas Hoffmann Le 14 juillet 2014 à 10:31

    Bonjour,

    détrompez-vous, la dette technique menace tout le monde, même les petites structures. C’est très facile d’en accumuler, vu que ce sont parfois des problèmes dormants. Attention quand ils se réveillent.

  • Laurentj Le 30 juillet 2014 à 15:34

    @Alexeo : le problème de la dette technique est tout aussi critique dans une PME que dans une grosse boite. Ça peut même être pire, car une PME n’aura probablement pas autant de moyen humain et financier à mettre derrière la résolution d’un problème. Et si en plus le site de cette PME est sa principal source de revenu, et qu’il faille couper l’accès plusieurs heures à cause d’un crash ou d’une restauration d’un site, cela peut être dramatique. (et puis, la taille de la boite ne présage pas le volume de données géré).

    À cela il faut ajouter la loi de Murphy (http://fr.wikipedia.org/wiki/Loi_de_Murphy) : si la dette technique peut aboutir à une catastrophe, soyez sûr que cela arrivera.

    Donc non, la dette technique n’est pas à négliger, que l’on soit PME ou grand groupe.

  • inf0mag Le 27 novembre 2014 à 22:06

    C’est vrai que si des tests bien aboutis ont été menés par les développeurs à l’époque on aurait pu éviter tous ces problèmes, mais il faut signaler que malgré les tests, on n’est jamais sur à 100% qu’un logiciel est exempt de bugs (surtout s’ils se manifestent pas lors de l’exécution des scénarios de tests)

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom