Pas à cause d'un bug obvieux. Pas à cause d'un test manquant. Ça casse parce que l'agent a progressivement oublié vos contraintes métier entre l'étape 1 et l'étape 12 de sa chaîne de génération. Il a respecté la règle à l'étape 2, l'a contournée à l'étape 7, et l'a complètement ignorée à l'étape 11. Pas par malveillance. Par structure.
C'est ce que j'appelle le Constraint Decay. Et si vous construisez un backend sérieux avec des LLM agents, vous avez besoin de comprendre ce mécanisme avant qu'il vous coûte une nuit blanche (ou pire, un client).
"Mehdi, vous exagérez. On a des tests. On a une CI. Si ça casse, on le voit avant la prod." Sauf que le Constraint Decay ne déclenche pas toujours les tests. C'est là que c'est vicieux.
Votre agent génère du code qui compile. Qui passe les tests unitaires. Qui répond aux assertions fonctionnelles. Mais qui viole une règle métier implicite que vous n'avez pas formalisée dans un test, parce que vous pensiez que c'était évident. Une règle du type "ce endpoint ne doit jamais être appelé sans vérification d'abonnement actif" ou "ce worker ne doit jamais écrire directement en base sans passer par la queue".
L'agent l'a su. Au début. Et puis il a oublié.
GitHub Copilot vous aide ligne par ligne. Vous restez dans la boucle. Vous validez chaque suggestion. Le contexte est local : un fichier, une fonction, une décision à la fois.
Un LLM agent en mode agentic coding, c'est autre chose. Il planifie, exécute, itère, corrige, souvent sur 10 à 30 étapes de génération enchaînées. Il gère sa propre mémoire de travail. Et c'est là que le problème émerge.
Une étude publiée en 2024 sur les benchmarks SWE-bench montre que les meilleurs modèles actuels résolvent environ 40 à 50% des issues GitHub réelles. C'est impressionnant. Mais ça veut dire que sur 50 à 60% des cas, quelque chose drift : une contrainte ignorée, un edge case oublié, une règle de cohérence cassée en cours de route.
Le problème n'est pas la capacité du modèle. C'est son architecture de mémoire. Un LLM n'a pas de mémoire persistante entre les étapes. Il a un contexte. Et ce contexte, il se dilue.
Voilà le mécanisme, sans bullshit :
Quand vous lancez un agent sur une tâche complexe, vous lui passez un contexte initial (vos règles, votre architecture, vos contraintes métier). À l'étape 1, il les a toutes en tête. Il génère du code cohérent. Mais à chaque étape, le contexte grossit : le code généré précédemment, les résultats d'exécution, les erreurs corrigées, les nouveaux fichiers créés.
Ce que vous avez écrit au début du contexte (vos contraintes) se retrouve noyé par tout ce qui s'est accumulé après. Les LLM font du recency bias : ils pondèrent davantage ce qui est proche de la fin du contexte. Vos règles métier définies à l'étape 0 ont mécaniquement moins de poids à l'étape 15.
C'est documenté. C'est reproductible. C'est pas un bug qu'Anthropic ou OpenAI va fixer dans la prochaine version. C'est une propriété fondamentale de l'architecture transformer.
Le frontend, vous pouvez improviser. Une UI quirky, ça se corrige en prod avec un patch. L'utilisateur lève un ticket, vous fixez en 2h.
Le backend, non. Voilà ce qui se passe quand un agent oublie une contrainte sur le backend :
Et le pire : dans les cas de Constraint Decay, le code a l'air correct à la lecture. L'agent a généré quelque chose de plausible. La review humaine passe si vous n'êtes pas en mode paranoïa active.
Couche 1 : Constraint Manifest explicite. Arrêtez d'injecter vos règles dans le prompt principal en espérant qu'elles restent actives. Créez un fichier dédié (CONSTRAINTS.md ou agent_rules.json) et réinjectez-le à chaque étape de génération, pas seulement au début.
Concrètement : si votre agent tourne sur n8n ou LangGraph, chaque node qui appelle le LLM doit inclure le Constraint Manifest dans son système prompt. Pas optionnel. Pas conditionnel. Systématique.
Couche 2 : Checkpoint de cohérence intermédiaire. Toutes les 3 à 5 étapes de génération, insérez un appel LLM dédié dont l'unique mission est de vérifier la cohérence des contraintes sur le code produit jusqu'ici. Ce n'est pas un test fonctionnel. C'est un audit de contraintes.
Votre prompt de checkpoint ressemble à ça : "Voici les contraintes métier [CONSTRAINTS]. Voici le code généré jusqu'ici [CODE_DIFF]. Identifie toute violation potentielle, même partielle, même implicite. Format JSON avec severity et justification."
Si le checkpoint détecte une violation avec severity HIGH → stop + alerte. On ne continue pas sur une fondation cassée.
Couche 3 : Anti-Drift Gate sur les règles critiques. Identifiez vos 5 à 10 contraintes les plus critiques, celles dont la violation crée un incident prod ou une faille sécu. Pour chacune, écrivez un test déterministe automatique qui s'exécute après chaque génération significative. Pas un test unitaire classique. Un test de contrainte.
Exemple : si votre contrainte est "aucun accès direct à la table users hors du module auth", votre Anti-Drift Gate scanne le code généré pour tout SELECT ou UPDATE sur users en dehors du chemin autorisé. En 2 secondes, avant même que l'agent passe à l'étape suivante.
Couche 4 : Human-in-the-Loop sur les étapes de risque. L'agentic coding ne signifie pas "l'humain sort de la boucle". Il signifie "l'humain est dans la boucle aux bons endroits". Mappez les étapes à risque dans votre chaîne : génération du schéma de base de données, modification des middlewares d'auth, création de nouveaux endpoints publics, refactoring de la couche transactionnelle. Sur ces étapes spécifiques, l'agent soumet pour approbation avant de continuer.
Vous mettez en place un beau système. Votre Constraint Manifest est propre. Vos checkpoints tournent. Et puis vous commencez à les bypasser parce que "l'agent est plutôt fiable sur ce type de tâche" et que "ça ralentit le flow". C'est exactement ce moment où le Constraint Decay frappe.
Le Decay est contextuel et non-linéaire. L'agent peut respecter vos contraintes sur 50 runs consécutifs, puis les violer sur le 51ème parce que ce run-là a un contexte légèrement différent (un fichier de plus, une instruction ambiguë, une erreur de compilation qui a forcé une reformulation). Vous ne pouvez pas prédire lequel.
La solution n'est pas de faire confiance à la régularité passée. C'est de traiter chaque run comme potentiellement le premier. Le système doit être structurellement robuste, pas statistiquement rassurant.
J'ai vu des fondateurs tech avec des stacks sérieuses tomber dans ce piège. Pas les juniors. Les seniors. Parce que leur expérience passée avec les LLM leur donnait une fausse confiance dans la stabilité du comportement.
Si vous utilisez Cursor, Copilot Workspace, Devin, ou un agent custom sur LangGraph / n8n, voilà les 3 ajustements immédiats :
Le "vibe coding" (balancer une spec vague à un agent et shipper ce qu'il sort) est une stratégie viable pour des prototypes et des POC. C'est pas une stratégie viable pour du backend en production avec de vrais utilisateurs et de vraies données.
Le coût d'un incident prod causé par un Constraint Decay n'est pas juste technique. C'est la confiance de votre équipe dans l'AI-assisted development. C'est le temps passé à auditer tout ce que l'agent a généré depuis 3 mois. C'est la conversation difficile avec votre client dont les données ont été mal traitées.
Ce que j'observe en 2024-2025 : les équipes qui utilisent les LLM agents de façon fiable ne sont pas celles qui font le plus confiance aux agents. Ce sont celles qui ont conçu leurs systèmes de contraintes les plus robustes. La confiance est dans le système, pas dans le modèle.
La LLM fiabilité prod n'est pas une propriété du modèle. C'est une propriété de votre architecture d'utilisation du modèle.
Le vibe coding en démo, c'est fun. En prod, c'est une dette technique qui vous attend au tournant.
L'audit gratuit, c'est 45 minutes. On regarde où vos agents sont exposés au Constraint Decay, et ce qui est prioritaire à corriger.
Réserver mon audit gratuit →3x en vitesse, 10x en dette technique. Le vrai coût caché du vibe coding.
Pourquoi votre CFO va vous détester si vous construisez sur Computer Use sans calculer.
Le signal d'alarme que tout founder B2B IA en secteur réglementé doit lire.