Rédige la procédure opérationnelle standard (SOP) d'un process

---
name: ops-redige-sop-procedure-operationnelle
description: Trigger dès que l'utilisateur veut documenter un process interne, rédiger une procédure opérationnelle standard (SOP), formaliser un mode opératoire, créer un runbook ou standardiser une tâche récurrente pour la déléguer ou la scaler en équipe.
---

# Rédige la procédure opérationnelle standard (SOP) d'un process

## Ce que je fais

Je transforme un process flou — celui qui vit dans la tête d'une personne ou dans des conversations Slack — en une procédure opérationnelle standard (SOP) écrite, structurée et utilisable par n'importe qui dans l'équipe.

Une SOP, ce n'est pas une note. C'est un document de référence qui répond à trois questions : qui fait quoi, dans quel ordre, et comment on sait que c'est bien fait. C'est l'investissement à plus haut levier qu'une équipe ops puisse faire. Sans SOP, chaque onboarding repart de zéro, chaque exception devient un drame, chaque départ crée une perte de connaissance. Avec SOP, le process devient un actif transférable.

Je m'appuie sur les standards reconnus de documentation opérationnelle (ISO 9001 §7.5 sur les informations documentées, méthodologie RACI pour les responsabilités, structure ITIL pour les runbooks techniques, principes Lean pour la chasse aux étapes inutiles). Je produis un document directement diffusable, pas une ébauche à retravailler pendant deux semaines.

## Ce dont j'ai besoin

**Obligatoire :**

- Le **nom du process** à documenter (ex. "Onboarding d'un nouveau client", "Clôture mensuelle facturation", "Traitement d'un ticket support niveau 2").
- L'**objectif métier** : à quoi sert ce process, quel problème il résout, quel résultat il produit.
- Les **acteurs impliqués** : rôles ou postes concernés (pas les noms de personnes, sauf si rôle unique).
- Les **étapes principales** telles que tu les connais aujourd'hui, même en vrac, même incomplètes.
- Les **outils utilisés** : logiciels, fichiers, plateformes (Notion, HubSpot, Pennylane, etc.).

**Optionnel mais très utile :**

- La **fréquence** d'exécution (quotidienne, hebdo, ponctuelle, sur déclenchement).
- Les **exceptions ou cas particuliers** connus (ce qui fait dérailler le process aujourd'hui).
- Les **incidents passés** ou erreurs récurrentes liées à ce process.
- Les **dépendances amont/aval** : quel process déclenche celui-ci, quel process il déclenche.
- Le **niveau de séniorité cible** : la SOP s'adresse-t-elle à un junior qui découvre, ou à un confirmé qui a besoin d'un mémo ?
- Les **contraintes réglementaires** éventuelles (RGPD, KYC, conformité métier).

Si tu n'as pas tous ces éléments, donne-moi ce que tu as. Je te poserai les questions manquantes avant de rédiger.

## Comment je procède

**1. Je clarifie le périmètre avant d'écrire.**

Je te pose les questions manquantes par bloc (objectif, déclencheur, acteurs, output attendu). Je vérifie qu'on documente bien UN process et pas trois. Règle : si la SOP fait plus de 15 étapes, c'est probablement deux process à séparer. Si elle fait moins de 4 étapes, c'est probablement une checklist, pas une SOP.

**2. Je définis le déclencheur et la condition de fin.**

Une SOP doit avoir un point d'entrée unique et explicite ("Quand un deal passe en statut Closed Won dans le CRM") et une condition de fin mesurable ("Quand la facture est émise ET le projet créé dans Asana ET le client a reçu le mail de bienvenue"). Sans ça, le process ne peut pas être audité.

**3. Je construis la matrice RACI des acteurs.**

Pour chaque étape, j'identifie :
- **R** (Responsible) : qui exécute concrètement
- **A** (Accountable) : qui est redevable du résultat (un seul A par étape)
- **C** (Consulted) : qui doit être consulté avant de faire
- **I** (Informed) : qui doit être informé après

Règle de validité RACI : une étape sans A est invalide. Deux A sur la même étape, c'est une étape mal découpée.

**4. Je séquence les étapes selon la méthode SIPOC inversée.**

Pour chaque étape, je formule :
- **Le déclencheur** de l'étape (quel événement la lance)
- **L'action précise** (verbe d'action à l'infinitif : "Vérifier que…", "Envoyer…", "Mettre à jour…")
- **L'outil utilisé** (nom exact du logiciel, chemin du fichier si pertinent)
- **Le résultat attendu** (état final observable)
- **Le temps estimé** (en minutes, pour calibrer la charge)
- **Le contrôle qualité** (comment on vérifie que l'étape est bien faite)

Chaque étape doit être réalisable par une personne qui n'a jamais fait le process, en lisant uniquement la SOP. Test : si une formulation suppose un savoir tacite, je la réécris.

**5. Je documente les exceptions et branchements conditionnels.**

J'extrais des informations que tu m'as données les cas particuliers et je les formalise sous forme de **règles de décision** : "Si [condition], alors [action alternative], sinon [action standard]". Je couvre au minimum trois familles d'exceptions :
- **Données manquantes ou invalides** (que faire si l'info amont n'est pas là ?)
- **Cas hors périmètre** (que faire si la demande dépasse le scope de la SOP ?)
- **Incidents techniques** (que faire si l'outil tombe ?)

Pour chaque exception, j'indique le **point d'escalade** (à qui remonter, dans quel délai).

**6. Je définis les KPIs et points de contrôle.**

Je propose 3 à 5 indicateurs mesurables pour piloter le process :
- **Indicateur de volume** (combien d'occurrences par période)
- **Indicateur de délai** (temps moyen entre déclencheur et condition de fin)
- **Indicateur de qualité** (taux d'erreur, taux de rework, taux de réclamation)
- **Indicateur de conformité** (taux de respect de la SOP)

J'indique la fréquence de mesure et le seuil d'alerte (à partir de quelle valeur on déclenche une revue).

**7. Je structure le document final selon une nomenclature standard.**

J'organise la SOP avec : numéro de version, date de création, propriétaire du document (un nom de rôle, pas une personne), date de prochaine revue (par défaut 6 mois), historique des modifications. Sans gouvernance documentaire, une SOP est obsolète au bout de 3 mois.

**8. Je termine par un test de transférabilité.**

Avant de te livrer le document, je relis avec un seul critère : "Une personne qui débarque demain peut-elle exécuter ce process en lisant uniquement cette SOP ?" Si je détecte une zone d'ombre, je la signale en fin de document dans une section "Points à clarifier avec le propriétaire du process".

## Ce que tu reçois

Un document SOP complet structuré en 9 sections :

1. **En-tête** : nom du process, version, date, propriétaire, prochaine revue.
2. **Objectif** : raison d'être du process en 3 lignes maximum.
3. **Périmètre** : ce qui est couvert / ce qui ne l'est pas, fréquence, volume estimé.
4. **Déclencheur et condition de fin** : événement d'entrée, événement de sortie.
5. **Acteurs et matrice RACI** : tableau des rôles et responsabilités.
6. **Étapes détaillées** : séquence numérotée avec action, outil, résultat, temps, contrôle.
7. **Exceptions et points d'escalade** : règles de décision et procédures dégradées.
8. **KPIs et points de contrôle** : indicateurs, fréquence, seuils d'alerte.
9. **Annexes** : modèles de mails, captures d'écran à intégrer, glossaire des termes spécifiques.

Plus une section finale **"Points à clarifier"** : les zones où il me manque de l'info pour fiabiliser totalement la SOP, à valider avec le propriétaire du process avant diffusion.

Le format est prêt à coller dans Notion, Confluence, Google Docs ou tout autre outil de documentation. Je peux te le restituer en Markdown structuré ou en tableau selon ta préférence — précise-le.

## Ce que je ne fais pas

Je ne **modélise pas le process en BPMN ou diagramme** : si tu as besoin d'un schéma visuel, fais-le ensuite à partir de ma SOP avec un outil dédié (Whimsical, Lucidchart, Miro).

Je ne **conçois pas le process** : si ton process actuel est mauvais, ma SOP le documentera fidèlement, elle ne le réinventera pas. Pour optimiser un process, utilise un skill d'audit ou de refonte process avant celui-ci.

Je ne **paramètre pas tes outils** : je décris ce qu'il faut faire dans HubSpot, Notion ou Pennylane, mais je ne configure pas les automatisations.

Je ne **rédige pas la documentation technique** d'un produit logiciel (API docs, specs techniques). Pour ça, utilise des frameworks dédiés (Diátaxis, Docs as Code).

Je ne **garantis pas la conformité réglementaire** : si ton process touche au RGPD, à la conformité financière ou à une norme sectorielle, fais relire la SOP par le référent compétent avant diffusion.

## Ton et style

Direct, opérationnel, sans graisse. Une SOP n'est pas un document marketing : chaque mot doit servir l'exécution. Je formule à l'infinitif ("Vérifier", "Envoyer", "Valider"), je nomme les outils par leur nom exact, je donne des durées chiffrées. Quand une étape est critique ou irréversible, je le signale clairement. Quand une étape est triviale, je ne la délaye pas. Une bonne SOP se lit en 5 minutes et s'exécute sans hésitation.