Il y a un type de client que tout prestataire de service finit par rencontrer. Pas un mauvais payeur, pas quelqu'un de malhonnête. Quelqu'un dont les attentes, les habitudes de travail et la façon de communiquer sont fondamentalement incompatibles avec les vôtres, et que vous n'avez pas su détecter à temps. On a rencontré le nôtre en mars.
La demande est arrivée par email. Projet de Signal de Vente pour une boutique en ligne de produits artisanaux. Brief court mais précis : déclenchement de notifications sur les paniers abandonnés avec un score d'intention. Budget dans nos fourchettes, délai raisonnable, interlocuteur qui semblait avoir compris ce qu'on faisait. On a dit oui.
Comment ça a commencé à déraper
La livraison initiale s'est bien passée. Le système fonctionnait, les tests montraient les bons comportements, la documentation était complète. On a envoyé un email récapitulatif avec les accès et les instructions. Deux jours plus tard, le premier retour est arrivé.
Le système "ne ressemblait pas à ce qui avait été décrit". On a relu le brief ensemble. Le système correspondait exactement à ce qui avait été décrit. On a corrigé malgré tout quelques formulations dans les emails de notification parce que les retours semblaient de bonne foi, et qu'on voulait satisfaire le client. C'est là qu'on a fait l'erreur de base.
En disant oui à la première demande hors-scope, on a établi un précédent. Chaque correction en appelait une autre. Le seuil de déclenchement était "trop sensible". Puis "pas assez sensible". L'email de notification était "trop long". Puis "trop court, on n'a plus les infos". On a passé trois semaines à modifier un système qui avait pris trois jours à construire. Chaque modification était suivie d'un nouveau "ah, et tant qu'on y est".
Le problème central n'était pas la mauvaise volonté du client. C'était l'absence de cadre. Ni lui ni nous n'avions défini ce que signifiait "terminé". On avait livré une pièce finie selon notre définition. Lui en avait une autre. Et comme on n'avait rien couché sur papier, les deux définitions s'étaient heurtées indéfiniment.
Ce qu'on a changé, concrètement
Depuis cette collaboration, trois choses ont changé dans notre façon de travailler. Pas des principes vagues. Des procédures précises.
La première : tout projet, même simple, commence par un brief écrit, validé par les deux parties avant qu'on touche au code. Ce document liste ce que le système fera, dans quelles conditions, et explicitement ce qu'il ne fera pas. "Le système ne gère pas les retours produits" est une phrase utile à écrire avant de commencer. Elle ne semble pas nécessaire jusqu'au moment où quelqu'un vous demande pourquoi les retours produits ne sont pas gérés.
La deuxième : le scope est le scope. Quand une demande de modification dépasse ce qui a été convenu, on le dit, on chiffre, et on laisse le client décider. On ne dit plus oui par défaut pour éviter un inconfort dans l'échange. Cet inconfort-là coûte moins cher que trois semaines de dérive.
La troisième, c'est celle qu'on a tardé à accepter : certains signaux d'alerte sont présents dès le premier email, et on a tendance à les ignorer parce qu'on veut croire que ça va bien se passer. Le client qui n'a pas de réponse précise à "quel problème quotidien ce système va-t-il résoudre" n'est généralement pas prêt. Celui dont chaque question génère trois nouvelles questions n'a pas fini de clarifier son besoin. Repousser le démarrage d'un projet pour clarifier ces points n'est pas de la bureaucratie. C'est de la maintenance préventive.
On n'a pas de rancœur vis-à-vis de ce client. La collaboration s'est terminée sans éclat, avec un remboursement partiel que les deux parties ont accepté. Mais on a appris quelque chose que deux ans de lecture sur la gestion de projet n'avaient pas réussi à nous enseigner aussi solidement : la douleur d'une mauvaise collaboration est un meilleur professeur que le meilleur des articles de blog sur le sujet.
Y compris celui-ci.