Le contexte

Dans le cadre de notre intervention en chefferie de projet pour l'un de nos clients, nous avons organisé et suivi une montée de version majeure d'un CRM. Nous avons planifié et conduit les tests afin de sécuriser ce déploiement.

Comme dans tout projet informatique, il est essentiel de situer le contexte dans lequel l'outil est utilisé. Dans notre cas, il s'agissait d'une application CRM asynchrone installée sur une flotte d’ordinateurs portables homogènes et permettant la prise de commandes, leur suivi, ainsi que le suivi client et la facturation.

Cette application est stratégique et génère plus de la moitié du chiffre d'affaires de notre client. Par ailleurs, l’outil est utilisé quotidiennement par plus de 150 commerciaux, répartis sur plusieurs établissements en France, avec des niveaux de compétences en informatique très variés.

Objectifs des tests de recette

L'objectif principal de toute campagne de test est de minimiser les problèmes pouvant survenir en production. Dans notre cas, les principaux enjeux étaient les suivants :

  • Valider les éléments techniques et fonctionnels de la montée de version :
    • La montée de version a nécessité la refonte complète de tous les écrans.
    • La montée de version doit permettre de modifier les formats d'échanges entre le serveur et les postes distants.
    • L’enjeu de la sécurisation de la prise de commande est prioritaire.
    • Il doit être possible de revenir sur l’ancienne version en quelques minutes sans perte de données et avec une procédure très simple (exécution d’un script par le commercial directement).
  • Valider les éléments techniques et le process de la phase de déploiement :
    • La mise à jour de tous les postes est indispensable avant le changement des formats d'échange.
    • Cette mise à jour doit pouvoir s'effectuer à distance, rapidement, avec une connexion téléphonique si nécessaire, permettre un rollback, et garantir l'accessibilité des informations non synchronisées.
    • Les commerciaux doivent pouvoir être migrés en groupe de 10 en 1h maximum.
    • La cible de migration est de 30 commerciaux migrés par semaine sans augmentation majeur des appels au support.

Outils et méthode de recette

Pour mener à bien la recette et suivre nos tests nous avons utilisé l’outil proposé par ProjeQtOr.

Ce dernier permet d’associer un jeu de test à une application et de mener plusieurs campagnes de tests dans le projet, notamment lorsqu’il s’agit de valider une version corrective et de s’assurer qu’il n’y a pas de régression.

Environ 250 cas de tests étaient ainsi planifiés et ont été enrichis durant le projet.

Historiquement ces cas de test avaient été travaillés par écran. Nous les avons complétés avec des cas d’usages et les retours des K-users durant leur phase de test.

Réalisation des tests de recette

Phase 1 - Lot 1 : Tests applicatifs

Les tests applicatifs ont été réalisés à partir d'un cahier de tests contenant environ 180 cas, que nous avons enrichi d'une quarantaine de cas supplémentaires au fur et à mesure des campagnes de tests. Nous avons d'abord testé les cas dits "passants" (actions normales sans erreur de saisie), puis les cas "non passants" qui doivent bloquer les actions, pour chaque écran.

Les résultats ont été communiqués systématiquement à l'éditeur pour corrections et retests des versions livrées. Lorsque les corrections avaient un impact majeur, nous avons repris les tests en rejouant les cas "passants" et "non passants" potentiellement affectés, afin de valider la conformité de l’application aux objectifs fixés.

Phase 1 - Lot 2 : Tests de déploiement

L’enjeu de ce déploiement était de garantir une simplicité d'exécution et de permettre un rollback en quelques minutes si nécessaire.

Pour cela, nous avons collaboré avec l'éditeur pour mettre en place une procédure scriptée assurant un déploiement rapide des éléments techniques. Une phase de tests techniques a été réalisée avec du matériel et des configurations identiques à ceux des commerciaux, en prenant en compte les différents types de connexions. Nous avons documenté et corrigé les cas nécessitant des ajustements, en les intégrant directement dans les scripts ou, si le cas était aléatoire, en prévoyant des actions spécifiques lors du déploiement.

Phase 2 : Tests avec les K-users

Nous avions la chance d’avoir un groupe de 10 K-user éclectique sur l’utilisation des outils informatiques.

Nous avons défini trois groupes de K-users pour tester l'application, chaque groupe étant décalé d'une semaine afin de capitaliser sur les corrections et ajustements nécessaires, et de les valider tant sur le plan du déploiement que des correctifs de l'application.

Les K-users avaient la possibilité de travailler sur le nouvel environnement ainsi que sur l’ancien. Durant cette phase, nous avons porté une attention particulière aux points de risques identifiés (ex. : conformité de la prise de commande entre le CRM et l'ERP). L'objectif était de confronter l'outil à une utilisation réelle et d'identifier d’éventuels freins à son acceptation et déploiement.
Cette phase a été cruciale, permettant de corriger de nombreux points d’ergonomie liés aux nouveaux écrans ou des effets de bord sur le fonctionnement du matériel.

Phase 3 : Post-déploiement

Une période de suivi post-déploiement a été mise en place, incluant :

  • l’envoi de questionnaires pour détecter d'éventuels problèmes de paramétrage des postes
  • une ligne de support directe pour traiter les problématiques rencontrées par les utilisateurs

Conclusion

Ces actions ont permis de résoudre quelques incidents liés au déploiement, souvent dus à une mauvaise exécution de la procédure ou à des configurations spécifiques des postes, ainsi qu’à des besoins d’accessibilité propres aux utilisateurs.
Durant cette phase, moins de 15 retours utilisateurs, - principalement pour des questions d’affichage - ont été enregistrés, signe de l'efficacité du travail de conduite de tests en amont.

Le pôle Organisation de Next Decision est à l'écoute de vos besoins et peut vous accompagner dans la structuration de votre projet, Contactez-nous !