Le prompt comme livrable opérationnel — la SOP exécutable

Toute entreprise qui a passé deux ans a un drive plein de SOPs (Standard Operating Procedures). Très peu sont utilisées. La plupart deviennent des reliques d'une époque, signalant que « oui, on a documenté ce processus ».

Cet article décrit comment utiliser un prompt pour produire des SOPs que vos équipes suivent vraiment. Et au passage, pourquoi le format compte plus que le contenu.

Pourquoi les SOPs ne sont pas suivies

Trois raisons reviennent quand on demande aux équipes :

1. Trop longues — la SOP fait 12 pages. Personne ne lit 12 pages avant d'agir. 2. Mal structurées — les étapes ne sont pas claires, on ne sait pas où on en est. 3. Trop polies — la SOP est écrite à l'éditeur. « Veuillez vous assurer que... » au lieu de « Coche que... ».

Le prompt qui marche corrige ces trois défauts.

La structure imposée

Voici la structure qu'on utilise pour TOUTES les SOPs internes :

[OBJET]                  Une phrase, verbe à l'infinitif.
[QUI]                    Le rôle qui exécute (pas un nom).
[QUAND]                  Le déclencheur (événement, calendrier).
[PRÉ-REQUIS]             Liste vérifiable, 3 items max.
[ÉTAPES]                 Numérotées. Chaque étape = 1 action observable.
[CRITÈRE D'ARRÊT]        Comment savoir que c'est fini.
[ESCALADE]               Quand demander de l'aide, à qui.
[RÉVISION]               Date prochaine review, owner.

Cette structure tient sur 1,5 page. Pas plus.

Les règles de chaque étape

Chaque étape numérotée respecte trois règles :

1. Verbe d'action en premier — « Ouvrir le fichier X », pas « Le fichier X doit être ouvert ». 2. Cochable — il existe un état « fait » objectif. Si le critère est « valider », mauvais. Si c'est « cliquer sur le bouton "Valider" et confirmer le toast vert », bon. 3. Pas plus d'une décision implicite — si l'étape contient « si X, faire Y, sinon faire Z », découpez-la en deux étapes (avec branche).

Quand vous écrivez un prompt qui génère des SOPs, ces trois règles sont à imposer dans le prompt directement.

Le prompt qui marche

Voici la structure du prompt :

Tu es chargé d'écrire la SOP de ce processus. Voici les notes brutes
de l'employé qui maîtrise la tâche depuis 2 ans. Convertis-les en
procédure exécutable par quelqu'un qui débute aujourd'hui.

Règles :
(1) Aucune phrase commençant par "il suffit de" ou "simplement"
(2) Chaque étape doit pouvoir être cochée (action observable)
(3) Signale en italique les pièges qui ne sont pas évidents
(4) À la fin, liste les questions à poser au manager si l'étape échoue

Structure imposée :
[OBJET] [QUI] [QUAND] [PRÉ-REQUIS] [ÉTAPES] [CRITÈRE D'ARRÊT]
[ESCALADE] [RÉVISION]

NOTES :
{{notes-brutes}}

L'entrée du catalogue SOP depuis un brouillon désordonné implémente cela exactement.

Le test de la nouvelle recrue

Avant de publier une SOP, faites-la suivre par quelqu'un qui n'a jamais fait la tâche.

Notez :

• À quelle étape la personne a hésité
• Quelle question elle a dû poser
• Quel outil elle ne savait pas où trouver

Pour chaque hésitation : ajoutez la précision dans la SOP.

C'est lent. C'est nécessaire. Une SOP qui n'a jamais été testée par un débutant n'est pas une SOP, c'est un mémo pour vous-même.

L'erreur à ne pas commettre

Ne tentez PAS d'écrire la SOP en partant de votre tête. Vous oublierez 30% des étapes parce qu'elles vous sont devenues automatiques.

Démarrez toujours d'une transcription. Soit :

• Une vidéo de vous (ou de l'expert) en train de faire la tâche, transcrite
• Un appel Zoom où l'expert explique en pensant à voix haute
• Les messages Slack qu'on a échangés sur le sujet

C'est en partant du désordre que la SOP devient utilisable. Si vous partez du « propre », elle reste générique.

Pour aller plus loin

• Le pilier : Le guide des prompts pour opérateurs
• L'entrée catalogue : SOP depuis un brouillon désordonné
• L'entrée catalogue : Plan d'onboarding 30/60/90
• L'entrée catalogue : Runbook on-call en 2 pages