D4 · Choosing the Right Capability

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

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.

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.

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.

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.

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.

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.

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é.

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.

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

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

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Décidez avant de dévoiler.

À 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.