Votre logiciel calcule quelque chose qui engage l'entreprise : une paie, un devis, une taxe, un simulateur sur votre site. Les tests passent au vert. Mais qui a décidé de la bonne réponse que ces tests attendent ? Souvent, personne. On a recopié ce que le programme sortait le jour où quelqu'un a jugé que « ça avait l'air bon ». C'est exactement ce qu'un oracle de test vient corriger.
J'en parle parce que c'est ce que nous avons fait chez Moonworkers, mon entreprise de logiciel de paie pour les petites entreprises britanniques, et parce que j'applique la même idée à mes machines de contenu. Voici comment je m'y prends, y compris ce que la méthode ne voit pas.
01Ce qu'est un oracle de test, en une phrase
Le glossaire de l'ISTQB, l'organisme qui certifie les testeurs, donne la définition la plus courte : un oracle de test est une source pour déterminer un résultat attendu, que l'on compare au résultat réel du système testé.
Le mot fait penser à une voyante. Il désigne en fait quelque chose de très terre à terre. Dans une courte vidéo de la chaîne Test Automation TV, l'auteur prend l'exemple d'un calculateur de prêt : le document d'exigences dit que 1 000 prêtés à 10 % sur un an donnent 100 d'intérêts. Ce document est l'oracle. Si le logiciel répond autre chose, le test échoue. Il rappelle aussi qu'un oracle peut être du code, un texte, un modèle mathématique ou le jugement d'un spécialiste.
La difficulté a un nom chez les chercheurs : le problème de l'oracle. Une revue publiée sur arXiv par Rui Li et ses coauteurs le résume ainsi : il faut un mécanisme systématique pour vérifier le résultat de chaque cas de test, et quand ce mécanisme manque, beaucoup de techniques de test perdent leur intérêt. Générer mille cas ne sert à rien si personne ne sait dire lesquels sont justes.
02Où trouver un oracle quand personne n'a la bonne réponse
Sur un calcul métier, on a rarement un tableau de réponses tout prêt. Voici les sources que j'utilise, de la plus sûre à la plus fragile.
Le texte officiel
Pour un calcul réglementé, la référence existe : c'est la loi, le barème, le manuel de l'administration. On en tire une implémentation séparée, écrite par quelqu'un d'autre ou au moins sans regarder le code de production, et on compare les deux. C'est la forme d'oracle la plus solide, parce qu'elle ne partage pas les erreurs du logiciel testé.
L'outil de référence
Quand l'administration ou un organisme publie un simulateur, il devient un oracle pratique. On saisit les mêmes cas des deux côtés et on compare. C'est plus lent, souvent manuel, mais c'est une deuxième opinion indépendante.
L'ancienne version
Pour une refonte, la version actuelle sert d'oracle à la nouvelle : mêmes entrées, mêmes sorties attendues. Attention, elle transmet ses erreurs. Je l'utilise pour détecter les écarts, puis chaque écart se tranche avec le texte.
Les propriétés du calcul
Quand on n'a aucune réponse exacte, on peut encore vérifier des relations. C'est le principe du test métamorphique décrit dans la même revue sur arXiv : la plus courte distance de a vers b doit être égale à celle de b vers a. Pour une paie, une hausse du salaire brut ne doit jamais faire baisser le net, et une cotisation ne doit pas apparaître sous le seuil.
03Ce qu'un oracle a trouvé dans nos calculs de cotisations
Chez Moonworkers, un oracle écrit à partir des textes du HMRC, l'administration fiscale britannique, a rejoué 896 cas de cotisations. Il a trouvé quatre erreurs d'un penny. Toutes venaient d'une règle d'arrondi.
Un penny, c'est peu. Sur une fiche de paie, c'est une ligne fausse, et dans un logiciel de paie, une erreur de ce genre ne reste jamais isolée : elle se répète sur chaque salarié, chaque mois. Personne ne l'aurait vue à l'œil. Les tests existants ne la voyaient pas non plus, puisqu'ils attendaient la réponse que le code donnait déjà.
Les textes sont pourtant précis. Le manuel du HMRC sur la méthode du pourcentage exact demande de calculer séparément les cotisations salariales et patronales, et d'arrondir chacune au penny le plus proche en ignorant les montants inférieurs à 0,005 £. Une phrase de ce genre, mal traduite en code, suffit à créer un écart d'un penny sur une partie des cas.
Nous avons appliqué la même méthode aux calculateurs gratuits du site, refait en mai 2026 : chacun a été vérifié un par un contre les outils officiels avant d'être mis en ligne. C'est lent, et c'est voulu.
04Construire un oracle pas à pas
Voici la méthode que je suivrais aujourd'hui sur n'importe quel calcul qui engage de l'argent.
1. Écrire les règles à partir de la source
Listez chaque règle avec sa référence exacte : article, page, paragraphe. Les seuils, les taux, l'ordre des opérations, l'arrondi. Pour les cotisations britanniques, la page taux et seuils 2026 à 2027 du gouvernement donne par exemple un seuil principal de 242 £ par semaine et un taux salarié de 8 %, valables du 6 avril 2026 au 5 avril 2027. Notez cette période : l'oracle doit savoir quelle année il vérifie.
2. Implémenter l'oracle à part
Le plus simple possible, lisible par quelqu'un qui connaît le métier, sans optimisation. Un tableur peut suffire pour commencer. L'important est qu'il ne réutilise pas le code de production.
3. Choisir les cas
Des cas ordinaires, et surtout les bords : juste sous un seuil, pile dessus, juste au-dessus, zéro, un montant très élevé, les demi-centimes. C'est aux bords que les arrondis et les comparaisons « inférieur ou égal » se trompent.
4. Comparer et trancher chaque écart
Un écart ne dit pas qui a tort. Je reviens au texte à chaque fois. Parfois c'est l'oracle qui s'est trompé, et c'est une bonne nouvelle : la règle était ambiguë et on vient de le découvrir.
5. Brancher le tout sur chaque mise à jour
Une fois les écarts réglés, les cas deviennent des tests de non régression, relancés à chaque déploiement. C'est la même logique que la recette avant mise en production : on vérifie avant que les utilisateurs ne le fassent pour vous.
05Quand l'oracle se trompe aussi
Un oracle n'est pas la vérité. C'est une deuxième lecture du texte, et elle peut être fausse. La vidéo de Test Automation TV le dit bien : un oracle incomplet laisse passer des erreurs, un oracle faux signale comme erreurs des résultats corrects. Si la même personne écrit le code et l'oracle avec la même mauvaise lecture, les deux seront d'accord, et faux ensemble.
Il coûte aussi. Il faut le mettre à jour à chaque changement de règle, sinon il devient lui-même une source d'erreurs. Et il ne couvre que les cas qu'on lui a donnés : plusieurs centaines de cas, c'est beaucoup, ce n'est pas tout.
J'ai appris à surveiller le contrôle lui-même. Dans mes machines de contenu, des articles de test volontairement mauvais doivent toujours sortir rouges au contrôle qualité. Si l'un d'eux passe au vert après une modification des règles, ce n'est pas l'article qui s'est amélioré : c'est le contrôle qui a régressé. Un oracle mérite la même méfiance.
Enfin, pour un calcul simple et stable, un tableau de vingt cas vérifiés à la main suffit souvent. Je ne construirais pas un oracle complet pour un calcul qui ne change jamais et n'engage personne.
06Par où commencer sur votre propre calcul
Prenez le calcul qui vous ferait le plus mal s'il était faux. Retrouvez le texte qui le définit et écrivez ses règles sur une page, avec les références. Choisissez dix cas, dont cinq aux bords. Calculez la réponse attendue sans passer par votre logiciel, puis comparez.
Si vous trouvez un écart dès cette première série, vous savez où vous en êtes. Si vous n'en trouvez aucun, gardez ces dix cas : ce sont vos premiers tests de non régression. Et si la règle elle-même est floue, c'est le bon moment pour la spécifier par écrit avant d'aller plus loin.
C'est le genre de chantier que je mène en mission courte, en direct avec l'équipe, si vous voulez en parler.