Les joueurs

PulchinellaJouer c’est apprendre. L’enfant fait son apprentissage de la vie en jouant. Il fait semblant de se battre, d’être amoureux, de résoudre des problèmes. Pour cela il joue aux cow-boys, à la poupée, aux cubes et maintenant aux jeux vidéo. Le concepteur-réalisateur du système d’information joue aussi, mais celui qui apprend c’est surtout la machine.

Pourquoi jouer ?

Pour les non-initiés, l’activité de programmation est celle qui prend le plus de temps pour développer une application. Nous serions tous à écrire du code, en assembleur, Cobol, en C++, en HTTP…
En réalité, beaucoup de concepteurs-développeurs ne savent pas coder, ou fort mal. De plus les éditeurs proposent aujourd’hui des outils d’aide à la programmation, des progiciels quasiment clés en main, qui réduisent le temps de codage (aujourd’hui fabriquer un site Web simple demande moins d’une demi-journée de travail, même pour quelqu’un qui n’a jamais fait de programmation).
Par contre, tout le monde dans l’univers du système d’information fait des tests.
En quoi consistent les tests ? La personne qui teste prend la place de l’utilisateur final et réalise les gestes à sa place dans le système. Le testeur joue donc avec le programme à la place des utilisateurs (les scénarios appliqués pendant cette phase sont appelés jeux de test). Comme l’enfant devient Luke Skywalker ou Obi-Wan Kenobi avec une épée en plastique, le concepteur-développeur devient comptable, acheteur, vendeur, écrivain…(tous les concepteurs-développeurs rêvent un jour ou l’autre d’être testeur de Super Mario, FIFA 16, ou Assassin’s Creed).
Le test sert à trois choses.
Premièrement, il faut vérifier qu’il n’y a pas d’erreur dans le système d’information ; c’est l’origine de cette activité. S’assurer que ce qui a été fabriqué correspond aux spécifications et qu’il n’y a pas d’anomalie. « Un test est un ensemble de cas à tester (état de l’objet à tester avant exécution du test, actions ou données en entrée, valeurs ou observations attendues, et état de l’objet après exécution), éventuellement accompagné d’une procédure d’exécution (séquence d’actions à exécuter). Il est lié à un objectif. » dit la norme IEEE 829-1998.
Deuxièmement, il faut prendre la place de l’utilisateur, être en empathie avec lui. Le monde du système d’information est obsédé par le «user friendly», la convivialité de l’outil. Il doit être d’usage facile, ne pas obliger à lire des notices en plusieurs volumes, ni à suivre de formations de plusieurs jours. Les couleurs des écrans doivent être agréables, la navigation fluide, les icones explicites. L’utilisateur doit l’utiliser sans fatigue, pendant plusieurs heures voire plusieurs jours. En se fondant dans la personnalité du futur utilisateur, le concepteur-développeur va tenter d’atteindre ce moment où homme et outil numérique ne font qu’un. Moment difficile à atteindre tant les attentes peuvent varier. Entre un utilisateur débutant et un autre chevronné, la perception de la convivialité peut être différente.
Troisièmement, les tests doivent permettre de rechercher les erreurs que l’utilisateur pourrait commettre et qu’il faut éviter à tout prix. Au début de l’informatique, l’écran et le clavier inspiraient la terreur aux utilisateurs. Agrippés au mode d’emploi, n’acceptant de toucher les touches qu’après des jours de formation, ils respectaient scrupuleusement les consignes. Ce temps est révolu. Les utilisateurs ont grandis biberonnés à la Nitendo, ou à la X Box, et l’univers du numérique ne leur fait pas peur. Ils se jettent sur le logiciel comme une horde de gremlins. Ils refusent de lire les manuels, et ont été habitués à ce que les outils numériques fassent plus que ce qui est annoncé (voir Word et Excel, logiciels que tout le monde utilise mais dont presque personne ne maîtrise toutes les fonctionnalités). Face à ces utilisateurs le concepteur-développeur devra multiplier les contrôles, les règles de gestion qui encadrent la saisie.

Qui teste ?

En fait tout le monde teste, le développeur fait des tests unitaires pour vérifier que le système fait les différentes opérations prévues, le concepteur des tests de bout en bout pour s’assurer que l’algorithme complet est conforme aux spécifications, le maître d’ouvrage contrôle par des tests de recette que le système répond au cahier des charges. Il y a aussi les tests d’intégration (vérifier que le nouvel outil s’intègre dans le système préexistant), les tests de masse (vérifier que le système fonctionne même si des centaines de personnes l’utilisent en même temps). Il faut aussi tester que l’ensemble du système (y compris les outils accessoires pilotés par le programme) fonctionne (pensons aux gens qui testent le fonctionnement de la Googlecar). Les cas de tests sont innombrables.
Parfois, il faut automatiser les tests, en particulier pour faire des tests de masse et vérifier la complétude des tests. Enfin dans certain cas désespérés, un pilote permet de faire un test vrai grandeur.
A chacune des étapes du processus de test, il sera possible de trouver des erreurs. Et à chaque fois c’est l’ensemble du cycle qui devra recommencer.
Le test montre la méfiance instinctive du concepteur-développeur pour les capacités de l’homme et de la machine. L’erreur, le bug fait parti du quotidien, et personne ne croit possible de repérer et comprendre la totalité des cas. L’algorithme le plus simple donne lieu à une multitude de situations réelles et le nombre de cas à tester augmente de manière exponentielle. Pour cette raison il est en général impossible de tester la totalité des configurations. La couverture complète étant impossible, la couverture réelle sera fonction de la probabilité des cas de figures, de la gravité du risque que font encourir les erreurs et du budget alloué à la réalisation du programme. Souvent les tests seront une variable d’ajustement. Comme ils arrivent en fin de projet, lorsque la probabilité de dépassement du budget est la plus forte, ils seront sacrifiés sur l’autel de la rentabilité. Pour avoir un outil qui fonctionne correctement, l’utilisateur attendra les patchs et versions correctives qui font le quotidien de la maintenance des outils.

La multiplication du papier

Pour montrer la difficulté à prévoir le comportement de l’utilisateur prenons un exemple simple (authentique !).
Un applicatif permettant de générer des commandes d’achat et de vente a été développé et est en cours de déploiement auprès des utilisateurs. Un assistant de Direction doit passer une commande de papier pour réalimenter les imprimantes et photocopieurs. Il souhaite acheter 20 ramettes de 500 feuilles, soit de quoi remplir une étagère. Méfiant dans sa capacité à utiliser le nouvel applicatif, il décide de commencer par calculer la commande hors système. Il prend le catalogue papier du fournisseur, trouve le produit souhaité et son prix (4€) et calcule le montant à payer. Il fait là une première erreur. Il croit que le prix du catalogue est un prix à la feuille alors qu’il s’agit d’un prix par ramette de 500 feuilles. Au lieu de multiplier par 20, le prix il le multiplie par 10000, soit un montant à payer de 40 000€ au lieu de 80€.
Il décide de saisir ce montant dans le nouvel applicatif. Mais il se trouve face non pas à une zone à remplir mais deux (le prix et la quantité). Ne sachant laquelle choisir, il décide de mettre le montant dans les deux zones et sauvegarde. Le système multiplie la quantité de 40000 par un prix de 40 000€. La commande de 80€ à l’origine atteint la somme de 1 600 000 000€ (un milliard six millions d’euros !). Confiant dans les capacités de son assistant, le manager valide la commande et celle-ci part chez le fournisseur.
Ceci a deux effets.
D’abord, le fournisseur répond à la commande en envoyant un carton contenant une dizaine de ramettes. Il l’accompagne d’une lettre indiquant qu’il s’agit d’un échantillon et demandant confirmation de la commande avec un délai de réalisation pour pouvoir fabriquer le papier et louer les semi-remorques nécessaires au transport.
Ensuite, le contrôleur de gestion de la Direction auquel appartient ce service constate furieux que le budget de plusieurs années a été consommé en une seule commande. Il se tourne vers le service informatique pour demander qu’une telle erreur ne puisse plus se reproduire. Il faut alors chercher quels peuvent être le prix et la quantité maximum à autoriser. A l’issue de cette recherche, un contrôle est mis en place bloquant la saisie au dessus d’un certain nombre.
Quelques années passent. Le service commercial vend une usine clé en main. Le prix à saisir excède le nombre autorisé, et il faut trouver une autre manière de traiter cette opération exceptionnelle.
Dans cette affaire, le concepteur-développeur n’a pas été assez imaginatif lors des tests et n’a pas su se mettre à la place des utilisateurs.

Bibliographie

Robert Reix, Bernard Fallery, Michel Kalika, Frantz Rowe : Système d’information et management des organisations (Magnard-Vuibert-2011)
Nicolas Colin, Henri Verdier : L’âge de la multitude : entreprendre et gouverner après la révolution numérique (Armand Colin 2015)

Cet article, publié dans developpement, informatique, système d'information, est tagué , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s