Ce dont les agents IA ont vraiment besoin côté infrastructure : 7 exigences, et là où l'hébergement pensé pour les humains coince

La plupart des hébergements ont été conçus autour d'une personne au clavier : un formulaire d'inscription, une carte, un tableau de bord, un e-mail quand quelque chose tourne mal. Un agent IA qui a besoin de puissance de calcul ne cadre avec aucune de ces étapes. Il ne résout pas de captcha, ne distingue pas une page de maintenance d'une page cassée et ne remarque pas qu'il a créé quarante fois le même serveur.

On est tenté de dire « donnez-lui simplement une API ». C'est la première exigence, pas la dernière. Voici les sept qui nous semblent compter, tirées de la construction de notre propre serveur MCP et de notre API REST pour agents. Pour chacune : ce qui se passe sans elle.

1. Tout ce dont un agent a besoin est programmable

Créer, inspecter, redimensionner et supprimer des ressources doit fonctionner sans navigateur. Y compris les parties ennuyeuses : connaître le prix avant d'acheter, vérifier qu'un emplacement a de la capacité, lire le mot de passe d'une nouvelle machine, résilier.

Sans cela : l'agent fait 80 % du chemin et bute sur la seule étape qui demande un clic, et un humain doit finir le travail de toute façon. Une API partielle est souvent pire qu'aucune, parce qu'elle invite à une automatisation qui ne peut pas aboutir.

2. Des erreurs sur lesquelles un programme peut agir

Un agent lit une réponse et décide de la suite. Un corps JSON avec un code stable (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded avec l'heure de réinitialisation) est quelque chose sur quoi il peut bifurquer. Une page d'erreur HTML, ou une 500 au message flou, le laisse deviner — et souvent réessayer quelque chose qui n'aboutira jamais.

Sans cela : des boucles de réessai. Les échecs d'agents les plus coûteux ne sont généralement pas de mauvaises décisions, mais le même appel en échec répété des milliers de fois.

3. Payer sans humain dans la boucle

Les paiements par carte regorgent d'étapes conçues pour confirmer qu'une personne est présente : codes 3-D Secure, confirmations dans l'appli bancaire, vérifications d'identité. Elles sont bonnes contre la fraude et impossibles pour un logiciel. Un solde prépayé, rechargé à l'avance (chez nous, souvent en stablecoins), permet à un agent de payer ce qu'il utilise sans qu'un humain approuve chaque débit.

Sans cela : soit un humain approuve chaque achat, ce qui annule l'intérêt, soit quelqu'un confie une carte à un agent, un risque que personne ne devrait prendre.

4. Des plafonds de dépenses stricts

Un solde prépayé limite le pire cas à ce qu'il contient. Cela peut encore faire beaucoup. Un plafond quotidien et mensuel, en dollars, appliqué par la plateforme plutôt que par les bonnes intentions de l'agent, transforme un agent qui boucle en petite perte. Le plafond doit échouer bruyamment, avec une erreur que l'agent reconnaît, et arrêter ou mettre en pause ce qui tourne.

Sans cela : vous découvrez la boucle par le solde. Notre facturation des sandboxes a des plafonds pour cette raison, et la page des garde-fous MCP suggère quelles actions devraient tout simplement exiger l'approbation d'un humain.

5. Une puissance de calcul à la bonne granularité

Les agents produisent trois sortes de travail très différentes :

• Secondes : exécuter un extrait généré, vérifier une réponse, tester un correctif.
• Heures : une évaluation, un scraping, une longue compilation.
• En continu : un bot, une API, un worker planifié.

Une plateforme qui ne propose que des serveurs au mois rend la première absurdement chère ; une qui ne propose que des sandboxes éphémères rend la troisième fragile. Une tâche de 20 secondes sur une machine facturée à l'heure paie 59 minutes de rien. Comment fonctionne la facturation à la seconde montre où chaque modèle cesse d'avoir du sens.

Sans cela : les agents paient trop cher le travail court ou font tourner des services durables sur une infrastructure qui n'était pas faite pour rester allumée.

6. L'isolation par défaut

Le code qu'écrit un agent est du code que personne n'a relu. Il doit tourner là où il n'y a rien de précieux : pas sur l'hôte de l'agent, pas sur un serveur qui détient vos clés, pas sur la machine qui envoie vos e-mails. Concrètement, une VM ou une microVM séparée par tâche, supprimée ensuite. Les niveaux d'isolation pour le code non fiable comparent les options ; les microVM Firecracker expliquées simplement montrent pourquoi un noyau à soi compte.

Sans cela : la première injection de prompt qui se glisse dans du code généré accède à tout ce que l'hôte de l'agent peut atteindre.

7. De la visibilité et un interrupteur

La personne responsable d'un agent doit voir ce qu'il a fait et pouvoir l'arrêter vite. Cela suppose l'utilisation et le coût par ressource, la liste de tout ce que l'agent a créé et un moyen de tout supprimer. Les identifiants doivent être révocables et suffisamment éphémères pour qu'un jeton divulgué ne reste pas valide indéfiniment, avec un renouvellement qui ne nécessite pas de personne.

Sans cela : le ménage devient de l'archéologie. Les ressources oubliées continuent d'être facturées ; un jeton divulgué continue de fonctionner.

Ce dont les agents n'ont pas besoin

Tout aussi parlant, ce qui n'aide pas : des tableaux de bord pensés pour la vente additionnelle, des e-mails d'onboarding, des offres dont les vraies limites sont en note de bas de page, des prix affichés seulement après inscription. Rien de cela n'est lisible par un logiciel, et une partie induit activement en erreur un modèle qui prend le texte au pied de la lettre.

Ce qui reste non résolu

Tout n'est pas un problème d'ingénierie résolu.

• La responsabilité. Quelqu'un est responsable de ce qu'un agent fait d'un compte. Les plateformes ont besoin d'un moyen de rattacher l'activité automatisée à une personne responsable sans lui imposer chaque étape.
• Les abus. L'inscription ouverte et entièrement automatisée est exactement ce que veulent aussi les fraudeurs. Chaque plateforme qui sert des agents arbitre entre un accès sans friction et les fermes de comptes ou le minage, et aucune n'a de réponse parfaite.
• Les parcours longs. Les agents échouent encore plus souvent sur des processus en dix étapes que sur des appels isolés. L'infrastructure peut aider en rendant chaque étape idempotente et son état facile à interroger, afin qu'un réessai reprenne au lieu de dupliquer.

Là où nous en sommes

Nous avons essayé de construire pour ces exigences plutôt qu'en les contournant : un serveur MCP et une API REST couvrant tout le cycle de vie, des erreurs lisibles par machine, un solde prépayé, des plafonds de dépenses, des sandboxes de code facturées à la seconde pour le travail court et des serveurs au mois comme le tarif AI agent pour le travail long. Un parcours côté sandboxes figure dans sandbox pour agents IA. Jugez toutefois la liste sur ses propres mérites ; c'est une check-list utile pour toute plateforme à laquelle vous confiez un agent.