# Où s’exécute réellement le travail d’un agent IA Dans loqy V1, le moteur, le modèle et les outils occupent des zones distinctes : chacun ne voit que les données et permissions qui lui sont attribuées. Cette séparation met en pratique [le point de départ local de loqy](/fr/blog/why-loqy-starts-local/). Prenons une demande concrète : > Lis les notes et les contrats du projet Atlas, recherche les alertes publiques sur ses trois fournisseurs principaux, compare les risques, puis livre une note sourcée avec les mesures à prendre. Les fichiers du projet sont locaux. La recherche appelle des services externes. L’analyse peut utiliser un modèle local ou hébergé. Le navigateur et les traitements de documents doivent manipuler du contenu potentiellement hostile. Le livrable, enfin, doit revenir dans le travail avec ses sources. Suivre cette demande permet de comprendre l’architecture de loqy V1 sans la réduire à une étiquette « local » ou « cloud ». ## En bref | Composant | Emplacement dans loqy V1 | Responsabilité | | --- | --- | --- | | Moteur de l’agent et Core | Mac | État du travail, contexte, permissions, outils, décisions et effets | | Modèle local | Mac | Génération à partir du contexte admis | | Modèle hébergé | Route hébergée sélectionnée | Génération distante à partir du contexte admis | | Outils non fiables | microVM isolée | Navigateur, code, scripts et traitements de documents | | Service externe | Destination autorisée | Recherche, connecteur ou API selon une requête bornée | | Secrets d’authentification | Trousseau macOS et adaptateur Core | Authentification sans exposition au modèle ni à la microVM | **Le lieu du modèle et celui du moteur de l’agent sont deux choix indépendants.** Dans la V1, un modèle hébergé produit une génération à distance, tandis que le Core, les espaces de travail, les outils et l’autorité métier restent locaux. ## Six composants, six responsabilités ### Moteur local de l’agent Le moteur orchestre le travail. Il ouvre une exécution, choisit le contexte admis, attribue un modèle précis, expose un ensemble fermé d’outils, vérifie les permissions et enregistre les résultats. Dans loqy V1, cette autorité appartient au Core local écrit en Rust. Le moteur décide quelles capacités existent. Le modèle propose du texte et des appels d’outils à l’intérieur de ces capacités. ### Modèle local Le modèle local produit sa réponse sur le Mac. Il reçoit le contexte construit par loqy ; les fichiers, le réseau et les secrets d’authentification restent derrière les capacités du Core. ### Modèle hébergé Le modèle hébergé produit sa réponse via la route du fournisseur sélectionné. Selon le contrat de ce fournisseur, le calcul peut être opéré directement ou confié à un fournisseur d’inférence tiers prévu par ses conditions. Le contexte nécessaire à la génération franchit le réseau, tandis que le moteur et le travail restent locaux. ### Outil isolé Le navigateur, le code, les scripts, les outils documentaires et les serveurs MCP locaux non fiables s’exécutent dans une microVM fondée sur Apple Containerization. Le Core leur accorde uniquement les montages, les destinations réseau et les capacités propres à l’exécution. ### Service externe Un moteur de recherche, un connecteur métier ou une API reçoit une requête adaptée à sa fonction. La conversation et les fichiers restent sous la sélection du Core. ### Exécution distante Une exécution distante déplacerait le moteur, l’état et les outils vers une infrastructure cloud. C’est une architecture différente, **hors du chemin d’exécution de la V1**. Le schéma la présente comme une zone séparée du modèle hébergé. ![Carte d’emplacement montrant le Core et le modèle local sur le Mac, les outils dans une microVM, le modèle hébergé derrière la route choisie et un service externe à sa destination](/assets/blog/execution-placement-map-fr.svg "Dans loqy V1, les composants occupent quatre zones distinctes. Une exécution distante reste un concept séparé hors V1.") ## Ce que voit chaque composant Le schéma indique les emplacements. Le tableau suivant précise le contenu qui traverse leurs frontières. | Donnée ou capacité | Core local | Modèle local | Modèle hébergé | Outil isolé | Service externe | | --- | --- | --- | --- | --- | --- | | Demande de l’utilisateur | Oui | Dans le contexte admis | Dans le contexte admis | Seulement si nécessaire à l’outil | Non, sauf requête dérivée | | Fichiers du projet | Références et contenu autorisé | Extraits admis | Extraits admis | Montages explicitement accordés | Non par défaut | | Résultats d’outils | Enregistrés et sélectionnés | Extraits admis | Extraits admis | Son propre résultat | Son propre résultat | | Secret du fournisseur | Adaptateur dédié | Non | Utilisé par la frontière d’API, pas inclus dans la requête du modèle | Non | Utilisé par un adaptateur dédié si nécessaire | | Réseau | Politique et attribution | Aucun accès direct | Route contractuelle fixe | Destinations autorisées | Sa propre destination | | Pouvoir d’agir | Autorité typée | Aucun pouvoir autonome | Aucun pouvoir autonome | Capacité étroite | Opération reçue | Un modèle hébergé peut recevoir du contenu sensible si l’utilisateur a choisi cette génération et si ce contenu est nécessaire. Ce contexte admis quitte bien le Mac. Le fournisseur ne reçoit pas pour autant les secrets d’authentification, les espaces de travail complets ou les permissions des outils. ## Étape 1 : le Core ouvre une exécution exacte La demande sur le projet Atlas arrive dans un fil de travail local. Le Core crée une exécution, appelée *Run* dans l’architecture, avec une identité et un état propres. Une seule exécution peut être active dans ce fil à un instant donné. Le Core fixe ensuite un bail de modèle, ou `RunModelLease`. Ce bail désigne un modèle exact, son mode local ou hébergé, son fournisseur éventuel et les paramètres nécessaires. Il reste immuable pendant l’exécution. Une erreur ne remplace donc pas silencieusement le modèle par un autre. Le bail permet d’attribuer chaque sortie au modèle qui l’a produite. Il empêche aussi un changement de route de modifier la frontière de données en cours de travail. ## Étape 2 : le contexte est construit localement Le modèle n’ouvre pas lui-même les dossiers. Le `ContextPlanner`, sous l’autorité du Core, construit le contexte utilisable à partir de la demande, de l’historique pertinent, des fichiers autorisés et des résultats d’outils. Pour Atlas, il peut sélectionner : - la demande de l’utilisateur ; - les passages des contrats qui décrivent les engagements de continuité ; - les notes internes sur chaque fournisseur ; - les résultats publics ramenés par la recherche ; - les règles de forme du livrable et les capacités d’outils disponibles. La sélection du contexte est un mécanisme explicite et testable. Le contenu envoyé à un modèle hébergé correspond au contexte admis pour cette génération. ## Étape 3 : les outils travaillent dans la microVM Les contrats peuvent être en PDF ou en format Office. Les pages web recherchées peuvent contenir des scripts ou des instructions destinées à manipuler un agent. Ces contenus ne doivent pas donner au processus hôte les mêmes droits que l’utilisateur. loqy attache donc à la demande une microVM isolée. Les traitements non fiables y reçoivent seulement les ressources nécessaires : fichiers montés selon une politique, espace de travail privé, mémoire temporaire et réseau autorisé par destination. L’isolation réduit la portée de chaque outil. Une page hostile peut tromper un modèle, un analyseur peut produire un résultat erroné et une destination autorisée peut retourner du contenu malveillant. Le Core conserve l’autorité et traite ces résultats comme des données à vérifier. ## Étape 4 : la recherche franchit sa propre frontière Pour chercher les alertes publiques, loqy transforme le besoin en requêtes bornées, par exemple le nom d’un fournisseur, un type d’incident et une période. Les contrats restent dans le contexte de travail local. Le service externe reçoit ces requêtes et renvoie des résultats. Le navigateur isolé peut ensuite ouvrir une page autorisée. Les extraits, dates et adresses utiles reviennent dans le travail sous forme de résultats d’outils. Recherche et choix du modèle restent indépendants. Une analyse locale peut utiliser des sources web. Un modèle hébergé peut travailler sans recherche si le contexte fourni suffit. ## Étape 5 : le modèle reçoit le contexte admis Si l’utilisateur choisit un modèle local, le contexte est transmis au moteur d’inférence sur le Mac. S’il choisit un modèle hébergé, le Core passe par `HostedInferenceRelay`, son relais d’inférence. Ce relais applique la route fixe du fournisseur, ajoute le secret d’authentification conservé dans le trousseau macOS, contrôle les limites et transmet la requête. Ce secret sert à la connexion, mais il n’est pas injecté dans les messages adressés au modèle. Le fournisseur voit le contenu admis pour la génération et les métadonnées nécessaires à son service. La clé reste dans l’adaptateur d’API, séparée des messages du modèle. ![Parcours en six étapes d’une requête adressée à un modèle hébergé, de la demande locale au livrable sourcé, avec le secret maintenu derrière le relais](/assets/blog/hosted-request-path-fr.svg "Le Core sélectionne le contexte et fixe le modèle avant l’appel hébergé. Le secret d’authentification reste confiné derrière le relais.") La séparation des secrets est imposée par le code, pas par une consigne ajoutée au message système. Un secret présent dans le contexte peut être recopié. Un secret détenu par un adaptateur séparé n’est pas disponible au modèle. ## Étape 6 : la réponse revient sous autorité locale La réponse du modèle, local ou hébergé, revient dans le même fil comme une proposition à vérifier. Le Core peut la présenter comme texte, demander un appel d’outil appartenant à l’ensemble fermé de l’exécution ou préparer un artefact. Une action conséquente, comme publier la note ou envoyer un message à un fournisseur, exige une permission propre et une décision contextualisée. Pour la note Atlas, le paragraphe final ne représente qu’une partie du résultat : - les fichiers et passages utilisés ; - les recherches effectuées et leurs destinations ; - les résultats d’outils retenus ; - le modèle exact attribué à l’analyse ; - les décisions humaines ; - les versions du livrable. Le modèle contribue au raisonnement. Le moteur local conserve la chaîne qui permet de le réviser. [L’article consacré aux preuves](/fr/blog/why-ai-agents-need-evidence/) détaille comment cette chaîne relie sources, outils, décisions et livrables. ## Des zones séparées pour une autorité vérifiable La séparation limite la portée d’une erreur de modèle ou d’une instruction hostile. Chaque composant reçoit le minimum nécessaire à sa responsabilité. loqy sépare les zones pour réduire cette portée : - le Core possède l’autorité, mais n’exécute pas le contenu non fiable ; - la microVM exécute les outils, mais ne possède ni l’état métier ni les secrets ; - le modèle reçoit un contexte, mais aucune capacité ambiante ; - l’adaptateur d’un fournisseur possède un secret, mais n’organise pas le travail ; - un service externe reçoit une opération, pas l’ensemble de la conversation. Les contrats entre ces zones ajoutent des passages. En retour, chaque responsabilité peut être auditée, testée et remplacée séparément. ## Ce que la qualification vérifie au-delà de la topologie Le schéma décrit l’autorité prévue et les chemins entre composants. La qualification vérifie cette topologie sur l’artefact signé et installé, ses politiques réseau, ses montages, ses routes de fournisseur, ses journaux et ses preuves. ## Le lieu du calcul et l’autorité La note Atlas peut associer une conversation locale, un modèle local, une recherche web isolée et un modèle hébergé. Ces éléments ne forment pas quatre produits séparés. Ils composent un seul travail parce que le Core local conserve l’état, les règles et les preuves. Demander où fonctionne loqy appelle donc une réponse précise : **dans la V1, l’autorité de l’agent fonctionne sur le Mac ; les outils non fiables s’exécutent dans une microVM ; le modèle peut être local ou hébergé ; les services externes ne reçoivent que les opérations qui leur sont destinées**. Le choix d’un modèle distant déplace un calcul, tandis que le travail et son autorité restent dans le Core local. ## Sources et méthode - loqy, vue d’ensemble de l’architecture - loqy, sélection du modèle et pilotage des exécutions - loqy, planification et compaction du contexte - loqy, intégration des fournisseurs de modèles hébergés - loqy, capacités et contexte sous autorité du Core - loqy, modèle de menace Les descriptions de la V1 suivent ses contrats produit et d’architecture. Le moteur distant est documenté comme une architecture ultérieure distincte.