# Qu’est-ce qu’un ordinateur IA ? PC traditionnels et ordinateurs pour agents

Ce qui change quand les agents utilisent les logiciels d’un ordinateur : interactions sur un PC traditionnel, exécution des outils, retours du navigateur, processus, fichiers et état des sessions.

Canonical page: https://beeuni.ai/blog/fr/what-is-an-ai-computer

Ouvrez un bureau Windows et vous verrez à qui il était destiné. Vous pouvez garder un tableur à côté d’un navigateur, trouver un document dans un dossier et choisir des commandes dans un menu. Aujourd’hui, un agent peut lui aussi utiliser ces logiciels. Que doit fournir un ordinateur lorsque la personne qui donne les instructions n’effectue plus elle-même chaque opération ?

Cette question est au cœur de Beeuni. Nous construisons un ordinateur natif pour l’IA : un environnement où les agents peuvent exécuter des programmes, utiliser un navigateur, travailler avec des fichiers et accéder à des applications connectées. Les personnes leur fixent des objectifs et déterminent les accès qu’elles leur accordent. L’ordinateur fournit les logiciels et l’environnement d’exécution dans lesquels l’agent travaille.

## Comment le bureau organisait le travail autour des personnes

Les environnements en ligne de commande demandent aux utilisateurs de décrire les opérations dans un langage que la machine peut exécuter. Vous indiquez le nom d’un programme, lui transmettez des arguments et lisez son résultat. Cette méthode reste efficace, notamment lorsque vous savez ce que vous voulez exécuter ou devez répéter une opération sur de nombreux fichiers.

Les environnements graphiques ont rendu une plus grande partie de ce travail visible et manipulable directement. Windows a contribué à faire découvrir le bureau à un vaste public d’utilisateurs d’ordinateurs personnels, aux côtés d’autres systèmes graphiques. Vous pouviez parcourir les fichiers, ouvrir des applications et passer d’un document à l’autre sans connaître la commande correspondant à chaque action. La ligne de commande a continué d’exister en parallèle de ces interfaces.

L’importance de cette évolution allait bien au-delà de l’apparence d’une fenêtre. Un environnement commun fournissait aux applications des conventions à respecter : comment ouvrir et enregistrer un fichier, afficher une boîte de dialogue ou partager des informations au moyen du presse-papiers. Les utilisateurs pouvaient acquérir des habitudes valables d’un programme à l’autre. Le système d’exploitation gérait les processus, le stockage et les ressources, tandis que les personnes se concentraient sur le travail à accomplir.

Les navigateurs sont ensuite devenus un lieu courant pour utiliser des logiciels, et les téléphones ont organisé une grande partie de nos interactions autour du toucher. Ces changements n’ont pas effacé les interfaces précédentes. Ils ont transformé la façon dont les personnes accédaient aux logiciels et ce qu’elles attendaient du système qui les entourait. Un ordinateur a toujours été en partie façonné par la manière dont ses utilisateurs travaillent.

## Un agent devient un nouvel utilisateur de logiciels

Prenons une tâche ordinaire : préparer un rapport. Vous trouvez des sources, ouvrez des documents, calculez des chiffres, rédigez le rapport et vérifiez le résultat. C’est vous qui coordonnez les applications : vous vous souvenez de l’emplacement d’un fichier, remarquez une erreur et décidez de l’opération à essayer ensuite.

Un agent peut prendre en charge une partie de cette coordination. Il peut s’appuyer sur un modèle pour interpréter la demande, choisir des outils, examiner leurs résultats et décider de la suite. Ses opérations peuvent passer par une interface de navigateur, une commande ou une API. L’interface appropriée dépend de la tâche et des logiciels disponibles.

La délégation modifie le rôle de la personne. Vous décrivez le résultat attendu, fournissez le contexte et vérifiez les décisions qui exigent votre jugement. L’agent exécute une suite d’opérations. Pour cela, il a besoin d’accéder à des logiciels, de disposer de fichiers sur lesquels travailler et d’utiliser un environnement en cours d’exécution qui lui renvoie le résultat de chaque action.

Une interface de conversation est un moyen pratique de formuler la demande. Le reste de la tâche se déroule dans des logiciels. Un rapport doit être rédigé quelque part. Un script doit être exécuté. Un site web doit se charger, et il faut pouvoir distinguer une requête qui a échoué d’une requête qui a abouti. Ces responsabilités incombent à l’environnement informatique qui entoure l’agent.

## Le modèle, l’agent et l’ordinateur remplissent des fonctions différentes

Le modèle interprète les informations et génère des réponses ou des actions proposées. Il peut produire un calcul, mais le fait d’écrire ce calcul dans une réponse ne signifie pas nécessairement qu’il a été exécuté. Il peut proposer une modification de fichier, mais il faut encore qu’un système l’applique et en renvoie le résultat.

L’agent relie les décisions du modèle aux outils. Ses instructions et sa logique d’exécution déterminent sa marche à suivre : quand lancer une commande, lire une page, poser une question ou s’arrêter. Un cadre de développement d’agent aide les développeurs à définir ce comportement.

L’ordinateur fournit les éléments sur lesquels ces outils interviennent. Il exécute le programme, conserve les fichiers de travail et fournit l’environnement du navigateur. Beeuni organise également autour de cette exécution la configuration de l’agent, l’accès aux outils et l’état de la session. Ces éléments peuvent être fournis ensemble, mais leurs fonctions restent distinctes.

Cette distinction compte au moment de choisir un système. Un modèle plus capable peut améliorer la façon dont un agent raisonne sur un problème. À lui seul, il ne peut pas fournir davantage de mémoire à une tâche en cours, récupérer un fichier manquant ni accorder l’accès à une application. L’environnement informatique a son propre rôle à jouer.

## PC traditionnels et ordinateurs pour agents : qu’est-ce qui change ?

Un PC traditionnel exécute déjà des programmes, gère des fichiers et se connecte aux réseaux. C’est généralement la personne qui coordonne le travail : ouvrir une application, lire son résultat, repérer un échec et choisir l’opération suivante. Quand un agent reprend cette coordination, l’ordinateur doit lui rendre ces opérations et leurs résultats accessibles par des outils qu’il peut appeler.

| Fonction | Sur un PC traditionnel | Dans un ordinateur pour agents |
| --- | --- | --- |
| Lancer une opération | Une personne ouvre une application ou saisit une commande | L’agent demande une action à un outil, avec des arguments et un contexte de travail |
| Lire le résultat | Une personne lit une fenêtre, la sortie d’un terminal ou un message d’erreur | Les outils renvoient les sorties des commandes, les erreurs, le contenu des pages ou des captures que l’agent examine |
| Travail de longue durée | Une personne surveille un terminal ou passe d’une application à l’autre | L’agent lance le travail, vérifie son avancement et utilise d’autres outils pendant son exécution |
| Accès aux applications | Une personne utilise directement les logiciels auxquels elle est connectée | L’agent utilise les connexions et les actions autorisées pour sa tâche |

Les fonctions habituelles du système d’exploitation restent nécessaires : les processus ont besoin de ressources, les fichiers d’espace de stockage et les applications d’un accès réseau. Les outils destinés à l’agent relient ces opérations à la tâche. Une commande a besoin d’un répertoire de travail et d’un résultat vérifiable ; une action dans le navigateur a besoin d’une page sur laquelle agir et d’un moyen d’examiner ce qui a changé.

## De la demande à un outil à l’action suivante

Prenons un agent qui vérifie une application Web. Il lit les instructions d’installation du projet, installe les dépendances nécessaires et lance le serveur de développement dans un terminal. Ce serveur doit rester actif pendant que l’agent ouvre le site dans un navigateur. Le terminal et le navigateur sont deux outils qui travaillent dans le même environnement de tâche.

Le lancement de la commande ne prouve pas que le site est prêt. L’agent doit examiner la sortie du processus, confirmer que le serveur accepte les connexions, puis charger la page. Si le démarrage échoue parce qu’un paquet manque, l’erreur lui donne un problème précis à examiner. Une fois le site chargé, il peut cliquer sur un bouton, examiner la page obtenue et comparer son comportement au test demandé.

Chaque observation alimente la décision suivante du modèle. Pour une commande, il peut s’agir de la sortie standard, de la sortie d’erreur et du code de sortie une fois la commande terminée. Pour un navigateur, il peut s’agir de la page actuelle, du texte visible ou d’une capture d’écran. Le modèle utilise ces retours pour choisir une autre action, corriger une erreur, demander de l’aide ou terminer. Si le système se contentait d’accepter la demande à l’outil, l’agent n’aurait pas les informations nécessaires pour poursuivre.

Cela aide aussi à localiser les échecs. Un modèle peut choisir la mauvaise commande, un processus peut ne pas démarrer ou un site peut refuser une requête. Ce sont des problèmes différents. Garder l’action et son résultat réel visibles permet de les distinguer, plutôt que d’attribuer toute tâche bloquée au modèle.

## Les fichiers, les processus et l’état des sessions ont des rôles distincts

Les fichiers font le lien entre les outils. Un agent peut télécharger un CSV dans le navigateur, le lire avec Python et rédiger un rapport qui reprend les résultats calculés. Les données d’entrée, le script et le résultat doivent être accessibles dans l’environnement de travail. C’est l’un des intérêts d’un ordinateur pour les tâches qui passent par plusieurs applications : l’agent peut travailler sur les fichiers réels tout au long de la tâche.

Les processus ont leur propre cycle de vie. Un serveur Web ou un entraînement de modèle peut continuer après que sa commande de lancement a rendu la main. L’agent doit vérifier les sorties et l’avancement, reconnaître la fin du travail et arrêter les processus devenus inutiles. Un fichier contenant une commande de lancement ne prouve pas que le programme s’est exécuté correctement.

L’historique de session consigne la conversation et l’activité des outils. Un commit suivi d’un push conserve les modifications de fichiers sur la branche de la session ; une demande de modification approuvée et fusionnée les intègre à la branche par défaut du projet. Aucune de ces opérations ne sauvegarde un processus en cours ni son état en mémoire. Lors de la reprise, l’agent peut devoir examiner les fichiers et relancer un programme. Revenir à la conversation ne garantit pas, à lui seul, que tous les processus fonctionnent encore.

Les accès et le travail simultané imposent une autre limite. Des environnements de session distincts séparent les fichiers et processus locaux, mais deux agents connectés au même service externe peuvent encore agir sur les mêmes données. Les autorisations des outils et les règles d’approbation déterminent ce que chacun peut faire. Un ordinateur isolé n’annule pas un message envoyé ni une donnée modifiée dans une autre application.

## Pourquoi un ordinateur en plus d’un framework d’agents ?

Un framework d’agents peut définir comment un modèle choisit ses outils et réagit à leurs résultats. Exécuter ces choix nécessite toujours des logiciels : un navigateur, des environnements d’exécution des langages, des dépendances installées et un endroit où lancer les processus. Une bibliothèque qui déclare un outil de navigation ne fournit pas, à elle seule, un navigateur opérationnel.

Beeuni réunit un moteur d’exécution d’agents avec cet environnement, des outils préparés, la configuration des projets et les commandes de gestion des sessions. Les développeurs peuvent utiliser ces capacités par une API tout en conservant leur logique applicative et leur interface. L’ordinateur fournit l’environnement logiciel dans lequel l’agent agit ; le produit construit dessus détermine à quoi sert ce travail.

## Comment cela se concrétise dans Beeuni

Dans Beeuni, un projet regroupe les fichiers et la configuration de l’agent associés à un ensemble de tâches. Vous pouvez définir des instructions, choisir un modèle, ajouter des compétences et configurer des outils connectés. Une session est une instance de travail de l’agent dans un environnement isolé. Vous pouvez suivre sa conversation et son avancement, examiner les fichiers qu’il produit et lui donner des instructions supplémentaires.

Prenons l’exemple de la transformation de votre base de connaissances du service d’assistance en jeu de données pour l’IA. L’agent consulte les documents par l’intermédiaire d’une connexion autorisée, suit les liens pertinents et rassemble les sources. Il extrait le texte, écrit un script de conversion et l’exécute. Il vérifie ensuite s’il manque des champs ou s’il existe des doublons. Vous examinez les catégories ambiguës tandis que l’agent se charge de la récupération des données, des opérations sur les fichiers et de l’exécution du programme.

Vous pouvez examiner le script, les références aux sources, le rapport de validation et le jeu de données exporté. Vous disposez ainsi de plusieurs moyens d’évaluer le résultat, au-delà de la lecture du message final de l’agent. Si une règle était incorrecte, vous pouvez demander une correction et examiner les modifications apportées au résultat.

Un autre agent pourrait tester un site web, tandis qu’un autre préparerait un rapport de recherche. Leurs instructions, leurs outils et leurs résultats diffèrent. Beeuni fournit à chaque session un environnement d’exécution et rend son travail visible dans le produit. Vous configurez les autorisations des outils et les règles d’approbation en fonction des actions que vous souhaitez déléguer.

## L’interface peut être Beeuni, un autre agent ou votre propre produit

Pour une utilisation directe, ouvrez Beeuni sur le web ou dans un client, choisissez un agent et décrivez la tâche. Vous pouvez lui fournir des fichiers et examiner le travail au fur et à mesure. Les sessions peuvent aussi être lancées selon un calendrier ou par un webhook lorsque la tâche nécessite une automatisation.

Un client d’agent existant peut se connecter via MCP. Les développeurs peuvent utiliser l’API et le SDK TypeScript pour créer des sessions, envoyer des requêtes et recevoir l’avancement et les résultats dans leurs propres applications. Un outil d’achat, par exemple, peut conserver son propre écran de vérification pendant que Beeuni rassemble les informations sur les fournisseurs, compare les produits et prépare le résultat.

Il s’agit de différentes façons d’accéder à une même idée du produit. L’ordinateur n’a pas besoin d’être l’interface dans laquelle la personne saisit du texte. Il peut être l’environnement qu’une autre application ou un autre agent utilise pour accomplir des tâches.

## Un ordinateur conçu pour un autre type d’utilisateur

Windows a rendu les applications et les fichiers accessibles grâce à un bureau que les utilisateurs pouvaient parcourir. Avec les agents, une partie de ce parcours et de cette coordination peut être déléguée. La question de conception consiste alors à donner à un agent les moyens de travailler tout en permettant à la personne responsable de comprendre ses actions.

Nous pensons que les personnes et les agents utiliseront les logiciels ensemble. Les personnes continueront à ouvrir des documents, à faire des choix et à utiliser directement des applications. Les agents prendront en charge une partie du travail entre ces décisions. Beeuni est conçu autour de cette relation : les agents utilisent l’ordinateur, et les personnes déterminent ce qu’elles leur demandent et ce à quoi elles font confiance.

Pour découvrir les choix techniques qui sous-tendent cette idée, lisez [Des appels d’outils à l’ordinateur pour agents](/blog/fr/from-tool-calls-to-agent-computer). Pour essayer, suivez le [guide de préparation d’un jeu de données](/blog/fr/build-ai-training-dataset-jsonl) ou consultez le [guide du SDK](/docs/fr/sdk) pour connecter Beeuni à votre application.