Le mur des trois mois
Vous construisez un SaaS en vibe coding. Le debut est rapide. “Cree un login” — 30 secondes. “Ajoute les paiements” — 2 minutes. Un MVP est livre en trois semaines.
Trois mois plus tard, des choses etranges surviennent. L’IA “nettoie” la logique de paiement et modifie silencieusement les calculs de remise. L’ajout d’un nouvel endpoint casse l’authentification existante. Une demande de refactoring change les noms de champs de l’API publique, tuant tous les clients.
C’est le logic drift — l’IA modifie involontairement la logique metier existante. Les bugs de regression existent aussi dans le developpement traditionnel. Mais le logic drift est different. Des modifications que le developpeur n’a jamais voulues se produisent invisiblement, dans tout le codebase. Chaque prompt demarre dans une fenetre de contexte vierge.
Le drift en chiffres
Ce n’est pas du ressenti. Il y a des donnees.
La vitesse coute en complexite. Une equipe de recherche de Carnegie Mellon a compare 807 depots GitHub avant et apres l’adoption de Cursor (MSR 2026). Les ajouts de code ont augmente de 3 a 5 fois le premier mois. Apres deux mois, l’avantage de vitesse avait disparu. Ce qui restait : les alertes d’analyse statique en hausse de 30%, la complexite du code en hausse de 41% — de maniere permanente.
Ca n’a pas accelere — ca a ralenti. L’organisation de recherche en IA a but non lucratif METR a mene un essai controle randomise avec 16 developpeurs open source experimentes (2025). Sur des projets qu’ils connaissaient bien, le groupe utilisant des outils IA a mis 19% plus de temps a completer les taches. Pourtant, les developpeurs eux-memes percevaient une acceleration de 20%. Un ecart de 39 points de pourcentage entre perception et realite. Les resultats peuvent differer sur de nouveaux projets, mais l’hypothese “IA = toujours plus rapide” est brisee.
A grande echelle, la stabilite s’effondre. Selon le Google DORA Report (2025), chaque augmentation de 25% de l’adoption de l’IA est correlee a une diminution de 7,2% de la stabilite de livraison logicielle.
Et elle s’est effectivement effondree. Amazon a impose l’utilisation d’outils de codage IA a l’echelle de l’entreprise en 2025 et deploye 21 000 agents IA. Durant la meme periode, environ 30 000 employes ont ete licencies, reduisant drastiquement la capacite de revue. La combinaison de generation rapide de code par IA et d’un personnel de revue reduit a provoque 4 incidents Sev-1 en 90 jours. Le 5 mars 2026, une panne de 6 heures a cause une perte estimee a 6,3 millions de commandes. Les documents internes declaraient : “La generation rapide de code par GenAI expose involontairement des vulnerabilites, et les garde-fous actuels sont totalement inadequats.”
“Fais du TDD” n’est pas la reponse
Le conseil habituel face au drift du vibe coding est “ecris des tests”. La direction est bonne, mais comment vous fournissez les tests determine le resultat.
L’etude TDAD (arxiv 2026) a teste cela precisement. Qwen3-Coder 30B a recu 100 instances de SWE-bench Verified.
| Condition | Taux de regression |
|---|---|
| Reference (aucune instruction de test) | 6,08% |
| Instruction procedurale “fais du TDD” | 9,94% (pire) |
| Fichiers de test concernes fournis en contexte | 1,82% (reduction de 70%) |
Dire a l’agent “fais du TDD” aggrave les choses. L’agent deraille de la tache originale en essayant de suivre des instructions procedurales. Mais fournir “ces fichiers de test doivent passer” comme contexte concret reduit les regressions de 70%.
La difference est claire. Pas des instructions sur “comment tester”, mais des contrats sur “ce qui doit passer”.
Hurl : des contrats en plain text
Hurl est un outil de test qui declare des requetes HTTP et des reponses attendues en plain text. Maintenu par Orange (France Telecom), c’est un binaire Rust sans dependance d’execution, 18,7k etoiles GitHub. Assez rapide pour s’executer a chaque commit en CI.
# Login succeeds
POST http://localhost:8080/api/auth/login
{
"email": "test@example.com",
"password": "secret123"
}
HTTP 200
[Asserts]
jsonpath "$.token" exists
jsonpath "$.user.email" == "test@example.com"
# Unauthenticated access returns 401
GET http://localhost:8080/api/pages
HTTP 401
Deux contrats. Le login doit retourner 200 avec un token. L’acces non authentifie doit retourner 401.
Quand ce fichier est commite dans git et s’execute a chaque commit en CI — au moment ou l’IA “nettoie” la logique d’authentification et que 401 devient 200, le commit est rejete. Le drift est detecte avant d’atteindre la production.
Pourquoi Hurl
Les tests unitaires peuvent aussi detecter le drift — si vous ne donnez pas a l’IA la permission de modifier les fichiers de test. Mais les tests unitaires verifient des fonctions internes, ce qui les rend structurellement couples a l’implementation. Quand les noms de fonctions changent, les tests cassent. Chaque refactoring necessite une mise a jour des tests.
Hurl se place a la frontiere HTTP. Il ne declare que des requetes et des reponses. Il ne connait rien des details internes du code. Peu importe comment l’IA modifie le code, si le comportement observable de l’exterieur reste le meme, les tests passent ; s’il differe, les tests echouent. Il est naturellement independant de l’implementation.
| Tests unitaires | Hurl | |
|---|---|---|
| Verifie | Les details internes des fonctions | Le contrat HTTP |
| Lors d’un refactoring IA | Modifies ensemble | Inchange |
| Detection du drift | Conditionnelle (si verrouilles) | Naturelle |
| Dependance a la structure du code | Elevee | Aucune |
| Lisibilite humaine | Niveau code | Plain text |
| Generation LLM | Necessite la comprehension de la structure du code | HTTP suffit |
Ce que Hurl verifie n’est pas le code mais le comportement. Le code peut etre librement modifie par l’IA. Le comportement ne doit pas changer. Cette distinction est la cle pour detecter le drift.
Verrouillage ratchet
Quand les tests Hurl passent, verrouillez-les. C’est le ratchet.
1. Write Hurl tests for current API (or auto-extract)
2. Run on every commit in CI
3. Passing tests cannot be deleted or modified
4. New features require new Hurl tests
5. All existing + all new tests must pass to merge
Dites a l’agent “refactorise ce code” et il modifie librement le code. Mais si les tests Hurl echouent, le commit est rejete. L’agent doit preserver tout le comportement existant lors du refactoring. Le drift sur des cas limites non couverts par Hurl reste possible, mais pour le comportement couvert, le drift est structurellement supprime.
Cela correspond exactement au resultat de l’etude TDAD. Pas une instruction procedurale “ecris des tests”, mais un contrat concret “ces fichiers Hurl doivent passer”. L’agent peut choisir la methode, mais ne peut pas violer le contrat.
Ca marche aussi sur le legacy
Vous faites deja tourner en production du logiciel vibe-code ? Pas besoin de tout recommencer.
Etape 1 : Capturez le comportement actuel avec Hurl.
Si une documentation API existe, traduisez-la directement en Hurl. Sinon, demandez a un agent de lire le code existant et d’ecrire des tests Hurl. L’objectif est de declarer “voici comment ca fonctionne actuellement” en plain text pour chaque endpoint.
Etape 2 : Integrez-le au CI.
Verifiez que tous les tests Hurl passent et ajoutez-les comme conditions de merge.
Etape 3 : Vous etes en securite.
Que l’IA refactorise ou ajoute des fonctionnalites, Hurl protege le comportement existant. Si du drift survient, le CI le detecte immediatement.
Pas des fondations — du renforcement parasismique. Consolider le batiment sans fermer la boutique.
Pas la fin du vibe coding — son evolution
Andrej Karpathy, qui a invente le terme “vibe coding”, a declare exactement un an plus tard, en fevrier 2026, que “l’ere du vibe coding est terminee”. Le nouveau paradigme est l’agentic engineering — les humains n’ecrivent pas le code, ils orchestrent des agents qui planifient, implementent et testent de maniere autonome.
Le Thoughtworks Technology Radar (2025) a place le Spec-Driven Development au niveau “Assess”. L’equipe de Martin Fowler a publie une analyse des outils SDD. L’industrie converge dans la meme direction.
Les tests Hurl sont la plus petite unite de cette transition. Pas besoin de 10 specifications. Pas besoin d’apprendre OpenAPI. Un fichier Hurl est un contrat. Et ce contrat previent structurellement le drift sans contraindre la liberte de l’agent.
Ne changez pas le modele. Ajoutez un contrat.
Articles lies
- yongol — La quille du SaaS de codage IA — Impose la coherence full-stack avec 10 SSOT. Hurl en fait partie.
- Ratchet Pattern — Comment faire aller les agents jusqu’au bout — La theorie derriere la verification deterministe et le verrouillage ratchet.
- IFEval-Exploiting Ratchet Code — Boucles de retroaction utilisant le sycophancy bias et Reins.
References
- Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
- METR (2025). “Measuring the Impact of Early AI on Experienced Open-source Developer Productivity.” arxiv.org/abs/2507.09089
- Google Cloud (2025). DORA Report 2025. cloud.google.com
- Wang, Z. et al. (2026). “TDAD: Test-Driven Agentic Development.” ACM AIWare 2026. arxiv.org/abs/2603.17973
- Autonoma (2026). “Amazon Vibe Coding Failures: 4 Sev-1s in 90 Days.” getautonoma.com
- CNBC (2026). “Amazon convenes ‘deep dive’ internal meeting to address AI-related outages.” cnbc.com
- Thoughtworks (2025). “Spec-Driven Development.” Technology Radar Vol.33. thoughtworks.com
- Karpathy, A. (2026). “From Vibe Coding to Agentic Engineering.” thenewstack.io
- Fowler, M. et al. (2025). “SDD Tools.” martinfowler.com
- Hurl. hurl.dev | github.com/Orange-OpenSource/hurl