Vous collez une fonction dans une IA, « écris-moi les tests », et une suite complète tombe en quelques secondes — la barre de couverture passe au vert. Rassurant. Sauf qu'un test qui passe ne prouve pas que votre code est juste : il prouve seulement que le code fait ce que le test attend — et l'IA a écrit ce test en lisant le code. Si le code contient un bug, elle risque d'écrire un test qui valide le bug, au vert, pour toujours. Voici comment tirer de l'IA de vrais tests, pas un faux filet de sécurité.
Ce que l'IA fait très bien
Écrire des tests est fastidieux, répétitif — donc un terrain idéal pour l'IA (Fig. 1).
Le code d'échafaudage : la préparation, les objets simulés, les fixtures — tout le répétitif. Les cas évidents : le fonctionnement nominal, quand tout va bien. Combler la couverture : générer des tests pour les lignes encore jamais exercées. Tous les assistants le font — ChatGPT, Claude, Gemini, Mistral Vibe (l'assistant anciennement « Le Chat ») — comme l'assistant de code de GitHub, via une commande dédiée, ou un éditeur de code IA. Sur ce terrain mécanique, le gain de temps est réel. Le problème est qu'un test n'est pas qu'un bout de code mécanique.
Le piège de l'oracle
Un test repose sur un oracle : le mécanisme qui dit quelle est la bonne réponse attendue. Et c'est précisément ce que l'IA ne connaît pas (Fig. 2).
C'est le problème de l'oracle, connu de longue date : un test ne vaut que par sa capacité à distinguer le comportement voulu du comportement faux. Or l'IA infère l'attendu depuis le code tel qu'il est, pas depuis votre intention — la recherche le confirme : « si l'implémentation contient un bug, le modèle peut encoder ce comportement bugué dans l'oracle, produisant un test qui passe à tort ». Vous obtenez, sans le vouloir, un test de caractérisation : il fige le comportement actuel, bugs compris, au lieu de vérifier le bon. S'ajoutent trois faiblesses mesurées : les tests d'IA visent le cas nominal et ratent les cas limites (zéro, valeur négative, entrée vide, dépassement) ; une part notable sont triviaux — une étude relève qu'environ un tiers ne contiennent aucune assertion réellement dépendante du code ; et surtout, la couverture n'est pas la correction. Une ligne exécutée n'est pas une ligne vérifiée : pour savoir si une suite attrape vraiment des bugs, la mesure pertinente n'est pas le pourcentage de couverture mais le test de mutation, qui injecte de petites fautes et regarde si les tests les détectent.
C'est le prolongement de ce qu'on disait sur le débogage assisté — un correctif qui compile n'est pas un correctif qui corrige — et sur la refonte de code hérité, où l'on caractérise justement l'existant avant de le changer. Le fil rouge est le même : l'IA écrit la mécanique, vous gardez le sens.
La méthode : gardez l'oracle
La parade tient en une idée : l'attendu, c'est votre travail, pas celui de la machine. Quatre réflexes.
- Définissez le comportement attendu — vous, pas le code. Dites à l'IA ce que la fonction doit faire (la spécification), et relisez chaque assertion : la valeur attendue vient-elle de l'intention, ou d'une simple recopie de ce que le code produit déjà ?
- Ajoutez les cas limites vous-même. L'IA couvre le chemin heureux ; à vous le zéro, le négatif, le vide, l'énorme, l'erreur — là où se cachent les vrais bugs.
- Mesurez la bonne chose. La couverture montre le code non testé ; elle ne dit rien de la qualité. Pour vérifier que vos tests mordent, passez-les au test de mutation.
- Traitez les tests comme du code. Ils se maintiennent, et un test trop rigide devient un poids. Et comme tout code sensible, ne collez pas un fichier confidentiel dans un outil grand public — réservez-le à un cadre validé.
Bien utilisée, l'IA supprime la corvée du test et vous laisse le seul travail qui compte vraiment : décider ce qui est correct. Mal utilisée, elle transforme une illusion de couverture en fausse assurance. Le vieux réflexe de testeur reste le meilleur garde-fou, même à l'ère de l'IA : « un test que je n'ai pas vu échouer sur un vrai bug n'a encore rien prouvé. »
- L'IA excelle sur la mécanique : échafaudage, cas nominaux, trous de couverture.
- Le piège de l'oracle : elle déduit l'attendu du code, pas de votre intention — si le code a un bug, le test le fige au vert.
- Couverture ≠ correction : une ligne exécutée n'est pas vérifiée ; le test de mutation mesure si vos tests attrapent des bugs.
- Gardez l'oracle : définissez l'attendu, relisez chaque assertion, ajoutez les cas limites.
- Les tests sont du code : à maintenir — et pas de code confidentiel dans un outil grand public.
Dans la même logique « l'IA écrit la mécanique, vous gardez le sens » : déboguer sans coller un correctif à l'aveugle, refondre du code hérité sans tout casser, automatiser une tâche par script. Et sur ce que vous confiez à l'IA : encadrer l'usage de l'IA en entreprise.
Cette analyse fait partie de notre veille Outils & IA. Pour tester votre code avec l'IA sans fausse assurance, téléchargez l'Atlas IA 2026 et abonnez-vous à la newsletter AISKILLSPRO.
Au-delà de l'IA, retrouvez nos guides, tutoriels et modules Odoo sur OdooSkills, le blog Odoo ↗ (nouvel onglet).