Tout le monde vend du "agentic coding" comme si c'était de la magie. Tu donnes un objectif à ton agent IA, tu attends 30 secondes, et hop, une feature prête en prod. La démo est bluffante. Le pitch deck est propre. Et puis tu déploies. Et ça casse.
Pas à cause d'un bug obvieux. Pas à cause d'un test manquant. Ça casse parce que l'agent a progressivement oublié tes 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 tu construis un backend sérieux avec des LLM agents, tu as besoin de comprendre ce mécanisme avant qu'il te coûte une nuit blanche (ou pire, un client).
"Mehdi, tu exagères. 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.
Ton 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 tu n'as pas formalisée dans un test, parce que tu pensais 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 t'aide ligne par ligne. Tu restes dans la boucle. Tu valides 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 tu lances un agent sur une tâche complexe, tu lui passes un contexte initial (tes règles, ton architecture, tes 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 tu as écrit au début du contexte (tes 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. Tes 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, tu peux improviser. Une UI quirky, ça se corrige en prod avec un patch. L'utilisateur lève un ticket, tu fixes 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 tu n'es pas en mode paranoïa active.
Couche 1 : Constraint Manifest explicite. Arrête d'injecter tes règles dans le prompt principal en espérant qu'elles restent actives. Crée un fichier dédié (CONSTRAINTS.md ou agent_rules.json) et réinjecte-le à chaque étape de génération, pas seulement au début.
Concrètement : si ton 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ère 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.
Ton 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. Identifie tes 5 à 10 contraintes les plus critiques, celles dont la violation crée un incident prod ou une faille sécu. Pour chacune, écris 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 ta contrainte est "aucun accès direct à la table users hors du module auth", ton 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". Mappe les étapes à risque dans ta 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.
Tu mets en place un beau système. Ton Constraint Manifest est propre. Tes checkpoints tournent. Et puis tu commences à 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 tes 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). Tu ne peux 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 tu utilises 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 ton é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 ton 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 ton architecture d'utilisation du modèle.
Le vibe coding en démo, c'est fun. En prod, c'est une dette technique qui t'attend au tournant.
L'audit gratuit, c'est 45 minutes. On regarde où tes 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 ton CFO va te détester si tu construis sur Computer Use sans calculer.
Le signal d'alarme que tout founder B2B IA en secteur réglementé doit lire.