François Nonnenmacher (FR) | EN

Il devait sortir aujourd'hui un article sur les weblogues en entreprise dans le cahier management des Echos pour lequel j'ai été interviewé avec d'autres personnes qui ont travaillé sur le sujet, mais tout ce que je vois, c'est une brève qui mentionne juste mon nom, et un ami me signale que dans la version papier il y a juste ma photo avec une légende laconique. Erreur de mise en page ?

Je n'ai pas lu l'article donc je ne risque pas de vendre la mèche, et tout en ayant une pensée pour Loïc le Meur qui doit se sentir comme un chien dans un jeu de quilles chez les dinosaures gestionnaires de la connaissance — franchement Loïc, quelle idée ! ;-) —, je peux vous livrer quelques bribes de mon expérience récente d'implantation de weblogues en entreprise.

Tout d'abord, je dois vous livrer mon point de vue, en toute mauvaise foi née de l'expérience sur le terrain, du knowledge management (une sorte de gestion des connaissances mais en plus fin). Le KM est un monde plein d'experts qui ont chacun une théorie personnelle sur la gestion des connaissances qui n'a jamais été appliquée avec succès dans la pratique. J'ai pourtant lu quelque part qu'en théorie, il n'y a aucune différence entre la théorie et la pratique. Jusqu'en 2002, le CKO (le gardien en chef de la connaissance) était très copain avec le CIO (le directeur informatique), enfin surtout avec son budget. Le CIO, lui, était copain avec le CKO parce que c'était le seul à bien vouloir lui parler gentiment et à avoir plein d'idées sympa pour dépenser son budget. Ensemble, ils pouvaient mettre en chantier des chantiers pharaoniques se chiffrant en millions et dont on pouvait trop souvent mesurer la déconnection complète de la réalité par l'absence totale de moyens d'en mesurer l'efficacité. Après l'éclatement de la bulle en 2001 et le crash économique subséquent, les mots d'ordre "diminution des coûts" et "externalisation (en Inde)" ont mis un coup d'arrêt à ces pratiques, et je connais plus d'un CEO qui a vu rouge, alors qu'on lui avait vendu une montagne, en découvrant le prix sur l'étiquette de la souris qu'on avait fini par lui présenter.

J'admets que le point de vue précédent est caricatural, cependant il reste représentatif des dérives du KM dans beaucoup de grandes entreprises. Je pense que nous sommes revenus depuis à nettement plus de pragmatisme, encore que pour certains il soit subit par la force des choses (dans le style "c'est ça ou je vous envoie à Mumbai !"). Toute entreprise, quelle que soit sa taille mais qui commence à avoir une histoire, a besoin de gérer ses connaissances sur la durée. Je ne remets donc pas en cause la nécessité d'une gestion des connaissances mais les principaux travers du "KM classique" que j'ai souvent rencontrés dans les grandes entreprises et qui sont, à mon sens :

• le décalage par rapport au terrain -- ces systèmes sont souvent conçus par des comités qui font du patchwork politique puis exécutés par le service informatique qui impose ses choix technologiques, le mix des deux s'apparentant souvent à une créature de Frankenstein n'ayant que peu de chance de refléter la réalité du terrain
• l'excès de centralisation et la pensée unique -- tout doit être stocké sous la même forme dans la même base de données, ce qui n'entre pas dans les cases doit être adapté pour coller au modèle unique
• l'inflexibilité -- assez liée à ou simplement conséquence de la centralisation et de la lourdeur des développements informatiques et du modèle unique. Synonymes : rigidité, lourdeur
• le coût -- très, trop souvent incroyablement élevé. J'ai pu vérifier dans ma vie professionnelle que j'arrivais à en faire dix fois plus avec dix fois moins d'argent que certaines "solutions" dite haut de gamme. S'il n'y avait pas de contrôle financier, les projets KM seraient un bon endroit pour toucher l'infini du doigt !
• l'inertie face au changement -- conséquence de tout ce qui précède, il est souvent très difficile de revenir sur les investissements colossaux déjà engloutis dans les systèmes existants, sans parler de la politique et des luttes de pouvoir en comités. Rares sont les entreprises qui ont le courage, lorsqu'elles peuvent se l'offrir, de faire table rase d'un système qui ne fonctionne pas plutôt que de lui rajouter encore une nième couche
• la dépersonnalisation -- les grandes entreprises ont une peur bleue de la personnalisation de l'information face à la rotation de leur personnel et ont une certaine tendance à "assainir" l'information en lui retirant tout ce qui n'est pas jugé pérenne. Bien souvent, d'ailleurs, les informations sont entrées dans le système non par les opérationnels mais par les "knowledge workers", considérés comme "subject owners" (responsables de domaine) ce qui augmente les problèmes de décalage par rapport au terrain

Comment les weblogues se placent-ils par rapport à ces problèmes ?

• Sur l'aspect décalage par rapport au terrain et la dépersonnalisation, que je préfère regrouper, les weblogues sont écrits à la première personne dans le style de leur auteur (même s'ils peuvent être collectifs) et tranchent ainsi avec l'un des grands dogmes de l'entreprise à savoir la peur de l'expression individuelle. C'est, je crois, le facteur le plus important car celui qui peut vraiment entrer en conflit direct avec la culture de l'entreprise. C'est à mon avis une crainte idiote, symptomatique de cultures trop hiérarchisées et psychorigides qui ont peur du changement et de l'inconnu. Si la culture de l'entreprise favorise l'expression des collaborateurs lors des réunions ou par email, pourquoi n'en serait-il pas de même sur un weblogue ? C'est la première question que je poserais avant de démarrer, la réponse conditionne beaucoup à mon avis le succès et l'amplitude (interne et/ou externe) d'un projet de weblogue d'entreprise
• Sur l'excès de centralisation et la pensée unique, les weblogues sont aux antipodes des systèmes classiques de KM car ils n'imposent de forme que la structure simple du billet, l'auteur pouvant s'exprimer librement sous forme de texte, de HTML, de liens hypertextes et de fichiers. Si l'absence de formalisme peut être un problème dans certaines situations, il en est d'autres où la liberté de pouvoir adapter la forme à chaque message est un atout appréciable. Les weblogues décentralisent aussi quelque peu l'information, en la rattachant à son auteur, cependant rien n'empêche la création d'une ferme de weblogues unique (un serveur qui héberge plusieurs weblogues) qui offre la possibilité de rechercher une information dans tous les weblogues disponibles. La centralisation n'est pas un problème en soi, mais uniquement l'excès (comme en toute chose)
• Sur l'inflexibilité, outre le fait qu'ils n'imposent que le formalisme léger du billet, les weblogues offrent souvent de grandes possibilités de personnalisation que ce soit en matière de structure (par exemple l'archivage par date ou par catégories ou même l'aggrégation de plusieurs weblogues en un site web) ou de présentation (via des gabarits personnalisables) sans qu'il soit nécessaire de faire appel à l'informatique pour cela
• Sur le coût, du gratuit au payant, on est très, très loin des coûts de licences logicielles et de la logistique nécessaire pour faire tourner les poids lourds du KM. Les weblogues ont le bon goût de savoir tourner sur des plateformes web modernes, simples et peu gourmandes. Une ferme correctement conçue devrait offrir la même simplicité d'usage et une gestion quasi automatique sur le modèle des services de blogging en ligne où le quidam peut créer tout seul son weblogue en quelques minutes. Par exemple, je serais plus intéressé par TypePad que par Movable Type pour une grande entreprise, car la gestion des comptes et la création des weblogues peut devenir problématique en volume si ces fonctions ne peuvent être automatisées
• Sur l'inertie face au changement, le caractère chronologique des weblogues les abstrait de facto de ce problème. S'ils sont mis à jour régulièrement, ils doivent naturellement suivre (voire documenter) les changements de l'entreprise

Un autre aspect s'est clairement dégagé pour moi, c'est la simplicité d'emploi perçue par les utilisateurs pour qui j'ai ouvert un weblogue. Tous ont trouvé l'outil (en l'occurrence Movable Type) incomparablement plus simple et intuitif à utiliser que les outils de KM à leur disposition (ici des applications informatiques maisons, Microsoft SharePoint et Lotus Notes). Il ne m'a jamais fallu plus de cinq minutes de formation pour que chaque éditeur soit autonome et commence à publier, ni plus de dix minutes pour ouvrir un nouveau weblogue proprement configuré (une fois la ferme installée, ce qui m'a pris environ une grosse journée). Du jamais vu pour des gens habitués à se faire envoyer sur les roses par l'informatique interne.

Tout n'est pas rose cependant. Les premiers problèmes que j'ai pu constater sont :

• beaucoup ne sont pas du tout habitués à cette nouvelle liberté, l'absence de formalisme est un peu comme le syndrome de la page blanche. C'est souvent une question de confiance en soi ou de culture
• les visiteurs voient en ces weblogues des sites web (ce en quoi ils n'ont pas tort) ou des forums (ce en quoi ils se trompent un peu et ça donne des résultats un peu étonnants dans les commentaires)
• le compagnon indispensable qu'est le fil de nouvelles (RSS/Atom pour les intimes) est le grand parent pauvre en entreprise à cause de la difficulté d'authentifier les utilisateurs d'aggrégateurs correctement. Tant que ce problème ne sera pas pris en compte plus sérieusement par les éditeurs, les weblogues n'offriront pas tout leur potentiel sur l'intranet des entreprises. La solution temporaire est d'envoyer des notifications par email (mais on ne touche que les abonnés, qu'il faut gérer), de rerouter les fils par email ou de mettre en place un aggrégateur en ligne sur l'intranet, mais ni l'un ni l'autre n'offrent le confort d'un aggrégateur sous forme d'application
• la gestion des pings et des TrackBacks (liens croisés automatisés entre sites) est un vrai problème, avec le danger d'envoyer des informations privées vers des sites externes (il convient de proprement sécuriser un weblogue interne et d'éviter qu'il n'envoie des "pings" à l'extérieur)

A la tête que font les gourous du KM à qui je les ai montré, je pense n'avoir encore qu'effleuré le potentiel des weblogues en entreprise, leurs avantages et leurs inconvénients. Il serait dangereux de croire qu'ils sont la panacée face à un KM déficient ou encore qu'ils pourraient tout remplacer. Tout aussi illusoire, à mon avis, serait de croire qu'ils ne sont qu'une mode passagère de jeunes en mal d'expression et qu'ils n'offrent aucun intérêt pour une entreprise. Ils restent pour l'instant l'apanage des early adopters, ces agents du changement qui peuvent préfigurer l'avenir proche et ont le potentiel de devenir un outil standard aussi généralisé que l'email. La grande question, que j'ai déjà eu l'occasion de poser à Six Apart, c'est combien de temps avant que Microsoft n'inclue la fonction weblogue dans SharePoint Server et Office ?

P.S. : Ludo a réagi à mon billet et celui de Loïc. A mon tour d'être perplexe face à sa réaction car mon propos ici n'a jamais été de décrire des scénarios d'utilisation des weblogues en entreprise, et certainement pas d'en dresser une liste exhaustive. Je (re)précise donc qu'il s'agit de premières réflexions nées d'une expérimentation récente et qu'il me faudra explorer un peu plus longtemps avant d'aller plus loin dans l'exercice. Ludo mentionne les wikis, qui peuvent également être utiles et complémentaires. Quant à ma webloggite aiguë, je la soigne, mais ce n'est pas une maladie honteuse ;-).