Un excellent exemple de projet applicatif en grande difficulté à cause de problème de qualité et une relation compliquée avec un prestataire.

Une application clé défaillante à chaque nouvelle version

Ce projet en crise est une application clé pour une entreprise accueillant du public. Tous les ans, une nouvelle version est imposée par l’éditeur.

Il y a donc 2 sociétés concernées par le problème : l’entreprise cliente (pour laquelle j’ai travaillé) et l’éditeur

Tous les ans, après le déploiement d’une nouvelle version, l’entreprise utilisatrice (cliente) traverse une crise de 2 à 4 semaines avec ces nouvelles versions qui sont de très mauvaises qualités.

D’un point de vue opérationnel, la crise est grave. Pendant ces quelques semaines, cela génère un haut niveau de stress chez les employés et des insatisfactions majeures chez les clients finaux (de la société utilisatrice).

L’outil étant instable voir hors service, chacun fait comme il peut pour survivre en contournant les problèmes voir en traitent manuellement ce qui ne peut pas être fait dans l’outil.

Du côté de l’informatique, le chef de projet n’arrive pas à s’en sortir avec le prestataire et le support interne passe son temps à courir pour mettre des pansements comme ils peuvent.

Bref, c’est la cata ! Ils décident donc de me staffer sur le projet en complément du chef de projet actuel.

Le diagnostic

Me voici débarqué dans la société utilisatrice pour les aider. J’arrive juste avant la crise habituelle. Le niveau d’anxiété dans cette société est énorme à ce sujet.

Point positif : le problème est clairement identifié, il y a un défaut de qualité.

Nous avons creusé un peu plus loin pour arriver à l’analyse suivante.

Le défaut de qualité est du :

  • à un défaut de qualification (test) chez l’éditeur
  • un manque de recette du côté la société utilisatrice (contrôle de la livraison)
  • l’adoption d’une version « jeune » ou « non éprouvée » chez le client qui en a l’utilisation la plus avancée

Comment sortir de la crise

Dans ce cas, il s’agissait plus d’éviter la crise à venir.

La résolution s’est déroulée en 3 phases.

 👉  Etape 1 : en urgence, faire une recette exhaustive dans la société utilisatrice

Le bon sens aurait voulu qu’on demande au prestataire de revoir la qualité. Mais pour tout un tas de bonnes et mauvaises raisons, ce n’était pas la solution la plus facile à mettre en place à court terme.

La société utilisatrice, qui m’a sollicité, a accepté de faire des recettes dans les règles de l’art :

  • Mise en place d’un cahier de recette exhaustif
  • Recette de toutes les fonctionnalités par des vrais utilisateurs
  • Mise en place de 2 itérations pour éviter les bugs de régression
  • Tests de montée en charge

Le travail a été énorme. Mais, bien coordonné et avec une charge bien répartie, le travail a pu être fait en 1 mois.

Pour la première fois et grâce à ce plan d’action, pas de crise au passage de cette nouvelle version.

Une première victoire, mais ce n’est pas la seule bataille à mener.

 👉  Etape 2 : une meilleure qualification chez l’éditeur

Cette étape a pris un peu de temps, mais l’éditeur a fini par accepter de revoir son organisation et de mettre en place un service de qualification (recette).

Cela a permis une amélioration de la qualité de leur produit mais aussi une diminution de la charge de travail du côté de la société utilisatrice (recette plus simple).

 👉  Etape 3 : stabiliser la version chez les clients les plus simples

La société utilisatrice en question, fait partie des plus gros clients de l’éditeur. La base de données est énorme, l’utilisation est forte et complexe.

Par conséquent, le bon sens veut qu’on commence par déployer les clients les plus simples.

Après de longues négociations et une meilleure anticipation, tout le monde a compris que l’intérêt général était de déployer en premier des petits clients ayant une utilisation simple et non risquée.

Et une fois cette phase « pilote » faite, le plus gros client ne serait déployé qu’avec une version stabilisée depuis plusieurs mois grâce aux autres clients.

Le plus dur a donc été de changer les mentalités. Maintenant la situation est stabilisée. Les étapes 2 et 3 ont permis une diminution de la charge de travail globale et il n’y a plus de problèmes majeurs.

Le projet est sauvé et la situation redevenue sereine !!

Quelles dépenses pour quel retour sur investissement ?

🔵 Cout de ma prestation : environ 21 k€ de prestation en redressement de projet

🔵 Valeur ajoutée par le sauvetage de projet : je vous calculerai bien un ROI mais dans ce contexte ce calcul est complexe. Quelle est la valeur d’une crise évitée ? La valeur des clients finaux satisfaits ? Quel est le cout du stress sur les équipes et ma démission de certains membres de l’équipe ?

Aller, je vais me risquer à un calcul approximatif. Prenons le postulat qu’un client satisfait reviendra dans la plupart des cas alors qu’un client insatisfait est perdu.

Un client dépense environ 60 euros par visite. Combien de clients satisfaits faut-il pour amortir le coût de mon intervention ?

👉 👉 21 000 / 60 = 350 clients , donc à partir du 351e client, l’intervention est « rentable ».

Sachant que ce site accueil entre 10 000 et 15 000 visiteurs par jour en moyenne…