De la bureau-cratie à la tout-doux-cratie : refonder la gouvernance associative

Une asso qui se lance, comment ça marche ? Ou plutôt quels écueils ça rencontre, comment on peut les contourner, quel mode de gouvernance installer… ? Ces questions et bien d’autres qui agitent ses membres jusqu’à les rendre perplexes, Quentin et ses complices les ont affrontées au sein de l’association Picasoft…

Faut-il préciser que chez Framasoft, asso déjà plus ancienne, ces questions et leurs réponses nous ont tout de suite « parlé », car d’une saison à l’autre ce sont bien les mêmes perplexités que nous avons rencontrés et retrouvons encore périodiquement sans avoir beaucoup plus de certitudes malgré les années…

C’est donc avec beaucoup de plaisir et d’intérêt que nous avons lu l’analyse très fine et teintée d’humour que propose Quentin et que nous vous partageons, tant il nous semble que beaucoup de membres d’associations diverses (et pas seulement les CHATONS) pourraient en tirer profit, du moins une saine réflexion.

---

Ce billet raconte une histoire : l’histoire d’un hébergeur associatif étudiant et universitaire face à ses dilemmes internes. Un chaton au bord de la crise de nerfs. Mieux sécuriser les données des utilisateur·ices au prix d’un flicage des bénévoles ? Militer pour des thèmes qui ne parlent pas à tout le monde ou rester consensuel ?

En fait, c’est l’histoire de dilemmes qui se transforment en crise. Je vous propose de me suivre dans cette enquête pour comprendre ce qui n’a pas fonctionné, et comment on a réagi. On y réalisera notamment que cette histoire est terriblement banale et que le ver était dans le fruit depuis le début. Toute organisation, tôt ou tard, doit regarder ses tensions dans les yeux sous peine d’imploser, et il y a fort à parier que certains machins résonneront avec vos propres histoires.

Rappelons d’abord qu’il n’y a pas de méthode optimale pour résoudre des conflits, ou plus généralement, pour décider de la bonne chose à faire – en premier lieu parce que tout le monde a ses propres besoins et ses propres valeurs et qu’il est rare de pouvoir les satisfaire simultanément et pleinement. Tout processus de décision porte en lui-même des arbitrages. Il peut favoriser la fluidité au détriment du consensus. Il peut préférer la lenteur à l’urgence. Il peut chercher à maximiser la satisfaction globale quitte à autoriser une insatisfaction marginale très forte. En bref, un processus de décision n’est jamais neutre.

Et pourtant, on verra qu’il est indispensable de choisir explicitement un processus de décision, sous peine de laisser les rapports de domination se reproduire subrepticement. Le nôtre, c’est la tout-doux-cratie, qui occupera la suite de ce billet. Nous l’avons écrit avec l’espoir qu’il essaimera et fera fleurir des idées fécondes, pour nos ami·es CHATONS mais pas seulement ; vers toutes les structures qui, un jour, se retrouveront face à des dilemmes explosifs. Bonne lecture! ☺️

J’oubliais… évidemment, ce système n’est pas parfait, alors après la théorie, il sera utile de regarder la pratique. Deux ans de tout-doux-cratie plus tard, je vous proposerai un retour d’expérience, quelques cas pratiques et un essai d’auto-critique. Mais ça… ce sera pour un autre billet. 😉

Qui sont-ils ? Quel est leur projet ?

Nous, je, on, c’est Picasoft. Je vous propose un peu de contexte pour se mettre dans le bain. Picasoft est une association étudiante créée en 2016 à l’Université de Technologie de Compiègne (UTC). Elle est membre du collectif CHATONS.

Le nombre de membres est plutôt stable dans le temps : entre cinq et dix membres actifs, entre vingt et trente enthousiastes prêt·es à donner un coup de main. Ses bénévoles sont étudiant·es ou enseignant·es chercheur·ses.

Quant à notre projet…

L’Association Picasoft a pour objet de promouvoir et défendre une approche libriste inclusive, respectueuse de la vie privée, respectueuse de la liberté d’expression, respectueuse de la solidarité entre les humains et respectueuse de l’environnement, notamment dans le domaine de l’informatique.

C’est un extrait de nos statuts. Vous l’aurez compris, la voie est libre. Plus concrètement, Picasoft s’est engagée dans trois voies :

1. Héberger des services web libres et respectueux de la vie privée ;
2. Sensibiliser les citoyenn·es aux enjeux autour du numérique ;
3. Former les étudiant·es ingénieur·es à des façons de faire (auto-hébergement, hébergement à petite échelle…) peu ou pas traitées en cours.

Par exemple, on propose :

• Une dizaine de services libres et gratuits ;
• Une émission de radio ;
• Des formations à Linux, à la culture libre… ;
• Des conférences sur le numérique, la surveillance… ;
• Une documentation fournie…

 

 

Par ailleurs, Picasoft s’inscrit dans un écosystème particulier, qui est important pour la suite ; je vous prie donc de me pardonner ces précisions administratives. L’UTC compte plus d’une centaine d’associations étudiantes, fédérées de manière très verticale jusqu’au Bureau Des Étudiants (BDE), un organe essentiellement administratif.

Lors de sa création, Picasoft fait le choix de se constituer en association loi 1901, pour s’assurer une relative indépendance par rapport au BDE. En effet, les autres associations, des genres de « projets » du BDE, n’ont pas d’existence légale propre ni de compte en banque. Pour autant, le couplage entre Picasoft et l’UTC reste très fort, notamment à travers le soutien fort du laboratoire de sciences humaines et sociales, Costech.

Et qui dit association loi 1901 dit statuts.

Les statuts sont l’acte fondateur d’une association [qui comporte] les informations décrivant l’objet (ou le but) de l’association et ses règles de fonctionnement.¹

Ça ne rigole pas, des règles de fonctionnement. Finie l’insouciance, fini de se rouler dans l’herbe pieds nus en jouant du djembé : il faut rédiger des statuts et les envoyer à la préfecture (bruit de tonnerre).

Alors l’équipe de l’époque s’attelle à la tâche. L’idée est moins de contrôler ses membres que de faciliter les roulements dans l’association en lui donnant un cadre. En effet, l’UTC fonctionne sur un rythme semestriel. Tous les semestres, des étudiant·es partent en stage ou à l’étranger : il faut sans cesse renouveler les membres, transmettre les savoir-faire technique, financier et administratif, s’assurer d’un service minimum… En bref, faire de Picasoft un chaton étudiant durable et compostable.

Alors, on signe où et quoi ?

Vieux pots et (dé)confiture

Les premiers statuts de Picasoft sont calqués sur ceux de Rhizome, le Fournisseur d’Accès à Internet étudiant de l’UTC. Et pour cause, c’est Kyâne, un ancien membre de Rhizome, qui a aidé à lancer l’aventure Picasoft.

Expérimenté plusieurs années chez Rhizome, c’est un modèle très classique qui a « fait ses preuves ». Examinons-en quelques concepts-clés. D’abord, les décisions sont prises par un sous-ensemble des membres.

L’Association est dirigée par un Bureau d’au moins trois membres. […] Toute prise de décision relevant du Bureau est soumise au vote. Ce vote a lieu lors d’une réunion où doivent être présents au minimum deux-tiers des membres du Bureau. La décision est adoptée à la majorité absolue des membres du Bureau.

Les membres doivent adhérer à l’association (chez Rhizome, c’est 1€ symbolique).

Est membre de l’Association toute personne à jour de la cotisation fixée dans le Règlement Intérieur.

Le bureau est renouvelé régulièrement…

L’Assemblée Générale Ordinaire se réunit obligatoirement au moins une fois par semestre. […] Il est aussi procédé à l’élection des membres du Bureau.

…et doit rendre des comptes.

Lors de cette réunion dite « semestrielle », le Président soumet à l’Assemblée Générale un rapport sur l’activité de l’Association. Le Trésorier soumet le rapport financier comportant les comptes de l’exercice écoulé.

L’intention de ces statuts est de déléguer aux membres de l’association à un bureau élu lors des Assemblées Générales (AG). En pratique, le bureau assure la gestion quotidienne, sous mandat de l’AG. Notamment, s’il est en rupture avec les autres membres, il peut être dissous par les membres.

Alors, à parler de bureau, d’AG et de préfecture, le suspense monte inévitablement. Je vous devine derrière l’écran, les yeux pétillants, à vous demander : mais quand est-ce-qu’on arrive ? qu’est-ce-qui a mal tourné alors que tout semblait si bien parti ?

Eh bien pour le savoir, il faut examiner dans le détail les cruels dilemmes qui ont déchiré l’association (le lecteur découvrira plus tard que j’en fais trop, mais j’espère pour l’heure avoir retenu son attention).

Picasoft, « respectueux de la vie privée » ?

À la fin de l’année 2017, nos services connaissent leur première hausse de fréquentation. 1000 utilisateur·ices sur Mattermost, 500 pads créés… C’est modeste, mais c’est aussi l’occasion de se poser une question : quelles sont les garanties que les utilisateur·ices sont en droit d’attendre ? Il y a en effet une tension entre la présentation de nos services et nos Conditions Générales d’Utilisation.

D’un côté, on pourrait tendre l’oreille sur un stand Picasoft et glaner un bout de conversation :

L’idée, c’est de proposer une alternative locale, pour les services collaboratifs mais pas que. Tes données restent à toi, on ne les regarde pas, on ne les vend pas, elles restent sur nos serveurs et personne n’y touche! 😙 — un·e sympathisant·e de Picasoft

De l’autre, nos CGU sont plus prudentes :

Picasoft fera tout son possible pour que vos données personnelles ne puissent être consultées par personne d’autre que vous et votre destinataire le cas échéant. […] On n’est pas obligé de réparer. Picasoft propose ce service gratuitement et librement. Si vous perdez des données, par votre faute ou par la nôtre, désolé, mais ça arrive. — nos sympathiques CGU

Cette prudence est naturelle : personne n’a envie d’engager la responsabilité juridique de Picasoft parce que quelqu’un a perdu son pad. Le message est clair : on fait de notre mieux. Mais est-ce vraiment cette version que les utilisateur·ices ont en tête ? Car mécaniquement, plus le public s’agrandit, plus le lien humain avec l’association est ténu. Et, aux convaincu·es du début, s’ajoutent deux types de personnes : les convaincu·es par un·e convaincu·e et les obligé·es par un·e convaincu·e. Avec un public encore élargi, on peut y ajouter les personnes qui découvrent les services par hasard.

 

Dans tous les cas, ces personnes n’ont généralement pas lu nos CGU ni échangé avec nous. Les convaincu·es attendent a minima que leur vie privée soit effectivement respectée tandis que les autres attendent que leurs données soient accessibles et intègres. Cette pseudo-catégorisation est bien entendu très réductrice ; on y oublie par exemple les personnes qui ont conscience de l’aspect artisanal des petites structures comme Picasoft. Ces dernières savent que la disponibilité permanente nécessite un fort investissement et se fait parfois au prix d’une infrastructure technique complexe, coûteuse et énergivore. Par ce prisme, il semble raisonnable que les services soient parfois indisponibles. Mais l’image marketing du Cloud, partout-tout-le-temps-pour-toujours, invisibilise la difficulté et les moyens à déployer pour obtenir ces garanties.

Alors, pour beaucoup, un service Picasoft c’est au pire un énième service, au mieux un service qui lui, respecte la confidentialité. La confidentialité est un des éléments du triptyque de la sécurité informatique : confidentialité (ma vie privée est respectée), intégrité (mes données ne sont pas perdues) et disponibilité (mes données sont accessibles). Ces attributs sont généralement pris comme des présupposés. Alors, quelle posture adopter ? Il est délicat de se cacher derrière nos CGU, car nous ne voulons pas ternir l’image du libre et des CHATONS, mais nous ne voulons pas non plus jouer le jeu des « Cloud » commerciaux².

Nous souhaitons véritablement faire de notre mieux pour la sécurité. Et en matière de sécurité, les déclarations d’intention ne suffisent pas. Les risques sont nombreux et concrets : clés d’accès aux machines perdues dans la nature, failles de sécurité non corrigées et exploitées par un·e attaquant·e, curiosité mal placée d’un·e membre… Au boulot : un des processus de base pour améliorer la sécurité d’une infrastructure est de réduire la surface d’attaque, c’est-à-dire la réunion des points d’entrée par lesquels une attaque est susceptible de se produire. Intuitivement, plus il y a de logiciels installés sur les serveurs et plus il y a de personnes qui y ont accès, plus la surface d’attaque augmente.

Cette question cruciale est débattue pendant l’AG extraordinaire de l’été 2018, a fortiori car à cette époque, personne n’est véritablement en maîtrise des accès à l’infrastructure. Ils sont donnés de la main à la main, sans trace nette, et ne sont jamais révoqués, même pas après que le départ des membres. L’idée que cette situation est problématique fait consensus. Parmi les options pour y remédier, la désignation d’une personne qui centralise la gestion des accès à l’infrastructure. C’est la solution retenue et de nouveaux statuts sont rédigés dans ce sens.

Le Responsable technique est responsable de la gestion de l’équipe technique et des accès à l’infrastructure de Picasoft. C’est la personne qui est apte à donner ou retirer les accès aux différents bénévoles de l’équipe technique. De plus le Responsable technique s’assure que l’infrastructure de Picasoft est correctement maintenue dans le temps.

C’est à ce moment de l’histoire que la péripétie principale entre en piste (bruits de roulement de tambour).

Une mayonnaise qui ne prend pas

On a testé pour vous : mélanger bureaucratie sécuritaire et fluidité artisanale, puis secouer très fort. Eh bien, ne refaites pas ça chez vous : ça explose. Prenons un peu de recul et mettons-nous en quête du ver dans la pomme.

 

D’un côté, le rôle de responsable technique est très inconfortable. Mettez-vous en condition : vous êtes seul·e responsable de la distribution des accès. Grand pouvoir, grandes responsabilités, tout ça. Une seule erreur de votre part et l’image publique de Picasoft part en lambeaux, la confiance avec. Une mise à jour de sécurité oubliée, un compte de bénévole piraté, une machine et ses données inondées : vous êtes techniquement responsable. Votre obsession devient dès lors la réduction systématique de la surface d’attaque de l’infrastructure. Pour autant, trancher entre « avoir accès » et « ne pas avoir accès » est trop binaire ; un membre pourrait avoir des droits d’édition sur la documentation sans pouvoir supprimer la base de données de Mattermost. Vous appliquez naturellement le très classique principe de moindre privilège (principle of least privilege en anglais). Chacun·e ne doit pouvoir faire que ce dont iel a strictement besoin, et pas plus. Autrement dit, la compromission des accès d’un·e membre ou ses maladresses ont un impact limité à ses privilèges — un compte de wiki ne pourra jamais supprimer les données de Mattermost. La question épineuse, en tant que responsable technique, est de définir les contours du besoin de chaque membre. Bien entendu, vous pourriez faire confiance et considérer que chacun·e demande les accès dont il a besoin. Mais c’est vous qui portez cette lourde responsabilité ; c’est vous qui connaissez les risques. Alors à défaut de sombrer dans la folie, vous préparez des procédures standardisées et un examen minutieux des demandes d’accès. Pas de sécurité sans ordre.

Maintenant, changement de costume. Vous êtes membre de Picasoft, enthousiaste et plein·e de vie. Vous aimez son fonctionnement artisanal et les projets spontanés qui en émergent. Pour vous, pas de doute : on se forme en faisant, et surtout en faisant des erreurs. C’est d’ailleurs aussi pour vous former que vous avez rejoint le navire. Alors, vous faites de votre mieux. Parfois vous cassez quelque chose, vous pleurez en vous demandant pourquoi vous n’avez pas choisi le maraîchage, puis, après vous être fait une raison, vous réparez du mieux que vous pouvez. Vous en sortez grandi. D’ailleurs, ces temps-ci, personne ne s’occupe de la maintenance des services — il faut dire que c’est un peu rébarbatif. Pas facile de se motiver. Mais aujourd’hui, après votre meilleur chocolat chaud, vous vous sentez en pleine forme. Time to upgrade. Vous enfilez votre plus beau hoodie, et quand vient minuit, vous vous lancez. Sur l’écran, les commandes se succèdent au rythme effréné de vos frappes. Les tests sont impeccables, la conclusion implacable : plus qu’à mettre en production et aller vous coucher. Mais au moment de lancer la dernière commande, un message s’affiche : permission denied. Accès refusé. Incrédule, vous essayez à nouveau, comme on tente d’ouvrir une porte qu’on sait fermement verrouillée. Il faut vous rendre à l’évidence, impossible de faire quoi que ce soit : on ne négocie pas plus avec les ordinateurs qu’avec les portes. Frustré·e, votre motivation tombe à plat. Vous rallumez la lumière et vous partagez votre malheureuse aventure au reste de l’équipe technique, avant d’aller vous rouler en boule sous votre couette.

Le lendemain matin, la réponse manque de vous faire tomber de votre chaise : ce refus n’est pas une erreur, bien au contraire : vous n’aviez pas besoin a priori de ces accès. Question de surface d’attaque. Si vous avez pour projet de faire la maintenance des services, pas de soucis : prévenez un peu avant et on vous donnera les accès nécessaires. Question de sécurité. Vous ne voudriez pas mettre à mal la confiance des gens, n’est-ce-pas ? Et puis c’est quand même pas grand-chose, de demander des accès. On ne vous interdit rien, on fait juste de la prévention. Pas de quoi en faire un plat.

Dernier tour de veste : vous êtes franchement arrivé·e dans l’équipe technique, et motivé·e comme jamais pour monter un nouveau service. On s’y met ? Eh ien, j’espère que vous avez du temps devant vous. Car avec le raisonnement qui précède, chaque étape (test, partage, déploiement, gestion des sauvegardes, communication…) nécessite des accès différents, et autant de potentielles discussions et argumentations sur votre légitimité à briguer ces accès. Légitimité dont l’appréciation revient en dernière instance au/à la responsable technique.

J’espère que cette mise en situation, quoique caricaturale, donne une bonne intuition des tensions qui macèrent pendant cette année. D’un côté, une responsabilité forte et mal définie qui repose sur une seule personne ; de l’autre, des membres de bonne volonté qui perdent leur autonomie et dont les actions sont sous contrôle.

Libre ou open source ?

À l’été 2019, le semestre se clôt par une assemblée générale électrique. Les tensions accumulées appellent un changement radical, c’est-à-dire un changement qui prend le problème à la racine. Or ces tensions ne sont que des manifestations d’un problème plus fondamental. La boîte de Pandore est ouverte.

Le procès verbal de l’AG donne quelques exemples de dissensus qui agitent les membres :

— Picasoft peut-elle être militante ou politique ?
— Picasoft doit-elle se positionner sur des questions éthiques, par exemple pour le choix d’une banque ?
— Qui doit décider de l’attribution des accès à l’infrastructure ? Faut-il privilégier la sécurité ou l’ouverture ?
— La monnaie libre rentre-t-elle dans les prérogatives de l’association ?

Passer à une banque plus dosée en éthique et payer plus cher, donc avoir moins d’argent pour agir, ou rester clients d’une banque bon marché, mais qui finance des projets écocides ? Organiser des événements autour de la monnaie libre, dont l’écosystème est très libriste-compatible, mais qui assume une critique radicale du système économique ?

En sous-texte de toutes ces questions, on retrouve en réalité la question à cent balles : une association d’informatique libre a-t-elle vocation à se positionner politiquement et idéologiquement ? Cette question fera peut-être tiquer certain·es d’entre vous, car elle est mal posée : elle suppose qu’il soit possible d’agir apolitiquement. Or, dans les exemples précédents, ne pas se positionner signifie en réalité adhérer au système dominant. Ne pas choisir une banque qui refuse de soutenir des projets écocides quand on en a les moyens, c’est adhérer, même mollement, à la ruine écologique. Par cette affirmation, je ne cherche à culpabiliser personne. Mais surtout en tant qu’association, c’est-à-dire en tant que personne morale, il est important de réaliser ce que veut vraiment dire rester apolitique. Ce qui ne veut pas dire que c’est une posture indéfendable.

 

Dans notre milieu, cette question prend la forme de la vieille dispute open source versus libre. Ce débat est resté relativement confidentiel, bien que la mainmise d’Amazon, Google ou Microsoft sur des outils open-source contribue à amplifier les voix qui s’élèvent contre l’open source. Je vous en propose un résumé à la hache. Open source et libre partagent les mêmes libertés fondamentales, exprimées par des licences qui ont valeur de contrat. Ces quatre libertés ne sont plus à présenter : droit d’utiliser, d’étudier, de modifier et de redistribuer.

Les tenants de l’open source s’intéressent particulièrement à la sécurité et à la performance : par exemple, l’ouverture du code d’un logiciel au plus grand nombre permet de détecter les failles plus rapidement. Aussi, les efforts des développeur·ses pourront se concentrer en un seul point plutôt que d’être gaspillés pour développer dix fois le même logiciel (competitive waste). Dans l’open source, l’accent est mis sur la liberté absolue : on ne vous donne que des droits mais aucun devoir. L’exemple typique est la licence MIT, qui dit en substance : faites ce que vous voulez. Vous pouvez donc faire de l’open source tout en créant un écosystème qui utilise tous les leviers pour rendre vos utilisateurs captifs d’outils qui, par ailleurs, ne sont pas libres³.

En miroir, le mouvement du libre a pour vocation de créer des communs. Un commun ne peut pas être approprié par une personne qui en tirerait du profit sans contrepartie. Cette vision des communs prône l’absolue liberté. L’exemple typique serait alors la licence GPL, qui est contagieuse : si vous utilisez un programme sous licence GPL comme base d’un autre programme, celui-ci devra également être sous licence GPL ou équivalent. De la sorte, vous rendez à la communauté ce qu’elle vous a donné. Cette contrainte ne contredit pas les 4 libertés fondamentales, mais porte en elle une vision marquée de l’intérêt général : il ne saurait être optimisé par une liberté totale, bien au contraire. Pour le dire en peu de mots, le libre est anti-libéral.

Pour clarifier cette affirmation un peu provocatrice, il est intéressant de s’attarder sur Eric S. Raymond, un défenseur emblématique de l’open source. Il est notamment l’auteur de la Cathédrale et le Bazar, un essai populaire qui théorise différents modes de développement de logiciels open source. Dans une réponse à une critique, il clarifie son positionnement idéologique :

In fact, I find the imputation of Marxism deeply and personally offensive as well as untrue. While I have made a point of not gratuitously waving my politics around in my papers, it is no secret in the open-source world that I am a libertarian, a friend of the free market, and implacably hostile to all forms of Marxism and socialism (which I regard as coequal in evil with Nazism).

Ce qui, traduit relativement fidèlement, donne ceci (tenez-vous bien) :

En fait, je trouve l’imputation de marxisme [à cet essai] profondément et personnellement offensante et inexacte. Même si j’ai toujours mis un point d’honneur à ne pas étaler mes convictions politiques dans mes articles [de recherche], ce n’est un secret pour personne dans le monde de l’open source que je suis libertarien favorable au libre marché et implacablement hostile à toutes formes de marxisme et de socialisme (que je considère comme aussi dangereux que le nazisme).

Là encore, l’exemple est caricatural, mais donne une intuition correcte du conflit. La parenthèse étant fermée, il était évident qu’une remise en cause de l’identité profonde de l’association ne pouvait pas être résolue en quelques heures.

L’AG vote alors pour le compromis suivant : le bureau proposé est élu, mais à la condition qu’il organise une journée de réflexion qui devra aboutir à des propositions concrètes pour trancher ces questions. Le bureau signe le mandat, l’AG est close. Les vacances peuvent enfin aérer les esprits.

Haïssez le jeu, pas les joueurs

À l’automne 2019, le premier Picacamp est organisé. Pas du tout inspiré du Framacamp (comme rien n’est inspiré de Framasoft d’ailleurs), une équipe de choc de — tenez-vous bien — quatre bénévoles se réunit à cette occasion.

Quatre, c’est peu. Trop peu pour décider de l’orientation idéologique de Picasoft. Sautons directement à la conclusion de cette journée : le problème n’est pas là. Il est encore plus profond. Décider d’une posture politique ne changera rien, car c’est le mode de gouvernance même de Picasoft qui est en cause.

En d’autres termes, ce qui s’est passé n’est pas un problème de personnes : certes, l’asso aurait pu continuer à rouler quelques semestres avec une bande de potes très complices, mais ses règles de fonctionnement étaient propices à faire émerger ce genre de tensions. Comme le rappelle le mathématicien et vulgarisateur Lê Nguyên Hoang dans son excellente série de vidéos sur la démocratie, il faut haïr le jeu, pas les joueurs.

En d’autres termes, les règles du jeu — ici les statuts — déterminent très majoritairement les comportements des joueurs, sur le long terme et à l’échelle globale. Une intuition de cette idée est que toutes les personnes qui jouent au Monopoly ne sont pas d’affreux·ses capitalistes ; de même, tout·es les responsables techniques ne sont pas d’affreux·ses autoritaires. Pourtant, les règles du jeu les incitent à se comporter comme tel·les.

Mais alors, si mon analyse se tient, pourquoi est-ce-que ce genre de conflits n’est pas arrivé à Rhizome, puisque les statuts de Picasoft sont peu ou prou les mêmes ? J’ai posé cette question à Kyâne — qui a adapté les statuts de Rhizome pour Picasoft. L’explication tient en ce que chez Rhizome, les modalités d’implication sont très différentes. D’un côté, il y a les abonné·es, celleux qui louent un accès à Internet, et qui votent en AG. De l’autre côté, il y a celleux qui font, qui mettent les mains dans le cambouis. Il y a peu de bras : les personnes motivées sont plus que bienvenues. Le format « pouvoir à l’AG et petit bureau qui mène les affaires », dixit Kyâne, fonctionne bien.

Mais chez Picasoft, les utilisateur·ices ne sont pas membres. Les membres, c’est un groupe hétéroclite fait de sympathisant·es, de bonnes volontés qui donnent parfois un coup de main, de motivé·es qui passent leurs nuits à déboguer, de personnes qui aiment aller en conventions, de curieux·ses timides qu’on ne voit jamais. Ce spectre de participation ne peut pas être correctement représenté par un bureau qui fait autorité.

À bien y réfléchir, l’entité même de bureau n’a plus de sens quand on lui ôte la fonction qu’elle avait chez Rhizome. C’est un archétype, un cliché, un spectre qui hante le monde associatif. C’est le modèle auquel nous sommes le plus exposés, des associations aux entreprises cotées en bourse en passant par notre démocratie représentative. Aussi, une recherche de modèle de statuts sur Internet a peu de chances de donner idée d’un autre système. C’est ainsi que la bureau-cratie et ses pièges se reproduisent en infrabasses.

La conclusion est sans appel : la gouvernance de l’association doit être intégralement repensée pour permettre l’inclusion de chaque membre et la répartition des responsabilités.

Les pièges de l’horizontalité

J’espère vous avoir convaincu⋅e, à ce stade, qu’un mode de gouvernance plus horizontal est nécessaire. Mais avec horizontal, on a tout et rien dit. On comprend bien qu’on l’oppose à une gouvernance verticale, hiérarchique, et on y perçoit des velléités d’inclusion et de participation. Mais l’horizontalité est du même genre que la bienveillance, l’inclusion ou l’agilité, à savoir un vernis qui part bien vite sans actes concrets.

Une première approche serait prendre l’idée de bureau à contre-pied et de soumettre l’ensemble des décisions au vote. De la sorte, chaque décision représente l’association dans sa majorité. Le problème évident de cette approche est que toute initiative est bloquante jusqu’à participation des membres. Or tout le monde est toujours occupé ; se tenir au courant des tenants et aboutissants de l’ensemble de la vie d’une association est coûteux ; donner son avis sur tout est encore plus difficile⁴. De plus, ce système charge les personnes motivées : elles doivent convaincre tou·tes les membres et aller quémander des voix. Ce système produit facilement du découragement et il est hostile aux initiatives originales. Il pousse à un fonctionnement plutôt conservateur.

Une approche orthogonale serait d’instaurer une do-ocratie : en gros, les personnes qui font ont le pouvoir. La do-ocratie est séduisante car les personnes motivées ne sont pas empêchées de faire, mais ne sont pas non plus statutairement tributaires de l’autorité. Il suffit de s’impliquer activement pour avoir son mot à dire. C’est d’ailleurs le mode informel qu’adoptent de nombreuses structures, où « déjà qu’il y a pas beaucoup personne pour faire les trucs chiants, si en plus on les emmerde, y’aura vraiment plus personne ».

Cependant, ce système est problématique à deux égards. D’abord, à y regarder de plus près, c’est virtuellement le même système que celui des premiers statuts. En effet, chez Rhizome, ce sont ceux qui font qui se présentent pour constituer un bureau, à qui l’AG confie la gestion quotidienne. À Picasoft, donc, ce sont généralement les personnes qui s’investissaient le plus à un moment donné qui se retrouvent membres du bureau, et confisquent involontairement le pouvoir aux autres membres.

Mais ce système fait pire encore : il déstructure le mode de gouvernance. Il ne donne aucun moyen de résoudre les conflits entre les doers, i.e. celles et ceux qui s’impliquent. Mais qui fait, et qui ne fait pas ? Où est la limite ? Qui est légitime et aux yeux de qui ? Comment s’assurer que ce n’est pas à celui qui gueule le plus fort ? À bien y regarder, ce système simpliste s’identifie à la caricature classique de l’anarchisme, qui voudrait que la loi du plus fort soit le seul principe qui tienne. C’est au fond l’idée nauséabonde du darwinisme social : briser tout cadre qui pourrait gêner la compétition, dont sortiront vainqueur·es les plus aptes. Si l’on s’en fie à cette idée, toute association sans structure devrait un jour arriver à son fonctionnement optimal. Ça vous rappelle quelque chose ?

Sans transition, l’article de blog du chaton deuxfleurs au sujet de l’autogestion est particulièrement éclairant. Je vais en paraphraser une partie (peut-être mal, alors foncez le lire!). Il s’attarde sur un texte de Jo Freeman, une avocate, politologue et militante féministe américaine. Intitulé « La tyrannie de l’absence de structure », elle le prononce en 1970 devant des militant·es féministes. On peut en trouver une traduction en français sur Infokiosques.

Ce texte s’adresse aux « groupes sans leader ni structure » du Mouvement de Libération des Femmes étatsunien. Jo Freeman remarque que l’absence de structure est « passée du stade de saine contre-tendance à celui d’idée allant de soi ».

Lors de la gestation du mouvement, le caractère détendu et informel qui régissait [le groupe de conscientisation] était propice à la participation aux discussions, et le climat de soutien mutuel qui se créait en général permettait une meilleure expression des visions personnelles. [Des problèmes surgirent lorsque] les petits groupes d’action épuisèrent les vertus de la conscientisation et décidèrent qu’ils voulaient faire quelque chose de plus concret.

Assez de contexte : pourquoi est-ce-que l’absence de structure ne fonctionne pas ? Jo Freeman est claire : parce que l’absence de structure n’existe pas. Nos différences interpersonnelles, nos intentions, la distribution des tâches — qu’elle soit équitable ou injuste — est de fait une structure, au même titre que ne pas se positionner est un positionnement et l’apolitisme n’existe pas. Il est seulement possible de choisir la nature de la structure : formelle ou informelle.

Lorsque la structure est intégralement informelle, deux phénomènes peuvent se produire : la formation d’élites et de stars.

Une élite est un petit groupe de gens qui domine un autre groupe plus grand […], et qui agit fréquemment sans son consentement ou sa connaissance.

Une élite, ce n’est pas une conspiration de méchants de film. Ce peut être ce groupe de bons potes au sein d’un mouvement, qui boit des coups au bar et y discute du mouvement. L’élite échange en son sein plus d’information que n’en reçoit le reste du groupe. Elle peut faire bloc pour pousser telle ou telle orientation, dans des discussions déséquilibrées d’avance. C’est moins par malveillance que par contingence que les élites se forment : leur activité politique et leur amitié coïncident. C’est aussi ce qui rend difficile leur dissolution, car l’élite ne commet pas de faute fondamentale. Elle s’entretient par affinité, et comme gagner la confiance de l’élite existante est difficile et nécessite d’intégrer ses codes, elle est sujette à une certaine homogamie.

Quant aux stars, ce sont des personnes qui sont mises en avant au sein du groupe, voire qui le représente dans l’inconscient collectif. Mais au sens de Freeman, elle n’ont pas été désignées explicitement. Une personne charismatique qui s’exprime bien prendra souvent plus de place. En plus de favoriser les normes dominantes, le « statut » de star n’est pas révocable dans la mesure où il n’a été attribué par personne. La star, comme l’élite, est rarement consciente de son statut. Les critiques légitimes qu’elle reçoit peuvent être vécues violemment et la conduire à quitter le groupe, et par là même, le fragiliser.

Pour lutter contre l’émergence d’élites et de stars, Jo Freeman propose 7 principes pour formaliser la structure d’un mouvement de sorte à faire émerger une horizontalité inclusive et politiquement efficace :

1. Assigner démocratiquement des tâches précises à des personnes concrètes, qui ont préférablement manifesté leur intérêt.
2. Assurer que toute personne qui exerce une autorité le fasse sous le contrôle du groupe.
3. Distribuer l’autorité au plus grand nombre de personnes raisonnablement possible.
4. Faire tourner les postes ; pas trop souvent (pour avoir le temps d’apprendre), pas trop peu (pour ne pas créer d’élite).
5. Rationaliser les critères d’assignation des tâches, par compétence plutôt que par sympathie.
6. Diffuser l’information au plus grand nombre, le plus possible. L’information, c’est le pouvoir.
7. Rendre accessibles les ressources de manière équitable (un local, du matériel, des identifiants…)

Ce billet tirant déjà en longueur, je vous laisse vous convaincre de la pertinence des propositions, et à la lumière de cette analyse, je vous propose de passer à l’examen de la tout-doux-cratie. 😙

Bienvenue en tout-doux-cratie

La tout-doux-cratie est le mode de gouvernance qui émerge pendant le Picacamp. Il est forgé selon trois principes :

• Faire et laisser faire (permettre à Picasoft d’être un lieu où chacun·e peut agir) ;
• Se préoccuper des opinions des autres membres (partager l’information, s’informer)
•  Rechercher le consensus (accepter les compromis, être amical·e et favoriser la vie ensemble).

Tout système de gouvernance s’ancre sur des partis pris adaptés au contexte dans lequel il se déploie. Pour Picasoft, on l’a vu, il y a un véritable enjeu à faciliter l’action des personnes motivées sans écraser les autres ; c’est pourquoi le nom dénote la fluidité (to-do) et le soin (tout-doux). L’intention du système de règles lui-même est d’être suffisamment simple pour être intégré rapidement (fluidité) mais suffisamment robuste pour être mis à l’épreuve dans les cas difficiles (soin).

Voyons très concrètement comment ça se passe⁵. Tout membre peut engager des actions, séparées en deux catégories.

• Une action ordinaire ressemble aux actions habituelles menées dans le cadre de l’Association. Le règlement intérieur contient une tout-doux-liste qui aide à déterminer si une action est ordinaire.
• Une action extraordinaire n’est pas habituelle dans le cadre et l’historique de l’Association, en particulier lorsqu’elle n’est pas réversible.

Certaines actions (modification du règlement intérieur, exclusion d’un membre, dissolution de l’association…) sont statutairement extraordinaires. En cas de doute ou de cas limite, l’action extraordinaire est préférée. Le mode de décision collectif diffère en fonction de l’action.

Une action ordinaire peut être lancée sans accord préalable, à partir du moment où la personne informe les membres de l’association de son action. Tout membre a la possibilité de suspendre l’action en posant un verrou non-bloquant : il lui faut alors convaincre une majorité des membres que l’action doit être annulée. S’il n’y parvient pas, l’action est maintenue.

Une action extraordinaire est associée à un verrou bloquant par défaut : l’action peut être réalisée uniquement si une majorité de membres y sont favorables, ou si dix jours se sont écoulés sans qu’une majorité des membres n’y soient défavorables.

Voici un petit résumé graphique pour tenter de rendre le processus plus tangible.

Pour lire la version vraiment formalisée du processus de décision en tout-doux-cratie, direction les statuts : https://wiki.picasoft.net/lib/exe/fetch.php?media=administratif:status-picasoft_p20.pdf

Si ce fonctionnement peut paraître alambiqué, il provient du raisonnement suivant :

1. L’horizontalité par consensus à majorité absolue ne fonctionne pas ;
2. Le « laisser-faire sauf en cas de véto » donne un pouvoir disproportionné à chaque membre, en tant qu’il peut empêcher l’action d’un autre membre seul et pour de mauvaises raisons (détruire est plus facile que construire) ;
3. La charge doit alors peser sur la personne qui est contre ; elle devra prouver que l’action doit être annulée en sollicitant un rejet collectif. Si elle n’y parvient pas, alors l’action est légitime à être menée.

Ce raisonnement a des accents conflictuels qui semblent bien loin du tout-doux. C’est pourquoi la tout-doux-cratie n’utilise pas ce mécanisme en fonctionnement nominal. En première instance, la recherche du consensus et la discussion sont les modes d’interaction privilégiés. Le vote agit généralement comme une chambre d’enregistrement. En d’autres termes, un membre qui a connaissance d’un dissensus devrait d’abord informer et, le cas échéant, chercher le compromis avant de lancer une action ordinaire ou extraordinaire. Si le dissensus persiste, le vote permettra de rendre compte de l’opinion générale des membres, tout en préservant la personne agissante d’une trop grande charge mentale.

De ce fonctionnement découle naturellement l’abolition du bureau. L’association ayant toujours besoin de personnes pour la représenter (juridiquement, économiquement…), trois personnes sont élues chaque semestre pour constituer un genre de spectre de bureau :

• Un·e représentant·e administratif, qui doit lever la main quand quelqu’un demande le·la président·e et qui signe tous les documents administratifs concernant Picasoft ;
• Un·e représentant·e financie·re, qui effectue les opérations bancaires ;
• Un·e représentant·e technique, qui distribue les accès aux machines.

Chaque représentant·e est la seule personne en capacité de réaliser ces actions ou de les déléguer. En revanche, la différence majeure avec l’ancien bureau est que les représentant·es n’ont aucun pouvoir décisionnaire ; iels exécutent simplement les décisions de l’association.

Dans la mesure où leurs actions peuvent engager leur responsabilité, iels disposent d’un droit de retrait, c’est-à-dire de la possibilité de démissionner sans aucune justification en cas de refus d’exécuter une action. Là aussi, ce droit de retrait correspond à la dernière alternative et n’a en pratique jamais été utilisé.

Enfin, la tout-doux-cratie a été conçue pour fonctionner correctement même en système ouvert, c’est-à-dire que devient membre toute personne qui en fait la demande. Si la plupart des associations fonctionnent par cooptation, Picasoft est une association dont les membres tournent beaucoup et qui a besoin de maintenir ses effectifs. Rendre l’adhésion peu coûteuse en temps et gratuite incite plus facilement à tenter l’expérience. C’est sans danger, car l’arrivée d’un·e nouveau·elle ne peut pas bouleverser l’association du fait du mode de décision : si cette nouvelle personne se trouve en opposition avec le reste des membres, elle ne sera pas en mesure de bloquer les décisions, quel que soit son poste. Enfin, si sa présence est réellement problématique, son exclusion peut être décidée par action extraordinaire.

Être membre implique cependant un nombre minimal d’obligations définies dans les statuts.

• Agir conformément à l’objet de l’Association ;
• Aider les autres à agir ;
• Participer au processus de tout-doux-cratie, c’est-à-dire donner son avis lorsqu’il est demandé, voter, rester informé·e et participer aux AG.

En pratique, seul la dernière obligation est cruciale, capitale, essentielle, indispensable, vitale, critique ; bref, vous l’aurez compris, faut pas passer à côté. Car pour bien fonctionner, la tout-doux-cratie a besoin de l’opinion de ses membres : sans prendre le temps de s’informer, on peut se lancer dans des actions conflictuelles. Sans voter, on allonge le délai de réalisation des actions extraordinaires et on démotive ses auteur·ices. Sans participer aux discussions, on perd le lien et la dynamique qui animent Picasoft.

En définitive, ce sont la circulation horizontale de l’information et la participation active aux décisions qui forment les clés de voûte d’une tout-doux-cratie saine.

Gardez de la place pour le dessert

Nous arrivons tranquillement à la fin du premier chapitre de cette enquête. Vous l’aurez compris, Picasoft fonctionne depuis plus de deux ans en tout-doux-cratie. Ce mode de gouvernance n’a rien de révolutionnaire. Au contraire, il s’appuie sur des idées théorisées depuis plusieurs décennies et qui structurent nombre de collectifs militants, plus ou moins informellement. On lui a donné un nom car on aime bien les jeux de mots mignons, et qu’on peut en parler plus facilement, voilà tout. ✨

Pour autant, si la critique de la bureau-cratie est facile et que j’ai présenté la tout-doux-cratie sous son meilleur jour, à ce stade, il vous manque cruellement de passage à la pratique à vous mettre sous la dent. Et l’occasion, inévitable, de relever les failles de ce système. Mais ça… ce sera pour la seconde et dernière partie de ce billet, par ici : https://framablog.org/2022/10/24/deux-ans-en-tout-doux-cratie-bilan-et-perspectives/ 😄

 

Un grand merci à Antoine, Audrey, Gaëtan, Jérôme, Stph, R01, Tobias, et tout·es les membres de Picasoft et de Framasoft pour leurs contributions, relecture, corrections et leur accueil bienveillants!

---

1. https://www.associations.gouv.fr/1001-redaction-statuts-association.html ↩︎
2. En effet, l’idée qu’il est normal que les services et contenus soit disponibles partout et tout le temps est largement et sciemment véhiculée par l’imaginaire du « Cloud », des nuages. La très haute disponibilité est par ailleurs un sujet de recherche actif. L’idée de diminuer la disponibilité d’un service rencontre des résistances similaires à l’idée de « décroissance », parfois vécue comme une régression. Pourtant, il y a de quoi s’interroger sur la disponibilité totale, mais c’est un autre sujet. Ne pas jouer le jeu du Cloud, c’est donc ne pas se fixer un objectif de disponibilité, mais en restant prudent pour ne pas se marginaliser. ↩︎
3. Les mécanismes par lesquels l’open-source devient un puissant outil de domination politique et économique sont passionnants, même si largement au-delà du sujet principal de ce billet. Néanmoins, pour les anglophones, cet article récemment paru sur l’éditeur de code open-source Visual Studio Code, développé par Microsoft, est édifiant : https://ghuntley.com/fracture. ↩︎
4. D’ailleurs, il est vraisemblable qu’avoir un avis sur tout n’est pas souhaitable. Un système qui oblige à prendre chaque décision à la majorité sera soit démesurément inefficace (car lent), soit irréfléchi (car la plupart des votes seront au doigt mouillé). C’est un raccourci que je me permets de faire dans cet espace plus confidentiel des notes de bas de page. On peut légitimement objecter que la lenteur n’est pas un problème en soi, et que des modes de gouvernance l’assument, et même plus, la revendiquent. Voir le cas fascinant des zapatistes : https://hal.archives-ouvertes.fr/hal-02567515/document ↩︎
5. Les curieux·ses trouveront la formalisation dans nos statuts et notre règlement intérieur. ↩︎