Étude en ombre avec l'IA : entraînez le diagnostic que le code généré ne fait pas pour vous

Quand quelqu'un propose de comparer son propre diagnostic à celui d'une intelligence artificielle, la réaction la plus courante est : si l'IA génère du code plus vite que moi, m'entraîner ainsi est une perte de temps. L'objection a raison sur un point et tort sur un autre. Pour produire du code, l'IA est plus rapide, et personne n'a besoin de s'entraîner pour taper plus vite qu'elle. Mais produire du code n'est pas le goulot d'étranglement d'un test instable. Le goulot, c'est le diagnostic : face à un échec intermittent, quelle est la cause ? Cette question exige de regarder les logs, le timing, l'état et l'ordre d'exécution, et générer un cy.wait(2000) ne coûte rien justement parce qu'il n'y répond pas.

Générer est bon marché et vérifier coûte cher. Plus l'IA produit de code, plus de décisions de relecture retombent sur vous, et la compétence qui ne disparaît pas est de juger si un correctif traite la cause ou ne fait que masquer le symptôme. C'est ce jugement que l'étude en ombre entraîne, et le cas le plus clair pour le voir est le test instable, le fameux flaky test.

Un test instable est un problème de confiance avant d'être un problème technique. Quand l'équipe apprend que le rouge ment parfois, elle se met à l'ignorer, et un vrai échec passe inaperçu. En automatisation d'interface, la plainte est courante : maintenir les tests coûte souvent plus cher que les écrire, et les attentes mal placées et les sélecteurs fragiles reviennent dans toute discussion sur le sujet. Je ne cite pas de pourcentages parce que je ne veux pas répéter un chiffre que je n'ai pas vérifié ; je décris le schéma que reconnaît quiconque travaille en automatisation.

Le faux vert

Le risque concret est le faux vert. Un correctif faux mais plausible est pire qu'un échec, car l'échec prévient alors que le mauvais correctif laisse le test passer sans rien avoir réparé. Prenons un test Cypress qui ouvre une liste chargée par une requête et clique sur le premier élément :

it("ouvre le premier article", () => {
  cy.visit("/blog");
  cy.get("[data-cy=post-item]").first().click();
  cy.url().should("include", "/blog/");
});

Il dépend du fait que l'API réponde avant le clic. La suggestion la plus courante, d'un humain comme d'une IA, est d'ajouter une attente fixe :

cy.visit("/blog");
cy.wait(2000); // délai fixe : masque le symptôme
cy.get("[data-cy=post-item]").first().click();

Cela passe sur votre machine et échoue en CI, sous plus de charge, parce que le temps fixe n'a aucun rapport avec l'événement que le test attend réellement. La cause racine est que le test attend un intervalle d'horloge et non une condition. Le correctif qui traite la cause se synchronise sur l'événement :

it("ouvre le premier article", () => {
  cy.intercept("GET", "/api/posts*").as("posts");
  cy.visit("/blog");
  cy.wait("@posts"); // attend le vrai événement
  cy.get("[data-cy=post-item]").should("have.length.greaterThan", 0);
  cy.get("[data-cy=post-item]").first().click();
  cy.url().should("include", "/blog/");
});

Remarquez ce que le diagnostic a exigé : savoir que Cypress réessaie les assertions jusqu'à ce qu'elles passent, qu'un cy.wait temporel n'est pas une assertion, et que la source du retard était le réseau. Un modèle peut y arriver ou proposer la première version, qui a l'air correcte, et celui qui n'a pas entraîné le diagnostic ne sait pas distinguer les deux.

Pour arriver vite à ce diagnostic, il aide de classer l'échec avant d'agir. Quatre familles couvrent la plupart des instabilités des tests d'interface :

• Synchronisation : élément introuvable ou non cliquable, et le test passe au second essai. La question est sur quel événement il devrait attendre.
• Données et ordre : le test passe seul et échoue dans la suite entière. La question est s'il dépend de l'état laissé par un autre test.
• Environnement : passe en local et échoue en CI. La question est ce qui diffère, comme le CPU, l'horloge, le réseau, le fuseau horaire ou les données.
• Sélecteur : casse après un changement d'écran qui n'a pas changé le comportement. La question est si le sélecteur décrit une intention ou une structure.

Classer l'échec dans l'une de ces familles réduit l'espace de recherche et nomme l'erreur, et nommer l'erreur est ce qui permet de mesurer la progression, c'est là que la méthode intervient.

Comment fonctionne l'étude en ombre

L'idée est une expérience contrôlée pour une seule personne, avec l'IA comme comparaison en aveugle : vous diagnostiquez d'abord, elle diagnostique en parallèle sans voir votre conclusion, puis les deux résultats sont confrontés. Le début de la marche à suivre est celui-ci :

1. Choisissez un test réellement instable, avec le log de l'échec et ce qui a changé entre une exécution verte et une rouge.
2. Écrivez votre hypothèse avant toute aide, en quatre champs : famille, cause probable, preuve et correctif proposé. Si vous ne pouvez pas écrire la preuve, ce que vous avez est une intuition.
3. Donnez à l'IA le même matériel, sans votre hypothèse, et demandez le diagnostic dans le même format.

Pour la troisième étape, un prompt simple suffit :

Voici le log d'un échec intermittent, le code du test et le diff entre l'exécution verte et la rouge.
Répondez en quatre champs :
1. Famille (synchronisation, données et ordre, environnement ou sélecteur)
2. Cause probable
3. Preuve, dans le matériel envoyé, qui soutient la cause
4. Correctif proposé et pourquoi il traite la cause

Une fois les deux diagnostics en main, le reste du processus est le suivant :

4. Comparez champ par champ et notez où vous étiez d'accord et en désaccord. Le désaccord est le point d'apprentissage.
5. Demandez à l'IA de critiquer votre hypothèse (quelle preuve vous avez ignorée, quelle alternative vous n'avez pas écartée), puis faites l'inverse avec la sienne.
6. Vérifiez par l'exécution : appliquez le correctif et lancez le test des dizaines de fois, pas une seule.
7. Consignez le résultat dans le tableau de suivi.

La sixième étape empêche la méthode de devenir un débat d'opinions et évite d'accepter une explication seulement parce qu'elle est bien écrite. Avec Cypress, une façon directe de répéter le test est d'en générer plusieurs copies, de préférence dans un environnement sous charge, comme la CI, qui augmente la chance d'exposer la condition de concurrence :

Cypress._.times(30, (i) => {
  it(`ouvre le premier article (${i + 1})`, () => {
    cy.intercept("GET", "/api/posts*").as("posts");
    cy.visit("/blog");
    cy.wait("@posts");
    cy.get("[data-cy=post-item]").first().click();
    cy.url().should("include", "/blog/");
  });
});

Le tableau de suivi transforme les réussites et les erreurs en données. Un tableau simple suffit, avec les colonnes cas, famille que vous avez indiquée, famille indiquée par l'IA, famille réelle, qui a trouvé la bonne cause et si le correctif est resté stable après les exécutions. Au bout de quelques semaines, lisez-le par colonne : votre taux de réussite sur la famille montre si l'entraînement fonctionne, la famille où vous vous trompez le plus montre quoi étudier, et les erreurs de l'IA montrent sur quel type d'échec s'en méfier davantage. Ces chiffres sont les vôtres, sur un petit ensemble de cas, et non une statistique du marché.

Reste à répondre à l'objection du début par autre chose qu'une opinion. Le coût est faible et borné, car chaque cas tient en quelques minutes d'écriture plus la conversation avec l'IA. Le retour se cumule, puisque vous travaillez avec l'IA tous les jours et que chaque diagnostic bien fait améliore la façon dont vous lui décrivez le problème et dont vous relisez sa sortie. Et la méthode protège contre le faux vert, dont le coût (un test qui ment, un vrai échec masqué) dépasse le temps passé à s'entraîner. Elle ne remplace pas l'IA : vous continuez à l'utiliser pour générer, et l'entraînement calibre le jugement qui décide quoi faire de ce qu'elle a généré.

Ce principe a un parallèle dans le logiciel embarqué des aéronefs. La norme DO-178C, reconnue par des autorités comme la FAA, l'EASA et Transports Canada, traite la vérification comme une activité à part entière, avec relecture des exigences et des cas de test, traçabilité entre exigence, test et résultat, et couverture structurelle jusqu'à MC/DC aux niveaux les plus critiques, et l'un de ses piliers est l'indépendance : celui qui vérifie n'est pas celui qui a produit, pour ne pas hériter du même angle mort. L'étude en ombre emprunte cette idée à l'échelle personnelle, avec l'IA comme seconde lecture indépendante et l'exécution répétée comme preuve objective. C'est un parallèle de principe : je ne dis pas que les équipes de l'aviation utilisent cette méthode sous ce nom.

Il convient d'énoncer les limites. La méthode est une proposition, sans étude contrôlée prouvant un gain, et son seul validateur est votre tableau de suivi. L'IA peut se tromper avec assurance, c'est pourquoi la vérification par l'exécution est obligatoire. Et les logs peuvent contenir des données sensibles, des jetons ou des informations clients, qui ne doivent pas aller au modèle. Pour commencer cette semaine, prenez les trois tests les plus instables de votre projet, écrivez l'hypothèse de chacun avant d'ouvrir le moindre outil, et comparez seulement ensuite.