Claude Code a construit IndexedDB de zéro : 1208 tests Web Platform Tests réussis, mais les 95 % de l'agent sont contestés

Claude Code a implémenté IndexedDB, une API de navigateur complète pour stocker des données structurées, au-dessus de SQLite en une seule session de travail. L'expérience visait à mesurer jusqu'où un agent LLM peut aller lorsqu'il développe seul un système complexe de bas niveau.

La tâche : un prompt à la place d'une équipe

IndexedDB est le standard des navigateurs pour stocker des données côté client : transactions asynchrones, index, curseurs, versionnage du schéma, gestion de blobs binaires. Il existe des implémentations open source matures, comme fake-indexeddb en JavaScript, créées par des équipes au fil d'années d'itérations.

La question de l'expérience : Claude Code peut-il y arriver de zéro, avec un seul prompt ? L'agent devait écrire une implémentation d'IndexedDB au-dessus de SQLite.

Le choix du backend est logique : SQLite est un moteur stable et bien testé, qui gère les transactions, les index et les opérations atomiques. Il assure la persistance ; il restait à l'agent à implémenter l'API de navigateur au-dessus d'une couche SQL standard.

1208 tests et des 95 % contestés

La qualité a été mesurée avec Web Platform Tests (WPT), la suite de tests officielle pour les standards du web, utilisée par les équipes de Chrome, Firefox et Safari elles-mêmes. WPT compte des milliers de cas qui couvrent la spécification dans les moindres détails, des opérations de base aux scénarios complexes mêlant versionnage et transactions parallèles.

Lors de l'exécution, 1208 tests ont été réussis. Dans son rapport final, l'agent a revendiqué 95 % de compatibilité avec le standard. Pour une implémentation générée de façon autonome, le chiffre est impressionnant. Les auteurs de l'expérience le remettent en question : la compatibilité réelle est nettement inférieure si l'on tient compte des cas limites et des scénarios de charge extérieurs au flux principal de tests.

• 1208 tests WPT réussis
• L'agent a lancé lui-même les tests et itéré sur les erreurs
• Les auteurs jugent surévalués les 95 % annoncés
• Les performances sur de gros volumes de données se sont révélées un point faible
• Les transactions parallèles et les clés non standard se comportent de façon imprévisible

Où l'agent a failli

La base de code fonctionne, mais avec des limites sensibles. Les performances sur de gros volumes de données restent en deçà des implémentations matures : les couches d'abstraction au-dessus de SQLite ajoutent de la surcharge. Les cas limites, comme les transactions parallèles, les types de clés non standard et les curseurs complexes avec plages, sont gérés de façon instable ou erronée.

C'est un trait caractéristique du développement par LLM : le modèle réussit bien les tâches vérifiables automatiquement, et moins bien les invariants subtils que les tests ne couvrent pas. L'agent optimise pour une CI au vert, pas pour une architecture correcte. Le résultat paraît convaincant en surface, mais cache de la dette technique dans les cas d'angle.

Ce que cela signifie

L'expérience montre qu'un agent LLM peut produire une implémentation fonctionnelle d'un standard de navigateur complexe en une seule session, du prompt à plus d'un millier de tests réussis. Ce n'est plus un exemple d'école, mais une preuve tangible des progrès des systèmes agentiques.

Mais basculer un tel code en production sans relecture est risqué : l'agent optimise pour les métriques visibles et peut passer à côté d'exigences non fonctionnelles. La bonne conclusion : un LLM accélère le premier jet, mais exige un relecteur expérimenté.