Analytique UX du workflow : mesurer l’efficacité des étapes

1. Pourquoi mesurer un workflow, tout simplement

En bref : sans analytics vous vivez en mode « il me semble », et non en mode « je sais ».

Dans les leçons précédentes de ce module, nous avons déjà découpé le scénario en étapes, distribué les rôles entre GPT, le widget et le MCP, discuté du tool gating et de la persistance d’état entre les étapes. Regardons maintenant la même construction avec des yeux d’analyste : est‑ce que tout cela fonctionne comme prévu, et où les utilisateurs se bloquent réellement.

Sur le Web classique, tout le monde est habitué aux entonnoirs : combien de personnes arrivent sur la landing, combien ajoutent un produit au panier, combien vont jusqu’au paiement. Dans ChatGPT App, c’est la même chose, sauf qu’au lieu de pages vous avez des étapes du workflow, et au lieu d’un « clic sur le bouton Acheter » — une combinaison de message utilisateur, d’appel d’outil et d’interaction avec le widget.

Quand vous construisez un scénario complexe sans métriques, vous ne voyez pas :

• à quelle étape les gens « abandonnent » le plus souvent ;
• où ils restent bloqués et lisent pendant une minute (ou sont simplement partis se faire un thé et ne sont pas revenus) ;
• quelle étape n’apporte aucune valeur et ne fait qu’irriter ;
• comment les changements dans les prompts ou le tool gating influencent le comportement.

L’objectif de l’analytics par étapes est simple : apprendre à augmenter la part de scénarios terminés, réduire le temps jusqu’au résultat et diminuer le nombre d’erreurs et de sollicitations du support.

À partir de maintenant, un workflow n’est pas seulement un objet d’architecture ou une quête UX. C’est aussi un élément mesurable avec des chiffres.

2. L’entonnoir de scénario dans ChatGPT App

Dans le Web classique, l’entonnoir est linéaire : Landing → Product → Cart → Checkout. Dans ChatGPT App, l’image est un peu plus mouvementée : l’utilisateur peut « sauter » une étape avec des mots, le modèle peut parfois passer une étape, et le widget et le texte du dialogue peuvent se désynchroniser.

Néanmoins, l’idée de base reste la même : nous avons une séquence d’étapes, et à chacune d’elles une partie des utilisateurs avance, une autre — non.

Prenons notre GiftGenius :

1. collect_recipient — ChatGPT et le widget collectent les données de base sur le destinataire (sexe, âge, relation, centres d’intérêt).
2. collect_budget — on précise le budget et la devise.
3. suggest_ideas — MCP / agent sélectionne des idées et renvoie des cartes cadeaux dans le widget.
4. review_selection — l’utilisateur aime / masque des idées et choisit 1–2 favoris.
5. checkout — un commerce intent est créé, la commande est effectuée.

On peut dessiner cela sous forme d’entonnoir ainsi :

flowchart TD
    A[Début du workflow] --> B["1\. Destinataire"]
    B --> C["2\. Budget"]
    C --> D["3\. Idées de cadeaux"]
    D --> E["4\. Choix du cadeau"]
    E --> F["5\. Checkout"]

Mais il est important de se rappeler : l’utilisateur peut écrire dans le chat « Allons directement au paiement » ou « Montre d’abord les options chères », et le modèle peut décider de sauter certaines étapes. Par conséquent, l’analytics par étapes dans ChatGPT App ne concerne pas seulement les écrans UI, mais aussi le comportement du modèle : quelles étapes sont réellement parcourues, dans quel ordre, et qui a initié la transition — l’utilisateur, le widget ou GPT.

3. Les métriques de base par étape

Commençons par les classiques de l’analytics produit et adaptons‑les un peu à ChatGPT App.

Pour chaque workflow, nous avons besoin d’au moins quatre indicateurs de base.

Pour plus de clarté, rassemblons‑les dans un tableau :

On y ajoute presque toujours des métriques d’effort :

• le temps moyen par étape (où les gens « restent bloqués ») ;
• le nombre d’interactions à l’étape (combien de messages / clics nécessaires) ;
• la part d’étapes qui se terminent par une erreur ou nécessitent une nouvelle tentative.

Dans le contexte des scénarios LLM, s’ajoutent des choses encore plus spécifiques, comme la précision du choix de l’outil par le modèle, ou la part de réponses « hallucinées » à une étape précise — mais cela relève d’un niveau avancé, que nous aborderons dans les modules finaux.

Pour les scénarios de commerce, on superpose des métriques business :

• conversion en paiement depuis le départ du workflow ;
• conversion en paiement depuis une étape spécifique (par exemple, depuis « sélection d’idées ») ;
• panier moyen ;
• part des annulations / retours.

Important : tous ces chiffres ne vivent pas isolément, une histoire causale les relie. Une étape avec un fort drop‑off n’est pas toujours mauvaise : peut‑être filtre‑t‑elle des utilisateurs non pertinents et seuls ceux pour qui le scénario est réellement utile avancent. L’analytics, ce n’est pas juste « calculer des pourcentages », c’est savoir raconter une histoire à partir des données.

Pour pouvoir calculer ces pourcentages et ces entonnoirs, il nous faut des événements bruts : qui, quand et quelle étape a été faite (ou non). Dans la section suivante, mettons‑nous d’accord sur le format de ces événements.

4. À quoi ressemblent les événements d’analytics

Avant d’écrire du code, il faut se mettre d’accord sur le format de « l’événement » (event) que nous enverrons depuis le widget et le backend.

Un événement analytique contient généralement :

• qui : identifiant de l’utilisateur, ou au moins de la session ;
• quel workflow et quelle version ;
• quelle étape ;
• ce qui s’est passé (type d’événement) ;
• si cela a réussi, combien de temps cela a pris ;
• un peu de métadonnées (locale, device, etc.).

On peut décrire un schéma simplifié d’événements pour un workflow ainsi :

export type WorkflowEventType =
  | "workflow_started"
  | "workflow_finished"
  | "step_started"
  | "step_completed"
  | "step_failed";

export interface WorkflowAnalyticsEvent {
  eventId: string;              // uuid
  timestamp: string;            // chaîne ISO
  userId?: string;              // si la désanonymisation est possible
  conversationId?: string;      // ID de conversation ChatGPT (si disponible)
  workflowId: string;           // notre identifiant interne
  workflowType: "gift_selection";
  workflowVersion: string;      // par exemple, "1.2.0" ou "1.2.0-A"
  stepName?: string;            // collect_budget, suggest_ideas, etc.
  eventType: WorkflowEventType;
  toolName?: string;            // si lié à un appel d’outil
  success?: boolean;
  errorCode?: string | null;
  durationMs?: number;
  metadata?: Record<string, unknown>;
}

Quelques nuances :

Premièrement, workflowVersion est très important si vous comptez faire des tests A/B : sans lui, vous ne saurez jamais quelle variante du scénario donne les meilleurs chiffres.

Deuxièmement, conversationId ou un autre ID de corrélation permet de relier les événements : étapes dans le widget, appels d’outils dans le MCP et dialogue textuel. Dans les modules suivants, nous parlerons encore de traçabilité et d’observabilité, mais l’habitude de penser dès le départ à des identifiants « de bout en bout » est très utile.

Troisièmement, n’embarquez pas tout et n’importe quoi dans l’événement : mieux vaut éviter les textes complets des messages, e‑mails, adresses et autres PII, ou les anonymiser strictement — nous en reparlerons vers la fin.

5. Instrumentation dans le widget (Next.js + Apps SDK)

Passons au plus intéressant : comment faire pour que notre widget GiftGenius rapporte discrètement les étapes quand l’utilisateur parcourt le scénario.

Supposons que, dans les leçons précédentes, vous ayez déjà fait quelque chose comme :

// components/GiftWizard.tsx
type StepId = "recipient" | "budget" | "ideas" | "review" | "checkout";

export function GiftWizard() {
  const [currentStep, setCurrentStep] = useState<StepId>("recipient");
  const [workflowId] = useState(() => crypto.randomUUID());

  // ... rendu des différentes étapes
}

Ajoutons une petite « couche d’analytics » sous forme de hook.

Hook useWorkflowAnalytics

Faisons un wrapper qui connaît workflowId, workflowVersion et sait envoyer un événement à notre route d’API Next.js /api/workflow-analytics.

// lib/useWorkflowAnalytics.ts
import { useCallback } from "react";
import type { WorkflowAnalyticsEvent, WorkflowEventType } from "./types";

const WORKFLOW_VERSION = "1.0.0";

export function useWorkflowAnalytics(
  workflowId: string,
  workflowType: WorkflowAnalyticsEvent["workflowType"] = "gift_selection"
) {
  const sendEvent = useCallback(
    async (payload: Omit<WorkflowAnalyticsEvent, "eventId" | "timestamp" | "workflowType" | "workflowVersion" | "workflowId">) => {
      const event: WorkflowAnalyticsEvent = {
        eventId: crypto.randomUUID(),
        timestamp: new Date().toISOString(),
        workflowId,
        workflowType,
        workflowVersion: WORKFLOW_VERSION,
        ...payload,
      };

      // envoi simple vers l’API ; en prod on peut ajouter un buffer/debounce
      await fetch("/api/workflow-analytics", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(event),
      });
    },
    [workflowId, workflowType]
  );

  const trackStepEvent = useCallback(
    async (stepName: string, eventType: WorkflowEventType, extra?: Partial<WorkflowAnalyticsEvent>) => {
      await sendEvent({ stepName, eventType, ...extra });
    },
    [sendEvent]
  );

  return { sendEvent, trackStepEvent };
}

Ici, il est important que le hook ne dépende d’aucune étape UI concrète. Il sait simplement ce que sont stepName et eventType. Les composants concrets vont lui dire : « j’ai commencé l’étape », « je l’ai terminée », etc.

Envoyer workflow_started et workflow_finished

Dans le composant GiftWizard, on peut, au moment du montage et du démontage, enregistrer le début et la fin du scénario :

// components/GiftWizard.tsx
export function GiftWizard() {
  const [currentStep, setCurrentStep] = useState<StepId>("recipient");
  const [workflowId] = useState(() => crypto.randomUUID());
  const { sendEvent } = useWorkflowAnalytics(workflowId);

  useEffect(() => {
    void sendEvent({ eventType: "workflow_started" });
    return () => {
      void sendEvent({ eventType: "workflow_finished" });
    };
  }, [sendEvent]);

  // ...
}

Bien sûr, terminer au démontage est une approximation grossière : l’utilisateur peut simplement réduire le chat ou partir dans un autre dialogue. Mais même une métrique aussi grossière donne déjà une idée du nombre de scénarios qui « vont quelque part ».

Suivre les événements par étape

Faisons maintenant en sorte que chaque étape informe elle‑même l’analytics. Pour commencer, ajoutons un simple wrapper :

interface StepProps {
  stepId: StepId;
  onNext: () => void;
  trackStepEvent: (stepName: string, eventType: WorkflowEventType, extra?: Partial<WorkflowAnalyticsEvent>) => Promise<void>;
}

function StepRecipient({ stepId, onNext, trackStepEvent }: StepProps) {
  useEffect(() => {
    void trackStepEvent(stepId, "step_started");
  }, [stepId, trackStepEvent]);

  const handleSubmit = async () => {
    // ... validation, sauvegarde dans widgetState
    await trackStepEvent(stepId, "step_completed");
    onNext();
  };

  return (
    <div>
      {/* champs du destinataire */}
      <button onClick={handleSubmit}>Suivant</button>
    </div>
  );
}

Dans GiftWizard, on passe trackStepEvent :

export function GiftWizard() {
  // ...
  const { trackStepEvent } = useWorkflowAnalytics(workflowId);

  const goToNext = () => {
    setCurrentStep((prev) => NEXT_STEP[prev]);
  };

  if (currentStep === "recipient") {
    return (
      <StepRecipient
        stepId="recipient"
        onNext={goToNext}
        trackStepEvent={trackStepEvent}
      />
    );
  }

  // autres étapes...
}

De même, dans les étapes où des erreurs potentielles existent (par exemple, une requête vers une API externe dans suggest_ideas), on peut, en cas d’échec, envoyer "step_failed" avec errorCode, et en cas de chargement réussi des options — "step_completed".

Cela nous donne :

• une liste d’événements claire : quand les étapes commencent et se terminent ;
• la possibilité de calculer le temps d’une étape : la différence entre "step_started" et "step_completed" ;
• la visibilité sur les étapes qui se terminent le plus souvent par "step_failed".

6. Instrumentation côté backend / MCP

L’analytics côté client, c’est bien, mais le widget vit dans un monde assez fragile : navigateur de l’utilisateur, iframe, contraintes de sandboxing, etc. Il est donc utile de journaliser les événements en parallèle côté serveur — dans les outils MCP ou l’API backend de votre app.

Par exemple, vous avez un outil suggest_gifts qui fait le travail lourd : interroger le product feed, appliquer des filtres et renvoyer des cadeaux. À l’intérieur d’un tel outil, vous pouvez journaliser à la fois la logique métier et les événements analytiques.

Un gestionnaire MCP‑tool en TypeScript pourrait ressembler à ceci :

// mcp/tools/suggestGifts.ts
import type { SuggestGiftsArgs } from "../schemas";
import { logWorkflowEvent } from "../analytics/log";

export async function handleSuggestGifts(args: SuggestGiftsArgs, context: { workflowId: string; stepName: string }) {
  const startedAt = Date.now();

  try {
    // ... logique principale de sélection des idées

    await logWorkflowEvent({
      workflowId: context.workflowId,
      workflowType: "gift_selection",
      workflowVersion: "1.0.0",
      stepName: context.stepName,
      eventType: "step_completed",
      toolName: "suggest_gifts",
      success: true,
      durationMs: Date.now() - startedAt,
    });

    return {
      content: [{ type: "text", text: "J’ai trouvé 5 idées de cadeaux." }],
      _meta: {
        // données brutes pour le widget
      },
    };
  } catch (e) {
    await logWorkflowEvent({
      workflowId: context.workflowId,
      workflowType: "gift_selection",
      workflowVersion: "1.0.0",
      stepName: context.stepName,
      eventType: "step_failed",
      toolName: "suggest_gifts",
      success: false,
      errorCode: "SUGGEST_FAILED",
      durationMs: Date.now() - startedAt,
    });
    throw e;
  }
}

Et logWorkflowEvent peut écrire dans la même table/le même stockage que celui où arrivent les événements du front, avec simplement un marqueur "source" : "backend".

Pourquoi l’analytics côté serveur est plus fiable

Premièrement, un appel d’outil a eu lieu ou non — c’est un fait clair, pas une heuristique du style « l’utilisateur a appuyé sur le bouton, probablement ».

Deuxièmement, il est plus facile d’agréger les données sur le serveur : vous pouvez compter combien de fois chaque outil est appelé, son durationMs moyen, et quelle part des appels se termine par une erreur.

Troisièmement, vous voyez la différence entre un problème UX (l’utilisateur n’atteint pas l’étape où l’outil est appelé) et un problème technique (on atteint l’étape, mais l’outil échoue souvent).

7. Comment lire les données : trouver les goulots d’étranglement

Supposons que vous ayez déjà implémenté l’envoi des événements "workflow_started", "step_started", "step_completed" et "step_failed" depuis le widget et le MCP, et que suffisamment de données se soient accumulées dans votre stockage. Imaginons que vous ayez déjà collecté un certain volume de données pour GiftGenius et obtenu des statistiques synthétiques par étape. Le tableau ci‑dessous présente des chiffres fictifs pour 1000 workflows lancés :

Que faut‑il regarder ici :

Premièrement, l’étape budget — est un goulot d’étranglement évident. Fort abandon (26 %) et temps moyen nettement plus élevé. Peut‑être que vous posez trop de questions sur les devises/taxes, que les formulations sont floues, ou que les gens ne sont tout simplement pas sûrs de leur budget. C’est un bon candidat pour simplifier l’étape, la scinder en deux sous‑étapes, ou modifier les formulations.

Deuxièmement, review provoque aussi beaucoup d’abandons. Peut‑être que l’UI des cartes cadeaux est trop chargée, ou que l’utilisateur ne comprend pas ce que signifie « liker » un cadeau. Il se peut que le modèle renvoie trop d’options et que le widget ressemble à une liste interminable. Il faut alors regarder non seulement les chiffres, mais aussi des captures d’écran / enregistrements de sessions (si vous en faites), ou au moins parcourir le scénario à la main comme un utilisateur.

Troisièmement, checkout perd 16 % — pour un scénario de commerce, c’est beaucoup d’argent. Mais il faut comprendre où ils se perdent : lors de la saisie de la commande, à cause d’erreurs du fournisseur de paiement, ou parce que l’utilisateur a simplement changé d’avis. Ce n’est plus une question purement UX, mais un mélange UX + contraintes business.

Il est important de savoir distinguer problèmes d’UI et problèmes de modèle.

• Si les utilisateurs reviennent souvent à l’étape précédente et modifient leurs réponses — c’est un signal d’une question incomprise ou mal formulée.
• Si l’étape se termine rapidement mais que l’appel d’outil qui s’y trouve échoue souvent — c’est un problème backend/MCP.
• Si l’étape dure longtemps sans erreurs ni retours, il est possible que l’utilisateur lise un long texte dont il n’a pas vraiment besoin.

8. Expériences et tests A/B du workflow

Les chiffres, en eux‑mêmes, n’améliorent rien. Pour que l’analytics serve à quelque chose, il faut savoir mener des expériences : modifier les étapes et comparer si cela s’est amélioré.

Dans le contexte de ChatGPT App, l’expérience typique consiste à comparer deux versions d’une étape ou d’une séquence d’étapes :

• un wizard long avec plusieurs écrans simples versus un formulaire complexe unique ;
• différentes formulations des questions ;
• un ordre différent des étapes (par exemple, demander le budget plus tôt ou plus tard) ;
• différentes stratégies de tool gating (moins d’outils à la première étape, plus à la seconde).

La bonne pratique — est de figer la version du scénario dans workflowVersion et d’y ajouter l’identifiant de l’expérience, par exemple "1.3.0-A" et "1.3.0-B".

Un split A/B tout simple dans le widget

En production, vous voudrez bien sûr un assignement stable au niveau de l’utilisateur ou de la session (via le backend), mais pour un exemple pédagogique, un choix aléatoire suffit.

// lib/useWorkflowVariant.ts
import { useMemo } from "react";

export type WorkflowVariant = "A" | "B";

export function useWorkflowVariant(): WorkflowVariant {
  return useMemo(() => {
    return Math.random() < 0.5 ? "A" : "B";
  }, []);
}

Dans GiftWizard, on détermine la variante et on la transmet à l’analytics :

export function GiftWizard() {
  const [workflowId] = useState(() => crypto.randomUUID());
  const variant = useWorkflowVariant();
  const { sendEvent, trackStepEvent } = useWorkflowAnalytics(
    workflowId,
    "gift_selection"
  );

  useEffect(() => {
    void sendEvent({
      eventType: "workflow_started",
      metadata: { variant },
    });
  }, [sendEvent, variant]);

  // ensuite on peut modifier les textes/la structure des étapes selon variant
}

Côté serveur, on peut remplacer le "1.0.0" figé par quelque chose comme "1.1.0-A" et "1.1.0-B", ou simplement journaliser metadata.variant et regrouper par celui‑ci dans l’analytics.

Le sens principal d’un test A/B : choisir la métrique cible à l’avance. Par exemple : « nous voulons augmenter le completion rate du scénario de 42 % à 50 % » ou « réduire le temps à l’étape budget de 20 % ». Sans métrique cible, toute restructuration du workflow ressemble à des travaux où « on a déplacé l’armoire, ça a l’air plus joli ».

9. Confidentialité et éthique des données

Nous avons déjà mentionné rapidement que, dans metadata et les événements analytiques, il vaut mieux ne pas envoyer de PII en clair. Quand on discute de métriques, on peut vite s’emballer et commencer à tout journaliser. Mais rappelez‑vous que vous travaillez dans ChatGPT, et l’utilisateur est en droit d’attendre que ses messages personnels ne partent pas en externe à l’état brut.

Quelques règles simples à suivre dès maintenant, avant les modules sur la sécurité et le Store :

• Premièrement, ne journalisez pas les textes complets des messages utilisateur. À la place, on peut conserver la longueur du message, le type de réponse (nombre, « oui/non », choix dans une liste), ou des indicateurs anonymisés comme « réponse vide / incomplète / modifiée ».
• Deuxièmement, ne journalisez pas d’informations identifiantes (PII) si vous n’en avez pas besoin pour la logique métier : e‑mail, téléphones, adresses, noms complets. Si c’est indispensable, conservez‑les dans un autre périmètre protégé et limitez strictement l’accès.
• Troisièmement, soyez prudent avec le contexte du dialogue. Si vous conservez conversationId, assurez‑vous de ne pas essayer, dans l’analytics, de « recoller » des dialogues distincts en super‑profils sans raison valable et base légale.
• Quatrièmement, prêtez attention aux politiques d’OpenAI et aux exigences du Store (nous couvrirons en détail cela dans les modules sur la publication et la sécurité), qui précisent clairement quelles données peuvent sortir de ChatGPT et lesquelles ne le peuvent pas. Au stade de conception de l’analytics, il est utile d’intégrer dès le départ l’anonymisation et la minimisation des données pour éviter de réécrire la moitié du système plus tard.

Enfin, souvenez‑vous que l’analytics UX n’est pas une surveillance totale et certainement pas un « surveillance » à la Big Brother. Le but — améliorer les scénarios et réduire la frustration de l’utilisateur, pas construire un tableau de bord Big Brother « qui à 2:37 du matin n’a pas atteint le checkout ».

10. Erreurs courantes dans l’analytics UX du workflow

Erreur n° 1 : « Nous ne sommes pas encore en prod, les métriques plus tard ».
Très souvent, les développeurs commencent à penser à l’analytics au moment où l’app est déjà utilisée par de vraies personnes. Résultat : les événements sont ajoutés « a posteriori », les données sont incomplètes et comparer l’ancienne et la nouvelle version du scénario est presque impossible. Il vaut mieux intégrer tout de suite un entonnoir minimal ("workflow_started", "step_started", "step_completed", "workflow_finished"), tant que le code est encore relativement simple.

Erreur n° 2 : Journaliser uniquement les succès et ignorer les erreurs.
Parfois, les logs ne contiennent que "step_completed", et personne n’écrit "step_failed" parce que « eh bien, ça ne devrait pas planter ». Au final, vous voyez que peu de gens atteignent une étape donnée, mais vous ne comprenez pas s’ils sont partis d’eux‑mêmes ou s’ils ont été éjectés par des erreurs. Journalisez toujours la fin réussie d’une étape et la fin en échec, avec au moins un errorCode grossier.

Erreur n° 3 : Absence totale d’ancrage à la version du workflow.
Vous modifiez des textes, l’ordre des étapes, introduisez du tool gating, mais dans les événements, workflowVersion est toujours "1.0.0". Un mois plus tard, vous regardez des graphes et vous ne pouvez pas comprendre ce qui était avant et après les changements. Fixer la version du scénario et, si nécessaire, la variante A/B — est un élément obligatoire de l’analytics.

Erreur n° 4 : Une analytics trop détaillée sans raison.
À l’extrême opposé — construire tout de suite le « schéma d’événements parfait » avec 50 champs, journaliser chaque clic au pixel près et chaque retape de caractère. D’abord, cela peut violer la confidentialité. Ensuite, ces données sont difficiles à analyser et vous vous noierez dans le bruit. Mieux vaut commencer par un petit ensemble d’événements et de métriques qui répondent réellement à des questions produit concrètes, puis faire évoluer le système selon les besoins.

Erreur n° 5 : Incohérence des noms d’étapes et de scénarios.
Parfois, dans le code, l’étape s’appelle budget, dans l’analytics — collect_budget, et dans le rapport — « l’étape avec la question sur l’argent ». Après deux semaines, plus personne ne se souvient de ce qui est quoi. Lors de la conception du workflow, il est utile de se mettre d’accord sur des identifiants d’étapes stables (stepName) et de les utiliser dans l’UI, les logs et les rapports.

Erreur n° 6 : Existence de métriques dont personne ne se sert.
Le cas le plus triste : vous avez collecté proprement une masse de données, configuré l’envoi d’événements depuis le widget et le MCP, mais personne n’ouvre ensuite les dashboards ni ne prend de décisions. L’analytics pour l’analytics ne sert à rien ; posez‑vous toujours la question : « Quelle décision vais‑je pouvoir prendre sur la base de cette métrique ? ». Si vous n’avez pas de réponse — cette métrique ne vous est pas encore nécessaire.