Idée

Sans contrainte de volumétrie énoncée, un assistant conçoit pour le jeu de test et le défaut se manifeste en lenteur, pas en erreur

Idée principale

Une API qui renvoie deux cents éléments et une API qui en renvoie trente mille appellent deux conceptions différentes : la première se charge et s'affiche, la seconde impose pagination, filtrage côté serveur et stratégie de chargement. Rien dans le code ne distingue les deux cas, et rien dans un jeu de données de développement non plus.

Un assistant comme Claude Code qui n'a reçu aucune information sur les volumes réels produit donc la solution la plus directe : tout charger, tout passer à la page, tout filtrer côté front. En développement, avec quelques dizaines de lignes, cela fonctionne — et c'est bien le problème, parce que la validation passe.

La défaillance qui suit ne ressemble pas à une défaillance. Il n'y a pas d'erreur rouge dans la console : il y a une page qui met huit secondes à répondre, un navigateur qui se fige, un comportement qu'on croit dû au réseau. Un défaut silencieux n'est pas seulement plus difficile à corriger, il est plus difficile à attribuer — et pour quelqu'un qui n'a pas la culture technique, il n'est même pas identifiable comme un défaut.

Pourquoi c'est important

Cela désigne une catégorie d'information que l'assistant ne peut pas déduire et qu'il faut lui donner : les ordres de grandeur du réel. Ni la lecture du code existant, ni le jeu de test, ni la formulation de la demande ne les contiennent.

Cela dit aussi ce qu'un jeu de données de développement ne prouve jamais. Une recette passée sur des données de test atteste que le comportement est juste, pas qu'il tient — et ce sont deux propriétés qu'on valide au même moment, avec le même écran, sans que rien ne les sépare.

Nuances et limites

Le mécanisme n'est pas propre aux assistants : des développeurs ont toujours livré des requêtes qui s'effondrent en production. Ce qui change est la fréquence, puisque personne ne se pose la question au moment où le code apparaît en quelques secondes.

Et l'énoncé de la volumétrie ne suffit pas toujours : certaines contraintes ne se découvrent qu'en production, sur des distributions de données qu'aucune estimation n'anticipait.

Questions ouvertes

  • Quelles autres contraintes du réel sont, comme la volumétrie, invisibles dans le code et absentes du jeu de test — la latence des dépendances, la concurrence d'accès, la taille des pièces jointes ?