Comment créer les bonnes conditions quand on démarre un projet collaboratif ? Dans l’excellent article « The Art of the Start« , Eugene Eric Kim donne trois ingrédients pour bien démarrer un projet collaboratif. Ils vous seront probablement très utiles dans des projets particulièrement délicats. J’ai traduit cet article et je le mets ici à disposition.
Cet article a été publié initialement par Eugene Eric Kim sous licence Creative Commons Attribution 3.0 Unported License.
Projets collaboratifs: l’art de bien démarrer
Deux de mes mentors, Gail et Matt Taylor, soulignent souvent l’importance des « démarrages propres ». Chaque fois que vous débutez un projet collaboratif difficile, vous devez vous attendre à ce que les choses deviennent désordonnées au milieu. Si vous prenez le temps de mettre en place des conditions pour le succès au début du projet, vous augmentez grandement vos chances de survivre et même vous épanouir dans ce désordre.
Les gens du métier parlent souvent de « créer une bulle protectrice » (note de Lilian: « safe container » se traduirait plutôt par « récipient sûr/sécurisée », mais je préfère une expression qui donne plus de sens en français).
Je suis dans ce processus avec deux projets en ce moment – une expérience avec le programme d’incubateur Code for America et le démarrage de la dernière Collaborative Networks Initiative de la Garfield Foundation – et j’ai voulu partager certaines expériences de l’art de bien démarrer dans ces projets et d’autres.
Créer une bulle protectrice consiste en trois activités:
- Créer un espace agréable et invitant (ce peut être un espace physique, virtuel ou les deux) dans lequel groupe peut interagir
- Développer une compréhension partagée à travers le groupe
- S’accorder explicitement sur la manière de travailler
Si c’est bien fait, la combinaison de ces trois points mène à une plus grande confiance à l’intérieur du groupe, ce qui lui permet d’avancer de manière effective dans le travail.
1 Créer un espace agréable et invitant
Les espaces physiques dans lesquels nous travaillons ont un impact énorme sur notre capacité de travailler effectivement. Des espaces sombres, étroits affectent l’humeur du groupe. L’arrangement des sièges peut renforcer certaines dynamiques de pouvoir. Si c’est difficile d’accéder au tableau blanc, les gens ne l’utiliseront pas.
(Note de Lilian: Pour aller plus loin sur ces sujets et les architectures qui « nourrissent », lire The Timeless Way of Building de l’architecte Christopher Alexander)
Ces problèmes ne s’appliquent pas juste à l’espace physique. Si votre groupe a une conférence téléphonique hebdomadaire de deux heures avec une mauvaise qualité audio et pas d’affichage partagé, les gens vont redouter ces appels (ou simplement faire la sourde oreille). Si vous avez choisi d’interagir en utilisant un outil en ligne que personne ne sait comment utiliser, alors personne ne l’utilisera.
Ces questions d’espaces peuvent sembler triviales, mais je pense qu‘elles sont au moins aussi importantes que la facilitation.
En 2012, j’ai co-dirigé un projet appelé Delta dialogues, où nous facilitions un groupe d’acteurs multiples autour des problèmes liés à l’eau en Californie. Nos participants s’étaient battus sur ces sujets extrêmement controversés pendant des dizaines d’années et beaucoup avaient des procès en cours avec les autres.
Une des premières décisions que nous avons prise a été d’effectuer une rotation des lieux des rencontres entre les participants plutôt que de rechercher un espace « neutre ». Nous avions six rencontres d’une journée et nous avons décidé de consacrer la moitié de ce temps à des « voyages d’apprentissage » – en gros des visites des espaces de chacun.
Nous avons fait cela parce que le Delta de Sacramento est magnifique, et nous voulions passer autant de temps que possible dans cette beauté pour nous rappeler pourquoi nous faisons tout cela. Nous voulions aussi que les participants vivent une expérience directe des environnements des autres pour bâtir une plus grande empathie.
Cette décision n’avait pas été prise à la légère. Étant donné la complexité des problèmes que nous discutions, consacrer la moitié de notre temps à des visites de terrain était difficile à avaler et nous sommes revenus plusieurs fois sur cette décision. Cependant, quand le processus a été terminé, les participants ont cités de manière répétée ces voyages d’apprentissage comme la partie la plus puissante du processus pour eux.
Rick Reed, le leader de l’initiative Collaborative Networks, de la Garfield Foundation’s a des sentiment aussi forts que moi sur l’importance de l’expérience physique. Il recherche des très bons lieux de rencontre avec une belle lumière, et s’assure que la nourriture est excellente et mémorable.
Certaines personnes ne pensent pas que des fondations devraient dépenser de l’argent sur des choses comme un bel espace et une bonne nourriture en regard des difficultés économiques auxquelles le secteur non marchand fait face. Bien que je sois fan d’une certaine discipline financière, je pense que si les fondations veulent contribuer à des grandes expériences collaboratives, deux des façons les plus simples de le faire et qui ont le plus d’impact sont d’investir dans un super espace et une super nourriture.
Créer un espace invitant et agréable/plaisant ne s’arrête pas à l’espace physique ou même virtuel. Le langage par exemple est une grande part de cela.
(Note de Lilian, à ce sujet lire: Jean-François Noubel, The role of Architectures in Human Ressources sur l’importance des architectures invisibles).
J’utilise souvent le terme « règles de base » pour décrire les accords de travail (voir dessous), mais quand j’ai utilisé le terme à une rencontre de design à Collaborative Networks, notre équipière, Ruth Rominger, l’a repoussé.
Elle pensait que les implications du mot « règles » allaient à l’encontre de la culture que nous étions en train d’essayer de bâtir. Sur une suggestion de Curtis Ogden, nous avons décidé d’adopter le terme d’ « accords de travail » (« working agreements ») à la place, terme plus invitant, mais toujours plein de sens.
2. Développer une compréhension partagée (shared understanding)
Le processus de normes du groupe consiste à développer une compréhension partagée, ce qui mène a une plus grande confiance et des relations plus fortes.
Par défaut, la meilleure manière de développer une compréhension partagée est de travailler ensemble. Cela a de grands avantages, mais ils sont facilement neutralisés ou pire si vous ne prenez pas le temps d’avoir aussi des conversations explicites à propos des normes.
Par exemple quand je travaillais comme consultant, j’ai passé une partie significative de mon temps à aider les parties en présence à être clair et alignés sur les objectifs du projet. C’était une étape assez directe mais gourmande en temps, une que la plupart des groupes livrés à eux même laisseraient de coté.
Et pourtant cette étape seule a fait une différence énorme dans la qualité de l’engagement une fois que nous étions lancés. Souvent les individus ne se sentent pas autorisés à agir ou responsables vis à vis du groupe, simplement parce qu’il n’y a pas de compréhension partagée de ce qu’ils sont censé faire ou de ce qui est attendu de leur part.
Comment développez vous cette compréhension partagée ? La première étape la plus simple est de ménager du temps pour avoir ces conversations en tant que groupe. Une énorme part de mon expérience avec l’incubateur Code for America est simplement cela – donner aux startups un temps structuré pour avoir des conversation explicites à propos de choses comme quel type d’organisation ils aimeraient et comment ils aimeraient travailler ensemble.
Au delà de cela, il y a quelques trucs utiles. L’un est de piocher dans les expériences et valeurs personnelles des personnes. Plutôt que de démarrer avec la question « Comment aimeriez vous travailler ensemble? », demandez à chacun « Quelle a été votre meilleure expérience à plusieurs ? » ou mieux encore « Pourquoi êtes vous arrivé dans ce travail?
Faites partager aux personnes leurs histoires avec les autres puis faites remonter les patterns (= « éléments récurrents », note de Lilian) et les idées clés des histoires.
Pour les Delta Dialogues, nous avions demandé aux participants de répondre à la question: Quel est votre endroit favori dans le Delta? » La plupart des participants se connaissaient depuis des dizaines d’années et pourtant ne connaissaient pas les réponses des autres à ces questions.
Cela renforçait le fait que tout le monde dans la pièce (y compris les supposés « méchants » ) avait des connexions profondes avec le Delta et cela a rappelé à chacun ce qui était en jeu.
Une autre astuce est de concevoir ces expériences pour qu’elles soient dans le flow autant que possible.
(Note de Lilian: Le flow est l’état mental atteint par une personne lorsqu’elle est complètement immergée dans ce qu’elle fait, dans un état maximal de concentration, Voir Flow sur Wikipédia).
Les personnes qui conçoivent des expérience collaboratives – les consultants en particulier – font souvent deux erreurs: ils focalisent surtout sur les réunions/rencontres et ils ne prêtent pas assez attention au travail que les participants sont déjà en train de faire.
Vous ne partez quasiment jamais de zéro. Les personnes ont des relations pré-existantes et ils ont peut-être déjà fait le travail que vous voulez leur faire faire.
J’ai rejoins le processus de planification stratégique de la Wikimédia Foundation en 2009. Quatre mois plus tôt, la Wikimédia Foundation avait recruté une agence traditionnelle de consultants en management et ils étaient bloqués.
Ces consultants n’avaient aucune expérience avec les processus participatifs ou la communauté Wikimédia et ils avaient conçu un processus qui n’était pas viable. Leur plan ressemblait à tous les processus de planification stratégique traditionnels. Ils passeraient quatre mois à faire leur recherche de leur coté et trouveraient les « bonnes » questions stratégiques, puis ils sortiraient une présentation léchée à destination de la communauté et demanderaient des retours.
Non seulement cette approche ne prenait pas en compte l’esprit du projet (planification stratégique style wiki) ou la culture de la communauté, mais elle ignorait complètement le défi du recrutement des participants. La communauté d’éditeurs Wikimédia, est principalement composée d’ados et jeunes hommes dans la vingtaine.
Ils n’avaient aucune idée de ce qu’était la planification stratégique et encore pourquoi ils devraient participer. Même s’il comprenaient ce qu’était la planification stratégique, ils n’avaient aucune raison de s’engager dessus avec nous. Pourquoi devraient ils croire nos intentions affirmées de faciliter un processus ouvert de type wiki ?
Je voulais développer une compréhension partagée du travail qui avait déjà été fait et je voulais aussi développer une compréhension partagée de ce que nous étions en train de d’essayer de faire avec ce processus. Plutôt que d’attendre quatre mois pour faire de la recherche isolée, dans la semaine du démarrage du projet, nous étions en train d’engager la discussion avec la communauté sur un wiki.
Nous avons expliqué ce que nous avions espéré faire, et nous avons écouté. Nous n’avons pas fait de grandes promesses et nous n’avons revendiqué aucune expertise. Nous avons simplement invités les gens à dire à tout le monde (pas seulement à nous) ce quelles devraient être les priorités du mouvement Wikimédia à leur avis et indiquer le travail déjà en train d’être fait.
Dans l’idée de créer une bulle invitante, notre facilitateur Philippe Beaudette, a insisté sur l’importance de rendre notre espace multilingue, étant donné le caractère international de la communauté. Nous avons invités les gens à engager la discussion dans n’importe quel langage avec lequel ils étaient à l’aise, et nous avons fait de notre mieux pour traduire nos demandes dans autant de langages que possible.
Nous avions une demande claire et cette demande était familière pour la communauté Wikimédia. Ils étaient habitués à partager et organiser leurs pensées, et ils n’étaient pas timides pour partager leurs opinions. En quelques semaines, nous avions un incroyable manuel de réflexions bien organisées qui avaient déjà étaient faites par la communauté, avec un groupe de questions stratégiques bien pensées que les gens pensaient qu’il était important d’explorer.
Plus important, les gens ont commencés à nous faire confiance. Ils ont vu que nous avions compris, que nous n’étions pas en train d’essayer d’ imposer quelque chose venant du haut sur un mouvement qui est intrinsèquement ascendant (nous aurions échoué si nous avions essayé).
Nous n’avons pas essayé d’avoir une grande rencontre de lancement ou de faciliter un groupe de conversations privées entre initiés. A la place, nous avons passé du temps dans des espaces qui existaient déjà (comme le wiki et les chats/canaux de discussion en ligne en temps réel) et nous avons facilité une conversation collective, pas juste une conversation entre quatre yeux.
La communauté prenait possession du processus et nous étions en train de contribuer à cela. Même s’il ne comprenaient pas complètement ce que nous étions en train d’essayer de faire, ils le comprenaient assez et ils nous faisaient assez confiance pour y donner une chance.
3. Établir des accords explicites sur la manière de travailler (« make explicit working agreements »)
Je trouve que s’accorder explicitement sur la manière de travailler est l’une des choses les importantes que l’un groupe puisse faire, que cela soit une petite équipe ou un large réseau.
Par exemple certains pourraient penser que « traiter les autres avec respect » devrait être implicite dans chaque dispositif de travail. Même si c’est le cas, le rendre explicite ne peut pas faire de mal et cela peut même aider. D’abord cela vous force à développer une compréhension partagée de ce que « traiter les autres avec respect » veut dire.
Pour certains, cela pourrait voir dire ne jamais élever la voix. Pour d’autres cela pourrait n’avoir rien à faire avec la façon dont vous vous exprimez, seulement ce que vous faites. Faire ressortir ces choses au début plutôt que plus tard, puis arriver à s’accorder dessus préviendra des problèmes plus tard.
Établir des accords sur la manière de travailler a deux autres effets importants, particulièrement dans les grands groupes. Premièrement, cela rend tout le monde responsable du respect de ces accords par lui/elle même ou par les autres . Souvent dans les grandes réunions, les gens dépendent d’un facilitateur pour garder la conversation constructive et polie.
C’est en effet une des responsabilités du facilitateur, mais c’est un muscle que chacun dans le groupe devrait exercer. Dans les groupes sains, tout le monde s’entraide pour respecter ces accords.
Deuxièmement, cela définit des conditions pour exclure quelqu’un d’un groupe sur lesquelles on s’est mis d’accord. Beaucoup de personnes redoutent les processus ouverts car ils ont peur que certains prennent la conversation en otage et supposent à tort que l’on ne peut pas exclure quelqu’un d’une conversation ouverte.
Si avant toute chose vous créez des accords de travail clairs, et si vous vous assurez que les participants soient conscients des ces accords, alors quand certains dépassent les bornes, vous avez le droit de les expulser.
Nous avons eu plus d’un millier de participants dans le processus de planification stratégique Wikimédia. Au cours de l’année qu’a durée le processus, nous avons exclut deux personnes du processus complet et j’ai exclut une personne d’une réunion (personne qui s’est excusée plus tard et est devenue ensuite un participant très constructif au processus).
Aucun de ces incidents n’était facile, mais quand nous avons agit ainsi, tout le monde dans la communauté comprenait et approuvait nos actions, de part nos accords préalablement établis sur la manière de travailler.
Cet article a été publié initialement par Eugene Eric Kim sous licence Creative Commons Attribution 3.0 Unported License.
Commentaires finaux
J’ai trouvé que Eugene résumait extrêmement bien de nombreux points importants sur la mise en place et la conduite de projets collaboratifs, ce qui m’a poussé à traduire cet article. En complément, en plus des liens que j’ain inséré dans la traduction, je vous conseille aussi de jeter un oeil sur les commentaires de l’article où il discute plus en détail la gestion et l’exclusion de participants difficiles dans des processus ouvert.
Pour finir, il y a un point en particulier sur lequel j’aimerai revenir:
je partage l’opinion d’Eugene sur l’extrême importance de l’architecture (visible et invisible) de l’espace de collaboration sur le processus collaboratif.
Trop de gens considère qu’une salle de réunion en vaut une autre, qu’un outil collaboratif en ligne qui, techniquement, fonctionne, suffira pour faire collaborer un groupe et ne voient pas comment ces espaces influencent fortement les interactions et les dynamiques subtiles au sein d’un groupe.
Comme Eugene, je pense que ces questions d’espaces (physiques ou virtuels) sont au moins aussi importantes que la facilitation.
Ce sont ces réflexions sur la conception d’architectures favorisant les dynamiques coopératives qui, influencées par les langages de patterns de l’architecte Christopher Alexander et les idées de Jean-François Noubel sur les architectures invisibles, m’ont amenées à lancer le projet de recherche ouverte sur les évènement co-créatifs pour identifier les meilleures solutions récurrentes.
8 commentaires sur “Projets collaboratifs: l’art de bien démarrer”
Un très grand merci Lilian pour cette découvert grâce à ta traduction et la veille que tu fais dans ce domaine. Trois leviers simples et de bon sens, évidents à mémoriser et à mettre en œuvre,très utiles pour tous nos projets collaboratifs.
oui, il me semblait important de partager pour ces même raisons.
Je fais toute ma veille grâce à mon réseau twitter. Comme je suis des gens très variés je vois différentes écoles de pensée, selon les pays ou les domaines, il me semble très important de faire circuler l’info entres les différents réseaux pour faire une pollinisation croisée des idées.
j’ai encore plein d’autres excellentes infos sous le coude et plein d’idées en tête, faut juste que je trouve le temps de digérer/synthétiser/traduire/rédiger/éditer/publier tout ça… 😉
Merci pour le partage et la traduction! J’ai appris un nouveau mot aussi — « bulle protectrice »!
Hi Eugene,
merci pour l’article et le commentaire 🙂
I was about to leave you a comment but you were faster to find me !
« safe container » translated in french sounds a bit like « secure can », so I chose « bulle protectrice » (« protecting bubble ») which, in my opinion, convey the meaning in a more inviting way.
a bientot !
Merci Lilian d’avoir traduit ce papier d’Eugene un excellent penseur de la collaboration.
Dans la même veine, vous pourriez être intéressés par ceci : http://peeragogy.org. Si d’aventure vous connaissez des personnes intéressées à traduire le contenu de ce guide, j’ai un wiki en stand-by à cet effet, mais ma thèse en-cours ne m’a pas encore permis de me pencher sur la traduction.
Je m’étais inscrit sur la communauté Peeragogy Google+, mais je n’avais pas exploré beaucoup et je ne connaissais pas cet ouvrage. Merci pour l’info, je vais essayer de prendre un peu de temps pour le lire.
Je trouve intéressant qu’ils l’aient aussi mis au format github pour une collaboration distribuée.
Pour trouver des participants/traducteurs, peut être voir:
la communauté anim-fr (animateur francophones), c’est avec certaines personnes de cette communauté que nous avons traduit un article sur la stigmergie.
La communauté G+ Co-Construire Nouveaux Savoirs dont l’esprit semble proche de la communauté Peeragogy
A l’avenir il serait interessant de réfléchir à rassembler une communauté de co-traducteurs, personnes intéressées par les modèles coopératifs, avec un lieu où des articles pourraient être proposés à une communauté de traducteurs.
Pas le temps de m’en charger, mais je lance l’idée, au cas ou ça inspire quelqu’un 🙂
MAJ: Juste après avoir posté le commentaire, je me souviens de Framalang, réseau de traducteurs de framasoft. C’est plus centré « libre », mais potentiellement avec des centres d’intérets proches