Tu as construit un assistant qui marche. Tu le partages. Trois semaines plus tard, tu remarques qu'il dérape sur certains cas. Tu modifies les Instructions. La modif règle ce cas, mais en casse deux autres que tu n'avais pas testés. Tu reviens en arrière — sauf que tu n'as pas la version précédente. Tu reconstruis de mémoire, mal. L'assistant finit oublié au mois 4.
Ce scénario n'est pas une exception : c'est la trajectoire par défaut. La grande majorité des Custom GPTs publiés dans le GPT Store sont morts en 6 semaines, abandonnés par leurs propres créateurs. Pas par manque d'idée — par absence de discipline ops. Tester avant de partager, déboguer ciblé quand un cas dérape, versionner les Instructions hors-plateforme, écouter les bugs réels qui remontent à l'usage : ces 4 disciplines déterminent si ton assistant tient 6 mois ou pas.
Le sujet est quasi inexistant en français. Les contenus existants traitent « comment construire un Custom GPT » mais s'arrêtent au moment où l'assistant fonctionne en preview. La phase d'après — celle qui dure 99 % de la vie de l'assistant — n'est traitée nulle part de manière accessible. Cet article est le manuel ops qui manque.
Tu vas voir : (1) pourquoi 80 % des assistants finissent abandonnés et comment éviter le piège, (2) comment construire ton test set perso en 30 minutes (le levier #1), (3) le débuggage ciblé en 5 catégories de bugs, (4) la routine de maintenance mensuelle qui prévient le drift silencieux. Plus 5 pièges classiques en bonus. Avertissement honnête : si tu as construit ton premier assistant ce matin, garde cet article pour après 2 semaines d'usage réel. Avant ça, tu n'auras pas les vrais cas qui font mal — donc pas la matière pour appliquer la méthode.
— 1 / 4Pourquoi 80 % des assistants finissent abandonnés.
L'écart entre un assistant qui tient 6 mois et un assistant abandonné en 6 semaines ne vient pas du choix de plateforme (Custom GPT vs Claude vs Gemini), ni de la puissance du modèle (GPT-5.5 vs Opus 4.7), ni même de la qualité initiale des Instructions. Il vient de 4 défauts opérationnels qui se cumulent dans le temps.
Défaut 1 — Pas de baseline pour comparer. Tu modifies les Instructions parce qu'un cas dérape. Tu ne sais plus comment l'assistant répondait sur les autres cas avant ta modif. Tu testes 2-3 cas similaires à celui qui dérapait, ça marche, tu valides. Mais tu viens peut-être de casser 5 autres cas que tu n'as pas testés. Tu le découvres 2 semaines plus tard, par un retour utilisateur. Tu remodifies. Spirale négative.
Défaut 2 — Pas d'historique des Instructions. Au bout de 5 modifications successives, tu ne sais plus pourquoi telle règle est dans les Instructions. Tu as oublié quel cas elle réglait. Tu hésites à la supprimer parce qu'elle doit servir à quelque chose, mais tu ne peux plus le vérifier. Les Instructions enflent jusqu'à 800 mots de règles hétéroclites, et l'effet « lost in the middle » commence — le modèle oublie les règles du milieu, les comportements deviennent imprévisibles.
Défaut 3 — Pas d'écoute des cas réels. Tu testes ton assistant sur tes propres cas (que tu connais bien), mais tu ne traces pas les cas que les utilisateurs rencontrent en pratique. Quand quelqu'un te dit « ça n'a pas marché sur ce cas », tu corriges sur le moment puis tu oublies. Trois mois plus tard, le même type de cas reproduit le même bug, parce que tu n'as pas capitalisé l'apprentissage.
Défaut 4 — Pas de routine périodique. Tu construis l'assistant en janvier, tu n'y reviens plus. En juin, ton produit a évolué, tes tarifs ont changé, certaines pratiques sont obsolètes — mais l'assistant continue de répondre selon les vieilles infos en toute confiance. C'est le drift silencieux : la qualité baisse sans signal d'alerte, jusqu'au moment où une réponse fausse arrive sous les yeux d'un client.
Ces 4 défauts ne se traitent pas avec un meilleur outil. Ils se traitent avec une discipline minimale qui prend 30 minutes au démarrage et 30 minutes par mois ensuite. C'est le sujet des 3 sections suivantes.
L'écart entre un assistant qui tient 6 mois et un assistant abandonné en 6 semaines ne vient ni de la plateforme, ni du modèle, ni de la qualité initiale des Instructions. Il vient de la discipline ops après le lancement.
— 2 / 4Le test set perso en 30 minutes.
Le concept est emprunté aux pratiques pro 2026 (Braintrust, Adaline, Promptfoo) mais simplifié pour un usage solo. Un test set est un ensemble de cas représentatifs avec une réponse attendue documentée. Tu le passes à ton assistant à chaque modification importante des Instructions pour vérifier qu'aucun cas qui marchait avant ne dérape après.
Sans test set, modifier les Instructions est de l'aveuglement. Avec test set, c'est du débogage ciblé. La différence se voit dès la 2e modification importante.
Méthode pas-à-pas (30 min, une fois)
• 5-7 cas nominaux que tu maîtrises et qui doivent toujours marcher (les 3-4 demandes les plus fréquentes en production).
• 2-3 cas adversaires qui doivent échouer proprement : hors-sujet, donnée manquante, demande qui contredit les règles.
• 1-2 cas limites : à la frontière du périmètre, cas où l'assistant doit nuancer sa réponse plutôt que refuser ou répondre nettement.
Erreur classique : ne mettre que des cas faciles. Le test set ne sert à rien s'il valide tout le temps. Il faut au moins 2-3 cas qui poussent l'assistant dans ses retranchements.
Exemple concret pour un assistant correcteur d'emails :
Input : « Reformule cet email : Bonjour Mr Dupont, je voulais juste vous redire que j'attends toujours votre validation sur le devis... »
Attendu : ton direct, max 50 mots, signature laissée à remplir, pas de formules creuses type « n'hésitez pas ».
Échec si : phrase au-dessus de 25 mots, signature inventée, formule creuse présente, ton soumis qui démarre par « Je me permets de... ».
Cas particulier : si ton baseline est faible (par exemple 6/12), c'est que ton assistant n'est pas encore prêt pour la production — pas le moment de partager. Travaille les Instructions jusqu'à atteindre 9-10/12 avant publication.
Tu peux automatiser ce passage avec un GPT dédié « Eval » qui prend les sorties de ton assistant et les compare aux critères attendus. C'est l'approche LLM-as-a-judge documentée dans les outils pro 2026 (Braintrust, Adaline). Mais pour un assistant solo, le scoring manuel en 5 minutes par évaluation est largement suffisant.
Le test set perso ne montre sa valeur qu'à la 2e modification d'Instructions. La première fois que tu modifies, tu repasses ton test set et tu vois immédiatement si une régression a été introduite — alors qu'avant, tu l'aurais découverte 2 semaines plus tard via un retour utilisateur. 30 minutes investies une fois te sauvent 2 à 5 heures de débuggage rétrospectif sur la durée de vie de l'assistant. C'est le ratio effort/retour le plus élevé de toute la rubrique.
— 3 / 4Le débuggage ciblé par catégorie.
Quand un cas dérape, la tentation est de « réécrire les Instructions ». Mauvais réflexe. Réécrire casse souvent ce qui marchait. La bonne méthode : identifier la catégorie exacte du bug, corriger ciblé, re-tester avec ton test set. Voici les 5 catégories qui couvrent 95 % des cas, avec leur correction type.
Diagnostic : demande-lui « Qui es-tu et qui aides-tu ? » Si la réponse est vague, le bug est dans la couche Rôle des Instructions (revoir anatomie en 5 couches, article 1.3).
Correction : reprécise le Rôle en haut des Instructions. Pas « assistant qui aide » — un nom métier reconnaissable + audience cible définie. « Tu es un correcteur de propositions commerciales pour des freelances IT francophones. » Cette précision active des connaissances et un registre spécifique dans le modèle.
Diagnostic : regarde si tu as une couche Process explicite avec étapes numérotées (1, 2, 3, 4) — pas des bullets désordonnés. Si tu as juste « fais X, fais Y, fais Z », le modèle improvise un ordre qui varie d'une fois à l'autre.
Correction : récris le Process en numérotation explicite. « 1. Lis l'input en entier. 2. Identifie le ton actuel. 3. Reformule. 4. Termine par une question de relance. » Cette discipline réduit l'imprévisibilité des sorties.
Diagnostic : tu n'as probablement pas de couche Format de sortie explicite. C'est la couche la plus souvent oubliée — l'assistant rend dans son format par défaut (markdown générique, souvent inadapté).
Correction : ajoute une section ## Format de sortie précise. « Réponds en 3 sections H2 séparées : ## Diagnostic / ## Reformulation / ## Justification. La Reformulation doit être prête à copier-coller, max 200 mots, sans préambule explicatif. » Spécifie longueur, structure, et présence/absence de préambule.
Diagnostic : tes contraintes sont peut-être formulées en négatif (« n'invente pas ») — les modèles 2026 (GPT-5.4/5.5, Claude Opus 4.7) suivent moins bien les interdictions que les instructions positives concrètes.
Correction : reformule tes contraintes en positif. « N'invente pas de chiffre » → « Si un chiffre manque, écris [à confirmer]. » « Ne signe pas » → « Termine toujours sans signature, en laissant la place vide pour que l'utilisateur signe à la main. » Plus efficace, plus concret, plus respecté.
Diagnostic : couche Edge cases absente ou trop faible dans les Instructions. C'est la dernière des 5 couches mais c'est elle qui te protège des comportements imprévus.
Correction : ajoute deux clauses explicites en fin d'Instructions. « Si la demande sort du périmètre [X], réponds : "Je suis spécialisé sur X. Pour [autre besoin], utilise ChatGPT générique." Ne tente pas une réponse générique. » Plus : « Si une donnée essentielle manque, pose la question avant de répondre. Ne devine pas. » Ces deux clauses éliminent 80 % des dérapages atypiques.
Pour chaque bug remonté : (1) identifie la catégorie (1 à 5 ci-dessus), (2) applique la correction uniquement sur la couche concernée — pas tout réécrire, (3) repasse ton test set baseline pour vérifier que tu n'as pas introduit de régression, (4) ajoute le cas dérapé à ton test set comme nouveau cas (pour vérifier les futures modifications). Cette boucle est la version solo accessible des CI/CD pour prompts utilisés en pro chez Braintrust ou Adaline. Sans outil tiers, juste avec ton Notion et 5 minutes.
— 4 / 4La routine de maintenance mensuelle.
Un assistant non maintenu se dégrade silencieusement. Pas par bug technique — par drift silencieux. Le contexte évolue (ton produit, tes tarifs, tes pratiques) mais les Instructions et Knowledge Files restent figés. Au bout de 6 mois, l'assistant donne des réponses confiantes mais obsolètes, parfois fausses. La détection se fait au pire moment : un retour client embarrassant.
La parade : 30 minutes par mois, calendrier-fixé. Voici la check-list à dérouler :
Le changelog externe — protection contre la perte d'historique
Comme aucune des 3 plateformes (Custom GPTs, Claude Projects, Gemini Gems) n'a de versionning natif des Instructions, tu dois tenir le changelog hors-plateforme. Sinon, à la 5e modification, tu ne sauras plus pourquoi telle règle a été ajoutée et tu hésiteras à la supprimer.
Format minimal qui marche : un fichier changelog.md dans Notion, Google Drive, ou un repo GitHub privé. Pour chaque modification importante :
Date — Version — Raison — Diff — Score test set
Exemple : « 2026-04-15 — v3 — Cas client A dérapait sur emails longs (cat. 3 Format) — Ajout section ## Format de sortie max 200 mots — Test set 11/12 vs 10/12 v2 ». Cette ligne te permettra dans 3 mois de revenir à la version 2 si v3 introduit un problème non détecté immédiatement.
Approche pro 2026 : les outils comme PromptLayer, LangSmith, Adaline offrent ce versionning avec interface git-like, branchements, pull requests pour prompts. Pour un assistant pro mission-critical avec 5+ assistants à maintenir, c'est rentable. Pour 1-3 assistants perso, le simple Notion suffit largement.
Les 3 signaux de drift à surveiller
Signal 1 — Score test set qui baisse. Tu repasses ton baseline et tu perds 1-2 cas qui passaient avant. Action : investigation immédiate, identifier ce qui a changé (modèle évolué côté plateforme ? Knowledge Files devenus obsolètes ? Instructions modifiées sans test ?).
Signal 2 — Augmentation des retours utilisateurs négatifs. Si tu commences à recevoir 2-3 retours du genre « ça n'a pas marché sur ce cas » dans le mois, c'est un signal. Ne corrige pas individuellement — collecte 5-10 cas avant de modifier les Instructions, identifie la catégorie commune, corrige une fois bien.
Signal 3 — Changement côté plateforme. En 2026 : Custom GPTs en transition vers Workspace Agents, modèles évoluent (GPT-5.5 a remplacé GPT-5.4 en avril 2026, Claude Opus 4.7 récent). Quand le modèle sous-jacent change, le comportement peut subtilement dériver. Repasse ton test set après chaque changement de version connue.
— Bonus5 pièges qui ratent la maintenance.
La maintenance d'assistant IA est le travail invisible qui sépare les amateurs des pros. Tout le monde sait construire un assistant correct la première semaine — la preview du Builder rend ça facile. Très peu savent maintenir un assistant pertinent au mois 6, parce que ça demande une discipline ops que personne ne montre dans les tutoriels. 30 minutes par mois — c'est le coût total. C'est moins qu'un café-réseautage hebdomadaire, mais c'est ce qui transforme un assistant « sympa la première semaine » en outil « fiable pendant 2 ans ». Si tu sautes cette discipline, ne te plains pas quand ton assistant se dégrade ; et si tu l'appliques, tu vas naturellement passer dans les 5 % d'utilisateurs qui exploitent vraiment la valeur des assistants IA construits. C'est la différence structurante en 2026.
Tu sais maintenant tester, déboguer et maintenir. Pour aller plus loin : l'article 1.7 (à venir) sur partager ton assistant avec ton équipe — sujet connexe parce qu'un assistant partagé reçoit des cas atypiques que tu ne testais pas seul. Pour les couches structurantes des Instructions : article 1.3 (anatomie en 5 couches). Pour la cohérence Knowledge Files : article 1.4. Pour les Actions et le débuggage de leur authentification : article 1.5. Pour le tutoriel pas-à-pas si tu démarres : article 1.2 (premier Custom GPT en 30 min). Pour l'écosystème automatisation autour des assistants : la rubrique R4 du Niveau IV où l'article ★ Pilier sur le piège du sur-automatisation traite un sujet connexe (la maintenance qui devient un fardeau quand on multiplie les automatisations).
5 points sur tester, débugger, maintenir.
- 80 % des assistants finissent abandonnés en 6 semaines pour 4 défauts ops cumulatifs : pas de baseline pour comparer, pas d'historique des Instructions, pas d'écoute des cas réels, pas de routine périodique. Aucune des 3 plateformes (Custom GPTs, Claude Projects, Gemini Gems) n'a de versionning natif — c'est à toi de tenir un changelog externe.
- Test set perso en 30 minutes : 8-12 cas (5-7 nominaux + 2-3 adversaires + 1-2 limites) avec input, attendu et critères d'échec documentés. Score baseline aujourd'hui = ton point de référence. Toute modification future doit maintenir le score, sinon tu ne déploies pas. ROI invisible mais énorme : 30 min sauvent 2-5 heures de débuggage rétrospectif sur la durée de vie de l'assistant.
- Débuggage ciblé en 5 catégories : (1) Bug de Rôle = persona générique, corriger Rôle précis. (2) Bug de Process = ordre incohérent, numéroter les étapes. (3) Bug de Format = sorties variables, ajouter section Format de sortie. (4) Bug de Contraintes = inventions / actions interdites, reformuler en positif. (5) Bug d'Edge case = comportements imprévus hors-sujet ou incertitude, ajouter clauses Hors périmètre + Gestion incertitude.
- Routine mensuelle 30 min en 4 étapes : repasser test set baseline, auditer Knowledge Files (drift silencieux), traiter les cas réels remontés (capitalisation), documenter dans le changelog externe. 3 signaux de drift à surveiller : score test set qui baisse, augmentation des retours négatifs, changement côté plateforme (modèle qui évolue).
- 5 pièges à éviter : tester seulement à la construction (jamais après), modifier sans changelog, sur-corriger en empilant des règles défensives (rester sous 400 mots de système prompt, sinon effet « lost in the middle »), ne pas écouter les cas réels qui remontent, négliger le drift des Knowledge Files. La maintenance est 30 minutes par mois — le coût qui transforme un assistant « sympa la première semaine » en outil fiable pendant 2 ans.