Articles
Arrêtez de balancer vos SOP brutes aux agents IA : contrôlez leur comportement au millimètre avec la RFC 2119 (MUST/SHOULD/MAY)
Fourrer une SOP humaine directement dans un LLM, c'est la roulette russe : ça passe une fois, ça déraille les trois suivantes. Voici comment réécrire vos System Prompt et Agent Skill avec les mots-clés MUST, SHOULD et MAY de la RFC 2119 pour tracer une ligne claire entre contraintes strictes, recommandations fortes et marge de manœuvre, le tout appuyé par trois principes concrets de déploiement.
· 4 min de lecture
Le piège classique dans lequel tombent la plupart des équipes au moment de déployer un Agent en prod, c'est de copier-coller un document Word ou Notion contenant une « SOP humaine » directement dans le LLM, en espérant que la magie opère. Résultat des courses : une loterie permanente où l'Agent réussit une fois pour dérailler trois fois de suite.
Le problème ne vient pas d'un manque de puissance du modèle, mais du fait qu'une SOP humaine regorge de « connaissances tacites (Tacit Knowledge) ». Un être humain sait d'instinct que « si le montant est inférieur à 500 €, pas besoin de validation » ou que « si cette étape renvoie une erreur, on peut passer outre pour l'instant ». Mais pour un LLM, un texte non structuré n'a aucune hiérarchie d'autorité : sans garde-fous explicites, il improvise.
Pour rendre le comportement d'un Agent déterministe, la première chose à faire n'est pas de switcher sur un modèle plus gros, mais d'emprunter un standard historique des spécifications de protocoles réseau : la gradation sémantique de la RFC 2119.
Le verdict d'entrée de jeu : réservez MUST à la conformité, à la sécurité et aux Schemas critiques. Confiez le reste des bordures à SHOULD et MAY, et déléguez systématiquement les nœuds à haut risque à une validation humaine.
Pourquoi adopter la RFC 2119 ?#
Quand on rédige un System Prompt, un Agent Skill ou une Workflow Rule, les formulations vagues comme « merci de faire attention », « dans l'idéal » ou « essayez de » n'imposent aucune contrainte exploitable au modèle. Adopter des niveaux de verbes stricts permet au contraire de verrouiller les frontières de décision.
MUST / REQUIRED : contrainte stricte, zéro compromis#
- Sémantique : strictement obligatoire, aucune exception tolérée.
- Cas d'usage : validation de données, contrôles de sécurité, respect des Schemas de sortie, blocage des actions critiques.
- Exemple : « Avant d'appeler l'API de facturation, vous
MUST valider l'existence de l'identifiant employé ; si le retour est vide, vous MUST interrompre immédiatement l'exécution. »
SHOULD / RECOMMENDED : recommandation forte, dérogation motivée permise#
- Sémantique : à respecter par défaut, sauf justification contextuelle indiscutable. En cas de déviation, l'Agent doit obligatoirement expliciter son Reasoning.
- Cas d'usage : sélection de stratégies algorithmiques, préférences de classification, logique de retry.
- Exemple : « Pour les Ticket de type support client, vous
SHOULD assigner en priorité au support niveau 1 ; toutefois, en cas de litige financier, une réattribution à l'équipe d'audit financier est autorisée. »
MAY / OPTIONAL : option facultative, discrétion totale#
- Sémantique : le modèle décide lui-même d'exécuter ou non l'action en fonction du contexte courant ou de son budget de token.
- Cas d'usage : explications complémentaires, pistes de réflexion ouvertes, formats de logs optionnels.
- Exemple : « Lors de la génération du résumé de traitement, vous
MAY inclure 1～2 ID de Ticket historiques similaires à titre de référence. »
Trois principes pour passer à la pratique#
1. Bannissez le tout-MUST : laissez respirer le Reasoning#
Tout blinder en MUST revient à traiter le LLM comme un Deterministic Compiler : vous risquez de provoquer des collisions de règles ou un deadlock logique dès que le Context sature. Réservez MUST au trio « conformité, sécurité, Schema principal », et confiez le reste à SHOULD.
2. Structurez vos sections en Markdown clair#
Découpez votre Prompt en quatre blocs distincts afin que le Scope de chaque niveau de contrainte saute aux yeux :
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Verrouillez les nœuds critiques avec du Human-in-the-loop#
Dès qu'une condition franchit une frontière vitale soumise à MUST (par exemple un montant unitaire > $5,000 ou une modification de privilèges Admin), l'unique action MUST de l'Agent consiste à « suspendre la pipeline et attendre le GO d'une validation humaine », sans jamais prendre la décision finale à sa place.
En conclusion : du simple Demo jetable au Production-Ready#
Concevez votre Agent comme une ligne d'assemblage industrielle, pas comme un homme à tout faire omniscient. C'est en formalisant ce contrat de comportement via la RFC 2119 que votre Agent cessera d'être un jouet de Demo pour devenir véritablement Production-Ready.