Comment documenter un processus etape par etape. Format, etapes, validation, cycle de vie.

Creer une proc

Une proc = des etapes numerotees. Elle dit COMMENT FAIRE.

L'agent ne reflechit pas. Il execute. Chaque etape est concrete et verifiable.

Proc vs Skill

Confusion la plus frequente du systeme.

SKILL : "Toujours verifier les donnees avant d'analyser."
  → Principe de reflexion. L'agent adapte.

PROC : "1. Ouvrir le fichier. 2. Compter les lignes nulles.
        3. Si > 5%, signaler au manager."
  → Etapes concretes. L'agent execute.

Test decisif : est-ce decomposable en etapes numerotees ?

Oui → proc.
Non → skill.

Format d'une proc

---
type: procedure
domain: [domaine]
version: 1.0
duree_estimee: [temps]
prerequis: [ce qui doit etre en place avant]
---

# Proc : [verbe]-[objet]

## Objectif
[1 phrase. Ce que cette proc accomplit.]

## Prerequis
[Ce qui doit exister avant de commencer.]

## Etapes

### 1. [Action concrete]
[Details. Commande. Outil a utiliser.]
**Verification :** [Comment savoir que l'etape est reussie.]

### 2. [Action concrete]
[Details.]
**Verification :** [Critere de succes.]

### 3. [Action concrete]
[Details.]
**Verification :** [Critere de succes.]

## Resultat attendu
[Ce qui existe apres execution.]

## En cas d'erreur
[Que faire si une etape echoue.]

Les 5 regles d'une bonne etape

1. Un verbe d'action

Chaque etape commence par un verbe.

BON :  "Ouvrir le fichier clients.csv"
BON :  "Envoyer l'email de confirmation"
MAUVAIS : "Le fichier clients"
MAUVAIS : "Pensez a l'email"

2. Un outil explicite

L'agent doit savoir QUEL outil utiliser.

BON :  "Ouvrir clients.csv avec le MCP obsidian (vault_read_note)"
MAUVAIS : "Ouvrir le fichier client"

3. Une verification

Chaque etape a un critere de succes mesurable.

BON :  "Verification : le fichier contient > 0 lignes"
MAUVAIS : "Verification : ca marche"

4. Un chemin d'erreur

Que faire si l'etape echoue.

BON :  "Si le fichier n'existe pas → creer depuis le template T-001"
MAUVAIS : (rien)

5. Pas de decision

Si l'etape demande une decision, c'est un skill, pas une proc.

BON :  "Si montant > 1000 EUR → escalader au manager"
MAUVAIS : "Evaluer si le montant est acceptable"

Exemple complet

---
type: procedure
domain: client
version: 1.0
duree_estimee: 10min
prerequis: [fiche client existante, devis valide]
---

# Proc : envoyer-devis

## Objectif
Envoyer un devis PDF au client par email.

## Prerequis
- Fiche client avec email valide
- Devis genere depuis le template T-DEVIS

## Etapes

### 1. Recuperer les donnees client
Lire la fiche client dans Notion (MCP notion).
Extraire : nom, prenom, email, societe.
**Verification :** les 4 champs sont non-vides.

### 2. Generer le PDF
Appliquer le template T-DEVIS avec les donnees.
Exporter en PDF dans /tmp/devis-{{client}}-{{date}}.pdf.
**Verification :** le fichier PDF existe et fait > 10 Ko.

### 3. Rediger l'email
Utiliser le template COMM-DEVIS.
Remplir les variables : {{prenom}}, {{projet}}, {{montant}}.
**Verification :** l'email contient le prenom et le montant.

### 4. Envoyer l'email
Utiliser le MCP email (send_email).
Destinataire : {{email_client}}.
Piece jointe : le PDF genere.
**Verification :** statut d'envoi = succes.

### 5. Logger l'action
Ajouter une entree dans le CRM Notion : "Devis envoye le {{date}}".
**Verification :** l'entree apparait dans l'historique client.

## Resultat attendu
- Le client a recu le devis par email.
- Le CRM est a jour.

## En cas d'erreur
- Email invalide → escalader au manager avec la fiche client.
- PDF vide → regenerer depuis le template.
- Envoi echoue → reessayer 1 fois, puis escalader.

Nommage

Les procs suivent une convention stricte.

proc-{verbe}-{objet}.md

Exemples :
- proc-envoyer-devis.md
- proc-publier-article.md
- proc-onboarder-client.md
- proc-generer-rapport.md

Le verbe est a l'infinitif. L'objet est singulier.

Validation

Avant d'integrer une proc :

[ ] Chaque etape a un verbe d'action
[ ] Chaque etape nomme l'outil utilise
[ ] Chaque etape a une verification
[ ] Les chemins d'erreur sont definis
[ ] Un agent a execute la proc avec succes
[ ] Le resultat attendu est atteint
[ ] Le nommage suit la convention

Test final : donner la proc a un agent Haiku (le plus basique). S'il l'execute correctement, la proc est bonne. Si non, les etapes sont trop vagues.

Cycle de vie

  [Besoin identifie]
        |
  [Brouillon]
        |
  [Test par agent Haiku]
       / \
     OK   KO → simplifier les etapes
      |
  [Catalogue]
        |
  [Usage courant]
        |
  [Feedback] → [Mise a jour] → [v1.1]
        |
  [Plus utilisee ?] → [Archive]

Versionning

v1.0 → Creation initiale
v1.1 → Correction d'une etape
v1.2 → Ajout d'un chemin d'erreur
v2.0 → Refonte (changement de processus)

Workflows

Un workflow = une chaine de procs avec des decisions.

  [proc-qualifier-lead]
          |
     Score >= 7 ?
      /        \
    Oui        Non
     |           |
  [proc-envoyer-devis]  [proc-archiver-lead]
     |
  [proc-relancer-client]

Les workflows ne sont PAS des procs. Ils orchestrent des procs. Les decisions entre les procs sont du ressort du manager.

Erreurs courantes

Etapes trop vagues. "Traiter le client." Non. Quel outil ? Quelle donnee ? Quel resultat ?

Pas de verification. L'agent croit avoir reussi. Le resultat est faux. Chaque etape a un critere mesurable.

Decision dans la proc. "Evaluer si c'est pertinent." Ca c'est un skill. La proc execute, elle ne juge pas.

Creer une proc

On this page