SOP vers code : transformer un processus métier en fonction exécutable

La phrase la plus lourde de sens dans notre métier est peut-être celle-ci : un bon agent IA commence par un bon SOP. Pas un bon prompt, pas un bon modèle, pas une bonne stack technique. Un bon SOP. Parce qu’un agent qui s’exécute correctement sans supervision humaine est d’abord un agent dont la mission est claire, bornée et décomposée. Et la clarté vient du SOP, pas du modèle.

Cet article explique la méthode que nous utilisons chez VirtuoseWeb pour transformer un processus métier en fonction exécutable par un agent. Elle est utilisable aussi bien en Voie 1 Claude Express qu’en Voie 2 Souverain Europe ou Voie 3 On-Prem : la méthode précède le choix d’infrastructure.

Pourquoi partir du SOP et pas du prompt

Beaucoup de projets IA échouent pour une raison simple : on commence par écrire un prompt génial, on branche un modèle performant, on teste sur quelques cas faciles et on pousse en production. Puis le monde réel arrive, et les cas particuliers multiplient les erreurs. L’équipe rejette l’outil. Le projet s’arrête.

Le problème n’était pas le modèle. Le problème était l’absence de spécification claire. Le modèle générait des sorties plausibles sans qu’on puisse évaluer objectivement si elles étaient correctes. Sans référentiel, pas de contrôle qualité.

Partir du SOP inverse la logique. On écrit d’abord, noir sur blanc, ce que la procédure doit produire, dans quels cas, avec quelles vérifications. Le modèle devient un moyen d’exécuter la spécification. S’il se trompe, on le voit immédiatement parce qu’on a une référence. On peut ajuster, calibrer, itérer.

Cette discipline change tout : elle transforme l’agent IA en système de production industrielle plutôt qu’en démo brillante.

Étape 1 — Extraire le SOP implicite

La première phase est un atelier de diagnostic. Nous nous asseyons avec le collaborateur qui effectue aujourd’hui la tâche cible et nous lui demandons de décrire ce qu’il fait, étape par étape, comme s’il expliquait à un nouvel arrivant.

La plupart du temps, le SOP est implicite. Le collaborateur a des routines qu’il n’a jamais formalisées. Il prend des décisions qui lui paraissent évidentes mais qui reposent sur une expérience non explicitée. Notre travail consiste à faire sortir tout cela.

Les bonnes questions à poser sont toujours les mêmes. Qu’est-ce qui déclenche la procédure ? Un email entrant, un rendez-vous planifié, une alerte système, une date calendaire. Quelles sont les entrées nécessaires ? Quelles informations doivent être réunies avant de commencer. Quelle est la première action ? Et la suivante. Et celle d’après. Quand prenez-vous une décision ? Sur quelles bases. Qu’est-ce qui vous fait escalader vers un collègue ? Quels signaux. Comment vérifiez-vous que le résultat final est correct ?

On note tout. On schématise. On revient sur les zones floues. À la fin de l’atelier, qui dure d’une demi-journée à deux jours selon la complexité, on a un document de travail qui décrit la procédure de manière exhaustive.

C’est le SOP. C’est la spécification de l’agent.

Étape 2 — Décomposer en fonctions

La deuxième étape consiste à convertir chaque action du SOP en une fonction que l’agent pourra appeler. On appelle ces fonctions des tools dans le vocabulaire des agents IA.

Prenons un exemple. Le SOP d’un agent de recouvrement comptable contient l’étape « envoyer une relance par email au client ». Cette étape devient le tool send_dunning_email(customer_id, template_id, custom_message). Le tool prend en paramètres l’identifiant du client, le modèle de relance à utiliser (premier, second, dernier rappel) et un éventuel message personnalisé. Il renvoie un identifiant de l’email envoyé et un accusé de transmission.

Le même exercice se répète pour chaque étape du SOP. Interroger la base pour connaître le solde devient get_customer_balance(customer_id). Consulter l’historique de paiements devient list_payment_history(customer_id, months). Enregistrer la relance dans le CRM devient log_interaction_crm(customer_id, type, notes).

Cette décomposition a deux vertus majeures. D’abord, elle force à nommer précisément chaque action que l’agent pourra entreprendre. Ce qui est nommé est maîtrisé. Ensuite, elle crée une frontière nette entre ce que l’agent sait faire et ce qu’il ne sait pas faire. Tout ce qui n’est pas un tool n’existe pas pour lui. Cette frontière est votre meilleure garantie de sécurité.

Étape 3 — Définir les règles de décision

Une fois les tools listés, il reste à spécifier quand l’agent utilise quel tool. C’est la partie décision du SOP, celle qui distingue un agent intelligent d’un simple automate.

Les règles de décision se formalisent de plusieurs manières. Les règles déterministes sont codées dans le prompt ou dans des fonctions utilitaires : « si le solde est supérieur à 1 000 euros et le retard supérieur à 30 jours, utiliser le template de second rappel ». Ces règles garantissent la prévisibilité sur les cas standards.

Les règles de jugement sont laissées au modèle, mais avec un cadre. « Si le client a un historique de paiement régulier malgré un retard ponctuel, tu peux proposer un échéancier. Si l’historique est erratique, passe directement au rappel strict. » Le modèle fait appel à son jugement contextuel, borné par les instructions.

Les règles d’escalade sont cruciales. « Si le solde dépasse 5 000 euros, ne jamais relancer automatiquement. Escalader vers le manager commercial avec un résumé structuré. » Ces règles protègent les cas à enjeu fort de toute décision autonome inappropriée.

Bien écrites, ces règles permettent à l’agent d’opérer de manière à la fois cohérente et adaptative.

Étape 4 — Spécifier les garde-fous et les validations

Un agent sans garde-fous est un risque. Un agent avec trop de garde-fous devient inutile. Le bon équilibre se calibre pendant cette étape.

Nous distinguons trois niveaux de validation. Le niveau vert correspond aux actions que l’agent peut effectuer seul, sans revue humaine. Par exemple, envoyer un email de premier rappel à un client dont l’historique est propre. C’est la zone d’autonomie pleine.

Le niveau orange correspond aux actions qui sont effectuées par l’agent mais rapportées à un humain dans les 24 heures pour validation a posteriori. Par exemple, proposer un échéancier inférieur à un certain montant. L’agent agit, mais quelqu’un vérifie.

Le niveau rouge correspond aux actions qui nécessitent une validation humaine préalable. L’agent prépare la décision, la motive, et attend l’aval. Par exemple, déclencher une procédure contentieuse ou accorder une remise significative.

Ces trois niveaux se définissent au cas par cas, en discussion avec le management. Ils évoluent au fil du temps : une tâche qui commence en niveau orange pendant la phase d’apprentissage peut basculer en vert après quelques semaines de bon comportement observé.

Étape 5 — Tester sur des cas réels

Avant la mise en production, nous faisons tourner l’agent sur un corpus de cas historiques tirés de votre activité réelle. Vingt, cinquante, cent cas selon la taille du chantier.

Pour chaque cas, nous comparons la décision de l’agent avec celle qui a été prise historiquement par le collaborateur. Là où il y a divergence, nous analysons pourquoi. Soit l’agent a raté quelque chose et il faut ajuster le prompt ou les règles. Soit l’agent a trouvé un meilleur chemin et il faut documenter cette amélioration. Soit le cas est vraiment ambigu et il faut le mettre en escalade systématique.

Cette phase de calibration prend typiquement une à trois semaines. Elle est indispensable. Un agent qui part en production sans avoir été calibré sur des cas réels est un agent qui va produire des surprises.

Un exemple complet — l’agent de pré-qualification de leads

Pour rendre la méthode tangible, voici comment elle s’applique à un cas simple : un agent de pré-qualification de leads entrants pour une agence B2B.

SOP extrait : à chaque nouveau lead entrant, enrichir avec les données d’entreprise (taille, secteur, CA), calculer un score selon la grille ICP, envoyer une réponse personnalisée si score élevé, archiver si score bas, escalader si score ambigu.

Tools définis : read_contact_form, enrich_company_data, compute_icp_score, send_templated_email, create_crm_entry, notify_sales_slack, archive_lead.

Règles de décision : si score > 80, envoyer réponse qualifiée et créer entrée CRM. Si score < 30, archiver. Si score entre 30 et 80, notifier commercial avec résumé structuré pour revue humaine.

Garde-fous : toutes les actions automatiques sont en niveau vert. L’escalade vers le commercial est déclenchée pour tous les leads du score intermédiaire (niveau orange de fait : l’agent prépare, un humain valide).

Tests : 50 leads historiques rejoués. L’agent a atteint un taux de concordance de 92 % avec les décisions prises par le commercial, et a détecté trois leads mal qualifiés par le commercial lui-même (erreurs humaines rattrapées).

Mise en production une semaine plus tard. Temps commercial libéré : estimé à 8 heures par semaine.

Et maintenant, on fait quoi

Si vous voulez appliquer cette méthode à un processus de votre entreprise, la première étape est le guide diagnostic SOP qui détaille les questions à se poser avant l’atelier.

Pour une vue plus large de la démarche, consultez le guide complet du salarié IA en entreprise.

Et si vous êtes prêt à passer à l’action directement, réservez un audit SOP gratuit de 30 minutes. Nous commencerons à extraire votre premier SOP en direct, pendant la visio.

La méthode SOP → Code n’est pas un exercice théorique. C’est la discipline qui sépare les projets d’agent qui durent de ceux qui s’écroulent au bout de trois mois. Vos processus sont déjà là, dans la tête de vos équipes. Il reste à les rendre exécutables.