Annuler les appels aux API d’IA : arrêter les tâches abandonnées et libérer les ressources

Fermer un écran ne signifie pas qu’une opération est arrêtée

Lorsqu’une génération est annulée, l’utilisateur s’attend généralement à ce que le travail s’arrête. Pourtant, l’action visible — cliquer sur un bouton, changer d’écran ou cesser d’attendre — décrit uniquement ce qui s’est passé dans l’interface. À elle seule, elle ne prouve rien sur la requête HTTP, le processus du serveur ou le traitement éventuellement effectué par un fournisseur externe. Il s’agit de couches distinctes, chacune pouvant avoir son propre cycle de vie.

Une intégration doit donc préciser ce que signifie « annuler » à chaque frontière. Le navigateur peut cesser d’attendre une réponse ; le serveur peut arrêter une tâche qu’il contrôle ; et une API distante peut proposer — ou non — un mécanisme documenté pour annuler une opération acceptée. Si une couche ne transmet pas le signal ou ne sait pas quelle opération arrêter, le travail peut s’y poursuivre même si l’utilisateur ne voit plus son résultat.

La conséquence pratique est importante : ne présentez pas une annulation comme s’il s’agissait d’une réponse valide, et n’affirmez pas que le fournisseur a arrêté le traitement sans l’avoir vérifié. L’application peut confirmer qu’elle a reçu une demande d’annulation et qu’elle a cessé d’attendre localement. Toute affirmation plus large nécessite des preuves relatives à l’intégration concernée, notamment la documentation du fournisseur et, si possible, un test observable.

Définissez ce qui est annulé avant d’écrire du code

Un signal d’annulation doit avoir une portée explicite. Il peut concerner l’attente de l’interface, une connexion HTTP, une tâche côté serveur ou une opération identifiable dans le service distant. Dans un système simple, vous ne contrôlez peut-être que les deux premiers niveaux. Dans une architecture dotée d’un serveur intermédiaire, l’annulation depuis le navigateur n’arrête pas automatiquement le travail de ce serveur : l’application doit détecter la déconnexion ou recevoir un signal explicite, puis le traduire en action sur la tâche concernée.

Il convient aussi de distinguer les motifs. Une annulation explicite se produit lorsque l’utilisateur demande l’arrêt du travail. Un abandon peut correspondre à une navigation ou à une déconnexion sans action délibérée. Une expiration de délai se produit lorsqu’une échéance configurée est atteinte. Ces trois situations peuvent amener l’application à cesser d’attendre, mais elles ne signifient pas la même chose, ne doivent pas nécessairement être présentées de la même façon et ne permettent pas toujours de savoir si le travail distant a pris fin.

Définissez des états terminaux qui décrivent ce que l’application a vérifié, et non ce qu’elle suppose. Par exemple : terminé, annulation demandée, délai local expiré et déconnexion observée. Si le système peut confirmer une annulation distante à l’aide d’un mécanisme documenté, il peut consigner ce résultat séparément. La distinction entre ces états améliore à la fois l’interface et le diagnostic ultérieur.

Propagez le signal à travers les frontières que vous contrôlez

Dans le navigateur, AbortController permet de créer un signal associé à une requête effectuée avec fetch. Lorsque ce signal est annulé, le client peut interrompre son attente pour cette requête. Cela résout une partie du problème : le code de l’interface cesse de traiter la réponse comme une opération toujours en attente. En soi, cela ne prouve pas qu’une tâche lancée au-delà de la connexion a été arrêtée.

La frontière suivante est souvent le backend. Si le navigateur communique avec un service que vous gérez, ce service a besoin d’une règle pour associer la requête entrante au travail qu’il a lancé. Selon la plateforme et les bibliothèques utilisées, il peut détecter un signal d’annulation, une déconnexion, ou les deux. L’application doit vérifier les capacités réelles de son serveur et de son client HTTP : ne supposez pas qu’une abstraction propage l’annulation simplement parce que l’interface comporte un bouton.

Si le backend appelle une API externe, vérifiez si son client HTTP accepte un signal d’annulation et ce qui se passe lorsqu’on l’utilise. Consultez ensuite la documentation de l’API concernée pour savoir si elle propose un mécanisme qui annule une opération déjà acceptée, ou si seule la connexion locale peut être interrompue. Ce sont des capacités différentes. Certaines API proposent une opération d’annulation explicite pour des opérations précises, mais cela ne permet pas de généraliser aux services de génération d’IA.

Les recommandations de conception des API asynchrones préconisent également qu’une opération en cours puisse être annulée. Il s’agit d’un principe de conception, et non de la garantie que chaque dépendance ou fournisseur implémente cette capacité, ni d’une méthode de propagation entre systèmes. Documentez, couche par couche, qui reçoit le signal, quelle action peut être effectuée et quel résultat peut être observé.

Exemple avec AbortController dans le navigateur

L’exemple ci-dessous envoie une requête vers une route de backend interne et permet au navigateur d’interrompre son attente. Il suppose que cette route reçoit un objet contenant un champ prompt et qu’en cas de réussite, elle renvoie du JSON avec un champ text. Cette route est illustrative : le backend doit implémenter ce contrat et décider séparément comment traiter la requête, propager l’annulation et déterminer ce qu’il peut confirmer au sujet de l’API externe.

La fonction vérifie si le signal est déjà annulé avant de commencer l’envoi et évite de mettre à jour l’interface si l’annulation est enregistrée en premier. Dans une interface réelle, reliez la fonction cancel au bouton correspondant et désactivez-le lorsque l’opération atteint un état terminal. L’exemple ne prouve pas que le backend ou le fournisseur a arrêté le traitement.

async function generate(prompt, output, signal) {
  if (signal.aborted) {
    output.textContent = "Annulation demandée avant l’envoi.";
    return;
  }

  output.textContent = "Génération en cours…";

  try {
    const response = await fetch("/api/generate", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ prompt }),
      signal
    });

    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const result = await response.json();

    if (!signal.aborted) output.textContent = result.text;
  } catch (error) {
    if (signal.aborted || error.name === "AbortError") {
      output.textContent = "L’attente de la réponse a été interrompue.";
      return;
    }
    output.textContent = "La requête n’a pas pu aboutir.";
  }
}

const controller = new AbortController();
const task = generate("Résume le document", document.querySelector("#output"), controller.signal);
// Appelez controller.abort() depuis l’action d’annulation.
// Conservez task si vous devez attendre la fin du code local.

Traitez l’expiration de délai comme une échéance, pas comme une preuve d’annulation

Une expiration de délai définit la durée pendant laquelle une couche accepte d’attendre. Il peut y avoir une limite dans l’interface, une autre sur le serveur et une troisième dans le client HTTP qui se connecte au fournisseur. Ces limites doivent être coordonnées délibérément : si une couche abandonne avant une autre sans le lui signaler, l’opération peut continuer à utiliser des ressources dans une couche qui la considère encore comme active.

Lorsqu’un délai expire, consignez quelle horloge a expiré et dans quelle couche. « Délai du navigateur expiré » est plus précis que « le modèle a dépassé le délai », sauf preuve que le service distant a communiqué ce résultat. L’application peut cesser d’attendre, demander l’interruption aux couches qui le permettent et afficher un état d’expiration. Elle ne doit pas transformer cette action en affirmation d’annulation confirmée.

Les conséquences sur l’utilisation ou la facturation dépendent de l’API et de ses conditions. La documentation d’une API donnée peut décrire ce que son mécanisme d’annulation interrompt ; cela ne permet pas d’en déduire le comportement d’un autre endpoint ou d’un autre fournisseur. Si cette conséquence est importante, consultez la documentation officielle propre à l’intégration, vérifiez quelle unité de travail est annulée et validez le résultat par un test contrôlé. Si la documentation ne le précise pas, gardez cette incertitude dans le produit et dans la politique de coûts.

Évitez les états incohérents en cas de concurrence

La réponse et l’annulation peuvent arriver presque en même temps. Si l’interface traite ces événements sans règle commune, elle peut d’abord afficher « annulé », puis remplacer cet état par une réponse tardive. L’inverse est également possible : afficher une réponse alors que l’utilisateur vient de demander l’arrêt de l’opération. Il ne s’agit pas de deviner quel événement s’est produit en premier dans le système distant, mais de définir quel état terminal doit prévaloir dans l’application.

Une règle simple pour l’interface consiste à empêcher toute mise à jour ultérieure d’une opération dès que sa première transition terminale a été enregistrée. Une autre possibilité est d’attribuer un identifiant à chaque requête et d’ignorer les réponses qui concernent une opération qui n’est plus active. Le choix doit être cohérent avec le produit : si une réponse terminée peut être conservée malgré une annulation tardive, cette règle doit aussi être explicite.

Ne confondez pas l’affichage et la réalité opérationnelle. L’interface peut marquer l’opération comme annulée localement alors que le backend consigne que l’annulation distante n’a pas pu être confirmée. Lorsque c’est pertinent, conservez ces informations séparément dans les journaux ou les états internes. Vous éviterez ainsi qu’une réponse tardive semble prouver que l’annulation a été annulée, ou que la fermeture d’une connexion semble prouver la fin du travail.

Testez chaque étape et chaque frontière

Un test qui clique sur « Annuler » après l’affichage d’une réponse ne vérifie pas l’annulation pendant le travail. Concevez des cas distincts pour les moments pertinents et observez à la fois l’interface et le backend. S’il existe une API externe, ne vérifiez que ce que l’intégration et sa documentation permettent d’observer ; la disparition du résultat à l’écran ne prouve pas que le fournisseur a cessé le traitement.

Ajoutez un cas d’annulation avant l’envoi : si le signal est déjà annulé lorsque la fonction est appelée, la requête ne devrait pas démarrer. Testez également l’annulation après le lancement de la requête mais avant la réception d’une réponse, ainsi que pendant une réponse en cours si l’endpoint utilise un mode qui permet d’observer cet intervalle. Vérifiez le comportement à la fermeture ou à l’abandon de la vue conformément à la politique définie par le produit.

Enfin, introduisez une concurrence entre réponse et annulation et vérifiez que l’état terminal est déterministe. Pour une expiration de délai, vérifiez qu’elle est enregistrée comme telle et non comme une action explicite de l’utilisateur. Dans chaque test, contrôlez s’il reste des tâches et des connexions locales ouvertes et si le backend maintient du travail actif. S’il est impossible d’inspecter une activité distante, consignez cette limite au lieu d’affirmer qu’elle a été arrêtée.

Vérifiez les ressources et les conséquences avant le déploiement

La vérification doit couvrir toute la chaîne, et pas seulement le code du bouton. Confirmez que le client HTTP local peut recevoir un signal d’annulation, que le backend associe ce signal à la bonne tâche et que le mécanisme distant — s’il existe — correspond à l’endpoint et au type d’opération utilisés. Les capacités d’annulation propres à un produit ne prouvent pas qu’une autre API du même fournisseur, ou celle d’un autre fournisseur, se comporte de façon équivalente.

Vérifiez également le nettoyage local : les tâches auxiliaires, les écouteurs, les connexions et les références associées à une requête ne doivent pas rester actifs sans raison connue. Dans les services qui traitent plusieurs requêtes simultanément, assurez-vous qu’un signal n’annule que l’opération concernée et non une tâche partagée avec d’autres utilisateurs. Consignez les identifiants d’opération et les états finaux afin de pouvoir reconstituer ce qui a été demandé et ce qui a été confirmé.

Avant toute affirmation sur les coûts, l’utilisation ou le traitement distant, consultez la documentation officielle de l’intégration et effectuez des tests limités, conformes à ses conditions. Une API d’appels par lots, par exemple, documente une opération d’annulation pour ses appels et ses destinataires ; c’est une preuve concernant cet endpoint, pas la génération de texte. Maintenez cette distinction dans la conception, les tests et les communications aux utilisateurs.

En définitive : dites ce que vous savez et vérifiez ce que vous ignorez

Le modèle essentiel est simple, même si sa mise en œuvre dépend de l’architecture : consignez le motif, propagez le signal dans les couches que vous contrôlez, appliquez une politique d’états déterministe et vérifiez quelles ressources restent actives. AbortController peut aider à interrompre l’attente dans le navigateur ; il ne remplace ni l’annulation côté backend ni le mécanisme distant qu’une API peut proposer.

Avant d’intégrer un service, répondez par écrit aux questions suivantes : la bibliothèque HTTP prend-elle en charge l’annulation ? Le backend détecte-t-il l’abandon ? L’API externe dispose-t-elle d’une opération documentée pour arrêter une tâche acceptée ? Qu’observe-t-on après l’utilisation de ce mécanisme ? Que sait-on de l’utilisation et de la facturation ? Si une réponse manque, consignez l’incertitude et évitez de promettre davantage que ce que l’intégration démontre.

Bien annuler ne signifie pas garantir que tout travail disparaît à toutes les couches. Cela signifie disposer d’états clairs, interrompre ce que l’application peut interrompre, libérer les ressources locales, tester les situations de concurrence et communiquer honnêtement la portée de chaque action.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.