D3 · Context, Tools and Permissions

Le second des deux domaines les plus lourds — 18 %, environ 9 des 50 items. Il teste deux jugements appariés : donner à un agent assez de contexte et d’outils pour réussir, et ne lui donner pas plus d’accès que la tâche n’en a besoin. Sous-provisionnez et l’agent devine ; sur-provisionnez et vous avez confié à un travailleur capable et littéral les clés de pièces où il n’avait jamais besoin d’entrer. Le matériel récompense la pensée du moindre privilège appliquée à un workspace agent qui agit en votre nom et hérite d’une portée à laquelle vous n’avez peut-être pas pensé.

Ce qu’il faut savoir

Un agent a besoin de quatre sortes de contexte : le brief de tâche (de D2), les documents sources pour cette tâche, la connaissance d’entreprise pertinente (politiques, standards, faits produit), et les décisions antérieures pour qu’il ne remette pas en cause des questions tranchées. Il a besoin d’outils et connectors pour atteindre les données et prendre des actions — mais chacun est à la fois capacité et rayon d’impact. Le moindre privilège signifie accorder le minimum de contexte et d’accès que la tâche exige et n’élargir que sur preuve du besoin. Un workspace agent agit avec une portée réelle dans les fichiers, connectors et systèmes partagés, donc son périmètre doit être fixé délibérément : ce qu’il peut lire, ce qu’il peut écrire, et où il doit s’arrêter. Le contexte et l’accès sont les deux moitiés de la même mise en place : le bon contexte rend l’agent compétent ; le bon accès le rend sûr.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Identifier les quatre sortes de contexte dont un agent a besoin et fournir chacune depuis le bon endroit.
2. Distinguer le contexte dont l’agent a besoin du bruit qui dégrade son travail.
3. Faire correspondre les outils et connectors à ce que la tâche exige réellement.
4. Appliquer la pensée du moindre privilège à l’accès d’un agent, en séparant lecture d’écriture et interne d’externe.
5. Cadrer un workspace agent délibérément, en raisonnant sur la portée dont il hérite.
6. Diagnostiquer si un échec est venu d’un contexte manquant ou d’un accès manquant.

3.1 Les quatre sortes de contexte

Un agent démarre avec seulement ce que vous lui donnez plus ce que ses outils peuvent chercher. Le contexte manquant est la cause la plus fréquente d’un travail faux avec assurance — l’agent comble le manque avec une supposition.

        ce que l’agent sait
        ┌───────────────────────────────────────────┐
        │  BRIEF DE TÂCHE (pourquoi + quoi + terminé)  │  vous fournissez
        │  DOCS SOURCES   (les entrées de cette tâche)  │  vous joignez
        │  CONN. ENTREP.  (comment on fait ici)         │  le workspace fournit
        │  DÉCISIONS ANT. (ce qui est déjà décidé)      │  vous indiquez
        └───────────────────────────────────────────┘
                 des manques ici ─► l’agent devine pour les combler

3.2 Plus de contexte n’est pas toujours mieux

Le contexte a un coût. Déverser chaque document que vous avez dans la tâche enterre le signal pertinent et peut activement égarer l’agent vers ce qui était le plus long ou le plus récent. La compétence est de fournir ce qui est pertinent et faisant autorité, pas tout ce qui est disponible.

Le lien avec les sources de vérité de D2 est direct : nommez ce qui fait autorité et fournissez cela, plutôt que tout en espérant que l’agent démêle. En cas de doute, fournissez le document source spécifique et la tranche pertinente de connaissance d’entreprise — pas le disque entier.

3.3 Outils et connectors : faire correspondre la capacité à la tâche

Les outils sont la façon dont un agent atteint au-delà du texte devant lui — recherche, accès aux fichiers, connectors vers des systèmes partagés, la capacité de rédiger ou d’envoyer. Le provisionnement est un exercice d’appariement : de quoi cette tâche a-t-elle réellement besoin ?

Le motif : lecture avant écriture, brouillon avant envoi, un système avant plusieurs. Chaque échelon gravi sur cette échelle ajoute capacité et rayon d’impact ensemble, donc ne franchissez chaque échelon que quand la tâche l’exige.

3.4 La pensée du moindre privilège

Le moindre privilège est le principe directeur de tout le domaine : accordez le minimum d’accès dont la tâche a besoin, et n’élargissez que sur preuve du besoin. C’est l’opposé du tentant « donne-lui tout pour qu’il ne se bloque jamais ».

              rayon d’impact
      faible ◄──────────────────────────► élevé
      lire un      lire un système  écrire   envoyer /
      document     partagé          données  publier / payer
      │            │                │        │
      commencez ici┘                │        │
      élargissez seulement si une   │        │
      exécution l’exige vraiment ───┴────────┘
                                  encadrez tout ce qui est à droite

Pourquoi cela importe spécifiquement pour les agents : un agent est autonome et littéral. S’il peut atteindre quelque chose, il le fera peut-être — pour satisfaire le but — en touchant des données ou en prenant une action que vous n’aviez jamais prévue. Un accès étroit signifie qu’un malentendu reste contenu. Un large accès signifie qu’un malentendu devient un incident.

3.5 Un agent hérite d’une portée — pensez à ce qu’il peut toucher

Un workspace agent agit en votre nom et à travers les connectors et permissions qui lui ont été donnés. Cela signifie qu’il peut atteindre tout ce que ces connectors atteignent — ce qui peut être plus que la tâche immédiate ne le suggère. Avant de déléguer, demandez ce que l’accès accordé expose réellement.

Le principe : la portée de l’agent est l’union des connectors que vous activez, et il utilisera n’importe lequel si le but semble l’appeler. Cadrez chaque connector sur la tranche la plus étroite qui fonctionne.

3.6 Diagnostiquer contexte manquant contre accès manquant

Quand un agent sous-performe, distinguez les deux familles d’échec — les correctifs sont opposés.

La sortie de l’agent est fausse ou incomplète
│
├─ A-t-il agi sur des faits faux/génériques, dévié de la marque,
│  ou rouvert une question tranchée ?    ──► CONTEXTE MANQUANT
│                                             correctif : fournir le doc source /
│                                             connaissance d’entreprise / décision antérieure
│
└─ A-t-il dit qu’il « ne pouvait pas accéder », s’est arrêté avant une
   étape, ou n’a pas pu atteindre un système requis ? ──► ACCÈS MANQUANT
                                              correctif : accorder l’outil/connector spécifique
                                              (moindre privilège), pas tout

Confondre les deux gaspille des efforts : accorder plus d’outils ne corrigera pas une réponse hors marque (c’est du contexte), et coller plus de documents ne corrigera pas « je n’ai pas accès au CRM » (c’est un connector). Lisez le symptôme, puis appliquez le correctif correspondant.

Cadre de décision

Utilisez la checklist de provisionnement CARE avant chaque délégation : Context (contexte), Access (accès), Reach (portée), Evidence (preuve). Remplissez chacune et vous provisionnez un agent à la fois compétent et contenu.

Appliquez-le demain : pour toute tâche, écrivez les quatre lignes. Si Access ou Reach est plus large que la tâche n’en a besoin, réduisez-le avant d’exécuter — c’est le moindre privilège en pratique.

Erreurs fréquentes

Mise en situation

Scénario. Amara, une responsable customer success sur ChatGPT Work, veut qu’un agent rédige des e-mails de synthèse de renouvellement pour douze comptes en renouvellement ce trimestre. Elle connecte l’agent au disque client partagé et à la boîte de réception d’équipe pour qu’il « ait tout ce dont il a besoin », et lui donne le but. Les brouillons reviennent en citant une politique de tarification périmée, en référençant des détails de fichiers de clients sans rapport, et un brouillon cite une note de marge interne qui ne devrait jamais quitter l’entreprise. Amara se demande si l’agent est simplement peu fiable pour ce genre de travail.

Trace de raisonnement d’expert.

1. Séparez contexte et accès. Deux problèmes distincts sont mêlés ici : la politique de tarification périmée est un échec de contexte (il a utilisé une connaissance périmée), tandis que référencer des clients sans rapport et citer une note de marge interne sont des échecs de portée (il a touché des données qu’il n’aurait jamais dû atteindre).
2. Corrigez le manque de contexte avec des sources faisant autorité, pas plus d’outils. La politique périmée signifie que la politique de tarification actuelle n’a pas été fournie comme connaissance d’entreprise faisant autorité ; l’agent s’est rabattu sur ce qu’il a trouvé. Fournissez la politique actuelle et nommez-la comme source de vérité (D2).
3. Diagnostiquez le sur-provisionnement. Connecter le tout le disque partagé et la toute boîte de réception d’équipe a donné à l’agent une portée sur les fichiers de chaque client et chaque fil interne. C’est un travailleur littéral et autonome : donné une tâche de renouvellement et l’accès à tout, il a puisé dans tout.
4. Appliquez le moindre privilège / le cadrage. La tâche a besoin, par compte, du fichier de ce compte — pas du disque entier. Cadrez le connector sur le dossier de renouvellement spécifique ou les douze enregistrements de compte, et retirez entièrement le connector de boîte de réception (rédiger des e-mails ne nécessite pas l’accès en lecture à l’historique de la boîte). La note de marge interne n’aurait jamais dû être atteignable.
5. Ajoutez les distinctions lecture/écriture et brouillon/envoi. L’agent a besoin de l’accès en lecture aux données de compte et de la capacité de produire des brouillons. Il n’a pas besoin de l’envoi — les e-mails devraient atterrir en brouillons pour qu’Amara les revoie et les envoie, encadrant l’unique étape irréversible.
6. Provisionnez, n’abandonnez pas. L’agent n’est pas « peu fiable pour ce travail » ; il était mal provisionné. Relancez avec un accès en lecture cadré sur les bons enregistrements, la politique actuelle comme contexte faisant autorité, une sortie en brouillon seulement, et la note interne hors de portée — et le même agent produit des brouillons sûrs et conformes.

Le point clé. « Donne-lui tout pour qu’il ait ce dont il a besoin » a causé à la fois la fuite et le bruit. Le correctif est CARE : fournir le bon contexte (politique actuelle), cadrer l’accès sur les enregistrements de compte, vérifier la portée pour que les notes internes soient inatteignables, et n’élargir que sur preuve — rien de quoi ne nécessite un modèle différent.

Pièges de l’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

À retenir

• Un agent a besoin de quatre sortes de contexte : brief de tâche, documents sources, connaissance d’entreprise, décisions antérieures — les manques sont comblés par des suppositions.
• Plus de contexte n’est pas toujours mieux ; l’excès enterre le signal faisant autorité et peut ancrer l’agent sur la mauvaise source.
• Faites correspondre les outils à la tâche sur l’échelle lecture→écriture→envoi ; chaque échelon gravi ajoute capacité et rayon d’impact ensemble.
• Moindre privilège : accordez le minimum d’accès dont la tâche a besoin et n’élargissez que sur preuve — « par sécurité, donne-lui tout » est toujours le piège.
• Un connector expose tout ce qu’il atteint ; un workspace agent hérite de cette portée et l’utilisera, donc cadrez chaque connector étroitement.
• Distinguez le contexte manquant (hors marque, générique, rouvre des décisions) de l’accès manquant (« ne peut pas atteindre le système ») — les correctifs sont opposés.
• Utilisez CARE — Context, Access, Reach, Evidence — pour provisionner un agent à la fois compétent et contenu.