Ce post est adapté de la partie Preuve de concept de mon ouvrage Cloud privé, hybride et public, publié aux éditions ENI et disponible en versions électronique et papier, en cliquant ci-dessous.
La preuve de concept (Proof of Concept en English, PoC) est une étape importante et primordiale de votre cheminement vers la transformation digitale. Attention à ne pas confondre preuve de concept et projet pilote, ce sont deux choses totalement différentes. La preuve de concept est courte et ne doit pas être mise en production. Il ne s’agit que d’une démonstration de faisabilité de la solution auprès d’un groupe restreint d’utilisateurs qui n’a aucun impact sur vos systèmes de production. Si la preuve de concept échoue, il est alors simple et rapide de supprimer le ou les services testés sans que la production soit impactée d’une quelconque façon.
Il y a cependant quatre règles que je conseille de respecter pour une preuve de concept réussie.
Les règles (simples) d’un PoC réussie
- Confiez le projet à un département autre que le service informatique. Comme nous l’avons vu dans les articles précédents, la transformation digitale, c’est d’abord une transformation d’entreprise avant d’être une transformation digitale. Certes, elle est poussée par le numérique et par des outils technologiques. Mais c’est avant tout une expérience utilisateur et client. C’est pourquoi, il convient de mettre la responsabilité de la preuve de concept entre les mains de ceux qui vont être moteur de cette transformation. Cela peut-être le service client, le marketing ou le département commercial. A vous de choisir, mais surtout pas l’informatique. Non pas que ces derniers soient incompétents, mais ils vont accaparer la discussion autour des outils et risquent d’avoir une vue biaisée en raison de leur focalisation technologique.
- Choisissez un groupe de testeurs à l’extérieur du service informatique. Comme pour la direction du projet, les informaticiens ont tendance à se focaliser sur la technicité de la solution, sans en voir les détails de l’expérience utilisateur. Or, c’est cette dernière qui va faire échouer ou réussir le projet. Demander à des utilisateurs « lambda » de faire partie de la preuve de concept apportera la vision nécessaire à son adoption.
- Intégrez la sécurité, en particulier le processus d’identification (et c’est là que l’informatique doit jouer son rôle). Si l’utilisateur doit avoir une autre identité avec identifiant et mot de passe différents de ceux dont il se sert pour l’accès au réseau, vous mettez de côté un point essentiel de l’adoption de la solution. Il est primordial que les annuaires soient synchronisés d’une façon ou d’une autre (celui local et celui dans le cloud), afin d’offrir une homogénéité de l’identification. Il est possible de renforcer l’accès par l’introduction d’une étape d’authentification multifactorielle par exemple. Pas d’ajouter une nouvelle identité numérique !
- Limitez la preuve de concept dans un temps court. Une, voire deux semaines. Les testeurs doivent comprendre que la rapidité des tests est primordiale. Il ne s’agit une fois de plus pas d’un projet pilote susceptible de finir en production. Il s’agit d’un test. Comme quand votre concessionnaire automobile vous propose de tester le véhicule qui a retenu votre attention. Il ne s’agit pas de le garder un mois ! Généralement, vous l’avez pendant vingt-quatre heures. A vous d’en profiter pour tout essayer. C’est pareil avec une PoC. On teste tout rapidement, et on rend ses conclusions.
Et après, on fait quoi ?
Une fois la PoC terminée, désactivez les accès des testeurs. Cela parait une évidence, pourtant c’est rarement fait. Une PoC n’est en effet, une fois de plus, pas destinée à être mise en production. Il n’est donc pas question que les testeurs s’habituent. Ils doivent tester, rendre leur appréciation et faire des suggestions de modification et d’amélioration. Ce sont grâce à ces conclusions qu’il sera possible de définir précisément les contours du service final et d’affiner l’expérience utilisateur.
Une fois cette PoC réussie, place au juridique. Il est en effet crucial de valider la confidentialité des utilisateurs, ainsi que la protection et la sécurité des données et applications. Le département juridique doit alors être partie prenante du choix. Le RGPD impose un certain nombre d’obligations en terme d’information des utilisateurs, il convient alors de les mettre au courant sans prendre de risque légal. Le département juridique sera alors à même de faire ses recommandations et de prendre part aux négociations avec le fournisseur d’accès pour garantir les droits de l’organisation, ainsi qu’avec la direction générale pour mettre en place les éléments nécessaires à la conformité de stockage et de traitement des données.
Le risque de l’échec (temporaire)
Il est possible que la PoC échoue. Les raisons peuvent être nombreuses : échec technique, interface utilisateur trop complexe, fonctionnalités manquantes, etc. Il conviendra alors de la refaire ou d’en redéfinir les contours. Il est absolument hors de question d’envisager la mise en production d’une solution dont ne veulent pas les utilisateurs. C’est le plus sûr chemin vers une réjection et un abandon de la solution à court ou moyen terme. Et s’il s’agit de votre premier projet sur le chemin de la transformation digitale totale, il y a fort à parier que l’outil technologique (cloud, mobile, etc.) sera déclaré comme fautif, même si ce n’est pas le cas. Pour un premier projet, vous ne pouvez pas vous rater, la PoC revêt donc une importance capitale.
Ces étapes franchies avec succès, on peut envisager la mise en production. Pas avant d’avoir revu le plan de transformation digitale complet et d’avoir bien compris comment l’ensemble des acteurs, internes et externes, vont s’approprier ce nouvel outil et comment il s’insère dans le plan global. C’est ce que nous verrons la semaine prochaine.
Crédit Photo Joakim Honkasalo sur Unsplash
