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

• Appréhender la notion de dette technique
• La dette technique (sur Wikipédia)
• Changer de jeu de caractères pour UTF-8