Je viens juste de terminer une phase de Beta-test pour un logiciel à mon boulot. Cela faisait quasiment 20 ans que je n’avais pas eu à le faire et hasard, c’était pour le logiciel prédécesseur de celui-là. Avec le progrès technique et technologique, on pourrait croire que l’on s’améliore…

Mais il faut que je précise qu’il y a 20 ans, j’étais participant dans l’équipe projet alors qu’aujourd’hui, je ne suis que testeur et utilisateur du produit. J’ai évidemment 20 ans d’expérience dans ce domaine particulier, une déformation à force d’utiliser un logiciel. Avant le beta-test, j’avais aussi participé à des tests sur l’ergonomie des candidats à la succession, des sessions avec des exercices imposés, filmées. Je n’ai pas eu le feedback / retour de ces séances mais j’avais vu que le choix s’était porté sur l’héritier du précédent logiciel, le “moins mauvais” sans doute. J’avais émis des réserves sur certains choix d’interface, de logique mais ça pouvait répondre au besoin. Quelques corrections ont été faites depuis.

Ce qui m’avait paru drôle dans cette affaire c’est qu’il y a 20 ans, tout le monde rejetait le nouveau logiciel et qu’après 15 ans, tout le monde l’aimait… ou presque. On finit par se faire à tout mais pour ma part, je le trouvais archaïque dès le départ avec un look à la Windows 3.11 / Début Windows 95 et on a contourné des difficultés par des configurations et détournements de fonctions. Il en est de même aujourd’hui, sauf que d’un logiciel Windows nous sommes arrivés aujourd’hui à un logiciel “Web” qui s’utilise via un navigateur. Tout le monde est familier maintenant avec cela et la transition se passe plus facilement que du “terminal 3270” à un Windows 32bits. Accessoirement, ça vous donne une idée de la lourdeur d’un changement logiciel dans une grande entreprise et des cycles de renouvellement. Il faut trouver des boites qui peuvent assurer un suivi longue durée, ceci explique aussi les difficultés du logiciel libre dans le domaine. Car pour le coup, c’est bien un domaine absolument pas couvert par la moindre offre de logiciel libre, même balbutiante : Trop technique et pointue pour un débouché rentable. Ce n’est pas un simple SGBD car il y a des spécificités dans la gestion des “calendriers”, les “héritages” entre les différents items, les différentes clés… Je ne vais pas détailler.

Nous avons donc eu une “base test”, c’est à dire une réplication des données existantes à un instant T dans l’ancien vers le nouveau logiciel et une trentaine d’utilisateurs pour tester tout cela. Il y a un serveur test et on estime qu’en charge on ne devrait pas rencontrer trop de connexions simultanées, de par l’expérience de l’usage précédent. Il faut tenir compte de l’effet nouveauté au début, souvent sous-estimé dans les lancements logiciels / sites web. Je n’ai pas eu d’information car je ne traite pas avec ceux qui gèrent les serveurs. Il y a pourtant des phases de sélection où l’on cherche à afficher toutes les valeurs possibles d’un champ et qui rament alors beaucoup trop. Un problème de conception, pas de serveur. Deux modes de remontée d’information / bug ont été utilisés : Un groupe Yammer (le réseau social d’entreprise de Microsoft) et un fichier Excel partagé. J’ai été assez surpris car j’ai vu par ailleurs de nombreuses utilisations de gestionnaires de bugs/remontées client comme Bugzilla, Jira par exemple. Ce choix n’empêche pas forcément que derrière il y ait du Jira dans la gestion côté éditeur du logiciel.

Le problème du Yammer, c’est que parmi les 30 ou 40 utilisateurs, je me suis vite senti seul à tracer, expliquer, commenter. La première semaine, il y a la “joie de la découverte” et les explications du “pourquoi les données ne sont pas reprises”, souvent par des habitudes prises. Et puis ensuite, ça ne teste plus beaucoup, ça n’essaye pas d’utiliser le produit dans la routine d’une vie d’entreprise. Donc il y a moins de remontées, moins d’animation. Même côté équipe projet, il y a toujours des actions de fond mais on communique moins, puisqu’en plus il ne semble pas y avoir grand monde sur le groupe Yammer. J’ai aussi la gestion d’un groupe yammer mais j’ai relâché l’animation car c’est à sens unique. Yammer, ça ne marche pas… Alors que pendant ce temps là, tous les collègues font un tour sur leur page facebook, ou autres forums. Si, les seuls qui fonctionnent dans ma boîte sont ceux où l’on parle de remontées qualité clientèle… pour les produits achetés par les collaborateurs. L’individualisme, une fois de plus, qui tue notre société. Tant que ça ne touche pas notre propre personne, ça ne motive pas d’aller sur Yammer, de diffuser de l’information, des bonnes pratiques.

Il y a juste que moi, je travaille pour 6 utilisateurs du produit dans le service donc je dois m’assurer que ça répond au besoin de chacun. Côté projet, ils sont plus détachés de l’utilisation “site”, avec une stagiaire qui va gérer la vie et le relationnel avec l’éditeur. Je trouve cela problématique car, s’il y a un œil neuf, il n’y a pas la connaissance des contraintes très différentes selon les activités, les sites. Il y a 20 ans, je l’avais découvert pas à pas et notamment en comparant R&D et production, qui n’avaient pas les mêmes besoins. Mais j’avais eu une expérience dans une autre société auparavant. Le lancement produit est fait avec des documents en provenance de l’éditeur, donc génériques mais qui ne répondent pas à “mon” besoin terrain. J’ai donc pris sur moi de tout revoir, en ciblant notre utilisation, en étant surtout moins vague et plus précis dans les exemples pour que l’utilisateur puisse le refaire en production, prendre cela comme base pour construire sa “boite à outils”. Dans les documents d’origine, on insistait sur l’ergonomie, on passait par des QCM, alors que je donne des exemples concrets à reproduire, à chercher, l’ergonomie n’étant pas, pour moi dans ce cas, le coeur du problème. Je dis cela car j’ai tâté le terrain dès le début du béta-test en montrant la bête à mes utilisateurs, en les rassurant. Il y a en effet beaucoup de stress et de nervosité lorsqu’il y a un changement de logiciel, surtout avec des personnes qui ont peur de l’Ordi.

Fractal Dead Tree par Marc Vanlindt

Mais ce qui est (était…) intéressant dans le Yammer, c’était d’avoir les questionnements des autres utilisateurs que soi. On découvre alors des possibilités, des modes de fonctionnement nouveaux qui peuvent parfois servir dans notre activité. Avec une remontée de bug classique, sans partage, l’utilisateur bêta-testeur ne voit pas ce que fait son homologue. J’ai déjà pensé à des évolutions possibles mais chaque chose en son temps. Il faut déjà se donner 6 mois pour retrouver vraiment ses marques, vérifier toute la cohérence des données, envisager des utilisations nouvelles via des fonctions qui n’existaient pas avant. J’ai préféré garder chez moi une extraction quasi complète de mes données anciennes pour pouvoir, le cas échéant, corriger. Car quand il s’agit d’un logiciel de gestion de base de données, comme ici, même spécifique, il y a à travailler sur les transferts de champs. Ici c’est pire que ce que j’ai connu puisque l’on fusionne certaines données existantes dans la version “du commerce” avec nos données. Un contenu de champs peut différer dans l’orthographe (un accent, un tiret, un espace) alors qu’il s’agit bien de la même chose. Quand vous avez X fois 10 000 lignes, il y a intérêt à dispatcher le travail dans un groupe. Il y a 20 ans, je m’étais tapé moi même tous les filtres. Là j’ai proposé de faire ceux que je maîtrisais mais pour le reste, on part dans le flou. Il faut dire que la base test propose un peu plus de fonctions que celles qui seront disponibles, d’autres choix dans les champs que ceux qui seront retenus. Je trouve cela étrange car cela aurait du être tranché avant. Je n’ai pas eu accès au “cahier de recette” qui sert à la réception du produit donc je ne sais pas le niveau de détail retenu. A deux semaines du démarrage en production, il y a du mieux mais encore des bugs bloquants.

Dans le béta-test, il y a différents niveaux d’investissement personnel. J’ai profité d’un creux de charge pour m’en occuper mais le lancement est arrivé dans un pic de charge. D’autant plus que je m’occupe de la formation de “mes” utilisateurs dans le même temps. Généralement, les produits sont lancés et les utilisateurs sont formés après, trop tard, ou sinon trop tôt, sur un produit trop différent de ce qu’il sera en production. Avec une date de lancement qui dérive constamment, on doit s’adapter sans arrêt, en gérant en plus les vacances de chacun. J’ai donc subdiviser cela en 3 petits groupes possibles, bougeant mes sessions et mes élèves de l’une à l’autre selon l’évolution. La première a sauté pour devenir la deuxième etc, etc. J’ai du composer avec les approximations de la base test et en plus, pas moyen d’avoir des comptes utilisateurs “formation” pour faire tous les exercices comme je le veux. J’ai l’avantage d’avoir formé ces utilisateurs il y a 2 ou 3 ans sur le produit précédent, quand j’ai “passé la main” et en dehors de quelques besoins spécifiques, ils ont été rapidement autonomes. Là aussi, l’expérience de 20 ans a servi. La confiance installée aussi mais il ne faut pas que ça dérive dans le “je ne sais pas, tu fais à ma place ? “ Je crains pourtant d’avoir été le seul à procéder comme cela.

Même si tout n’est pas parfait comme je le voudrais pour ce lancement, le niveau atteint est suffisant pour faire vivre le produit. A l’heure où j’écris ces lignes, j’ai encore des bugs importants sur “ma base” mais qui ne sont pas bloquants vis à vis de la production, des normes à respecter, etc… sauf un. Je sens qu’il va falloir apprendre à faire différemment le temps que ces bugs soient soldés. De la même manière, un basculement d’une base à une autre est, comme un déménagement, l’occasion de faire un grand ménage, de se poser de vraies questions sur le besoin de garder ceci ou cela. Surtout que cette fois nous avons une fusion de deux bases différentes. J’avais anticipé quelques mois avant cela en travaillant avec mes interlocuteurs, le projet. Il reste pourtant toujours à reprendre. Les mois d’été où il y a moins de monde et moins de charge sont là aussi pour ce type de tâches.

Se pose alors la question du coût de ce test, puisqu’on nous dit toujours de participer mais jamais en dégageant du temps pour cela par rapport au reste des activités. C’est un peu comme le logiciel libre qui réclame d’un côté des dons et de l’autre côté du temps. Si par le passé, j’ai fait quelques tests de logiciels libres ou pas, c’est que j’avais du temps à y consacrer, que je pouvais me permettre d’accepter des bugs sur ces logiciels en ayant à côté des alternatives aussi. Aujourd’hui, je n’ai plus ce temps, ce n’est plus ma priorité non plus, surtout quand je vois les dérives de certains projets (Firefox et la fondation Mozilla, Debian dans ses dernières versions). Je ne me sens plus en phase avec cela. Dans une activité professionnelle, tu n’as pas ces états d’âme, tu dois faire avec ce que l’on te donne, même si ce n’était pas ton choix. Il y a 20 ans, j’étais pour une autre solution mais j’ai du faire avec une décision politique et commerciale plutôt que technique. J’ai donné de mon temps sur le projet car c’était mon job. Ca ne l’est plus aujourd’hui, le seul étant de former les utilisateurs, d’assurer le fonctionnement normal du service. Malheureusement, tout comme la maintenance et le SAV, le bêta-testing/ déverminage est toujours sous-évalué dans les projets, autant en temps qu’en argent.

Dans le cas présent, le manque d’implication de chacun est un coût. Quand j’entends dire de la part de personne de l’équipe projet que je “m’implique beaucoup”, je ne le prends pas comme un compliment, mais comme une anomalie, car eux, je ne les vois pas beaucoup participer, ou sinon se reposer sur la personne stagiaire/en alternance. Sans doute les outils ne sont pas les plus pertinents pour avoir cette implication mais sur le fond, ça ne changerai pas. Il faut avoir une carotte au bout pour que les gens participent. La date butoir est fixée, sans changement. J’aurai formé tout le monde à cette date pour que ça tourne. J’ai des idées d’automatisations pour simplifier le fonctionnement, parce que j’ai l’expérience de tous les postes de ce “processus” maintenant mais je sais qu’on en a encore pour 3 ans à faire tomber les réticences, à faire bouger un développeur extérieur qui lui aussi à d’autres priorités que notre mode de fonctionnement. Et puis une bonne partie de l’équipe projet est ou sera à la retraite d’ici là, sans même parler d’un tiers de mes utilisateurs. Alors le don de soi risque encore de se transformer en don de moi…

En video :