Une suite de tests de régression est une affirmation sur ce que vous savez déjà. Chaque scénario qu'elle contient existe parce que quelqu'un y a pensé un jour, l'a écrit et l'a jugé important. C'est sa force : c'est un contrat, elle tourne sans surveillance et elle tient devant un audit. C'est aussi sa limite. La suite ne trouvera jamais ce à quoi personne n'a pensé, et c'est précisément de là que vient une part tenace des incidents en production.
La suite de tests ne bouge pas
Notre position sur l’automatisation des tests n’a pas changé et ne changera pas. Une suite de tests portée par un framework, avec des scénarios écrits en Gherkin pour que le métier lise la phrase que l’ingénieur automatise, qui tourne sans surveillance à chaque étape vers la mise en production. Nous avons déjà écrit sur la différence entre cela et une case cochée dans un tableur, et cela reste le plus grand levier sur la capacité d’un logiciel à tenir sa valeur sur cinq ans.
Ce qui suit s’adresse à qui possède déjà une suite de régression et se demande ce que les modèles y changent. Sans cette base systématique, l’exploration trouve quand même des choses. Elle n’a simplement nulle part où les poser. Un défaut est corrigé une fois, rien ne l’empêche de revenir, et le test devient quelque chose que l’on rapporte plutôt que quelque chose que l’on possède.
Décrire ce qu’une fonctionnalité sait faire est un travail d’écriture
Avant de pouvoir tester quoi que ce soit, il faut que quelqu’un dise ce dont une fonctionnalité est capable. Les entrées qu’elle accepte et leurs limites, quel rôle a le droit de faire quoi, chaque langue et chaque taux de TVA qu’elle doit traiter. Les états dans lesquels une commande ou un dossier patient peut se trouver, et les sauts entre eux qui sont censés être impossibles. Fait correctement, c’est un travail lent, et dans beaucoup d’équipes il se fait en fin de sprint, donc mal.
Cette partie relève de l’écriture, et les petits modèles rapides y excellent. Nous les utilisons pour cela de façon courante : lister les dimensions d’une fonctionnalité, produire les cas limites, croiser la matrice des droits avec la machine à états, et remettre à un humain une liste à élaguer plutôt qu’une page blanche. Le modèle est généreux et parfois ridicule, l’ingénieur en raye deux tiers, et ce qui reste couvre plus de cas que ce que la même personne aurait écrit seule dans la même heure. Il en va de même pour l’entretien de la suite : maintenir les sélecteurs en vie à travers une refonte, porter un scénario dans trois langues, ou dire lesquels des quarante échecs d’un pipeline rouge partagent une cause.
C’est l’essentiel de ce que nous voulons dire par l’IA achète de la vitesse, pas une autorisation. La suite est devenue plus grande et moins chère à entretenir, et la description de départ est plus complète. Ni l’une ni l’autre ne remplace le fait d’aller voir.
Parcourir chaque chemin est un travail de jugement
Le test exploratoire est la discipline qui consiste à aller chercher le non spécifié : quelqu’un qui connaît le produit manipule l’application, se forme une intuition, suit ce qui paraît bizarre, et reconnaît un écran fautif alors qu’aucune assertion ne le dit. Dans notre expérience, il remonte une classe de défauts que la suite ne cherche pas, pour une raison simple : la suite ne connaît que ce qui a déjà été écrit.
Nous utilisons déjà de petits modèles pour cela, et cela fonctionne. On peut demander à un modèle bon marché si un écran a l’air cassé, si un chemin a déjà été couvert, si un message d’erreur est un vrai défaut ou la validation qui fait son travail. Il ne fatigue pas au bout de 90 minutes, et il ne saute pas le coin ennuyeux du tableau.
Ce qu’il ne fait pas, c’est venir gratuitement. Chacune de ces questions est une réponse écrite : des tokens en sortie, une seconde d’attente, et une ligne sur la facture. La gamme bon marché l’est réellement aujourd’hui, et elle dépasse un seul fournisseur :
- La famille Claude Haiku : les petits modèles rapides de l’offre Anthropic.
- La famille Gemini Flash-Lite : la gamme grand volume de Google.
- Des modèles ouverts, hébergés chez vous en Suisse : Llama, Mistral, Qwen, Gemma. C’est la meilleure protection possible pour votre propriété intellectuelle, parce que rien ne quitte votre infrastructure.
N’importe laquelle est confortable à quelques centaines de décisions par campagne. À quelques centaines de milliers, et c’est l’ordre de grandeur d’une exploration sérieuse sur une grande application, l’attente devient le facteur limitant bien avant la facture. L’exploration reste donc rationnée : plus large qu’avant, mais rationnée.
Un modèle qui renonce à écrire
En septembre 2026, TypeSafe AI a publié Jev, le premier d’une famille que l’entreprise appelle les modèles System One, en référence au mode de pensée rapide et intuitif décrit par Kahneman. L’échange est inhabituel : le modèle renonce entièrement à écrire, et ne peut produire ni phrase, ni test, ni justification. Ce qu’il renvoie est une valeur typée accompagnée d’une confiance calibrée, en une seule passe.
Trois formes couvrent l’essentiel : une probabilité pour une question par oui ou non, une répartition sur des options définies à l’avance, jusqu’à 255, pour un choix multiple, et une valeur pondérée sur une échelle que vous fixez pour une notation. Comme rien n’est écrit, l’ensemble arrive en 70 à 500 millisecondes, et le coût des tokens produits disparaît entièrement. Face à la gamme d’écriture bon marché, c’est un autre ordre de grandeur, pas une remise.
Jev n’est pas seul dans cette forme : Laya a exploré la même idée en 2025 comme modèle ouvert et va encore plus vite, et quelques cousins ouverts sont apparus depuis. La catégorie compte davantage que le fournisseur, ce qui tombe bien, car Jev est derrière une liste d’attente.
Où se place un modèle de décision
Un modèle de décision ne peut rien explorer par lui-même. Ce qu’il fait, c’est répondre aux questions de jugement qu’une campagne d’exploration produit, et la structure de cette campagne reste la même, que le jugement revienne à un petit modèle d’écriture ou à un modèle de décision.
- 1 Suite de régression Ce qui est déjà spécifié tourne sans surveillance à chaque étape vers la mise en production. C'est le point de départ, et il ne bouge pas. déterministe
- 2 Exploration Un robot énumère les actions atteignables depuis l'état courant. Aucun modèle n'agit à sa place : il ne peut ni cliquer, ni taper, ni naviguer. déterministe
- 3 Modèle de décision Quel candidat mérite d'être pris, cet écran a-t-il déjà été vu, quelque chose y paraît-il fautif. Une valeur typée en réponse, pas une phrase. modèle de décision
- 4 Validation déterministe ou humaine Un contrôle déterministe ou une personne confirme la découverte avant qu'elle ne devienne un rapport de bug. Le modèle propose où regarder, il ne décide jamais de ce qui est vrai. déterministe ou humain
- 5 Nouveau test de régression Un modèle d'écriture rédige les étapes de reproduction et le scénario Gherkin, une fois que quelque chose a effectivement été trouvé. modèle d'écriture
C’est la boucle que nous faisons tourner aujourd’hui. Confier ce jugement à un modèle de décision ne change pas sa forme. Cela change ce que coûte une étape, et le coût par étape décide de deux choses. La première est la part de l’application qu’une campagne peut se permettre de parcourir. La seconde est la vitesse à laquelle le verdict revient, et c’est la moitié que l’exploitation ressent réellement. Chez un client, une vérification rapide parcourt les dix parcours utilisateur que la modification peut avoir touchés, sur l’environnement de test, et revient pendant que le développeur a encore son changement en tête. Ce qu’elle attrape le plus souvent, ce sont des fonctionnalités cassées par effet de bord : quelque chose d’adjacent au changement, que personne n’avait pensé à rouvrir. La suite complète tourne toujours et le confirme plus tard, souvent après que le correctif est déjà posé. Un article récent intègre Jev et Laya à exactement quatre points de ce type dans un harnais de test d’intrusion open source et rapporte des latences de décision d’environ 250 millisecondes pour Jev et 35 pour Laya. Les auteurs précisent qu’il s’agissait d’une seule campagne contre une seule cible : une proposition de conception accompagnée d’observations, et nous la lisons ainsi.
Une technique mérite d’être reprise quel que soit le modèle : ces modèles sont bien meilleurs pour les jugements relatifs que pour les jugements absolus. Ne demandez pas une note pour chaque action candidate. Donnez-les par lots et faites une seconde passe sur les gagnants.
Ce qui sort réellement de la maison
Envoyer quoi que ce soit à un modèle que l’on n’exploite pas soi-même est une question à poser à voix haute, en particulier pour des clients qui répondent devant un régulateur. Pour cette boucle, la réponse est confortable.
Ce qui part est petit et ennuyeux. Une empreinte de l’écran courant, une liste d’actions candidates et une question étroite à leur sujet. Aucun document, aucun enregistrement, aucun historique. Et cela vise un environnement de test : patients inventés, commandes inventées, personnes inventées. La base de production n’est jamais dans la boucle, puisque tout l’intérêt est de tourner avant que de vraies personnes s’y trouvent. Ce que renvoie un modèle de décision est un nombre, et un nombre ne peut rien divulguer qu’on ne lui ait donné.
Là où un client a besoin de plus, les options sont bonnes aujourd’hui : un modèle ouvert hébergé chez soi, vers lequel nous allons quand l’enjeu est la propriété intellectuelle, ou un point d’accès suisse comme Infomaniak, qui sert les mêmes modèles ouverts depuis des centres de données ici, ne garde aucune trace des requêtes et opère sous la LPD et le RGPD. C’est le même raisonnement de juridiction qui décide déjà où nous exploitons les plateformes de nos clients : pas de données clients dans des modèles publics sans consentement explicite, et un point d’accès suisse ou européen quand le travail l’exige.
Ce qui nous enthousiasme
Le jugement était l’intrant cher, et c’est exactement ce qu’un modèle de décision change : un ordre de grandeur, pas une marge.
Nous n’avons pas fait tourner Jev. Il a quelques jours, il est derrière une liste d’attente, et il ne prend pas encore d’images : une campagne doit donc travailler à partir de la structure de la page. Sa propre documentation range les nombres, les dates et les entrées hostiles dans la colonne des faiblesses. Rien de cela n’entame beaucoup l’intérêt. Jev est la première réponse crédible à la moitié du test qui n’a jamais baissé de prix, et nous l’essaierons d’abord sur nos propres applications, à côté d’une suite qui passe déjà. La barre n’est pas une démo impressionnante. Elle est de trouver deux fois quelque chose que la suite a manqué, sans nous enterrer sous les faux positifs. Nous dirons ce qu’il en ressort, dans un sens comme dans l’autre.
Deux problèmes, deux types de modèle
La suite de tests reste le capital. Rien ici ne sort un scénario de Gherkin, et rien ici ne change ce qui doit être au vert avant une mise en production.
Ce qui a changé, c'est que décrire ce qu'une fonctionnalité sait faire et parcourir tout cela sont deux problèmes distincts. Décrire relève de l'écriture, et les petits modèles rapides s'en sortent assez bien aujourd'hui pour que nous ne partions plus d'une page blanche. Parcourir relève du jugement, un appel après l'autre, des milliers de fois. Le jugement est la part restée chère.
Garder la suite à jour et les campagnes d'exploration bon marché est chez nous une tâche permanente, pas un projet. Les modèles de décision sont la nouveauté la plus intéressante sur cette seconde moitié depuis des années, et nous les suivons de près.
