Daytona : un cloud dédié aux agents IA
Daytona lève 60 millions de dollars à une valorisation d’un milliard pour son cloud d’agents. Enjeux, architecture et critères pour les entreprises européennes.
Daytona veut donner un ordinateur à chaque agent IA
L'intelligence artificielle ne se limite plus à des modèles qui répondent à une question dans une fenêtre de discussion. Les agents peuvent enchaîner des tâches, lancer des outils et exécuter du code. Et du coup, il y a une question qui devient vite centrale, même si elle est souvent moins visible que le choix du modèle : où ces opérations tournent-elles, concrètement, et dans quel environnement isolé ?
C'est là que Daytona se positionne. La jeune pousse new-yorkaise annonce une levée de 60 millions de dollars en série B, menée par FirstMark Growth, pour une valorisation d'un milliard de dollars. L'entreprise dit aussi avoir levé 91 millions de dollars au total. Son objectif : proposer un cloud pensé pour des agents qui exécutent des tâches courtes, nombreuses, parfois persistantes - plutôt que pour des services conçus pour rester allumés en continu.
La levée et la liste d'investisseurs attirent forcément l'attention. Mais une valorisation ne prouve pas, à elle seule, que le produit répond à un besoin bien défini. Pour les équipes techniques et les entreprises européennes, la vraie question est ailleurs : le modèle d'exécution de Daytona résout-il un problème réel, et dans quels cas peut-il être utile ? Voici ce qu'on sait, ce que l'entreprise avance, et ce qu'il faut vérifier avant d'y voir une brique crédible de son architecture.
Ce que Daytona annonce
Daytona Platforms dit avoir bouclé une série B de 60 millions de dollars à une valorisation d'un milliard de dollars. Le tour est mené par FirstMark Growth, qui avait déjà mené sa série A de 24 millions de dollars en février. La société, fondée il y a trois ans et basée à New York, annonce 91 millions de dollars levés au total.
Parmi les investisseurs annoncés, on retrouve aussi des noms bien connus : Patrick Collison (Stripe), Tobi Lütke (Shopify), Aravind Srinivas (Perplexity), Eric Yuan (Zoom), Olivier Pomel (Datadog), Adam D'Angelo (Quora, et membre du conseil d'administration d'OpenAI), ainsi que Brendan Foody (Mercor). Qualcomm Ventures, Samsung Next et Okta Ventures figurent également dans la liste publiée.
Tout ça signale un intérêt, et ça donne de la visibilité. Mais ça ne suffit pas à trancher sur la qualité du produit, l'adoption par les clients ou la rentabilité. Ce sont des signaux à suivre, pas des conclusions.
Le cœur de l'offre : fournir un environnement d'exécution pour des agents capables de lancer des tâches et d'utiliser des outils. Le fondateur, Ivan Burazin, décrit des agents qui démarrent « des milliers de tâches courtes et avec état » que les équipes n'ont pas forcément prévues à l'avance. Il explique que les infrastructures cloud pensées pour des services longuement actifs ne collent pas toujours à ces usages.
Daytona présente sa plateforme comme un « ordinateur » attribué à chaque agent. L'entreprise affirme proposer des environnements isolés basés sur Linux, Windows et macOS, avec aussi de l'accès à des GPU et à d'autres services, au sein d'une même plateforme. Le détail disponible publiquement reste toutefois incomplet : on ne peut pas, à partir de ça, évaluer finement le niveau d'isolation, les garanties de disponibilité, la grille tarifaire, ni les options de résidence des données.
Pour une entreprise, la nuance compte. Une annonce décrit un positionnement ; une décision d'architecture doit s'appuyer sur des éléments vérifiables, un test représentatif et des engagements contractuels.
Pourquoi les agents réclament une autre infrastructure
Un service web « classique » est souvent pensé pour tourner en continu : il reçoit des requêtes, les traite et répond, avec une architecture que l'équipe a préparée (composants, ressources, sécurité, procédures). Rien n'interdit d'héberger des agents là-dessus. Mais le comportement d'un agent peut rendre certains choix beaucoup plus difficiles à anticiper.
Un agent peut exécuter du code, lire ou modifier des fichiers, installer des dépendances, utiliser un navigateur et d'autres outils. Une tâche peut s'arrêter rapidement, reprendre plus tard, ou échouer en plein milieu. Et si plusieurs agents tournent en parallèle, l'infrastructure doit gérer la création et la suppression d'environnements à grande échelle, avec des besoins variables selon les tâches.
Autrement dit : le défi n'est pas seulement de « faire tourner un modèle dans le cloud ». Même si le modèle peut être hébergé ailleurs, il faut aussi :
- un espace d'exécution contrôlé,
- les bons fichiers et outils transmis au bon moment,
- des permissions limitées,
- une observation de ce qui se passe,
- et un nettoyage quand la tâche est finie.
Dans ce contexte, la sécurité et l'exploitation ne sont pas « des détails ». Elles deviennent l'essentiel.
Des tâches courtes ne signifient pas des tâches simples
Un traitement de quelques secondes peut déjà être risqué s'il manipule des données sensibles ou exécute du code fourni par un utilisateur. À l'inverse, un agent qui tourne longtemps consomme des ressources et maintient un état qu'il faut sauvegarder, puis restaurer ou fermer proprement.
Donc, la durée ne suffit pas. Il faut regarder le profil réel des tâches : fréquence, durée, ressources, accès réseau, nature des données, et niveau d'autonomie. Résumer des documents internes n'entraîne pas les mêmes risques qu'un agent autorisé à exécuter des commandes ou à modifier des dépôts logiciels.
C'est dans ce cadre que l'argument de Daytona a du sens - au moins sur le papier. Si les agents multiplient les environnements isolés, l'automatisation de leur cycle de vie peut éviter de reconstruire les mêmes briques projet après projet. Mais si les tâches sont peu nombreuses, prévisibles et déjà bien couvertes par l'infrastructure actuelle, une plateforme spécialisée risque surtout d'ajouter une couche supplémentaire et un coût... sans gros bénéfice.
Le vrai enjeu : maîtriser le cycle de vie
Créer un environnement, c'est une étape. En production, il faut aussi décider :
- qui peut créer quoi,
- quelles ressources l'agent peut utiliser,
- combien de temps l'environnement reste actif,
- et ce qu'il advient des données à la fin.
Il faut également pouvoir diagnostiquer un échec sans conserver indéfiniment des fichiers potentiellement sensibles.
Concrètement, pour les équipes, ça revient à poser des questions très pratiques : peut-on limiter l'accès réseau ? Les tâches peuvent-elles utiliser des secrets, et comment sont-ils protégés ? Les journaux permettent-ils de comprendre ce qui s'est passé sans exposer des données confidentielles ? Et si un agent ne se termine pas, que se passe-t-il ?
Une plateforme ne « convient » que si ces réponses correspondent vraiment aux risques et aux contraintes opérationnelles du projet.
Ce que change le modèle du « un ordinateur par agent »
La formule de Daytona est facile à comprendre : chaque agent disposerait de son propre ordinateur. Mais il faut la lire comme une image d'architecture, pas comme la promesse d'une machine physique dédiée.
Le point utile, si c'est bien implémenté, c'est la création d'environnements d'exécution isolés associés à des tâches distinctes. Cette séparation peut limiter les interférences : chaque environnement a ses propres fichiers, dépendances et processus. On réduit ainsi le risque qu'une tâche modifie « par accident » l'espace d'une autre.
Daytona annonce aussi plusieurs systèmes d'exploitation (Linux, Windows, macOS selon l'offre), ce qui peut aider à coller à certains besoins de compatibilité. Mais l'annonce ne donne pas assez d'éléments pour comparer sérieusement les performances, les limites et les garanties.
Isolation : utile, mais à vérifier
Le mot « sandbox » ne suffit pas. Il faut connaître le modèle d'isolation, les permissions par défaut, la façon dont le réseau est géré, le traitement des secrets, et la manière de supprimer les données après exécution. Et il faut voir comment la plateforme réagit à des tâches malveillantes... ou juste mal conçues.
Dans un contexte européen, l'analyse doit aussi couvrir les données personnelles et les obligations liées au traitement. Le RGPD ne se résume pas au fait de choisir un fournisseur « européen ». Il faut comprendre quelles données sont transmises, où elles sont traitées, qui peut y accéder, et quelles clauses encadrent ce traitement. Localisation, conservation, suppression : ça doit être documenté.
Un test simple consiste à lancer une tâche sans données sensibles, puis à vérifier les journaux, les permissions et le nettoyage après exécution. Ensuite, il faut réessayer avec des scénarios d'erreur : interruption, dépassement de durée, tentative d'accès non autorisé, reprise après échec. Une démo fluide ne remplace pas ces essais.
Plusieurs systèmes d'exploitation, un avantage à mesurer
Le support annoncé de Linux, Windows et macOS peut attirer les équipes qui ont besoin de reproduire des environnements différents. Dans certains cas, ça évite d'avoir à maintenir plusieurs systèmes d'exécution séparés.
Mais plus de choix, c'est aussi plus de configurations à tester et à superviser. La question pratique : ces environnements correspondent-ils à des cas d'usage réels chez vous ?
Si votre automatisation tourne essentiellement sur des scripts Linux, payer pour une compatibilité étendue peut être inutile. En revanche, si vous exécutez réellement des tâches liées à plusieurs systèmes (tests, outillage, compatibilité applicative), la valeur dépendra de deux choses : la disponibilité des outils nécessaires et la performance.
Même logique pour les GPU : ce n'est pas parce qu'ils sont « disponibles » que votre cas d'usage y est vraiment couvert. Il faut vérifier les types de tâches compatibles, les limites d'allocation, la disponibilité et le coût.
Sans ces détails, comparer Daytona à votre infrastructure existante (ou à d'autres fournisseurs) reste difficile.
Une levée de fonds impressionnante, mais pas une preuve de marché
Une valorisation à un milliard de dollars place Daytona parmi les jeunes entreprises les plus regardées. Elle dit quelque chose des conditions de financement et des attentes des investisseurs à ce moment-là. Mais ça ne mesure ni le chiffre d'affaires, ni la fidélité des clients, ni la capacité à faire tourner une plateforme de manière durable.
La liste des investisseurs raconte aussi une partie de l'histoire. Des dirigeants et fondateurs reconnus participent, mais ce n'est ni une recommandation d'achat, ni une validation indépendante de toutes les affirmations techniques.
Pour évaluer une jeune pousse, les signaux les plus utiles restent ailleurs : usage réel, rétention, qualité du support et capacité à tenir ses engagements.
Ce que les clients devront regarder
Pour les équipes qui testent ou envisagent ce type de service, la valorisation passe au second plan. Les indicateurs à surveiller :
- La fiabilité : les environnements démarrent-ils et se terminent-ils de façon prévisible ? Les échecs sont-ils observables et récupérables ?
- Le coût complet : il faut compter le temps d'ingénierie, les ressources perdues, les sorties de données et les environnements de test.
- La sécurité : l'isolation, les contrôles d'accès, la gestion des secrets et les journaux sont-ils adaptés aux données traitées ?
- La portabilité : peut-on déplacer les tâches ailleurs si vos besoins ou vos tarifs changent ?
- La maturité : quelles garanties de disponibilité, de support et de continuité sont contractualisées ?
Une petite entreprise peut aussi être plus agile qu'un fournisseur généraliste. Mais elle peut aussi créer un risque de dépendance plus élevé si une fonction critique repose sur une plateforme encore jeune. Ce n'est pas forcément un motif de rejet ; c'est quelque chose à intégrer dans le choix.
Pour un projet pilote, mieux vaut limiter le périmètre, fixer un budget et prévoir un scénario de sortie. Pour une fonction critique, il faut en plus vérifier les garanties contractuelles, les procédures de reprise et la façon de récupérer les données et les configurations.
L'objectif n'est pas d'exiger une certitude parfaite. C'est de rendre le risque explicite avant de s'engager.
Comment évaluer ce type de cloud en entreprise
La bonne décision n'est pas de choisir entre « plateforme spécialisée » et « ancien cloud » comme si c'était un duel. L'enjeu, c'est de comparer coût et complexité pour le même type de travail.
Selon vos équipes, vous pouvez :
- gérer vous-mêmes des environnements isolés,
- utiliser une plateforme cloud existante,
- ou tester un fournisseur dédié à l'exécution d'agents.
Un essai limité aide à passer des impressions aux mesures. Choisissez un cas réel, mais pas trop sensible. Puis définissez à l'avance ce qui compte : temps de démarrage, coût par tâche, taux d'échec, facilité de diagnostic, et effort pour intégrer l'environnement à votre produit.
Une grille de décision en quatre étapes
- Décrivez les tâches. Notez leur fréquence, leur durée, les ressources nécessaires, les outils utilisés et les données accessibles. Distinguez ce qui est déjà en production de ce qui relève encore d'un prototype.
- Définissez les frontières de sécurité. Précisez les droits de chaque agent, les accès réseau autorisés, les secrets disponibles et la politique de conservation. Ne commencez pas par donner des permissions très larges « pour simplifier ».
- Mesurez le coût réel. Comparez la plateforme avec l'infrastructure existante, en intégrant exploitation, développement et incidents. Un prix bas à l'exécution peut cacher un coût élevé d'intégration, et l'inverse existe aussi.
- Testez la sortie. Vérifiez si vous pouvez exporter les données, reproduire les tâches ailleurs et arrêter le service sans casser le produit. Une dépendance acceptable, c'est une dépendance que l'équipe a choisie en connaissance de cause.
Quand une plateforme spécialisée a du sens
Une solution dédiée devient plus pertinente quand les agents créent beaucoup d'environnements, que les tâches sont variées, et que votre équipe passe trop de temps à construire les mécanismes d'exécution plutôt qu'à développer le produit.
Elle peut aussi être logique si certains systèmes ou ressources sont nécessaires et difficiles à obtenir avec vos outils actuels.
À l'inverse, si l'usage en est encore à l'exploration, à une utilisation rare, ou à des cas simples à isoler dans votre infrastructure actuelle, une nouvelle plateforme peut compliquer le système avant d'avoir prouvé sa valeur.
Dans la pratique, commencez par tester un parcours complet - création, exécution, observation et suppression - plutôt que de trancher sur une liste de fonctionnalités.
Pour une entreprise française ou européenne, ajoutez à tout ça des exigences de conformité et de gouvernance : données personnelles, clauses contractuelles, lieux de traitement, sous-traitants, et capacité à répondre aux demandes internes. Rien de tout cela n'est spécifique à Daytona : c'est valable pour tout fournisseur qui exécute du code ou traite des données pour votre organisation.
Conclusion
Daytona répond à une évolution concrète : quand les agents exécutent davantage d'actions, il faut penser à l'environnement qui les fait tourner, pas seulement au modèle qui produit les réponses. L'idée d'un espace isolé par agent peut simplifier certains usages et réduire une partie du travail d'infrastructure à maintenir.
Mais ça ne supprime pas le travail de vérification : permissions, coûts, conformité, et dépendance à un fournisseur.
La levée de 60 millions de dollars et la valorisation annoncée d'un milliard donnent à Daytona de quoi avancer. Elles ne remplacent pas un test sérieux en conditions réelles. Si vous évaluez ce type de plateforme, choisissez une tâche représentative, mesurez le coût complet, et testez le comportement en cas d'échec comme lors de la suppression de l'environnement. C'est à cette échelle - pas à celle des annonces financières - que se prend une décision d'architecture.
Pour aller plus loin, consultez l'annonce de la levée de fonds publiée par TechCrunch.