Le technicien commence une note de passation dans la fiche d’intervention. Il demande une synthèse IA, corrige sa saisie pendant l’attente, puis voit la réponse remplacer son travail. Un bouton « Valider » apparaît sans préciser si la note sera enregistrée ou transmise. Le problème du copilote est devenu un problème de produit : l’utilisateur ne comprend plus ce qui vient des sources, ce qu’il a modifié et quelle action sera réellement effectuée.
La méthode sépare suggestion, brouillon de l’utilisateur et effet enregistré. L’écran conserve le contexte de la demande, présente les faits vérifiables et décrit chaque geste. Une proposition peut être utile tout en étant périmée, partielle ou impossible à insérer sans conflit. Le contrôle se voit dans les états et les actions disponibles, au-delà d’une formule « vous gardez la main ».
Nous prenons une fiche d’intervention fictive sur l’équipement P-14. Le copilote prépare une note de passation, sans modifier le statut de l’équipement ni envoyer de message. Le parcours annoté et les cas de recette constituent une proposition de conception ; aucun test utilisateur, appel de modèle ou résultat client n’est revendiqué. Ils rendent vérifiables sources, correction, enregistrement et annulation.
Une IA sur mesure utile dans les opérations doit respecter ce que le technicien fait déjà dans sa fiche. Le développement d’une fonctionnalité IA dans une application métier définit donc les gestes avant le panneau de conversation : demander une note, examiner sa source, insérer un passage et enregistrer. Le parcours ci-dessous précise lequel de ces gestes peut encore être annulé et comment préserver une saisie concurrente.
Pour qui concevoir une assistance dans un écran existant
Décrire un effort précis dans le parcours
Le sujet concerne responsables produit, designers, développeurs et équipes métier qui ajoutent une assistance à un back-office, un portail ou un outil interne. La première question décrit le geste coûteux : relire un historique, rapprocher des faits ou préparer une note. Un panneau de conversation générique ne dit pas quand l’aide devient pertinente ni comment son résultat rejoint le travail existant.
Dans notre cas, le technicien veut préparer une passation après lecture de l’intervention et de l’historique accessible. Il possède déjà un champ de note et un enregistrement classique. L’assistance doit réduire l’effort de rédaction sans bloquer ce parcours. Le produit reste utilisable lorsque le copilote ne peut pas produire de suggestion.
Borner ce que la suggestion peut changer
La mission propose une formulation de faits connus. Elle ne confirme pas une réparation, ne clôture pas une intervention et ne décide pas que l’équipement peut reprendre son service. Ces opérations possèdent des règles et validations propres. Un utilisateur qui insère une synthèse dans sa note n’a pas nécessairement demandé l’une de ces actions.
Les recommandations de Microsoft Research sur l’interaction humain-IA mettent notamment l’accent sur des capacités compréhensibles, une correction accessible et la possibilité d’écarter une assistance. Ces principes orientent la conception ; ils ne prouvent pas que notre parcours fictif est utilisable sans essais auprès de ses utilisateurs.
Montrer le dossier et les sources réellement utilisés
Identifier la demande sans exposer les paramètres techniques
L’écran indique que la note est préparée pour l’intervention I-42 de l’équipement P-14. La proposition G-1 utilise la fiche enregistrée en version 7 et un historique H-4. Ces références appartiennent à notre exemple. L’utilisateur n’a pas besoin d’un identifiant de déploiement ou du prompt complet pour comprendre cette portée ; il doit savoir quel dossier a été lu.
Les sources réellement consultées sont distinguées des sources prévues. Si une pièce manque ou n’est pas accessible, le produit ne laisse pas croire que la synthèse couvre tout l’historique. Le service renvoie une couverture explicite avec la proposition. L’interface conserve cette information jusqu’au moment où l’utilisateur choisit d’utiliser la suggestion.
Décider comment les saisies non enregistrées participent
Le brouillon local L-3 peut contenir une observation qui n’existe pas dans la fiche enregistrée. Le produit choisit explicitement si elle entre dans la demande. Si elle est utilisée, elle apparaît comme saisie de l’utilisateur, distincte d’un fait déjà enregistré. Si elle ne l’est pas, la portée visible prévient que la proposition ne tient pas compte des modifications en cours.
Cette décision doit précéder l’appel au modèle. Ajouter les nouvelles saisies après réception ne rend pas rétroactivement la proposition à jour. Quand le dossier ou le brouillon change, le produit peut signaler la différence et demander une nouvelle préparation. La règle évite qu’une réponse calculée sur un ancien contexte remplace silencieusement un travail récent.
Parcours annoté : de la suggestion au brouillon enregistré
Présenter la proposition avant tout remplacement
Exemple concret : la fiche I-42 indique qu’un contrôle reste à terminer. La proposition doit conserver cette réserve dans la note. Une phrase annonçant « contrôle terminé » serait refusée, même si sa rédaction semble plus fluide. Le technicien peut consulter le passage source, corriger la formulation et choisir quelles phrases ajouter au brouillon.
| Étape visible | Information présentée | Geste proposé | Effet exact |
|---|---|---|---|
| 1. Préparer | Intervention I-42 ; fiche v7 ; historique H-4 | Préparer une note de passation | Créer une demande de suggestion |
| 2. Vérifier | Proposition séparée ; contrôle restant à terminer ; source associée | Consulter la source ou écarter la proposition | Aucune modification du brouillon |
| 3. Corriger | Différences avec le brouillon L-3 ; réserve conservée | Insérer la sélection dans mon brouillon | Modifier le brouillon local |
| 4. Relire | Note finale, modifications humaines et statut non enregistré | Enregistrer la note | Demander une sauvegarde contrôlée |
| 5. Confirmer | Note enregistrée avec sa référence ; intervention non clôturée | Continuer la fiche | Aucun envoi ou changement de statut implicite |
La séparation des étapes ne signifie pas cinq fenêtres ou confirmations systématiques. Une seule fiche peut montrer suggestion, sources et brouillon. Ce qui compte est la distinction perceptible des effets. La validation locale ne doit pas prendre l’apparence d’une sauvegarde distante, et la sauvegarde d’une note ne doit pas prendre l’apparence d’une clôture métier.
Nommer les états au niveau de la tâche
Les libellés décrivent ce que l’utilisateur peut attendre : préparation en cours, proposition à relire, contexte modifié, brouillon non enregistré, sauvegarde confirmée ou résultat de sauvegarde à vérifier. Le statut du fournisseur n’est pas un statut métier. Une réponse reçue par le navigateur ne prouve pas que la note existe dans la fiche enregistrée.
Le contrat d’entrée conserve dossier, portée et version du brouillon utilisée. Sa sortie contient proposition, références de sources, couverture et motif de refus éventuel. Le produit possède la responsabilité des états visibles et de leur journalisation. Le repli conserve la saisie classique, avec une indication claire de ce qui n’a pas été préparé ou enregistré.
Dans un produit partagé entre clients, cette portée doit aussi suivre cache, file et consommation. Le contrôle d’isolation d’un copilote SaaS multi-tenant éprouve des identifiants identiques, des droits retirés et des travaux repris dans le mauvais contexte. La frontière de l’écran conserve ainsi sa signification jusqu’aux objets dérivés et à la préparation différée.
- Proposition G-1 : conserve la référence I-42 v7 et les sources effectivement utilisées.
- Brouillon L-3 : conserve les modifications de l’utilisateur, y compris celles produites pendant la préparation.
- Note enregistrée : possède une référence confirmée par le serveur et un historique distinct de la proposition.
Rendre les faits vérifiables sans surcharger l’écran
Relier une affirmation au passage qui la soutient
Un lien « sources » contenant une liste de documents ne suffit pas à contrôler une phrase précise. L’affirmation « contrôle restant à terminer » doit conduire au passage utile de l’intervention, avec son contexte. La référence indique la version consultée. Si l’interface ouvre la version actuelle, elle signale qu’elle peut différer de celle utilisée pour la proposition.
Une source accessible et correctement citée peut néanmoins être interprétée de travers. L’utilisateur doit pouvoir constater la négation, la réserve ou l’exception sans parcourir des dizaines de pages. Le produit met en évidence le passage pertinent tout en permettant de lire autour. Il ne réduit pas la preuve à un badge vert qui affirme une exactitude non démontrée.
Rendre l’incertitude actionnable
Le produit distingue un fait issu d’une source, une reformulation proposée et une information manquante. « Historique incomplet : vérifier la dernière intervention » décrit une action possible. Un score de confiance non calibré ne dit pas si la source manque, si elle est ancienne ou si le modèle a rapproché deux équipements différents.
Le contrôle d’accès s’applique aussi à l’ouverture du passage source. Une référence affichée ne donne pas un droit supplémentaire. Si l’accès a été retiré, le produit suit sa politique de révocation et suspend l’usage concerné ; il ne conserve pas un extrait révélateur derrière un lien refusé. Cette situation doit être testée dans le parcours complet, y compris les copies et états déjà chargés.
Corriger et régénérer sans perdre la saisie humaine
Préserver la contribution de l’utilisateur
Le brouillon humain reste modifiable pendant la préparation lorsque le parcours le permet. La proposition apparaît dans un espace séparé et n’écrase pas cette saisie à l’arrivée. L’insertion peut porter sur une sélection et montrer ce qui sera ajouté ou remplacé. Les corrections déjà effectuées par l’utilisateur ne doivent pas être confondues avec un nouveau contenu généré.
Cas concret : le technicien ajoute « attente de pièce confirmée » après le lancement. La proposition G-1 ne connaît pas cette observation. Si elle remplace toute la note, cette information disparaît. La règle d’insertion doit alors conserver la saisie ou demander un choix sur la différence ; elle ne doit pas traiter la fin de génération comme une autorisation de remplacement.
Donner un sens distinct à correction et régénération
Corriger une phrase modifie la note de l’utilisateur. Demander une nouvelle proposition crée une autre sortie du modèle. Le produit ne régénère pas automatiquement après chaque correction si cette opération remplace le travail ou change la portée. Il décrit ce qui sera pris en compte dans la nouvelle demande et permet de comparer les propositions utiles.
Une correction opérationnelle n’est pas automatiquement un signal d’entraînement. Le chapitre Feedback + Control du People + AI Guidebook distingue les usages du feedback et recommande d’expliquer leurs effets. Pour notre conception, sauvegarde de note et retour d’évaluation restent des gestes séparés ; aucun réentraînement immédiat n’est promis après une modification.
La qualification des corrections utilisateur d’un copilote approfondit ce second usage. Type, proposition, révision, source et portée accompagnent le retour avant une revue explicite. Dix parcours synthétiques vérifient répétition, conflit et retrait de qualification ; une préférence de style ou une exception locale ne devient pas une réponse factuelle commune. Le travail enregistré et la référence d’évaluation conservent ainsi des décisions distinctes.
Faire correspondre le bouton à son effet métier
Rendre le verbe et la portée lisibles
« Insérer dans mon brouillon » annonce un changement local. « Enregistrer la note » annonce une persistance. « Transmettre la passation » annoncerait un autre effet, absent de notre mission. Le libellé « Valider » devient ambigu s’il recouvre ces trois gestes. Le produit doit choisir une formulation en fonction de l’effet réel et de l’état courant.
La confirmation supplémentaire dépend de la conséquence du geste, pas de la présence d’IA. Une opération réversible dans un brouillon ne demande pas nécessairement un dialogue. Un effet externe ou difficile à annuler peut demander une revue plus explicite. La règle produit doit être cohérente avec le parcours classique, afin que l’assistance ne crée pas une convention contradictoire.
Réexaminer le contexte à la frontière d’enregistrement
Si la fiche est passée de la version 7 à la version 8, l’écran indique le changement avant d’utiliser une proposition qui dépend de la version précédente. Un contrôle serveur de version empêche la sauvegarde silencieuse sur un état concurrent. Un bouton désactivé uniquement dans le navigateur ne suffit pas à imposer cette règle.
Le risque est de croire qu’un clic de l’utilisateur rend tout le contexte valide. Son accord porte sur ce qui était présenté. Une modification de source ou de droits peut nécessiter une nouvelle vérification. Le produit montre le conflit et conserve le brouillon, puis propose rapprochement ou nouvelle préparation ; il ne transforme pas ce conflit en succès pour simplifier l’expérience.
Distinguer arrêt, abandon et retour sur une modification
Décrire ce que l’arrêt garantit réellement
Arrêter la préparation peut empêcher l’utilisation d’une réponse tardive sans garantir que le calcul fournisseur a été annulé. Le produit affiche la portée qu’il sait tenir. L’utilisateur peut continuer son brouillon ; une réponse arrivée après l’arrêt ne doit pas réapparaître comme nouvelle proposition active ni modifier la saisie.
Abandonner une suggestion ferme cette proposition sans effacer le brouillon humain. Quitter la fiche peut poser une autre question si des modifications locales ne sont pas enregistrées. Les alertes portent sur ce travail réel. Multiplier des confirmations identiques pour l’IA et le brouillon peut rendre le parcours moins compréhensible qu’une distinction claire de ce qui sera perdu.
Séparer retour local et correction d’un effet enregistré
Annuler une insertion peut restaurer l’état local précédent tant que le produit conserve les changements nécessaires. Après enregistrement, le retour peut être une nouvelle modification de note avec historique. Une note déjà transmise ne serait pas retirée de tous ses destinataires par un simple bouton Annuler. Le vocabulaire et la possibilité d’action suivent l’effet effectivement réalisé.
Si la sauvegarde a perdu sa réponse, son résultat est à vérifier. Le produit retrouve l’intention d’enregistrement et la note éventuelle avant de proposer une reprise. Une répétition aveugle peut créer un doublon. L’interface peut garder le brouillon et informer sans prétendre savoir que l’opération a échoué ou qu’une annulation a supprimé un effet distant.
Garder un parcours utilisable au clavier et sur mobile
Préserver l’attention et la position de saisie
La fin d’une génération ne déplace pas automatiquement le curseur dans la proposition et ne fait pas défiler la fiche loin du champ actif. Le produit annonce sa disponibilité sans interrompre le travail. Le parcours permet de demander l’aide, consulter les sources, corriger, insérer et enregistrer au clavier dans un ordre compréhensible.
Les états ne sont pas exprimés uniquement par une couleur. Les messages de statut et erreurs sont accessibles aux technologies d’assistance, sans annonces continues à chaque fragment de génération. Une erreur nomme ce qui manque et la prochaine action possible. Une animation de chargement ne remplace pas cette information et ne doit pas rendre la saisie inutilisable.
Adapter l’espace sans cacher la distinction des effets
Sur mobile, le panneau de suggestion peut devenir une section ou une vue dédiée. Le retour à la fiche conserve le brouillon et son emplacement utile. Sources, insertion et statut non enregistré restent visibles au moment du choix. Une barre de boutons qui masque la fin de la proposition peut faire accepter une note que l’utilisateur n’a pas pu relire entièrement.
Le budget de latence dépend du geste et des conditions d’usage. La supervision sépare attente de préparation, disponibilité de proposition et confirmation de sauvegarde. Un plafond serveur et un repli permettent de revenir à la rédaction classique ; l’écran ne prolonge pas indéfiniment une opération parce que le fournisseur reste en attente. Les détails de traitement asynchrone demandent ensuite une conception dédiée.
Le parcours d’attente et d’annulation d’un copilote IA approfondit cette période. Six situations synthétiques vérifient arrêt local, réponse tardive, nouvelle demande et révisions, avec conservation du brouillon. Une fin de préparation ne remplace jamais l’accord d’insertion et ne prouve aucun arrêt du calcul distant.
Matrice de recette : huit situations visibles dans l’écran
Observer les gestes et les effets ensemble
La recette utilise un service simulé pilotable et un jeu de dossiers synthétiques. Elle vérifie affichage, droits, saisie et résultat enregistré, au-delà d’une capture du panneau. Les situations ci-dessous sont des essais proposés, non exécutés sur un logiciel client. La décision d’ouverture doit aussi s’appuyer sur des essais de compréhension avec les utilisateurs concernés.
| Situation | Comportement attendu | Effet à vérifier | Décision si défaut |
|---|---|---|---|
| Suggestion correcte sur I-42 v7 | Proposition séparée, source accessible | Aucune modification sans insertion | Bloquer l’ouverture si écrasement |
| Brouillon corrigé pendant l’attente | Différence signalée ou insertion sans perte | Correction humaine conservée | Revoir la règle de remplacement |
| Source I-42 devenue v8 | Proposition marquée à réexaminer | Pas de sauvegarde silencieuse sur ancien contexte | Suspendre le parcours concerné |
| Source retirée des droits | Accès et usage conformes à la révocation | Pas de divulgation par l’extrait | Fermer la capacité et corriger |
| Préparation arrêtée puis réponse tardive | Réponse sans insertion ni réactivation automatique | Brouillon inchangé | Corriger la corrélation de demande |
| Insertion puis annulation locale | Retour annoncé et compréhensible | État local restauré selon le contrat | Limiter le geste si retour absent |
| Sauvegarde avec réponse perdue | Résultat à vérifier, brouillon conservé | Rapprochement avant répétition | Fermer la reprise aveugle |
| Parcours mobile et clavier | Sources et actions accessibles, focus conservé | Tâche terminable sans geste bloquant | Corriger avant exposition |
Fixer des seuils qui portent sur le risque visible
Un défaut qui efface la saisie humaine ou révèle une source interdite doit fermer le parcours concerné. Une formulation moins pratique peut relever d’une amélioration suivie si elle laisse la tâche compréhensible et les effets maîtrisés. Le seuil ne se réduit pas à un taux moyen de satisfaction : les erreurs de frontière restent examinées séparément.
Le bilan conserve tâches abandonnées, corrections, demandes de clarification et temps de vérification. Le nombre d’insertions ne prouve pas que les notes ont été utiles ou fidèles. Une acceptation fréquente peut aussi signifier que les utilisateurs n’ont pas compris qu’ils devaient relire. Les observations de compréhension doivent pouvoir changer les libellés et le périmètre ouvert.
Erreurs fréquentes des interfaces de copilotes IA
Faire du panneau une boîte noire persuasive
Une proposition formulée avec assurance, un bouton Valider et une liste de sources globale peuvent donner une apparence de contrôle sans permettre la vérification. Une animation ou un label « intelligent » n’explique pas la portée. Le produit doit montrer les réserves qui changent le geste, même lorsque la synthèse semble plus courte sans elles.
Un contrôle humain nominal ne suffit pas si l’utilisateur ne peut ni voir les différences ni corriger sans tout recommencer. Les sources doivent être utiles au moment de la décision. Un système qui exige de quitter la fiche, perdre le brouillon et retrouver manuellement l’intervention impose un coût de vérification que le taux d’acceptation ne révèle pas.
Masquer les états difficiles pour fluidifier le parcours
Les erreurs typiques sont l’insertion automatique, la régénération qui écrase une correction, le succès annoncé avant confirmation et l’annulation ambiguë après effet distant. Le changement de dossier mérite aussi une protection : la réponse de I-42 ne doit pas apparaître dans la nouvelle fiche ouverte comme si elle la concernait.
Autre défaut : transformer toute indisponibilité en phrase générique produite localement. L’utilisateur ne sait plus si elle s’appuie sur ses sources. Un repli doit être nommé et adapté à la mission. Il peut conserver la saisie classique ou proposer un modèle de note vide, sans le présenter comme synthèse de l’intervention.
Plan d’action : définir le parcours puis vérifier ses effets
Écrire le contrat visible avant le premier prototype
Choisissez un écran, une tâche et une population. Décrivez le travail sans IA, les sources autorisées et l’effet attendu. Écrivez les libellés des gestes avant d’implémenter : préparer, consulter, insérer, corriger, enregistrer, arrêter et revenir. Pour chacun, indiquez ce qui change dans la proposition, le brouillon et le dossier enregistré.
Le contrat précise entrée, sortie, versions et responsabilité des états. Le produit possède les actions et leur journalisation ; le service IA possède les références de contexte et les motifs d’abstention. Le repli conserve le chemin manuel. Si une action ne peut pas être décrite sans ambiguïté, réduisez la mission avant d’améliorer la rédaction de la suggestion.
Vérifier les situations où l’utilisateur doit reprendre
Prototypez ensuite la proposition séparée, l’ouverture des sources et la correction. Faites jouer les cas de changement de dossier, source périmée, saisie concurrente et réponse tardive avec un service simulé. Vérifiez le résultat enregistré et les refus serveur. Des essais avec le fournisseur réel évaluent ensuite la fidélité des suggestions ; ils ne remplacent pas les tests des gestes produit.
Faites réaliser la tâche par les utilisateurs sans expliquer les boutons à leur place. Demandez-leur ce qui sera enregistré et ce qui peut encore être annulé. Observez erreurs de compréhension et effort de vérification. Ouvrez un périmètre limité lorsque ces résultats permettent une décision ; conservez les cas et versions pour vérifier les évolutions futures du modèle et de l’interface.
Guides complémentaires pour l’architecture et la mission
Choisir la frontière technique sans la faire porter à l’utilisateur
La réflexion sur le placement d’une automatisation IA dans le produit ou dans un service traite le choix d’architecture, les droits et la responsabilité de chaque frontière. L’écran doit rester compréhensible même si l’inférence est exécutée par un service séparé.
Cette décision d’architecture ne décide pas automatiquement du sens des boutons. Le produit reste responsable de présenter la proposition et d’annoncer les effets. Une intégration technique correcte peut encore donner un parcours qui efface la saisie ou fait croire à une sauvegarde. Les deux preuves doivent donc être réunies avant l’ouverture.
Les états et exceptions d’un dossier métier avec IA précisent la persistance et le résultat inconnu derrière ces gestes. Ils complètent la conception de l’écran lorsque le brouillon rejoint un dossier durable, avec des responsabilités distinctes pour la proposition et l’effet enregistré.
Conserver une mission précise derrière l’assistance
Le contrat de mission d’un agent support avec outils et conditions d’arrêt montre comment borner rôle, contexte et actions. Le cas support est distinct de notre passation, mais cette précision de mission aide à empêcher un copilote rédactionnel d’acquérir silencieusement une capacité de clôture ou d’envoi.
L’interface traduit ces limites en actions accessibles et en raisons compréhensibles de refus. Elle ne doit pas annoncer une capacité qui reste interdite côté serveur ni cacher une action ouverte derrière un libellé de simple rédaction. Mission, outils et expérience produit doivent décrire la même portée.
Conclusion : rendre le contrôle observable dans le produit
Un copilote dans un écran métier doit préserver le travail humain et rendre ses effets lisibles. La suggestion reste distincte du brouillon ; le brouillon reste distinct de l’enregistrement. Les sources et versions permettent de réexaminer une proposition lorsque le dossier évolue.
Correction, arrêt et annulation ont des portées différentes. Les gestes suivent les effets réellement réalisables, avec des états explicites pour les conflits et résultats inconnus. Le parcours annoté et la matrice servent à préparer une recette ; leur valeur doit être confirmée par des essais du produit et de compréhension.
Le développement d’applications augmentées par l’IA associe ces interactions aux droits, aux sources et au fonctionnement classique. Une nouvelle capacité conserve les exigences de vérification du premier parcours.
Pour intégrer cette IA sur mesure dans les outils de vos équipes, Dawap vous accompagne depuis un écran utilisé, avec observation de la rédaction, de la vérification et de la sauvegarde actuelles. Un prototype doit ensuite faire jouer la réponse tardive, le changement de fiche et la correction pendant l’attente. Les essais avec vos utilisateurs vérifient qu’ils savent ce qui sera enregistré et comment reprendre leur note ; ils peuvent conduire à modifier les libellés ou à réduire l’assistance avant son ouverture.
