Quand l’IA dit PASS mais que le navigateur dit non

Le contexte

Dans le projet KOUSSEVO, j’ai rencontré un écart entre des tests automatisés réussis et le comportement observé dans le navigateur. Le résultat technique semblait confirmer le changement ; la recette réelle a montré que le parcours utilisateur n’était pas encore correct.

Cette expérience a renforcé une distinction dans ma méthode : une validation porte toujours sur un périmètre. Avant de conclure, je dois comprendre ce qui a été exécuté, dans quel environnement et avec quelles assertions.

Le piège

Une réponse « PASS » est facile à interpréter comme une validation globale. Elle peut pourtant résumer un ensemble de vérifications très ciblées. Lorsque l’IA prépare le code, les tests et le compte rendu, je dois aussi vérifier qu’ils ne reposent pas tous sur la même hypothèse erronée.

Un test automatisé valide ce qu’on lui demande de vérifier. Il ne garantit pas que l’utilisateur vivra le comportement attendu.

Ce que les tests automatisés avaient validé

Les tests avaient confirmé les assertions prévues dans leurs scénarios. Cela reste une information utile : les règles couvertes se comportaient comme attendu dans les conditions du test.

En revanche, un mock ne reproduit que le comportement qu’on lui a donné. Une simulation peut laisser de côté une interaction, une transition ou un état du navigateur. Une suite peut aussi être complète techniquement tout en oubliant un critère d’acceptation fonctionnel.

Ce que la recette navigateur a révélé

La recette a révélé que le comportement attendu n’était pas correctement restitué dans l’usage réel. Ce constat ne signifie pas que tous les tests étaient inutiles ; il signifie que leur couverture ne suffisait pas à conclure.

Dans cette phase, j’observe notamment le focus, la navigation, les formulaires, les délais de réaction et le rendu. Ces points sont des axes de vérification, pas une liste d’incidents tous rencontrés sur le projet.

Pourquoi les deux sont complémentaires

L’automatisation permet de répéter les contrôles et de détecter les régressions. Le navigateur réel permet de confronter le résultat à un parcours complet, dans son contexte d’utilisation.

Des tests automatisés peuvent eux-mêmes piloter un vrai navigateur. La distinction utile porte donc aussi sur la couverture : quels usages sont exercés, quelles observations sont vérifiées et quelle part reste à examiner humainement ?

Ce que j’ai changé dans ma méthode

Je sépare désormais le compte rendu technique de la décision de validation :

• préciser les tests exécutés et leurs limites ;
• vérifier le parcours dans le navigateur, y compris sur smartphone ;
• comparer le résultat aux critères d’acceptation ;
• transformer un écart reproductible en test de régression lorsque c’est pertinent ;
• conserver les points non vérifiés comme des questions ouvertes.

Le principe Trust, but verify consiste à demander des preuves proportionnées au changement, puis à les examiner.

À retenir

La recette réelle complète les tests automatisés ; elle ne les remplace pas. Mon rôle est de relier les résultats techniques au comportement attendu par l’utilisateur avant d’autoriser l’étape suivante.