Test Technique

© Christian PAULUS. Document créé le 1er novembre 1999 , mis à jour le 12 avril 2009.

Un idiot pauvre est un idiot, un idiot riche est un riche. Paul Laffitte

Accueil du site > Etudes > Test Technique

Le test technique est-il une passion à ne pas laisser entre toutes les mains. Juste quelques réflexions sur une profession qui semble merveilleuse à beaucoup, mais qui demande beaucoup de patience et de conviction.

Tester, dans le sens professionnel du terme, est parfois une lourde charge. On parle dans ce texte trop long de validation d’aptitude et/ou technique, dans un réel but de mise en place d’un outil de production.

Réflexion sur le test de solution informatique

Ce texte se veut un guide pour la création ou la gestion de tests de produits informatiques dans une petite ou moyenne entreprise, dont le métier n’est pas la production de services informatiques. Il ne s’adresse pas aux SSII (sociétés de services) ou autres entreprises dont la population est majoritairement composée d’informaticiens. Il ne s’adresse pas non plus aux très grosses entreprises qui auront peut-être intérêt, si ce n’est pas déjà fait, à créer un Département ou un Service Technique ayant pour seule vocation de valider le bon fonctionnement des outils informatiques (sorte de contrôle qualité). Dans ces derniers cas, je conseillerai plutôt la lecture d’ouvrages spécialisés dont on trouvera quelques références en fin de mémo.

Ayant trouvé très peu de documents sur le test informatique en petite et moyenne entreprise, j’ai commencé la rédaction de celui-ci dans un principe ouvert à tous. Il est simplement basé sur une expérience personnelle et professionnelle de plusieurs années. Ce texte devra bien sûr être adapté suivant les besoins.

J’aurai plaisir à lire vos commentaires qui peuvent m’être adressés par courrier électronique. Je ne peux pas prendre l’engagement à maintenir ce document, pour des raisons de temps libre toujours de plus en plus difficile à trouver. Mais dans la mesure du possible, je tiendrai compte des remarques formulées. Ce texte est libre de droit. Vous pouvez le copier, le transformer, l’adapter à votre situation, mais s.v.p., n’oubliez de mentionner son auteur. Merci.

Le test et la validation de solutions informatiques

Présentation du document

Si tu veux que l’on te comprenne, fais-toi comprendre. (proverbe juif).

Ce document ne se veut pas le témoignage de ma situation actuelle, mais bien plus une synthèse d’échange d’idées avec d’autres confrères ou Responsables de grosses entreprises sur le propos du test et de la validation d’outils informatiques, glanées de part et d’autre des rencontres, des colloques et des séminaires. L’outil informatique étant de plus en plus présent, voire indispensable à la production d’une entreprise, réaliser un test et une validation de produit dans le dessein d’améliorer ou de mettre en place un système de production n’est pas une chose à prendre à la légère.

Dans la plupart des petites entreprises, et parfois des grosses, la procédure de test n’existe pas, ou est mal définie. La plupart du temps, parce qu’elle a été mise en place, ou s’est mise en place, au cours de l’évolution de l’entreprise sans que cette dernière puisse prendre le recul nécessaire à sa bonne organisation.On essaiera ici de redéfinir les objectifs d’un Responsable de test informatique, dont le travail n’est pas de développer le produit à déployer, mais bel est bien de valider le bon fonctionnement d’une nouvelle solution, de la mise à jour d’une solution ou du retrait d’une solution existante. La plupart des opérations de tests seront nommées "étude de faisabilité", car la bonne élaboration d’un test ne permet pas pour autant de passer du jour au lendemain au déploiement grandeur nature. D’autres phases sont nécessaires, nous les découvrirons ci-après. Pour des raisons de clarté, nous identifierons les acteurs, les nécessités du test, puis ses différents composants. Nous parlerons de la validation de production mais aussi du calcul du risque en cas de dysfonctionnement.

Définition des acteurs

Les vieilles églises ont des vitraux sombres. (proverbe allemand).

Dans ce mémo, certains acteurs sont clairement identifiés par l’emploi de la capitale en premier caractère. Ainsi :

  • Testeur, est la personne dont la fonction officielle est de tester, de valider une solution, son fonctionnement, sa documentation.
  • Veilleur, est la personne dont la fonction officielle est de veiller, c’est à dire d’être à l’affût de toutes nouvelles technologies dont l’entreprise peut tirer bénéfice. On parle ici de Veilleur Technologique, même si par moment son travail se rapproche de la veille concurrentielle et de la veille économique.
  • Responsable, est en général le Directeur du département ou du Service qui a en charge les tests de validation. Il arrive parfois que cette cellule soit un Département à part entière, un peu comme le Responsable de la sécurité des systèmes d’information (RSSI), afin de ne pas être juge et partie. Mais si encore pour les RSSI on commence à voir une prise de conscience de la part des Directions Générales sur la nécessité d’une certaine indépendance des Directions des Systèmes d’Information (DSI), on en est encore très loin sur les cellules de validation techniques. Le sujet mérite pourtant quelques réflexions car il est très proche de celui de la sécurité.
  • Directeur, dans ce mémo, il correspond au Directeur Général. Si le Responsable à la responsabilité de son équipe, le Directeur à la responsabilité de la bonne marche de son Entreprise.
  • Demandeur, est la personne qui signifie un besoin. Cela peut être l’utilisateur final, un Responsable technique, le Directeur.

Chacun de ces acteurs aura bien souvent une bonne visibilité sur le travail de son collaborateur le plus proche, mais pour des raisons humaines tout à fait compréhensibles, il aura bien souvent une mauvaise visibilité sur les acteurs trop loin de son cercle de préhension. Mais ceci n’est pas une généralité. Il peut arriver que votre propre responsable ne comprenne rien à votre fonction. Il ne faut pas se formaliser, nous avons là juste un problème de communication.

Le test, pour quoi faire ?

Si vous vous posez la question "pourquoi donc faire un test pour l’installation de tel logiciel dans mon environnement de production ?" avec comme sous-entendu que ce test est inutile, cela veut dire qu’il n’y a aucun risque à l’installation du nouveau produit (ou à sa désinstallation). Si le produit testé ne fonctionne pas correctement, pouvez vous quantifier la perte d’exploitation au temps passé à l’installer et le désinstaller ?

Tester, c’est tout simplement valider une solution. Toutes les solutions installées dans une entreprise doivent être validées. N’acceptez jamais sur votre parc de production, l’installation d’un produit qui n’a pas été correctement testé, qui n’est pas documenté, qui n’est pas maintenu. Ou alors, ne vous prétendez pas responsable.

Mettre en place ou retirer une solution dans un environnement de production, sous-entend que l’entreprise en tire un gain immédiat, dans le meilleur des cas, mais aussi puisse en tirer profit dans des situations plus complexes. Il faudra valider la démarche, sa documentation, dans une utilisation quotidienne mais aussi dans une situation de crise.

Que diriez vous d’un bon produit : une chaloupe capable de transporter un équipage entier, de la côte au bateau, par beau temps ? Vous seriez heureux de savoir que votre équipage peut continuer à produire sur les bords des quais en cas d’avarie de votre bateau. Imaginez maintenant que votre bateau prenne feu, la nuit, par temps d’orage, à mille lieux des côtes. La chaloupe que vous avez choisie ne dépassera pas le kilomètre. La mer engloutira votre équipage, et dans la foulée votre entreprise.

Maintenant, regardez autour de vous. Que peut symboliser le bateau, la chaloupe et l’équipage ? Si vous avez un doute, prenez un morceau de papier et listez les éléments qui composent le bateau, la chaloupe et l’équipage. N’omettez ni l’ampleur du bateau, son chiffre d’affaire, le délais imparti à la livraison des denrées périssables, la composition de l’équipage, en notant ceux qui sont en bonne santé, leur poids respectif qui peut évoluer au fur et à mesure des années, les compétences de chacun qui sont mesurables aisément (historique, capacité, volonté, etc.).

Vous noterez également les éléments matériels nécessaires à la bonne conduite du bateau. Le compas est-il bien réglé ? La carte géographique est elle à jour ? La météo s’annonce bonne ? Avez vous déjà effectué ce voyage ?

Et imaginez le pire. En tant que Responsable, vous êtes un des maillons d’une chaîne à qui il incombe d’assurer le suivi de la production. Vous comprendrez aisément que le test est loin d’être un passe temps à confier à des gens qui sont à mille lieux de comprendre ce qu’est une situation à risque.

Produits concernés par le test

Pour se gratter, il faut des ongles (proverbe turc).

Deux types de produits sont concernés par le test : le produit " prêt à l’emploi " que l’on trouve sur les rayons des grossistes ou les revendeurs informatiques et le produit développé sur cahier des charges, ce dernier étant réalisé par le client ou sous sa maîtrise.

Dans le cas du produit " fourni en l’état ", le test consistera bien souvent à ne valider que le bon fonctionnement de quelques éléments de l’outil aux besoins de la production de l’entreprise. Curieusement, tester ce type de produit demandera parfois plus de temps qu’un produit développé sur Cahier des charges. En effet, lorsqu’on part d’un Cahier des charges, on ne teste pas à l’aveugle. Par contre, pour tester un produit commercial, n’ayant sous la main que la documentation du produit et parfois un numéro de téléphone ou une adresse électronique, il lui faudra user de patience pour valider la solution. Le Testeur devra comparer le produit avec d’autres solutions avant toute action. Il devra lire, ou au moins survoler la documentation du produit, l’installer sur au minimum, deux ordinateurs, l’un représentatif du plus lent disponible sur le parc, l’autre le plus sensible en matière de risque.

Le Testeur ne devra jamais employer son ordinateur personnel à des fins de tests. C ’est son outil de travail qu’il met en péril en cas de dysfonctionnement grave. Et de toutes façons, par expérience, un ordinateur d’informaticien n’est jamais représentatif d’un poste utilisateur final. De plus, les outils étant de plus en plus communiquant, il est largement conseillé de construire un réseau de test séparé, physiquement, du réseau de production.

Objectifs d’un test

Plus on avance dans la forêt, plus le bois est grand. (proverbe russe).

On rencontre plusieurs objectifs pour la même fonction, formulés par plusieurs Demandeurs : Le Veilleur lui-même, qui par goût personnel ou connaissance d’un besoin peu ou mal exprimé, effectue une recherche permanente. On a tendance à appeler ceci de la veille technologique. Elle débouche parfois sur une phase de test pour une validation d’aptitude technique. Bien souvent, le Veilleur passe directement par cette étape lorsqu’il en a le temps, afin de ne pas déclencher inutilement toute une procédure de tests de validation, plus coûteuse et plus contraignante à préparer.

Le Demandeur est l’utilisateur final. Il s’agit donc de valider un besoin réel. Dans ce cas, le Testeur devra s’assurer de la conformité du produit avec les procédures de productions en cours. Si l’entreprise n’a pas clairement défini les procédures de productions, il faudra commencer par la rédaction de ces procédures avant toute action.

Parfois, le Demandeur n’est pas l’utilisateur final (le bénéficiaire). Il s’agit dans bien des cas d’un Demandeur technique, c’est-à-dire d’une demande de la part d’un technicien du département de production, pour par exemple, la mise à jour d’une solution instllée sur un poste utilisateur.

Lorsque le Testeur validera une solution, il le fera en calculant le gain apporté, en évaluant le retour sur investissement, mais devra également calculer le risque encouru par cette installation ou désinstallation. Toute solution a ses avantages, mais aussi ses inconvénients. Si vous rencontrez un Testeur, ou une personne qui prétend en avoir les capacités, vous présenter sa solution à grands coups de " Y’a qu’à ", évitez le, ou reprenez complètement son étude. Vous y trouverez sans peine les failles qui font qu’un test mal mené peut arriver à facilement multiplier par 100 les coûts financiers d’un déploiement mal préparé.

A éviter aussi le " ca ne coûte rien, allons y ". Rien ne coûte rien. Le pas cher à un coût caché, le coûteux aussi. Dans tous les cas, il faudra un Testeur ayant une certaine expérience, connaissant bien les procédures à employer afin d’éviter au maximum l’erreur, une bonne connaissance du produit ou du principe du produit, et aussi une bonne connaissance du métier de l’entreprise dans laquelle il travaille. La connaissance des processus en place dans l’entreprise sera un plus indéniable, car il saura utiliser les " circuits non-officiels " lui permettant de réduire les coûts de la validation technique, du déploiement ou autre formation. Que le Directeur ne s’offusque pas d’une telle réflexion, l’être humain est ainsi. Peu communiquent, principalement par frustration, au delà de leur sphère la plus proche. C’est là un détail bien connus des Ressources humaines dont j’aurai plaisir à discuter dans un autre mémo.

Lorsque vous avez affaire à un projet lourd, par son implémentation ou son impact sur la population, n’hésitez pas à demander de l’aide et à quémander la création d’un Comité de pilotage. D’ailleurs, si vous regardez bien les choses en face, ce comité existe déjà autour de vous, ce sont les gens qui vous jugent ou vous conseillent. Nommer un comité de pilotage de tests revient à officialiser la situation et permet d’organiser les réunions nécessaires à l’élimination des sous-entendus, des incompris, qui font que la solution étudiée aura toutes les chances d’aboutir à son terme, ou l’inverse, grâce à la participation de tous.

Si les tests à réaliser sont trop compliqués, s’ils nécessitent des compétences que vous n’avez pas, n’ayez pas honte à sous-traiter en faisant appel à des ressources externes à l’entreprise. Ne comptez pas trop sur les ressources internes, ce serait sous-entendre qu’elles sont disponibles pour des études dont le planning est bien souvent aléatoire. Ce serait là une grande erreur.

En effet, s ’il est une chose importante dans les tests de validation, le planning est la chose la plus délicate à régler. Si vous vous donnez un planning élastique, c’est qu’il n’y a pas d’urgence en la matière. Vous pouvez abandonner la recherche. De nos jours, la durée de vie d’un ordinateur au catalogue constructeur est de l’ordre du trimestre. En matière de logiciels, il n’est pas rare de voir défiler les versions et sous-versions mensuellement. Dans la mesure du possible, lorsqu’une demande de validation est formulée, arrêtez vous à la dernière version du logiciel et fixez vous une date de remise de votre rapport, la plus courte possible. Ne changez pas de version au cours de votre validation, sauf si bien sûr vous rencontrez un problème important. Il ne faut pas changer pour le plaisir de changer, ou alors, annulez toutes vos vacances et préparez vous à passer vos week-end au bureau. A priori, votre patron n’y verra pas d’inconvénient, mais commencera à se poser des sérieuses questions sur vos capacités d’analyse et d’organisation.

Deux cas basés sur l’impact apporté par la solution envisagée :

  • Impact lourd, transversal. Il ne s‘agit pas forcément d’un coût financier élevé, mais de la population ciblée,
  • Impact léger, ce qui sous entend une faible population.

Dans chacun des cas, nous pouvons segmenter sans peine en deux sous ensembles :

  • Impact fort sur la maintenance et l’exploitation de la solution par une population de techniciens,
  • Impact léger sur l’organisation de travail des services techniques, la solution envisagée ne demandant qu’une bonne collaboration des utilisateurs.

Le rapport de tests devra préciser l’impact de l’installation afin de permettre au Directeur de bien appréhender dès le début du déploiement le coût financier associé. Si vous vous en sentez le courage, essayez d’évaluer le coût d’un déploiement. Mais ne vous vous attachez pas trop à l’argent. Comptez plutôt en jours/homme. Votre Directeur, en bon financier, saura faire le calcul pour vous, bien plus rapidement et justement que vous ne pourriez le faire. C’est normal, c’est son travail.

Infogérance : sous traiter le test

Parfois pour des raisons de mode, ou parce qu’il a lu un article dans son quotidien favori, le Directeur décidera d’employer un conseil extérieur pour sa veille technologique et ses tests de validation d’aptitude technique.

Pourquoi une telle décision, au détriment de désir d’accomplissement de ses équipes internes ? Tout simplement par manque de maîtrise du sujet. On peut difficilement lui en vouloir.

Nous prendrons en compte également les effectifs de plus en plus réduits de techniciens dans les entreprises. Soit par manque de ressources humaines appropriées, soit dans un soucis d’économie, le Responsable qui court comme les autres après la technologie perdue aura du mal à expliquer à son Directeur que c’est un mal nécessaire, que ca se passe comme ca un peu partout chez les autres. Il tombera dans un " y’a qu’à " qui résultera à la hauteur de la confiance que le Directeur donne à son Responsable. Un peu du style : " je n’y comprends plus rien, visiblement vous non plus, mais allez-y quand même ".

Si le Responsable informatique a du mal à s’en sortir dans cette situation, il choisira la solution attendue du Directeur. Il peut arriver que ce dernier, toujours pour des raisons " nous ne maîtrisons pas ce sujet, confions le à une entreprise qui saura le faire pour nous " arrive à vous faire avaler la pilule. En réalité, il faudra comprendre ici " je ne comprends pas ce que vous faites, je souhaite confier votre travail à quelqu’un d’extérieur qui me l’expliquera correctement ".

On l’aura bien compris, le Veilleur est victime de son succès, à force de prendre les choses à cœur, il aura mis en avant le résultat en oubliant d’en préciser le difficile parcours à celui qui le finance. Bien souvent une simple erreur de communication suite à un comportement ou l’affectif a pris le pas sur le rationnel.

L’infogérance n’a pas que de mauvais côtés. Elle est d’ailleurs bien souvent utilisée, parfois à son insu, par le Veilleur lui-même. En effet, lorsqu’il base une recherche d’une solution sur un comparatif présenté dans un article de presse spécialisé, il utilise parfois, sans le savoir, les résultats d’un cabinet d’études spécialisé.

Mais il faudra se méfier aussi de la décision de sous-traiter systématiquement la recherche de nouvelle solution. Si le Veilleur est un être sensible, il peut mal prendre la chose, un peu du style " mon patron décide de tout passer à l’extérieur, je suis plus compétent que la boîte extérieure, mais comme il ne veut pas le reconnaître, je ne communiquerai plus mon point de vue ". C’est une grave erreur. Si on en arrive à cette situation tendue du " je ne communique pas, donc tu n’existes plus ", le Veilleur ne voit pas qu’en réalité, c’est lui qui n’a pas communiqué dès le début correctement, ou qu’il a perdu le recul nécessaire à la présentation claire de son activité. Ceci est tout autant valable pour une autre profession.

Mais nous nous éloignons du sujet de ce document. Le management est un art encore mal maîtrisé, il suffit de voir les sessions de formations dans les grandes entreprises pour s’en convaincre. Tout le monde y va à tâtons, back-management, étude de Taylor, More, coaching, etc. La gestion du stress et des projets n’a pas encore sa solution, ou en tout cas semble mal maîtrisée par les divers organismes de formation qui s’en sont fait une spécialité. Les mauvaises langues diront que ces entreprises de conseils ont tout intérêt à ne pas communiquer les vraies solutions, car finalement, les formations sont leur gagne-pain.

Ne négligeons pas les bienfaits de l’infogérance. Elle permet au Responsable ou au Directeur d’obtenir le recul nécessaire à une meilleure compréhension du métier de son Testeur, ou de l’équipe de travail, et donc des budgets alloués à de telles opérations. Si le travail de la veille ou de la recherche leur paraît quelque peu obscur, si le Responsable de Veille, pour peu qu’il soit correctement interrogé, n’arrive pas à expliquer correctement le pourquoi du comment de son travail, une Infogérance bien conduite, en général courte, permettra à ce Veilleur de prendre le recul nécessaire à l’analyse des processus de la veille et de la recherche. L’Infogérance peut même être pour le Testeur ou le Veilleur un nouveau challenge, ne serait ce que pour mieux expliciter l’inadaptation de cette décision avec les vrais besoins de l’Entreprise. Il devra redécouvrir l’amont de la réflexion qu’il a bien souvent perdu ou oublié à force de ne voir que la qualité de service à donner au Demandeur, en mettant stupidement de côté le fait que le Financeur de ses opérations n’est autre que son Directeur, et que c’est à lui en premier qu’il doit des explications.

Veille technologique

La première fonction du Veilleur est de veiller, donc de devancer le besoin de son entreprise ou la demande de l’utilisateur. On ne demandera pas au Veilleur de tout connaître, mais il devra au moins savoir où trouver l’information demandée. Le Veilleur passera une grande partie de son temps à s’informer sur les nouvelles solutions liées aux outils utilisés dans son entreprise. Connaissant bien le métier de cette entreprise, il pourra aisément en identifier les besoins éventuels, mais aussi les acteurs qui pourront lui assurer la réussite de son projet.

Son travail s’apparente parfois à la veille économique, car en découvrant comment les meilleurs concurrents de son entreprise travaillent, il pourra en étudier les outils employés et en imaginer l’éventuel bénéfice pour sa propre entreprise.

Pour le moment, il est assez rare de rencontrer un tel personnage n’ayant pour fonction que la veille technologique. Des cabinets d’études proposent bien de la veille concurrentielle, mais la veille technologique, lorsqu’elle est intégrée à l’entreprise, demande une connaissance approfondie du métier de cette entreprise. Ceux qui ne sont pas persuadés de la nécessité d’un poste de Veilleur technologique n’ont qu’à regarder autour d’eux. Bien souvent, cette veille est déjà présente dans leur Entreprise. Elle est partagée entre diverses personnes, quelque peu de façon informelle, et donne lieu à des dépenses extraordinaires en photocopies et recherches en parallèle sur le même sujet. Au pire ; certaines personnes, peu ou mal encadrées, n’hésiteront pas à se lancer dans un test de validation, sans procédures de tests ni d’analyse des besoins, et cela en doublon d’un autre collaborateur, ceci sans aucune concertation.

La centralisation de la veille permet de réduire les coûts de cette dispersion d’énergie. Mais bien malin celui qui arrivera à quantifier avec précision le coût de cette dispersion. La veille fait - idéologiquement - partie intégrante des souhaits de bons nombres de techniciens informatiques. Il est rare en effet qu’une personne ne choisisse cette branche technologique pour obtenir un boulot tranquille, sans évolution. L’informatique vit un rythme effréné de découvertes de nouvelles technologies, qui touche non seulement l’Inventeur, le Chercheur, le Responsable, et ce, chaque jour un peu plus fort et un peu plus vite. La biologie ne devrait pas tarder à venir rejoindre cette tornade de complications, c’est d’ailleurs le cas dans certains ministères et entreprises de pointe. Ceci pour dire qu’à première vue, il n’y a aucune raison que les besoins d’adaptation prennent un rythme plus calme, plus serein. Plus humain en somme.

Le Responsable de la veille pourra habilement utiliser les ressources internes à ses recherches et tests de validation d’aptitudes. Il optera ainsi pour un rôle de guide. Il en est ainsi pour des projets nécessitant des compétences que le Veilleur n’a pas forcément eut le temps d’acquérir.

Son travail lui permettra de piloter la validation d’une solution en compagnie d’acteurs plus compétents, mais aussi plus à même de l’accepter, de l’adopter. Ceci ne pourra être pleinement réalisé que dans les entreprises ayant une culture, ou désireuses d’avoir une culture, d’organisations transversales. Mais ce n’est pas gagné pour tout le monde. Bon nombre d’entreprises sont divisées en Départements, qui eux-mêmes sont divisés en Services. Divisé est un mot à prendre ici dans le sens littéral.

L’âge moyen des Managers, parfois l’historique de ce Manager dans l’Entreprise, sera souvent un indicateur d’adaptation à l’organisation transversale. Les systèmes comptables sont eux-mêmes peu ou mal adaptés à la facturation entre Services, la plupart du temps par manque d’outils. Il en résulte des effets papillon sur les budgets financiers, et l’on comprendra que certains Managers acceptent mal d’imputer leur budget d’opération qui bénéficie en réalité à d’autres Départements. Et l’on notera les situations conflictuelles entre les Départements dits de " service " et ceux qui sont dits de " production ". Beaucoup oubliant l’intérêt de l’Entreprise, prenant à cœur leur Département comme une entité jugée à part entière et autonome. Une filiale en quelque sorte.

Coût d’une validation technique

Ce n’est pas le puits qui est trop profond, mais c’est la corde qui est trop courte. (proverbe chinois).

Si nous suivons de près les différentes étapes de la validation technique, son coût est loin d’être négligeable. Nous ne parlerons pas dans ce paragraphe du coût " matériel ", le prix de la licence d’exploitation du logiciel, mais bel et bien du coût humain de la validation.

Le coût d’une validation technique sera difficilement quantifiable avec précision, pour diverses raisons. Essayons d’en établir la liste par un exemple, en se basant sur la recherche d’une nouvelle solution pour un département de production :

M. Durand passe plusieurs heures par jour à numériser des documents papier en utilisant un scanneur de bureau, appareil directement relié à son ordinateur. Cette numérisation lui prend un temps considérable depuis des années et M. Durand a de plus en plus de mal a en voir le bénéfice pour son équipe. M. Durand lit parfois la presse spécialisée du monde informatique. Il y découvre un article passionnant sur la gestion documentaire au sein d’une grande entreprise. L’article parle d’une solution révolutionnaire de numérisation automatique et de reconnaissance optique de caractères. M. Durand y voit immédiatement un intérêt pour son travail quotidien, et calcule rapidement le gain de temps dans son classement de documents ainsi que pour la recherche d’anciens documents. De plus, M. Durand pense à tous ces autres documents qu’il n’a pas le temps de numériser chaque jour, et qu’il pourra grâce à cette solution miracle, mettre à la disposition de ses collaborateurs. Nous avons là affaire à un homme qui a un extrême soucis de la qualité. D’un geste alerte, il arrache le combiné téléphonique, contacte le service informatique en charge de valider et d’installer les produits de production, et demande à ce qu’on installe au plus vite la solution aperçue dans l’article parcouru.

M. Durand a juste oublié un détail de poids : si son Entreprise a un département de validation technique, ce n’est pas par plaisir, mais par intérêt économique. En effet, ce département a été créé il y a quelques années suite à de nombreux problèmes de production rencontrés par l’utilisation anarchique de solutions hétéroclites donnant de bons résultats, mais finissant par démontrer une usine à gaz dont la maintenance devenait chaque jour plus coûteuse, voire délicate - pour ne pas dire impossible - pour l’ensemble du parc informatique.

Ce département prendra en compte la demande de M.Durand, en commençant par le début, c’est-à-dire en définissant clairement les besoins. Devons nous installer une nouvelle solution pour faire plaisir à M. Durand, passionnés de nouvelles technologies, ou parce que la solution actuelle est peu satisfaisante ? Cette nouvelle solution permet-elle un réel gain, et ce gain est il nécessaire ? Est-il source de profit ? L’installation de cette nouvelle solution est elle simple ? Apporte t’elle un plus par rapport à l’installation de l’ancienne solution ? Cette solution ne remet pas en cause le schéma directeur de l’entreprise ? Son disfonctionnement remet-il en cause la production finale de l’entreprise ? Le département de validation technique devra étudier chacun de ces points avec vigilance.

Validation d’aptitude technique

La validation d’aptitude technique doit être détachée des problèmes financiers. Savoir si un produit est apte a telle tâche ne doit pas freiner son installation par un quelconque " de toutes façons, on ne l’utilisera jamais, ca coûte trop cher ". La question réelle doit être " est-ce que ca rapporte quelque chose, et si oui combien ? ".

Cette validation d’aptitude technique peut très bien être sous-traitée. Il est même largement conseillé de le faire. En effet, cela nécessite bien souvent une installation complète d’un poste existant, conforme avec la configuration utilisée dans l’Entreprise. Cela prend du temps, au coût d’une installation, sur un agenda d’un Veilleur bien souvent surchargé. Il est en général plus économique de faire installer le poste de test par un installateur externe. De plus, cette installation permettra un contrôle qualité sur les procédures d’installation, contrôle qui est bien souvent oublié dans les procédures d’installation, principalement suite aux évolutions technologiques remettant en cause ces dites procédures plusieurs fois par an.

Par expérience, la mise en place de procédures automatisées, telle que la télédistribution de logiciels sur les postes clients, ne résout pas pleinement les problèmes de non homogénéisation de parc informatique. Ces solutions de centralisation des licences et autres télémaintenance apportent un plus indéniable, mais il en est comme de toutes bonnes solutions, elles s’avèrent difficile à maintenir tout au long de leur vie. C’est un passage obligé, mais vous n’aurez pas pour autant une solution fiable à 100 %, il faut en être conscient. Je parle ici bien sûr de la gestion de parc hétérogènes. Il n’en est pas de même sur un système centralisé, client serveur, permettant l’uniformisation des solutions, mais somme toute mal adaptée à une Entreprise qui n’est déjà pas homogène dans ces propres systèmes de production, et ceci pour des raisons économiques ou concurrentielles tout à fait compréhensibles. Ceci est le cas typique par exemple, des Entreprises qui pratiquent plusieurs métiers, ou plusieurs variantes d’un métier.

Recette technique

Une recette technique est tout à fait comparable à une recette de cuisine. On y établit la liste des ingrédients, en précisant pour chacun d’eux un ingrédient de remplacement en cas de rupture de stock. On y indiquera les éléments devant être préparé la veille (disque dur à formater, préréglage de moniteur). Puis étape par étape, on indiquera la préparation de la solution.

Le style de rédaction de cette recette doit être simple. Cette recette n’est pas là pour expliquer tel ou tel protocole utilisé sur le réseau par exemple, mais elle doit indiquer sa présence indispensable. On pourra expliquer le pourquoi de la présence de ce protocole, à condition que cette explication tienne en quelques mots. Il est important de préciser en quelques lignes, en début de document, à quelle population s’adresse ce document. S’il s’agit par exemple d’une installation d’un serveur de fichiers, il faudra préciser le pré-requis à la bonne démarche de l’installation.

Une recette n’est pas un document de formation. Si vous ne savez pas faire la différence entre un oignon et une gousse d’ail, une préformation est sans aucun doute nécessaire avant d’attaquer la cuisine d’un bon petit plat.

Réception de la solution

La réception est l’étape finale d’une validation. Elle signifie que le Demandeur réceptionne la solution proposée, mais aussi par la même occasion, accepte les composants de l’étude, soit l’analyse des besoins, la procédure de test qui lui a été présentée, les composants documentaires lui assurant la possibilité de distribuer le savoir à ses propres collaborateurs, donc l’autonomie – le suivi – de la solution.

Le document de réception présentera :

  • Le rappel des besoins exprimés,
  • L’étude des solutions envisagées,
  • La ou les procédures de tests de validation,
  • Le calendrier des tests effectués, l’éventuelle participation des utilisateurs à ces tests,
  • Les avantages, les inconvénients, si possible en en chiffrant les coûts,
  • Le témoignage des utilisateurs à la présentation de la solution,
  • Le calendrier de la période pilote, les étapes de formations,
  • Le calendrier de déploiement envisagé.

Formation, un acte indispensable

On plie une jeune branche, mais pas un vieil arbre. (proverbe flamand).

La formation a un double intérêt :

  • Former, tout simplement, l’utilisateur à la nouvelle solution apportée, afin qu’il puisse utiliser le nouvel outil efficacement dans son environnement de production,
  • Engager l’utilisateur dans la bonne détermination à obtenir de la nouvelle solution le meilleur résultat possible. Il est important que la nouvelle procédure de production soit acceptée. Si vous vous êtes trompé dans la mise en production du nouvel outil, c’est l’utilisateur seul qui pourra vous le dire. Il est impensable de compter sur votre propre intelligence, orgueilleusement, pour suivre la vie et la survie de la solution que vous avez contribué à installer. Cette solution a été choisie non pas par vous seul, mais par vous et les divers membres des équipes qui vous ont accompagnées à trouver cette solution. La seule personne capable de vous tenir au courant de la survie de la solution, ou de son malaise, est simplement l’utilisateur de tous les jours. Il vous faudra donc lier avec lui un tissu de confiance. Vous avez tenu compte de sa demande, et avez passé du temps à lui trouver la meilleure solution possible. Il en tiendra compte. Une fois de plus, il est important d’user de diplomatie. L’utilisateur ne voit que son environnement de travail. Il est à mille lieux de comprendre les problèmes techniques. Ce n’est pas de sa responsabilité, il n’a pas été embauché pour cela. Mais il saura tenir compte des problèmes, des contraintes, à condition de lui faire savoir, sans trop tomber dans la technique, ces divers points.

N’oubliez pas aussi que la formation " one-shot " est ridicule. Pour la plupart des solutions en tous cas. Il vous faudra en effet effectuer une " piqûre de rappel ", au minimum une fois par an. Cette piqûre peut être effectuée par vous même ou déléguée à un responsable de formation, voire un responsable technique plus proche de l’utilisateur final. Cette dernière option est à préférer aux précédentes. En effet, l’exploitation d’un produit est une chose, la validation une autre. Et bien souvent, on préfèrera utiliser vos talents de Veilleur à la recherche et validation de solution, et déléguer la formation à des gens reconnus pour la qualité de leur contact avec l’utilisateur.

Le coût de la formation peut être aisément évalué en comptant le nombre d’écrans et d’options de menu indispensables à l’utilisation de l’outil, et en multipliant le tout par un coefficient temps, par exemple 3 minutes. L’expérience permettra là, suivant l’entreprise et le métier de l’entreprise, de mieux calculer ce coefficient.

Ceci dit, ne vous attendez pas à pouvoir effectuer des formations de moins d’une heure, quelque soit l’outil. Les utilisateurs sont en général curieux de nature. Ile ne manqueront pas à vous poser des questions sortant du cadre que vous vous êtes fixé. Prévoyez large, pas forcément pour cette formation, mais donnez à l’utilisateur les moyens d’obtenir les réponses, pas forcément en passant par vous. Sous-traiter cette formation est une bonne solution pour cadrer au mieux le temps nécessaire. De plus, spécialisé dans le test, la formation n’est peut-être pas votre métier. La population ciblée par cette formation vous échappera, au risque de tuer, tout simplement, votre solution. Un formateur professionnel assurera la réussite de cette mission, vous permettant de vous consacrer à l’étude d’autres solutions. Et en cette période de révolution technologique permanente, il devient impossible d’être en même temps à la foire et au moulin.

Documentation utilisateur

Il est plus aisé de bâtir des cheminées que d’en tenir une chaude. (proverbe français).

Ne négligez pas la documentation destinée à l’utilisateur. Elle est de loin l’élément qui assurera la réussite de la solution, c’est à dire sa continuité.

Cette documentation doit être courte, proprement illustrée et simple d’accès.

Composée au maximum d’une quinzaine de pages, elle emploiera des phrases de moins de 75 mots simples, eux-mêmes composés de moins de 3 syllabes. Il est conseillé de ne pas employer de termes abscons, trop techniques, ou anglophones, à moins qu’il soit largement connus et usités par la plus grande masse.

La construction de leçons " étape par étape " est conseillée. 5 étapes au maximum devraient être suffisantes pour bien faire passer votre message. Dans votre rédaction évitez les négations. Pas de " impossible de faire cela " ou de " ne surtout pas faire ceci ". Il faut être constructif dans tous les termes employés.

Le plus simple est de bien identifier ce que l’utilisateur va vouloir utiliser du logiciel à 90 % des cas, et de bien s’attacher à n’illustrer que ces 90 % indispensables (qui bien souvent ne se trouve être que 20 % des possibilités du logiciel). N’essayez pas d’en faire trop, mais essayez plutôt de préparer une documentation qui pourra satisfaire la majorité, pas l’ensemble de la population.

Beaucoup diront que ce choix est stupide, mais à vouloir trop en faire, on devient rapidement repoussant. Si vous faites une documentation de 500 pages sur un outil qui ne servira, somme toute, à l’utilisateur, qu’à envoyer du courrier électronique, il sera inquiet par l’épaisseur de votre prose, et comprendra par sa richesse que l’utilisation du produit que vous lui conseillez est trop compliqué, qu’il n’aura pas le temps de lire 500 pages pour pouvoir simplement envoyer quelques mots à ses correspondants.

Les images écrans doivent être travaillées. Il est regrettable de voir des documents de tests, de mode d’emploi, illustrés de copies d’écrans mal préparées, fonds d’écran personnalisés, icônes non 7 standardisées. Si vous avez la chance d’avoir un environnement utilisateur sous la main, utilisez cet environnement pour faire vos copies d’écran plutôt que votre environnement personnel, bien souvent loin de la réalité d’un poste de production.

Petit détail : pour présenter certains exemples de comptes utilisateurs, n’utilisez surtout pas des comptes existants (nom d’un de vos collaborateurs par exemple). Non seulement cela peut-être mal interprété par la personne dont vous empruntez le nom, mais peut vous mettre dans une situation délicate plus tard, en cas de départ de la personne par exemple. Utilisez plutôt des noms génériques, ou des noms célèbres pour amener un peu d’humour ou rendre sympathiques vos exemples.

Dernier conseil ; il faut faire attention à la présentation des éléments sensibles, tels que les mots de passe. Si dans un document, vous citez un exemple de connexion à une session machine, en citant explicitement le mot de passe " toto ", soyez sûr que bon nombre d’utilisateurs choisira ce mot comme mot de passe pour leur compte. Préférez ici à, soit ne pas citer clairement le mot de passe, soit à faire référence à une règle de création de mot de passe existante dans l’entreprise.

Documentation technique

Il ne faut pas confondre la documentation d’administration à la documentation d’exploitation. Cette documentation d’administration sera rarement lue, car finalement utile que dans les installations et désinstallations du produit. Réaliser un tel document demande plusieurs heures, voire plusieurs jours ou semaines, pour seulement quelques minutes d’utilisation.

La majorité des produits, commerciaux ou non, ont bien souvent la chance d’être accompagnés d’un bonne, voire très bonne, documentation d’administration. De l’installation du produit à son réglage du plus délicat, tout y est référencé. Si ce n’est pas le cas, laissez tomber ce produit et tournez vous vers un produit concurrent bien documenté. De nos jours, ca ne manque pas.

Si par malchance vous devez impérativement installer un produit peu ou mal documenté, préparez le terrain en demandant à votre patron une rallonge de budget conséquente. Et n’hésitez pas à sous traiter la réalisation de ce document auprès d’un spécialiste chevronné.

La documentation d’exploitation permet d’exploiter le produit, c’est à dire de le faire vivre. Il en est ainsi pour la gestion des comptes et des mots de passe par exemple. Elle doit être courte et cohérente. Inspirez vous du paragraphe 13 pour sa réalisation.

Gestion commerciale

Ouvrir son cœur à l’ambition, c’est le fermer au repos. ((proverbe italien).

L’identification financière fait partie de la validation technique. On devra faire attention à bon nombre de détails avant de se lancer dans une quelconque installation. Avant tout, la lecture des documents liés à au produit concerné est indispensable. Plusieurs produits sont soumis à des accords tacites, d’autres explicites, entre le créateur du produit et son utilisateur. L’utilisateur étant pour vous une personne morale, il vous appartient de prendre toutes les dispositions possibles pour ne pas mettre votre entreprise dans une mauvaise position.

Par exemple, beaucoup de gens pense que l’utilisation de logiciels dits " shareware " ou " partagiciels " sont libres de droits d’utilisation, et qu’aucun contribution financière doit être envoyée à leurs auteurs. Il n’en est rien. Vous devez lire les documents liés à ces applications et en suivre les recommandations et accords de licence. Parfois également, les obligations portent sur l’utilisation du logiciel, mais aussi de la donnée utilisée (cas par exemple d’un logiciel permettant un accès à une base d’information internationale). Non seulement vous devrez vous renseigner sur les conditions d’utilisation du logiciel, mais aussi des données fournies par la base. Méfiez vous, beaucoup se font piéger ici.

Dans tous les cas, n’oubliez pas que pour l’installation d’une solution dans un département, la chose n’est pas toujours facile, mais plus difficile encore est de retirer une solution qui donne entière satisfaction à des centaines d’utilisateurs.

La mise à jour d’un logiciel est aussi parfois une chose compliquée, techniquement et commercialement. Entendons par là qu’une nouvelle version, même si elle corrige un grave bogue (bug) de la version actuelle d’un logiciel, n’en est pas pour autant gratuite. Il vous faudra obtenir l’accord du développeur ou de l’éditeur. Le suivi d’une solution passe aussi par un grand nombre de rapports écrits envoyés à tous les acteurs. C’est grâce à ces rapports que vous assoirez votre réputation, mais aussi que vous pourrez obtenir plus facilement un " geste commercial " de la part de l’éditeur. On parle ici de partenariat plus que de la simple relation du client face à son fournisseur.

Pour la gestion des licences, mais aussi des divers historiques sur l’évolution de la solution installée, je ne saurai que trop conseiller l’utilisation d’une base de données. Cette base peut être plus ou moins évoluée, suivant la complexité des solutions gérées , mais il est conseillé une base ouverte, ou un serveur WEB par exemple, mettant à la disposition de tous le résultat de vos recherches. Dans le cas d’un suivi des opérations par un serveur de NEWS (NNTP) ou par mail, le Veilleur/Testeur devra consolider les éléments acquis et en proposer une synthèse. C’est un travail de longue haleine indispensable en cas de conflit ou problème technique. On vous reprochera toujours de ne pas avoir donné l’information au bon moment, mais on ne pourra pas vous faire le reproche de ne pas avoir fait d’effort pour communiquer.

Références

Pardon à ceux que j’ai pu oublier. N’hésitez pas à m’envoyer un message à ce propos.

Les quelques ouvrages que j’ai pu lire et qui ont pu me donner d’en enrichir ce mémo sont, hormis les articles de presse :

- Test logiciel, de Maurice Ozenberg, Editions Eyrolles, ISBN ; 2-212-0900-1. On trouvera également de nombreux liens sur http://www.eyrolles.com/livres/rozenberg
- La veille technologique, concurrentielle et commerciale, de Bruno Martinet et Jean-Michel Ribault, ed. Organisation

Plussoyez !

Les forums sont fermés.