Lorsqu’un groupe de recherche doit recruter quelqu’un, plusieurs personnes s’en occupent généralement : le superviseur a une idée approximative du profil recherché, un collègue plus expérimenté dispose d’une liste de noms potentiellement adaptés, et la personne chargée des relations extérieures réfléchit à la manière de formuler cette invitation. La difficulté est que ces informations se trouvent rarement au même endroit : le périmètre a été évoqué une fois en réunion, la liste est dans les notes de quelqu’un, et il faut redemander la présentation à utiliser. Au moment de rassembler le tout, personne ne dispose souvent d’une version complète.
Le fond du problème n’est pas un manque de diligence, mais l’absence d’un espace de travail commun. Le profil de talent répond à la question « pourquoi une fiche est-elle fiable ? », tandis que l’atelier de recherche collaborative répond à « où placer cette fiche fiable, et qui la maintient collectivement ? ». Cet article détaille précisément le point de jonction entre les deux.
01 Des listes dispersées dans les échanges, ou consolidées dans un groupe de projet
▲ Figure 1 | La différence ne tient pas à qui se souvient du plus de choses, mais à la possibilité pour la personne suivante de reprendre le travail.
Commençons par la différence la plus évidente. Lorsque les listes sont dispersées dans les conversations et les e-mails, chacun ajoute quelques éléments dans son propre document, et il est courant que les versions ne concordent pas au moment de la synthèse : une personne portant le même nom se retrouve sur deux lignes, la même personne apparaît sous deux orthographes, et il est ensuite difficile de savoir de quelle version il s’agit. Une fois le tout placé dans un groupe de projet, il n’existe plus qu’une seule version : qui a ajouté quoi, quand, et sur quelle base à ce moment-là, tout reste dans le même espace.
La manière de traiter les doutes change elle aussi. Lors d’une organisation dispersée, l’élément incertain est souvent laissé de côté sans précision ; dans un document de travail partagé, les noms qui ne concordent pas peuvent être placés dans une catégorie distincte, pour indiquer clairement aux personnes suivantes que « cette entrée n’a pas été vérifiée ». Mieux vaut conserver une entrée à vérifier que de mélanger à la liste officielle des fiches dont la source n’est pas claire.
Le coût de la transmission constitue la troisième différence. Lorsqu’une autre personne reprend le sujet, le contexte dispersé dans les conversations doit être raconté de nouveau ; dans un groupe de projet, les échanges, les agents et les fichiers sont tous là, et la personne suivante peut ouvrir l’espace et poursuivre directement.
02 Trois onglets, chacun prenant en charge une partie
▲ Figure 2 | Membres, agents et fichiers : trois types d’objets qui partagent le même contexte.
Le niveau des membres répond à la question « qui participe ? ». Le créateur du projet et les membres ordinaires sont distingués dans la liste, et la répartition des tâches est explicite : le superviseur définit le périmètre, le collègue plus expérimenté complète les candidats, et la personne chargée des relations extérieures envoie les documents. Une fois les rôles clairs, il n’est plus nécessaire de discuter sans cesse de qui doit compléter quelle partie.
Le niveau des agents répond à la question « qui va organiser ? ». Un groupe de projet peut associer un agent, que les membres peuvent invoquer en saisissant `@` dans le champ de saisie. Pour la recherche de candidats, l’intérêt est de réorganiser selon un même ensemble de champs la masse de noms apportés par chacun — informations de base, parcours scolaire, expérience professionnelle, principaux résultats de recherche — en alignant chaque élément en colonnes, plutôt que de rédiger chacun son propre paragraphe. Dans les groupes de projet MuchSci, cette étape se déroule au même endroit que la discussion, sans qu’il faille sortir puis réimporter la liste.
Le niveau des fichiers répond à la question « où sont conservés les résultats ? ». La liste de candidats, les dossiers organisés et les documents d’invitation finalisés sont conservés avec le projet et ne sont pas emportés par les nouveaux messages de discussion. Pendant les échanges, il est possible de citer directement les documents, au lieu de lancer un lien et de laisser chacun chercher.
03 Voici comment un document de travail partagé prend forme
▲ Figure 3 | De la création du groupe et de la définition du périmètre jusqu’au document finalisé déposé dans l’espace fichiers, les six étapes se déroulent dans le même espace.
Le processus comporte en gros six étapes : créer un groupe de projet pour un sujet de recrutement et commencer par clarifier le périmètre ; chaque membre ajoute des personnes de son côté, sans se presser de tout organiser ; dans la discussion, invoquer avec `@` l’agent associé pour qu’il complète les dossiers par lots selon les quatre catégories de champs ; placer les entrées incertaines dans une catégorie distincte, marquée à vérifier, sans les intégrer à la liste officielle ; déposer les dossiers organisés dans l’espace fichiers, partagés par les membres ; puis faire relire l’ensemble par une personne qui connaît bien le sujet.
Ce qui compte, c’est que « l’incomplétude est elle aussi autorisée ». L’existence d’une catégorie « à vérifier » montre que le processus d’organisation reconnaît qu’il comporte des incertitudes. Si un document de travail partagé n’autorisait que les contenus certains, les membres supprimeraient purement et simplement les éléments douteux, et l’on perdrait au contraire des pistes.
La traçabilité est un autre avantage. Qui a complété une entrée, sur quelle base, et si elle a été vérifiée ou non : tout reste dans l’espace du projet. Au moment d’envoyer officiellement une invitation, il est bien moins coûteux de faire une vérification rétrospective.
04 Interface fonctionnelle : membres, agents et fichiers sur le même écran
▲ Figure 4 | Les trois types de difficultés liées au travail isolé peuvent justement être pris en charge par un même document de travail.
Après être entré dans le groupe de projet, l’interface ressemble à un espace de travail de sujet : à droite, trois onglets « Membres », « Agents » et « Fichiers », et en bas, le champ de saisie indique que la saisie de `@` permet d’invoquer l’agent du groupe de projet associé.
▲ Figure 5 | À l’intérieur du groupe de projet : trois onglets côte à côte, et dans la discussion, il est possible d’assigner directement une tâche à l’agent avec `@`.
Le mécanisme `@` est ici essentiel. Dans une conversation ordinaire, mentionner une personne avec @ revient à l’appeler pour qu’elle vienne lire le message ; dans la discussion d’un groupe de projet, mentionner un agent avec @ revient à invoquer ses capacités. Le même champ de saisie permet donc à la fois d’envoyer un message aux membres et de confier une tâche à l’agent, qui fait ainsi partie du processus de collaboration. MuchSci place le profil de talent dans l’onglet de l’assistant agent personnel ; grâce à cette mécanique, l’organisation des dossiers et les discussions peuvent avoir lieu au même endroit.
05 Limites
① Cet article présente les mécanismes fonctionnels et les modes d’utilisation ; il ne constitue pas une promesse de résultat. Le fait qu’un groupe de projet puisse centraliser le contexte ne signifie pas que la recherche de candidats sera nécessairement plus fluide : cela dépend aussi des habitudes d’utilisation des membres et de la clarté de la tâche.
② Structurer ne signifie pas évaluer. Les dossiers consistent en une organisation de sources publiques et ne constituent ni une évaluation des compétences, ni une recommandation, ni une caution pour quiconque ; les jugements concernant une personne précise doivent être vérifiés et assumés par l’utilisateur.
③ Utiliser uniquement des sources publiques. Aucune donnée personnelle privée n’est concernée ; pour les usages officiels tels que l’évaluation, le recrutement ou la due diligence, les règles et procédures en vigueur de l’organisme concerné prévalent.