Confier une tâche précise. Vérifier son résultat.

Indiquez le responsable, l’organisation, la fiche visée et le résultat attendu. « Aide-moi avec l’inventaire » laisse plusieurs décisions ouvertes. « Relis la fiche choisie et signale les faits qui manquent pour préparer une réponse » permet de comparer le résultat à une source identifiable.

La supervision dépend de l’effet : une réponse dans le chat, une écriture CRM et un clic externe n’ont pas le même point de contrôle. Les permissions de connexion, les droits actuels du compte et les autorisations Newton se complètent. Une consigne « ne modifie rien » ne retire pas un droit technique déjà accordé.

Les noms techniques et les effets précis sont décrits au catalogue MCP. Cette matrice aide à décider ; elle ne constitue pas une qualification de bout en bout de Facebook ou Messenger.

Scénario pédagogique entièrement fictif, sans client réel : une personne demande si le véhicule SIM-102 est disponible et quel est son prix. La fixture partagée indique un prix enregistré de 0 $, un kilométrage absent, le statut en attente et 0 lien photo.

1. Lecture : retrouver la bonne fiche et conserver ces valeurs. Le test MCP de la fixture vérifie leur restitution ; il ne valide pas une conversation Muse.
2. Comparaison : le statut en attente ne permet pas d’annoncer une disponibilité ; zéro ne signifie pas gratuit. Le responsable doit confirmer ces deux faits.
3. Brouillon : proposer « Le prix et la disponibilité restent à confirmer auprès de l’équipe. Le kilométrage n’est pas renseigné. » Ce texte est une proposition pédagogique, pas une réponse observée d’un assistant.
4. Écriture : si un fait est confirmé, demander sa correction à la source dans un périmètre autorisé puis relire la fiche. La lecture précédente ne vaut pas accord pour corriger.
5. Externe : décider séparément si une réponse peut être envoyée. Aucun envoi, capture navigateur ou reçu destinataire n’est fourni par cet exemple.

Une consigne à adapter : « Relis la fiche choisie. Prépare uniquement un brouillon à partir des faits retournés ; sépare les inconnus et les confirmations humaines nécessaires. N’envoie rien et ne synchronise pas le CRM. » Vérifiez les permissions et le résultat ; la consigne seule n’est pas une garantie technique.

Exemple original entièrement fictif, SIM-102, fichier rapport-pedagogique-SIM-102.txt, daté du 1er octobre 2026. Aucun fournisseur d’historique ni véhicule réel n’est représenté. Passage présent : « Le 12 septembre 2026, une vidange est consignée dans le relevé pédagogique. »

• Fait citable : Une vidange est consignée le 12 septembre 2026 dans ce relevé fictif. Citez le fichier et le passage ; aucune inspection réelle n’est démontrée.
• Absence utile : une recherche « collision » retourne zéro passage sur la fixture. L’historique complet et le kilométrage restent inconnus. Ce résultat ne prouve pas l’absence d’incident.
• Supervision : Faire vérifier la pièce source et les rubriques absentes par le responsable. Le prix zéro, le statut en attente et le kilométrage absent de la fiche ne changent pas.

Le SDK et la copie du serveur servi ont contrôlé ces lectures en mémoire avec un CRM simulé. Ce contrôle ne teste ni extraction OCR, ni lecture d’un rapport client, ni réponse Muse, ni envoi.

Pour une demande sur l’entretien, le brouillon pédagogique peut reprendre la ligne citée et annoncer les limites. Il ne peut pas transformer une recherche vide en « aucun incident ». Retrouvez les lectures contrôlées du même exemple et les conditions de qualité.

Avant une écriture, faites relire la cible et annoncez les effets attendus. Les six écritures CRM utilisent un request_id stable pour la même opération. Les mises à jour client ou véhicule contrôlent expected_updated_at ; celles d’un événement contrôlent expected_revision. Un conflit appelle une nouvelle lecture, pas un écrasement aveugle.

Après une interruption, vérifiez le reçu et l’état cible avant de répéter la demande. Ajouter une note ne signifie pas envoyer un message. Créer une tâche n’établit pas qu’elle a été réalisée ; l’événement client est assigné au compte connecté. La référence des autorisations complète les contrôles de périmètre.

Une préparation peut réussir alors que l’accès navigateur ou l’autorisation d’action manque. Gardez le brouillon comme résultat de préparation, puis nommez l’étape manquante. Pour une republication, l’intention enregistrée précède l’exécution ; une issue published exige une preuve Facebook et l’identifiant de l’annonce.

Pour Messenger, le ticket de coordination précède un clic autorisé ; la confirmation s’appuie sur une relecture native indépendante. Une synchronisation CRM enregistre des observations et peut créer ou enrichir un contact, mais ne prouve pas une livraison. Si l’issue reste incertaine, interrompez la reprise et faites examiner l’état avant un nouveau geste.

Ce guide ne revendique aucun essai externe réussi ni gain de temps mesuré. La décision et la préparation restent utiles tant que leurs limites sont visibles.

• Utilisable dans ce périmètre : source et cible identifiées, accès adaptés, résultat vérifié et responsable désigné.
• À compléter : une preuve, un champ ou un accès manque ; conserver le résultat acquis et nommer le contrôle restant.
• À interrompre : mauvaise organisation, cible ambiguë, effet inattendu ou issue d’action incertaine.

Pour comparer des CRM et organiser un pilote, utilisez la grille de choix CRM. Pour qualifier les valeurs de la fiche, utilisez le guide de qualité d’inventaire. Ici, la décision porte sur la tâche à déléguer et sa preuve de réussite.