Tout est parti de ce billet provocateur de Michael Idinopulos. Son message est relativement simple, clair, compréhensible. Partant du principe que l’entreprise 2.0 repose sur des intéractions en réseau, que les dites intéractions nécessitent une masse critique non seulement en raison de la Loi de Metcalf mais aussi parce que par définition on ne sait au départ de qui on aura besoin à un moment donné, il en conclut que dans une perspective entreprise 2.0 les habituels pilotes mis en place par les entreprises n’ont aucun sens et ne permettent pas de démontrer quoi que ce soit.

Une prise de position qui a entrainé nombre de réactions sans qu’aucune solution tranchée n’émerge vraiment (voir les réactions au post de Steven Walling ainsi que les résultats de son sondage). Au final il semble que bien qu’une phase d’apprentissage, de découverte, soit nécessaire, les avis diffèrent quant à ses modalités. Ou, dit autrement, tout le monde est à peu près d’accord mais on diverge sur les points de détail voire sur la manière dont on formule les choses.

Qu’est ce qu’un pilote ?

Qu’est ce qu’un pilote ? C’est un projet permettant de tester sans trop de risque et sur un périmètre restreint les points clé de quelque chose qu’on désire mettre en application de manière plus large dans le futur. Ou, plutôt, c’est la manière dont on a généralisé le contenu d’un pilote. Si, on se concentre sur l’objectif il s’agit d’apprendre à valider quelque chose de nouveau, apprendre à le maitriser, en appréhender les risques et les limites. Dans le contexte de beaucoup de choses qui se sont faites par le passé, la définition donnée un peu plus haut est totalement pertinente par rapport au but car, au final, la seule chose qui différencie le pilote du projet final est le dimensionnement, la scalabilité. Dans un système reposant sur la transaction il suffit de vérifier que le processus fonctionne pour 10 personnes, ensuite le faire fonctionner pour 100, 1000 ou 10 000 n’est qu’une question d’infrastructure.

Conversationnel ou transactionnel ? Deux logiques différentes.

Ce qui est nouveau dans le domaine de l’entreprise 2.0 en tant que projet informatique c’est sa dimension humaine, peu transactionnelle, peu prévisible et le fait qu’il repose sur un réseau d’individu. Autrement dit ça n’est pas parce que quelque fonctionne avec 10 personnes que ça fonctionnera avec 1 000. Mais surtout, cas le plus fréquemment rencontré : quelque chose qui ne fonctionne pas avec 10 ou 100 personnes peut parfaitement fonctionner avec 1 000 ou 10 000. Si internet n’avait que 1000 utilisateurs les réseaux sociaux tels qu’on les connait n’existeraient peut être pas, la probabilité pour chacun de trouver son réseau, son audience en phase avec ses problématiques ou envie devenant d’un seul coup très faible.

Il existe également un autre point qui est loin d’être anecdotique : on peut tester une application transactionnelle “à blanc”, en lui injectant des données et voyant ce qu’il en sort. Une application plus “conversationnelle” ne peut être ainsi mise en salle blanche, déconnectée de la réalité opérationnelle. Isolée des préoccupations quotidiennes de manière à ne rien impacter,  elle ne peut donner aucune preuve ni piste quant à son utilité et son efficacité future.

Le but du pilote s’applique donc à l’entreprise 2.0 (tout du moins à sa composante logicielle) mais ses modalités doivent certainement être revues pour rester cohérent avec le but poursuivi dans le contexte spécifique des applications 2.0, notamment ce qui concerne le dimensionnement et le positionnement par rapport aux besoins et objectifs quotidiens des collaborateurs.

Une bonne synthèse de ce que doit être un pilote 2.0 une fois ce contexte pris en compte peut être trouvée dans le commentaire de Claire Flanagan. Un commentaire qui prend d’autant plus de poids lorsqu’on voit les résultats du pilote actuellement mené par la dame.

Un pilote n’est pas un explorateur

Un pilote sert à valider, à affiner la compréhension qu’on a d’une problématique, et à se donner les outils nécessaires pour….piloter le projet une fois qu’il sera généralisé. Dans notre contexte il importe donc qu’il existe une masse critique d’utilisateurs et que le dit pilote ne soit pas confiné en salle blanche et isolé de la réalité du quotidien. En tout état de cause cela impose qu’on ait déjà une idée de ce dont quoi on parle, de ce à quoi ça va servir, des changements préalables au projet et de ceux qui risquent d’en découler.

Lorsqu’on confine un pilote à quelques personnes et qu’on le coupe du monde, c’est souvent qu’on ne sait pas trop ce qu’on va faire, ce que permettent ou non les outils, quel peut être leur apport et leur impact au quotidien, ce qu’ils permettent de changer et le changement préalable nécessaire. C’est une phase de découverte des outils et des concepts sans rien d’opérationnel qui, comme cela a été expliqué plus haut, ne peut rien permettre de prouver. Cela permet, au mieux, de comprendre si tant est qu’on arrive à appréhender l’étendue des possibles avec un périmètre si restreint. Mais dans ce cas il ne s’agit pas d’un pilote mais plutôt d’un explorateur qui a vocation à défricher le terrain. C’est une composante de la nécessaire et trop souvent oubliée (ou expédiée) phase de réflexion stratégique amont mais, au final, en aucun cas un pilote. Et lorsqu’on attend d’un “explorateur” la même chose que d’un pilote on est nécessairement déçu par le résultat final.

S’il importe donc de prendre en compte les spécificités du paradigme 2.0 dans la mise en place de pilotes, il ne faut pas non plus appeler pilote ce qui n’est qu’un élément de la phase d’exploration et de compréhension préalable à celui-ci, qui sert à défricher avant de lancer le pilote, qui permet de comprendre  pour éviter de mal entreprendre.

En attendant vous pouvez également lire ce qu’en pense Steward Mader.