Workflows multi‑étapes comme moyen de réduire la charge cognitive

1. Qu’est-ce qu’un workflow dans le contexte de ChatGPT App

Bon, si vous avez compris l’authentification, vous avez bien mérité une récompense. Passons à un sujet très intéressant — les workflows dans ChatGPT App. Le mot « workflow » déclenche chez beaucoup des flashbacks de diagrammes BPMN et de logiciels d’entreprise austères. Rassurez‑vous : dans le contexte de ChatGPT App, nous parlons d’une version bien plus légère.

Dans ce cours, par workflow nous entendons un scénario multi‑étapes, dans lequel :

• il y a un objectif clair (par exemple, trouver un cadeau et aller jusqu’à l’achat),
• il y a des étapes successives (entretien → génération d’options → affinage → final),
• à chaque étape, des rôles distincts pour GPT, le widget et les outils.

Point important : un workflow n’est pas « une seule méthode dans le serveur MCP ». C’est une composition :

• du raisonnement du modèle (quelles questions poser, quel outil appeler),
• d’appels d’outils (MCP/Agents),
• d’étapes UI dans le widget,
• d’état côté back‑end.

Autrement dit, vous n’avez pas un « super‑outil » solve_everything, mais plusieurs petits outils activés à différentes étapes. Et pas un « méga‑widget », mais un petit ensemble d’écrans/états, chacun pour une sous‑tâche.

« Triangle des responsabilités » dans un workflow

On peut voir le workflow comme une danse à trois :

Ces trois rôles mettent en œuvre le même scénario, mais à des niveaux différents : GPT décide « quoi faire ensuite », le widget montre « ce qui se passe maintenant », MCP gère ce qui arrive réellement aux données.

2. Exemple de workflow basé sur GiftGenius

Prenons le scénario GiftGenius — un assistant de choix de cadeaux. On peut le décrire comme un assistant linéaire simple.

La séquence d’étapes peut être la suivante :

1. Recueillir les informations de base sur le destinataire.
2. Définir le budget et les contraintes.
3. Générer et filtrer des idées de cadeaux.
4. Afficher les candidats, permettre d’aimer/masquer.
5. Passer à la finalisation (Checkout) ou enregistrer la sélection.

On peut également représenter ce scénario comme une petite « machine à états » :

stateDiagram-v2
    [*] --> Profiling
    Profiling --> ProfilingDone: profil complété
    ProfilingDone --> Browsing: idées générées
    Browsing --> Refining: l’utilisateur a précisé les filtres
    Refining --> Browsing: liste mise à jour
    Browsing --> Checkout: cadeau sélectionné
    Checkout --> Success: commande passée
    Success --> [*]

Ici :

• Profiling — l’étape de collecte des réponses sur le destinataire,
• Browsing/Refining — le travail avec la liste des candidats,
• Checkout — finalisation,
• Success — confirmation finale.

Notez qu’il n’y a aucun bouton ni aucun fetch sur le diagramme. Ce sont des étapes logiques; les écrans UI concrets, les outils et les appels d’API se greffent par‑dessus.

3. Pourquoi découper la tâche en étapes

Si vous avez déjà conçu « un questionnaire de 25 questions sur un seul écran », vous savez déjà pourquoi. Mais détaillons point par point.

Charge cognitive de l’utilisateur

L’attention d’une personne est limitée. Les psychologues aiment citer la loi de Miller sur 7±2 éléments en mémoire à court terme. En UX, cela se traduit par une règle très pratique : plus vous affichez de champs et d’options en même temps, plus la probabilité augmente que l’utilisateur se bloque, se fatigue ou ferme l’onglet.

Un formulaire de 12 champs sur un seul écran dans un petit widget inline de ChatGPT — c’est presque un rage‑quit garanti : l’utilisateur abandonne et ferme l’onglet. Il est venu « discuter », pas passer un examen.

Si vous découpez la tâche en étapes :

• « Étape 1 sur 4 : parlez‑nous de la personne »,
• « Étape 2 sur 4 : choisissez un budget »,
• « Étape 3 sur 4 : explorez les options »,
• « Étape 4 sur 4 : confirmez votre choix »,

chaque moment paraît abordable. Une barre de progression ou des libellés d’étapes donne un sentiment de contrôle : on comprend ce qui se passe et combien il reste.

Charge cognitive du modèle

Surprise : le modèle a un problème similaire. Une LLM n’est pas un humain, mais elle a aussi une « attention » et une fenêtre de contexte limitées. Si vous demandez à GPT en un seul passage :

• d’apprendre tout sur le destinataire,
• de gérer le budget,
• de tenir compte des détails de livraison,
• de proposer 10 options,
• d’expliquer pourquoi ces options,

le modèle dépense une partie de son attention et de ses tokens sur chaque sous‑tâche. Plus il y a de tâches disparates dans une requête, plus le risque augmente qu’une partie soit faite superficiellement ou avec des erreurs.

Si vous construisez une chaîne d’étapes — en somme le même chain-of-thought mais explicitée dans l’interface — le modèle résout d’abord la tâche étroite « extraire le profil », puis « ajuster le budget », puis « proposer des candidats ». La qualité du raisonnement du modèle à chaque étape est nettement supérieure.

Maintenabilité et débogage

Quand tout est fourré dans un seul outil et un seul écran, le débogage devient une quête : « À quel moment exact ça a mal tourné ? »

Dans un workflow multi‑étapes, vous obtenez quasi automatiquement :

• des points de journalisation : step_started, step_completed, step_failed,
• des points clairs de mesure de conversion (combien de personnes atteignent l’étape 3),
• des problèmes localisés : « ça plante uniquement à l’étape de génération d’idées ».

Tout cela sera utile dans le module sur l’analytique de workflow, mais il est déjà utile de s’habituer à penser en étapes.

4. Types d’étapes dans un workflow et à quoi elles ressemblent dans l’UI

Nous avons déjà discuté des raisons de découper en étapes. Maintenant organisons les étapes elles‑mêmes et voyons quels « blocs » types reviennent le plus souvent dans une ChatGPT App. Pour éviter de tomber dans un ensemble chaotique d’écrans, il est pratique d’avoir une « bibliothèque » de types d’étapes. Dans votre App, plusieurs patrons vont presque toujours se répéter.

Voici un tableau de base :

Il faut garder à l’esprit : la même étape logique peut se manifester à la fois dans l’UI et dans un dialogue purement textuel. Par exemple, l’étape « collecte des centres d’intérêt » peut être :

• soit un formulaire avec des tags « sport », « jeux de société », « cuisine »,
• soit une conversation dans laquelle GPT demande doucement : « Et quels sont ses centres d’intérêt ? ».

Souvent, la meilleure option est un hybride : GPT pose une question, l’utilisateur répond en texte, et en même temps peut cliquer des chips dans le widget.

5. Qui « conduit » le workflow : GPT, le widget ou le serveur ?

Intuitivement, on a envie de dire : « Bien sûr le widget, nous sommes des front‑end devs, on contrôle tout via le state ». Mais dans le monde des ChatGPT Apps, ça ne marche pas comme ça. Un workflow est un travail conjoint des trois participants.

GPT comme orchestrateur

GPT :

• conduit le dialogue, pose des questions,
• décide quand on peut considérer l’étape terminée,
• choisit quand appeler un outil (par exemple, « il est temps de générer des cadeaux »).

Pour lui, votre workflow ressemble à un ensemble de sous‑tâches. Dans le system‑prompt, vous pouvez décrire quelles sous‑tâches existent et dans quel ordre les exécuter en général, tout en laissant au modèle la liberté d’adapter légèrement la séquence.

Exemple de mini‑instruction dans le system‑prompt pour GiftGenius (pseudo‑code, sans syntaxe exacte) :

1. D’abord préciser le profil du destinataire (âge, relation, centres d’intérêt).
2. Ensuite préciser le budget.
3. Quand les données sont suffisantes — appeler l’outil suggest_gifts.
4. Après réception des candidats — aider l’utilisateur à choisir.

L’essentiel : GPT ne connaît pas (et ne doit pas connaître) les détails de vos composants React. Il manipule les étapes en termes d’objectifs : « collecter le profil », « proposer des idées ».

Le widget comme « visage » de l’étape

Le widget :

• affiche précisément l’étape pertinente du moment,
• stocke l’état UI (carte sélectionnée, onglet ouvert, champs du formulaire locaux),
• peut afficher un indicateur de progression par étapes.

Une représentation minimale du workflow UI en code :

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type GiftWidgetState = {
  step: GiftWorkflowStep;
  selectedGiftId?: string;
};

Dans le widget React, vous pouvez stocker cet état soit dans un useState classique, soit, si vous voulez le lier au cycle de vie du widget dans ChatGPT, utiliser useWidgetState depuis l’Apps SDK.

const [widgetState, setWidgetState] = useState<GiftWidgetState>({
  step: "profiling",
});

Les gestionnaires (handlers) du widget ne vont pas « acheter un cadeau » directement, mais changer d’étape et renvoyer les données nécessaires au modèle/back‑end.

Les outils MCP comme « mains » du workflow

Le serveur MCP :

• stocke l’état métier (profil, historique des choix),
• valide les étapes (« impossible de passer à Checkout s’il n’y a pas de cadeau sélectionné »),
• exécute le travail lourd : recherche dans le catalogue, calcul des prix, intégration avec l’ACP.

Par exemple, il est plus logique que la décision « quels cadeaux afficher » soit prise non pas dans le widget, mais dans l’outil MCP suggest_gifts, afin que le modèle puisse l’appeler plusieurs fois lors des affinages.

Vous obtenez ainsi une séparation :

• GPT — texte et séquençage,
• widget — représentation visuelle de l’étape actuelle,
• MCP — données et invariants.

6. Comment décrire un workflow dans le code : mini machine à états

Vous vous souvenez du diagramme d’états pour GiftGenius au début du cours ? Nous allons maintenant écrire la même logique sous forme de types et de fonctions simples — une mini machine à états dans le code. Il ne s’agit pas de transformer votre App en cours théorique sur les automates finis, mais quelques types et fonctions simples simplifient beaucoup la vie.

Types d’étapes et configuration

Commençons par une description déclarative des étapes. Reprenons le type GiftWorkflowStep (pour la clarté) et décrivons sa configuration :

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type StepConfig = {
  label: string;
  isFinal?: boolean;
};

export const GIFT_WORKFLOW_STEPS: Record<GiftWorkflowStep, StepConfig> = {
  profiling: { label: "Destinataire" },
  budget: { label: "Budget" },
  candidates: { label: "Candidats" },
  checkout: { label: "Commande", isFinal: true },
};

On peut maintenant ajouter une simple fonction de transition :

export function getNextStep(
  current: GiftWorkflowStep
): GiftWorkflowStep | null {
  switch (current) {
    case "profiling":
      return "budget";
    case "budget":
      return "candidates";
    case "candidates":
      return "checkout";
    default:
      return null; // fin
  }
}

Cela vous apporte déjà :

• une liste centralisée des étapes,
• des règles de transition explicites,
• la possibilité de changer rapidement l’ordre et la logique.

Utilisation dans le widget

La version la plus simple de « l’assistant » dans votre widget peut ressembler à ceci :

function GiftWizard() {
  const [step, setStep] = useState<GiftWorkflowStep>("profiling");

  const handleStepComplete = () => {
    const next = getNextStep(step);
    if (next) setStep(next);
  };

  return (
    <div>
      <ProgressBar step={step} />
      <StepContent step={step} onComplete={handleStepComplete} />
    </div>
  );
}

Le composant StepContent sait rendre différents sous‑formulaires selon l’étape :

function StepContent(props: {
  step: GiftWorkflowStep;
  onComplete: () => void;
}) {
  const { step, onComplete } = props;

  if (step === "profiling") {
    return <ProfilingStep onNext={onComplete} />;
  }
  if (step === "budget") {
    return <BudgetStep onNext={onComplete} />;
  }
  if (step === "candidates") {
    return <CandidatesStep onNext={onComplete} />;
  }
  return <CheckoutStep />;
}

Notez : ici, nous ne touchons pas encore à la façon dont GPT choisit l’étape — c’est une logique UI locale. Plus tard, vous pouvez synchroniser ce step avec l’état serveur ou des messages d’outils, mais pour comprendre la multi‑étapes, cela suffit.

7. Faire évoluer l’application d’apprentissage : du « méga‑formulaire » à l’assistant

Imaginons qu’avant ce cours, votre widget GiftGenius ressemblait à un « grand formulaire » :

• nom du destinataire,
• âge,
• centres d’intérêt,
• budget,
• type d’événement,
• cases à cocher « livraison nécessaire » et cinq autres champs,
• et en bas un gros bouton « Trouver un cadeau ».

Pour un prototype, c’est souvent OK, mais dès que vous voulez un scénario produit — il est temps de découper en étapes.

Avant

Exemple caricatural :

// Anti‑pattern : un seul formulaire gigantesque
function GiftFormAllInOne() {
  return (
    <form>
      {/* 10+ champs mélangés */}
      {/* ... */}
      <button type="submit">Trouver un cadeau</button>
    </form>
  );
}

Problèmes typiques :

• l’utilisateur ne sait pas quels champs sont obligatoires,
• on ne sait pas combien de temps cela prendra,
• il est plus difficile pour GPT d’expliquer à l’utilisateur ce qui s’est passé et de faire un suivi (follow‑up).

Après : un assistant en trois écrans

Étape 1 — séparer le profil du budget :

function ProfilingStep(props: { onNext: () => void }) {
  const [recipientType, setRecipientType] = useState("");
  const [interests, setInterests] = useState<string[]>([]);

  const handleSubmit = () => {
    // on peut appeler ici l’outil d’enregistrement du profil
    props.onNext();
  };

  return (
    <div>
      <h3>Pour qui cherchons‑nous un cadeau ?</h3>
      {/* paires de boutons radio / chips pour le type et les centres d’intérêt */}
      <button onClick={handleSubmit}>Suivant</button>
    </div>
  );
}

Étape 2 — budget :

function BudgetStep(props: { onNext: () => void }) {
  const [budget, setBudget] = useState<number | null>(null);

  const handleSubmit = () => {
    // on peut appeler l’outil de validation du budget
    props.onNext();
  };

  return (
    <div>
      <h3>Quel est votre budget ?</h3>
      {/* slider ou champ de saisie */}
      <button onClick={handleSubmit} disabled={!budget}>
        Proposer des options
      </button>
    </div>
  );
}

Étape 3 — liste des candidats :

function CandidatesStep(props: { onNext: () => void }) {
  const [selectedId, setSelectedId] = useState<string | null>(null);

  // ici vous affichez déjà des cartes de cadeaux
  // et permettez d’en choisir une

  return (
    <div>
      <h3>Choisissez l’option qui convient</h3>
      {/* cartes avec onClick = setSelectedId */}
      <button onClick={props.onNext} disabled={!selectedId}>
        Passer à la finalisation
      </button>
    </div>
  );
}

Oui, il y a un peu plus de code, mais la logique est plus simple :

• chaque étape résout une petite tâche,
• le modèle peut commenter séparément les transitions entre étapes,
• vous pouvez journaliser/mesurer chaque étape individuellement.

8. Anti‑patterns : comment éviter de transformer un workflow en monstre

La pratique et l’observation d’Apps similaires montrent plusieurs erreurs typiques à éviter absolument.

Premièrement, n’essayez pas de « tout dessiner » avec un diagramme BPMN complexe où l’on a 30 états, 40 flèches et une affiche en A0. Dans le contexte des ChatGPT Apps, une échelle d’étapes intuitive est plus importante qu’une notation formelle. Des diagrammes comme celui que nous avons dessiné pour GiftGenius suffisent largement.

Deuxièmement, ne transformez pas l’App en un immense formulaire, surtout dans un widget inline. L’utilisateur est déjà dans un chat ; l’ajout d’un bloc UI dense doit réduire, et non augmenter, la charge. Si vous pensez « bon, il y a 12 champs, mais ils sont tous importants » — c’est presque toujours le signe qu’il faut découper la tâche.

Troisièmement, n’ajoutez pas d’étapes « pour faire joli ». Chaque étape doit avoir un objectif clair : soit collecter des données, soit réduire le choix, soit faire confirmer quelque chose à la personne. Un écran vide du type « on y est presque » avec un seul bouton « suivant » aide rarement.

Enfin, n’essayez pas de dévoiler toutes les possibilités de l’App dès les premières étapes. Les éléments détaillés comme « filtres avancés », « conditions de livraison particulières » peuvent être ajoutés comme étapes supplémentaires uniquement pour ceux qui en ont réellement besoin.

9. Exercice simple de conception de workflow

Pour mieux ancrer la matière, essayez, sur papier (ou dans l’IDE, mais sans code), de faire ce qui suit.

Choisissez une tâche. Cela peut être :

• le choix d’un cadeau (GiftGenius),
• la réservation d’un voyage,
• l’élaboration d’un plan d’apprentissage de quelque chose.

Découpez‑la en 3 à 5 étapes. Pour chaque étape, décrivez :

• l’objectif : ce qui doit être connu/fait après cette étape,
• le format : ce qui est le plus approprié ici — texte pur par GPT, widget, ou combinaison.

Par exemple, pour un « plan d’apprentissage TypeScript » simple :

1. Étape « Évaluation du niveau » — dialogue (GPT pose quelques questions) + court formulaire d’auto‑évaluation.
2. Étape « Objectifs » — discussion textuelle + cases à cocher d’objectifs dans le widget.
3. Étape « Plan » — génération du plan (liste) + boutons « complexifier/simplifier ».
4. Étape « Confirmation » — bref résumé et bouton « enregistrer le plan ».

Essayez ensuite d’estimer quels outils (tools) pourraient être utilisés à chaque étape, sans entrer dans les détails : l’activation/désactivation des outils et la gestion de l’état sont les sujets des prochains cours de ce module.

10. Erreurs typiques lors du travail avec des workflows multi‑étapes

Erreur n° 1 : tenter de tout résoudre en une seule étape et avec un seul outil.
Il est très tentant de créer un « grand outil intelligent » qui pose les questions, analyse, propose et finalise l’achat. En pratique, cela dégrade l’UX (un seul écran lourd) et la qualité du raisonnement du modèle — trop de responsabilités dans un seul appel. Il est plus simple, plus fiable et moins coûteux en maintenance de découper la tâche en une chaîne de 3 à 5 étapes simples.

Erreur n° 2 : des étapes implicites, cachées dans la tête du développeur.
Parfois, le code semble contenir une séquence d’actions, mais elle n’est explicitée nulle part : pas de types d’étapes, pas de configuration, pas de diagramme. Au final, personne dans l’équipe ne peut expliquer clairement « ce qui se passe dans l’App du début à la fin ». Une description déclarative minimale des étapes et des transitions fait gagner des heures de débogage.

Erreur n° 3 : mélanger étapes UI et logique métier.
Si la logique de transition entre les étapes est enfouie profondément dans les composants React (du style if (isValid && hasBudget && !needsShipping) sur le onClick d’un bouton), il devient difficile de la réutiliser et de la tester. Il vaut mieux disposer d’une « machine à états » relativement explicite, ou au moins d’une fonction getNextStep, et que l’UI l’appelle puis affiche le résultat.

Erreur n° 4 : ignorer le rôle de GPT comme orchestrateur.
Il arrive qu’un développeur essaie de tout contrôler depuis le widget : « je poserai moi‑même toutes les questions, le modèle ne fait que proposer ». Le ChatGPT cesse alors de paraître un assistant vivant et devient un moteur de calcul derrière un formulaire. C’est bien meilleur lorsque GPT communique activement, pousse vers l’étape suivante et initie lui‑même les appels d’outils — et que vous l’aidiez par le design des étapes et des instructions.

Erreur n° 5 : des étapes sans objectif clair.
Parfois, un assistant comporte des « étapes en trop » — pour être honnête, juste parce que c’est plus joli. L’utilisateur voit « Étape 2 sur 5 », mais à cette étape on ne lui demande rien et il ne se passe rien. Ces écrans vides ne font qu’augmenter la perception de complexité. Si une étape ne peut pas se formuler comme « après elle, nous savons X avec certitude » ou « après elle, l’utilisateur a fait Y » — il est probable qu’elle n’est pas nécessaire.

Erreur n° 6 : oublier la progression et l’absence de sentiment de parcours.
La multi‑étapes sans support visuel devient une boîte noire : l’utilisateur ne comprend pas où il en est ni combien il reste. Même un indicateur textuel simple « Étape 2 sur 4 » ou une liste horizontale d’étapes dans l’en‑tête du widget réduit nettement l’anxiété. Ignorer cet effet est l’une des raisons pour lesquelles les gens « décrochent » au milieu du scénario alors qu’il n’y a pas forcément de réelle complexité.