Il y a quelques temps, un ami a vécu une expérience intéressante au sein de sa start-up. Il a vendu une licence à un client, et le retour client n’a pas été très bon. En substance, le client se plaint de la complexité du logiciel et des bugs qu’il rencontre. Ce fut très surprenant, car le même logiciel est par ailleurs utilisé en environnement de production « intensif » par d’autres clients, qui leur sauteraient dessus à la moindre bug; or le front est calme de ce côté-là. La réaction des commerciaux, fort naturelle, fut de demander à l’équipe de développement d’améliorer son processus de test lors de la sortie du produit, et de travailler à une interface plus intuitive, et de demander au support d’améliorer les documentations, la formation, etc. Rien que de très classique me direz-vous. Oui, sauf que ce n’est pas la bonne manière de réagir. La bonne manière consisterait d’abord, comme le suggère Donald Schon dans « The reflective Practitioner » (le praticien réfléchissant, pas disponible en français), à formuler correctement le problème. Seulement lorsque cela est fait peut-on établir un diagnostic. En l’occurrence, une manière plus correcte de formuler le problème n’est pas de dire « Le client se plaint qu’il y ait des bugs et que le logiciel soit compliqué », mais « le client, avec les moyens dont il dispose, trouve difficile l’utilisation du logiciel, et en plus il rencontre des bugs que d’autres clients ne rencontrent pas. » Cette formulation est meilleure car elle fait intervenir la particularité du client dans la réflexion.
Une fois reformulé le problème, l’analyse peut commencer. D’abord, notons le fait qu’il s’agit d’un type nouveau de client. Jusque-là, la start-up avait surtout eu comme clients des ingénieurs qui utilisent l’application en environnement de production de manière routinière. Leur utilisation suit une courbe de distribution normale: ils utilisent le même petit nombre de fonctions 95% du temps. En outre, comme ce sont des ingénieurs, ils connaissent la difficulté de leur domaine d’application. Par conséquent, ils sont très conscients des apports du logiciel par rapport à l’alternative qui consisterait à tout faire « à la main » comme avant. Ils ne le trouvent donc pas complexe parce qu’ils savent que, de toutes façons, la tâche à réaliser est intrinsèquement complexe. Au contraire, ils le trouvent simple, relativement.
Le nouveau client a un profil différent. Il s’agit d’un designer dont les équipes sont moins techniques. Il en estime donc mal la difficulté, et ne comprend pas la complexité du logiciel. Comme en outre le projet n’est pas prioritaire au sein de son entreprise, il ne travaille pas dessus en permanence. En conséquence, il se retrouve régulièrement comme un débutant chaque fois qu’il décide de reprendre le travail, et son utilisation est donc plus erratique, augmentant ainsi la probabilité de sortir des chemins tracés et de trouver un bug.
La première analyse donne donc le résultat suivant: L’environnement de ce type de client n’est pas favorable à une réussite du projet avec le logiciel.
Trop facile me direz-vous. Et les bugs? Pourquoi ne pas corriger les bugs? Après tout, un logiciel peut être difficile à maîtriser si la tâche à accomplir est elle-même difficile, mais ça n’est pas une raison pour avoir des bugs, et ne pas mettre en place un système de production avec une démarche qualité!
Eh bien si, il y en a. Comme partout, chaque décision de gestion a des bénéfices et des coûts. Des tests, la startup en fait déjà beaucoup, mais imaginons qu’elle mette en place une démarche qualité « totale » afin d’être certain que chaque version qui sorte soit exempte de bug. Chaque nouvelle version ferait donc l’objet d’un processus de test, et ne serait sortie qu’après examen complet satisfaisant. La probabilité pour qu’il reste des bugs se rapprocherait de zéro. Oui, mais la vitesse de sortie de nouvelles versions diminuerait
considérablement. En conséquence, la start-up s’adapterait beaucoup plus lentement aux demandes de ses clients. Beaucoup trop lentement en fait
pour que ce soit acceptable. Entre la qualité et la vitesse d’adaptation, il faut choisir. En fait, il faut surtout choisir les clients qui sont conscients de ce choix et les servir en conséquence. Certains clients valorisent la vitesse, d’autres la sécurité, mais on ne peut avoir les deux.
La seconde analyse donne donc le résultat suivant: dès lors que la start-up vend à ses clients sa capacité d’être à la pointe de leurs besoins en temps réel, elle ne peut vendre qu’à des clients qui sont effectivement en évolution forte, et qui acceptent qu’au delà des fonctions qu’ils utilisent, il y ait risque de bug, cela à condition que la startup soit capables de les corriger très rapidement.
La conséquence logique est donc qu’il y a des clients à qui il vaut mieux ne pas vendre, car ils ne valorisent pas le paramètre qui est optimisé par la start-up, à savoir être à la pointe et corriger rapidement.
Ce qui au départ était un problème de qualité et de définition du produit se ramène in fine à une question de segmentation de son marché et de choix de ses types de clients. Pas évident à accepter au premier abord. Cela ne signifie pas
nécessairement qu’il faille abandonner le client, mais qu’il doit au moins être servi différemment. Typiquement, la start-up lui a proposé de réaliser elle-même les étapes initiales de son produit, en attendant que l’importance du projet augmente en interne et que les conditions soient réunies pour un succès. Ce qu’il a accepté avec joie et, je soupçonne, soulagement.