Sur cette page
Un système de support recommande de rembourser une commande. L’écran affiche « forte confiance », mais la personne qui traite le dossier ne voit ni quelle commande, ni la version des règles, ni si un envoi de remplacement a déjà eu lieu. La recommandation peut être juste. Impossible de le savoir. Ce scénario de support est illustratif, pas un incident rapporté.
Une démonstration d’aide à la décision présente une méthode plus vérifiable : la personne chargée de la revue peut voir les mesures de chaque composante et ouvrir l’examen d’origine au lieu de recevoir seulement une suggestion finale. La démonstration se déroule dans un contexte médical, où une validation indépendante compte particulièrement. Elle ne démontre pas une précision clinique. La leçon de conception peut être appliquée à un travail moins sensible sans reprendre les promesses de résultat du fournisseur.
Une recommandation comprime les preuves
La compression sert à quelque chose. La personne qui décide d’un remboursement ne veut pas lire tous les événements d’un registre. Une recommandation peut transformer un long historique en prochaine action. Mais elle écarte des détails, y compris ceux qui pourraient renverser la conclusion.
Imaginez un historique de commande illustratif. Un client signale un colis manquant. Le modèle lit « non livré » dans les données du transporteur et propose un remboursement. Un autre dossier indique qu’un remplacement a été expédié ce matin. Si la recommandation cache ce dossier, la personne peut accorder deux remèdes pour un seul problème. Si les deux faits et leurs horaires apparaissent, elle peut décider en connaissance de cause.
L’interface devrait répondre à quatre questions avant d’inviter à agir : qu’a-t-on observé ? D’où cela vient-il ? Quelle est l’ancienneté de l’information ? Qu’est-ce qui pourrait rendre la recommandation erronée ? Une justification en prose n’est qu’une partie de la réponse.
Les observations source et la personne chargée de la revue sont reliées par une recommandation qui inclut provenance et incertitude, avec accès au dossier original.
« Rembourser parce que la livraison a échoué » peut sembler convaincant même si le statut du transporteur est périmé.
| Élément visible | Ce qu’il permet de vérifier |
|---|---|
| Recommandation et action proposée | Si l’action correspond à la tâche |
| Observations source datées | Si les faits sont récents et complets |
| Preuves manquantes ou contradictoires | S’il faut suspendre ou enquêter |
| Lien vers le dossier original | Si le résumé a omis un détail décisif |
| Historique des résultats et corrections | Si des suggestions semblables échouent souvent |
Il s’agit d’une liste conceptuelle pour l’interface, pas d’une affirmation qu’un tableau de bord particulier améliore les décisions.
Mettez l’incertitude au cœur du travail
Un système peut hésiter pour plusieurs raisons. Une source n’a pas répondu. Deux identifiants peuvent désigner la même commande. Une politique a changé depuis la dernière indexation. Le modèle peut être incertain du sens d’une plainte rédigée librement. Ce sont des modes d’échec différents qui méritent des présentations différentes.
« Faible confiance » ne suffit pas quand la personne peut trouver un fait manquant. Affichez « dernière mise à jour du transporteur hier » ou « impossible de consulter le dossier de remplacement ». Si la note n’a pas de base, n’affichez pas un pourcentage faussement précis. Le but est d’aider la personne à choisir la prochaine vérification.
La même structure importe dans une synchronisation. Si une destination reçoit un nouveau statut de client, gardez l’identifiant et la date de l’événement source ainsi que la règle qui a produit le changement. Quand quelqu’un demande pourquoi une campagne a inclus ce client, l’équipe peut remonter le fil de la décision. Une valeur copiée sans explication est une conclusion sans preuve.
Cette vue Tajo proposée distingue ce que signale le journal d’activité de ce qui reste à prouver. L’écriture apparaît comme appliquée, tandis que la vérification de la cible est en attente. Le journal actuel de Tajo expose les résultats et les événements bruts. Le panneau ajouté illustre une façon de rendre cette limite plus visible.
Une écriture terminée demande encore des preuves
La synchronisation du client est-elle terminée ?
Écriture appliquée. Vérification en attente.
L'état de la cible n'a pas encore été vérifié.
Activité de synchronisation
- Demande acceptée
- Mise à jour appliquée
- Vérification de la cible en attente
Exécution d'exemple · 14:32 UTC
Ce que nous savons
- Réponse du fournisseur
- Acceptée
- Résultat de l'écriture
- Appliquée
- Relecture de la cible
- En attente
Un appel réussi ne prouve pas l'état final.
Présentation proposée d'après le journal d'activité de Tajo. Cette illustration ajoute un état de vérification sans prétendre que la relecture de la cible est déjà disponible.
Facilitez la revue sans tout exposer
La plupart des actions ordinaires ne devraient pas imposer l’ouverture d’un dossier complet. Une bonne interface peut rester concise tout en plaçant les preuves à un clic. Elle peut aussi mettre en avant les seules contradictions susceptibles de changer la décision. C’est différent de masquer entièrement son fondement.
Afficher davantage de données a un coût réel pour la vie privée. La personne qui révise ne doit voir que les champs nécessaires, sous les mêmes règles d’accès que le dossier sous-jacent. La visibilité des preuves n’autorise pas à exposer tout l’historique client. Conservation et journaux d’audit doivent aussi avoir un responsable.
Autre souci : le biais d’automatisation. Une recommandation visible peut encore orienter la personne chargée de la revue. Testez si elle détecte des contradictions insérées dans les cas et peut choisir « preuves insuffisantes » sans lutter contre l’interface. Après déploiement, mesurez les corrections et retours en arrière. Une explication plaisante n’est pas le résultat à mesurer.
Il faut aussi enregistrer les désaccords. Si la personne refuse le remboursement proposé, demandez un motif assez précis pour améliorer le système : mauvaise correspondance de commande, statut périmé du transporteur, dossier de remplacement absent ou exception à la politique. N’exigez pas une longue justification à chaque fois. Regroupez les motifs et cherchez les sources de problèmes récurrents. La revue individuelle peut ainsi conduire à une réparation du système. Le guide de découverte du processus aide à trouver les exceptions avant de construire une suggestion. Les preuves à côté de la recommandation aident aujourd’hui ; les données de correction peuvent améliorer demain.
Pour les actions importantes, le chemin de revue fait partie du contrat du produit. Le système propose, cite ses sources, dit ce qu’il n’a pas pu vérifier et enregistre le résultat. Quand les preuves ne soutiennent pas un choix, la recommandation la plus utile peut être « attendre ».
Questions fréquemment posées
Une explication rend-elle une recommandation fiable ?
Non. Une explication plausible peut accompagner un résultat faux. Les personnes qui révisent doivent accéder aux observations originales, à leur provenance, aux incertitudes et aux résultats, pas seulement à une phrase assurée.
Quelles preuves faut-il afficher près d’une suggestion automatique ?
Montrez les observations utilisées, leur source et leur date, les données manquantes, la version de la règle ou du modèle si elle compte, ainsi qu’un accès au dossier original.
Quand une personne doit-elle réviser le résultat ?
Quand les conséquences dépassent le périmètre autorisé du système ou que les preuves sont incomplètes, anciennes ou contestées. La personne doit pouvoir réellement contredire la suggestion et arrêter l’action.