Latence d’un copilote IA : concevoir attente, annulation et mode dégradé

Une technicienne prépare la note de passation d’une intervention. Elle demande une proposition IA, attend, puis choisit de poursuivre seule. Quand la réponse arrive enfin, elle remplace les observations ajoutées entre-temps. Le défaut ne se résume pas à quelques secondes de lenteur : le produit a rendu à une ancienne demande le pouvoir de modifier un travail que l’utilisateur avait repris.

En pratique, l’attente doit conserver un contrat d’interaction. Chaque préparation possède une identité, un contexte et des conditions d’usage. Arrêt, nouvelle demande ou changement de dossier retirent certaines possibilités au retour ancien. La proposition reste séparée de la saisie ; son arrivée ne donne ni permission d’insertion ni preuve d’enregistrement.

Nous suivons une fiche fictive F-16 et six parcours sur un petit écran local. Les événements et réponses sont injectés à la main, sans modèle ni service distant. Les essais au navigateur vérifient des états, des champs et des gestes réels dans cette simulation. Ils ne mesurent pas la latence d’un fournisseur et ne démontrent aucun résultat utilisateur ou arrêt de calcul serveur.

Dans le développement d’un copilote pour une application métier, le cas à traiter est celui du gestionnaire qui continue à rédiger sa note pendant l’attente. Le résultat doit rester une proposition consultable ; son arrivée ne l’autorise pas à remplacer la note modifiée. La recette d’une IA sur mesure pour cet écran doit donc suivre séparément la demande en cours, la version de la source et la version du brouillon.

Pour qui concevoir une attente qui laisse travailler

Identifier les préparations qui concurrencent une saisie

Ce problème concerne une synthèse, une suggestion de réponse, une explication ou un préremplissage demandé pendant une tâche active. L’utilisateur ne quitte pas nécessairement son dossier pour attendre. Il peut ajouter une observation, consulter une pièce, recevoir un appel ou corriger le contexte. La fin du calcul et l’état courant de son travail deviennent deux événements indépendants que le produit doit rapprocher.

Le cas est différent d’un traitement lancé pour produire un rapport plus tard. Une assistance placée dans un écran de saisie porte une promesse immédiate de continuité. Il faut examiner ce que l’utilisateur peut encore faire durant l’attente, ce qui reste enregistré et ce qu’il doit relire à l’arrivée. Une animation agréable ne résout pas cette concurrence entre le travail humain et une proposition ancienne.

Décider quand l’attente cesse de rendre service

Le budget se définit par tâche et conditions d’usage. Pour une passation avant déplacement, rester connecté ne garantit pas que la technicienne puisse attendre. Le produit convient d’un seuil d’information, d’un plafond de préparation et d’un chemin manuel. Ces valeurs viennent d’une décision produit puis d’essais, pas d’un temps universel au-delà duquel toutes les fonctions IA deviendraient inutiles.

Le délai acceptable n’est pas forcément le délai maximal du fournisseur. L’équipe peut interrompre l’usage d’un résultat devenu inutile tout en conservant une observation de sa fin distante. La recette doit donc préciser qui possède le budget et la décision de repli. Elle vérifie aussi que la tâche principale reste possible lorsque l’assistance est fermée, au lieu d’assimiler disponibilité du logiciel et disponibilité de son modèle.

Définir ce qui est préparé et ce qui reste manuel

Limiter la mission à une proposition de note

F-16 présente une intervention et un brouillon de passation. La préparation P-1 reçoit la version 7 de la fiche et la révision 1 du brouillon. Elle doit proposer une formulation dans un panneau séparé. Elle ne change ni statut d’intervention, ni affectation, ni message transmis. Cette portée rend le bouton Arrêter compréhensible : il concerne la préparation locale de la suggestion, pas une opération métier générale.

Le parcours de copilote avec sources, corrections et validation distingue suggestion, saisie et enregistrement. Ici, nous approfondissons la période entre lancement et réception. Une suggestion utile peut arriver trop tard pour être employée telle quelle. Son exactitude éventuelle ne lui rend pas les droits retirés par un arrêt ou un nouveau contexte.

Nommer les états que l’écran et le service doivent partager

Le contrat distingue repos, préparation en cours, attente prolongée, arrêt local, rédaction manuelle, proposition disponible et proposition à réexaminer. Chaque entrée d’événement produit une sortie visible et des gestes ouverts : arrêter pendant la préparation, comparer après une correction, insérer une proposition encore admissible. La responsabilité de ces transitions appartient au produit et à son contrôleur d’écran. Une réponse tardive est un événement à classer dans l’état courant, pas un ordre de revenir à Disponible.

Un service complet garde aussi ses états distants : demande acceptée, calcul commencé, résultat produit, arrêt demandé ou effet inconnu. L’écran peut retirer l’usage d’une préparation avant d’obtenir la confirmation distante. Le vocabulaire utilisateur doit suivre ce que l’application sait réellement. « Préparation arrêtée dans cet écran » est plus précis qu’un succès d’annulation générale lorsque la seule preuve concerne le panneau local.

Séquence fictive : arrêt, saisie et retour tardif

Lire le parcours depuis la tâche de l’utilisateur

Exemple concret : à t=0, P-1 commence sur F-16 v7. Dans cette chronologie illustrative, à t=4 secondes l’écran indique que la préparation se prolonge ; à t=6 la technicienne arrête ; à t=8 elle ajoute « pièce attendue confirmée » ; à t=11 le résultat de P-1 arrive. Ces délais sont choisis pour raconter les événements. Ils ne sont ni une mesure exécutée du fournisseur ni une recommandation de seuil de production.

Distinguer une séquence d’événements d’une mesure de temps

Le petit écran de recette reproduit l’ordre des gestes avec des réponses synthétiques. Il vérifie le champ après l’arrêt puis après le retour. Il n’attend pas onze secondes pour prétendre tester une latence réelle : son contrôle porte sur les transitions. Le test de durée, les délais réseau et les conditions d’usage doivent ensuite utiliser une horloge et un environnement adaptés au produit.

Cas concret complémentaire : P-2 est lancée après P-1 avant tout retour. Le résultat de P-1 est injecté d’abord, puis celui de P-2. Seule la seconde préparation peut fournir la proposition courante. Le test ne déduit pas la bonne demande de l’ordre d’arrivée : il compare son identité à l’identité active. Un résultat rapide peut être ancien ; un résultat lent peut encore être pertinent.

Informer sans inventer une progression

Montrer la phase que l’application peut observer

« Demande reçue » repose sur un accusé de réception. « Recherche des pièces » exige que le service puisse observer cette phase. « Proposition disponible » arrive lorsque le résultat attendu est effectivement utilisable. Une barre qui atteint 90 % sur la seule base du temps écoulé suggère une connaissance de l’avancement que le produit ne possède pas. Elle peut rendre les derniers instants plus frustrants sans apporter de preuve.

Pour F-16, le message dit que la préparation est en cours, puis qu’elle prend plus de temps. Il présente les gestes encore possibles. Si l’application affiche plusieurs phases, elle doit pouvoir rester bloquée, revenir en arrière ou échouer sans inventer une fin imminente. Le lecteur n’a pas besoin d’un décompte technique de tokens pour comprendre s’il peut continuer sa passation.

Éviter de présenter un fragment comme une proposition achevée

Le streaming peut réduire le délai avant le premier affichage tout en laissant le résultat incomplet. Une phrase initiale peut être contredite par une réserve ajoutée ensuite. Le produit distingue contenu partiel et proposition terminée, notamment avant une insertion ou une décision. Un bouton ouvert dès le premier fragment implique une règle de validation du partiel, qu’il faut assumer et tester explicitement.

Une rupture de flux conserve aussi son statut incomplet. La proposition déjà visible ne devient pas complète parce que la connexion a cessé. La politique peut permettre copie ou lecture avec indication de cette limite, mais elle ne transforme pas le dernier fragment en preuve de succès. Dans notre simulation, les résultats arrivent entiers ; aucun essai de flux, ordre de fragments ou reprise de streaming n’est revendiqué.

Donner à l’arrêt une portée vérifiable

Retirer l’usage local avant de promettre l’arrêt distant

Le geste Arrêter retire immédiatement l’identité active dans l’écran et ferme les actions de la proposition. Le retour ancien est alors ignoré pour ce parcours. Une demande d’annulation peut également être transmise au serveur si son contrat le prévoit. Son acceptation, son effet sur le calcul et son coût facturé éventuel sont des questions distinctes à vérifier avec le service concerné.

La documentation MDN d’AbortController.abort() décrit l’interruption d’opérations asynchrones côté navigateur, dont fetch et la consommation de flux. Cela ne démontre pas qu’un travail déjà accepté par un serveur ou fournisseur est arrêté. Notre écran n’effectue aucun fetch ; son test démontre uniquement le retrait local de la préparation et le traitement du retour injecté.

Ne pas confondre préparation arrêtée et action annulée

Une génération de suggestion et l’envoi d’une note sont deux opérations. Si un agent a déjà engagé une action distante, arrêter le panneau ne la défait pas. Le contrat d’outil avec résultat vérifiable traite les états confirmés ou inconnus à cette autre frontière. Le produit doit réserver les verbes Annuler et Retirer aux capacités effectivement démontrées.

Le test d’arrêt devient plus exigeant dès que la préparation produit un objet persistant. Il faut examiner ce qui subsiste, qui y accède et si une reprise peut encore l’utiliser. Un état local Annulé ne constitue pas un nettoyage de cache, de journal ou de stockage distant. La recette doit nommer les effets attendus au lieu d’inférer leur disparition depuis la fermeture de l’animation.

Rattacher chaque retour à sa demande et ses révisions

Vérifier l’identité avant de changer l’écran

L’entrée de réception contient l’identité de préparation et les révisions utilisées. Le contrôleur vérifie qu’une préparation est encore active, qu’il attend son résultat et que l’identité correspond. Sa sortie est soit une proposition admissible, soit un retour écarté avec une trace de motif. Sa responsabilité est de décider avant de mettre à jour le panneau. Il ne suffit pas de vérifier le numéro de fiche : deux préparations sur F-16 peuvent avoir des consignes ou brouillons différents.

{
  "requestId": "P-2",
  "recordId": "F-16",
  "sourceRevision": 7,
  "draftRevision": 1,
  "purpose": "proposer_une_note",
  "effect": "aucune_insertion_automatique"
}

Ce JSON est un contrat illustratif, pas une API standard ni un message réellement renvoyé par un fournisseur. L’application construit les champs de contrôle depuis son contexte. Les informations utiles ne doivent pas dépendre de la capacité du modèle à recopier fidèlement un identifiant. Une réponse qui revient sur un onglet rouvert exige également un rapprochement avec le parcours courant.

Traiter le changement de source sans effacer le travail

Si la fiche passe à la version 8 avant le retour de P-2 préparée sur la version 7, le produit ne présente pas cette sortie comme une synthèse actuelle. Dans notre simulation, il demande une nouvelle préparation et garde le brouillon. Une autre politique pourrait permettre une comparaison explicitement datée, à condition de rendre l’ancienne portée visible et de fermer les actions qui supposent des sources actuelles.

Le contrôle du contexte périmé avant une action ERP approfondit la fenêtre au moment de l’écriture. Le contrôle d’écran améliore l’interaction ; il ne remplace pas le contrôle serveur des versions et permissions à l’enregistrement. Les deux frontières peuvent détecter des changements différents. Leur contrat prévoit une correction ou une relecture plutôt qu’une sauvegarde silencieuse.

Conserver le brouillon et traiter ses changements

Faire de la saisie une contribution indépendante

L’utilisateur peut modifier sa note pendant la préparation. La révision du brouillon augmente et le champ reste sa propriété. À l’arrivée, la proposition est présentée séparément. Notre écran ferme l’insertion directe si la révision a changé : il demande une comparaison avant usage. Le retour ne remplace aucune valeur du champ et ne déplace pas le curseur dans le panneau.

Une vraie interface de comparaison doit ensuite préciser ajout, remplacement et périmètre sélectionné. Il serait insuffisant d’afficher « modifications détectées » puis de réactiver la même insertion globale. La technicienne doit retrouver son observation et comprendre ce que la proposition sait ou ignore. La validation devient un geste sur une différence explicite, au lieu d’une confirmation abstraite de confiance dans l’IA.

Distinguer changement local et sauvegarde du dossier

Le dernier parcours de simulation autorise une insertion explicite lorsque les révisions correspondent. La proposition s’ajoute localement au brouillon ; le statut indique Note non enregistrée. Aucun serveur de persistance n’est présent. Cette précision permet de vérifier le geste sans prétendre avoir testé la sauvegarde, la concurrence entre utilisateurs, l’historique de notes ou la reprise d’un enregistrement dont la réponse a été perdue.

Dans le produit, les champs modifiés, l’état non enregistré et la prochaine action doivent rester perceptibles après l’insertion. Un succès de préparation n’est pas un succès de sauvegarde. Si la fenêtre se ferme ensuite, les règles ordinaires de récupération du brouillon s’appliquent. L’assistance ne devrait pas contourner ces règles ni créer une version persistante invisible pour simplifier le panneau.

Préparer un mode manuel réellement utilisable

Retrouver le parcours classique avec le même dossier

Continuer sans IA retire la préparation active et conserve la saisie, les pièces accessibles et les contrôles métier. Le produit ne demande pas de recommencer la fiche. Le mode manuel peut proposer un canevas habituel de passation, mais il doit distinguer ce canevas d’un résultat déjà produit. Un repli utile permet réellement de finir la tâche dans les droits courants.

Le choix entre assistance intégrée dans le produit et automatisation séparée dépend aussi de cette continuité. Lorsque l’équipe ne peut plus terminer sa tâche sans génération, le service a créé une dépendance forte. Le plan de reprise examine alors compétences, données disponibles et capacité des équipes à absorber les dossiers concernés.

Éviter la réactivation à l’insu de l’utilisateur

Une réponse reçue après le passage manuel ne rouvre pas le panneau comme si l’utilisateur avait changé d’avis. Le produit peut conserver une observation technique selon ses règles, mais une nouvelle proposition utilisable doit suivre une nouvelle demande ou un choix clair. Une notification insistante peut être aussi perturbatrice qu’un écrasement si elle détourne systématiquement l’attention du travail repris.

La supervision observe combien de parcours vont vers ce repli et ce qu’il advient de la tâche. Un taux élevé peut signaler budget trop court, sources lentes, mauvaise place de l’assistance ou préférence pour la saisie. Aucun de ces motifs ne se déduit du seul bouton. Il faut rapprocher événements et observations utilisateur avant de décider d’allonger le délai ou de supprimer le chemin manuel.

Annoncer les états sans détourner l’attention

Informer sans déplacer le focus à chaque transition

Le document W3C d’explication du critère 4.1.3 traite les messages de statut identifiables par les technologies d’assistance sans recevoir le focus. L’écran de recette emploie une région de statut pour attente et disponibilité. Ce balisage constitue une partie du dispositif, pas une certification de conformité ou la preuve que toutes les combinaisons de lecteur d’écran réagiront correctement.

L’essai vérifie que le champ garde le focus lorsqu’une proposition arrive après la saisie. Il ne teste pas un lecteur d’écran humain. Une recette d’accessibilité doit ensuite examiner annonces, ordre de tabulation, libellés, focus après activation et navigation du panneau. La présence de role="status" ne remplace ni ces observations ni un test de la tâche avec les personnes concernées.

Rendre les choix disponibles dans le bon espace

Sur mobile, Arrêter et Continuer sans IA doivent rester atteignables sans masquer le brouillon. La préparation ne force pas un défilement vers un panneau dès qu’un résultat arrive. Les messages distinguent délai prolongé, arrêt local et source modifiée avec des mots, pas uniquement une couleur. Le produit peut limiter les annonces successives afin que l’assistance ne parle pas continuellement pendant que l’utilisateur écrit.

Le comportement après un changement d’orientation, une mise en arrière-plan ou une restauration de session demande une recette propre. Les timers et états conservés par le navigateur ne garantissent pas une continuité correcte du parcours. Une restauration doit retrouver le dossier, le brouillon et l’état courant de demande sans rouvrir une insertion ancienne. Nos essais à deux largeurs ne couvrent pas ces cycles de vie.

Six parcours testés sur un écran synthétique

Observer champs, propositions et actions disponibles

Les six cas sont exécutés à 1920 et 390 pixels, soit douze parcours locaux. Les réponses sont écrites à la main et les événements explicitement injectés. Les assertions lisent le brouillon, le panneau, l’action d’insertion et, pour la saisie, le focus courant. Elles ne vérifient pas seulement le libellé du message, qui pourrait sembler correct alors que le contenu a déjà été perdu.

Mesurer ensuite les délais à la bonne frontière

La mesure de latence complète sépare lancement, acceptation, premier contenu, proposition utilisable et confirmation d’un effet éventuel. Un premier fragment rapide n’améliore pas nécessairement le temps jusqu’à une note correctement relue. Les données doivent permettre de relier un repli à sa préparation et à la tâche, sans journaliser par défaut tout le contenu des notes privées.

Les seuils de décision s’appuient sur la distribution observée et les conséquences du défaut. Dans cette recette, perdre une correction ou réactiver une demande arrêtée est éliminatoire, même si le délai moyen paraît bon. Un dépassement de budget qui conserve le travail et permet une passation manuelle n’a pas le même impact. Le dossier d’ouverture distingue ces incidents au lieu d’agréger tous les échecs dans un taux unique.

Erreurs fréquentes de reprise après une attente

Prendre la fin de génération pour une décision utilisateur

La première erreur consiste à copier la réponse dans le champ dès qu’elle arrive. Paradoxalement, une préparation plus lente augmente alors les chances d’écraser une correction utile. La seconde est de garder un seul indicateur Chargement pour plusieurs demandes : le premier retour peut fermer l’attente de la seconde et afficher un résultat qui n’est plus demandé. L’identité doit faire partie du contrat de réception.

Une troisième erreur est de réinitialiser les révisions lors d’un changement de fiche sans distinguer les sessions de parcours. Un ancien résultat peut sembler correspondre à une valeur réutilisée. Le produit examine aussi navigation, onglets et restauration avant de considérer un numéro local comme suffisant. La simulation réduite possède un seul écran et ne prétend pas résoudre toutes les identités d’un système distribué.

Cacher une incertitude derrière une reprise automatique

Un timeout peut inciter à relancer la même préparation sans montrer qu’une précédente est encore ouverte. Le retour ancien et le nouveau résultat concurrencent ensuite le panneau. Le produit choisit une politique explicite : retrait local de l’ancienne demande, réutilisation d’un résultat encore admissible ou nouvelle demande distincte. Aucune reprise ne doit effacer la saisie simplement pour retrouver un état facile à afficher.

Le dossier de lancement avec critères d’arrêt et repli conserve cette politique et les réserves connues. Un service qui échoue parfois lentement peut rester utilisable avec un repli testé ; un service rapide qui perd le travail humain ne satisfait pas la même exigence. Les décisions d’ouverture appartiennent aux responsables de tâche et d’exploitation, avec une trace des défauts jugés acceptables.

Plan d’action : valider le parcours avant son ouverture

Écrire les transitions depuis un dossier réel limité

Choisissez un écran et une préparation dont la portée est connue. Listez ce que l’utilisateur peut changer pendant l’attente, les révisions nécessaires et les effets ouverts après réception. Préparez les messages d’attente, les gestes d’arrêt et le retour au parcours classique. Le livrable initial est une séquence de travail vérifiable, pas une promesse d’accélération déduite d’une démonstration rapide.

1. Définir l’identité de préparation et les versions capturées.
2. Conserver un brouillon indépendant du résultat généré.
3. Fermer l’usage de tout retour devenu ancien ou arrêté.
4. Tester correction, nouvelle demande et changement de source pendant l’attente.
5. Vérifier ensuite repli, enregistrement et accessibilité sur le produit intégré.

Pour chaque transition, notez l’entrée, la décision, l’affichage et l’effet attendu. L’équipe produit définit le message d’attente et le geste d’insertion ; l’équipe application vérifie à quelle demande appartient le résultat et quel brouillon peut être sauvegardé ; l’exploitation fixe les délais et les signaux d’indisponibilité. Réception, insertion et sauvegarde demandent des contrôles distincts. Notre test d’insertion dans l’écran ne démontre pas encore que le serveur refusera une sauvegarde concurrente sur une version dépassée.

Passer de la simulation aux conditions d’usage

Le parcours du copilote avec correction et sources consultables fournit la continuité entre préparation et validation. Les preuves d’effet d’un outil connecté deviennent nécessaires dès qu’un geste dépasse le brouillon. Les essais locaux de F-16 ne doivent pas être réutilisés comme preuve d’un envoi ou d’une mutation distante.

La recette intégrée ajoute les vrais délais, interruptions, droits retirés, sources concurrentes et cycles de session. Les essais de compréhension observent si les personnes savent ce qui est arrêté, conservé et enregistré. Un tableau d’événements peut démontrer une transition correcte sans prouver que son message est compris. La validation finale associe ces deux observations au même parcours métier et à la version effectivement ouverte.

Conclusion : une réponse arrivée n’est pas une autorisation

Une préparation IA reste rattachée à sa demande, à ses sources et à l’état du travail humain. L’attente informe sans immobiliser la tâche. Arrêt et repli retirent l’usage local du retour ancien ; nouvelle demande et nouvelle révision imposent un rapprochement explicite. La proposition ne récupère aucun pouvoir par le simple fait d’être finalement disponible.

Les six parcours exécutés sur F-16 montrent conservation du brouillon, identité de réception, contrôle de révision et insertion locale au clic. Ils ne démontrent ni arrêt fournisseur, ni sauvegarde serveur, ni qualité du modèle, ni compréhension par les utilisateurs. Ces limites indiquent les essais d’intégration à compléter, au lieu de transformer une simulation réussie en garantie de produit.

Le développement d’une application métier avec assistance IA doit faire correspondre attente, messages et boutons aux effets réellement maîtrisés. Le service garde les corrections, rend le repli utilisable et expose l’état non enregistré tant qu’aucune preuve de sauvegarde n’existe.

Dawap accompagne l’intégration d’une IA sur mesure dans votre écran de rédaction en partant de ces gestes : lancer une préparation, poursuivre la saisie, annuler, puis recevoir une réponse tardive. Avec l’équipe qui utilise l’application, nous vérifions ce qui reste visible et ce qui peut encore être inséré. La recette côté serveur complète ensuite les essais de l’écran pour empêcher qu’une sauvegarde écrase le travail effectué pendant l’attente.