IDE web agentique : ce que le terme désigne, et ce qu’une IDE dans le navigateur doit offrir

Une IDE web agentique est un environnement de développement qui tourne dans le navigateur et dans lequel des agents IA ne se contentent pas de suggérer du code : ils exécutent des tâches de façon autonome. Ils planifient, modifient plusieurs fichiers, lancent des commandes dans le terminal, lisent le résultat et se corrigent. « Agentique » décrit cette façon de travailler. « Web » décrit le lieu : il n’y a pas d’installeur, l’espace de travail se trouve sur un serveur, et vous l’ouvrez avec une URL — sur un ordinateur portable, sur le poste du bureau ou sur un téléphone. C’est ce qui la distingue de Cursor, Windsurf ou Kiro, des programmes de bureau qui tournent sur votre appareil. Cet article précise le terme, énonce huit critères et situe le paysage 2026 — UltraNOS compris, avec ses limites.

Deux mots, deux promesses

Le terme « IDE agentique » est bien occupé en 2026. Des listes comme celle de DataCamp citent Cursor, Windsurf, Kiro, Antigravity, Trae, PearAI et Zed. Point commun : elles tournent sur votre machine — la plupart comme dérivés de VS Code.

« IDE web agentique », en revanche, n’est guère établi comme terme à part entière. C’est notable, car la variante web est un autre produit, pas seulement un autre emballage. Les deux parties du terme signifient :

• Agentique : le modèle reçoit des outils (lire et écrire des fichiers, shell, Git, navigateur) et une boucle : réfléchir, agir, vérifier. Il ne s’arrête pas après une suggestion, il travaille jusqu’à ce que l’objectif soit atteint ou qu’un frein s’enclenche.
• Web : l’éditeur, le terminal et les agents vivent sur un serveur. Le navigateur n’est que la fenêtre. Votre appareil n’a besoin ni de chaîne d’outils, ni de version de Node, ni de clé d’API stockée en local.

Un plugin Copilot ne remplit aucun des deux points. Une IDE de bureau avec des agents remplit le premier. Un éditeur en ligne sans agents remplit le second. Une IDE web agentique doit remplir les deux.

Pourquoi « dans le navigateur » n’est pas un détail

On pourrait objecter que savoir si l’agent tourne en local ou sur un serveur relève de l’implémentation. Au quotidien, ce n’est pas le cas.

Chaque appareil est un poste de travail. Une exécution d’agent lancée le matin au bureau continue quand vous fermez l’ordinateur portable. Sur le téléphone, vous voyez la progression, vous pouvez arrêter ou réorienter. Avec une IDE de bureau, l’exécution s’arrête avec la mise en veille.

Des espaces de travail partagés. Quand le projet, le terminal et l’état Git sont sur le serveur, un collègue peut voir exactement le même état — plus de « chez moi, ça marche ».

Les limites de charge sont là où elles agissent. Un agent qui lance par erreur npm install en boucle infinie dévore la mémoire de votre poste de bureau. Sur le serveur, la plateforme peut attribuer à chaque processus enfant du temps de calcul, un nombre de processus et de la mémoire — et l’arrêter avant que la machine ne s’effondre.

Pas de clé sur l’appareil. Les IDE de bureau stockent votre clé de fournisseur en local, dans un fichier de configuration. Dans une IDE web, elle se trouve sur le serveur et elle est contrôlée avant l’envoi — ou, comme dans UltraNOS, remplacée par un substitut avant l’envoi au modèle.

Il faut nommer honnêtement l’envers : sans réseau, rien ne fonctionne. Et la latence à la frappe dans l’éditeur est un sujet bien réel, que les éditeurs de bureau n’ont pas par construction.

Huit critères : ce qu’une IDE web agentique doit avoir

La liste est volontairement exigeante. Une fenêtre de chat à côté d’un éditeur ne suffit pas.

#	Critère	Pourquoi il est obligatoire
1	Un vrai éditeur	Coloration syntaxique, onglets, diagnostics de lint, saut à la ligne. Sans éditeur, c’est un chat avec accès aux fichiers.
2	Un vrai terminal	Un PTY, pas une fenêtre de sortie. L’agent et vous avez besoin du même shell.
3	Git intégré	Statut, commit, branche, push — dans le navigateur, pas via un client séparé.
4	Plusieurs agents en parallèle	Un agent qui lance des sous-agents et affiche leur sortie en direct. Avec des plafonds.
5	Autorisations d’outils	Les actions risquées (suppression, force-push) demandent confirmation — une fois, par session, ou jamais.
6	Frein aux boucles et aux coûts	Détection quand l’agent tente la même chose pour la cinquième fois ; budget de temps par tour.
7	Mémoire entre les sessions	Ce qui a été décidé hier doit être encore là aujourd’hui — sans que vous ayez à le recoller.
8	Protection des clés	Les clés d’API et les mots de passe ne doivent pas se retrouver dans le prompt chez le modèle.

Les points 5 et 6 sont les plus souvent oubliés dans les comparatifs de produits. Ce sont pourtant eux qui décident si un agent peut tourner la nuit sans surveillance. Un agent sans frein aux boucles peut brûler un quota journalier en une heure sans avancer d’un pas.

Le paysage 2026, trié équitablement

Trois groupes, selon le lieu d’exécution.

IDE agentiques de bureau

• Cursor — dérivé de VS Code avec mode agent, de bureau.
• Windsurf — également basé sur VS Code, de bureau, agent « Cascade ».
• Kiro — d’AWS, basé sur VS Code, centré sur les spécifications avant le code.
• Antigravity — l’IDE agentique de Google, de bureau.
• Trae — de ByteDance, de bureau, basé sur VS Code.
• Zed — éditeur natif propre, écrit en Rust, de bureau, avec des fonctions d’agent.

Les six sont de bons outils. Aucun ne tourne dans le navigateur. Qui veut utiliser un téléphone ou la machine de quelqu’un d’autre n’a, avec eux, aucun accès à l’agent en cours d’exécution.

Offres web

• Claude Code Web — l’agent d’Anthropic dans le navigateur, qui travaille sur un dépôt dans un bac à sable cloud. Fort côté agentique, mais sans la partie IDE classique avec éditeur et terminal en libre-service.
• Codex Web d’OpenAI — approche comparable : vous posez la tâche, l’agent travaille dans un bac à sable, une pull request revient.
• Replit — la plus ancienne IDE de navigateur de la liste, désormais avec un agent. Éditeur, terminal, hébergement en un seul endroit.
• Bolt et Lovable — des générateurs d’applications dans le navigateur. Ils produisent des applications complètes à partir de prompts, mais ne sont pas des IDE au sens des huit critères : l’éditeur est accessoire, un terminal manque souvent complètement.

Où se situe UltraNOS

UltraNOS est un espace de travail IA dans le navigateur avec chat multi-agents, éditeur Monaco, Git et un vrai terminal. Ce n’est ni un fork de VS Code ni une application de bureau (hormis une application Android). Ce n’est pas non plus de l’open source — le dépôt est privé. L’hébergement est assuré chez Hetzner à Nuremberg ; l’auto-hébergement est possible sur demande, pas en téléchargement.

Il n’y a pas de modèle propre. L’IA vient du fournisseur que vous choisissez : Claude via API ou CLI, des points de terminaison compatibles OpenAI, Ollama ou un point de terminaison personnel. C’est voulu, mais cela signifie aussi que sans accès à un fournisseur de modèle, l’espace de travail reste muet.

Où UltraNOS remplit les huit critères

Tout ce qui suit figure tel quel dans la fiche fonctionnelle du projet. Là où une limite est connue, elle est indiquée à côté.

1. Éditeur. Monaco (le même composant d’éditeur que dans VS Code) avec onglets, marqueur de modification, Cmd+S, saut à la ligne, lint via ruff et un contrôle JS comme diagnostic, complétion en ligne sous forme de texte fantôme avec 500 ms de délai, ligne de blame au curseur. S’y ajoutent Cmd+P pour les fichiers et Cmd+Shift+F pour les contenus.

2. Terminal. Un PTY via WebSocket, donc un vrai shell. Sur téléphone, une barre de touches fournit Ctrl, Tab et les flèches. Limites : 8 terminaux par locataire, sortie limitée à 512 Ko/s. Un cat sur un fichier de log de 2 Go est donc lent — volontairement.

3. Git. Statut, stage, commit, push, branches, stash, fetch, pull, merge, message de commit généré par IA. Le clone est un clone partiel par défaut, avec des chemins sparse pour les gros dépôts. S’y ajoute UltraForge, un serveur Git propre avec dépôts, tickets et pull requests.

4. Plusieurs agents. Depuis le chat, spawn_agent lance des sous-agents qui apparaissent en direct dans une flotte — avec sortie en streaming, badges d’outils et bouton d’arrêt. Limites : profondeur 2, 16 tâches simultanées au maximum. Les sessions peuvent s’interroger mutuellement (cross-chat, 120 secondes de blocage au maximum). Un orchestrateur de pipeline enchaîne plan, code, test, revue, sécurité et vérification avec un modèle juge.

5. Autorisations d’outils. Pour les outils risqués, une boîte de dialogue apparaît, au choix avec une autorisation groupée pour toute la session, plus un journal. Quatre garde-fous sont préinstallés (no-rm-rf, no-force-push, no-drop-table, no-curl-pipe-bash) ; des règles regex personnelles peuvent s’ajouter. Limite ouverte tirée de la documentation du projet : les garde-fous comparent du texte ; sur la voie CLI, la CLI de Claude exécute Bash elle-même, et les garde-fous y sont plutôt des avertissements que des verrous.

6. Frein aux boucles et aux coûts. La surveillance des boucles compare l’appel d’outil et son résultat. Le troisième appel identique reçoit un avertissement, à partir du cinquième il n’est plus exécuté ; une oscillation entre deux actions est détectée à part. Chaque tour a un budget de temps, 45 minutes par défaut. En cas d’erreurs interruptibles (limite de jetons, 429, 5xx), un « Continuer » suit automatiquement, deux fois au plus. Le rythme par fournisseur respecte Retry-After et limite le débit fournisseur par fournisseur.

7. Mémoire. Une mémoire persistante entre les sessions (Centre AI), un contrôle du contexte par session avec résumé de l’historique ancien, et, depuis le 5 septembre, un redémarrage du contexte avec jeu de données de transmission au lieu d’une simple compression. 60 skills fournis dans 9 catégories.

8. Protection des clés. Le composant s’appelle cloak. Il remplace les clés d’API, les mots de passe et les adresses e-mail par des substituts comme CLOAK_SECRET_… avant que la requête n’atteigne le fournisseur, et retraduit la réponse. Sur l’instance hébergée, il tourne en profil enforce ; vérifiable via GET /api/health, champ cloak. Deux limites sont importantes : d’abord, la détection repose sur des motifs — un secret sans préfixe connu, sans contexte d’affectation et à faible entropie passe à travers. Ensuite, sur la voie CLI (claude-instanz, la voie active en production), seuls le prompt et le prompt système sont masqués ; les résultats d’outils que la CLI lit elle-même ne passent pas par cloak. La couverture complète, tours d’outils compris, vaut pour les voies API avec clé personnelle. Détails dans l’article API-Keys im Prompt schützen.

S’y ajoute ce dont une IDE web a besoin pour que le serveur ne bascule pas : des limites de charge pour chaque processus enfant (temps de calcul, taille de fichier, nombre de processus, mémoire via cgroup), un bac à sable bwrap pour le terminal et les builds, et une surveillance de la charge pour l’espace libre et la mémoire. Run/Preview démarre des serveurs de développement derrière un reverse proxy, sans ouvrir de port.

Gratuit ?

Chez UltraNOS, l’offre gratuite s’appelle Starter et coûte 0 €. Pro est à 19 €/mois, Team à 49 €/mois, avec 14 jours d’essai. Dans l’offre Starter, vous utilisez soit une clé de fournisseur personnelle, soit le quota de l’accès mis à disposition par l’exploitant ; le quota de stockage est de 200 Mo, de 5 Go dans Pro, illimité dans Team. Aucun prix n’inclut les coûts de modèle — votre fournisseur les facture.

Chez les autres, « gratuit » recouvre des choses très différentes. Les IDE de bureau proposent en général un palier avec un quota limité de requêtes ou de modèles propres, et les conditions changent souvent. Replit et les générateurs d’applications ont eux aussi des paliers d’entrée, mais souvent avec une limite de temps de calcul ou de projets publiés. Seule la page de tarifs de chacun fait foi — je n’y recopie volontairement aucun chiffre qui serait faux la semaine prochaine.

Une question vaut la peine chez chaque fournisseur : puis-je apporter ma propre clé et, si oui, où va-t-elle ? Cela décide des coûts et de qui voit vos prompts.

Pour qui ce n’est pas adapté

Une IDE web agentique n’est pas le bon choix pour tout le monde.

• Travail hors ligne. Dans le train sans réseau, une IDE web est un onglet vide. Qui travaille régulièrement hors ligne a besoin de Zed, de Cursor ou tout simplement de VS Code.
• Frappe sensible à la latence. Un éditeur natif réagit en moins d’une milliseconde. Pas à travers le réseau.
• Grandes chaînes d’outils natives. Qui a besoin de Xcode, d’Android Studio avec émulateur ou d’Unreal Engine ne peut pas se passer du poste de bureau. L’application Android d’UltraNOS est un client, pas une machine de build.
• Qui doit exploiter son modèle lui-même et n’a pas de serveur pour cela. UltraNOS n’apporte aucun modèle. Ollama sur du matériel personnel fonctionne, mais c’est votre matériel.
• Qui pose l’open source comme condition. UltraNOS ne l’est pas. C’est une condition légitime, et elle exclut ce produit.

Tout le reste — travail depuis des appareils différents, longues exécutions d’agents, équipes avec un état commun, clés qui ne doivent pas se trouver sur l’ordinateur portable — est le cas pour lequel le terme a été conçu.

FAQ

Qu’est-ce qu’une IDE agentique ?

Un environnement de développement dans lequel le modèle d’IA reçoit des outils et travaille en boucle : planifier, modifier des fichiers, exécuter des commandes, vérifier le résultat, corriger. La différence avec un simple assistant de suggestions est que l’agent mène une tâche à son terme au lieu d’attendre la prochaine frappe. Une IDE web agentique fait cela dans le navigateur, avec l’espace de travail sur un serveur.

Quelle IDE agentique est gratuite ?

La plupart des fournisseurs ont un palier gratuit avec un quota limité ; ce qu’il contient exactement figure sur la page de tarifs de chacun et change souvent. Chez UltraNOS, l’offre Starter coûte 0 € ; vous utilisez une clé de fournisseur personnelle ou le quota de l’accès de l’exploitant. Les coûts de modèle s’ajoutent chez chaque produit, soit dans l’abonnement, soit via votre propre accès.

IDE agentique ou Copilot : quelle différence ?

Un Copilot complète ce que vous êtes en train de taper, ou répond à des questions dans le chat. Un agent reçoit un objectif et travaille dans cette direction à travers plusieurs fichiers, commandes et étapes de vérification. En pratique : avec le Copilot, vous êtes présent à chaque étape ; avec l’agent, vous donnez des autorisations et lisez le résultat. Les deux ont leur place, et UltraNOS propose aussi le mode Copilot avec la complétion en ligne dans l’éditeur.

Une IDE web fonctionne-t-elle hors ligne ?

Non. L’éditeur, le terminal et les agents tournent sur le serveur ; sans connexion, l’onglet du navigateur est inutilisable. Une interface installée comme PWA démarre certes, mais ne peut rien exécuter. Qui doit travailler hors ligne a besoin d’une IDE de bureau.

Puis-je utiliser mes propres modèles ?

Chez UltraNOS, oui : Claude via API ou CLI, n’importe quel point de terminaison compatible OpenAI, Ollama pour les modèles locaux, ou un point de terminaison personnel. Le routage des modèles permet d’attribuer séparément des modèles à huit tâches (chat, tâches, sous-tâches, message de commit, planification, revue, résumé et d’autres). UltraNOS n’a pas de modèle propre. Chez d’autres fournisseurs, la clé personnelle est parfois possible, parfois non — cela figure sur leurs pages de tarifs.

Vos clés restent chez vous : le reste tourne dans le navigateur.

UltraNOS est l’IDE web agentique : des agents IA en parallèle, un éditeur, git et un terminal. cloak remplace les clés d’API et les mots de passe avant qu’un prompt n’atteigne le fournisseur. Hébergé en Allemagne, 14 jours gratuits.

Essayer 14 jours gratuitement →