# D4 · Choosing the Right Capability
La décision centrale de la piste — choisir entre un prompt, une instruction enregistrée, un Project, un GPT personnalisé, un agent de workspace et une application API, et quand recourir à search, deep research, l’analyse de données, Canvas ou l’import de fichiers.
import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components';
C’est le domaine le plus lourd de l’examen blanc — **20 %**, environ **10 items sur 50** — et c’est la section que le matériel Applied AI désigne comme la chose la plus utile à maîtriser. Il teste un jugement de façon répétée : étant donné une tâche, *avec quoi devriez-vous réellement la construire ?* La réponse suit une échelle allant de l’option la plus légère (un prompt bien écrit) à la plus lourde (une application API), et le savoir-faire consiste à recourir à la **capacité la plus légère qui répond au besoin** plutôt qu’à la plus impressionnante.
## Ce qu’il faut savoir
ChatGPT offre une échelle de façons de packager un workflow : un **prompt ponctuel**, une **instruction enregistrée** (custom instructions / un prompt réutilisable), un **Project** (un workspace avec ses propres instructions et fichiers de connaissances pour un contexte récurrent), un **GPT personnalisé** (un assistant partageable et configuré pour une tâche répétable que d’autres peuvent exécuter), un **agent de workspace** (travail multi-étapes délégué avec supervision), et — quand vous dépassez ChatGPT — une **application API** (programmatique, intégrée, scalable). Orthogonales à cette échelle se trouvent les *capacités en conversation* que vous activez quand une tâche en a besoin : **search** pour des faits actuels, **deep research** pour une synthèse sourcée multi-sources, l’**analyse de données** pour du calcul sur des fichiers, **Canvas** pour itérer sur un document ou du code, et l’**import de fichiers** pour travailler sur vos propres documents. Le jugement gagnant est de gravir l’échelle seulement aussi loin que la répétabilité, le partage et l’intégration l’exigent réellement.
## Objectifs d’apprentissage
À la fin de cette page, vous devriez être capable de :
1. **Placer** une tâche sur l’échelle prompt → instruction enregistrée → Project → GPT personnalisé → agent de workspace → application API.
2. **Justifier** le choix de l’échelon le plus léger qui répond au besoin, et reconnaître le sur-dimensionnement et le sous-dimensionnement.
3. **Sélectionner** la bonne capacité en conversation — search, deep research, analyse de données, Canvas, import de fichiers — à partir des signaux de la tâche.
4. **Distinguer** un Project d’un GPT personnalisé, et un GPT personnalisé d’un agent de workspace.
5. **Décider** quand un workflow a dépassé ChatGPT et relève d’une application API.
---
## 4.1 L’échelle des capacités
```text
LE PLUS LÉGER ────────────────────────────────────────────────► LE PLUS LOURD
Prompt Instruction Project GPT perso. Agent de API
(ponctuel) enregistrée (contexte (assistant workspace application
(réutilisable) récurrent + partageable, (multi-étapes (programmatique,
connaissances) configuré) délégué) intégrée)
▲ ▲
pour une quand vous quand une quand D’AUTRES quand une quand ça doit
seule répétez le tâche a besoin exécutent la tâche multi- tourner en code,
tâche même prompt de son propre même tâche étapes peut à l’échelle, ou
souvent contexte/fich. sans vous être déléguée câblée à d’autres
avec supervis. systèmes
```
Chaque échelon ajoute de la capacité *et* du coût (mise en place, maintenance, gouvernance). La posture par défaut est : commencer à gauche, se déplacer à droite seulement quand un besoin concret vous y force.
| Échelon | Ce que c’est | Le besoin qui le justifie |
| --- | --- | --- |
| **Prompt** | Une seule instruction dans un chat | Une tâche ponctuelle |
| **Instruction enregistrée** | Custom instructions ou un prompt réutilisable que vous gardez | Vous répétez souvent le même prompt |
| **Project** | Un workspace ChatGPT avec ses propres instructions + fichiers de connaissances | Une tâche récurrente a besoin du même contexte/fichiers à chaque fois |
| **GPT personnalisé** | Un assistant configuré et partageable | *D’autres personnes* doivent exécuter la même tâche sans vous |
| **Agent de workspace** | Exécution multi-étapes déléguée avec supervision | Une tâche multi-étapes peut tourner de façon semi-autonome sous revue |
| **Application API** | Du code appelant l’API (Responses API) | Cela doit tourner de façon programmatique, à l’échelle, ou s’intégrer à d’autres systèmes |
:::tip[Signal d’évaluation]
« Je recolle sans cesse le même contexte » → **Project**. « Mes coéquipiers doivent l’exécuter aussi » → **GPT personnalisé**. « Cela doit tourner dans notre application / sur une planification à l’échelle / câblé à notre base de données » → **application API**. Faites correspondre le *besoin* de l’énoncé à l’échelon ; le piège est un énoncé décrivant un besoin de Project et une réponse « construire un GPT personnalisé / une application API ».
:::
## 4.2 Prompt vs instruction enregistrée vs Project
Les trois premiers échelons sont tous dans votre propre usage de ChatGPT ; la différence est *ce qui persiste*.
| | Persiste ? | Partageable ? | Porte des fichiers ? | Choisir quand |
| --- | --- | --- | --- | --- |
| Prompt ponctuel | Non | Non | Joindre au coup par coup | Vous le faites une fois |
| Instruction enregistrée | L’instruction | Copier/coller | Non | Vous répétez souvent la même demande |
| Project | Instructions + fichiers de connaissances + chats | Projects partagés avec votre workspace | Oui (fichiers de connaissances) | Une tâche a besoin du même contexte permanent à chaque fois |
**Exemple travaillé.** Vous écrivez une synthèse hebdomadaire qui a toujours besoin du guide de style de l’équipe et des OKR du trimestre dernier.
- *Prompt à chaque fois :* vous recollez le guide de style et les OKR chaque semaine — gaspilleur et source d’erreurs.
- *Instruction enregistrée :* la demande est enregistrée, mais vous joignez encore les fichiers à chaque fois.
- *Project :* le guide de style et les OKR vivent comme fichiers de connaissances ; l’instruction du Project dit « produire la synthèse du vendredi dans le gabarit maison ». Vous n’avez qu’à déposer les mises à jour de la semaine. C’est le bon échelon — le contexte récurrent est exactement ce à quoi sert un Project.
## 4.3 Project vs GPT personnalisé
Les deux détiennent des instructions permanentes et des connaissances. La question qui les sépare est **qui l’exécute**.
```text
D’AUTRES personnes doivent-elles exécuter cette tâche, seules, sans vous ?
│
├─ Non ─► PROJECT (votre workspace récurrent ; partageable au sein de votre équipe
│ comme un Project partagé, mais centré sur votre travail)
│
└─ Oui ─► GPT PERSO. (un assistant packagé que d’autres invoquent ; configuré une fois,
utilisé par beaucoup ; partageable dans le workspace)
```
Un Project est *votre* contexte récurrent. Un GPT personnalisé est un *produit que vous remettez à d’autres* : il emballe les instructions, les connaissances et le comportement afin qu’un collègue obtienne des résultats cohérents sans savoir comment vous l’avez configuré. Si la réponse à « qui l’exécute » est « moi seul, de façon répétée », un Project est plus léger et suffisant ; construire un GPT personnalisé est un sur-dimensionnement.
## 4.4 GPT personnalisé vs agent de workspace
Un GPT personnalisé *répond encore à une personne tour par tour*. Un **agent de workspace** *exécute une tâche multi-étapes* pour votre compte, en utilisant des outils et des connectors, sous supervision.
| | GPT personnalisé | Agent de workspace |
| --- | --- | --- |
| Interaction | Conversationnelle, un tour à la fois | Déléguée : donnez un objectif, il travaille sur plusieurs étapes |
| Idéal pour | Un *assistant* répétable avec lequel d’autres discutent | Une *tâche* répétable à exécuter avec des points de contrôle |
| Supervision | Vous lisez chaque réponse | Vous fixez des limites et relisez aux points de contrôle |
| Lien de piste | Ce domaine | Approfondi dans [Agents and Workflows](/fr/openai/agents/) |
Ne recourez à un agent de workspace que lorsque la tâche a réellement des *étapes à exécuter*, pas seulement des *questions à répondre* — et toujours avec la conception de supervision du [Domaine 5](/fr/openai/applied-ai/domains/d5-review-points-and-human-oversight/).
## 4.5 Quand quitter ChatGPT pour une application API
ChatGPT cesse d’être le bon conteneur quand le workflow doit être **embarqué, planifié à l’échelle, intégré ou gouverné de façon programmatique**.
| Signal | Pourquoi ChatGPT ne suffit pas | Où cela relève |
| --- | --- | --- |
| Doit tourner dans l’interface d’un autre produit | ChatGPT est une surface distincte | Application API |
| Des milliers d’exécutions sur une planification | L’usage manuel/agent ne scale pas à ce volume | API (avec Batch/Flex pour le coût) |
| Câblé à une base de données ou un service interne | Aucun chemin de données programmatique dans un chat | Application API (+ outils/MCP) |
| Contrats déterministes et journalisation requis | Vous avez besoin de code autour des appels au modèle | Application API |
| Une tâche humaine ponctuelle ou occasionnelle | Le code est excessif | Rester dans ChatGPT |
Le piège est de sauter à « construire une application API » pour une tâche qu’un Project ou un GPT personnalisé gère. Construire du logiciel a un coût réel ; il se justifie par l’échelle, l’intégration et le contrôle programmatique — pas par l’ambition.
## 4.6 Capacités en conversation — le second axe
Indépendamment de l’échelon où vous êtes, une tâche peut nécessiter d’activer une capacité spécifique. Faites correspondre le signal à la capacité.
| Capacité | Y recourir quand la tâche a besoin de… | Mots-signaux |
| --- | --- | --- |
| **Search** | Faits actuels, événements récents, info en direct au-delà des connaissances du modèle | « dernières », « actuelles », « aujourd’hui », « actualités récentes » |
| **Deep research** | Une synthèse sourcée sur de nombreuses sources, avec citations | « comparer sur le marché », « citer les sources », « rapport approfondi » |
| **Analyse de données** | Calcul, graphiques ou statistiques sur un fichier importé | « analyser ce tableur », « calculer », « tracer », « tendance » |
| **Canvas** | Itérer sur un document ou du code côte à côte | « rédiger et réviser », « éditer ceci ensemble », « travailler sur le doc » |
| **Import de fichiers** | Travailler sur *vos propres* documents | « résumer ce PDF », « répondre à partir de ces fichiers » |
**Search** répond rapidement à une question de faits actuels (« quoi de neuf sur X ? »). **Deep research** mène une investigation plus longue, multi-sources et sourcée (« produire une comparaison sourcée des cinq principaux fournisseurs »). Recourir à deep research pour une recherche factuelle rapide fait perdre du temps ; utiliser une simple search pour un rapport qui doit être *sourcé et exhaustif* sous-livre.
L’**import de fichiers** laisse le modèle *lire* vos documents. L’**analyse de données** lui laisse *calculer* dessus — totaux, tendances, graphiques, contrôles statistiques. Si la tâche est « résumer ce rapport », l’import suffit ; si c’est « trouver les cas atypiques et tracer la tendance », vous avez besoin de l’analyse de données.
**Canvas** est pour les livrables itératifs — un document ou du code que vous révisez sur plusieurs tours dans une surface d’édition dédiée. Si vous allez affiner le même artefact de façon répétée, Canvas vaut mieux que recoller ; pour une réponse en un seul jet, il est inutile.
:::tip[Signal d’évaluation]
Deux décisions de capacité se cachent dans la plupart des énoncés : *quel échelon* (packaging) et *quelle capacité en conversation* (search/research/analyse/Canvas/import). « Récent » ou « actuel » → search ; « comparaison sourcée » → deep research ; « calculer/tracer sur un fichier » → analyse de données ; « itérer sur le doc » → Canvas. Ne confondez pas search (rapide, actuel) avec deep research (long, sourcé).
:::
## 4.7 Le contexte et le coût du sur-dimensionnement
Les échelons plus lourds coûtent plus que de l’argent. Un Project doit être maintenu (des fichiers de connaissances périmés induisent en erreur), un GPT personnalisé partagé dans un workspace a besoin de gouvernance, un agent a besoin d’une conception de supervision, une application API a besoin d’ingénierie et de supervision opérationnelle. Le sur-dimensionnement avance un coût que vous ne récupérerez peut-être jamais ; le sous-dimensionnement (un prompt ponctuel pour une tâche que dix personnes exécutent chaque semaine) fait perdre du temps et produit des résultats incohérents. Le bon échelon minimise le coût *total* — construire + maintenir + gouverner — pour le besoin réellement présent.
---
## Cadre de décision
**Le jeu de questions LADDER** — posez-les dans l’ordre ; le premier « oui » qui ajoute un besoin authentique vous fait monter d’un échelon.
| # | Question | Si oui → cet échelon (au moins) |
| --- | --- | --- |
| **L** — Later (à nouveau) ? | Le referez-vous ? | Instruction enregistrée |
| **A** — Attached context (contexte joint) ? | A-t-il besoin des mêmes fichiers/contexte à chaque fois ? | Project |
| **D** — Delegated to others (délégué à d’autres) ? | D’autres personnes doivent-elles l’exécuter elles-mêmes ? | GPT personnalisé |
| **D** — Do steps run (des étapes s’exécutent) ? | Est-ce une tâche multi-étapes à *exécuter*, pas seulement à répondre ? | Agent de workspace |
| **E** — Embedded/at scale (embarqué/à l’échelle) ? | Doit-il tourner en code, à l’échelle, ou câblé à des systèmes ? | Application API |
| **R** — Right capability (bonne capacité) ? | A-t-il besoin de faits actuels, de sourçage, de calcul, ou d’itération sur doc ? | Activer search / deep research / analyse de données / Canvas |
Arrêtez-vous à l’échelon le **plus bas** dont le besoin est réellement présent. Si seul **L** est oui, une instruction enregistrée est la réponse — pas un GPT personnalisé parce qu’il « pourrait être utile à d’autres un jour ».
## Erreurs fréquentes
| Erreur | Pourquoi elle se produit | Que faire à la place |
| --- | --- | --- |
| Construire un GPT personnalisé quand *vous* seul exécutez la tâche | Les GPT personnalisés paraissent plus « sérieux » | Utiliser un Project ; c’est l’échelon plus léger et suffisant |
| Sauter à une application API pour une tâche de taille Project | L’ingénierie paraît l’option sérieuse | Réserver l’API à l’échelle, l’intégration ou le contrôle programmatique |
| Recoller le même contexte dans de nouveaux prompts chaque semaine | Ça marche et ne nécessite aucune mise en place | Déplacer le contexte récurrent dans les fichiers de connaissances d’un Project |
| Utiliser deep research pour une recherche factuelle rapide | « Research » paraît approfondi | Utiliser search pour les faits actuels ; réserver deep research aux rapports sourcés |
| Utiliser un chat simple pour une comparaison de marché sourcée | Il a répondu, plus ou moins | Deep research quand la sortie doit être multi-sources et citée |
| Importer un tableur puis demander des tendances calculées sans analyse de données | L’import semble couvrir les fichiers | Activer l’analyse de données pour le calcul, les statistiques et les graphiques |
| Recourir à un agent de workspace pour une seule question | Les agents sont l’échelon excitant | Les agents sont pour l’*exécution* multi-étapes ; une question est un prompt ou un GPT |
| Laisser des fichiers de connaissances périmés dans un Project | On installe et on oublie | Maintenir les connaissances du Project ; les fichiers périmés induisent silencieusement en erreur |
## Mise en situation
**Situation.** Marcus assiste une équipe de vente de 30 personnes. Chaque lundi, il compile une « synthèse des risques de deals » : il tire les notes de chaque commercial, vérifie les dernières actualités sur les cinq principaux comptes, calcule à partir de l’export CRM quels deals ont glissé par rapport à la semaine dernière, et rédige un résumé d’une page dans le gabarit de l’équipe avec le guide de style appliqué. Aujourd’hui il fait tout cela en prompts frais, recollant le guide de style et le gabarit à chaque fois, et cela prend deux heures. La direction veut désormais que *chaque commercial* accède en libre-service à une version personnelle, et veut que l’ensemble tourne à terme automatiquement chaque lundi matin et publie sur Slack. Le manager de Marcus dit « construis simplement une application API pour le tout ».
**Trace de raisonnement expert.**
1. **Séparer les deux décisions.** Il y a une question de *packaging* (quel échelon) et une question de *capacité* (quoi activer) — et il y a en fait deux consommateurs différents maintenant : le travail récurrent propre à Marcus, et la version libre-service des commerciaux, et une future version automatisée. Ils peuvent se situer à des échelons différents.
2. **Corriger d’abord le travail récurrent propre à Marcus — c’est un Project.** Recoller le guide de style et le gabarit chaque semaine est le signal Project classique (**A** — même contexte à chaque fois). Mettre le guide de style, le gabarit et la référence de la semaine dernière comme fichiers de connaissances dans un Project ; Marcus dépose les notes de cette semaine. Cela seul élimine l’essentiel des deux heures. Sauter directement à une application API pour *sa* tâche est un sur-dimensionnement.
3. **Attribuer les capacités en conversation.** « Dernières actualités sur les principaux comptes » → **search** (faits actuels), pas deep research, puisque c’est une extraction rapide de faits actuels par compte. « Quels deals ont glissé par rapport à la semaine dernière depuis l’export CRM » → **analyse de données** (calcul sur un fichier importé), pas seulement import de fichiers. La rédaction dans le gabarit est de la génération simple ; l’itérer pourrait utiliser **Canvas**.
4. **Gérer la version libre-service des commerciaux — c’est un GPT personnalisé.** « Chaque commercial exécute une version personnelle lui-même, sans Marcus » est le signal déterminant du GPT personnalisé (**D** — d’autres l’exécutent). Emballer les instructions et les connaissances partagées dans un GPT personnalisé partagé dans le workspace pour que chaque commercial obtienne une sortie cohérente. C’est plus léger qu’une application API et cela correspond exactement à « d’autres exécutent la même tâche ».
5. **Seule la version automatisée du lundi matin vers Slack justifie l’API.** « Tourner automatiquement sur une planification et publier sur Slack » est de l’embarquement + planification + intégration (**E**) — c’est la seule pièce qui dépasse réellement ChatGPT et relève d’une application API (avec la Responses API, outils/connectors, et Batch/Flex si le volume grandit). Mais c’est une pièce *future*, pas « le tout aujourd’hui ».
6. **Rejeter la réponse « une seule API » du manager.** Construire une application API pour l’ensemble avance le coût d’ingénierie et de gouvernance pour des parties (la synthèse propre de Marcus, le libre-service des commerciaux) qu’un Project et un GPT personnalisé gèrent bien plus économiquement. Le bon dimensionnement, c’est : Project maintenant, GPT personnalisé pour les commerciaux, API seulement pour l’intégration planifiée quand elle est réellement nécessaire.
**La décision :** un **Project** (avec search + analyse de données + Canvas) pour la synthèse récurrente de Marcus, un **GPT personnalisé partagé** pour le libre-service des commerciaux, et une **application API** *seulement* pour la future automatisation Slack planifiée — pas une seule application API pour tout. Chaque besoin correspond à l’échelon le plus léger qui le satisfait.
## Pièges de l’évaluation
| Piège | Pourquoi c’est tentant | Le discriminant |
| --- | --- | --- |
| « Construire un GPT personnalisé » pour une tâche que vous seul exécutez | Les GPT personnalisés paraissent plus capables | D’autres-l’exécutent est le déclencheur du GPT personnalisé ; le travail récurrent solo est un Project |
| « Construire une application API » pour le tout | L’ingénierie paraît sérieuse/scalable | Seuls l’échelle, l’intégration ou la planification programmatique justifient l’API |
| « Utiliser deep research » pour un fait actuel rapide | « Research » implique de l’approfondissement | Faits actuels → search ; deep research est pour les rapports sourcés multi-sources |
| « L’import de fichiers suffit » pour calculer des tendances | L’import lit bien le fichier | Le calcul/graphiques/statistiques nécessitent l’activation de l’analyse de données |
| « Utiliser un agent de workspace » pour une seule question | Les agents sont l’échelon excitant | Les agents exécutent des tâches multi-étapes ; une question est un prompt ou un GPT |
| « Un prompt par semaine suffit » pour un contexte récurrent | Ça marche sans mise en place | Le contexte permanent récurrent est exactement ce à quoi sert un Project |
## Questions d’entraînement
Chaque item indique combien de réponses sélectionner. Décidez avant de dévoiler.
A. Un prompt ponctuel avec les fichiers recollés à chaque fois
B. Un Project avec les fichiers en connaissances et des instructions permanentes
C. Une application API
D. Un agent de workspace
**Réponse : B.** Un contexte récurrent qui doit être présent à chaque fois est le signal déterminant d’un Project. Recoller (A) est le gaspillage qu’un Project élimine. Une application API (C) et un agent (D) sur-dimensionnent pour une tâche récurrente solo.
A. Quel modèle il utilise
B. Si d’autres personnes doivent exécuter la tâche elles-mêmes sans vous
C. Combien de fichiers de connaissances il a
D. Son réglage de température
**Réponse : B.** Un Project est votre workspace récurrent ; un GPT personnalisé emballe la tâche pour que d’autres l’exécutent indépendamment. Le modèle (A), le nombre de fichiers (C) et la température (D) ne déterminent pas lequel des deux vous faut.
A. Une instruction enregistrée
B. Un Project
C. Un GPT personnalisé
D. Une application API
**Réponse : D.** L’embarquement dans un autre produit, à la demande, intégré à une base de données est exactement ce à quoi sert une application API. Les instructions enregistrées (A), les Projects (B) et les GPT personnalisés (C) vivent tous dans ChatGPT et ne peuvent pas s’embarquer de façon programmatique dans votre application.
A. Deep research
B. Search
C. Analyse de données
D. Canvas
**Réponse : B.** Une recherche rapide de faits actuels est ce à quoi sert search. Deep research (A) est plus lourd — pour les rapports sourcés multi-sources. L’analyse de données (C) est pour le calcul sur des fichiers. Canvas (D) est pour itérer sur des documents.
A. Un chat simple sans outils
B. Search pour un titre
C. Deep research
D. Canvas seul
**Réponse : C.** Une comparaison multi-sources, citée et exhaustive est le cas d’usage de deep research. Un chat simple (A) ne peut pas la sourcer de façon fiable. Un seul titre de search (B) sous-livre. Canvas (D) est une surface d’édition, pas un outil de recherche.
A. L’import de fichiers seul
B. L’analyse de données
C. Search
D. Un GPT personnalisé
**Réponse : B.** Le calcul, la détection des cas atypiques et le tracé sur un fichier nécessitent l’analyse de données ; l’import seul laisse seulement le modèle lire le fichier (A). Search (C) est pour les faits actuels. Un GPT personnalisé (D) est un échelon de packaging, pas une capacité de calcul.
A. Un Project que vous gardez pour vous
B. Un GPT personnalisé partagé dans le workspace
C. Un prompt ponctuel que vous leur envoyez
D. Une application API
**Réponse : B.** D’autres exécutant la même tâche indépendamment, avec un comportement cohérent, est le signal du GPT personnalisé. Un Project solo (A) ne remet pas la tâche à d’autres. Un prompt ponctuel (C) produit de l’incohérence. Une application API (D) sur-dimensionne pour du libre-service dans ChatGPT.
A. Les échelons plus lourds sont toujours plus lents à exécuter
B. Chaque échelon plus lourd ajoute un coût de construction, de maintenance et de gouvernance qui n’est justifié que par un besoin réel
C. Les échelons plus légers sont toujours plus précis
D. C’est exigé par la politique d’OpenAI
**Réponse : B.** Gravir l’échelle ajoute un coût total de possession ; vous ne le payez que lorsqu’un besoin concret (contexte récurrent, partage, exécution, échelle/intégration) le justifie. Les échelons plus lourds ne sont pas intrinsèquement plus lents (A) ni moins précis (C). C’est un principe de conception, pas une règle de politique (D).
A. Une instruction enregistrée
B. Un Project
C. Un GPT personnalisé
D. Une application API
**Réponse : D.** Une exécution planifiée, automatisée, intégrée à Slack est de l’embarquement à l’échelle — la justification d’une application API. Les instructions enregistrées (A), les Projects (B) et les GPT personnalisés (C) ne tournent pas sur une planification câblée à Slack de façon programmatique.
A. Le travail est une tâche multi-étapes à exécuter, pas une seule question à répondre
B. D’autres personnes ont simplement besoin de discuter avec un assistant configuré
C. La tâche peut tourner de façon semi-autonome avec revue aux points de contrôle
D. Vous avez besoin des mêmes fichiers de référence présents à chaque fois
E. La sortie est une réponse d’une ligne
**Réponse : A et C.** Un agent de workspace exécute des tâches multi-étapes de façon semi-autonome sous supervision ; un GPT personnalisé répond tour par tour. D’autres discutant avec un assistant (B) est un GPT personnalisé. Des fichiers permanents (D) pointent vers un Project. Une réponse d’une ligne (E) est un prompt.
A. Une seule application API pour les trois
B. Un Project pour (a), un GPT personnalisé partagé pour (b), et une application API seulement pour (c)
C. Un GPT personnalisé pour les trois
D. Tout garder en prompts hebdomadaires
**Réponse : B.** Chaque besoin correspond à un échelon différent : contexte solo récurrent → Project ; d’autres en libre-service → GPT personnalisé ; automatisation planifiée intégrée → API. Une seule application API pour tout (A) sur-construit (a) et (b). Un GPT personnalisé pour tout (C) ne peut pas faire de publication Slack planifiée. Les prompts hebdomadaires (D) ne scalent pas et ne sont pas en libre-service.
A. Search
B. Deep research
C. Canvas
D. Analyse de données
**Réponse : C.** Canvas est la surface dédiée pour itérer sur un document ou du code au fil des tours. Search (A) et deep research (B) rassemblent de l’information ; l’analyse de données (D) calcule sur des fichiers — aucun n’est une surface d’édition/itération.
A. Déplacer le contexte dans les fichiers de connaissances d’un Project avec des instructions permanentes
B. Construire immédiatement une application API complète
C. Si des collègues l’exécutent aussi, l’emballer en GPT personnalisé partagé
D. Augmenter la température du modèle pour la cohérence
E. Continuer à recoller mais utiliser un modèle plus gros
**Réponse : A et C.** Le contexte récurrent relève d’un Project (correction la moins chère), et si d’autres l’exécutent aussi, un GPT personnalisé partagé l’emballe pour eux. Une application API (B) sur-dimensionne pour cela. La température (D) aggrave la cohérence. Un modèle plus gros (E) ne corrige ni le recollage ni la variance due au contexte permanent manquant.
A. Deep research pour le rapport sourcé
B. Search pour un seul fait actuel
C. Canvas pour l’affinage itératif du brief
D. Analyse de données pour calculer sur un fichier
E. Un agent de workspace pour répondre à une question
**Réponse : A et C.** Un rapport sourcé et cité appelle deep research, et l’affiner sur plusieurs éditions appelle Canvas. Un seul fait de search (B) sous-livre le rapport. L’analyse de données (D) n’est pas nécessaire sans fichier sur lequel calculer. Un agent à une question (E) ne correspond pas à un livrable multi-éditions.
## À retenir
- L’échelle des capacités va de **prompt → instruction enregistrée → Project → GPT personnalisé → agent de workspace → application API** ; recourir à l’**échelon le plus léger qui répond au besoin**.
- **Project vs GPT personnalisé** dépend de *qui l’exécute* : votre contexte récurrent est un Project ; une tâche que d’autres exécutent eux-mêmes est un GPT personnalisé.
- **GPT personnalisé vs agent de workspace** dépend de *répondre vs exécuter* : un GPT répond tour par tour ; un agent exécute un travail multi-étapes sous supervision.
- Ne quitter ChatGPT pour une **application API** que lorsque le workflow doit être **embarqué, planifié à l’échelle, intégré ou gouverné de façon programmatique**.
- Le second axe est la **capacité en conversation** : search (faits actuels), deep research (synthèse sourcée), analyse de données (calcul sur fichiers), Canvas (itérer sur un doc/code), import de fichiers (vos documents).
- Ne confondez pas **search** (rapide, actuel) avec **deep research** (long, sourcé), ni l’**import de fichiers** (lire) avec l’**analyse de données** (calculer).
- Le sur-dimensionnement avance un coût construire/maintenir/gouverner ; le sous-dimensionnement fait perdre du temps et produit des résultats incohérents — dimensionner au besoin réellement présent.