À la manière du test de Beshdel (qui permet en trois critères de mettre en lumière la sous-représentation des femmes et la sur-représentation des hommes dans des films), nous vous proposons un nouvel outil pour dénicher les embuscades tendues par l’autogestion-washing, en toute simplicité : « le test de l’Autogestion ».
Il nous semble plus que nécessaire dans le contexte actuel. En effet, utiliser des mots à tord et à travers, et les détourner de leur sens pour récupérer ceux qui y sont attachés est devenu si courant que l’on peine parfois à trouver des mots qui ne portent pas à confusion ou qui ne servent pas un discours de communicants. L’autogestion n’échappe pas à la règle au point que l’on peut désormais parler d’autogestion-washing. Que le processus soit conscient ou le fruit de l’ignorance. Il nous semblait donc important de proposer un outil simple et efficace permettant de faire le tri dans la majorité des cas.
Le test de l’Autogestion
Trois critères :
- Pas d’AGs ;
- Pas de salarié ;
- Pas de gestion informatisée.
Le projet ne respecte pas les trois critères ? Le collectif ou l’organisme n’est pas autogéré.
Il les coche tous ? C’est prometteur, vous tenez peut être là une initiative sans donneur d’ordre individuel ni collectif, humain comme machine ! Attention, le test de l’autogestion élimine la plupart des faux prétendants au titre. Il n’est pas une garantie à 100% d’un modèle autogéré, il faudra pousser l’analyse plus loin. Comme le test de Beshdel ne vous garantit pas un film respectant l’égalité femme-homme.
Quelques explications
Pas d’AG
Autogestion et chef apparaissent immédiatement comme contraires. Ce dernier a le pouvoir sur les membres d’autoriser ou interdire, à priori, des initiatives. L’Assemblée Générale est donc par définition un chef collectif. Parfois l’ensemble des membres constitue ce chef collectif mais le plus souvent c’est uniquement un petit groupe qui les organise. Petit groupe qui pré-écrit les délibérations en AG qui restent à valider.
Ce chef, quoique collectif, reste arbitraire. Il dicte ses volonté et ce qui doit être fait et pas fait, interdisant des pratiques et initiatives jugées marginales par une partie du groupe, au détriment du reste.
Les « simples membres » chercheront la validation des responsables et ces derniers pourraient se sentir trahis sans validation demandée. L’AG est un lieu de déresponsabilisation des membres d’un collectif et de sur-responsabilisation de quelques personnes mandatées pour résoudre les problèmes. La pratique des AGs a démontré que les simples membres deviennent attentistes et râleurs. Les mandatés eux, auront une charge mentale élevée.
Ces membres mandatés sont souvent des membres de longue durée dans des groupe de travail permanents (bureau, conseil d’administration, commissions, comité de pilotage, etc). Cela créé à terme des lieux de pouvoir et des déséquilibres d’investissement dans le projet, d’accès à l’information et du nombre de prises de décisions. Cela instaure mécaniquement des membres en responsables et gestionnaires et les autres comme consommateurs pouvant exiger des résultats.
Pas de salarié
L’existence de salarié instaure d’emblée une relation dominant / dominée, contraire au principe d’autogestion.
De plus, le salarié a pour rôle de gérer des pans entiers du projet. Il s’investit plusieurs dizaines d’heures par mois : beaucoup plus que n’importe quel autre membre. Cela crée un déficit d’impact des actions des membres qui sont marginales et un déséquilibre d’information mécanique entre le salarié et les autres membres.
Un salarié n’a pas les mêmes intérêts que les simples membres : sa gestion est d’abord au service du maintien de son poste et ensuite au maintien de la raison d’être de l’initiative.
Pas de gestion informatisée
Les outils informatiques tels qu’ils sont majoritairement conçus organisent les collectifs de manière hiérarchique. Quasi exclusivement nous retrouvons des administrateurs puis des rôles subalternes dont les pouvoirs sont définis et accordés par les premiers (et donc révocables par eux).
C’est d’autant plus problématique qu’un outil gère de nombreux pans de l’organisation. Or un outil informatique est construit pour le grand nombre et n’est jamais adapté aux projets particuliers. Et il ne peut l’être. D’autant plus que la plupart sont la propriété d’un organisme privé qui le conçoit en fonction de ses intérêts. Si la gestion d’un projet se fait au travers d’un seul outil unifié, que se passe-t-il lorsque un aspect ne convient pas et est incontournable ? Le plus souvent l’outil ne s’adapte pas, c’est le fonctionnement du collectif qui s’y adapte. De plus, que se passe-t-il quand le développeur change ses conditions d’utilisation (prix, valeurs, suppression de fonctionnalité, etc.) ? Qu’il signe un partenariat avec des entreprises peu recommandables ou qu’il vend vos données sans votre accord ?
De plus à mesure que se créé une dépendance à un outil il se créé une dépendance aux personnes compétentes (souvent peu nombreuses). Quel pouvoir cela leur donne-t-il ? Que se passe-t-il quand les personnes ne peuvent plus, ne veulent plus et que l’outil n’est plus maintenu ? Dans ces deux cas, le collectif est-il alors en capacité de s’en passer ? Devient-il prisonnier ?
Enfin, derrière ces outils, il y a des gens dont les idées imprègnent ces outils. Ils prennent donc des décisions pour le collectif bien en amont de la création de celui-ci, décisions qui ne pourront presque jamais être remise en cause. Il sort du champs de l’autogestion des composantes entières du fonctionnement du projet.
Évidemment, les épiceries libres passent le test ! 🙂
Pourquoi dites vous « Or un outil informatique est construit pour le grand nombre et n’est jamais adapté aux projets particuliers. Et il ne peut l’être. » ?
Je construit des outils informatique adaptés aux projets particuliers et locaux, comme tout développeur. Au niveau des données, aucune ne doit être recueillie. Vous devriez vous intéresser au logiciel libre, et peut être apprendre à développer (je conseille le php). Un développeur ne choisit pas les idées de l’outil, il fait ce qu’on lui demande de faire grâce à un dialogue qui identifie les besoins précisément.
Bonjour Georges,
théoriquement chaque collectif pourrait se faire développer un logiciel pile poil selon ses besoins.
Dans la pratique les collectifs sont relativement petits et n’ont pas les moyens financiers de payer quelqu’un pour développer ce logiciel ni l’envie d’y attribuer un budget.
La quasi-totalité des collectifs se tournent alors vers des solutions existantes qui visent à satisfaire une demande assez large et qui ne seront donc pas adaptés aux choix précis du collectif (par exemple MonEpi).
Il y a toujours des exceptions, par exemple des collectifs qui ont eu des développeurs en leur sein qui ont mis construit bénévolement une plateforme. Ce que l’on peut remarquer, c’est que ensuite, pour rentabiliser l’exercice ces développeurs ont mis à disposition d’autres collectifs leur solution informatique et qu’un business modèle est construit autour de ça (voir à nouveau monepi ou la cagette) et que ces logiciels ne seront pas adaptés aux besoins de ces autres collectifs ou petit à petit. Ici la solution a été développé pour un cas particulier et mis à disposition.
Donc pour résumer :
– les collectifs n’ont pas les moyens de se payer la création d’un logiciel ni d’en faire adapter un, sans parler de le faire évoluer avec les pratiques.
– ils ont donc recours à des solutions toutes faites qui ne seront pas adaptées à leurs besoins spécifiques.
Dans la grande majorité des cas donc l’informatique contraint à fonctionner d’une manière, à la manière du collectif pour lequel la solution a été pensée.
—
Petite paranthèse sur les lacunes du monde libriste sur un sujet : les logiciels libres ne prennent que très peu en compte les logiques de pouvoir que les outils numériques créaient au sein des collectifs. Par exemple : je fais un logiciel où il y a des administrateurs qui peuvent casser tout et qui ne permettent pas aux rôles subalternes de reprendre la main et « revenir en arrière ». « Cagette » qui permet de gérer des amaps, groupements d’achat ou autre est médiocre à cet endroit qui pour nous est capital. Cela cristallise des craintes, réduit les gens à qui ont donne des accès, etc. Bref, sans le vouloir on hiérarchise, cloisonne. En bonne pratique on pourrait citer framapad qui permet de garder la confiance sur la rédaction d’un texte en commun car il permet le retour en arrière, car il ne créait pas des pouvoirs en fait.
ps : pour me situer, j’ai quelques bases de programmation, voir un peu plus, je l’enseigne à l’université. Ce qui ne m’empêchera pas de dire des âneries mais juste pour signaler que c’est un parti pris réfléchi et pas en passant vite fait comme tu semblais le penser 🙂
Bonjour,
Merci pour les explications détaillées sur les problèmes que pose l’outil informatique, ce point m’avait également surpris et j’ai trouvé ces explications très utiles!
Je suis moi aussi développeur et j’aurais sûrement tendance à vouloir proposer des solutions pour aider tout le monde… Maintenant je vois mieux la beauté de la simplicité en toutes choses.
Merci pour ces informations précieuses!