Développer avec un harnais d’IA

Le rôle du harnais

Un harnais est le programme qui donne à un modèle ses outils et organise leur exécution. Dans le cas qui nous intéresse, il permet au modèle de modifier les sources, puis de vérifier les conséquences de cette modification.

Les outils de l’éditeur ou du harnais écrivent les fichiers. WebFront fournit des opérations de contrôle des types, de compilation de l’interface, de test et d’inspection de la prévisualisation. Le modèle peut ainsi corriger une erreur à partir d’un diagnostic, puis demander une nouvelle vérification.

L’intérêt d’un environnement commun

Lorsqu’un agent travaille sur une interface native, le projet doit lui fournir les moyens de construire le programme, de piloter ses contrôles et d’interpréter les résultats. Ces moyens existent dans de nombreuses bibliothèques d’IHM, mais leur assemblage et leur adaptation restent souvent à la charge du projet.

WebFront réunit dans son environnement la compilation TSX, le contrôle des types, Jasmine et la prévisualisation. Le même callback C++ est appelé lors d’une utilisation normale et pendant le test. Une modification peut donc être accompagnée immédiatement d’un contrôle exécutable.

L’intérêt pratique est de réduire les interventions où le développeur relance une commande, lit une sortie et la retransmet à l’agent. Il dépend du projet, de ses tests et du modèle employé ; il ne constitue pas un facteur d’accélération garanti.

Cette méthode intervient dès la création d’une application, puis lors de son évolution. Les fonctions et les tests ajoutés pendant les premières itérations deviennent les éléments de travail de la maintenance et de la distribution.

Construire le lanceur

Les commandes suivantes construisent webfront-agent et le pilote webfront-wf depuis le dépôt 0.7.0, sur macOS. Sous Windows ou Linux, activez le moteur embarqué correspondant.

Le lanceur demande une archive d’environnement 0.6.3 ou ultérieure contenant l’API d’automatisation v1, ainsi qu’une empreinte SHA-512 de confiance. Cette archive peut provenir de la distribution vérifiée ou d’une construction décrite dans le guide source.

Le manifeste, le fichier de verrouillage et les dépendances du projet doivent être préparés avant de connecter l’agent. Les outils d’automatisation ne proposent ni install ni restore.

cmake -S . -B build-agent -DCMAKE_BUILD_TYPE=Release \
  -DWEBFRONT_EMBED_WKWEBVIEW=ON \
  -DWEBFRONT_BUILD_AUTOMATION=ON -DWEBFRONT_ENABLE_TESTING=ON
cmake --build build-agent --target webfront-agent webfront-wf --parallel 2

Partager une fenêtre de développement

La commande suivante ouvre une fenêtre qui reste utilisable par le développeur. Remplacez les chemins et sha512-TRUSTED_DIGEST par leurs valeurs réelles ; cette chaîne n’est pas une empreinte valide. Le répertoire de session doit être nouveau, privé et situé hors du projet.

• --serve conserve la fenêtre et son terminal ouverts.
• --listen permet à un client local de s’y attacher.
• Chaque option --allow autorise l’opération nommée.

Accordez seulement les opérations nécessaires au travail prévu. Une vérification de types et de tests ne demande pas les autorisations d’inspection ou d’interaction.

webfront-agent --project /absolute/project \
  --environment /absolute/environment.tgz --integrity sha512-TRUSTED_DIGEST \
  --allow check --allow build --allow test \
  --allow preview --allow inspect --allow interact \
  --serve --listen /absolute/private-session

Configurer le client MCP

Le lanceur expose MCP sur l’entrée et la sortie standard d’un processus local. Le client démarre ici un adaptateur qui s’attache à la fenêtre déjà ouverte. Il ne se connecte pas à un service HTTP.

L’exemple reprend la forme courante d’une configuration mcpServers. Adaptez son emplacement aux conventions de votre client et indiquez le chemin réel du binaire. Fermer le client détache l’adaptateur sans fermer la fenêtre du développeur. Le client ne peut pas élargir les permissions accordées par le propriétaire de la session.

{
  "mcpServers": {
    "webfront": {
      "command": "/absolute/build-agent/webfront-agent",
      "args": ["--attach", "/absolute/private-session", "--mcp"]
    }
  }
}

Utiliser la ligne de commande

Un harnais qui sait lancer un processus peut employer l’interface JSON en ligne de commande. L’option --schema décrit le contrat ; --agent-help fournit des instructions courtes.

Chaque commande attend son résultat final. Le statut de sortie indique notamment :

• 0 : réussite ;
• 1 : échec de l’opération ;
• 70 : échec du bootstrap ;
• 71 : expiration du délai natif.

Les commandes de construction portent sur l’interface. La compilation C++ de l’application reste à organiser dans le harnais.

webfront-agent --attach /absolute/private-session --operation check
webfront-agent --attach /absolute/private-session --operation test
webfront-agent --attach /absolute/private-session --operation preview --entry ui/main.tsx

Suivre une opération MCP

Le client dispose de quatre outils :

• webfront.session obtient les informations de session.
• webfront.start lance une opération et renvoie son identifiant runId.
• webfront.result consulte l’état et le résultat de cette opération.
• webfront.cancel demande son annulation.

L’extrait ci-dessous décrit une suite d’appels d’outils ; il ne doit pas être collé dans le JavaScript de la page. Après chaque lancement, attendez un état terminal : succeeded, failed, cancelled, timeout ou disconnected.

L’acceptation d’une requête ne signifie pas que l’opération a réussi. Les diagnostics de compilation peuvent indiquer le fichier, la ligne et la colonne ; Jasmine fournit un rapport dans report.

webfront.session({})
// Use the returned session identifier:
webfront.start({session: SESSION, operation: "check"})
// Use the returned runId; poll until a terminal state:
webfront.result({session: SESSION, runId: RUN_ID})
// For a preview after a successful build:
webfront.start({session: SESSION, operation: "preview",
               arguments: {entry: "ui/main.tsx"}})
// After completion, inspect and use the returned pageId and element IDs:
webfront.start({session: SESSION, operation: "inspect"})
webfront.start({session: SESSION, operation: "fill",
               arguments: {pageId: PAGE_ID, elementId: "quantity", value: "3"}})
webfront.start({session: SESSION, operation: "click",
               arguments: {pageId: PAGE_ID, elementId: "calculate"}})
// Operations must run sequentially; inspect again to observe the result.

Exemple : ajouter un écran de devis

Le devis du chapitre précédent peut servir de premier exercice. La demande ci-dessous précise le comportement attendu, l’emplacement du calcul et le test à produire.

Le harnais modifie les fichiers avec ses outils habituels, puis demande à WebFront de vérifier les types, de construire l’interface et d’exécuter les tests. Il peut ensuite inspecter la prévisualisation et essayer les contrôles.

Le développeur examine les sources modifiées et les assertions. Le parcours Jasmine reste dans le dépôt : il pourra être exécuté par la CI et signaler une régression ultérieure.

Add a quantity field and a Calculate button to the quotation screen.
Keep the price calculation in the existing C++ callback.
Give the controls stable IDs and show bridge failures in the UI.
Add a Jasmine journey: enter 3, calculate, expect a total of 75.
Run check, build and test; inspect the preview and try the controls.
Read each final run state. Report changes, test results and limitations.

Autres travaux adaptés à cette méthode

La correction d’une erreur TypeScript est un cas simple. Le modèle lit le diagnostic, modifie la source et relance wf check, puis les tests concernés. Le développeur n’a plus à lui recopier chaque message de compilation.

Pour un panneau de réglages, une description des champs C++ permet de générer le formulaire et les déclarations TypeScript. On peut alors demander au modèle d’ajouter les tests de bornes et de valeurs invalides.

Pour une régression fonctionnelle, on commence par reproduire le défaut dans un test Jasmine. La correction est ensuite évaluée sur ce cas et sur les tests existants. Cette démarche laisse un contrôle durable, indépendant de la conversation avec le modèle.

Étendue de l’inspection

L’opération inspect décrit les éléments visibles qui possèdent un identifiant explicite. Elle fournit des textes et libellés de taille limitée, ainsi que les erreurs observées. L’opération fill accepte les champs texte et nombre ordinaires ; click accepte notamment les boutons et les cases à cocher.

Une action doit reprendre le pageId de l’inspection. Après une navigation, cette révision devient caduque et l’action est refusée. L’inspection ne fournit ni capture d’écran, ni sélecteur arbitraire, ni arbre d’accessibilité complet. Les interactions DOM sont synthétiques.

Le terminal et l’agent ne peuvent pas exécuter simultanément des opérations incompatibles. Un observateur wf dev peut toutefois rester ouvert pendant qu’il attend une modification.

Résultats observés et limites

La qualification locale du 29 octobre 2026 a porté sur cinq modèles installés. Les 30 sources finales ont passé une vérification indépendante des types et des tests. Dans 29 conversations sur 30, le modèle a lui-même observé les deux réussites. Le rapport donne le détail des tâches et du cas incomplet. Ces observations ne sont pas une comparaison de productivité avec une autre bibliothèque d’IHM.

Le lanceur est facultatif et local. Il ne fournit ni shell, ni évaluation JavaScript libre, ni lecture arbitraire des fichiers. Le projet et ses tests exécutent néanmoins du code avec l’autorité de l’application. Pour du code inconnu, employez un environnement isolé sans secrets. Sur WKWebView et WebKitGTK, les données du navigateur ne sont pas isolées par processus.