Dans le même esprit que la dette technique en exemple, je vais vous raconter une histoire vécue il y a peu. Je vous propose donc une petite enquête policière : « la recherche du coupable de la chaine de production ».

Comme toute enquête, nous aurons plusieurs protagonistes :

• le développeur,
• le client,
• et l'enquêteur, moi en l'occurrence.

Plantons le décor : le site Web envoie des données à un CRM via un export de données en XML. Ledit CRM renvoie également des données, toujours dans le format XML, le site ayant un parser qui mouline ces fichiers et insère les données correctement.

Tout ce qui est côté CRM est du ressort du client, tout ce qui est côté site est du ressort du développeur.

Suite à plusieurs ajouts sur le site, l'import/export des données a été modifié. Les données sont censées revenir dans un certain ordre, disons que les données « B » ont besoin des données « A » pour fonctionner correctement sur le site. À cet effet, si les données « A » ne sont pas revenues avant les données « B », elles seront stockées dans un dossier d'attente.

Et c'est là que commence notre histoire, le client appelle le développeur et signale qu'il doit y avoir un problème, le dossier en question déborde de fichiers XML. Le développeur vérifie… 350 fichiers en attente. Pour un système prévu pour être une zone très temporaire, c'est un peu fort !

Le développeur observe un peu les noms de fichiers, il constate déjà que l'export du CRM fait un peu trop de zèle : les mêmes enregistrements sont exportés plusieurs fois, parfois même à seulement quelques secondes. Coupable : le client ?

Le développeur commence un travail méticuleux de tri, le nombre de fichiers XML est réduit à une petite centaine. Le client remarque à juste titre que le système du dossier d'attente pourrait être un poil moins stupide, coupable : le développeur ?

Le développeur remarque qu'attendre 6 mois pour signaler cela n'était pas une bonne idée. Du reste, si le CRM faisait ce qui a été défini pour l'envoi de données (l'ordre d'arrivée, d'abord les données « A » et ensuite les données « B »), ils n'en seraient pas là. Coupable : le client ?

Durant l'analyse des données et du pourquoi de leur rejet par le parser, le développeur remarque que le CRM envoie des données bizarres, le parser n'est pas construit pour gérer des cas non-prévus. Pour donner un ordre d'idée, par exemple, le champ « id_web » contient le numéro de la commande au lieu d'un simple nombre. Coupable deux fois : le client ?

Là, vous seriez tenté de dire que le client a tout faux, on a défini une procédure, on sort des clous et l'on s'étonne que cela ne marche pas ! Hé bien, ce n'est pas aussi simple que cela.

Le client demande au développeur de vérifier les exports de données du site vers le CRM. Il y a deux parties qui exportent ces données. Le développeur ouvre la première et stupeur : les données avec lesquelles il popule le « id_web » sont… bien celles des numéros de commande ! Un copier/coller malheureux ou une faute d'inattention sûrement, donc le CRM ne renvoie jamais que les erreurs qu'on lui a envoyées. Coupable : le développeur ?

Le développeur vérifie la seconde partie, assez semblable à la première. Là, il doit se rendre à l'évidence, les données populant le champ « id_web » sont… bien celles des numéros de commande !!! Sauf que… le développeur a sciemment mis ces données là-dedans, il a fait une requête SQL vers la base pour sortir ces données. Là, impossible d'incriminer une erreur d'innatention ou un copier/coller malheureux. Du coup, le développeur a sûrement dû faire quelque chose qu'on lui a demandé. Coupable : le développeur ? Le client ?

Stoppons là l'enquête, même si nous aurions pu la continuer indéfiniment. Je suis sûr que nous serions arrivés avec deux accusés, une poule et un œuf.

En fait, nous avons trouvé le vrai coupable. L'enquêteur.

Il y a sûrement un coupable, une erreur primordiale, toutefois, la chercher indéfiniment peut être une vaste… perte d'énergie, surtout que cette énergie pourrait être consacrée à trouver une solution.

La recherche de l'erreur, c'est humain. La compréhension en est importante, je ne le nie pas. Maintenant, j'ai volontairement simplifié cette histoire, imaginez-là avec 5 intervenants côté « client », et 5 à 6 développeurs qui se sont suivis côté « développeur ». Imaginez également que le système ait été prévu pour fonctionner d'une certaine manière et qu'il ait été détourné de cette manière.

Moi-même, je ne fais pas exception, il m'arrive régulièrement d'être rapidement affirmatif et de dire que l'erreur ne vient pas de moi. Et il m'arrive même d'avoir raison. Toutefois, par simple honnêteté intellectuelle, je reconnais que les torts sont sûrement partagés dans bon nombre de cas. Et encore plus, je constate que passé une certaine quantité d'énergie dépensée à les chercher, cela me fatigue, et surtout, cela ne sert à rien, au mieux à se conforter dans une idée qu'on n'a pas commis d'erreur. Illusoire à partir d'un certain niveau de complexité.

Sur le même sujet, vous pouvez regarder « Le client, ce gentil méchant », une vidéo de Sud Web édition 2013.