De Claude Code à REA : l’agent IA passe de l’écriture de code à l’utilisation de logiciels

Vous obtenez du code, mais votre agent ne réalise pas encore l’action attendue dans l’application métier.
Le changement le plus utile à retenir : Claude Code illustre le travail centré sur le dépôt de code ; REA renvoie ici à un projet présenté sous ce nom, à examiner selon ses capacités vérifiables. L’agent IA peut s’étendre à l’utilisation de logiciels, sans que cette évolution remplace automatiquement les agents de programmation.

Cet article s’adresse aux développeurs qui utilisent Claude Code et veulent comprendre ses limites, aux équipes qui évaluent l’automatisation d’applications et aux responsables techniques chargés des permissions, de l’environnement d’exécution et des contrôles.

Deux façons différentes de faire agir un agent IA

Un agent de programmation travaille principalement sur un projet logiciel : il lit des fichiers, propose ou modifie du code, puis peut exécuter des commandes ou des tests pour examiner le résultat. Un agent qui opère un logiciel vise plutôt un état dans une application : remplir un formulaire, modifier un dossier, préparer une publication ou déplacer une tâche dans un outil de gestion.

La différence ne tient donc pas seulement à la forme de la réponse. Dans le premier cas, le résultat principal est une modification du code ou un diagnostic sur celui-ci. Dans le second, le résultat attendu est une action réalisée dans un environnement logiciel, avec un état observable à confirmer.

Cette distinction permet de comprendre le passage « de Claude Code à REA » sans le transformer en classement de produits. Le premier nom est celui d’un outil de programmation documenté. Le second désigne, dans le contexte de cet article, le projet référencé sous le nom REA. Le dépôt fourni ne permet pas, à lui seul, d’établir un développement universellement reconnu de ce sigle ; il est donc préférable de ne pas lui attribuer une expansion sans définition explicite. La présentation du dépôt REA est la source à consulter pour comprendre les fonctions que ses auteurs annoncent.

En quoi l’évolution de l’agent IA change-t-elle réellement son champ d’action ? Elle ajoute une possibilité d’exécution : l’agent peut être évalué non seulement sur ce qu’il écrit, mais aussi sur sa capacité à utiliser un logiciel, à constater un changement d’état et à signaler une erreur. Cela ne prouve pas qu’il sait accomplir n’importe quelle tâche de manière autonome.

Pour votre décision, séparez donc trois questions : l’agent sait-il comprendre la tâche, peut-il agir dans le bon environnement, et pouvez-vous vérifier sans ambiguïté ce qu’il a fait ? Un résultat convaincant sur la première question ne répond pas automatiquement aux deux autres.

Claude Code et le travail centré sur le dépôt

Claude Code est documenté comme un outil utilisable depuis la ligne de commande. Sa documentation décrit des modes d’interaction et des commandes pour travailler avec l’outil ; elle ne justifie pas de généraliser chaque capacité à l’ensemble des agents de programmation. Consultez le guide officiel de Claude Code en ligne de commande pour vérifier les commandes et les modes d’utilisation disponibles.

Dans un scénario de correction, vous pouvez lui demander d’examiner un dépôt, de repérer le code concerné, de proposer une modification, puis d’exécuter les vérifications pertinentes. Le chemin de preuve est relativement lisible : vous pouvez examiner les fichiers modifiés, lire les commandes lancées et comparer le comportement avant et après. Ce contrôle reste nécessaire : un test réussi ne signifie pas que la modification répond à toutes les exigences métier.

Les permissions font partie de la décision, pas d’un réglage secondaire. La documentation officielle des permissions de Claude Code décrit les mécanismes de contrôle associés à l’utilisation de l’agent. Avant de lui confier un dépôt, vérifiez quelles actions sont autorisées, lesquelles demandent une validation et si les accès accordés sont cohérents avec la tâche. Ne déduisez pas d’une permission disponible qu’il est prudent de l’accorder dans tous les projets.

Quelle différence avec l’utilisation d’un logiciel ? Modifier un script qui automatise une opération n’est pas la même chose qu’ouvrir directement une application, choisir un dossier et lancer l’opération. Le script expose des éléments que vous pouvez inspecter dans le code ; une action dans l’interface peut dépendre d’un compte connecté, d’un écran chargé ou d’un état temporaire. Les deux approches peuvent se compléter : l’agent de programmation prépare ou corrige l’automatisation, tandis qu’un agent d’action exécute une tâche limitée dans le logiciel.

REA et l’automatisation par l’interface ou les outils

L’expression « opération d’un logiciel » recouvre plusieurs mécanismes. Un agent peut interagir avec une interface graphique, appeler des outils prévus par une application, ou combiner ces voies. Le chemin choisi détermine ce qu’il peut observer et les preuves dont vous disposez après l’action.

Pour une interface, l’agent doit interpréter l’écran, choisir une commande, l’exécuter, puis vérifier l’état obtenu. Une fenêtre qui se ferme n’est pas nécessairement une preuve de réussite : l’enregistrement peut avoir échoué, le mauvais élément peut avoir été sélectionné, ou une confirmation peut être restée en attente. Avec un outil logiciel, les entrées et les retours peuvent être plus structurés, mais une réponse positive ne prouve pas toujours que l’effet métier attendu s’est produit.

Les annotations d’outils peuvent aider à décrire la nature d’une action, mais ne remplacent ni les permissions ni la validation. Le document du protocole MCP sur les annotations d’outils présente ces annotations comme des indications sur les outils. Elles ne constituent pas, à elles seules, un mécanisme de sécurité garantissant qu’une action est sans risque.

À propos de REA, gardez une frontière claire entre nom du projet et catégorie générale. Le dépôt et son guide d’installation sont les références à consulter pour vérifier son installation et son périmètre documenté. Ne concluez pas qu’un projet sait piloter toutes les applications, qu’il dispose de permissions particulières ou qu’il est prêt pour un usage de production si les documents consultés ne l’établissent pas.

Dans une équipe de création, par exemple, l’agent peut être chargé de préparer une fiche de production, de renseigner des métadonnées ou de classer des éléments dans un outil. En audio ou en vidéo, la valeur potentielle vient surtout de la répétition : appliquer une convention de nommage, remplir des champs connus ou préparer une séquence d’étapes. En design, une tâche de classement ou de préparation peut être plus contrôlable qu’une décision créative laissée sans validation. Dans chaque cas, définissez l’état final attendu plutôt que de demander simplement à l’agent de « s’occuper du projet ».

Chaînes d’exécution et preuves de réussite

Pour comparer les deux approches, utilisez une même tâche de bout en bout. Supposons que vous deviez créer une nouvelle catégorie de contenu dans un service de gestion. L’agent de programmation peut modifier le code d’une intégration ou d’un outil interne, puis exécuter des tests. L’agent d’utilisation peut tenter de créer la catégorie dans l’application. Dans le premier cas, inspectez la modification et le résultat des tests ; dans le second, vérifiez que la catégorie apparaît au bon endroit, avec les bons attributs, dans le compte prévu.

Une démonstration peut établir qu’une séquence fonctionne dans un contexte donné. Elle ne garantit pas qu’elle résistera à un changement d’interface, à une session expirée, à une différence de droits ou à un résultat inattendu. Pour une évaluation sérieuse, consignez la tâche, l’environnement, les permissions accordées, l’état initial et la preuve finale. Cette méthode aide à distinguer une capacité observée d’une promesse générale.

Tâches adaptées, limites et retour arrière

Les usages les plus raisonnables sont répétitifs, encadrés par des règles compréhensibles et vérifiables après exécution. Vous pouvez évaluer le classement de dossiers selon des critères explicites, la saisie de champs à partir d’un document, la préparation d’un brouillon ou la mise à jour d’un statut. Commencez par une tâche où l’erreur reste réversible et où un responsable peut comparer l’état final à la demande.

Les avantages possibles sont concrets : l’agent peut suivre une séquence définie, préparer des actions répétitives et réduire la manipulation manuelle dans une application. En contrepartie, il faut traiter des risques que le travail dans le code ne présente pas de la même manière.

• Interface instable : une mise à jour, une fenêtre surgissante ou un chargement incomplet peut changer la cible de l’action. Prévoyez une vérification de l’écran ou un arrêt si l’état attendu n’est pas détecté.
• Permissions trop larges : un compte qui peut supprimer, publier ou modifier des données importantes augmente les conséquences d’une erreur. Limitez l’accès au périmètre nécessaire et faites approuver les actions sensibles.
• Résultat difficile à prouver : une animation terminée ou un message de succès ne suffit pas toujours. Cherchez une trace indépendante, comme l’élément réellement modifié ou un historique d’activité.
• Erreur en chaîne : une première sélection incorrecte peut rendre toutes les actions suivantes cohérentes en apparence, mais fausses. Ajoutez des contrôles intermédiaires et un moyen d’interrompre l’exécution.
• Dépendance au contexte : la session, le compte actif, les données visibles et l’environnement de travail influencent le résultat. Vérifiez que l’agent opère dans le bon espace avant de lui donner une tâche réelle.

Un agent de programmation reste souvent le choix le plus direct lorsque le problème se situe dans le code, que les changements sont examinables et que les tests peuvent reproduire le contrôle. Un agent opérant le logiciel devient intéressant lorsque le résultat exige une action dans une application et qu’un état final peut être vérifié sans ambiguïté. Il n’y a pas de raison de remplacer un chemin de travail contrôlable par une interface automatisée si cette dernière ne résout aucun blocage réel.

Environnement d’exécution et critères de déploiement

Un agent qui agit dans un logiciel dépend de son environnement : système accessible, application installée ou disponible, compte autorisé, session, réseau et outils nécessaires. Ces exigences doivent être établies pour votre cas précis. La documentation d’installation de REA peut vous aider à examiner le projet cité, mais elle ne permet pas de conclure que tous les agents nécessitent le même système ou que chaque environnement Mac convient à chaque application.

Pour une équipe qui envisage un Mac distant, vérifiez d’abord que l’application visée et les conditions d’accès sont compatibles avec l’environnement proposé. Une machine distante peut être pertinente pour des tâches de développement, de compilation, de test ou d’automatisation qui doivent s’exécuter dans un environnement Mac. Elle n’élimine ni les risques liés aux permissions ni la nécessité de confirmer l’état de l’application. Consultez les informations de location de Mac mini chez Kvmzen pour examiner l’environnement réellement proposé, puis comparez-le aux dépendances et aux règles d’accès de votre tâche.

Appliquez ensuite cette décision conditionnelle :

• Si la tâche consiste à comprendre ou modifier un dépôt, que le changement peut être relu et que des tests pertinents existent, choisissez un agent de programmation tel que Claude Code, avec des permissions adaptées.
• Si la tâche exige une action dans une application, que son déroulement est répétable et que l’état final peut être contrôlé, évaluez un agent d’utilisation du logiciel sur un environnement d’essai.
• Si l’action est irréversible, touche des données sensibles ou ne laisse pas de preuve fiable, exigez une validation humaine avant exécution ; à défaut, gardez la tâche hors automatisation.
• Si l’application, les accès ou les conditions d’exécution ne sont pas compatibles avec l’environnement disponible, revenez à une automatisation par code, à une intervention humaine ou à un autre environnement vérifié.

L’essentiel est de choisir l’agent selon l’endroit où se trouve le travail, pas selon une promesse d’autonomie. Pour une tâche de code, les fichiers et les tests offrent un parcours de contrôle naturel. Pour une tâche dans un logiciel, l’accès, l’état réel de l’application, le risque d’erreur et le retour arrière deviennent centraux.

Si vous hésitez entre votre environnement actuel et un Mac distant, comparez les contraintes avant de déplacer le travail : une configuration locale peut être préférable pour un usage continu avec des périphériques physiques ; un service distant peut éviter de préparer une machine dédiée pour un essai ou un besoin de développement et de test, mais seulement si l’application et les accès requis y sont disponibles. Les machines virtuelles ou les environnements distants ne règlent pas, à eux seuls, les problèmes de stabilité d’interface, de permissions trop larges ou de vérification insuffisante.

Pour explorer ce choix sans supposer que le Mac distant convient à toute tâche, examinez les environnements Mac proposés par Kvmzen et confrontez-les à votre application, à vos exigences d’accès et à votre méthode de validation. Si vous pouvez décrire l’action attendue, limiter les droits et prouver le résultat, l’automatisation logicielle mérite un essai encadré ; sinon, gardez l’agent dans un rôle de préparation et faites exécuter ou approuver l’action par une personne.