Une version déployée n'est pas une version livrée

Une date annoncée, un périmètre qui ne couvre que le code

Un responsable technique annonce une date de livraison pour une nouvelle version logicielle. Dans sa tête, et souvent dans celle de toute l'équipe, cette date correspond au moment où le code sera déployé en production. Rien dans cette date ne garantit que les scénarios de test ont été rejoués, que la note de version a été écrite, que le client a été prévenu de ce qui change, ou que quelqu'un lui a montré la fonctionnalité en fonctionnement. Le code peut être parfaitement opérationnel en production et rester, du point de vue du client, invisible, mal compris, ou tout simplement jamais utilisé.

Ce décalage ne se voit pas tout de suite. Il se voit un mois plus tard, quand un client demande une fonctionnalité qui existe déjà depuis trois semaines, parce que personne ne la lui a présentée, ou quand un bug signalé s'avère être un comportement volontaire que personne n'a documenté nulle part. Le travail technique était bon. Ce qui manquait ne se trouve pas dans le code, il se trouve dans tout ce qui entoure sa mise en production.

Pourquoi « fini » se réduit si souvent au code

La définition de « fini » qu'une équipe technique porte naturellement s'arrête là où son propre travail s'arrête, c'est-à-dire au moment où le code compile, passe en revue, et tourne sans erreur visible. Ce réflexe n'est pas un manque de rigueur, c'est une conséquence directe de la manière dont le travail est découpé : un développeur maîtrise son code, ses tests unitaires, son déploiement. Il ne maîtrise pas, et souvent ne voit même pas, le moment où un utilisateur découvre le changement, ni la question qu'il se pose en le découvrant.

Le symptôme : « ça tourne » contre « le client sait s'en servir »

Un développeur qui vient de finir une fonctionnalité a toutes les raisons de la considérer comme aboutie : il l'a testée lui-même, elle répond au cahier des charges, elle ne plante pas. Ce qu'il ne peut pas voir de l'intérieur, c'est l'écart entre une interface qui fonctionne et une interface qu'un utilisateur comprend du premier coup. Repérer cet écart est rarement le travail du développeur, c'est celui de quelqu'un qui anticipe ce qui va manquer à quelqu'un qui découvre la fonctionnalité pour la première fois, sans le contexte de celui qui l'a construite.

Ce réflexe n'épargne pas les changements invisibles à l'écran. Une évolution purement interne, par exemple une nouvelle règle de calcul dans un moteur de facturation qui ne change rien à l'interface, a besoin exactement de la même discipline que si elle changeait un bouton : les équipes support et commerciales qui répondent au client doivent savoir que la règle a changé, sinon elles continuent d'expliquer l'ancien comportement à un client qui observe le nouveau, sans que ni l'un ni l'autre ne comprenne d'où vient l'écart.

Déployé, pas livré : le principe

Chez Leando, nous appelons ce principe déployé, pas livré : une version déployée en production n'est considérée comme livrée que si les tests sont validés, la documentation à jour, le client prévenu, et la fonctionnalité montrée en fonctionnement, pas seulement expliquée. Ces quatre éléments ne sont pas des formalités annexes qu'on ajoute si le temps le permet, ils font partie de la définition même du travail terminé. Une version dont le code tourne mais dont personne n'a vérifié les scénarios de test, écrit la note de version, ou prévenu le client reste, par définition, une version à moitié livrée, quel que soit le niveau de qualité du code sous-jacent.

« C'est toujours valeur créée, valeur délivrée, valeur perçue. »

Ces trois mots désignent trois états différents, et la distance entre le premier et le dernier est exactement ce que ce principe cherche à réduire. Une fonctionnalité peut créer de la valeur techniquement, être déployée, sans jamais être perçue comme telle par la personne censée en bénéficier, si personne ne fait le dernier geste qui relie les deux.

Quatre éléments, pas une case à cocher

Rejouer les scénarios de test avant la bascule, et pas seulement les tests unitaires automatisés, signifie reproduire le parcours complet qu'un utilisateur suivrait, avec ses données réelles : une commande avec une remise, un client avec une adresse de facturation différente de l'adresse de livraison, les cas qui s'écartent du chemin le plus simple. La documentation à jour ne signifie pas un wiki exhaustif, quelques lignes dans la note de version suffisent si elles répondent à une question précise : qu'est-ce qui se comporte différemment depuis aujourd'hui. Prévenir le client ne veut pas dire noyer sa boîte mail de notifications techniques, une phrase ciblée vers la personne concernée suffit la plupart du temps. La démonstration, enfin, se distingue des trois autres : elle seule montre le comportement plutôt que de le décrire, et c'est elle qui disparaît en premier sous pression de calendrier, alors qu'elle coûte rarement plus de dix minutes.

Ce que ça change concrètement sur une livraison

En pratique, ce principe change l'ordre des opérations plus qu'il n'ajoute du travail : les tests, la note de version et la démonstration existent déjà dans la plupart des équipes, mais après coup, une fois qu'un utilisateur a buté sur le problème qu'ils auraient permis d'éviter. Rejouer les scénarios de test avant la bascule plutôt qu'après le premier signalement coûte le même temps, sans l'incident ni la perte de confiance qui l'accompagnent. Écrire une note de version de quelques lignes avant d'annoncer que « c'est prêt » prend dix minutes, et évite les trois échanges qui suivent généralement une découverte silencieuse en production.

Le même renversement s'applique à la relation avec le client. Un client qui découvre un changement par lui-même, sans avoir été prévenu, se demande d'abord si quelque chose s'est cassé, avant même de se demander si quelque chose s'est amélioré. Ce premier réflexe de méfiance coûte plus cher à dissiper qu'un message de quelques lignes envoyé la veille n'aurait coûté à écrire. La confiance accordée à un prestataire se construit largement sur ce type de détail répété, pas seulement sur la qualité du code qu'il livre.

La démonstration mérite une attention particulière, parce qu'elle est le geste le plus souvent sacrifié sous pression de calendrier. Une fonctionnalité expliquée par écrit et une fonctionnalité montrée en train de fonctionner ne produisent pas le même niveau de compréhension chez celui qui la reçoit : la première suppose que le lecteur reconstruit mentalement l'usage, la seconde le lui montre directement. Sur un outil métier conçu pour des utilisateurs qui ne l'ont pas demandé dans ces termes, cette différence détermine souvent si la fonctionnalité sera réellement utilisée dans les semaines qui suivent, ou si elle restera ignorée jusqu'à ce qu'un besoin urgent la fasse redécouvrir par hasard.

Cette discipline rejoint une autre méthode que nous détaillons par ailleurs : stabiliser un outil métier sans ralentir la livraison. Les deux partagent le même constat de départ : une équipe technique compétente peut produire un travail de bonne qualité et laisser, malgré tout, un écart durable entre ce qui a été construit et ce que le client en perçoit réellement.

Ce que ce principe exclut

Ce principe ne demande pas de transformer chaque mise à jour en cérémonie, et il ne se confond pas avec la documentation technique d'un projet. Un correctif invisible pour l'utilisateur, une optimisation de requête ou une mise à jour de dépendance sans effet perceptible, n'a besoin ni de note de version, ni de démonstration. Il s'applique aux changements qui modifient ce que l'utilisateur voit, fait, ou attend du système, pas à l'intégralité du flux de déploiement technique.

Il se distingue aussi de la documentation qui explique pourquoi un système a été construit ainsi, destinée au prestataire ou à l'équipe qui reprendra le projet dans un an. Ce principe porte sur chaque livraison individuelle et sur ce qu'un client en perçoit tout de suite, pas sur l'architecture globale du système. Les deux se complètent, elles ne se substituent pas l'une à l'autre.

La taille de l'équipe change la forme que prend ce principe, pas son existence. Sur une équipe de deux ou trois personnes, la démonstration se fait en direct entre collègues avant l'annonce au client, sans cérémonie particulière. Sur une équipe plus grande, répartie entre plusieurs fonctions, elle prend la forme d'un enregistrement court partagé une fois, consultable par quiconque en a besoin plus tard. Dans les deux cas, le critère reste le même : quelqu'un qui n'a pas touché au code doit pouvoir dire ce qui a changé, sans avoir à le découvrir seul en explorant l'interface.

Le test à faire sur votre prochaine mise en production

Avant votre prochaine bascule qui change quelque chose de visible pour un utilisateur, posez une question simple à l'équipe : si on devait décrire en deux phrases ce qui change et pourquoi, le pourrait-on dès maintenant, sans improviser ? Si la réponse demande plus de réflexion que prévu, la version n'est pas encore livrée, même si elle tourne déjà en production. Prenez les dix minutes qu'il faut pour l'écrire avant d'annoncer que c'est prêt, et faites-en l'habitude plutôt que l'exception.