Pourquoi nous racontons aussi les échecs de nos tests d’agents IA

Un bon score peut masquer une fonction absente. Deux résultats de nos essais internes montrent pourquoi nous devons regarder les erreurs et préciser ce que nous avons réellement mesuré.

Une copie d’application de pointage avait obtenu 92,5 sur 100 dans notre évaluation interne. Une vérification ultérieure a révélé qu’elle ne compilait pas et qu’elle effaçait sa base au lancement. Ce cas nous a obligés à revoir la façon de juger un résultat, même bien noté.

La première défaite portait sur un besoin précis

Lors du premier duel sur un suivi d’habitudes, notre méthode obtenait 82,1 contre 90,8 pour BMAD-METHOD v6. Il s’agissait d’un score de couverture de la conception : le jury cherchait si les règles attendues étaient présentes dans les documents. Ce n’était pas un pourcentage de fiabilité du logiciel.

Les remarques portaient notamment sur les dates, les doublons et les règles oubliées. Elles ont servi à préparer les essais suivants. Nous conservons ce résultat dans le récit des campagnes, avec les limites du protocole.

Une bonne note ne suffit pas à dire « utilisable »

Le cas de la pointeuse venait d’une autre campagne. Ses documents pouvaient paraître convaincants alors que le démarrage réel échouait. Lire les explications et exécuter le produit ne répondent pas à la même question.

Nous avons donc renforcé les vérifications qui passent par le vrai point d’entrée de l’application. Pour une réservation, cela signifie essayer le parcours depuis l’écran, puis retrouver la donnée enregistrée, au lieu de contrôler seulement une fonction isolée.

Comparer les mêmes copies devant le même juge

Une note peut aussi changer parce que le juge devient plus exigeant. Nous avons soumis deux versions anonymisées du même sujet au même juge IA, avec un ordre de présentation tiré au sort. La version plus récente a été préférée sur six des huit sujets.

Ce résultat concerne une comparaison entre deux versions de notre méthode. Il ne classe pas Maestro face à tous les outils de création d’applications et ne prédit pas le résultat de votre projet.

Ce qui est public et ce qui reste interne

Nous publions des synthèses : des résultats, des exemples de défauts et les limites de la mesure. Les rapports détaillés, les copies testées et les verdicts complets restent internes. Le lecteur ne dispose donc pas ici de toutes les pièces pour reproduire ces campagnes.

Ces observations sont produites par notre équipe, avec des jurys d’IA. Elles ne constituent pas une évaluation indépendante. Raconter une défaite apporte du contexte ; cela ne rend pas automatiquement notre protocole impartial ou exhaustif.

Ce que vous pouvez demander pour votre projet

Demandez ce qui a été essayé, ce qui a échoué et ce qui reste à vérifier. Faites préciser si le résultat porte sur un premier lot de fonctions ou sur toute l’application. Un compte rendu utile permet de retrouver un problème et de le rejouer.

Notre guide pour vérifier une application sans savoir coder propose une façon de commencer. Gardez aussi les dépenses de l’essai à côté du résultat : elles ne prennent leur sens qu’avec ce qui a été construit.