Développer avec des agents IA : du cadrage aux tests sur appareil réel

Préparer le travail des agents et leurs moyens de test

Mon expérience full-stack en grands comptes sert au cadrage, aux choix d’architecture et à l’intégration. Avec Codex et Claude Code, je prépare aussi le contexte de travail et les outils qui permettront aux agents de développer, manipuler le système et vérifier leurs changements. Je garde les arbitrages produit et la décision d’accepter un résultat.

MultiPOV, Aidventures et Nomad montrent comment j’adapte cette préparation : accès à une WebView Android, CLI partageant le moteur du jeu, ou tâches réparties entre spécialistes Rust et Flutter à partir de retours d’usage.

Cadrer à l’oral, puis transmettre les décisions

Je commence dans le chat classique de ChatGPT, avec la dictée vocale. J’y exprime le besoin, je compare les approches et je précise les contraintes. Je décide du périmètre, des priorités, de l’ordre de développement et des critères d’acceptation. Ce cadrage porte aussi sur les moyens de travail : comment l’agent accédera au système, quelles actions il pourra effectuer et avec quels outils il pourra tester et valider.

Quand ces choix se stabilisent, je demande des spécifications et des instructions de transmission pour l’agent qui travaillera dans le dépôt. Elles doivent conserver les décisions et leurs raisons, les contraintes, les critères et les accès nécessaires. Si je choisis de traiter le cœur complexe avant l’interface, cette priorité doit arriver jusqu’à la tâche de développement.

À chaque transmission, je demande aussi de vérifier les recommandations officielles OpenAI pertinentes et à jour pour adapter les instructions aux outils concernés.

Cadrer le besoin et les moyens avec un agent conversationnel → transmettre les spécifications et les accès → préparer les tâches et outils de Codex ou Claude Code → exécuter, observer, diagnostiquer, corriger et retester.

Préparer les instructions, les rôles et les contrôles

Dans le dépôt, je prépare les instructions et les skills réutilisables, les rôles et les tâches délimitées. Une tâche doit indiquer ce que l’agent doit changer, le contexte utile, les contraintes et les contrôles attendus. Je précise aussi la version à tester, le parcours à exécuter, les signaux à observer et les critères d’échec.

Lorsque les tâches sont indépendantes, je peux répartir l’exploration, l’implémentation et la revue entre des rôles distincts. Je rassemble leurs résultats et tranche les désaccords. Les revues portent sur le code, mais aussi sur l’environnement et la fiabilité des outils de test : un contrôle ne sert à décider que si l’on sait ce qu’il a réellement observé.

MultiPOV : implémenter et tester sur la bonne couche

MultiPOV synchronise plusieurs points de vue vidéo. Son évolution vers Rust/WASM et Android est racontée dans l’article sur le système média.

Pour travailler sur un problème Android, je voulais que l’agent puisse reproduire le parcours sur le téléphone et identifier le build concerné. Le MCP connecté via CDP lui permet de piloter la WebView : lire le DOM, utiliser les boutons et vérifier les états de la régie. ADB complète cet accès avec l’identification de l’APK installé, les logs natifs, les captures et les enregistrements d’écran.

La boucle de travail est : implémenter → tester la WebView via MCP/CDP sur un build identifié → consulter les logs natifs via ADB si nécessaire → diagnostiquer et corriger → retester. Un état correct dans le DOM renseigne sur l’interface web ; il ne prouve pas que la vidéo native Media3/ExoPlayer est rendue correctement. Pour vérifier ce que voit l’utilisateur, il faut des observations adaptées à cette couche.

SyncBench fournit un banc pour les observations audio/vidéo et des critères explicites. Je définis les scénarios et les seuils, puis j’examine si les observations suffisent à accepter le résultat. La qualification reste attachée au scénario et à la version : VOD, live, web et Android demandent des contrôles distincts.

Corriger aussi le banc de test

Une revue du banc a révélé un faux succès possible : lorsque la mesure ne parvenait pas à observer le contenu, elle pouvait confondre cette panne avec un contenu effectivement bloqué. Le verdict doit alors être inconclusive, avec l’observation manquante signalée. Pour la synchronisation, je voulais également prendre en compte l’écart temporel afin qu’un nombre d’images apparemment acceptable ne masque pas une durée excessive.

L’agent peut examiner les règles du banc et proposer un correctif. Je garde la responsabilité du phénomène à mesurer et des critères d’acceptation. Ce cas impose de revoir l’outil de test avant de se fier à son verdict.

Aidventures : travailler d’abord sur le cœur via une CLI

Pour Aidventures, j’ai choisi de traiter d’abord le cœur complexe du jeu et de le rendre manipulable en ligne de commande. La CLI partage le moteur, la base de jeu, le lore, les fournisseurs de modèles et l’orchestrateur avec l’application web. Codex et Claude Code peuvent ainsi jouer un parcours, reprendre une session et examiner une transition d’état sans dépendre de l’interface graphique.

La boucle est : implémenter dans le cœur partagé → exécuter un parcours CLI → analyser les traces du moteur → corriger → rejouer et vérifier les régressions. Le replay relit une trace sans nouvel appel API. Les simulations et les replays ne constituent donc pas une validation des appels à un fournisseur réel. L’IA qui joue le maître de jeu appartient au produit ; les agents qui développent l’application ont un autre rôle.

Retrouver les appels LLM et les transformations d’état

Dans les parcours d’audit instrumentés, je veux pouvoir retrouver la requête envoyée au LLM et le texte brut de sa réponse, avant l’interprétation et les corrections anti-drift. Ces captures conservent les messages, le modèle, les paramètres de génération, les réponses et les erreurs d’appel. Les traces du moteur suivent les contrôles anti-drift et les changements d’état du jeu.

Si un objet manque dans l’inventaire final, l’agent peut comparer ce que le modèle a proposé, ce que l’anti-drift a accepté ou corrigé et ce que le moteur a appliqué. Il peut alors chercher l’écart dans le contexte préparé, l’appel au fournisseur, la réponse, son interprétation ou le traitement anti-drift.

Les écarts d’inventaire rencontrés en playtest ont demandé une contre-revue pour distinguer un problème d’analyse des traces d’un défaut de partage du contexte. Le diagnostic s’appuyait sur les actions et les changements d’état, puis sur des tests de régression.

L’environnement demande aussi des contrôles : un service audio ne répondait plus après un déplacement de fichiers. Le diagnostic a identifié un chemin de lancement invalide. Sa correction a été suivie d’un retest du flux audio et de l’ajout d’un contrôle des chemins à la CI. Pour ce problème, la vérification passait par l’interface et les services en fonctionnement.

Nomad : partir du besoin et des retours d’usage

Nomad répond à mon besoin de continuer à développer depuis un téléphone, avec la voix pour dicter les demandes et un Joy-Con pour piloter la machine distante. Le parcours couvre la connexion à Linux, la saisie dans les outils de développement et le retour à l’environnement habituel après déconnexion.

J’ai organisé le travail avec Claude Code autour des rôles Rust, Flutter, maintenance des patches et distribution. Chaque rôle reçoit le contexte et les contraintes de sa partie. Le socle RustDesk impose de tenir compte du projet d’origine lors des adaptations ; je garde les décisions d’intégration.

La boucle est : besoin ou retour d’usage → contexte et tâche pour le rôle concerné → implémentation → contrôles adaptés → correction et retest → revue d’intégration. Pour une modification Rust, ces contrôles comprennent les tests Rust et Clippy. Les retours d’usage restent nécessaires pour juger le parcours mobile.

Une déconnexion pouvait par exemple ramener l’écran à une orientation fixe. Je voulais restaurer l’état qui existait avant la session. Ce retour a conduit à une correction et à des tests de régression. La revue d’intégration doit ensuite vérifier la cohérence de ce comportement avec le parcours complet.

Accepter un résultat à partir des observations

Je conserve les décisions produit, la préparation du contexte, les limites des tâches et l’acceptation des résultats. Les agents peuvent implémenter, exécuter les parcours auxquels ils ont accès, diagnostiquer et retester ; je dois aussi décider si l’environnement et les outils ont permis une vérification suffisante.

Un résultat doit préciser le scénario, la version et les observations : passed lorsque les critères sont satisfaits, failed lorsqu’un écart est observé, inconclusive lorsque les observations ne permettent pas de trancher, et non applicable lorsqu’une action sort du contexte testé.