Donner un état de preuve et un responsable à chaque feedback IA
Le feedback IA doit éviter la certitude excessive, car une phrase fluide peut confondre information soutenue par l’entrée actuelle, inférence valable sous condition et inconnu non résolu. «Je vais m’en charger» n’est pas non plus une promesse tenable sans responsable, dépendance extérieure, échéance, expiration et état d’échec. Il s’agit de rédaction produit et d’interaction, pas d’une nouvelle méthode permettant à l’utilisateur de vérifier une réponse particulière. Le contrat comporte sept champs: état de preuve, condition, inconnu, action contrôlable, dépendance externe, responsable avec temps et échec, puis expiration. Le ton certain doit suivre un état observable et ne jamais le fabriquer.
Séparer quatre états avant de rédiger
«Soutenu maintenant» renvoie à une entrée, un enregistrement ou un événement terminé et nommé. «Inférence conditionnelle» énonce la prémisse qui doit rester vraie. «Inconnu» laisse visible une donnée absente, une source indisponible ou un conflit. Un statut d’action — demandé, en attente, envoyé, accusé, terminé ou échoué — n’est utilisé que si le produit observe la transition. Le NIST montre qu’un contenu faux peut sembler assuré; le ton ne constitue donc pas une preuve. Séparez aussi les affirmations atomiques: créer un événement n’équivaut pas à recevoir l’accord externe. Chaque carte montre catégorie de soutien et heure du dernier contrôle.
Décomposer la promesse en propriétaire et états terminaux
Le propriétaire doit pouvoir agir et observer la fin: produit, utilisateur, service nommé ou personne extérieure. Ajoutez prérequis, délai réel ou estimation, point de contrôle et fins possibles: terminé, refusé, expiré, échoué, toujours en attente. «Je garantirai sa réponse demain» n’a aucun propriétaire contrôlable. «Invitation envoyée par l’application; réponse détenue par le destinataire; nouvelle vérification mardi» sépare contrôle et dépendance. HAX recommande des frontières claires de capacité et de performance. La première personne de l’assistant ne doit pas absorber l’obligation d’un tiers. Sans propriétaire possible, formulez une option et non un engagement.
Placer condition et expiration auprès du message
Un avertissement général ne répare pas un badge «terminé» inconditionnel. Ajoutez «selon le calendrier connecté», «si les horaires restent identiques» ou «accusé externe non reçu». L’heure de preuve, le prochain contrôle et l’expiration ont des rôles différents. Données externes, permissions, version et modification peuvent changer séparément. Quand une dépendance disparaît, dégradez le statut au lieu de conserver la certitude d’hier. L’OCDE soutient une information contextuelle sur entrées et limites. Le texte ancien peut rester dans un historique daté, jamais comme état courant.
Proposer une action, pas son résultat
PAIR recommande d’expliquer ce qui manque et d’offrir réessai au point de contrôle, reconnexion, modification, voie manuelle, annulation ou maintien de l’inconnu. Le bouton nomme l’action: «Envoyer la demande», pas «Obtenir l’accord»; «Vérifier la disponibilité», pas «Réserver avec succès». Décrivez aussi l’effet réel du feedback. Une correction qui ne change que l’écran n’a pas «réentraîné» le modèle. Si elle rejoint une revue ultérieure, donnez périmètre et délai. Un remerciement ne doit pas suggérer une mise à jour immédiate. L’étape reste utile sans promettre la décision d’un tiers.
Tester cinq ruptures de dépendance
Après un résultat positif, déconnectez une source, retirez une permission, retardez l’accusé au-delà du contrôle, ajoutez une entrée contradictoire et rouvrez un résultat expiré. Titre, badge, notification, résumé et texte suivant doivent se dégrader ensemble. «Terminé», «garanti», «toujours» ou un futur que le produit ne possède plus doivent disparaître. Vérifiez que reconnecter, modifier, réessayer, annuler, passer en manuel ou rester inconnu correspond au nouvel état. Utilisez des données anodines sans sonder de protections cachées. Consignez entrée, dépendance, heure, fin attendue, texte observé et version.
Faire des sept champs une porte de sortie
La version passe si chaque phrase correspond à un état, chaque promesse à un propriétaire capable, chaque dépendance est visible, l’expiration dégrade le statut et les cinq tests finissent honnêtement. Elle échoue si l’assurance visuelle dépasse la preuve, l’envoi devient achèvement, l’estimation devient échéance, un feedback devient apprentissage instantané ou une sortie ancienne reste active. Examinez texte et modèle d’événements ensemble: un backend limité à succès ne peut produire attente, échec et expiration par adjectifs. Cette porte évalue le feedback produit; la vérification externe d’une réponse reste le parcours séparé de l’article 170.
Questions fréquentes
Tout langage certain est-il mauvais?
Non. Un achèvement observable dont périmètre, source et heure sont clairs peut être formulé avec certitude.
Peut-on afficher une estimation?
Oui, comme estimation, avec sa base, un contrôle et l’état affiché sans réponse.
Tout inconnu est-il une erreur?
Non. Certains points restent légitimement ouverts et ne reçoivent que des actions capables de réduire l’écart.