Préparer une application que votre agent de programmation peut utiliser

Une équipe demande à une IA d’ajouter une fonction de téléchargement à son logiciel de suivi des interventions. La responsable des opérations veut récupérer la liste des interventions terminées dans le mois sous forme de fichier CSV à ouvrir dans Excel. La demande est claire, mais la copie de travail n’a ni base de données initialisée ni compte permettant à l’IA de se connecter.

L’IA cherche les instructions de démarrage, essaie des commandes et s’arrête avant de pouvoir tester le bouton. Reformuler la demande ne réglerait pas ces problèmes. L’équipe doit d’abord préparer les outils et les données nécessaires.

Les développeurs utilisent parfois le terme anglais harness pour désigner cet environnement de travail : les consignes, les commandes, les accès et les moyens de reprendre une tâche qui accompagnent le modèle d’IA. Cet ensemble peut rester simple. Son utilité dépend de ce qu’il permet réellement à l’agent de faire.

Fournir un point de départ clair

Au début d’une nouvelle session, l’IA doit retrouver la demande en cours et les règles de l’application. Dans cet exemple, elle doit savoir ce qui définit une intervention terminée et respecter la séparation des dossiers des entreprises clientes. Le cahier des charges de la fonctionnalité rassemble ces décisions.

L’équipe peut conserver un court guide de démarrage avec le code source. Ce guide renvoie aux règles, explique comment lancer l’application, énumère les vérifications à effectuer et précise quand demander de l’aide. Les décisions détaillées restent dans leurs documents habituels, avec le nom de la personne responsable et une indication claire de ce qui a été approuvé.

Évitez les contradictions entre les anciennes et les nouvelles consignes. Une note proposant de modifier une règle ne doit pas être présentée comme une décision approuvée. De même, le texte d’un billet de suivi ou d’une page externe ne doit pas accorder de nouveaux droits à l’outil.

Préparer une copie qui démarre de façon fiable

L’IA a besoin d’une version connue de l’application, des composants nécessaires à son fonctionnement et de données d’essai. Pour cet exemple, préparez des entreprises fictives, des comptes ayant des droits différents et des interventions à différents stades de traitement.

Essayez la procédure à partir d’une installation neuve. Si un collègue doit créer une table manquante dans la base de données ou ajouter un paramètre non documenté, consignez l’étape afin de pouvoir la reproduire. L’équipe pourra ainsi distinguer un défaut du code proposé d’un problème d’installation.

Les accès doivent aussi être configurés. Placer une copie de travail dans un dossier distinct ne suffit pas si elle conserve les identifiants d’accès au système utilisé par les clients. L’article sur les droits d’accès explique comment limiter les fichiers, les données et les connexions à ce que la tâche exige.

Produire des messages d’erreur utiles

Un résultat qui indique seulement « échec » oblige à chercher quelle opération a été tentée. Un message utile peut préciser : « Le compte de l’entreprise A a téléchargé une intervention appartenant à l’entreprise B. » Il indique aussi la version du logiciel et les données fictives utilisées.

L’équipe et l’IA peuvent alors chercher pourquoi le filtre limitant les données à l’entreprise concernée n’a pas été appliqué. Elles doivent pouvoir reproduire l’erreur et comparer le fichier obtenu au fichier attendu. Si le problème concerne l’interface, la version d’essai doit aussi leur permettre d’ouvrir l’écran et d’utiliser le bouton.

Les journaux de test n’ont pas besoin de contenir de vrais dossiers clients. Conservez les renseignements nécessaires au diagnostic, avec des droits d’accès et une durée de conservation adaptés.

Préparer la reprise après la fin d’une session

Une tâche peut s’étendre sur plusieurs sessions d’IA. À la fin de chaque session, une courte note peut indiquer les fichiers modifiés, la version actuelle, les vérifications terminées et le travail restant. Elle peut, par exemple, préciser que le téléchargement avec un compte autorisé fonctionne, mais qu’une tentative avec un autre compte reste à tester.

Les travaux d’Anthropic sur les agents qui exécutent des tâches de longue durée décrivent l’utilisation de notes d’avancement pour assurer cette continuité. Au début de la session suivante, l’IA doit tout de même comparer la note aux fichiers et aux résultats disponibles. Le code peut avoir changé entre-temps.

Corriger un obstacle observé, puis mesurer l’effet

Pendant un essai, notez ce qui a fait perdre du temps à l’IA : retrouver une règle, démarrer l’application, comprendre une erreur ou reprendre le travail. Corrigez l’obstacle observé, puis recommencez avec une tâche comparable. Tenez compte des nouvelles tentatives et du temps consacré à l’examen humain du travail.

Le retour d’expérience d’OpenAI sur les environnements des agents de programmation et celui d’Anthropic sur les tâches de développement de longue durée proposent des pistes de conception. Ils décrivent les situations de leurs auteurs; votre équipe doit vérifier ce qui fonctionne avec son propre logiciel.

Un environnement utilisable n’empêche pas l’IA de faire des erreurs de raisonnement ou de programmation. Une fois les problèmes de préparation résolus, il permet toutefois de les observer. L’article suivant explique comment choisir des tests qui détectent les erreurs importantes.