Ce qu'est exactement un GPT personnalisé (et pourquoi ce n'est pas un agent)
Un GPT personnalisé, c'est ChatGPT avec une zone de texte devant. Cette zone contient des instructions — comment il doit se comporter, quel ton adopter, ce qu'il ne doit pas faire — et à côté on peut accrocher jusqu'à 20 fichiers de connaissance de 512 Mo chacun, activer des capacités comme la recherche web, et brancher des apps ou des actions vers des API externes. C'est tout. Beaucoup plus que ça n'en a l'air, et beaucoup moins que ce qu'on te vend.
La différence avec un agent n'est pas une question de puissance, mais d'architecture. Un agent décide quel outil utiliser, se souvient entre les interactions et mesure son propre travail. Un GPT personnalisé fait le premier point à moitié et aucun des deux autres. La comparaison honnête n'est donc pas « GPT contre agent » mais « très bon formulaire contre système ». Un formulaire avec une mémoire de poisson rouge : il te sert impeccablement et demain il ne sait plus qui tu es.
Un détail a changé et il vaut mieux le savoir avant d'ouvrir l'éditeur : la création de nouveaux GPT n'est plus disponible sur les comptes ChatGPT personnels — ni Free, ni Go, ni Plus, ni Pro. Créer et publier dépend désormais d'un espace de travail Business, Enterprise ou Edu et de ses permissions. Les GPT déjà existants continuent de fonctionner. Si ton plan « je monte l'agent samedi après-midi » passait par ton compte Plus, commence par là.
Ce qu'il résout vraiment, et il le résout bien
Commencer par un GPT personnalisé n'est pas naïf : c'est le diagnostic le moins cher qui existe. En un après-midi on découvre si le problème était de connaissance (les gens ne trouvent pas l'info) ou de processus (l'info est là, personne n'exécute). Deux problèmes différents, et un seul se règle avec un agent.
- Un jugement répété, écrit une fois. Comment on rédige une proposition, ce qu'on demande en découverte, quel ton on prend avec un client remonté. Dix personnes appliquant la même règle sans que personne ne la connaisse par cœur.
- Consultation de documentation stable. Manuel produit, politique de frais, conditions contractuelles. Si le document change deux fois par an, le GPT est le bon outil et rien d'autre n'est nécessaire.
- Premier jet de travail répétitif. Brouillons, résumés, classement simple. Un humain relit et publie. C'est là que le GPT fait gagner de vraies heures, et dès le premier jour.
- Actions simples en lecture seule. Vérifier une disponibilité, retrouver une commande, récupérer une donnée dans un de tes systèmes. Lecture, pas écriture : risque minimal, valeur élevée.
C'est le plafond utile. Le franchir coûte de l'argent, et la bonne nouvelle c'est que le GPT te prévient : quand il casse, il casse toujours contre l'un de ces quatre murs. Reconnaître le tien, c'est la moitié du travail. L'autre frontière — le plafond du no-code quand ce que tu veux automatiser est un flux entre outils et pas une conversation — est traitée dans automatiser avec l'IA sans coder.
Mur 1 : il ne retient rien d'une conversation à l'autre
La documentation d'OpenAI ne laisse aucune place à l'interprétation : les GPT n'utilisent ni la mémoire enregistrée, ni les instructions personnalisées, ni les conversations précédentes. Chaque conversation repart de zéro. La seule chose qui persiste, c'est ce que tu as écrit dans les instructions et les fichiers — identique pour tout le monde, tous les jours.
Ça a l'air d'un détail technique et c'est le mur qui tue le plus de projets, parce qu'il se voit tard. Le GPT de support marche à merveille en démo et trois semaines plus tard quelqu'un demande pourquoi on lui réclame encore le numéro de commande donné mardi. Ce n'est pas un bug : c'est le design. Un GPT n'a pas d'état ; il a des instructions.
Mur 2 : il n'écrit pas dans tes systèmes avec sa propre identité
Les Actions connectent bien un GPT à tes API, avec trois modes d'authentification : aucune, clé d'API ou OAuth. La différence entre eux, c'est exactement la différence entre une démo et un système. Avec une clé d'API, le GPT entre dans ton système avec une seule identité pour tout le monde : ton journal d'audit ne dira pas « María a changé le statut de la commande », il dira « le GPT l'a fait ». Avec OAuth, chaque personne se connecte avec son compte et tu récupères la traçabilité — en échange d'un vrai flux d'autorisation à monter, avec ses jetons, ses scopes et sa maintenance.
| Mode d'auth | Qui est l'agent pour ton système | À quoi ça sert vraiment |
|---|---|---|
| Aucune | Un anonyme venu d'internet | Données publiques. Rien de plus. |
| Clé d'API | Un seul utilisateur technique, le même pour tous | Lecture et démos. Écriture seulement si peu importe qui a fait quoi. |
| OAuth (code d'autorisation) | Chaque personne avec son compte et ses permissions | Écriture réelle et traçable. Demande du travail d'intégration. |
Deux contraintes de plus déroutent beaucoup de monde. Un GPT peut utiliser des apps ou des actions, mais pas les deux en même temps. Et dans les espaces de travail gérés, l'admin peut limiter les actions à une liste de domaines autorisés : pas de domaine dans la liste, pas d'actions. Autrement dit, la partie qui transforme ton GPT en quelque chose qui exécute dépend d'une permission que tu ne contrôles probablement pas. Quand tu voudras de la vraie écriture — créer le contact, faire avancer l'opportunité, déclencher la séquence — la conversation ne portera plus sur les prompts : elle portera sur connecter l'IA à ton CRM et sur l'intégrer à tes systèmes.
Mur 3 : personne ne mesure s'il a raison
C'est le mur silencieux. Celui qui construit un GPT ne peut pas voir les conversations individuelles que les utilisateurs ont avec lui : la documentation d'OpenAI le dit, et c'est une décision de confidentialité raisonnable. La conséquence opérationnelle l'est moins. Elle signifie que tu ne peux pas faire la seule chose qui améliore un système : regarder les cas où il s'est planté.
En Enterprise et Edu, tu as l'analytique de l'espace de travail avec une section GPT et les conversations disponibles dans la plateforme de conformité. Ça te donne l'adoption et des traces de conformité — combien de gens l'utilisent, à quelle fréquence. Ça ne te donne pas la justesse. Deux chiffres qu'on confond en permanence et qui pointent dans des directions opposées : un GPT qui répond mal génère plus de conversations, pas moins.
- Adoption — combien de gens l'ouvrent. C'est ce que tu verras. Ça monte rien qu'avec la nouveauté.
- Justesse — quel pourcentage de réponses est correct et actionnable. C'est ce qui compte. Tu ne le verras pas.
- Coût de l'erreur — ce qui se passe quand il se trompe. C'est ce qui décide si le GPT peut toucher à quelque chose de réel. Tu ne le verras pas non plus.
La sortie n'est pas d'abandonner : c'est de monter la boucle hors de ChatGPT — un jeu de vraies questions avec les réponses attendues, que tu passes à la main chaque fois que tu touches aux instructions. C'est artisanal, c'est inconfortable et ça marche. Comment se construit ce jeu de tests, c'est dans comment entraîner un agent IA. Et le jour où cette boucle te fait assez mal pour vouloir l'automatiser, tu ne construis plus un GPT : tu construis un agent.
Mur 4 : il n'a pas de propriétaire dans l'organigramme
Ici il faut être précis, parce que la version paresseuse de ce mur n'est plus vraie. Dans un espace de travail géré, si le propriétaire d'un GPT est désactivé ou retiré, la propriété passe à un propriétaire de l'espace et le GPT est marqué comme non attribué pour que quelqu'un le revoie ou le réattribue. Le compte n'est pas perdu. Le problème est ailleurs.
Ce qui se perd, c'est le jugement. Les instructions d'un GPT sont un texte brut dans un formulaire : pas d'historique de versions, pas de relecture, pas un commentaire pour expliquer pourquoi en mars on a ajouté cette phrase bizarre sur les remises. Quand la personne qui l'a écrit s'en va, le texte survit et le pourquoi non. Six mois plus tard, le GPT répond encore avec une politique qui ne s'applique plus, et personne ne le sait parce que — voir mur 3 — personne ne lit les conversations.
Les deux questions qui te disent contre quel mur tu es
Pas besoin d'un diagnostic de deux semaines. Deux questions situent ton cas :
- La deuxième conversation a-t-elle besoin de savoir ce qui s'est passé à la première ? Si oui → mur 1, mémoire. Aucun GPT ne te sert, avec ou sans instructions.
- Le résultat doit-il être écrit dans un de tes systèmes, avec la trace de qui l'a écrit ? Si oui → mur 2, identité. Il te faut OAuth et de la validation en écriture, ou il te faut autre chose.
Si les deux réponses sont « non », reste où tu es : le GPT est le bon outil et dépenser plus, c'est jeter de l'argent. Si l'une est « oui », ton problème est d'architecture et de meilleures instructions n'y changeront rien. Et attention au piège habituel : les murs 3 et 4 n'apparaissent pas dans ce test parce qu'ils ne sont jamais la raison pour laquelle on décide de sauter le pas — ils sont la raison pour laquelle le GPT meurt en silence six mois après avoir été validé.
| Si ton cas est… | Un GPT personnalisé | Ce qu'il faut vraiment |
|---|---|---|
| Consulter de la documentation stable | Suffisant | Rien de plus |
| Appliquer un jugement répété à des brouillons | Suffisant | Relecture humaine |
| Suivre un client sur plusieurs jours | Insuffisant | Mémoire persistante |
| Écrire dans le CRM ou l'ERP avec audit | Insuffisant | OAuth, validation et logs |
| Répondre sur ton site ou dans ton produit | Impossible | L'API, pas un GPT |
Ce qu'on construit quand le GPT ne suffit plus
Réponse courte : la même chose, plus les quatre pièces que le GPT n'a pas. Mémoire persistante pour que le système sache ce qui s'est passé avant. Identité par utilisateur pour qu'il écrive avec un nom. Evals pour que quelqu'un sache s'il a raison. Et un propriétaire humain avec un nom dans l'organigramme, pour que le jour où la politique change, les instructions changent.
Ce n'est ni un acte de foi ni une refonte depuis zéro : le travail fait dans le GPT — les instructions affinées, les documents qui ont marché, les vraies questions que les gens lui ont posées — c'est exactement la matière première. C'est ce qui fait que commencer par un GPT reste une bonne idée même en sachant qu'il sera vite trop court : tu ne construis pas un prototype jetable, tu écris la spécification.
Si la destination est un assistant sur ton site ou dans ton produit, le chemin passe par construire un chatbot RAG sur ta base de connaissance. Si c'est du travail interne avec des processus et des systèmes au milieu, par les agents IA pour les entreprises. Et si ce que tu cherchais n'était pas de construire mais de tirer parti de ChatGPT tel quel dans l'équipe, c'est une autre conversation et elle est ici : utiliser ChatGPT dans une vraie entreprise.
Nous, on fait la partie ennuyeuse : on monte des employés IA qui se souviennent, qui écrivent dans tes systèmes avec leur propre identité et qui ont quelqu'un pour vérifier s'ils ont raison. On ne vend pas le prompt. On facture le système qui tourne.
Et si tu arrives ici en concluant que le GPT est trop juste, la décision suivante n'est pas quel outil utiliser mais dans quelle couche vivre : c'est dans plateformes pour créer des agents IA, avec les trois questions de sortie à régler avant de signer quoi que ce soit.