Projet final : un workflow ChatGPT réel de bout en bout

Construisons un système réaliste de bout en bout : un assistant de support client pour une petite entreprise SaaS, qui répond depuis une base de connaissances, récupère les données de commande et de compte en direct, escalade les tickets difficiles vers un humain, et envoie chaque lundi un rapport de santé hebdomadaire au fondateur. Vous connaissez déjà les briques prises séparément. Cette leçon porte sur leur assemblage et, surtout, sur **le choix de *quelle* brique utiliser à quel endroit**.

Le scénario et les contraintes

« SupportBot » doit faire quatre choses :

1. Répondre aux questions produit à partir de la documentation interne.
2. Consulter l'abonnement en cours et les tickets récents d'un client.
3. Passer la main à un humain quand la confiance est faible ou que le client est en colère.
4. Produire un rapport hebdomadaire sur le volume de tickets, le temps de résolution et les principaux sujets.

Trois contraintes déterminent chaque décision : l'équipe compte deux personnes, la documentation change chaque semaine, et les données clients vivent dans une base Postgres et dans Zendesk. Gardez-les en tête, car elles nous poussent vers des surfaces différentes selon les tâches.

Décision 1 : custom GPT ou APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → ?

C'est le point de bifurcation central de l'architecture, donc tranchez-le d'abord.

Un Custom GPT (configuré sur chatgpt.com, distribué via le GPT Store ou un lien privé) est le bon support pour l'assistant *à usage interne*. Vos deux agents de support l'ouvrent dans ChatGPT, collent un email client et obtiennent un brouillon de réponse ancré dans votre documentation. Zéro hébergement, zéro code d'authentification, et il hérite nativement des Connectors et des Actions.

L'API (la Responses API) est le bon support pour tout ce qui est *face client* ou *automatisé* : le widget sur votre site web, le job de rapport nocturne. Vous avez besoin de contrôle programmatique, de votre propre authentification, de logging, et de la capacité à tourner sans humain dans la boucle.

La réponse est donc les deux, répartis par audience :

• Outil de rédaction destiné aux agents → Custom GPT.
• Widget du site web + rapport planifié → API.

N'essayez pas de forcer une seule surface à tout faire. Le Custom GPT est votre voie rapide ; l'API est votre voie durable.

Décision 2 : comment la documentation entre dans la réponse

La documentation change chaque semaine, donc la stratégie de grounding compte.

Pour le Custom GPT, utilisez les Connectors pour relier le dossier Google Drive où l'équipe garde la documentation. Le GPT interroge cette source au moment de la requête, donc une modification faite lundi est prise en compte lundi. C'est mieux que d'envoyer des fichiers statiques dans la knowledge du GPT, qui se périmeraient et exigeraient un nouvel envoi. Consultez help.openai.com pour le catalogue de Connectors à jour et les contrôles administrateur.

Pour le widget adossé à l'API, le retrieval vous appartient. Soit vous faites tourner votre propre recherche vectorielle et passez les résultats dans le prompt, soit vous utilisez le file search comme outil hébergé sur la Responses API. Pour une équipe de deux personnes, le file search hébergé est le choix pragmatique : moins d'infrastructure à surveiller. Un job cron hebdomadaire resynchronise la documentation dans le file store.

Décision 3 : données en direct via Actions ou function calling

L'assistant a besoin de getCustomer(email) et getRecentTickets(customerId). Même capacité, deux implémentations selon la surface.

Dans le Custom GPT, vous les exposez sous forme de GPT Actions : une spécification OpenAPI pointant vers votre API interne, avec l'authentification configurée dans le builder du GPT. Le modèle décide quand les appeler.

Dans le widget API, les mêmes opérations deviennent du function calling avec structured outputs, de sorte que les arguments arrivent en JSON conforme au schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → à chaque fois. Voici la définition de l'outil pour la Responses API :

from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "name": "get_customer",
    "description": "Look up a customer's subscription and account status by email.",
    "parameters": {
        "type": "object",
        "properties": {
            "email": {"type": "string", "description": "Customer email address"}
        },
        "required": ["email"],
        "additionalProperties": False
    },
    "strict": True
}]

response = client.responses.create(
    model="gpt-4.1",
    input="What plan is taylor@acme.com on, and is their account in good standing?",
    tools=tools
)

print(response.output)

strict: True est la partie à intégrer : elle garantit que les arguments du modèle sont conformes à votre schéma, ce qui signifie que votre code backend n'a jamais à parser défensivement un champ email mal formé. Lisez le guide function calling pour la boucle complète, y compris la façon de renvoyer le résultat de l'outil pour la réponse finale du modèle.

L'idée clé : les *mêmes opérations OpenAPI* alimentent à la fois vos GPT Actions et vos outils de function calling. Écrivez l'API une fois, exposez-la deux fois.

Décision 4 : l'escalade et la frontière du human-in-the-loop

Ne laissez jamais un bot de support garantir un remboursement ou clore un ticket de lui-même. Construisez un outil d'escalade explicite, escalate_to_human(reason, urgency), et demandez au modèle de l'appeler quand le client est mécontent, réclame de l'argent, ou que la documentation ne couvre pas la question.

Faites de l'escalade un *outil de premier rang*, pas une impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète →. Quand il est appelé, votre code dépose la conversation dans une file Zendesk et indique au client qu'un humain s'en occupe. Cela transforme « le bot s'est trompé » en « le bot connaissait ses limites », ce qui fait la différence entre un assistant utile et un risque.

Décision 5 : où le modèle orchestre et où votre code orchestre

Quand vous avez plusieurs outils et une logique multi-étapes (consulter le client → vérifier les tickets → décider de répondre ou d'escalader), vous avez un choix :

• Laisser le modèle orchestrer via la boucle d'outils de la Responses API. Simple, adapté aux flux linéaires.
• Utiliser l'[Agents SDK](https://platform.openai.com/docs/guides/agents-sdk) quand vous voulez des agents typés, des handoffs entre agents spécialisés (un « agent facturation » face à un « agent technique »), des guardrailsguardrailsRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → et du tracing. Pour le schéma escalade-et-passation de SupportBot, l'Agents SDK justifie son coût car les handoffs sont une primitive intégrée.

Si vous prototypez de façon interactive, le ChatGPT agent (l'agent qui navigue, clique et enchaîne les étapes dans ChatGPT) est très bien pour des investigations ponctuelles (« va trouver tous les tickets ouverts qui mentionnent le nouveau bug de facturation »), mais ce n'est pas là que vous faites tourner du trafic de production. Gardez cette distinction nette : ChatGPT agent pour l'exploration, Agents SDK pour le système déployé.

Décision 6 : le rapport hebdomadaire

C'est là que l'Advanced Data Analysis (Code Interpreter) brille. Le rapport nécessite du vrai calcul : temps de résolution médian, écarts de tickets d'une semaine sur l'autre, un graphique des principales catégories de sujets.

Vous avez deux options propres :

Option A : tâche planifiée dans ChatGPT. ChatGPT prend en charge des scheduled tasks qui exécutent un prompt de façon récurrente. CrCrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éez une tâche dans votre Custom GPT : « Chaque lundi à 8h, récupère les tickets de la semaine passée via le connecteur Zendesk, calcule les statistiques de résolution, et produis une synthèse avec un graphique. » Effort minimal, aucun code à héberger.

Option B : job API sur votre propre cron. Un petit script interroge Postgres, passe les lignes au modèle avec l'outil Code Interpreter pour faire les calculs et générer un graphique, puis envoie le résultat par email. Plus de contrôle, versionné, testable. Choisissez cette option quand le rapport alimente quelque chose en aval ou que le fondateur en a besoin dans un format précis à chaque fois.

Pour une équipe de deux personnes, commencez par l'option A. Passez à l'option B quand le rapport devient porteur.

Assembler les surfaces

Voici le tableau complet, surface par surface :

Notez le fil conducteur : une seule API backend sert les consultations, exposée comme Actions au GPT et comme function tools à l'API. Une seule source de documentation (le dossier Drive) alimente à la fois le Connector et la synchronisation du file search. Vous ne construisez pas quatre systèmes ; vous construisez deux points d'intégration (votre API, votre documentation) et vous y pointez plusieurs surfaces.

Memory, Projects et instructions

Quelques fonctionnalités de ChatGPT améliorent discrètement l'outil destiné aux agents :

• Placez les règles de ton de SupportBot, la politique d'escalade et la règle « toujours citer le document » dans les instructions du Custom GPT, pas dans chaque prompt.
• Regroupez le travail de support de l'équipe dans un Project pour que conversations, fichiers et instructions personnalisées restent cadrés ensemble, séparés de leurs autres usages de ChatGPT.
• Laissez la memory désactivée pour le Custom GPT de support. Vous ne voulez pas qu'il transporte des hypothèses d'un client à un autre sans lien. La memory est excellente pour un assistant personnel, risquée pour un outil de support partagé.

Une note sur Canvas et Codex

Quand vous *rédigez* les modèles de rapport ou le texte des emails, Canvas est une meilleure surface d'édition que le chat : vous itérez sur un document sur place. Et le travail d'implémentation lui-même (le script Responses API, la spécification OpenAPI, le job cron) est exactement ce à quoi sert Codex. Utilisez-le pour construire la boucle de function calling et la requête Postgres, puis relisez chaque ligne avant qu'elle touche des données clients.

Modes de défaillance à anticiper

Avant de livrer, décidez à l'avance ce qui se passe quand les choses cassent :

• L'API de consultation est en panne. Votre fonction doit renvoyer un objet d'erreur clair, et les instructions du modèle doivent dire « si une consultation échoue, escalade plutôt que de deviner ».
• Le modèle invente une politique. Contraignez-le : répondre uniquement à partir des documents récupérés, et si le retrieval ne renvoie rien de pertinent, le dire et escalader.
• Rate limits ou pics de coût. Loggez la consommation de tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → par conversation. Le widget du site web est votre surface non plafonnée, donc limitez la longueur des conversations et ajoutez un repli vers la passation à un humain.

Concevez tout cela sur le papier d'abord. C'est moins coûteux à décider maintenant qu'à déboguer en production.

Points clés

• Répartissez par audience, pas par fonctionnalité. Custom GPT pour votre équipe interne (rapide, sans hébergement) ; Responses API pour les flux face client et automatisés (contrôle, logging, authentification).
• Construisez le backend une fois, exposez-le deux fois. Les mêmes opérations OpenAPI alimentent vos GPT Actions et vos outils de function calling. Même idée pour la documentation : une source alimente à la fois les Connectors et le file search.
• Faites de l'escalade un outil de premier rang avec des structured outputs strict, et demandez au modèle d'escalader en cas d'échec ou de faible confiance plutôt que de deviner.
• Commencez sur la surface la moins coûteuse en effort, passez à l'échelle quand c'est porteur. Utilisez d'abord une scheduled task ChatGPT pour le rapport hebdomadaire ; passez à un job cron API + Code Interpreter seulement quand il alimente quelque chose en aval.
• Tournez-vous vers l'Agents SDK quand vous avez besoin de handoffs, de guardrails et de tracing ; réservez le ChatGPT agent à l'exploration, pas au trafic de production.