La majorité des Custom GPTs publics dans le GPT Store sont médiocres. Ce n'est pas une question d'outil — l'outil est puissant. C'est une question de structure. Un assistant qui marche est construit ; un assistant qui rate est improvisé.
Si tu as fini l'article 1.2 sur ton premier Custom GPT en 30 minutes, tu as un assistant qui fonctionne. Bien. Mais peut-être que tu sens qu'il dérape sur certains cas, qu'il oublie une règle de temps en temps, qu'il invente parfois. Ces dérapages ne viennent pas du modèle — ils viennent de la structure de tes Instructions.
Cet article décompose la structure d'un assistant qui marche dans la durée. 5 couches obligatoires, dans cet ordre : (1) Rôle, (2) Process, (3) Format de sortie, (4) Contraintes, (5) Edge cases. Saute une couche, et l'assistant aura un trou correspondant. L'ordre compte aussi — le modèle interprète les instructions séquentiellement et donne plus de poids au début. Cette structure marche pour Custom GPTs, Claude Projects, Gemini Gems, et tout système qui accepte un prompt système — d'où sa valeur durable.
Tu vas aussi voir les 5 erreurs structurelles qui tuent 80 % des assistants en 2026 — et comment les corriger sans tout reconstruire.
— 1 / 4Pourquoi 80 % des assistants ratent.
Avant de voir ce qui marche, comprendre ce qui rate. Les assistants qui finissent abandonnés en 3-6 semaines partagent presque tous un défaut structurel commun : Instructions improvisées au fil de l'eau, sans architecture pensée en amont.
Le scénario typique : tu construis un assistant en mode conversationnel avec le Builder. Le Builder te pose des questions, tu réponds en improvisant, il rédige des Instructions à ta place. Tu testes 2-3 cas faciles, ça marche, tu déploies. Puis :
Semaine 1. Un cas atypique fait dérailler — l'assistant invente une donnée. Tu ajoutes une règle dans les Instructions : « Ne jamais inventer de chiffre ». Ça règle ce cas.
Semaine 2. Un autre cas fait dérailler — l'assistant répond hors-sujet. Tu ajoutes une autre règle. Ça règle ce cas aussi.
Semaine 4. Tes Instructions font maintenant 800 mots, sont devenues une liste hétéroclite de règles ajoutées au fur et à mesure. Le modèle commence à oublier les règles du milieu (effet « lost in the middle » documenté). De nouveaux cas dérapent. Tu rajoutes des règles. Spirale négative.
Semaine 6-8. Tu abandonnes l'assistant. Trop d'efforts pour des résultats inégaux. Tu retournes au prompt direct.
L'erreur n'est pas dans les règles — chacune était bonne. L'erreur est structurelle : les Instructions n'ont jamais eu d'architecture, juste un empilement réactif. Un assistant qui marche dans la durée est construit comme un building : fondations en bas, étages au-dessus, finitions en haut. Pas comme un patchwork de règles ajoutées dans le désordre.
L'erreur n'est pas dans les règles. Elle est dans l'absence d'architecture. Un assistant qui marche est construit comme un building : fondations en bas, étages au-dessus, finitions en haut. Pas comme un patchwork.
— 2 / 4Les 5 couches, dans l'ordre.
Voici les 5 couches structurantes. L'ordre est crucial. Le modèle pondère plus fort les premières instructions ; en cas de conflit, c'est ce qui est en haut qui gagne. Donc on commence par le Rôle (la fondation) et on termine par les Edge cases (la couche défensive).
Pourquoi c'est la fondation : le rôle précis active des connaissances et un registre de réponse spécifique dans le modèle. Plus le rôle est nommé précisément, plus la qualité de réponse monte automatiquement, sans même ajouter de règles. C'est le levier le plus économique. Inutile de dire « tu es expert », « tu es professionnel » — ces qualificatifs valent peu. Ce qui compte : un nom métier reconnaissable et une audience cible définie.
Pourquoi c'est crucial : sans process explicite, le modèle improvise un ordre de traitement qui varie d'une fois à l'autre — d'où l'incohérence d'un assistant à l'autre. Avec un process explicite, tu garanties la même séquence à chaque conversation. Règle : utilise des numéros (1, 2, 3) plutôt que des bullets — la séquence est plus claire pour le modèle et il respecte mieux l'ordre. Et utilise « quand X arrive → fais Y » pour les branches conditionnelles.
Si ton assistant alimente un système en aval (Zap, automation, copier-coller dans un autre outil), spécifie un format strict — JSON, table markdown, liste numérotée, etc. Et précise la longueur attendue (« max 200 mots », « 3 puces »). C'est la couche que la majorité des constructeurs oublient — résultat, l'assistant donne des réponses correctes mais inutilisables sans retraitement manuel à chaque fois. Format spécifié = gain de temps réel.
Exemples typiques de contraintes utiles : « Ne jamais inventer un chiffre — si la donnée n'est pas disponible, dis "[à vérifier]". » « Ne jamais signer un email à la place de l'utilisateur — laisse la signature vide. » « Toujours répondre en français. » « Ne jamais faire de promesses commerciales (délais, prix) sans validation explicite de l'utilisateur. » Limite-toi à 3-5 contraintes vraiment importantes. Au-delà, le modèle commence à oublier les règles du milieu et tu perds en cohérence.
Hors périmètre : que doit faire l'assistant si quelqu'un lui demande quelque chose en dehors de son rôle ? Sans cadrage, il répond quand même (en mode ChatGPT générique), ce qui pollue ses réponses futures et donne l'impression d'un assistant « qui sait tout » alors qu'il est calibré sur un cas précis. « Si la demande sort du périmètre [propositions commerciales B2B], réponds : "Je suis spécialisé sur la correction de propositions. Pour [autre besoin], utilise plutôt ChatGPT ou Claude directement." Ne tente pas une réponse générique. »
Incertitude : que doit faire l'assistant s'il manque une info essentielle pour bien répondre ? Sans cadrage, il devine avec confiance — le défaut le plus coûteux d'un assistant mal cadré. « Si tu n'as pas une donnée nécessaire (contexte client, budget, deadline), pose la question avant de répondre. Ne devine pas. Si tu n'es pas sûr d'une recommandation, dis-le explicitement. »
— 3 / 4Le template universel commenté.
Voici le template qui assemble les 5 couches dans le bon ordre. Applicable Custom GPT, Claude Project (champ « Custom Instructions »), Gemini Gem (champ « Instructions »). Les sections en orange sont à adapter à ton cas. Les commentaires en gris (commentaires // gris) ne sont pas dans le prompt — c'est juste pour t'expliquer.
Ce template fait environ 250 mots une fois adapté. C'est le bon ordre de grandeur. En dessous de 150 mots, tu n'as pas assez de précision et tu rates des règles. Au-dessus de 500 mots, tu rentres dans la zone de « lost in the middle » où le modèle commence à oublier les règles du milieu. La sweet spot 2026 est 200-400 mots structurés en 5 sections claires.
Si tu travailles avec Claude (Claude Projects, API), tu peux remplacer les ## Section markdown par des balises XML : <role>, <process>, <format>, <constraints>, <edge_cases>. Claude est entraîné spécifiquement pour bien parser ces balises. Pour Custom GPTs (OpenAI) et Gemini Gems, le markdown ## fonctionne mieux. Cette différence est documentée dans les guides Anthropic et OpenAI 2026 — pas un détail esthétique, ça change réellement la qualité de suivi des instructions.
— 4 / 4Les 5 tests qui valident l'anatomie.
Une fois ton assistant construit avec les 5 couches, valide chaque couche avec un test ciblé. Chaque test isole une couche — si un test échoue, tu sais quelle couche corriger. Beaucoup plus efficient que des tests vagues qui ne te disent pas quoi changer.
Si les 5 tests passent, ton assistant a une anatomie saine. Il va tenir dans le temps. Si un test échoue, tu sais exactement quelle couche corriger — pas besoin de réécrire tout. C'est l'avantage de la structure : le débogage devient ciblé.
— BonusLes 5 erreurs structurelles qui ratent l'anatomie.
L'écart de qualité entre deux assistants construits par deux personnes différentes sur la même plateforme avec le même cas d'usage vient à 80 % de la structure des Instructions, et à 20 % seulement des knowledge files et des capabilities. Cet écart se voit immédiatement à l'usage : un assistant « qui marche vraiment » est cohérent, prévisible, refuse proprement le hors-sujet, ne devine pas dans le doute. Un assistant « construit en improvisant » dérape de manière imprévue 1 fois sur 5 et finit oublié. La discipline anatomique des 5 couches est ce qui distingue les deux. Ce n'est pas du sur-engineering — c'est le minimum pour qu'un assistant tienne dans la durée. Si tu n'as appliqué qu'une seule chose de cet article, applique l'ordre : Rôle, Process, Format, Contraintes, Edge cases. Tu vas voir la différence dès le prochain assistant que tu construis.
Tu maîtrises maintenant l'anatomie d'un assistant qui marche. Pour aller plus loin : les couches Knowledge et Capabilities sont approfondies dans l'article 1.4 (Knowledge Files) et 1.5 (Actions et APIs). Pour tester et maintenir un assistant dans la durée : article 1.6 (tester, débugger, maintenir). Pour partager proprement avec une équipe : article 1.7 (partager et sécuriser). Pour le choix de plateforme : article 1.1 (comparatif Custom GPTs / Projects / Gems). Pour ton premier assistant pas-à-pas : article 1.2 (premier Custom GPT en 30 min). Pour les bases du prompt direct (sans assistant construit) : retour aux articles du Niveau II sur l'anatomie d'un prompt.
5 points sur l'anatomie d'un assistant.
- 80 % des assistants ratent par défaut structurel, pas par manque d'outil. Instructions improvisées au fil de l'eau, empilement réactif de règles, plus d'architecture après 800 mots — abandon en 6 semaines. La structure prévient ça dès le départ.
- 5 couches obligatoires dans cet ordre : (1) Rôle (qui est l'assistant + qui il aide, précis pas générique), (2) Process (séquence numérotée step-by-step de ce qu'il fait), (3) Format de sortie (la couche la plus souvent oubliée), (4) Contraintes (3-5 max, en positif quand possible), (5) Edge cases (hors-sujet + gestion incertitude). L'ordre compte — le modèle pondère plus fort le début.
- Sweet spot 2026 : 200-400 mots structurés en 5 sections claires. Sous 150 mots = trop flou. Au-dessus de 500 mots = effet « lost in the middle » où le modèle oublie les règles du milieu. Pour Claude, balises XML <role><process> etc. ; pour Custom GPTs et Gemini, markdown ##.
- 5 tests ciblés validés couche par couche : (1) qui es-tu ? révèle Rôle, (2) cas nominal révèle Process, (3) sortie révèle Format, (4) cas piégé révèle Contraintes, (5) hors-sujet révèle Edge cases. Si un test échoue, tu sais quelle couche corriger — débuggage ciblé, pas réécriture totale.
- 5 erreurs structurelles à éviter : commencer par les contraintes au lieu du rôle, process en bullets au lieu de numérotation, oublier la couche Format, contraintes en négatif partout, oublier les Edge cases jusqu'à ce qu'un cas dérape en prod. La discipline anatomique = 80 % de l'écart de qualité entre deux assistants. Pas du sur-engineering — le minimum pour qu'un assistant tienne dans la durée.