App auto-amélioratif : boucle d’amélioration fermée

1. Pourquoi une boucle d’amélioration fermée est indispensable pour l’App

Tout LLM‑App vit dans un environnement changeant. Vous avez de nouveaux utilisateurs et scénarios, OpenAI publie de nouveaux modèles et mécanismes de protection, vous mettez vous‑même à jour le serveur MCP, l’Agents SDK, le widget UI… Et même si tout le code était écrit impeccablement (oui, oui, je sais que vous faites presque ainsi), un seul changement de modèle ou de prompt peut, sans bruit, casser la moitié des cas d’usage.

Sans boucle d’amélioration, la vie ressemble à ceci. Un utilisateur écrit au support : « GiftGenius s’est mis à proposer des cadeaux plus chers que le budget » ou « reste à réfléchir pendant 15 secondes ». Vous ouvrez les logs, corrigez quelque chose dans le system‑prompt, basculez de modèle, et déployez. Une semaine plus tard, tout recommence, mais ailleurs. À la sortie — un incendie chronique et une pile de changements « magiques » que personne ne peut expliquer.

Avec la boucle, tout est différent. Vous avez :

• un ensemble clair de signaux côté technique, finances, produit et qualité ;
• un rituel régulier : les examiner et choisir des hypothèses ;
• des changements contrôlés dans le code/la configuration ;
• des vérifications automatiques : golden cases + LLM‑evals + expériences.

Alors l’App cesse d’être un « prompt figé » et devient un système vivant, qui :

• montre où ça fait mal et pourquoi ;
• suggère ce qui peut être amélioré précisément ;
• protège contre une dégradation silencieuse après un changement « innocent » de prompt.

Bonus : cette boucle s’appuie très bien sur tout ce que vous avez déjà fait dans les modules précédents. Les logs et SLO du M17 donnent les signaux techniques, l’instrumentation cost et AARRR du M19 — les signaux économiques et produit, les golden cases et LLM‑evals du M20.1–2 — les signaux de qualité. Il ne reste qu’à relier tout cela en une boucle opérationnelle claire.

2. Carte des signaux pour les améliorations

Pour que l’App puisse suggérer lui‑même où l’améliorer, il faut comprendre clairement quels signaux vous avez et d’où ils proviennent. Il est pratique de raisonner en quatre groupes.

Les signaux techniques viennent de votre stack d’observabilité : logs tool_invocation, métriques latency et error‑rate, health checks MCP/ACP, échecs OAuth. Ils répondent à la question « le service est‑il vivant et à quel point est‑il stable ».

Les signaux économiques naissent dans l’instrumentation cost et la facturation : cost_per_tool_call, cost_per_task, cost_per_user, pics de coûts inattendus sur des tools ou scénarios spécifiques. Ils disent : « nous brûlons plus de tokens et d’argent que prévu » ou, au contraire, « il y a de la marge, on peut améliorer la qualité ».

Les signaux produit se forment à partir d’événements comme app_opened, workflow_started, workflow_completed, checkout_*. Ce sont le taux d’activation, les conversions entre les étapes de l’entonnoir, la rétention par cohortes. Ils montrent ce qui se passe dans le comportement réel des personnes.

Les signaux de qualité et de comportement incluent les résultats des LLM‑evals sur des golden cases (scores de correctness/helpfulness/style/safety), des revues manuelles échantillonnées de dialogues, des thumbs up/down, des plaintes et avis dans le Store. C’est ce qui est le plus proche du ressenti « l’App est devenue plus intelligente/plus bête ».

Pratique de rassembler cela dans un tableau :

Point clé : tous ces signaux sont loggés avec rattachement au scénario spécifique et à la version de l’App. Autrement dit, les événements incluent au moins scenario, appVersion et experimentId. Ainsi, en voyant que la helpfulness sur les golden cases a chuté de 8.5 à 6.2, vous pouvez dire non pas seulement « c’est pire », mais « c’est pire dans le scénario "gift_selection" après le release "1.3.0", dans la variante d’expérience "B" ».

Dans le code, on peut même introduire une structure simple pour décrire un signal :

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // valeur "avant"
};

De tels objets sont pratiques à alimenter aux dashboards et à votre futur assistant d’amélioration.

3. Boucle de feedback canonique : 4 étapes

Assemblons maintenant une boucle d’amélioration canonique, sur laquelle vous pourrez vous appuyer à chaque fois. Elle est très concrète : quatre étapes.

flowchart TD
  A[Signal : quelque chose cloche
ou il y a une opportunité de croissance] --> B[Hypothèse :
ce que l’on change et comment]
  B --> C[Changement contrôlé
dans code/config]
  C --> D[Vérification :
offline + online]
  D --> A

Étape 1. Détecter un problème ou une opportunité

À cette étape, vous répondez à la question « où regarder ». Exemples :

• Un LLM‑eval sur des golden cases avec budget montre une baisse de helpfulness.
• p95 latency pour le tool "suggest_gifts" est passée de 1.2 s à 3.8 s.
• cost_per_task pour le scénario "gift_selection" a augmenté de 40 % après le passage à un modèle de reasoning.
• La conversion workflow_completed → checkout_success a baissé de 5 points de pourcentage après un changement de l’assistant (wizard) UX.
• En une semaine, 10 plaintes sont apparues dans le Store : « des cadeaux plus chers que la limite indiquée ».

Important : parfois le signal ne dit pas « mauvais », mais « peut être meilleur ». Par exemple, vous voyez que le cost_per_task est sensiblement inférieur au seuil acceptable, alors que le quality‑score est déjà à 9/10. On peut donc tenter un modèle plus cher ou un scénario plus « intelligent » — la conversion pourrait augmenter.

Étape 2. Formuler une hypothèse

Une hypothèse, ce n’est pas « nous allons réécrire le prompt », mais « nous pensons que le changement concret X dans le composant Y améliorera la métrique Z, parce que… ». Sans « parce que », ce n’est pas une hypothèse, mais un souhait.

Exemples :

• « Si nous ajoutons une règle de respect strict du budget dans le system‑prompt et demandons d’expliquer systématiquement comment le budget a été utilisé, la helpfulness sur les cas avec budget augmentera d’au moins 2 points. »
• « Si nous remplaçons le modèle cher par "gpt-mini" à l’étape de rerank, le cost_per_task baissera de 30 %, et la conversion ne chutera pas de plus de 1 point de pourcentage. »
• « Si nous simplifions le wizard (fusion de deux étapes en une) et réécrivons le CTA, le taux d’activation augmentera de 5 points de pourcentage. »

Dans le code, il est pratique de décrire explicitement une telle hypothèse, ne serait‑ce qu’en objet :

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Ce que nous changeons et pourquoi"
  targetMetric: string;  // e.g. "quality.helpfulness" ou "conversion.checkout"
  successCriteria: string;
};

Oui, c’est presque comme un ticket Jira, mais au moins typé.

Étape 3. Effectuer un changement contrôlé

Deux mots sont importants ici : contrôlé et séparé.

Contrôlé signifie que le changement est formalisé en PR/commit, lié à l’hypothèse, possède un changelog et, si possible, un feature flag ou une version. Vous n’avez pas juste « bricolé le prompt en prod », vous pouvez dire quelle release l’a amené.

Séparé signifie que vous évitez de mélanger trois hypothèses différentes dans une seule release. Si vous :

• changez de modèle,
• réécrivez la moitié du system‑prompt,
• et ajoutez une nouvelle étape UX,

alors même si les métriques s’améliorent, il sera difficile de comprendre ce qui a fonctionné. Il est bien plus honnête d’avancer par petites touches.

Techniquement, les changements peuvent être partout :

• le system‑prompt de l’agent (lib/prompt/systemPrompt.ts) ;
• les descriptions des tools (description, inputSchema, annotations) ;
• la config de l’agent (limites des étapes de reasoning, choix du modèle pour un tool donné) ;
• le code du widget (CTA, ordre des étapes, textes d’erreur).

Étape 4. Vérifier si c’est mieux

La vérification se divise en offline et online.

La vérification offline consiste à exécuter les golden cases sur la nouvelle version de l’App sans utilisateurs réels. Vous avez déjà :

• des LLM‑evals (module 20.1) ;
• une logique threshold/baseline (module 20.2).

Vous regardez comment les quality‑scores ont évolué sur les scénarios cibles : en hausse, en baisse, inchangés. Vous vérifiez aussi les cas safety : toute modification de prompt doit d’abord passer la suite safety.

La vérification online est une expérience sur du trafic réel. Dans la version la plus simple, vous activez la nouvelle version pour N % d’utilisateurs et vous comparez :

• la conversion vers l’action cible (checkout, relance du scénario) ;
• cost_per_task ;
• les plaintes/feedback.

Ensuite, la boucle se ferme (l’hypothèse est confirmée/invalidée et documentée) ou engendre une nouvelle hypothèse.

4. L’« assistant d’amélioration » interne comme agent séparé

Voici le plus intéressant : donnons au modèle LLM un rôle supplémentaire — non seulement répondre aux utilisateurs, mais aussi vous aider vous à améliorer l’App. C’est un agent interne, distinct du GiftGenius côté utilisateur.

De quoi s’agit‑il

Cet assistant vit dans votre environnement interne (dans le même repo, en Dev Mode, dans une App ChatGPT séparée). Il :

• lit les logs et des échantillons de dialogues ;
• regarde les métriques ;
• analyse le system‑prompt et les descriptions des tools ;
• aide à formuler des problèmes et des propositions de changements.

En essence, vous obtenez un « product/analyste virtuel » qui :

• ne se fatigue pas à lire des dialogues ;
• trouve rapidement des patterns récurrents ;
• sait rédiger des brouillons de prompts et de changelog.

Quelles entrées il accepte

Il est utile de formaliser l’entrée pour faciliter le travail de l’agent. Par exemple, ce type :

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // depuis la section précédente
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Vous pouvez assembler un tel objet en extrayant des logs 10–20 dialogues ratés pour le scénario "gift_selection" et en joignant le system‑prompt actuel et les descriptions des tools.

Quelle sortie il doit fournir

Il est également pratique de fixer la réponse attendue :

export type ImprovementSuggestion = {
  patterns: string[];     // problèmes récurrents
  promptPatches: string[]; // propositions de fragments pour le system-prompt
  toolsPatches: string[];  // idées pour les descriptions des tools
  uxCopyIdeas: string[];   // variantes de textes UX
  changelog: string[];     // courte liste "quoi changer"
};

Un méta‑prompt pour un tel agent serait à peu près :

• « analyse les exemples et les signaux » ;
• « décris 2–3 patterns de problèmes » ;
• « propose 1–2 changements dans le prompt, les descriptions des tools et les textes UX » ;
• « renvoie tout dans un JSON strictement défini ».

Ensuite vous prenez ces fragments à la main, discutez en équipe, les intégrez dans le code et les faites passer par les evals et les expériences. Principe important : cet assistant ne change rien lui‑même en production. Il génère des idées et du texte, pas des commits.

5. Types de changements : que peut‑on optimiser au juste

Quand on a cet assistant et une boucle claire, il est très facile de tout réduire à « propose‑moi une nouvelle version du system‑prompt ». En réalité, le champ d’amélioration est bien plus large.

Prompt et instructions

Le system‑prompt définit le rôle, le ton, les priorités et les règles strictes (par exemple budget, safety, ordre des étapes). On peut :

• simplifier en supprimant les instructions contradictoires ou redondantes ;
• renforcer en ajoutant des règles manquantes (comme dans l’exemple du budget) ;
• adapter par scénario (sous‑prompts séparés pour "gift_selection", "post_purchase_help", etc.).

Les descriptions des tools aident le modèle à comprendre quand appeler un tool et ce qu’il fait. Les améliorations ici se résument souvent à :

• un « Use this when… / Do not use when… » plus explicite ;
• des formulations plus précises (réduction du recouvrement avec d’autres tools) ;
• l’ajout d’informations sur les conséquences (destructiveHint, isConsequential).

Les règles de safety font partie du prompt/des descriptions et gouvernent le comportement dans des domaines sensibles. Mieux vaut les toucher seulement après de bons safety‑evals.

Architecture du comportement (behavior)

Parfois, on ne résout pas le problème par le prompt : il faut changer l’ordre des actions.

Exemples :

• ajouter une étape obligatoire de clarification de paramètres avant d’appeler un tool coûteux ;
• externaliser une partie des calculs dans une étape séparée, moins chère (par exemple un pré‑filtrage côté backend) ;
• limiter le nombre d’appels de tools consécutifs dans un même scénario.

Ces changements se décrivent généralement dans la config de l’agent ou la couche MCP, pas seulement dans le prompt.

UX et copywriting

Oui, les textes des boutons et des erreurs font aussi partie de la qualité. Un GiftGenius qui écrit :

« Erreur 500. Veuillez contacter l’administrateur »,

n’inspire pas la même confiance que :

« Impossible d’obtenir une réponse du magasin. Vos idées sélectionnées n’ont pas été perdues, essayez de finaliser l’achat un peu plus tard ».

Les écrans intermédiaires, les aides, la structure des assistants (wizards) — tout cela influe sur le taux d’activation et les conversions que vous mesurez.

Économie

On joue ici au jeu bien connu « qualité ↔ coût » :

• choix du modèle (cher avec reasoning, rapide/bon marché) ;
• profondeur du reasoning/des étapes agent (combien d’itérations autorisées) ;
• limites du dialogue (par exemple, pas plus de N recalculs de sélection dans une session) ;
• modes fallback « bon marché » quand le budget en tokens/limites est épuisé.

Les signaux d’ici alimentent cost_per_task, cost_per_user, la marge et se combinent avec le quality‑score.

6. Garde‑fous : ce qu’il ne faut pas confier au LLM

Quand on a un « assistant d’amélioration » et une boucle pratique, on a très envie d’appuyer sur « Auto‑optimisation » et d’aller prendre un café. Mettons‑nous d’accord tout de suite sur les zones où ce bouton est interdit.

Les changements d’autorisations (OAuth scopes, outils MCP, accès aux données) — c’est toujours une zone human‑in‑the‑loop. Aucun modèle ne doit décider seul que l’App peut maintenant lire des commandes, toucher aux paiements ou envoyer des emails aux utilisateurs. Cela vaut aussi pour le flux commerce : tout changement autour d’ACP/Stripe, des limites, des types de paiements et des remboursements passe par une revue humaine et des tests.

Le profil de safety de l’App (dans quels domaines elle a le droit de conseiller, où elle doit refuser) — ce n’est pas non plus quelque chose à déléguer au LLM. Le modèle peut aider à formuler le texte des règles, mais la décision de confiance par thème vous revient.

La politique de données et de logging (ce qu’on logge, combien de temps on conserve, comment on répond aux demandes de suppression) — même liste. Le LLM peut suggérer une structure de Privacy Policy, mais ne doit pas changer la rétention dans le code sans votre participation.

Que peut‑on semi‑automatiser ? Les formulations et le wording des prompts, des descriptions des tools et des textes UX, les priorités des tools (dans des limites raisonnables), des questions de clarification supplémentaires. Tout cela peut être confié à l’assistant comme source d’idées, mais le dernier mot et la vérification reviennent à l’humain et aux scripts d’eval.

7. Exemple end‑to‑end de boucle d’amélioration (GiftGenius)

Revenons à notre héros.

Problème

L’utilisateur indique un budget, mais GiftGenius propose souvent des cadeaux plus chers que cette limite. Les logs montrent beaucoup de suites de dialogue du type « non, c’est trop cher » et « fais moins cher ».

Signaux

D’abord, vous voyez la qualité : un LLM‑eval sur des golden cases du type « trouve un cadeau jusqu’à 50 $ » donne une helpfulness autour de 6/10. Le juge écrit régulièrement dans reason que « les cadeaux dépassent le budget » ou « il n’est pas expliqué comment le budget est pris en compte ».

En parallèle, des signaux produit et économiques arrivent :

• la conversion vers checkout_success pour les scénarios avec limite définie est plus faible que sans limite ;
• une partie des utilisateurs abandonne le scénario après avoir vu des options trop chères ;
• cost_per_task est plus élevé pour ces scénarios, car l’App refait plusieurs sélections de cadeaux à la demande « fais moins cher ».

Analyse avec l’assistant d’amélioration

Vous rassemblez 20 dialogues où les utilisateurs se sont plaints du prix, et vous formez un ImprovementInput :

• scenario = "gift_selection_with_budget" ;
• signals avec baisse de helpfulness et de conversion ;
• examples avec les dialogues ;
• le system‑prompt actuel et les descriptions des tools.

Vous donnez cela à l’agent interne d’amélioration. En réponse, il produit, par exemple :

• Patterns :
  • un budget formulé comme « environ jusqu’à 50 $ » est perçu trop librement ;
  • le system‑prompt ne contient pas l’exigence explicite « ne jamais proposer des cadeaux au‑dessus de la limite » ;
  • les réponses n’expliquent pas à l’utilisateur comment le budget a été pris en compte.
• Propositions :
  • ajouter dans le system‑prompt une instruction de respect strict de la limite ;
  • demander au modèle d’indiquer systématiquement que « toutes les options ≤ X » ;
  • ajouter une question de clarification si le budget est flou (« environ », « à peu près »).

Hypothèse et changement

Vous formulez l’hypothèse :

« Si nous fixons explicitement le respect strict de la limite et demandons d’expliquer l’utilisation du budget, la helpfulness sur les cas avec budget montera au moins à 8/10, et la conversion vers l’achat — de 3 points de pourcentage. »

Vous ajoutez dans le system‑prompt le fragment suivant :

export const budgetRule = `
Si l’utilisateur indique un budget (par exemple, "jusqu'à 50$" ou "environ 30€"),
considère cette somme comme un plafond STRICT.

Ne propose jamais d’options au-dessus de cette limite.
Dans chaque réponse, indique explicitement que toutes les options respectent le budget
et de quelle manière (par exemple : "tous les cadeaux ne dépassent pas 45$").
`.trim();

Et vous ajoutez budgetRule au system‑prompt global de GiftGenius.

Validation offline

Vous exécutez la suite de golden cases « cadeaux avec budget » sur la nouvelle version :

• le score de helpfulness LLM‑eval passe de 6.0 à 8.5 ;
• la correctness augmente aussi : le budget est respecté ;
• la safety ne se dégrade pas (au minimum).

Si au contraire la helpfulness n’augmente pas ou la safety se dégrade, le changement ne passe pas et l’hypothèse est revue.

Test online

Ensuite, vous lancez une expérience :

• 10 % des utilisateurs reçoivent la nouvelle version du prompt (variant B) ;
• les autres 90 % — l’ancienne (variant A).

Au bout d’une semaine, vous regardez :

• la conversion workflow_completed → checkout_success pour B est, disons, 13 % au lieu de 10 % pour A ;
• cost_per_task a quasiment inchangé ;
• la part de dialogues avec des plaintes « trop cher » a diminué.

L’expérience est jugée réussie.

Consolidation

Après cela :

• vous déployez le nouveau prompt sur 100 % du trafic ;
• vous ajoutez un nouveau golden case « budget souple jusqu’à 50 $ » à la suite de régression ;
• vous consignez le résultat dans le changelog et, éventuellement, dans les tech notes : pour qu’on comprenne dans six mois pourquoi il y a une formulation si stricte sur le budget.

La boucle est bouclée. La prochaine itération peut concerner, par exemple, les recommandations pour des passions très rares ou l’optimisation du coût de la sélection.

8. Mini‑feuille de route d’un App auto‑amélioratif

Pour éviter que cela ressemble à « encore 100 500 tâches en plus », il est utile de voir le minimum nécessaire pour que l’App soit déjà considéré comme auto‑amélioratif, et ce qu’on peut ajouter ensuite.

Version 1.0 : boucle d’amélioration minimale

Pour commencer, trois choses suffisent.

Premièrement, des logs structurés et des SLO de base. Vous savez déjà journaliser tool_invocation, workflow_completed, checkout_* avec requestId, userId, scenario, appVersion, costEstimateUsd. Par‑dessus, on construit des SLO : latency, error‑rate, succès du checkout.

Deuxièmement, 10–20 golden cases et un script LLM‑eval. Un petit set bien choisi d’exemples pour les scénarios clés + des cas safety. Un script CLI unique qui les exécute via l’App et le juge et renvoie des scores en JSON.

Troisièmement, un rituel simple toutes les 2 semaines. S’asseoir (seul ou avec l’équipe), ouvrir :

• 2–3 dashboards sur SLO, cost, métriques produit ;
• le rapport LLM‑eval sur les golden cases ;

et choisir 1–2 hypothèses pour la boucle suivante. Formuler, documenter, faire une petite release, vérifier.

Version 2.0 : boucle d’amélioration « intelligente »

Au niveau suivant apparaissent :

Assistant d’amélioration interne. C’est un agent décrit séparément (ou une App ChatGPT) qui prend un ImprovementInput et renvoie un ImprovementSuggestion. Il vous évite des heures de tri manuel de dialogues.

Rapports automatisés. À partir des logs et des evals, on peut générer :

• des clusters de cas problématiques (par exemple, tous les cas où l’utilisateur a réécrit le budget) ;
• des brouillons prêts à l’emploi pour des modifications de prompts et de descriptions des tools ;
• un changelog court.

Hooks CI. Toute modification des prompts, configs d’agents, descriptions d’outils déclenche automatiquement :

• la suite de golden cases fonctionnels ;
• la suite safety.

Si les cas safety échouent ou si la qualité des scénarios clés passe sous les seuils — build en échec, pas de release.

9. Pratique

Exercice 1. Mini‑feedback‑loop pour votre App

Prenez un scénario clé de votre application. Pour GiftGenius, nous avons déjà choisi « sélection et achat de cadeau », vous pouvez prendre un scénario similaire ou le vôtre.

Décrivez librement (ou créez un petit improvement-plan.md) :

Quels signaux vous allez suivre. Un par un :

• technique : par exemple, p95 latency du tool qui fait le gros du travail ;
• économique : cost_per_task pour ce scénario ;
• produit : conversion workflow_started → workflow_completed ou jusqu’à l’action cible ;
• qualité : le quality_score moyen sur plusieurs golden cases pour ce scénario.

Ensuite, fixez clairement quels seuils vous considérez comme une dégradation. Pas « on verra un jour », mais très concrètement :

• p95 > 5 secondes — mauvais ;
• cost_per_task a augmenté de plus de 30 % sans croissance du revenu — alerte ;
• quality_score est tombé sous 7 — il faut enquêter.

Et formulez la première hypothèse. Par exemple :

« Je soupçonne que nous posons trop de questions de clarification. Si nous raccourcissons le wizard d’une étape et rendons les questions un peu plus générales, alors le taux d’activation augmentera et la helpfulness ne souffrira quasiment pas. Je vais le vérifier via un petit changement UX et un A/B test. »

Ce n’est plus « améliorons l’UX », mais une étape concrète dans la boucle.

Exercice 2. Méta‑prompt pour l’assistant d’amélioration

Essayez d’ébaucher le texte du prompt pour l’agent interne d’amélioration de votre App. Commencez simplement :

• Décrire qui il est : « Tu es l’analyste qualité de l’App N, qui… ».
• Énumérer quelles entrées il reçoit : dialogues, signaux, system‑prompt, descriptions.
• Formuler les tâches :
  • trouver 2–3 patterns de problèmes ;
  • proposer 1–2 changements dans le prompt, les tools, les textes UX ;
  • composer un changelog court.
• Décrire le format de réponse : un JSON structuré avec les champs patterns, suggestions, changelog.

Même si vous n’appelez pas encore cet agent depuis le code, un tel prompt vous aidera déjà à mieux structurer vos réflexions sur la manière dont vous améliorez l’App.

10. Erreurs typiques lors de la mise en place de la boucle d’amélioration

Erreur n° 1 : optimiser une seule métrique.
Se focaliser sur une seule chose est très tentant. On peut ne viser que le cost, se réjouir de la baisse de la facture OpenAI — et ne pas remarquer que le quality‑score, les conversions et la rétention chutent. Une boucle d’amélioration doit considérer un paquet de métriques : qualité ↔ argent ↔ comportement utilisateur.

Erreur n° 2 : changements de prompt « magiques » sans mesure.
La phrase « j’ai réécrit le system‑prompt, ça devrait aller mieux » sans golden cases et sans evals — c’est se préparer une surprise dans deux semaines. Tout changement de prompt — surtout en production — doit passer par un pipeline clair : set de cas, LLM‑eval avant/après, si nécessaire — expérience online. Sinon vous n’améliorez pas l’App, vous jetez la qualité au hasard.

Erreur n° 3 : auto‑déploiement des changements de l’assistant LLM.
Même si l’assistant d’amélioration écrit des fragments de prompt magnifiques et des descriptions de tools convaincantes, ce n’est pas une raison pour les pousser en prod sans revue. Le modèle peut ignorer des contraintes business, des risques safety, le contexte de vos métriques. Son rôle est celui de consultant, pas de DevOps avec droit de release.

Erreur n° 4 : absence de lien entre changements, hypothèse et signaux.
Parfois les équipes modifient « au feeling » sans fixer quel signal a mené au changement et quelle hypothèse elles testent. Un mois plus tard, personne ne se souvient pourquoi un étrange paragraphe est apparu dans le prompt et à quoi il servait. Un bon PR « qualité » doit répondre au minimum à trois questions : « qu’est‑ce qui faisait mal ? », « que change‑t‑on ? », « sur quelle métrique saura‑t‑on que c’est mieux ? ».

Erreur n° 5 : oublier la safety lors des améliorations.
À courir après l’utilité, on peut facilement relâcher les contraintes de safety, retirer des « refus » jugés superflus ou oublier d’exécuter la suite safety. Tout changement de system‑prompt, de descriptions de tools et de behavior d’agent doit d’abord passer la suite safety. Si un seul cas qui passait avant échoue maintenant — c’est un stop, même si le reste des métriques est séduisant.

Erreur n° 6 : vouloir « optimiser tout et tout de suite ».
Réécrire la moitié du prompt, changer de modèle, ajouter un nouveau tool MCP et un nouveau wizard — tout dans une seule release — semble productif, mais tue complètement la capacité à comprendre quel changement a eu l’effet. La boucle d’amélioration n’est efficace que si elle est itérative et focalisée : une à deux hypothèses, un petit set de changements, un plan de rollback clair.

Erreur n° 7 : transformer la boucle d’amélioration en rare « journée de grand ménage ».
Si vous organisez tous les six mois une énorme « journée qualité », et le reste du temps vous vivez sans evals ni analyse de métriques, l’App passera la majeure partie du temps à « dériver ». Bien plus utile est un petit rituel, mais régulier : chaque semaine/deux semaines, regarder les signaux, mettre à jour les hypothèses et faire de petits pas. C’est ainsi que votre App ChatGPT cesse d’être statique et se met vraiment à s’auto‑améliorer.