Outils collaboratifs : entre syndromes du canard et de Paris

Jamais les applications collaboratives n'ont été aussi prisées en entreprise : wikis, blogs, plates-formes sociales, réseaux sociaux d'entreprise, progiciels de veille, sans parler des applications métiers et sectorielles. Mais en termes d'intégration et d'appropriation, deux syndromes les guettent.

Le premier est celui de Paris, en référence au syndrome touchant une certaine population japonaise qui a développé une vision idéale de Paris, jusqu’à ce qu’elle visite la capitale française et se confronte à la réalité. Ainsi, dans une majorité d’organisations, le rêve du bouton magique et de l’application mobilisatrice des équipes existe encore.

Des illusions encouragées par des discours marketing  « trop roses » bien loin des préoccupations opérationnelles des managers et collaborateurs. Il est   tout à fait logique que, dans certains contextes, le syndrome de Paris se reproduise, en générant des réactions plus ou moins virulentes ou radicales. Le décalage entre la promesse client et les résultats obtenus peut être très important.

La déception peut s’expliquer par trois facteurs. Le premier est lié à une approche de mise en œuvre purement technico-fonctionnelle, s’attardant uniquement sur les fonctionnalités présentes ou à développer dans la future application. Et qui néglige le lien avec les métiers et les objectifs opérationnels et stratégiques de l’entreprise.

Deuxième facteur, le fait de ne pas impliquer les usagers dès l’amont. Pour une participation viable et plurielle, il est important de les inviter à co-concevoir le dispositif cible. Ils pourront ainsi s’approprier ses tenants et aboutissants, adhérer au projet et se mobiliser pour aller plus loin.

Un troisième élément explicatif de l’échec de la mise en œuvre d’une application collaborative est d’écarter (volontairement ou pas) la réflexion autour des contenus supportés par l’application logicielle d’une part, et l’ensemble des modalités organisationnelles, des responsabilités et compétences nécessaires pour l’appropriation d’autre part. En somme, il s’agit des socles fonctionnels et métiers, considérés généralement de manière partielle, à côté du socle technique.

De l’usage spécifique au volet collaboratif

L’autre syndrome facilement identifiable dans les projets de mise en œuvre d’applications collaboratives est celui du canard. Le canard nage mais pas comme un poisson, il vole mais pas comme un pigeon, il court mais pas comme un lièvre ! Il fait un peu de tout sans pour autant être performant sur une opération particulière.

Il faut savoir que les applications collaboratives sont à l’origine des applications dédiées à un usage spécifique, et dotées de fonctions de collaboration qui se déclinent et se matérialisent par des fonctionnalités de partage de droits, d’accès, de contenus…

Ainsi, chaque application va chercher d’abord à répondre au besoin initial qui est à l’origine de sa conception : surveillance du web, édition de contenu, gestion de projet… Et c’est en fonction de la maturité de la société éditrice, de la vision de ses dirigeants, des caractéristiques de ses clients et de l’évolution du marché que la feuille de route R&D se dessine.

La société éditrice intègre ainsi au fur et à mesure des fonctionnalités nouvelles et développe d’autres fonctions pour améliorer le volet collaboratif et répondre aux besoins du marché. Toutefois, le cœur de métier de l’éditeur, sa courbe d’apprentissage et les économies d’échelle en R&D vont faire qu’il ne peut être performant à tous les niveaux.

Ainsi, sur le marché actuel, même si la majorité des offres logicielles dites collaboratives disposent de moteurs de recherche, il n’est pas évident d’atteindre le même niveau de performance qu’une application dédiée à la recherche. Il en va de même pour les fonctions de traçabilité des modifications et de gestion des versions, ou encore pour celles de partage de contenus.

Il s’agit en effet, pour les porteurs de projet et les collaborateurs impliqués lors de la phase de sélection des éditeurs, de bien positionner l’offre logicielle à sa juste valeur, et de bien décrire sa couverture fonctionnelle.
Nous citons à titre d’exemple l’utilisation des applications gratuites du marché, et la nécessité de jongler entre plusieurs, pour arriver à un dispositif opérationnel. Ce bricolage se justifie entre autres par le fait que les couvertures fonctionnelles n’apportent pas toujours la valeur ajoutée tant attendue.

Aref Jdey est consultant-chercheur chez le spécialiste en système de veille et management de l'information Help Management. Il est l'auteur, avec Florence Gicquel, documentaliste, d'un ouvrage récent : Le projet collaboratif – Pour mobiliser la documentation au service de l'entreprise, aux éditions ADBS.

Promo Newsletter