# Des appels d’outils à un ordinateur pour agents : comment l’architecture évolue

De la boucle d’appels d’outils à un ordinateur qui exécute de vraies tâches : environnements distincts, état conservé, permissions et progression consultable.

Canonical page: https://beeuni.ai/blog/fr/from-tool-calls-to-agent-computer

Imaginez un bouton de comparaison de fournisseurs dans votre produit. Un client choisit plusieurs devis et demande un tableau avec les prix, les dates de livraison et les différences de conditions. Votre premier prototype envoie le texte à un modèle. Cela fonctionne avec un devis court. Puis un client fournit des PDF scannés, un tableur et un lien vers le site d’un fournisseur.

La fonction doit maintenant ouvrir les fichiers, extraire les tableaux, consulter le site, calculer des prix comparables et créer un tableur téléchargeable. Le modèle aide à décider quoi faire. Il lui faut aussi un endroit pour exécuter les programmes chargés de le faire. C’est là qu’un ordinateur pour agents devient utile.

## Que se passe-t-il quand le modèle demande d’exécuter une commande ?

Un appel d’outil est une demande du modèle adressée à votre programme. Le modèle peut, par exemple, demander de lancer un script qui lit les devis. Votre programme doit encore fournir les fichiers, installer l’outil d’extraction, lancer le script et renvoyer sa sortie. Si l’extraction échoue sur une page scannée, l’agent doit examiner l’erreur et essayer une autre méthode disponible.

Vous pouvez construire ces étapes vous-même. À mesure que la fonction grandit, il faut aussi un navigateur, un accès aux fichiers, les sorties des commandes et un moyen de séparer le travail des clients. Beeuni rassemble ces éléments dans une session : l’agent travaille sur un ordinateur cloud où il peut lire des fichiers, écrire du code, lancer des commandes et naviguer sur le web.

Pour la comparaison, l’agent peut enregistrer les lignes extraites, écrire un script de calcul et l’exécuter. Il peut consulter une page publique du fournisseur pour vérifier une condition de livraison. Si une unité ou une date reste incertaine, il peut le signaler dans le résultat. Le client reçoit un tableur qu’il peut vérifier, avec des références aux sources.

## De la boucle d’appels d’outils au travail sur un ordinateur

La boucle d’appels d’outils continue de guider le raisonnement : interroger le modèle, exécuter l’action demandée, lui renvoyer ce qui s’est passé, puis recommencer. Pour le PDF, l’ordinateur lance un script d’extraction et renvoie le code de sortie, la sortie et les erreurs. L’agent les lit avant de décider de la suite. Une erreur d’extraction, un tableau vide et une extraction réussie appellent des actions différentes.

Conservez le PDF d’origine, extracted.csv, le script de calcul et le tableur final dans des fichiers distincts. Si les chiffres semblent faux, vous pourrez remonter d’un fichier à l’autre. Demandez à l’agent de comparer une ligne extraite avec la page d’origine avant de modifier le calcul. Vous pourrez ainsi corriger l’étape qui a perdu l’information.

Un outil peut aussi lancer un processus qui dure plus longtemps que l’appel. Une conversion de documents peut encore tourner après l’expiration de la requête. La couche d’exécution doit permettre de consulter ce processus et sa sortie. Demander au modèle de le relancer pourrait créer deux conversions sans résoudre le retard.

## Donnez un environnement de travail distinct à chaque tâche

Si deux comparaisons utilisent le même répertoire, chacune peut écraser extracted.csv ou installer une version de paquet incompatible avec l’autre. Chaque session Beeuni possède son propre environnement d’exécution, qui sépare ces fichiers et processus locaux. Pour le travail sur un dépôt, sa branche permet aussi d’examiner les changements avant de les accepter dans la branche par défaut.

Les applications partagées demandent une attention particulière. Si les deux sessions peuvent modifier le même enregistrement d’achat, des ordinateurs séparés n’empêchent pas les conflits dans cette application. Décidez si la comparaison doit seulement lire ces données ou si une modification doit être approuvée.

## Décidez ce qui doit être conservé après un arrêt ou une panne

La session enregistrée raconte ce qu’a fait l’agent. Le disque contient les fichiers extraits et le tableur. Un processus en cours contient du travail pas encore écrit. Ce sont des états différents : récupérer les messages ne signifie pas qu’une conversion reprend à l’instruction où elle s’était arrêtée.

Un arrêt normal conserve le disque de l’ordinateur. Supprimer ou perdre l’ordinateur demande une autre procédure de récupération, à partir des échanges enregistrés et du travail sauvegardé dans le dépôt, lorsqu’ils sont disponibles. Enregistrez les fichiers importants dans votre stockage et poussez les modifications du dépôt dont vous avez besoin. Le [guide des sessions](/docs/fr/work/sessions) précise ce que chaque opération conserve.

## Définissez les permissions pour les actions importantes

L’agent de comparaison peut avoir besoin de lire des documents fournisseurs, alors que passer commande exige une décision humaine. Les [règles des connecteurs](/docs/fr/connect/connectors) Beeuni peuvent autoriser une action, demander une approbation ou la bloquer. Configurez l’action elle-même au lieu de compter entièrement sur une phrase dans la tâche. L’ordinateur isole le travail local, mais ses outils connectés peuvent toujours agir sur un véritable système d’achat.

Votre produit vérifie aussi quel client peut ouvrir chaque comparaison et ses fichiers. Une clé API conservée sur votre serveur authentifie votre application auprès de Beeuni. Vos propres contrôles d’accès relient cette requête à la personne autorisée à voir le résultat.

## Laissez les tâches longues continuer après la fermeture d’une connexion

Le client peut fermer la page pendant une conversion. Conservez l’identifiant de session Beeuni avec la comparaison pour retrouver le même travail à son retour. Les flux d’événements montrent la progression en direct ; les journaux enregistrés permettent de rattraper ce qui s’est passé. Un ordinateur accessible peut travailler, avoir terminé ou attendre une réponse. Affichez donc l’état de la tâche en plus de la disponibilité de l’ordinateur.

Avant de répéter une requête interrompue, vérifiez ce qui s’est passé. C’est particulièrement important pour les actions externes : une commande peut avoir été créée même si sa confirmation n’est jamais arrivée. Le [guide du backend pour agents](/blog/fr/use-beeuni-as-your-agent-backend) explique les données à conserver dans votre application et la gestion des reconnexions.

## Facilitez la recherche des causes d’un échec

Supposons que la colonne des prix du tableur produit soit vide. Ouvrez les fichiers et les sorties de commandes de la session. L’extraction du PDF n’a-t-elle renvoyé aucune ligne ? Le script attendait-il une colonne « Price » alors que le devis utilisait « Unit cost » ? Le site du fournisseur demandait-il une connexion ? Chaque cause appelle une correction différente.

L’agent travaille avec des fichiers et des programmes. Vous pouvez donc lui demander d’examiner un CSV intermédiaire, de corriger la correspondance des colonnes et de relancer le calcul. C’est souvent plus utile que de demander au modèle de produire une nouvelle réponse finale sans savoir ce qui a échoué.

## Accélérez l’étape dont vous constatez la lenteur

Cette fonction peut passer du temps à préparer l’ordinateur, attendre le modèle, extraire les documents ou charger les sites. Examinez une vraie comparaison avant de changer l’architecture. Si l’agent ouvre sans cesse le même PDF, enregistrez le texte extrait et travaillez dessus. Si un script de calcul est lent, examinez-le. Si le site du fournisseur est lent, changer de modèle ne le fera pas charger plus vite.

Vérifiez le tableur après chaque modification. Une extraction plus rapide n’est utile que si les prix et les conditions restent corrects. Comparez les mêmes documents avec les mêmes paramètres de modèle pour voir si la modification a aidé.

## Ce que l’architecture apporte désormais

Le modèle choisit toujours les actions dans une boucle d’appels d’outils. Autour de lui, le service exécute maintenant les programmes, sépare les tâches, conserve le travail utile, applique les permissions et rend la progression visible. C’est le changement d’architecture derrière un ordinateur pour agents. Beeuni fournit ces interfaces d’exécution et de session pour que votre application puisse envoyer une tâche et examiner le travail pendant son déroulement.

La même organisation peut servir à préparer des jeux de données ou à tester un site dans le navigateur. Les fichiers, les commandes et les résultats attendus changent. Votre produit démarre toujours une session, suit le travail et présente un résultat utilisable par le client.

Commencez par [Sessions depuis le code](/docs/fr/sdk/sessions) et [Authentification](/docs/fr/sdk/auth). Pour découvrir l’idée du produit, lisez [Qu’est-ce qu’un ordinateur IA ?](/blog/fr/what-is-an-ai-computer).