Conception de prompts & workflows

Dans un système MCP-first, il existe, en plus des outils et des ressources, un troisième composant : les prompts et les workflows. Un workflow est un processus prédéfini qui guide un agent pas à pas à travers un processus complexe. Il définit quels outils sont appelés dans quel ordre, à quel moment l’humain doit être consulté, et quels résultats sont transmis.

Les workflows ne sont pas des scripts. Ils donnent à l’agent contexte, intention et structure, sans lui ôter sa liberté de décision.

La meilleure interface est souvent l’absence d’interface

De nombreuses tâches du quotidien professionnel n’ont plus besoin d’une page. Elles sont dialogiques, contextuelles et fondées sur des workflows. L’humain interroge, l’agent travaille :

• « Crée-moi un résumé de tous les deals ouverts. »
• « Quels clients devrais-je contacter aujourd’hui ? »
• « Planifie un rendez-vous de suivi avec tous les participants. »
• « Prépare un e-mail pour ce contact. »
• « Vérifie s’il manque des documents chez cet employé. »
• « Génère un rapport sur tous les projets à risque. »
• « Compare les deux dernières exécutions de paie. »

Pas de navigation, pas de filtre, pas de modale. L’agent rassemble le contexte, combine les bons outils et fournit un résultat, ou demande une approbation avant d’agir en externe.

Workflows au lieu de navigation

Une webapp classique guide l’utilisateur via la navigation : liste de clients → page de détail → onglet communication → modale de rappel. C’est intuitif pour les humains. Pour un agent, c’est un surcoût inutile, il doit cliquer dans une interface qui n’a pas été conçue pour sa façon de travailler.

Un workflow résout le même problème différemment : il décrit le processus directement comme une séquence ordonnée de capacités. L’agent comprend ce qu’il faut faire sans connaître l’interface.

Un workflow en détail

L’exemple suivant présente un workflow de suivi acheteur pour un logiciel immobilier. L’agent doit examiner tous les projets actifs, identifier les acheteurs pertinents et préparer une communication de suivi.

Voici le déroulement du workflow :

1. projects.list_active, L’agent lit tous les projets actifs. Il s’agit d’un accès en lecture à faible risque qui peut être exécuté de manière autonome.
2. contacts.search_buyers, Pour chaque projet, les contacts acheteurs pertinents sont recherchés. Également un accès en lecture, sans effet externe.
3. contacts.get_purchase_profile, L’agent charge le profil d’achat de chaque contact afin de vérifier si un suivi est pertinent.
4. exposes.generate_download_link, Pour les projets pertinents, un lien de téléchargement limité dans le temps vers l’exposé est généré.
5. emails.create_project_draft, L’agent crée un brouillon d’e-mail avec le texte personnalisé et le lien de téléchargement. Pas d’envoi encore.

À ce stade, le workflow s’arrête.

L’humain est consulté. Le système affiche le brouillon finalisé : destinataire, objet, contenu, date d’expiration du lien, niveau de risque critical. L’utilisateur peut confirmer, modifier ou rejeter le brouillon. Ce n’est qu’après une approbation explicite que emails.send_project_email est exécuté.

6. reminders.create_follow_up, Après l’envoi, l’agent crée automatiquement un rappel si le contact ne répond pas dans les sept jours.
7. deals.recommend_next_action, Enfin, le système calcule l’action recommandée suivante par deal et la retourne comme résultat structuré.

Les workflows composent des outils

Un workflow est fondamentalement une composition d’outils individuels avec une logique claire :

• Accès en lecture à faible risque (list_active, search_buyers, get_purchase_profile) sont exécutés de manière autonome et séquentielle, pas d’effet externe, pas de risque.
• Actions d’écriture à effet interne (create_project_draft, reminders.create_follow_up) sont exécutées mais ne génèrent pas d’effet externe.
• Actions d’écriture à effet externe (emails.send_project_email) sont protégées par un Confirmation Gate. L’agent prépare, l’humain décide.

Ce schéma s’applique à tout workflow : la lecture est bon marché, l’écriture a besoin de contexte, les actions externes nécessitent un consentement. Construire des workflows de cette façon maintient le système entièrement contrôlable, sans le paralyser.