Personne n'a décidé d'arrêter
Il n'y a pas eu de réunion pour annuler le projet. Personne n'a écrit que ça ne marchait pas. L'abonnement est toujours payé, les dossiers créés au lancement existent encore, et la note qui expliquait comment nommer les fichiers dort dans une boîte mail.
Simplement, les documents continuent d'arriver en pièce jointe. Le partage réseau vit toujours. Les personnes arrivées depuis n'ont jamais entendu parler de l'outil.
Un projet documentaire ne s'arrête presque jamais sur une décision. Il s'arrête parce qu'il demande, chaque jour, un geste de plus à des gens qui n'en tirent rien tout de suite. Ce n'est ni un manque de volonté, ni un défaut de formation. C'est un mécanisme, et il est décrit depuis près de quarante ans.
« On n'a pas eu le temps »
C'est vrai, et ça n'explique rien. Le temps manque partout, et certaines choses se font quand même.
La question utile est ailleurs : qui fait le travail, et qui en profite ?
En 1988, Jonathan Grudin publie un texte sur l'échec des logiciels de travail collaboratif qui est resté une référence. Il y nomme un facteur simple : la disparité entre ceux qui bénéficient d'un outil et ceux qui doivent fournir le travail supplémentaire qui le fait fonctionner. Son exemple est l'agenda partagé. Celui qui y gagne est le responsable qui organise la réunion. Ceux qui doivent tenir leur agenda à jour sont les autres, et eux n'en ont pas l'usage.
Transposez aux documents. Celui qui dépose une pièce choisit un dossier, écrit un nom, remplit parfois un champ. Celui qui en profite est la personne qui cherchera ce document dans six mois, et ce n'est pas la même personne. Le coût est immédiat, certain et individuel. Le bénéfice est différé, incertain et collectif.
Aucun rappel ne corrige durablement ce déséquilibre. C'est aussi pourquoi un projet documentaire tient rarement sans que quelqu'un en ait la charge.
Une réserve. Grudin écrit en 1988, sur les logiciels collaboratifs en général, pas sur la gestion documentaire d'une PME. Il décrit une propriété structurelle des outils partagés, pas un taux.
« Les gens n'aiment pas le changement »
Cette formule ferme la discussion au lieu de l'ouvrir. Dans la plupart des cas observés, les gens ne refusent pas l'outil. Ils s'en servent, mais pas comme prévu.
Wanda Orlikowski, chercheuse au MIT, a suivi l'installation de Lotus Notes dans une grande entreprise et publié ses observations dans les actes de la conférence ACM CSCW de 1992. Sa conclusion ne porte pas sur le logiciel. Elle porte sur ce qui l'entoure : l'idée que les gens se font de l'outil, et les structures de l'entreprise, à commencer par ce qui y est récompensé.
Son résultat central : faute de voir la nature collaborative de l'outil, ceux qui s'en servent le réinterprètent comme une technologie personnelle et autonome, du genre de celles qu'ils connaissent déjà. Elle ajoute que dans une culture individualiste et compétitive, sans incitation à coopérer, un logiciel collaboratif ne produit pas de coopération à lui seul.
C'est exactement ce qu'on observe. Le nouvel espace partagé devient une collection d'espaces personnels. Chacun crée son dossier, y met ses fichiers, et les nomme comme il le faisait avant. Personne ne résiste. Tout le monde travaille comme avant, dans un décor neuf.
Une réserve, là aussi : une seule entreprise, un seul logiciel, une étude qualitative. Elle explique un mécanisme, elle ne mesure pas une fréquence.
« On s'est trompé d'outil »
C'est la conclusion la plus fréquente, et la plus coûteuse, parce qu'elle mène à recommencer.
Or les deux travaux ci-dessus ne parlent pas d'un logiciel en particulier. Ils décrivent ce qui se passe dès qu'un outil demande un geste volontaire à quelqu'un qui n'en récolte pas le fruit. Changer de logiciel ne change pas cette structure. Refaire l'arborescence non plus : un chemin de dossiers ne dit pas ce qu'un document est.
La bonne question n'est donc pas « lequel choisir », mais : est-ce que le classement dépend encore d'un geste que quelqu'un doit penser à faire ?
Tant que la réponse est oui, le projet s'use. Pas d'un coup. À mesure que l'urgence reprend le dessus.
Ce que nous ne savons pas
Aucune source primaire accessible ne donne un taux fiable de projets documentaires qui s'arrêtent en route. Les pourcentages qui circulent sur l'échec des projets internes ont le même défaut que les dix-huit minutes passées à chercher un document : on les recopie, et personne ne remonte à l'origine. Nous n'en citons donc aucun.
Ce que nous savons : le mécanisme est documenté, et il ne dépend d'aucune génération de technologie.
Ce que nous ne pouvons pas déduire : l'état de votre projet à vous. Ça, ça se constate. Prenez les dix derniers documents importants entrés dans l'entreprise, et regardez par où ils sont arrivés. Le relevé prend dix minutes, et il est rarement celui qu'on attend.
Un classement qui ne demande rien à personne
Voilà pourquoi MIKURA ne commence pas par une règle à respecter.
La pièce est lue et identifiée à son arrivée : sa famille, sa date de référence, son statut, ce qu'elle remplace. Personne ne choisit de dossier, personne n'écrit de nom. Le geste que Grudin décrit comme le point de rupture n'est demandé à personne, et il n'y a donc rien à abandonner.
Ce qui ne se départage pas tout seul part en bannette. Une personne tranche, et sa décision est consignée. L'effort humain existe, mais il porte sur les quelques cas réellement ambigus, pas sur tous les fichiers qui entrent.
Il n'y a pas de nouvelle habitude à prendre. C'est la réponse au second mécanisme. On ne peut pas réinterpréter un outil avec ses vieux réflexes quand il ne demande aucun réflexe : le document est déposé, le reste se fait derrière.
Et ce que le travail rapporte arrive tout de suite. Le fonds devient interrogeable en langage naturel, et les réponses citent les documents sur lesquels elles s'appuient. Il n'y a pas six mois à attendre avant que le classement serve. Il sert à la première question posée.
C'est ce que recouvre notre positionnement. Le diagnostic et la structuration sont notre métier ; MIKURA est l'outil qui les fait tenir dans le temps. Un fonds mis en ordre une fois se dégrade, parce que les documents continuent d'arriver. Ce qui tient, c'est ce qui ne repose sur la discipline de personne.
Faites le relevé des dix dernières pièces. Si la plupart ne sont pas passées par l'outil que vous avez installé, écrivez-nous ce que vous trouvez : contact@mikura.fr.
Sources
Jonathan Grudin, Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces, actes de la conférence ACM CSCW '88, 1988, p. 85-93. DOI 10.1145/62266.62273.
Éléments cités : la disparité entre ceux qui bénéficient d'une application et ceux qui doivent fournir le travail supplémentaire qui la soutient ; l'exemple de l'agenda partagé, où le bénéficiaire est celui qui organise la réunion et où le travail retombe sur ceux qui n'en ont pas l'usage.
Wanda J. Orlikowski, Learning from Notes: Organizational Issues in Groupware Implementation, actes de la conférence ACM CSCW '92, 1992, p. 362-369. DOI 10.1145/143457.143549.
Éléments cités : étude du déploiement de Lotus Notes dans une grande entreprise ; faute de reconnaître la nature collaborative de l'outil, il est réinterprété comme une technologie personnelle et autonome plus familière ; dans une culture individualiste et compétitive sans incitation à coopérer, un logiciel collaboratif ne produit pas de coopération à lui seul.
Aucun taux, aucune fréquence et aucune durée ne sont transposés d'un de ces travaux à un fonds documentaire d'entreprise dans cet article.