Manuel opérationnel
Télécharger ce modèle
Généré le 2026-08-31 · Télécharger tous les modèles
Processus opérationnels essentiels
Which things have to keep happening every week — and are they written down anywhere?
Clauses RCOS 7.3.4, 7.7.2, 7.6.3
- 7.3.4 Les processus opérationnels critiques DOIVENT être documentés de telle sorte que la continuité ne dépende pas de connaissances tacites détenues par des individus spécifiques.
- 7.7.2 Les processus opérationnels critiques NE DOIVENT PAS reposer uniquement sur la mémoire individuelle, la bonne volonté ou la transmission informelle.
- 7.6.3 Le Manuel opérationnel DOIT définir, au minimum :
Pourquoi documenter les processus critiques ?
Si un processus n'existe que dans la tête d'une seule personne, la communauté dépend de la présence de cette personne — indéfiniment. Mettre par écrit les processus critiques, avec des responsables nommés, c'est ce qui transforme un savoir privé en un bien commun capable de survivre aux passations, aux absences et aux départs.
Comment remplir cette section
Pour chaque processus critique récurrent (intégration, départ, publication de propositions, enregistrement des contributions, cadence des réunions, gestion de la trésorerie, revue des accès aux plateformes), nomme un·e responsable et fournis une brève description.
| Processus | Qui | Détail |
|---|---|---|
| <Intégration des membres> | <rôle> | <voir Protocole d'intégration (Couche 1)> |
| <Départ des membres> | <rôle> | <voir Protocole de départ et séparation (Couche 1)> |
| <Publication des propositions> | <rôle> | <voir Protocole de gouvernance (Couche 2)> |
| <Enregistrement des contributions> | <rôle> | <voir Protocole d'économie interne (Couche 3)> |
| <Réunion récurrente> | <facilitateur·rice> | <publication de l'ordre du jour ; notes ; suivi des actions> |
| <Gestion de la trésorerie> | <intendant·e finances> | <voir Règles de trésorerie (Couche 3)> |
| <Revue des accès aux plateformes> | <intendant·e infrastructure> | <cadence de revue ; révocation des accès pour les membres sortis> |
Ce qu’il faut couvrir
- Which processes have to keep happening for the community to work — onboarding, exit, publishing proposals, recording contributions, running meetings, managing money, reviewing platform access, and anything else?
- For each process: which role owns it, and what does it involve in two or three sentences?
- For each process: where are the steps written down, so someone new could carry it out without asking the person who usually does it? (Where our documents live in general is its own question.)
- Which of these still depends on one person's memory or goodwill — and who will write it up, by when?
- How do we keep each written process up to date when the way we actually do it changes? (Handoffs between roles are their own question.)
Exemples
Our core processes are member onboarding and member exit (Membership Admin, following those protocols), proposal publication (Governance Secretary), contribution recording (Contribution Steward), the weekly meeting (rotating facilitator: agenda, notes, action list), treasury management (Finance Steward) and platform access review (Infrastructure Steward, monthly, removing exited members). Each has a one-page checklist in the shared handbook that a new role holder can follow without help, and the owner updates it within a week of any change in practice.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Responsabilités temporaires et ponctuelles
How do we stop a temporary favour becoming somebody's permanent unpaid job?
Clauses RCOS 7.1.5, 7.1.4, 7.7.1
- 7.1.5 Les responsabilités temporaires ou ponctuelles DOIVENT être explicitement limitées dans le temps et NE DOIVENT PAS devenir continues sans une définition formelle de rôle.
- 7.1.4 Aucune responsabilité continue NE PEUT exister sans un rôle explicite, et aucune personne NE PEUT être tenue responsable de responsabilités qui ne sont pas formellement assignées à un rôle.
- 7.7.1 Les responsabilités continues NE DOIVENT PAS exister sans un rôle explicite.
Pourquoi limiter les responsabilités temporaires dans le temps ?
Les tâches ponctuelles se transforment silencieusement en postes permanents non rémunérés — généralement portés par la personne qui a dit oui une fois. Une durée maximale stricte et une revue obligatoire font la différence entre « j'ai assuré le relais pendant une semaine » et « apparemment c'est mon rôle maintenant. »
Comment remplir cette section
Indique que toute responsabilité temporaire DOIT être limitée dans le temps dès son attribution, documentée, revue avant expiration, puis soit formalisée soit clôturée.
Lorsqu'une tâche ou une responsabilité est attribuée temporairement, elle DOIT être :
- <Explicitement limitée dans le temps dès le départ (date de fin spécifique ou condition d'achèvement).>
- <Documentée comme temporaire au moment de l'attribution.>
- <Revue avant la date de fin ; convertie en rôle formel ou clôturée.>
<Durée maximale de toute responsabilité temporaire avant qu'elle ne DOIVE être formellement attribuée ou clôturée — p. ex. 90 jours.> Si une responsabilité temporaire n'a plus de titulaire après sa date de fin, elle expire ; elle ne se transfère pas implicitement.
Ce qu’il faut couvrir
- When someone takes on a temporary task, how is its end set — a date, or a clear condition that marks it done?
- Where is it recorded as temporary at the moment it is handed out, and by whom?
- What is the longest a temporary responsibility may run, extensions included, before it must become a formal role or stop?
- Who checks on it before the end date, and how is it either ended or turned into a proper role? (Defining the new role is a Role Registry question.)
Exemples
Every temporary task is given with an end date or a clear "done when" condition and logged as temporary on the task board by whoever assigns it. A week before it ends, the assigner and the person doing it check in: the task either ends, or it is proposed as a new role for the Role Registry. No temporary responsibility may run longer than 90 days in total, extensions included.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Interfaces entre rôles et domaines
Where does one role's work end and the next one's begin?
Clauses RCOS 7.6.3, 7.3.4
Pourquoi cartographier explicitement les passations ?
La plupart des défaillances opérationnelles ne surviennent pas à l'intérieur d'un rôle mais entre les rôles — aux frontières où le travail passe d'un·e responsable à l'autre. Nommer les passations transforme des dépendances invisibles en dépendances vérifiables, et prévient les échecs du type « je pensais que c'était toi qui t'en occupais ».
Comment remplir cette section
Pour chaque paire de rôles qui se transmettent du travail, nomme la passation et le type de travail transféré.
| De | Vers | Passation |
|---|---|---|
| <rôle> | <rôle> | <ce qui est transmis> |
| <rôle> | <rôle> | <...> |
Ce qu’il faut couvrir
- Which roles regularly pass work to each other?
- For each handoff: what is handed over, in which direction, and how does the receiving role know it has arrived?
- At what point does the work stop being the first role's responsibility and become the next one's?
- Where does work pass between a role and a meeting — for example, a decision that a role must then carry out?
- When a handoff gets dropped, who notices and who sorts it out?
Exemples
Membership Admin to Infrastructure Steward: when a new member's trial starts, the admin posts their details in the access channel and the steward sets up accounts within three days; on exit the same route removes them. Finance Steward to Contribution Steward: at each month-end the finance steward shares amounts paid in so contribution records can be reconciled. Governance meeting to role holders: each adopted decision is assigned to a named role in the notes, and that role confirms it has picked it up.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Limites de charge de travail
How much time, meeting and care can we ask of one person — and what happens when someone is overloaded?
Clauses RCOS 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.7.3
- 7.4.1 Le temps, l'attention, la capacité de coordination et le travail émotionnel DOIVENT être traités comme des ressources finies et limitées.
- 7.4.2 La communauté DOIT définir des limites de charge de travail explicites, incluant :
- 7.4.3 Les limites de charge de travail DOIVENT être révisables et ajustables via un processus de gouvernance autorisé.
- 7.4.4 La surcharge persistante, le risque d'épuisement, la non-participation chronique ou la dépendance à des individus en sur-fonctionnement DOIVENT déclencher des processus de révision ou de réparation tels que définis dans la Couche 4.
- 7.7.3 La charge de réunions, le poids de la coordination et le travail non rémunéré ou invisible DOIVENT être limités et révisables.
Pourquoi rendre les limites de charge explicites ?
Une charge de coordination illimitée est le mode de défaillance par défaut des communautés bénévoles — elle épuise silencieusement les membres les plus engagés jusqu'à ce qu'ils partent. Des limites explicites et vérifiables font de la capacité une préoccupation collective plutôt qu'un fardeau individuel.
Comment remplir cette section
Définis des limites pour la charge de réunions, la charge par rôle, les attentes en termes de temps de réponse, et le processus de renégociation des responsabilités.
- Charge de réunions : <cadence des réunions récurrentes et durée maximale ; règles pour les réunions extraordinaires.>
- Charge par rôle : <plafond le cas échéant ; règle pour signaler une surcharge ; délai de résolution.>
- Attentes en termes de temps de réponse : <asynchrone non urgent ; opérationnel urgent ; critique pour la sécurité.>
- Renégociation et allègement : <processus de redistribution des responsabilités ; délai de résolution.>
- Surcharge persistante : <comment la surcharge persistante, le risque d'épuisement, la non-participation chronique ou la dépendance envers des personnes en sur-fonctionnement sont détectés, et comment ils sont orientés vers le processus de révision ou de réparation de la Couche 4.>
Ce qu’il faut couvrir
- How much meeting time can we ask of one person — how often, how long, and what counts as an extra meeting?
- How many roles or hours a week may one person carry — counting unseen work like hosting, cleaning up or emotional support?
- What reply times do we expect — for everyday messages, urgent operational matters and safety issues — and when is nobody expected to answer?
- When someone says they are overloaded, how is their work covered, handed on or shared out — and how quickly?
- What signs tell us there is a pattern — lasting overload, burnout, members going quiet, or everything resting on a few people — and which review or repair process does that start?
- How often do we review these limits, and how are they changed?
Exemples
Recurring meetings take up at most four hours a month per person; an extra meeting needs 72 hours' notice. Nobody holds more than two roles or about eight hours a week, care and hosting work included. Messages get a reply within three days, urgent operational ones within a day, safety issues at once. Anyone can say they are overloaded, and their tasks are reshared within two weeks; overload flagged twice in a quarter goes to our review-and-repair process. These limits are reviewed yearly and changed by proposal.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Continuité opérationnelle
If any one of us disappeared for a month, what would stop working?
Clauses RCOS 7.5.1, 7.5.2, 7.5.3
Pourquoi planifier la continuité dès maintenant ?
Une communauté qui dépend d'une personne irremplaçable n'est qu'à une maladie, un conflit ou un départ de l'effondrement. Nommer honnêtement les points de défaillance uniques — et intégrer la passation dans chaque rôle — c'est ce qui permet à la communauté de survivre à ses fondateur·rices.
Comment remplir cette section
Nomme honnêtement les points de défaillance uniques actuels. Indique les exigences de passation pour chaque rôle et la cadence de revue de continuité.
- État actuel : <liste honnête des points de défaillance uniques ; plan de recrutement pour réduire la concentration.>
- Mécanismes de passation : <référence aux exigences de passation par rôle dans le Registre des rôles ; la passation DOIT être achevée avant qu'un rôle ne soit libéré.>
- Cadence de revue de continuité : <trimestrielle ; ponctuelle lors d'un changement de rôle.>
Ce qu’il faut couvrir
- Honestly, who or what is a single point of failure today — a person, account, key or skill that only one of us has?
- For each one: what is our plan to share it, and by when?
- For each core role and process: is the procedure written down, and what must be handed over before the holder leaves?
- Who backs up each core role — and where is a backup not yet possible?
- How often do we review this, and what else triggers a review, such as a role changing hands?
Exemples
Today only one member can access the bank account and only one understands the water system. By March a second bank signatory will be added, and the water system will have a written guide and a trained deputy. Every core role has a named backup and a handover checklist that must be completed before the holder steps down. The Infrastructure Steward reviews this list every quarter and whenever a role changes hands.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Flux d'information et anti-verrouillage
How do we make sure nobody has to go through one person to find something out?
Clauses RCOS 7.3.5, 7.7.4, 7.3.2
- 7.3.5 Les flux d'information DOIVENT être conçus pour prévenir le verrouillage d'accès, les goulets d'étranglement ou la dépendance à des intermédiaires informels.
- 7.7.4 Les règles d'accès à l'information DOIVENT être explicites et applicables.
- 7.3.2 Les règles de documentation DOIVENT spécifier, au minimum :
Pourquoi traiter l'accès à l'information comme un enjeu de gouvernance ?
Quiconque contrôle l'accès à l'information contrôle la communauté, intentionnellement ou non. Rendre les règles d'accès explicites — et interdire les points d'accès uniques — c'est ce qui empêche les gardien·nes informel·les d'accumuler le type de pouvoir que le système de gouvernance est censé contrôler.
Comment remplir cette section
Indique quels registres sont accessibles à tou·tes les Membres actifs, le délai de réponse aux demandes d'information, et la règle interdisant les points d'accès uniques pour l'information pertinente à la gouvernance.
- <Décisions de gouvernance accessibles à tou·tes les Membres actifs.>
- <Notes de réunion publiées dans un délai de X heures.>
- <État des adhésions et affectations de rôles accessibles.>
- <Registres de contributions accessibles.>
- <Délai de réponse aux demandes d'information.>
- <Retenir l'accès à des informations auxquelles les membres ont droit déclenche le processus de responsabilité prévu par la Couche 4.>
- <Aucun rôle ni individu NE PEUT être le seul point d'accès à une information requise par d'autres titulaires de rôle.>
Ce qu’il faut couvrir
- Which records can every Full Member open directly, without asking anyone — decisions, meeting notes, roles, membership, contributions? (Restricted and private records are their own question.)
- How soon after a meeting must notes and decisions be published?
- When someone asks for information they are entitled to, who must answer, and within how long?
- How do we make sure no single person or role is the only way in to information others need — passwords, files, contacts?
- What happens when someone holds back information a member is entitled to?
Exemples
Every Full Member can read decisions, meeting notes, role assignments, membership status and contribution records in the shared drive without asking anyone. Meeting notes are posted within 48 hours. Any other request for information a member is entitled to is answered within five days. Every shared account and folder has at least two people with access, and withholding information a member is entitled to is treated as an accountability issue under our conflict process.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Emplacements de la documentation et procédures de mise à jour
What do we write down, where, and who may read it — and can every decision be traced to who made it and how?
Clauses RCOS 7.3.1, 7.3.2, 7.3.3, 7.8.1
- 7.3.1 La communauté DOIT définir des règles de documentation explicites pour les décisions, les rôles, les opérations et les obligations partagées.
- 7.3.2 Les règles de documentation DOIVENT spécifier, au minimum :
- 7.3.3 Toutes les décisions DOIVENT être traçables jusqu'à :
- 7.8.1 Les éléments suivants DOIVENT être explicites :
Pourquoi nommer l'emplacement de chaque document ?
Si personne ne peut dire où se trouve la version canonique d'un document, il n'y a pas de version canonique. Nommer l'emplacement, le ou la responsable et la cadence de revue pour chaque type de document, c'est ce qui rend la mémoire de la communauté auditable plutôt que folklorique.
Comment remplir cette section
Pour chaque type de document, nomme l'emplacement canonique, le ou la responsable et la cadence de revue.
| Type de document | Emplacement | Responsable | Cadence de revue |
|---|---|---|---|
| <Artefacts RCOS> | <emplacement> | <responsable> | <cadence> |
| <Registre des membres> | <emplacement> | <responsable> | <cadence> |
| <Notes de réunion> | <emplacement> | <responsable> | <cadence> |
| <Propositions de gouvernance> | <emplacement> | <responsable> | <cadence> |
| <Registres de contributions> | <emplacement> | <responsable> | <cadence> |
Ce qu’il faut couvrir
- For each kind of record — our governance documents, member registry, meeting notes, proposals, contribution records: where does the official copy live, who keeps it, and how often is it reviewed?
- What must be written down about decisions, roles, day-to-day operations and shared obligations — what does each record have to contain at minimum?
- Who may read which records, and which are restricted for privacy — on what grounds, and who may still see them?
- When must a new record be published or announced, and to whom?
- Does every decision record say what type of decision it was and which area it covers, who had the authority, how it was decided and by what threshold, the outcome, and when it takes effect?
- Where can anyone find, written down, our roles, who may decide what, our meeting types, and our access and privacy rules?
Exemples
Governance documents, the member registry and proposals live in the shared drive, kept by the Secretary and reviewed yearly; meeting notes and contribution records live on the wiki, kept by each facilitator and the Contribution Steward and reviewed quarterly. Every decision record states its type and area, who decided, the mechanism and threshold, the outcome and its start date, and is announced within three days. Members can read everything except health, safeguarding and conflict records, which only the people involved and two named stewards may see.
Des exemples, pas des recommandations. Vos réponses vous appartiendront.
Registre de ratification
- Adopté le : <AAAA-MM-JJ>
- Type de décision : Stratégique
- Version : <version>
- Registre de décision : <lien vers le registre de décision>