Test d'acceptation de ChatGPT Computer History : guide macOS pour la mémoire du contexte de travail

ChatGPT Computer History a besoin d'un test d'acceptation strict, pas d'une vérification au ressenti. La fonctionnalité peut réduire le travail fastidieux qui consiste à reconstruire le contexte après des réunions, des recherches dans le navigateur, des modifications de brouillons ou des changements de tâche. C'est utile. C'est aussi exactement le type de fonctionnalité qui peut paraître impressionnante tout en récupérant discrètement un contexte obsolète, vague ou mal attribué.

Le seuil est simple : l'activité de travail mémorisée doit être exacte, actuelle, attribuable et délimitée. Si l'un de ces points échoue, l'assistant peut produire de la confiance sans preuve. C'est pire que de redemander le contexte à l'utilisateur.

OpenAI décrit Computer History comme une fonctionnalité de contexte de travail pour l'application de bureau macOS, désactivée par défaut, destinée aux utilisateurs ChatGPT Pro, Business et Enterprise. Les utilisateurs Pro peuvent choisir de l'activer. Les administrateurs des espaces de travail Business et Enterprise doivent accorder l'accès avant que les membres puissent l'activer. La fonctionnalité exige Memories, n'est pas disponible via une clé API ni Amazon Bedrock, et n'est pas actuellement disponible dans l'EEE, en Suisse ou au Royaume-Uni. OpenAI indique aussi que Computer History enregistre des événements d'interaction plutôt que des captures d'écran, et ne capture ni écran ni audio.

Cette description produit n'est pas un modèle opérationnel. L'acceptation en production exige une question plus étroite : Computer History améliore-t-il un travail macOS précis tout en gardant les sources et les limites testables ? Cet article présente le test d'acceptation Optijara Computer History, ou CHAT. C'est un guide de mémoire du contexte de travail sur macOS, pas un plan de contrôle pour agents autonomes ni une checklist générique de confidentialité. Si votre équipe utilise déjà une logique de tests d'acceptation pour les systèmes d'IA, il s'aligne sur nos recommandations concernant les tests d'acceptation des routes vocales, les tests d'acceptation des routes d'inférence et l'acceptation des benchmarks de raisonnement spatial.

Ce que ChatGPT Computer History change sur macOS

Des préférences enregistrées aux événements de contexte de travail

Memories permet à ChatGPT et Codex de transporter un contexte utile d'un travail précédent vers un travail futur. Computer History pousse cette idée vers l'activité informatique récente. OpenAI décrit des activités dans les applications et sur les sites web qui deviennent des souvenirs et une chronologie que ChatGPT et Codex peuvent consulter. Le changement pratique n'est pas que l'assistant sait soudainement tout. C'est que des événements de travail récents peuvent l'aider à identifier la source que vous visiez, à reprendre une tâche ou à suggérer une compétence ou une automatisation à partir de flux de travail répétés.

Cela change ce qui doit être testé. Une fonctionnalité de mémoire classique peut être vérifiée en demandant si une préférence a été stockée correctement. La mémoire de contexte de travail comporte plus de points de défaillance : capture des événements, recherche de source, inclusion des applications et des sites, suppression, comportement de pause, séparation des comptes et correction par l'utilisateur.

Éligibilité, accès opt-in et dépendance à Memories

Avant de tester la qualité, vérifiez l'accès. La documentation mentionne les utilisateurs ChatGPT Pro, Business et Enterprise dans l'application de bureau ChatGPT sur macOS. Les utilisateurs Pro peuvent l'activer directement. Les utilisateurs Business et Enterprise ont d'abord besoin d'un accès administrateur, puis d'un opt-in individuel. Computer History dépend aussi de Memories. Si Memories est désactivé, bloqué par une politique ou indisponible dans la région de l'utilisateur, Computer History n'est pas prêt pour cet utilisateur ou cet espace de travail.

La documentation macOS d'Apple ajoute une autre couche. Les applications peuvent exiger une autorisation pour l'enregistrement de l'écran, l'enregistrement de l'audio système et d'autres catégories de confidentialité. Même si OpenAI indique que Computer History ne capture ni écran ni audio, les réglages de confidentialité macOS restent importants. Les utilisateurs et les administrateurs doivent savoir à quoi l'application de bureau peut accéder et quelles autorisations sont inutiles pour le test prévu.

Ce qui reste une affirmation fournisseur tant que ce n'est pas testé

Les exemples d'OpenAI incluent reprendre là où vous vous étiez arrêté, retrouver un travail récent, comprendre des schémas et transformer des flux de travail répétés en compétences ou automatisations. Traitez ces exemples comme des hypothèses. Ne supposez pas de gain de productivité, d'économies de coûts ou d'amélioration de fiabilité tant que des tâches contrôlées n'ont pas été exécutées sur de vrais flux de travail.

Le point d'acceptation pratique est que Computer History est en partie un problème de provenance avec une expérience utilisateur utile par-dessus. Si la piste des sources est faible, la commodité ne vaut pas grand-chose.

Le framework CHAT : contexte, historique, attribution et frontières de confiance

C : gain de contexte par rapport à une référence sans historique

Exécutez la même tâche deux fois lorsque c'est possible. Lancez-la d'abord avec Computer History désactivé. Relancez-la ensuite avec Computer History activé pour un compte de test. Les bons candidats incluent la reprise d'un brouillon, la recherche d'une source utilisée plus tôt, le résumé d'un fil de travail récent ou la réconciliation d'une exigence modifiée. Le point n'est pas de savoir si l'assistant paraît plus confiant. Le signal utile est de savoir s'il a besoin de moins de questions de clarification, identifie le bon artefact et termine la tâche avec moins de reconstruction manuelle du contexte.

H : qualité de l'historique, obsolescence et gestion des corrections

La qualité de l'historique ne se limite pas au rappel. Testez des documents aux noms similaires, d'anciens brouillons, des pages supprimées et des exigences modifiées. Demandez à l'assistant d'utiliser la décision la plus récente, puis vérifiez s'il ignore l'activité supplantée. Corrigez-le lorsqu'il se trompe et vérifiez si la correction tient dans la tâche en cours. Un système qui rappelle couramment le mauvais événement doit échouer à cette couche tant que le flux de travail n'est pas resserré.

A : attribution par parité de réouverture de source

OpenAI indique que Computer History peut aider ChatGPT et Codex à identifier une meilleure source, puis à la lire directement lorsque c'est approprié. Votre test d'acceptation doit exiger la parité de réouverture de source. Si l'assistant dit qu'une activité précédente provenait d'un fichier, d'une page, d'un espace de travail ou d'une application, l'utilisateur doit pouvoir vérifier cette source. Le contexte mémorisé est un indice. Ce n'est pas une preuve tant que la source n'est pas vérifiée.

T : frontières de confiance pour les applications, sites, comptes et fenêtres sensibles

C'est ici que de nombreux pilotes devraient ralentir. Testez la navigation privée, les fenêtres de gestionnaire de mots de passe, les documents sensibles, les sites web exclus, la politique d'administration et l'utilisation de plusieurs comptes. La question centrale est de savoir si Computer History peut être limité à l'activité de travail qui aide la tâche tout en laissant l'activité sans rapport ou sensible hors du test.

Construire le test d'acceptation avant d'activer la mémoire de contexte de travail

Commencez par une référence propre. Choisissez cinq à dix tâches représentatives, puis exécutez-les sans Computer History. Capturez le prompt, les artefacts fournis, les questions de clarification posées, la qualité de la réponse et le résultat de vérification des sources. N'utilisez pas de données de production sensibles pour rendre le test réaliste. Utilisez des exemples sûrs qui reproduisent la structure réelle sans exposer d'identifiants, de données personnelles ou de matériel réglementé.

Activez la fonctionnalité pour un petit groupe de test seulement après confirmation de l'accès, de la région, du statut de Memories et de l'approbation administrateur. Répétez ensuite les tâches de référence. Posez des questions pratiques : quel document étais-je en train de modifier avant la réunion, quelle source ai-je utilisée pour cette affirmation, quelle exigence a changé hier, ou où en étais-je dans le brouillon ? Une réussite exige plus qu'une réponse plausible. L'assistant doit identifier le bon événement antérieur, distinguer des projets similaires, poser une question lorsque l'historique est ambigu et éviter d'inventer de l'activité.

Les tests de frontières doivent être explicites. Créez une liste d'autorisation ou une liste d'exclusion pour les applications et les sites, puis vérifiez le comportement avec des applications approuvées, des applications exclues, des fenêtres de navigation privée, des gestionnaires de mots de passe, des documents sensibles et des comptes séparés. Passez en revue les réglages Confidentialité et sécurité de macOS afin que les utilisateurs sachent quelles autorisations sont actives. Si une tâche exige une collecte large pour fonctionner, ce n'est peut-être pas la bonne tâche pour Computer History.

OpenAI indique que les utilisateurs peuvent inspecter, mettre en pause et supprimer l'historique. Testez ces contrôles avant le déploiement. Mettez la collecte en pause, effectuez une activité de test, puis confirmez qu'elle ne devient pas un contexte utilisable. Supprimez l'historique pertinent et voyez si l'assistant y fait encore référence. Confirmez où le stockage local et le comportement de rétention sont documentés pour votre version et votre type de compte. Enfin, prouvez le retour arrière. L'utilisateur doit pouvoir revenir à un état sûr connu sans perdre de réglages sans rapport.

Matrice de décision : activer, restreindre, surveiller ou conserver le contexte explicite

Les meilleurs premiers cas d'usage sont récents, à faible risque et vérifiables par source. Pensez à reprendre une recherche, localiser une page utilisée plus tôt, revenir à un brouillon ou relier des événements de travail approuvés et connexes. Ces tâches bénéficient de la mémoire parce que le contexte manquant est généralement temporel : qu'étais-je en train de faire, où était la source et quel élément venait ensuite ?

Utilisez le contexte explicite lorsque les versions exactes comptent, que la sensibilité des données est élevée, que la séparation des comptes est stricte ou que la réponse doit être auditable. Un extrait collé, un dossier projet, une base de connaissances approuvée ou une référence de fichier précise peut être moins pratique, mais c'est plus facile à vérifier. La mémoire de contexte de travail ne doit pas remplacer les preuves contrôlées pour les tâches à forte assurance.

Pour les équipes, commencez par un pilote. Gardez le groupe petit. Notez les autorisations. Définissez une politique d'inclusion ou d'exclusion. Mesurez un ensemble de tâches que les personnes effectuent réellement. N'étendez que lorsque le gain de contexte, l'attribution, la suppression, la pause et le retour arrière sont prouvés. Si un test de frontière échoue, restreignez le flux de travail au lieu de demander aux utilisateurs d'être plus prudents.

Plan de mesure : prouver la qualité sans sur-collecter

Suivez les compromis opérationnels avec des mesures locales lorsque vous le pouvez. Computer History peut ajouter du contexte qui modifie l'utilisation des tokens ou la latence, mais l'effet final dépend de la tâche, du modèle, du compte, de l'état de l'application et du comportement de récupération. Mesurez vos propres flux de travail au lieu de copier des exemples fournisseur dans une justification métier.

{
  "framework": "CHAT",
  "recommended_status": "canary_before_team_rollout",
  "required_controls": ["memories_enabled", "admin_access_confirmed", "app_site_boundaries", "pause_delete_tested", "source_reopen_parity"],
  "test_cases": ["no_history_baseline", "context_recovery", "stale_event_rejection", "sensitive_window_exclusion", "rollback"],
  "rollback_ready": false,
  "unresolved_risks": ["ambiguous_history", "prompt_injection_from_recorded_activity", "multi_account_separation"]
}

Erreurs courantes des équipes avec la mémoire de contexte de travail

Un événement mémorisé n'est pas une preuve. Si une réponse dépend d'une source antérieure, exigez la parité de réouverture de source. C'est important lorsqu'un document a été modifié, renommé, supprimé ou supplanté. Les démonstrations sur le chemin heureux sont trop faciles, alors ajoutez des cas désordonnés : noms de fichiers similaires, notes contradictoires, brouillons abandonnés, anciens onglets de navigateur et tâches où la bonne réponse est de poser une question de clarification.

L'activité enregistrée peut inclure des pages, des notes ou des chats contenant des instructions qui ne sont plus valides ou qui n'ont jamais été destinées à contrôler un travail futur. Traitez l'injection de prompt à partir d'une activité enregistrée comme un cas de test réel. L'assistant ne doit pas obéir à une ancienne page ou note simplement parce qu'elle figurait dans l'historique. La pause, la suppression, l'accès administrateur, la séparation des comptes et la réponse aux incidents doivent être testés avant un déploiement large. Si les utilisateurs ne peuvent pas revenir à un état sûr connu, le pilote n'est pas prêt.

Architecture de référence : flux d'événements vers mémoire puis récupération de source

Les contrôles commencent avant la collecte : éligibilité du compte, disponibilité régionale, accès administrateur, Memories, opt-in et autorisations macOS. Ils continuent pendant la collecte au moyen de l'inclusion des applications et des sites, des exclusions et des contrôles de pause. Ils comptent encore lors de la récupération, où la parité des sources, la correction utilisateur et les tests de suppression déterminent si le contexte devient une preuve utilisable.

Si Computer History ne se comporte pas comme prévu, vérifiez l'éligibilité du plan, les régions non prises en charge, le statut de Memories, la version de l'application de bureau, l'accès administrateur, les applications ou sites exclus, les autorisations macOS, l'incohérence de compte, les événements obsolètes et si la source peut réellement être rouverte. Gardez les notes de dépannage attachées au test d'acceptation afin que les échecs améliorent la politique de déploiement au lieu de disparaître dans l'historique du chat.

Réserves, séquence de déploiement et angle conseil d'Optijara

Computer History ne remplace pas la gestion des preuves. Il peut être affecté par le coût de mise en oeuvre, les compromis de confidentialité, le comportement du modèle, l'obsolescence de la mémoire, les limites de récupération, les changements d'autorisations, la formation des utilisateurs et le support opérationnel. Plus de contexte n'est pas toujours mieux. La frontière utile est le plus petit ensemble d'activités de travail enregistrées qui améliore une tâche définie et peut être vérifié.

Une séquence de déploiement pratique est directe. Documentez le périmètre. Exécutez la référence sans historique. Configurez les autorisations et les frontières. Exécutez les cas de test CHAT. Passez en revue les échecs. Lancez un pilote. Surveillez la qualité, le comportement des frontières et les frictions opérationnelles. Préparez la réponse aux incidents et le retour arrière. N'étendez que si les preuves le soutiennent.

Optijara aide les équipes à transformer les nouvelles fonctionnalités de mémoire IA en tests d'acceptation, contrôles de déploiement et procédures opérationnelles. L'objectif n'est pas de faire paraître chaque nouvelle fonctionnalité sûre par défaut. L'objectif est de décider où elle améliore le travail, où elle doit être restreinte et où le contexte explicite du projet reste le meilleur outil.