IA de programmation : tester au-delà de la démo
Un benchmark met à l’épreuve les applications créées par l’IA face aux erreurs, aux doubles clics et aux petits écrans. Découvrez ses résultats et ses limites.
Quand l'IA code une application web, qui vérifie qu'elle fonctionne vraiment ?
Un formulaire s'affiche, un bouton répond, un message vert annonce « Opération réussie » : dans une démo, l'application générée par une IA donne souvent l'impression d'être finie. Mais qu'en est-il si le serveur renvoie une erreur, si l'utilisateur clique deux fois, ou si le site est consulté sur un téléphone ? C'est dans ces situations banales - pas dans le scénario parfait - que la fiabilité se voit.
RealityBench, un benchmark présenté dans le cadre d'un défi Kaggle, a soumis douze petites applications web à ce genre de tests. Résultat : un problème moins visible qu'un bug d'affichage. Certains modèles remplacent l'appel au serveur par une imitation exécutée directement dans la page. Sur l'écran, tout ressemble à une réussite, alors qu'aucune opération réelle ne s'est produite.
On ne peut pas, avec ces résultats, classer tous les modèles ni trancher définitivement sur la « qualité » de l'IA de programmation. En revanche, ils expliquent très bien pourquoi il faut tester le comportement réel du code - pas seulement ce qu'il affiche. Voici le protocole, les principaux résultats, et ce que ça change pour une équipe produit ou technique.
Pourquoi un test de démonstration ne suffit pas
Les outils d'IA générative savent produire vite une interface qui a l'air crédible. On leur demande une page de réservation, un tableau de bord ou un parcours de paiement : ils génèrent du code qui peut donner une impression de produit « prêt » dès le premier écran. C'est utile pour explorer une idée ou obtenir un prototype. Mais ce n'est pas une preuve que l'application fonctionne une fois sortie du cadre idéal.
Un parcours « parfait » ne teste qu'une partie du système. Il dit peu de choses sur la réaction de l'interface quand le réseau lâche, quand les données sont invalides, ou quand une action est répétée. Et ce sont justement ces cas-là qui mettent à l'épreuve la gestion des erreurs, la cohérence des données, et la qualité de l'expérience utilisateur.
Une interface crédible peut masquer une opération absente
Prenons une réservation. L'utilisateur choisit une date, clique sur « Réserver » et voit un numéro de confirmation. Sur l'écran, tout semble logique. Sauf que si l'application n'a jamais envoyé la demande à un serveur réel, il n'existe aucune réservation à l'arrivée.
L'interface ne se contente pas de simplifier un détail : elle donne à l'utilisateur une information qui paraît fiable... alors qu'elle ne l'est pas. C'est pour ça que, côté produit, une démo peut rester acceptable si elle est clairement annoncée comme telle. En revanche, une application présentée comme fonctionnelle ne devrait pas afficher une confirmation de paiement, de réservation ou de modification alors que rien n'a été transmis.
Le risque apparaît surtout aux frontières du système
Les problèmes ne viennent pas toujours d'un algorithme « tordu ». Ils surgissent souvent à la jonction entre le navigateur, le serveur et les actions de l'utilisateur, par exemple :
- une réponse HTTP 500 au moment de l'enregistrement ;
- un créneau déjà pris qui déclenche un conflit 409 ;
- un bouton de paiement cliqué deux fois ;
- un formulaire vide ou une quantité négative soumise ;
- un fichier non autorisé (ex. un exécutable au lieu d'un PDF) sélectionné ;
- un écran étroit ou une navigation au clavier qui révèle des défauts de mise en page ou d'accessibilité.
Un modèle peut gérer le cas « nominal » et échouer sur ces frontières sans que ça saute aux yeux en démonstration rapide. Et pour comprendre comment intégrer l'IA dans un processus de développement logiciel, il faut évaluer le comportement observable, les échanges réseau, et la reprise après erreur - pas seulement la vitesse de génération.
RealityBench met les interfaces à l'épreuve
RealityBench donne à un modèle une spécification parmi douze cas d'usage web. Ensuite, la page est ouverte dans un navigateur automatisé, sans interface graphique, et manipulée comme le ferait un utilisateur. L'idée est simple : vérifier si l'application tient quand le scénario s'éloigne du chemin idéal.
Le benchmark attribue deux notes sur 100. La note « Demo » regarde si le parcours nominal marche et si l'action principale atteint bien le serveur. La note « Reality » mesure la tenue de l'application face aux incidents, aux entrées incorrectes, et aux contraintes d'usage. Cette séparation compte : une interface peut réussir « sur la démo », puis se dégrader au moindre pépin.
Douze tâches, des erreurs courantes
Les tâches couvrent des besoins assez familiers, pas des problèmes de recherche pointus : connexion, recherche avec autocomplétion, paiement, téléversement de fichier, gestion de tâches, réservation, messagerie, fiche produit, tableau d'administration, paramètres, formulaire avec dépendances et assistant en plusieurs étapes.
Chaque tâche inclut des attentes concrètes. Une réservation doit refuser une date passée et gérer un créneau déjà pris. Un paiement ne doit pas vider le panier en cas d'échec, et il doit ignorer le double clic. Un formulaire en plusieurs étapes doit garder les réponses si l'utilisateur revient en arrière.
Il y a aussi des contraintes faciles à oublier en génération : afficher la page sur 375 pixels de large, vérifier la navigation au clavier, gérer un champ manquant dans une réponse, ou respecter des contrôles désactivés tant que les informations nécessaires ne sont pas là. Ce ne sont pas des cas rares. À l'échelle d'un service, ce sont souvent eux qui décident si les utilisateurs arrivent au bout de leur tâche.
Ce que montrent les deux séries complètes
Deux modèles ont été évalués sur les douze tâches : Claude Opus 5.5 et Gemini 3.7 Flash. Selon les résultats publiés par l'auteur de RealityBench, les scores sont :
| Modèle | Tâches évaluées | Démo | Réalité | Pages ayant remplacé fetch |
|---|---|---|---|---|
| Claude Opus 5.5 | 12 | 96,9 | 99,6 | 1 |
| Gemini 3.7 Flash | 12 | 69,8 | 86,1 | 7 |
Ce tableau n'est pas un classement « définitif » des modèles. Chaque tâche n'a été exécutée qu'une fois par modèle. D'autres modèles étaient prévus, mais des soucis de quota ont interrompu certains essais ; des scores issus d'anciennes versions du correcteur n'ont pas été intégrés. En bref : on peut analyser un comportement précis dans ce protocole, pas mesurer « toutes » les capacités d'un modèle.
Cela dit, le test reste intéressant. Le signal le plus parlant concerne souvent les appels réseau : remplacer fetch - la fonction du navigateur utilisée pour envoyer des requêtes - peut donner à la page l'apparence d'une application connectée alors qu'elle répond localement. Et pour aller plus loin sur les tests automatisés avec Playwright, ça aide à distinguer ce que fait l'interface de ce que fait réellement le service derrière.
Le problème révélé : un faux serveur dans la page
Dans l'application de réservation de Gemini 3.7 Flash, le code remplace window.fetch pour intercepter une demande vers /api/book. Au lieu d'envoyer la requête à une API, la page attend quelques centaines de millisecondes puis renvoie elle-même une réponse de confirmation et un identifiant de réservation.
Côté utilisateur, ça se comprend vite : le message « Réservation confirmée » s'affiche. Sauf que rien n'a été enregistré sur un serveur. L'intention est d'ailleurs indiquée dans l'exemple source : fournir un serveur simulé pour permettre une exécution autonome. Une solution de démonstration devient un gros défaut si elle se retrouve indifférenciée du comportement attendu en production.
Une démo locale n'est pas une transaction réelle
Le problème n'est pas le fait d'utiliser des données fictives pendant la conception. Un prototype autonome peut être tout à fait légitime si l'équipe assume clairement que c'est une simulation. Le souci apparaît quand il n'y a aucun repère fiable pour distinguer simulation et opération réelle, ou quand le code simulé remplace la vraie connexion au service sans que ce soit explicitement demandé.
En entreprise, les conséquences dépendent de l'usage. Sur un outil interne, ça peut faire perdre du temps à une équipe qui pense que ses modifications ont été sauvegardées. Dans un parcours de réservation ou de paiement, ça peut générer des confirmations trompeuses, des commandes absentes et des demandes au support. Et quand il y a des données personnelles, des paiements ou des obligations de traçabilité, l'écart entre l'action affichée et l'action réellement exécutée pose aussi une question de confiance et de contrôle.
Le score seul ne raconte pas toute l'histoire
Sur les douze pages de Gemini, sept remplacent fetch. Huit échouent au parcours nominal, et dans sept des huit cas, la page est signalée comme ayant un faux backend. Ça suggère un lien fort, mais ce n'est pas une explication unique de tous les échecs.
L'exemple de la page de connexion est parlant : elle obtient 62,5 en note « démo », sans remplacer fetch. À l'inverse, la page de téléversement réussit le parcours de démonstration, mais perd des points parce que le champ de sélection de fichier n'avait pas de libellé. Donc oui, la simulation de serveur explique une partie importante des problèmes. Mais il reste aussi des défauts d'interface, de validation et d'accessibilité.
Claude Opus 5.5 suit une autre logique. Sept de ses douze pages contiennent une simulation de fetch, mais six ne l'activent que dans certains contextes - par exemple avec un paramètre de démonstration ou sur une adresse file://. Dans ces conditions, le chargement « normal » conserve la fonction native. Ces pages obtiennent 100 aux deux notes. La page des paramètres active, elle, la simulation par défaut et affiche une option « utiliser le serveur simulé » cochée : c'est la seule page Opus signalée en échec de tâche.
Sur les deux séries complètes, huit des neuf échecs au parcours nominal concernent donc des pages qui ont remplacé fetch. C'est un signal à prendre au sérieux dans ce benchmark, pas une preuve que tout code généré par l'IA porte ce défaut.
Le correcteur doit lui aussi être testé
L'auteur explique que sa première version du benchmark pouvait être trompée. Elle cherchait certains mots dans le code ou dans la page : un texte de confirmation caché pouvait être compté comme « visible », et un bloc catch pouvait être considéré comme la preuve qu'une erreur était affichée. Le correcteur récompensait alors du code qui ne produisait pas vraiment le comportement attendu.
Il pouvait aussi pénaliser des pages qui fonctionnaient correctement. Le protocole tentait, par exemple, de cliquer sur un bouton de téléversement désactivé avant la sélection d'un fichier, ou utilisait des cases à cocher comme s'il s'agissait de champs de texte. Le protocole a ensuite été ajusté : il se base sur le texte réellement visible, les valeurs des champs, clique sur le bouton correspondant à l'action et traite un contrôle désactivé comme « impossible » à presser.
Ça rappelle une règle simple : un benchmark n'est jamais une mesure neutre par nature. Il embarque ses hypothèses, et ses erreurs peuvent orienter les conclusions. Une équipe qui construit sa propre évaluation doit s'assurer que le test mesure une expérience réelle - pas juste la présence de mots « dans le code ».
Ce que ces résultats changent pour les équipes
Le message principal n'est pas « interdisez les modèles génératifs ». C'est plutôt : ne confondez pas une interface visuellement convaincante avec une fonctionnalité prête à être livrée. L'IA peut accélérer la première version, mais la validation doit vérifier les engagements que cette version donne à l'utilisateur.
Ajouter des tests autour des frontières importantes
Pour chaque fonctionnalité générée ou assistée par l'IA, commencez par identifier l'action métier principale : réserver, payer, enregistrer, supprimer, envoyer. Ensuite, avant de vous fier à l'interface, vérifiez quatre choses :
- La requête part-elle vers le service attendu ? Contrôlez l'URL, la méthode, les données envoyées et la réponse reçue.
- Que se passe-t-il en cas d'échec ? Provoquez une erreur serveur et vérifiez que l'utilisateur comprend ce qui arrive - et que vous ne perdez pas ses données inutilement.
- Les actions répétées sont-elles sûres ? Testez le double clic et, pour les opérations sensibles, la protection contre les doublons.
- L'interface respecte-t-elle les contraintes d'usage ? Vérifiez validations, navigation au clavier, libellés et affichage sur mobile.
Vous pouvez automatiser ça avec un navigateur comme Playwright, mais l'automatisation ne remplace pas le choix des bons scénarios. Un test qui clique « au bon endroit » sans comprendre l'état réel de l'UI risque de mesurer... le testeur, pas le produit.
Séparer clairement démonstration et production
Si une maquette doit fonctionner sans backend, le mode simulé doit être visible, explicite et désactivé par défaut dans les configurations destinées à la production. Une bannière « données de démonstration » vaut mieux qu'une confirmation ambiguë. Côté code, les dépendances et les environnements doivent rendre l'activation accidentelle d'un faux service plus difficile.
Oui, ça a un coût : maintenir un mode démo, une API réelle et des tests demande de la configuration. Mais c'est moins cher que de livrer une application qui affiche « fait » alors que rien n'a été réellement exécuté. Dans beaucoup de cas courants (80 %), la vraie question n'est pas « est-ce que le modèle sait simuler un backend ? ». C'est plutôt : « est-ce que l'équipe peut identifier et contrôler le moment où la simulation est utilisée ? »
Pour les usages impliquant des données personnelles, des paiements ou des décisions opérationnelles, il faut aussi intégrer sécurité, journalisation et responsabilités dans la revue. Ces sujets dépassent le benchmark, mais ils relèvent de la même discipline : évaluer les risques liés à l'IA générative à partir de conséquences concrètes, pas de l'apparence du résultat.
Lire un benchmark comme un outil de décision
RealityBench est intéressant parce qu'il teste des comportements visibles, et qu'il rend aussi ses limites lisibles. Pour l'utiliser en référence interne, une équipe peut reprendre la logique sans reproduire exactement les douze tâches :
- choisissez les parcours qui comptent vraiment pour vos clients ou vos opérations ;
- définissez ce que l'utilisateur doit voir, et ce que le système doit vraiment faire ;
- testez le scénario nominal puis les erreurs et les clics répétés ;
- conservez les traces utiles, notamment les requêtes réseau et les états de l'interface ;
- répétez les évaluations avant de comparer deux modèles, car une seule génération peut tomber « à côté ».
L'auteur de RealityBench propose justement des pistes d'amélioration : répéter les tâches pour observer une plage de résultats, compléter les essais interrompus par les quotas, et ajouter une consigne indiquant qu'un backend réel est déjà disponible. L'objectif serait de voir si le faux serveur disparaît quand le contexte est explicite, ou si le modèle le garde « au cas où ».
Le code et les tâches sont disponibles sur GitHub et les exercices sont aussi publiés sur Kaggle. Une équipe peut lancer le correcteur localement avec Playwright, sur un fichier HTML ou sur une réponse modèle contenant le code. Le plus utile reste d'en faire un point de départ pour construire une évaluation adaptée à votre produit - pas un substitut à une revue technique.
Conclusion : valider le comportement, pas l'apparence
RealityBench met en évidence un angle mort des applications générées par l'IA : une interface peut donner l'impression d'avoir accompli une action alors qu'elle ne fait qu'en simuler le résultat. Le benchmark ne suffit pas à départager tous les modèles, mais il fournit une méthode plus exigeante pour évaluer ce que vous construisez vraiment.
La règle est simple : testez ce que l'utilisateur voit, mais vérifiez aussi ce que le système exécute. Pour votre prochain prototype assisté par IA, choisissez une action métier importante, puis testez son parcours nominal, son échec et le double envoi. Si l'application tient dans ces conditions, vous aurez une base de décision plus solide qu'une démo « qui marche ». Consultez le dépôt RealityBench, puis adaptez ses scénarios à votre produit avant toute mise en production.