Moi – Hier, j'ai été dans l'impossibilité de me connecter sur un nouveau compte via le back-office. Et en creusant avec un membre de l'équipe technique, on s'est rendu compte que le nom de ce compte avait été modifié : est-ce que cela te dit quelque chose ?

X – Je pense bien que oui : en voulant modifier l'entreprise du contact qui a fait la demande, j'ai probablement modifier le nom du compte à la place.

Moi – Effectivement ça correspond bien à ce qu'on a fait pour corriger : on devait simplement remettre le nom du compte initial pour tout remettre dans l'ordre.

X – D'habitude je modifie uniquement le nom de l'entreprise et là j'ai modifié le nom du compte directement sans faire exprès. Je suis sincèrement désolée. Je vais tenter d'être plus vigilante la prochaine fois.

Moi – Au contraire, je te remercie de nous apporter un problème comme celui-là : il rentre pile-poil dans ton kaizen. Est-ce que tu peux me rappeler son titre d'ailleurs ?

X, interloquée – "Smooth stride". J'y tente d'améliorer la fluidité des process internes. On y a d'ailleurs fait pas mal d'évolution pour que les informations arrivent le plus vite possible à la bonne personne. Surtout quand un prospect crée un compte sur nos outils.

Moi – La fameux pilier du "Just-in-Time". L'autre pilier qu'il ne faut pas négliger c'est le "Jidoka" : s'arrêter quand on a un problème et tenter de le corriger à la racine. Alors est-ce que tu sais pourquoi ce simple changement de nom a posé des problèmes ?

X – Pas vraiment. Je ne me suis même pas rendu compte sur le coup que ça pouvait poser des soucis en cascade.

Moi – En fait le nom du compte est repris dans certains fichiers de configuration : quand le nom change, il faut s'assurer que tous ces fichiers soient mis à jour pour garder la cohérence. Et ce que tu ne sais pas, c'est qu'il y a une option dans les outils accessibles aux développeurs pour faire ce changement. Mais pas dans les outils accessibles à l'équipe qui s'occupent du support client.

X – Et pourquoi alors est-ce comme ça ?

Moi – Parce qu'il y a bien longtemps, un de nos clients a été racheté. Et ils ont voulu changer l'URL de leur compte pour qu'elle reflète leur nouvelle entité. Un commercial de l'équipe a donc eu le même réflexe que toi : changer directement dans l'interface d'administration. Et il a été le premier à créer ce problème.

X – Si seulement je l'avais su : on aurait réussi à s'éviter de répéter l'erreur. Peut-être un point à améliorer pour la formation initiale au sein des équipes commercial et support...

Moi – On pourrait aussi considérer que la solution initiale de l'équipe technique n'était finalement pas terrible : elle n'a pas corrigé le problème à la racine puisque tu as réussi à reproduire le problème, sans même le faire exprès. En plus de produire une façon de répondre au client, elle aurait dû bloquer toute mauvaise modification potentielle. On a encore du boulot sur notre chemin vers les véritables causes racines...

Moi — Est-ce qu'on peut regarder comment tu as corrigé ce ticket ?

X — Facile : dans la version mobile, en bas de la page, il manquait toujours l'historique d'un contact. Et maintenant c'est tout bon : regarde bien, cet historique est bien présent. C'était un problème dans l'API.

Moi — Et peut-on regarder le code qui correspond ?

X — Toujours aussi facile : avec le numéro de ticket, on va vite retrouver le numéro de commit.

X, tapant quelques commandes dans son terminal —Voici le diff avec la version juste avant le commit.

Moi, dubitatif — Et quand tu écoutes ce code, qu'est-ce qu'il te dit ?

X, gêné — Qu'il lui manque son test unitaire.

X — Pourtant on a fait une revue de code avec ma responsable.

Moi — Mais devant moi, tu as directement pointé le problème.

X — Je connais la règle : avec une correction de bug, toujours ajouter un test unitaire. Avec chaque évolution du code en fait, y compris avec une nouvelle fonctionnalité.

Moi — C'est donc que j'ai raté une étape dans la transmission, peut-être avec ta responsable.

X — Ou peut-être qu'on était pressé ce jour-là, je ne m'en souviens plus.

Moi — Reste que le jidoka est un des deux piliers du Lean.

X — Le jido-quoi ?

Moi — C'est le pilier qui préconise de construire la qualité dans le produit, en détectant les anomalies dans le processus.

X — Naïvement, je dirais que c'est précisément ce que nous avons fait en corrigeant le problème, non ? On n'avait pas forcément besoin d'un test test unitaire en plus...

Moi — Sauf qu'en refusant de faire le test unitaire correspondant, tu as bloqué deux choses : d'une part la démonstration que tu avais bien compris la racine du problème (et pas juste les symptômes), et d'autre part la vérification automatique si le problème devait se reproduire plus tard.

X — J'ai quand même une question : est-ce que tu savais qu'il y avait ce problème dans ce commit avant que nous commencions ce gemba ?

Moi — Bien sûr que non, je sais juste d'expérience qu'on finira par trouver un premier problème. Et qu'il mérite toujours qu'on y passe du temps. Les problèmes suivants finiront toujours par remonter un peu plus tard.

X — Alors ce jidoka, recouvre-t-il autre chose que les tests unitaires chez nous ?

Moi — Avec 206864 tests unitaires, c'est sur qu'on ne peut pas les rater : l'effet de masse joue à fond. Mais il y a aussi tous nos tests d'intégrité : est-ce que les fichiers qui doivent être dupliqués sont bien identiques ? est-ce que tous les fichiers de langue contiennent strictement les même chaînes de traduction ?

X — C'est donc pour ça qu'on m'avait demandé un petit script qui puisse identifier les fichiers qui n'ont pas été modifiés depuis 5 années !

Moi — Certainement : ça veut peut-être dire qu'ils sont devenus inutiles. Et dans ce cas, autant les supprimer : c'est toujours ça de surface en moins pour des attaques de cybersécurité.

X — Tu as d'autres exemples ? On ne m'a jamais parlé de ce type de tests dans mon cursus universitaire.

Moi — Voici une anecdote : un client nous appelle parce qu'un champ qu'il a activé sur les utilisateurs n'est pas accessible dans l'export Excel de ces même utilisateurs. On ajoute le champ en question dans l'export Excel, il est content. L'affaire aurait pu en rester là. Sauf qu'on se dit qu'il y a peut-être d'autres champs qui ne sont pas présents dans cet export. On ajoute donc un nouveau test d'intégrité et on découvre qu'il y avait bien 3 autres champs dans le même cas. Personne ne s'était jamais plaint jusqu'à présent. Et désormais si un développeur devait oublier d'ajouter un nouveau champ dans l'export, il recevrait un message d'échec via l'intégration continue. Le processus est devenu beaucoup plus robuste.