Le proof of concept pour évaluer un Logiciel

Franck Le Tendre directeur général France et vice-président pour l’Europe de l’Ouest, SynerTrade  

Le processus de sélection d’un éditeur de logiciels est souvent décrit par les chefs de projets ou les analystes comme l’un des exercices les plus difficiles qu’une organisation puisse avoir à appréhender. L’effort de faire venir des éditeurs, de sortir des collaborateurs de leurs tâches quotidiennes, d’écouter des présentations « prêtes à l’emploi », de comparer ses notes et de sélectionner un produit parmi d’autres représente à lui seul un coût si significatif que la conclusion de ce processus peut souvent être le non‐choix.

Essayer en plus d’obtenir l’adhésion des utilisateurs finaux ne fait qu’ajouter au délai, au coût et à l’effort. Il n’est ainsi par rare de voir le coût indirect lié au processus d’évaluation représenter à lui seul jusqu’à 25 % du prix du logiciel considéré. Certaines études indiquent que les entreprises qui s’y prennent mal établissent plus ou moins malgré elles les conditions d’un projet défaillant en créant des prérequis qui ne sont pas bien compris ou mal partagés avant le démarrage du projet, en formant des utilisateurs fi naux sur la base d’une version non définitive du logiciel, en changeant les spécifications métiers pendant les phases de confi guration du logiciel, ou en imposant des méthodologies qui empêchent l’application des bonnes pratiques.

Un « proof of concept », ou POC, doit s’utiliser comme une étape du projet d’implémentation. Il permet au comité d’évaluation de s’épargner les présentations « prêtes à l’emploi » et de se focaliser sur la compréhension réelle des capacités de l’outil et de la société éditrice. Dans le cycle d’achat, l’étape de POC permet à l’entreprise de mieux se focaliser sur les sujets importants, de créer les conditions d’une meilleure adoption par la communauté des utilisateurs, d’initier le changement, d’implémenter les bonnes pratiques et de poser les bases d’un déploiement réussi.

QU’EST-CE QU’UN PROOF OF CONCEPT ?

Un proof of concept est un test d’un logiciel applicatif basé sur la construction d’un prototype architecturé autour de processus métiers documentés. C’est la première étape du processus d’implémentation qui clarifi e les besoins métiers et les attendus en matière de configuration. Le POC requiert de donner accès au logiciel dans l’environnement du client afin de s’assurer de son bon fonctionnement selon la promotion qu’en a fait l’éditeur. Les livrables incluent, en général, un document de cadrage qui détaille les processus métiers et les bonnes pratiques, des tests approfondis sur les capacités du logiciel et de l’éditeur, ainsi que des plans de formation et une communication qui facilitent l’adoption des utilisateurs, et enfin des documents d’architecture (mapping des données, interfaces, règles de conversions, etc.).

QUAND FAUT-IL LANCER UN PROOF OF CONCEPT ?

Du fait du périmètre et de la complexité, le POC intervient plutôt vers la fin du cycle de vente et se prolonge comme le premier jalon du projet d’implémentation. Il en résulte qu’une organisation ne devrait travailler à cette étape qu’avec un seul éditeur, et ce pour une myriade de raisons : les coûts et les efforts importants dédiés à la compréhension des capacités de la solution logicielle, le temps dépensé à recueillir les besoins métiers, la réallocation des ressources humaines, les dépenses de voyages, les efforts pour produire la documentation des processus, la profondeur des tests et le niveau d’implication de l’éditeur…

A contrario, si le POC intervient plus tôt dans le cycle, une entreprise devra réaliser en double la première étape de l’installation et du paramétrage du logiciel. Il en résultera au fi nal que les coûts, les eff orts et l’utilisation des ressources seront décuplés et que cela créera une plus forte probabilité de non-choix. Positionner le proof of concept comme la première étape du projet est une bonne pratique qui implique de devoir finaliser le processus de sélection avec un seul éditeur ; il va sans dire qu’il est dans l’intérêt de l’entreprise de prévenir le deuxième éditeur de la situation dans l’hypothèse où l’éditeur retenu faillirait à bien dérouler le POC. Au final, mettre le proof of concept en première étape du projet permet de comprendre les attentes métier sur une base méthodologique qui donnera le La à une implémentation réussie.

CRÉER UN PROOF OF CONCEPT

Comme indiqué précédemment, un proof of concept est un test d’un applicatif architecturé à partir de documents détaillant les processus métiers. Son planning devrait être correctement établi et proportionnel au planning global du projet. Par exemple, un projet d’implémentation de 8 mois ne devrait pas inclure une phase de POC supérieure à 1,5 ou 2 mois. Comme il s’agit de la première étape de l’implémentation, la première tâche recouvre la rédaction d’un document de cadrage fonctionnel qui inclut la charte et le plan projet, la définition des ateliers de formation, des ateliers de design, un travail sur les données (règles de conversion, interfaces, etc.), et enfin la description des scénarios de tests. Les livrables devront inclure un plan projet détaillé et son RACI, les supports de formation, le document de cadrage fonctionnel et technique, un environnement de développement et de production, une analyse d’écarts, et les scénarios de tests.

Le plan projet est généralement fourni par l’éditeur et conduit par l’organisation. La formation produit permet aux équipes de l’organisation de se familiariser avec le paramétrage du logiciel et évidemment de former les utilisateurs finaux. L’analyse des gaps est généralement conduite à l’issue des sessions de formation et peut à l’occasion découler d’un RFI (Request for Information) ou d’un RFP (Request for Proposal).

Dans la plupart des cas, l’étape de « testing » inclut les phases d’acceptance des utilisateurs ainsi que de la technique ; l’acceptance utilisateur est notamment importante lorsqu’il s’agit d’évaluer des fonctionnalités ou un processus où le résultat devra être binaire (accepté ou rejeté). Par exemple, le produit peut-il analyser des données sur plus de quatre axes analytiques : la réponse ne peutêtre que « oui » ou « non ». Les tests d’acceptance (UAT) sont également utiles pour obtenir l’adhésion des utilisateurs clés, surtout si ces derniers sont influenceurs auprès de leurs pairs. Les stress tests, quant à eux, doivent mesurer les capacités techniques de la solution en matière de temps de réponse et de rapidité des principaux traitements.

En dernier lieu, le POC devra permettre de tester l’éditeur en tant que « partenaire » ; par exemple, a‐t-il des compétences et des experts pour accompagner le changement ? Est-ce qu’il a les facultés de déployer les bonnes pratiques dans l’organisation ? A-t-il l’expérience pour nous assister dans les développements des workflows ? Définir le proof of concept comme une étape de l’implémentation permet de solidifier les besoins métiers à l’heure de configurer le logiciel.

CONDUIRE UN PROOF OF CONCEPT

Le proof of concept se déroule traditionnellement entre les murs du client. Un espace dédié devrait être préparé pour les utilisateurs finaux afin qu’ils puissent se retrouver et dérouler le proof of concept dans les meilleures conditions. Le groupe devrait être constitué d’un mix « d’inter et d’intra » départements : les « inters » sont ces domaines susceptibles d’être aff ectés par la suppression des silos d’information ou par des interfaces ; les « intra‐départements » sont intéressés par l’acceptation des utilisateurs finaux.

Les ressources leur étant aff ectées devraient être bien respectées au sein de cette communauté car leur acceptation du nouveau système est largement corrélée à l’adoption de l’ensemble des utilisateurs fi naux. Selon la nature des engagements contractuels, les responsabilités de l’organisation porteront sur la gestion globale du projet. Cela inclut la gestion du périmètre du POC, son délai et son coût. L’organisation concernée devra également être disponible pour fournir l’ensemble des « inputs » nécessaires à la définition du cadrage, communiquer avec les utilisateurs finaux pour favoriser l’adoption et le bon niveau de motivation, participer activement à la configuration du logiciel, et dérouler les scénarios de tests.

Quant à l’éditeur de logiciel, ses responsabilités incluent la fourniture du document de cadrage, le déploiement des bonnes pratiques, la configuration et le paramétrage du logiciel, la correction des éventuelles anomalies, et la coordination des activités de « testing ».