Sans générer de texte, comment Jev pilote-t-il un navigateur et compose-t-il des interfaces ? Analyse de Browser Use et json-render

Lorsqu’on conçoit un système d’IA capable d’agir dans un navigateur, l’approche la plus intuitive consiste souvent à transmettre une capture d’écran ou le DOM à un grand modèle généraliste, à lui demander d’analyser la page et de planifier l’étape suivante, puis à lui faire générer une position de clic, un sélecteur ou un appel d’outil.

La création d’interfaces suit souvent la même logique. L’utilisateur décrit son besoin, le modèle génère directement du JSON, du JSX ou du code front-end, puis le système tente d’analyser, de valider et de rendre le résultat.

Jev Ultrafast de Browser Use et l’expérience Jev de json-render empruntent une autre voie :

Le code commence par limiter les actions possibles du modèle à un ensemble fini, et Jev ne fait que choisir dans cet ensemble.

Dans Browser Use, cet ensemble comprend les actions exécutables et les éléments interactifs de la page actuelle. Dans json-render, il comprend les composants, les configurations de propriétés, les liaisons de données et les positions de mise en page préparés à l’avance par l’application.

Jev n’a pas besoin d’écrire un plan d’action complet ni de générer tout un arbre d’interface en JSON. Il répond uniquement à des questions comme :

• La prochaine étape doit-elle être un clic, une saisie, un défilement ou une attente ?
• Sur quel élément de la page actuelle faut-il agir ?
• Quels composants doivent apparaître dans l’interface ?
• Dans quel conteneur parent, quel emplacement et quel ordre un composant doit-il être placé ?

Ces deux exemples ne montrent pas qu’« un modèle qui ne génère pas de texte sait tout faire ». Ils illustrent une autre architecture logicielle : transformer une tâche de génération ouverte en une suite de décisions contraintes et vérifiables.

Ce que Jev fait réellement ici

Jev est un modèle System One publié par TypeSafe AI. Il reçoit un state ainsi qu’un ensemble de questions typées définies par le développeur, puis renvoie des résultats structurés comme Choice, Score ou Noul, au lieu d’un long texte destiné à un lecteur humain.

On peut le voir comme une fonction de décision à sorties probabilistes :

État actuel
   ↓
Le développeur construit un ensemble fini de candidats
   ↓
Jev choisit, note ou évalue
   ↓
Le code classique valide le résultat
   ↓
Une action est exécutée ou l’interface est rendue

Dans ce schéma :

• Choice sélectionne une option parmi un ensemble fourni ;
• Score positionne le résultat sur les niveaux ordonnés définis par le développeur ;
• Noul renvoie la probabilité qu’une proposition donnée soit vraie.

L’essentiel n’est pas le format de réponse, mais la répartition des responsabilités. Jev ne génère pas librement les textes de la page, les sélecteurs du navigateur, du JavaScript ou un JSON complet ; le code conserve la maîtrise de l’état, du flux de contrôle, des autorisations et de l’exécution. TypeSafe décrit ce schéma comme « un état non structuré en entrée, des décisions probabilistes typées en sortie ». (typesafe.ai)

Voyons maintenant comment Browser Use et json-render appliquent ce principe dans des systèmes concrets.

---

Browser Use : transformer d’abord la page en un espace d’actions fini

Le projet jev-ultrafast de Browser Use présente un agent de navigation : l’utilisateur formule un objectif en langage naturel, le programme lit la page actuelle, Jev choisit l’action suivante et le code du navigateur l’exécute.

Dans la démonstration publique, la tâche consiste à rechercher sur Google Flights un vol aller simple de Zürich à London. Le projet indique un temps d’exécution enregistré d’environ 7,1 secondes, incluant les appels aux modèles, la génération de texte, l’exécution dans le navigateur, le chargement de la page et les nouvelles tentatives dues à des décisions devenues obsolètes. Il ne s’agit toutefois que d’une tâche dans une configuration de navigateur donnée, et non d’un test général de fiabilité sur n’importe quel site. (github.com)

Étape 1 : le code lit la page ; Jev ne se contente pas de « regarder une capture »

À chaque cycle de décision, le code du navigateur commence par lire les contrôles et les textes visibles sur la page, puis construit une table numérotée des éléments.

Une version simplifiée pourrait ressembler à ceci :

[1] button     Modifier le type de billet · Aller-retour
[2] combobox   D’où partez-vous ?       · San Francisco
[3] combobox   Où allez-vous ?          · vide
[4] textbox    Départ                    · vide
[5] button     Rechercher

La table contient le type de l’élément, son nom, sa valeur actuelle et son index. Le programme conserve également le véritable nœud DOM associé à chaque index afin de résoudre à nouveau la cible avant l’exécution.

Dans cet exemple, Jev ne regarde pas directement une capture pour deviner qu’un bouton se trouve aux coordonnées (482, 316). Les captures servent surtout aux démonstrations et à l’inspection humaine. Les décisions effectives s’appuient sur l’état structuré extrait du DOM. Le projet précise également que les numéros affichés sur la page sont ajoutés au moment du rendu de la capture et ne pilotent pas le navigateur. (github.com)

Cette distinction est importante.

Si un modèle génère librement des coordonnées ou un CSS Selector, il peut produire :

• un sélecteur qui n’existe pas sur la page ;
• une position d’élément déjà périmée ;
• un contrôle masqué ou impossible à cliquer ;
• un fragment de JavaScript capable d’exécuter un comportement arbitraire.

Jev Ultrafast limite au contraire le modèle aux index des éléments que le programme vient d’observer.

Étape 2 : Jev choisit l’action et l’élément cible

Le projet propose l’ensemble d’actions suivant :

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

En fonction de l’état actuel de la page, le programme ne propose que les actions et les cibles compatibles réellement disponibles à cet instant.

Par exemple :

• si la page ne contient aucune liste déroulante, aucune cible pour SELECT n’est proposée ;
• si elle comporte trois champs de texte, les cibles de saisie sont limitées à ces trois éléments ;
• si elle comporte dix éléments cliquables, les cibles de clic sont limitées à ces dix éléments.

Une décision peut être simplifiée ainsi :

Question 1 : Quelle doit être la prochaine action ?
Candidats : CLICK / TYPE_TEXT / SELECT / WAIT / DONE

Question 2 : Si l’action est CLICK, sur quel élément faut-il cliquer ?
Candidats : [1] / [5] / [8] / [11]

Question 3 : Si l’action est TYPE_TEXT, quel élément doit recevoir le texte ?
Candidats : [2] / [3] / [4]

Ces questions peuvent être évaluées en parallèle dans une seule requête. Seule la cible compatible avec l’action sélectionnée est exécutée. Si Jev choisit CLICK, le programme ne lit que click_target ; il n’exécute pas une cible calculée à l’avance pour TYPE_TEXT.

Le projet appelle cela un espace d’actions dynamique et indexé. Cette approche réduit le nombre d’appels séquentiels au modèle nécessaires à chaque étape et évite de lui demander de générer librement les paramètres de l’opération. (github.com)

Étape 3 : appeler un modèle génératif uniquement lorsqu’il faut écrire du texte

Jev peut décider qu’il faut maintenant saisir une valeur dans le champ de départ, mais il ne génère pas le texte à saisir.

Lorsque l’action est TYPE_TEXT, le système appelle un petit modèle de génération de texte qui produit la valeur à partir de la tâche en cours et du champ cible. Par exemple :

{
  "text": "Zürich"
}

Le résultat doit encore être analysé comme un très petit objet JSON avant que le navigateur puisse le saisir.

L’agent de navigation combine donc deux capacités différentes :

Tâche	Composant responsable
Décider si l’étape suivante est un clic, une saisie, une sélection ou une attente	Jev
Choisir l’élément de la page sur lequel agir	Jev
Générer le texte en langage naturel à saisir	Petit modèle génératif
Lire le DOM et l’état de la page	Code du navigateur
Cliquer, saisir et sélectionner	Code du navigateur
Vérifier que l’objectif a réellement été atteint	Code de validation indépendant

Cela montre aussi que « Jev pilote le navigateur » ne signifie pas que Jev accomplit seul toute la tâche.

Une description plus précise serait : Jev est le sélecteur d’actions dans la boucle du navigateur.

Étape 4 : le code vérifie à nouveau la page avant l’exécution

Une fois le choix effectué par le modèle, le programme ne clique pas aveuglément.

Avant l’exécution, Jev Ultrafast vérifie également :

• si la page actuelle est toujours celle que le modèle a observée ;
• si le nœud DOM correspondant existe encore ;
• si l’élément est masqué par un autre contenu ;
• si sa géométrie actuelle est toujours valide ;
• si la valeur du formulaire et le contexte proche correspondent encore à l’instantané ;
• si l’entrée utilisée pour la demande de génération de texte a changé.

Si la page change avant le retour du modèle, la décision précédente peut déjà être invalide. Le programme la considère comme obsolète au lieu de continuer à agir sur un ancien élément.

Le projet limite explicitement ce que peut devenir la sortie du modèle : elle n’est pas directement convertie en CSS Selector, en coordonnées d’écran, en commande shell ou en JavaScript exécutable. Toute cible exécutée doit être résolue de nouveau vers un véritable nœud DOM précédemment observé. (github.com)

Ce code n’est pas « intelligent », mais il détermine la fiabilité du système.

Le résultat en sept secondes ne peut pas être attribué à Jev seul

Sur six exécutions alternées, le projet rapporte que les deux implémentations ont chacune terminé la tâche trois fois. Le temps médian est passé d’environ 9,450 secondes à 7,092 secondes, soit une baisse proche de 25 % ; le nombre d’appels au protocole du navigateur est passé de 1 092 à 101. L’auteur souligne également qu’il ne s’agissait que de trois essais par implémentation sur la même tâche et dans la même configuration, et non d’un test général de fiabilité. (github.com)

Le gain de performance ne vient donc pas seulement de la vitesse du modèle, mais de l’ensemble de l’implémentation du navigateur :

• lecture des contrôles visibles en une seule passe ;
• réduction des allers-retours avec le protocole du navigateur ;
• regroupement des questions sur l’action et la cible dans une même décision ;
• appel du modèle génératif uniquement lorsqu’une saisie de texte est nécessaire ;
• attente limitée aux changements de page nécessaires après l’exécution ;
• exclusion du texte sans rapport de la page du contexte du modèle.

Il serait donc incorrect de conclure que le simple remplacement d’un modèle par Jev permet à tout agent de navigateur de finir sa tâche en sept secondes.

Le MVP actuel ne prend pas non plus entièrement en charge le shadow DOM, les iframe, les canvas, le téléversement de fichiers, les onglets contextuels, le défilement imbriqué et les widgets clavier arbitraires. Même lorsque le modèle choisit DONE, le système exige toujours une vérification indépendante de l’achèvement réel de la tâche. (github.com)

---

json-render : laisser Jev choisir des composants au lieu de générer tout le JSON de la page

json-render traite un autre problème : comment composer, à partir d’une demande en langage naturel, une interface directement rendable.

Les systèmes d’interface générative traditionnels demandent souvent au modèle de produire directement :

• du code React ou Vue ;
• un arbre d’interface complet en JSON ;
• du CSS et des propriétés de mise en page ;
• une logique de gestion des événements ;
• une configuration de liaison des données.

Cette méthode est flexible, mais elle offre au modèle un espace de sortie immense. Il peut mal orthographier le nom d’un composant, générer une propriété inexistante, référencer une action non enregistrée ou produire un JSON impossible à analyser.

L’expérience Jev de json-render reformule la tâche :

L’application prépare d’abord un ensemble d’instances de composants valides, puis Jev décide uniquement lesquelles utiliser et comment les combiner.

Cette fonctionnalité est toujours signalée comme expérimentale. experimental_composeSpec et experimental_createEvaluator ne sont pas encore publiées comme API stables ; leurs noms et leur comportement peuvent changer d’une version à l’autre. La documentation recommande de verrouiller une version précise et de vérifier le journal des modifications. (json-render.dev)

L’application fournit d’abord le catalogue de composants et les candidats

Supposons que l’utilisateur demande :

Créez un tableau de bord des ventes avec une table de commandes en haut, une rangée d’indicateurs de chiffre d’affaires, de nombre de commandes et de nouveaux clients en dessous, puis un graphique du chiffre d’affaires hebdomadaire en bas.

L’application ne transmet pas directement cette phrase à Jev en lui demandant d’écrire librement le JSON de l’interface.

Elle fournit d’abord des candidats :

Dashboard
OrdersTable
MetricRow
RevenueMetric
OrdersMetric
NewCustomersMetric
RevenueBarGraph

Chaque candidat n’est pas qu’un simple nom : c’est une instance de composant configurée par l’application, pouvant inclure :

• le type de composant ;
• des propriétés fixes ;
• les configurations de mise en page disponibles ;
• les liaisons d’état ;
• les liaisons de données ;
• les actions autorisées ;
• une description du candidat destinée au modèle.

Par exemple, un bouton candidat peut être prédéfini ainsi :

Composant : Button
Texte : Enregistrer
Action : savePreferences
Arguments : lire l’état actuel de /name

Jev peut décider d’utiliser ou non ce bouton, mais ne peut pas inventer une action non enregistrée comme deleteAllUsers.

La documentation de json-render insiste sur le fait que la plateforme contrôle les capacités disponibles et le système de design. Jev ne peut choisir que parmi les composants, configurations et liaisons d’actions fournis par l’application ; les textes, données ou composants absents ne sont pas créés automatiquement par Jev. (json-render.dev)

Phase 1 : choisir les composants nécessaires à l’interface

Lors de la création d’une nouvelle interface, le premier lot de décisions porte sur :

• le candidat qui devient le nœud racine ;
• les composants à sélectionner ;
• le nombre d’instances nécessaires d’un composant réutilisable ;
• la variante à choisir lorsqu’une même ressource en possède plusieurs.

Par exemple :

Composant racine : Dashboard

Inclure :
- OrdersTable
- MetricRow
- RevenueMetric
- OrdersMetric
- NewCustomersMetric
- RevenueBarGraph

Une fois ces choix effectués, le code classique assemble immédiatement un premier Spec, vérifie les propriétés des composants et les arguments des actions par rapport au schéma du catalogue, puis diffuse un aperçu déjà rendable.

À ce stade, la disposition peut encore suivre l’ordre du catalogue, mais l’utilisateur voit déjà un résultat intermédiaire structurellement valide.

Cette méthode diffère d’un modèle qui émettrait le JSON complet token par token : Jev n’écrit pas de JSON sérialisé. Le code assemble le JSON à partir de choix contraints. (json-render.dev)

Phase 2 : décider des relations parent-enfant et de l’ordre

Une fois les composants sélectionnés, un deuxième lot de décisions traite la mise en page :

• le parent auquel appartient chaque composant ;
• l’emplacement nommé du parent dans lequel il doit être placé ;
• l’ordre des composants frères.

La structure finale peut ressembler à ceci :

Dashboard
├── OrdersTable
├── MetricRow
│   ├── RevenueMetric
│   ├── OrdersMetric
│   └── NewCustomersMetric
└── RevenueBarGraph

Le code vérifie ensuite :

• qu’il existe exactement une racine valide ;
• qu’aucun cycle parent-enfant n’a été introduit ;
• que la profondeur ne dépasse pas la limite ;
• que chaque composant est placé dans un emplacement valide ;
• que chaque candidat est utilisé le nombre de fois autorisé ;
• que toutes les propriétés, liaisons et arguments d’actions respectent le schéma.

Si la disposition composée est incohérente, le système conserve l’aperçu précédemment validé au lieu de produire un arbre d’interface cassé.

Pour les structures simples avec une seule racine, ou un seul enfant dans un unique emplacement, la seconde évaluation de la mise en page peut même être inutile. (json-render.dev)

Modifier une interface reste une sélection, pas une réécriture complète

json-render peut également modifier un Spec existant, par exemple :

• supprimer le bouton Enregistrer ;
• déplacer la table des commandes au-dessus du graphique ;
• remplacer un type de graphique par un autre candidat fourni ;
• modifier l’ordre des champs ;
• remplacer la configuration d’un composant.

Ces modifications suivent généralement un protocole séquentiel :

1. Sélectionner l’élément à modifier.
2. Sélectionner la nouvelle recette de composant ou la destination.
3. Appliquer la modification dans le code.
4. Valider à nouveau l’ensemble de l’arbre.

Les identifiants des composants non modifiés, les liaisons d’état, les données et les enfants compatibles sont préservés autant que possible. Le Spec d’entrée n’est pas modifié directement. (json-render.dev)

Sélectionner un bouton ne signifie pas qu’il s’exécute automatiquement

json-render sépare clairement « composer l’interface » et « exécuter une action métier ».

Jev peut sélectionner un bouton lié à savePreferences, mais le composer n’appelle pas lui-même cette action. L’exécution ne se produit qu’après le clic de l’utilisateur et elle est prise en charge par l’action handler de l’application hôte.

L’application doit toujours assurer :

• la vérification des autorisations de l’utilisateur ;
• la validation des arguments ;
• l’autorisation côté serveur ;
• la validation des données ;
• l’idempotence et la journalisation d’audit ;
• une confirmation supplémentaire pour les opérations dangereuses.

La documentation avertit expressément qu’enregistrer une action dans le catalogue ne la rend pas sûre face à des arguments arbitraires. Le composer ne peut pas non plus vérifier l’état futur au moment de l’exécution ni assurer l’autorisation à la place de l’application. (json-render.dev)

Une structure valide ne garantit pas une interface correcte

json-render peut garantir que la sortie respecte sa structure et son schéma, mais pas que l’interface choisie par Jev soit complète, cohérente ou visuellement réussie.

La documentation donne cet exemple :

Générez un tableau de bord avec la table en haut

Cette demande peut ne sélectionner qu’une table, puisqu’elle ne réclame pas explicitement d’indicateurs ni de graphique.

Une demande plus précise :

Créez un tableau de bord des ventes :
placez la table des commandes en haut ;
placez en dessous une rangée d’indicateurs de chiffre d’affaires, de commandes et de nouveaux clients ;
placez enfin le graphique du chiffre d’affaires hebdomadaire.

a davantage de chances de sélectionner tous les candidats requis et de les ordonner comme prévu.

Cela met en évidence une limite essentielle : Jev ne décide qu’à l’intérieur de l’espace des candidats, tandis que les développeurs restent responsables de la complétude de cet espace et de la clarté de la demande.

L’API réutilisable décrite dans la documentation publique limite par défaut le processus à 32 évaluations, 32 éléments créés par lot et une profondeur maximale de 8. Le Playground public réduit encore ces limites à 14 éléments par lot, 14 évaluations et une profondeur de 4. Lorsqu’une limite d’appels, d’éléments ou de profondeur est atteinte, le système peut renvoyer un Spec partiel, mais « le processus est terminé » ne signifie toujours pas que le résultat est sémantiquement correct. (json-render.dev)

---

Les deux exemples utilisent en réalité la même architecture

Mis côte à côte, Browser Use et json-render résolvent des problèmes différents avec une structure presque identique.

Étape	Browser Use	json-render
Objectif de l’utilisateur	Rechercher un vol, remplir un formulaire, ouvrir une page	Créer ou modifier une interface
État lu par le code	DOM visible, contrôles, textes et valeurs	Spec actuel, candidats de composants, catalogue et structure de l’arbre
Espace fini de candidats	Clic, saisie, sélection, défilement et éléments interactifs	Instances de composants, parents, emplacements et ordre
Responsabilité de Jev	Sélectionner l’action et la cible	Sélectionner les composants, les relations parent-enfant et l’ordre
Responsabilité du modèle génératif	Générer du texte uniquement lorsqu’une saisie est nécessaire	Dans le parcours Jev, il ne génère pas librement l’interface ; les nouveaux textes et données doivent être fournis à l’avance ou générés séparément
Responsabilité du code classique	Instantanés du DOM, vérification de fraîcheur, exécution, attente et validation du résultat	Assemblage du Spec, validation du schéma, validation de l’arbre, rendu et autorisation des actions
Principaux modes d’échec	État de page obsolète, cible absente, contrôle non pris en charge	Candidats manquants, demande ambiguë, mise en page incomplète, mauvais choix
Vérification finale	Vérifier si l’objectif de la tâche a réellement été atteint	Vérifier si le Spec est complet, utilisable et conforme aux exigences du produit

Les deux suivent la même formule :

Transformer l’environnement en état structuré
        ↓
Transformer les actions disponibles en un ensemble fini de candidats
        ↓
Laisser Jev choisir
        ↓
Laisser le code valider et exécuter
        ↓
Observer à nouveau le résultat

Par rapport à la génération libre de l’étape suivante, cette approche abandonne une partie de la souplesse en échange de limites de contrôle plus claires.

---

Pourquoi un modèle qui ne génère pas de texte peut tout de même paraître « intelligent »

L’intelligence n’a pas besoin de s’exprimer sous la forme d’un article, d’un programme ou d’une conversation.

Dans de nombreux flux logiciels, le système a seulement besoin d’une décision :

• Sur quel bouton faut-il cliquer maintenant ?
• Dans quelle zone cet élément doit-il être placé ?
• L’exécution doit-elle continuer ?
• Quelle configuration de composant correspond le mieux à la demande de l’utilisateur ?
• Le résultat actuel a-t-il atteint l’objectif ?

Un LLM généraliste peut d’abord produire une explication, puis encapsuler sa réponse dans du JSON. Mais si le code n’a finalement besoin que d’une option, une grande partie de cette génération intermédiaire peut être inutile.

Les expériences Browser Use et json-render déplacent davantage le « processus de réflexion » vers la conception du système :

• le développeur définit l’état ;
• le développeur définit l’espace des candidats ;
• le développeur définit les règles d’exécution ;
• le modèle ne comble que les lacunes de décision sémantique difficiles à couvrir par des règles classiques.

Cette architecture ne supprime pas les erreurs ; elle en change la forme.

Jev ne renverra pas de composant ou d’action hors de l’ensemble des candidats, mais il peut encore :

• choisir le mauvais bouton ;
• choisir le mauvais composant ;
• déclarer la tâche terminée trop tôt ;
• sélectionner une moins bonne disposition parmi plusieurs options raisonnables ;
• omettre un contenu nécessaire parce que la demande est ambiguë.

La sûreté de typage garantit l’interface, pas la vérité. Le rapport de recherche fourni souligne lui aussi qu’une structure contrainte ne garantit pas une décision métier correcte ; la conception des questions, la modélisation de l’état, les seuils et la validation indépendante restent essentiels en production.

---

Quelles tâches se prêtent à ce modèle

Browser Use et json-render fournissent un critère pratique :

Si une tâche peut être décomposée en « choisir parmi un ensemble fini de candidats », il peut être pertinent de confier ce nœud de décision à Jev.

Parmi les tâches relativement adaptées :

• la sélection d’actions dans les navigateurs et les applications de bureau ;
• le routage des outils et compétences d’un agent ;
• la composition d’une interface à partir d’un catalogue contrôlé de composants ;
• le choix entre plusieurs mises en page candidates ;
• la classification d’e-mails, de tickets d’assistance et de documents ;
• la sélection de contenu pertinent parmi des éléments de preuve candidats ;
• la décision de réessayer ou de transférer le résultat à un humain.

Les tâches suivantes ne doivent pas être confiées directement à Jev :

• rédiger de longs articles ou des réponses de support ;
• générer un nouveau texte absent de l’ensemble des candidats ;
• concevoir librement un système visuel entièrement nouveau ;
• écrire des programmes complexes ;
• effectuer des calculs arithmétiques ou de dates en plusieurs étapes ;
• inventer une solution lorsqu’aucune action candidate n’existe ;
• réaliser des tâches nécessitant un long raisonnement et une planification ouverte.

Les produits réels ont généralement besoin d’une combinaison de modèles :

Modèle généraliste : générer des objectifs, du texte, du code ou des plans candidats
Jev : évaluer, filtrer et router les candidats
Code classique : valider, exécuter, appliquer un repli et journaliser

Le petit modèle de texte utilisé dans Browser Use illustre directement cette répartition : Jev décide qu’un texte doit être saisi ; le modèle génératif décide quel texte saisir.

---

La véritable leçon est la séparation des responsabilités, pas les deux démonstrations

La leçon la plus réutilisable de Browser Use et json-render n’est pas que « Jev sait naviguer sur le Web » ou que « Jev sait générer une interface ».

Une conclusion plus exacte est la suivante :

• Browser Use transforme une génération libre d’actions de navigation en sélection d’actions sur de véritables éléments DOM ;
• json-render transforme l’écriture libre d’un JSON d’interface en sélection et en ordonnancement dans le propre catalogue de composants de l’application ;
• Jev fournit les décisions sémantiques ;
• le code limite les autorisations, maintient l’état, valide la structure et exécute le résultat ;
• lorsqu’un texte ouvert est nécessaire, un modèle génératif continue de le produire.

Cette architecture fait passer l’IA du rôle d’unique conducteur du système à celui d’un nœud de décision au sein d’un flux contrôlé par le code.

Pour les équipes qui souhaitent réellement intégrer l’IA à un logiciel de production, cela peut être plus important que la capacité d’un modèle à générer une réponse complète en une seule fois. La fiabilité du système dépend finalement non seulement du choix du modèle, mais aussi de :

• l’état présenté au modèle ;
• les candidats fournis par le développeur ;
• les actions autorisées par le système ;
• la possibilité d’intercepter les résultats erronés ;
• la capacité de réévaluer après une modification de la page ou de l’interface ;
• la vérification indépendante de l’achèvement.

Ne pas générer de texte ne signifie pas que Jev ne sait rien faire.

Cela signifie que l’intelligence du modèle s’exprime principalement non sous la forme d’une chaîne de caractères, mais sous celle d’un ensemble de choix que le logiciel peut consommer directement — et doit tout de même valider avec soin.