Si de bons outils technologiques ne font pas nécessairement le succès d'une communauté, ce sont des atouts importants, et le plus souvent de mauvais outils peuvent en tout cas mener à l'échec.

Ils doivent notamment permettre malgré la distance géographique la collaboration, la communication, le management des connaissances, l'échange de documents, ou encore la résolution de problèmes. La liste n'est pas exhaustive, et le défi soulevé par ces nouveaux enjeux demande de savoir coller de très près à la réalité rencontrée, une réalité par définition dynamique et mettant en jeu de surcroît des connaissances tacites dont la formalisation ne va pas de soi.

Il faut donc, nous l'avons dit, des outils appropriés. Le terme anglophone "usefulness", qui regroupe à la fois l'utilité (utility) et l'utilisabilité (usability), n'a pas vraiment d'équivalent français. Mais la question qu'il pose est fondamentale : Qu'est-ce qui fait qu'un logiciel est, dans le contexte d'une organisation donnée (utilisateurs, etc.), à la fois utile et utilisable (... et réellement utilisé) ?

Commençons par son utilité : Un outil doit répondre bien sûr à des besoins, besoins qui dans le cas de configurations sociales en mouvement ne peuvent se satisfaire d'une réponse figée et définitive. L'Actor Network Theory (qui porte mal son nom puisqu'il s'agit plus d'une méthode que d'une théorie) est un cadre efficace pour représenter ce type de configuration et aider à concevoir dans une dynamique participative des solutions évolutives.

Le terme d' "utilisabilité", qui évoque l'ergonomie des logiciels, explore le deuxième versant de cet édifice. Un logiciel peut très bien avoir des fonctionnalités répondant au besoin exprimé, tout en n'étant pas suffisamment "utilisable". Ajoutez un contexte organisationnel et humain, et vous aurez un juste panorama de ce qui pourra le faire réellement utiliser par les principaux intéressés.

Bien sûr, la conduite du changement, dont je reparlerai sans doute dans un autre article, est un très grand atout, pour arriver à une "bonne" utilisation du logiciel (et ce que je décris peut d'ailleurs tout aussi bien s'inscrire dans le cadre de la conduite du changement). Quand on travaille pour (et avec !) des communautés de pratique, il est possible d'agir dès la conception (ou le choix des outils), en impliquant les utilisateurs d'une manière adéquate. Dans une méthode de conception participative, l' "usefulness", telle que décrite ici (utilité + utilisabilité, grosso modo) est l'objet d'une "négociation" de sens (à travers des interactions sociales) faisant converger les points de vue des différents protagonistes (utilisateurs et concepteurs), ce qui est particulièrement adapté à l'esprit et à la nature des communautés de pratiques.

ANT fournit un appui intéressant, dans cette démarche. Comment ? Grâce à sa capacité unique à décrire des environnements sociaux en mouvement, et mettant en scène des acteurs hétérogènes, y compris, et c'est l'un des points forts, des "acteurs non humains" du réseau (les logiciel en construction, ou existants, peuvent par exemple en faire partie). D'autres notions sont particulièrement utiles, dans un projet informatique destiné aux communautés de pratiques, comme l'alignement des intérêts des acteurs durant le processus, le black-boxing (fait de considérer comme acquis un élément, qui ne bougera plus, et servira de point d'appui à la construction), et les rôles d' "inhibiteurs" et de "promoteurs" des acteurs dans le réseau.

Théorie (sociologique ici) et pragmatisme font facilement bon ménage, les associer pour savoir où l'on va est, in fine, un gage d'efficacité !