La décision n'est pas « Quel logo héberge l'agent ? », mais « Qui peut opérer, inspecter, restaurer et modifier chaque partie du runtime ? »
Que comprend l'hébergement d'agents IA ?
L'hébergement d'agents IA comprend le runtime et toutes les dépendances nécessaires pour garder le travail de l'agent disponible, inspectable et récupérable. L'architecture de référence de Google Cloud sépare la plateforme d'hébergement, les interactions, les modèles, la mémoire, les bases vectorielles, les outils et l'exécution de code (Google Cloud, vérifié le 18 septembre 2026). Mastra sépare également le runtime de l'accès aux modèles, du stockage persistant, des secrets, des traces et des appels d'outils (Mastra, vérifié le 18 septembre 2026).
Utilisez cette carte des responsabilités :
- Calcul et runtime. Notez où tourne le processus de l'agent et qui peut le déployer, l'arrêter, le redémarrer ou le mettre à jour. Cloud Run documente des services, instances, worker pools et jobs pour différents types de charges agentiques (Google Cloud, vérifié le 18 septembre 2026).
- Accès aux modèles. Notez chaque endpoint de modèle, le compte qui le possède et la personne autorisée à le modifier. L'architecture Google Cloud montre que la couche d'orchestration peut appeler des modèles hébergés par plusieurs services (Google Cloud, vérifié le 18 septembre 2026).
- Fichiers et état. Notez les fichiers de travail, l'état des conversations, les checkpoints, la mémoire et le stockage de chacun. Mastra indique qu'un agent avec état a besoin d'un stockage durable et qu'un état gardé seulement en mémoire ne survit pas au redémarrage du serveur (Mastra, vérifié le 18 septembre 2026).
- Secrets. Notez les clés de modèles, les identifiants de base de données et les clés d'outils, puis qui peut les créer, lire, faire tourner ou révoquer. Mastra recommande de garder les identifiants côté serveur et d'utiliser des variables d'environnement ou un gestionnaire de secrets plutôt que de les coder en dur (Mastra, vérifié le 18 septembre 2026).
- Logs et traces. Notez les événements capturés, leur destination et leur lecteur. Mastra décrit des traces couvrant les appels de modèles, les appels d'outils, la récupération en mémoire et la réponse finale (Mastra, vérifié le 18 septembre 2026).
- Sauvegardes. Définissez quels stockages persistants, fichiers et éléments de configuration entrent dans la sauvegarde. Les sources établissent que l'état doit persister hors de la mémoire du processus ; le périmètre exact de sauvegarde reste un choix de déploiement (Mastra, vérifié le 18 septembre 2026).
- Reprise. Nommez la personne qui restaure chaque composant conservé et celle qui accepte le service restauré. Mastra cite les nouvelles tentatives et la reprise après défaillance parmi les sujets de production, tandis que la procédure exacte dépend du déploiement (Mastra, vérifié le 18 septembre 2026).
Cette liste révèle une séparation fréquente. Un fournisseur peut opérer le calcul tandis que votre entreprise garde les comptes de modèles, les identifiants d'outils, les stockages ou les décisions de reprise. Une box opérée par son propriétaire peut inverser la responsabilité du calcul tout en appelant des modèles et des outils externes (Google Cloud, vérifié le 18 septembre 2026).
Comment comparer l'hébergement managé et une box opérée par son propriétaire ?
L'hébergement managé et la box opérée par son propriétaire diffèrent par l'opérateur runtime par défaut, pas par le nombre de responsabilités à attribuer. Mastra présente le runtime managé comme un échange entre travail d'exploitation et dépendance aux abstractions et au modèle tarifaire du fournisseur. Mastra présente le serveur auto-hébergé comme un déploiement flexible dont l'opérateur gère la montée en charge, la surveillance et les redémarrages (Mastra, vérifié le 18 septembre 2026).
| Ligne de responsabilité | Hébergement d'agent managé | Box opérée par son propriétaire | Preuve à collecter |
|---|---|---|---|
| Calcul | Le fournisseur opère le runtime fourni dans la limite documentée du service | Un opérateur nommé gère l'hôte ou le conteneur | Cible de déploiement, liste des administrateurs, route de redémarrage (Mastra, vérifié le 18 septembre 2026) |
| Accès aux modèles | Peut être inclus ou relié par un compte fournisseur séparé | L'opérateur configure les endpoints locaux ou externes | Liste des endpoints, propriétaire du compte, autorité de modification (Google Cloud, vérifié le 18 septembre 2026) |
| Fichiers et état | Le fournisseur peut fournir le stockage ou l'acheteur peut connecter le sien | L'opérateur choisit et exploite les stockages persistants | Carte des stockages, rôles d'accès, test de persistance (Mastra, vérifié le 18 septembre 2026) |
| Secrets | Le gestionnaire de secrets de la plateforme peut conserver les identifiants | L'opérateur choisit le mécanisme de secrets | Inventaire, responsable de rotation, route de révocation (Mastra, vérifié le 18 septembre 2026) |
| Logs et traces | Les outils du fournisseur peuvent capturer certains événements | L'opérateur choisit et exploite les outils de journalisation | Liste des événements, destination, rôles de lecture (Mastra, vérifié le 18 septembre 2026) |
| Sauvegardes | Confirmer les stockages et fichiers inclus | L'opérateur définit et exécute la sauvegarde | Composants conservés, responsable, dernier enregistrement (Mastra, vérifié le 18 septembre 2026) |
| Reprise | Séparer les tâches du fournisseur et de l'acheteur | L'opérateur possède la procédure écrite de restauration | Responsable de restauration, responsable d'acceptation, compte rendu (Mastra, vérifié le 18 septembre 2026) |
Ce tableau est une feuille de travail, pas une garantie fournisseur. Remplissez-le avec la documentation actuelle, la configuration et les enregistrements d'exploitation du service choisi.
Voir le cockpit AI Jungle OS pour comparer une box done-with-you opérée par son propriétaire à un runtime managé sans masquer le partage des responsabilités.
Puis-je héberger un agent IA ?
Oui. Vous pouvez héberger un agent IA comme service déclenché par requête, instance persistante, worker en arrière-plan ou job exécuté jusqu'à son terme lorsque la ressource correspond au travail. Google Cloud associe les agents sans état pilotés par les requêtes aux services, les boucles persistantes avec état aux instances, les flottes en arrière-plan aux worker pools et les workflows bornés aux jobs (Google Cloud, vérifié le 18 septembre 2026).
La cible de déploiement n'est qu'une ligne. Un agent hébergé peut aussi appeler des modèles externes, conserver sa mémoire dans un stockage séparé, interroger une base vectorielle, utiliser des outils et exécuter du code (Google Cloud, vérifié le 18 septembre 2026). La décision d'hébergement devient exploitable lorsque ces chemins ont aussi des propriétaires.
Faites correspondre le runtime au travail :
- Utilisez un service pour le travail déclenché par requête. Google Cloud présente les services pour les agents sans état qui répondent à un trafic utilisateur variable (Google Cloud, vérifié le 18 septembre 2026).
- Utilisez une instance pour une boucle persistante. Google Cloud présente les instances pour les boucles d'agents dédiées, avec état et toujours actives (Google Cloud, vérifié le 18 septembre 2026).
- Utilisez un worker pool pour les tâches d'arrière-plan en file. Google Cloud présente les worker pools pour des agents distribués qui consomment des tâches sans endpoint HTTP public (Google Cloud, vérifié le 18 septembre 2026).
- Utilisez un job pour une exécution bornée. Google Cloud présente les jobs pour les workflows qui vont jusqu'à leur terme, notamment les tâches planifiées ou par lot (Google Cloud, vérifié le 18 septembre 2026).
Ce sont des exemples tirés du modèle de ressources d'une plateforme, pas des catégories universelles. Appliquez la description de la charge à chaque candidat et vérifiez ses limites réelles.
Où doivent vivre les fichiers, les secrets et les logs ?
Placez chaque enregistrement opérationnel dans un stockage nommé, puis attribuez son accès et sa maintenance. Un agent avec état a besoin d'un stockage durable pour l'historique, la mémoire de travail ou les checkpoints si cet état doit survivre à un redémarrage (Mastra, vérifié le 18 septembre 2026). Google Cloud sépare les composants de mémoire et de base vectorielle dans son architecture de référence (Google Cloud, vérifié le 18 septembre 2026).
Ne regroupez pas ces stockages sous le mot « données ». Écrivez une ligne pour les fichiers téléversés, l'état du workflow, la mémoire des conversations, les documents récupérés et les sorties finales lorsque le cas les utilise. Pour chaque ligne, nommez le stockage, les rôles d'accès, la décision de conservation, le périmètre de sauvegarde et le responsable de reprise. Les sources justifient la séparation de la mémoire, des bases et de l'état runtime ; les choix de conservation et de reprise appartiennent au déploiement (Google Cloud, vérifié le 18 septembre 2026; Mastra, vérifié le 18 septembre 2026).
Séparez les secrets du contenu. Mastra indique que les clés de modèles, chaînes de connexion et clés d'outils doivent rester côté serveur dans des variables d'environnement ou un gestionnaire adapté (Mastra, vérifié le 18 septembre 2026). Notez qui peut modifier chaque secret et comment l'opérateur le révoque.
Traitez les logs comme un chemin de données distinct. Mastra décrit des traces de production qui enregistrent les appels de modèles, les appels d'outils, la récupération en mémoire et la réponse finale (Mastra, vérifié le 18 septembre 2026). Décidez quels événements le cas exige, où ils vont et qui peut les inspecter. Ne déduisez pas la réponse de l'emplacement du calcul.
L'emplacement d'une box n'est pas une carte des données. Le document utile nomme chaque stockage, chemin d'identifiants, destination de logs et service externe utilisé par l'agent.
Qui possède les sauvegardes et la reprise ?
Le responsable de sauvegarde conserve les composants convenus ; le responsable de reprise les restaure et présente le résultat pour acceptation. L'état durable évite que le processus en cours soit l'unique copie du workflow, mais le stockage durable ne définit pas à lui seul une sauvegarde ou une procédure de restauration (Mastra, vérifié le 18 septembre 2026).
Écrivez le passage de relais avant le lancement :
- Périmètre. Listez les fichiers, les stockages d'état, la configuration et les enregistrements inclus. Mastra distingue l'état applicatif et le stockage persistant du processus runtime (Mastra, vérifié le 18 septembre 2026).
- Opérateur. Nommez la personne ou le fournisseur responsable du processus de sauvegarde. Les options managées et auto-hébergées attribuent différemment le travail d'exploitation ; confirmez la tâche pour le service choisi (Mastra, vérifié le 18 septembre 2026).
- Route de restauration. Écrivez quel composant revient en premier et qui exécute chaque action. Mastra traite la reprise après défaillance comme un sujet de production sans imposer une procédure universelle (Mastra, vérifié le 18 septembre 2026).
- Acceptation. Nommez la personne qui vérifie que l'agent restauré accomplit le travail approuvé. Google Cloud sépare les types de runtime et leurs composants connectés ; le périmètre d'acceptation doit correspondre à l'architecture déployée (Google Cloud, vérifié le 18 septembre 2026).
- Preuve. Conservez le dernier compte rendu de sauvegarde et de reprise avec la matrice. Les sources établissent les composants et le besoin de persistance ; ce compte rendu constitue la preuve de l'opérateur pour le déploiement choisi (Mastra, vérifié le 18 septembre 2026).
Si une offre managée dit « sauvegardes incluses », demandez quels stockages et éléments de configuration sont couverts. Si une box opérée par son propriétaire dit « nous contrôlons les données », demandez qui exécute la sauvegarde et qui accepte une restauration. Ce sont des questions d'achat, pas des affirmations sur les deux modèles.
Quelles sont les meilleures plateformes d'hébergement d'agents IA ?
La meilleure plateforme est celle dont le runtime documenté correspond à la charge et dont votre équipe peut réellement opérer la carte des responsabilités. Il s'agit d'une règle éditoriale, pas d'un classement fournisseur. Les sources autorisées documentent des types de ressources et des compromis d'exploitation ; elles n'établissent aucun vainqueur universel.
Comparez chaque candidat à la même charge et à la même carte de responsabilités. Notez chaque modèle, stockage, outil, secret et destination de logs externe. Attribuez les sauvegardes et la reprise. Gardez toute réponse manquante visible comme non résolue. Cette méthode soumet le runtime managé et la box opérée aux mêmes questions.
FAQ
Puis-je héberger un agent IA ?
Oui. Un runtime d'agent peut être déployé comme service déclenché par requête, instance persistante, worker pool ou job, selon la charge (Google Cloud, vérifié le 18 septembre 2026). Vous devez encore nommer les responsables des modèles, de l'état, des outils, des secrets, des logs, des sauvegardes et de la reprise.
Quelles sont les meilleures plateformes d'hébergement d'agents IA ?
Les sources capturées ne permettent pas un classement universel. Comparez le type de runtime et la propriété du calcul, des modèles, des fichiers, des secrets, des logs, des sauvegardes et de la reprise. Choisissez ensuite le candidat adapté à la charge sans tâche requise non attribuée.
Voir le cockpit AI Jungle OS pour examiner une box done-with-you opérée par son propriétaire avec la carte des responsabilités visible.
Written by Tileo, who operates a portfolio of internet businesses on this same cockpit.