Des réseaux sociaux en entreprise : pas aujourd'hui

Pierre continue nos réflexions à propos de la bonne utilisation de la messagerie professionnelle et des nouveaux moyens tels que les réseaux sociaux pour faciliter les travaux tout en ne baissant pas la qualité du travail, ne serait-ce que parce que les progrès techniques font que les normes habituelles (les méthodes « qualité » et autres âneries pourtant indispensables) ne sont plus respectées.

Un troisième larron nous rejoint dans cette discussion. Il avait d’ailleurs déjà travaillé sur l’usage des réseaux sociaux en entreprise (dans son domaine, les bibliothèques, si j’ai bien compris).

L’entreprise jugera si elle doit utiliser les réseaux sociaux (blog, compte Twitter, page Facebook, …) pour sa communication, soit avec les clients ou usagers, soit avec le personnel (ou le potentiel personnel…). Ce qui m’intéresse, ici, c’est comment peut une entreprise peut utiliser des réseaux sociaux pour son travail au quotidien, pour permettre une diminution du nombre de mails et un meilleur respect des normes, normes qu’il reste d’ailleurs peut-être à créer ou recréer, tout en améliorant le niveau d’efficacité des salariés.

Il y a des entreprises (dont ATOS, je crois) qui ont tenté l’utilisation des réseaux sociaux pour remplacer le mail mais s’il s’agit uniquement de remplacer un outil par un autre, autant pisser dans un violon. S’il faut écrire sur le mur de 10 personnes : « pouvez-vous me donner vos disponibilité pour telle réunion ? » autant envoyer un mail… (mais c’est vrai que recevoir les réponses de tout le monde quand on est dans une telle boucle est très pénible).

Il faudrait donc définir les besoins. En voilà un : préparer et organiser une réunion ? Je vais en trouver deux ou trois autres pour les intérêts de mon billet. Il y en a des dizaines…

Peu importe les exemples que je cite, ils sont là uniquement pour illustrer le billet.

Besoin 1 : organisation d’une réunion

La plupart des boites ont des agendas partagés qui permettent de consulter les disponibilités de chacun. Il n’empêche qu’il est hors de question que je partage mon agenda avec des inconnus. Il est hors de question que quelqu’un m’impose une réunion sans que je puisse savoir à l’avance de quoi il retourne, si ma présence est indispensable, …

Je « veux » donc pouvoir recevoir une information sur la nature d’une réunion, son urgence,… Je « veux » avoir la possibilité de dialoguer avec l’organisateur. Je « veux » que me soient proposées des dates, que soit vérifié mon agenda, que je puisse indiquer mes préférences, que l’on puisse traiter les priorités entre les réunions (il m’arrive d’en avoir plusieurs en même temps puisque j’ai donné mes disponibilités avant d’avoir les dates définitives, …).

Je vous laisse imaginer ce que l’on pourrait avoir.

Besoin 2 : gérer la documentation

Différents outils existent pour gérer la documentation, son partage, ses versions,… Mais ils semblent conçus par des gens qui vivent dans un monde parallèle.

Par exemple, je rédige des spécifications de logiciels pour les serveurs de mon entreprise. C’est une partie de mon job. Après, je les transmets pour relecture à mes collègues ou à ma hiérarchie. Concrètement, je leur envoie un mail avec le document en pièce jointe (pour leur faciliter le travail) et le lien vers le document sur le réseau si je leur passe la main pour qu’ils fassent des modifications.

A ce stade, on arrive déjà à une impasse qui fait que le meilleur retour que je puisse avoir est une impression du document annoté par les relecteurs. Les meilleurs outils au monde ne permettront jamais de résoudre toutes les problématiques. Par exemple, si un collègue me signale une faute d’orthographe, les autres ne doivent pas le voir pour ne pas me donner la honte, mais moi je dois pouvoir vérifier qu’il s’agit bien d’une faute. Si le collègue formalise une modification de forme importante (ça arrive souvent, les gens se focalisent souvent sur la forme et omettent de s’occuper du fond, ce qui explique pourquoi nos braves entreprises sortent souvent de la merde), je dois pouvoir la refuser sans le vexer (on pourrait faire un billet entier sur la relecture des documents des collègues).

Avec un peu de chance, on arrivera bien à faire un document potable. On devra alors le faire valider par les services utilisateurs ou les clients. A partir de ce moment, il faut user de « méthode » puisqu’on rentre dans le cadre d’un accord contractuel. Le client va lui-même diffuser le document en interne et préparer une fiche quelconque avec une série de remarques. Il va falloir que je lui réponde point par point, soit en modifiant mon document soit en refusant la réponse et en argumentant. Il va donc falloir suivre le niveau de traitement de chacune des remarques du client, avec un tas d’allers-retours pour valider le document.

Il finira par être validé.

A ce stade, il devient un cahier des charges que je vais transmettre à « l’informatique » (soit internet soit externe), mon fournisseur. Il va lui-même faire des remarques qu’il faudra éventuellement soumettre aux utilisateurs, créant ainsi deux dialogues (le fournisseur et moi d’un côté, le client et moi de l’autre), générant des modifications des documents avec des nouvelles phases de validation, de négociation.

J’arrête là mon explication… Mais je vous laisse imaginer la suite avec la négociation du coût de développement avec les deux parties, la spécification du fournisseur, … (un informaticien ira plus loin puisqu’il se dira qu’il faut faire un « cahier de tests » pour ce bazar).

Besoin 3 : la gestion des incidents

Ayant été un peu long à propos du besoin 2, je vais faire plus léger sur le trois. Toujours est-il que, sur nos serveurs, à différents stades (homologation, pilote, recette, …), des incidents sont rencontrés soit par le fournisseur, soit par le client, soit par nous. Des applications existent pour gérer le « cycle de vie de l’incident » (on utilise Redmine) avec la fourniture des logs, la négociation sur la gravité et l’urgence, la livraison d’un correctif dans un lot ultérieur plus important de modification ou en urgence, …

J’ai besoin de cet exemple pour la suite.

Trois besoins identifiés

Chacun pourra imaginer des besoins supplémentaires. J’ai pris ces trois exemples parce qu’ils prennent beaucoup de temps en échanges de mail et ils sont tous les trois « gérables » par des outils de type « réseau social » (différents acteurs identifiés par « cercle » peuvent intervenir sur chaque élément, le but étant de les faire communiquer entre eux).

Pour rebondir sur le dernier, les difficultés sont complexes.

Première difficulté – l’absence de norme

Il y a trois interlocuteurs : l’utilisateur (le client), le fournisseur et nous (l’intégrateur). Chacun des trois va utiliser son propre système de gestion d’incident. On pourrait se mettre d’accord pour utiliser le même mais chacun à plusieurs clients ou plusieurs fournisseurs. Trouver un accord nécessiterait que tout le monde (tous les clampins du monde travaillant dans l’informatique ou à côté) utilise le même.

Pour l’instant, le seul outil commun est le mail… Pourtant, on sent bien qu’un outil de type « réseau social » pourrait être bien utile…

Dans la pratique, les trois entités utilisent leur propre outil et s’échange par mail des tableaux Excel pour faire le suivi, ce qui nécessite de faire le reporting manuellement.

Seules des très grosses entreprises sont susceptibles d’imposer des outils à des clients ou à des fournisseurs… On n’imagine assez mal un fabriquant de boite de vitesses refuser d’utiliser le système informatique du fabriquant de voitures !

Deuxième difficulté – la sécurité

Les informations échangées sont parfois strictement confidentielles pour des raisons de sécurité ou de politique industrielle. Par exemple, notre fournisseur ne voudra pas que l’on sache les anomalies signalées par ses autres clients. L’outil que nous utilisons est donc installé sur nos serveurs, sans accès possible de l’extérieur à part… par l’interface d’un serveur mail…

Malgré la mode du « cloud », aucun patron au monde n’acceptera que les informations quittent le domaine de l’entreprise avec une diffusion totalement maitrisée par des salariés. On pourrait donner un accès externe à nos serveurs mais cela nécessiterait de contourner la politique de sécurité de la boite (en obtenant des dérogations en bon et due forme) ce qui nécessiterait d’énormes travaux de « cloisonnement » de nos serveurs (il faudrait que les serveurs soient connectés à Internet).

Tout est toujours possible techniquement… Mais il resterait à garantir la compatibilité entre nos systèmes et ceux du client et du fournisseur. Vive les normes !

Troisième difficulté – l’apprentissage

Nous disposons de nombreuses applications sur l’Intranet mais, à part l’application pour poser des congés, on oublie toujours comment elles fonctionnent. Entre le serveur de documentation de la boite, celui de chacun des partenaires, celui pour les notes de frais, celui pour le suivi de l’activité, l’intranet de la boite, nos propres serveurs annexes, le serveur du CE, celui pour réserver les numéros d’audios conférence, … il nous faut connaître un tas de trucs ! Rien n’est compliqué mais le cumul fait qu’on oublie systématiquement les modes d’emploi, les mots de passes, …

Quand j’ai commencé à bosser, on avait une secrétaire pour une dizaine ou une vingtaine de bonhomme. Maintenant, on utilise des applications. Je ne suis pas sûr que l’employeur soit réellement gagnant…

Il suffit de voir comment un informaticien « pur » utilise Word pour se rendre compte de la marge qu’il y a pour quelqu’un entre faire son cœur de métier (du développement informatique) et autre chose… Tiens ! Si avec mes deux compères on se sent obligés de donner des conseils d’utilisation de messagerie, c’est bien parce que de nombreux lascars ne savent pas s’en servir.

Il est temps de conclure

Ce billet a dépassé la taille maximale autorisée par le syndicat.

Ainsi, les réseaux sociaux traditionnels n’ont pas vraiment leur place en entreprise, même s’ils peuvent avoir une utilité. De nombreux outils existent. De puis que je bosse, j’ai découvert un tas d’outil de « travail collaboratif » et j’en utilise toujours quelques uns. On peut en inventer d’autres mais ils auraient tous un certain nombre de frein à leur mise en œuvre.

En fait, dans ma carrière, la plupart des outils de type réseau social que j’ai eu l’occasion d’utiliser (sauf ceux extrêmement spécialisés, voire développés spécifiquement pour un usage) se sont traduits par, non seulement un échec, mais aussi une perte financière importante, notamment via le temps passé par les utilisateurs qui finissent toujours par revenir aux bonnes vieilles méthodes : le mail, le stylo et le coup de fil.

Ca ne concerne pas vraiment les réseaux sociaux mais le pire que j’ai vu est un outil qui s’interconnectait avec un outil de gestion de projet (type MS Project) et le système de gestion de l’activité des salariés. C’était grandiose et sur le pied c’était parfait. Il répondait parfaitement aux besoins imaginés par ses concepteurs et le service « méthodes » de l’entreprise l’avait trouvé absolument génial jusqu’à l’acquérir et le rendre obligatoire à toute la Direction Informatique. Il n’avait pas pensé un détail : l’outil ne correspondait pas du tout aux besoins de l’informaticien et du chef de projet… Du coup, on passait un temps monstre à essayer de l’adapter… Jusqu’à ce qu’on gueule très fort et que le chef aille voir la direction.

Les outils de réseau social s’imposeront en entreprise parce qu’ils sont indispensables mais uniquement s’ils s’annoncent incontournables, comme le sont devenus, maintenant, Facebook et Twitter, si on s’intéresse un peu à Internet.

La deuxième condition est qu’ils soient utilisés par tous, du technicien au management. Notre système de gestion d’incidents est très bien pour les ingénieurs mais la direction est incapable de l’utiliser (faute d’avoir l’occasion). De fait, elle ne connaît pas l’outil et est incapable d’en faire la promotion auprès d’autres services voire de l’imposer dans l’entreprise pour lever les contraintes de sécurité que j’évoquais.

Il n’y aura jamais aucune volonté politique des entreprises d’utiliser des outils de type « réseau social », avec différentes applications et des contacts dans des cercles, à cause du mode de fonctionnement des entreprises. S’ils s’imposent dans une entreprise, ça sera par la force, donc dans une démarche condamnée à l’échec, de même que des méthodes de travail ont été imposées dans les années 90 et 2000 pour répondre à des démarches « qualité », parce qu’il fallait des Plans d’Action Qualité, parce que c’était dans la norme, toutes démarches qui ont été contournées par les mails parce qu’elles ne correspondaient pas à l’activité quotidienne des salariés.

Les réseaux sociaux en entreprise mourront probablement d'eux-mêmes parce qu'ils ne seront pas compatibles avec d'autres système et parce que les concepteurs n'ont pas pensé aux besoins réels des gens. Twitter et Facebook doivent avant tout leur succès "au hasard"...

Pour résumer : il n’y a aucune raison d’être optimistes.

C’est mal.