Meilleurs outils de Vibe Coding en 2026 : comparaison de 12 générateurs et agents de code

Le moment où un outil de Vibe Coding m’impressionne le plus est aussi celui où je redouble de prudence. Un seul prompt peut produire un écran d’application soigné, mais un bel écran ne signifie pas qu’une exigence est satisfaite. Ce qui a changé, la possibilité pour une autre personne de reprendre le projet et le point auquel revenir après l’échec d’un build n’apparaissent généralement qu’au tour suivant.

C’est pourquoi un classement unique de la première à la douzième place me paraît peu utile. Replit, Lovable, Bolt, v0, Base44 et Google AI Studio excellent lorsqu’il faut transformer une idée en première version exécutable. Codex, Claude Code, Cursor, Windsurf, l’application GitHub Copilot et Google Antigravity sont plus pertinents lorsqu’un projet existe déjà et qu’il faut examiner ses fichiers, commandes, contrôles et différences. Ces groupes se recoupent, mais leurs points de départ restent distincts.

La question n’est donc pas « Quel est le meilleur outil ? », mais « À ce stade du projet, quel type de méthode choisirais-je et de quelles preuves aurais-je besoin avant de continuer ? »

Deux types d’outils

Je classe les produits selon leur méthode de départ, et non selon une étiquette définitive attachée à chaque marque.

Un générateur d’applications par IA réunit un prompt, la configuration du projet, un aperçu en direct et, généralement, l’hébergement. C’est un point de départ pratique lorsqu’aucun projet n’existe et que le premier besoin est un parcours utilisateur exécutable avec peu de configuration.

Un agent de code par IA agit plus directement sur les fichiers, les commandes, les tests et les modifications de contrôle de version. Il devient plus utile lorsqu’un projet existe déjà et que la décision suivante dépend de son inspection ou de sa modification dans un périmètre maîtrisé.

L’assistant de code en ligne constitue un troisième mode, exclu de cette comparaison. La complétion en ligne est précieuse pour une personne qui écrit déjà du code, mais elle n’offre pas le même parcours de bout en bout qu’un générateur ou un agent de projet.

Ces modes ne forment pas une progression du plus faible au plus puissant. Plus un agent peut toucher de fichiers et d’outils, plus j’ai d’éléments à vérifier. Je commence généralement un prototype délimité avec un générateur et ne passe à un agent que si la tâche suivante exige réellement un contrôle au niveau des fichiers. Le cours AILesson Vibe Coding pour débutants part de la même distinction plutôt que de prescrire une marque.

Ma méthode de comparaison

J’ai utilisé deux niveaux de preuve, vérifiés le 20 août 2026.

• Le comportement documenté par le produit provient de la documentation officielle, des pages d’assistance et des notes de version actuelles. Il décrit la méthode proposée, mais ne prouve pas que le produit a accompli notre tâche.
• Les preuves observées dans le projet proviennent d’un build, d’un test, d’une modification ou d’un transfert conservé. Elles n’étayent que le comportement effectivement contrôlé.

Seul le parcours de Replit à Codex peut être retracé dans le projet conservé de liste de contrôle pour une bourse aux livres de quartier utilisé dans le cours AILesson. Pour les dix autres produits, j’ai étudié les méthodes officielles actuelles ; je ne présente pas cette lecture de documentation comme si j’avais exécuté le même test pratique dans chaque produit. Une page de fonctionnalité peut confirmer la synchronisation Git, les points de contrôle ou les tests dans le navigateur, mais pas qu’un outil accomplirait mieux la consigne qu’un autre.

Le projet observé partait d’un cahier des charges délimité : construire une liste mobile avec catégories, état d’achèvement, filtres, persistance après actualisation, réinitialisation récupérable et aucune donnée personnelle réelle. La tâche ultérieure confiée à l’agent de code était volontairement plus petite : inspecter un conflit de dépendance au niveau d’un fichier, proposer une modification circonscrite et préserver le comportement existant de l’application.

Le dossier du projet distingue les exigences satisfaites, partiellement satisfaites, échouées et non testées. Je ne transformerai pas une exécution variable d’un modèle en classement définitif de qualité. Elle sert à fixer les critères de comparaison : comportement en cours d’exécution, modifications réelles des fichiers, sortie des commandes, voie de récupération, état du transfert et limite de publication.

Ma sélection de départ

• Commencez avec Replit si vous souhaitez un seul espace pour planifier, construire, prévisualiser, créer des points de contrôle, manipuler les fichiers et publier, et si vous êtes prêt à tester le résultat dans cet espace.
• Commencez avec Lovable ou v0 si l’itération visuelle est la principale inconnue et qu’un transfert appuyé sur Git est important.
• Commencez avec Bolt si vous privilégiez un projet Web dans le navigateur, exécutable immédiatement, avec accès au code, historique des versions et GitHub comme porte de sortie.
• Commencez avec Base44 si les données, l’authentification, les autorisations et l’hébergement intégrés économisent davantage de travail que la dépendance à la plateforme n’en crée.
• Commencez avec Google AI Studio si les capacités Gemini, la génération Android native ou le déploiement Cloud Run sont au cœur du produit.
• Commencez avec un agent de code — Codex, Claude Code, Cursor, Windsurf, l’application GitHub Copilot ou Google Antigravity — si un dépôt existe déjà et que le prochain résultat doit être une modification vérifiable et testable.

Il s’agit d’une sélection initiale, pas de catégories immuables. Les générateurs ajoutent des dépôts et des éditeurs ; les agents de code pilotent des navigateurs et produisent des preuves visuelles. Je choisirais toujours en fonction du prochain problème non résolu du projet, sans rester fidèle à une catégorie.

Générateurs d’applications

Si j’ai une idée délimitée mais aucun projet, voici les six produits que j’examinerais d’abord. Tous réduisent la configuration. Ils se distinguent par l’emplacement du code, la propriété du backend, le retour des modifications visuelles dans le code source et ce qui subsiste lorsque le projet quitte la plateforme.

Replit : tout dans un même espace de travail

Replit est né comme environnement de programmation dans le navigateur avant de devenir une plateforme full-stack de création logicielle. Replit Agent, lancé en 2024, y a ajouté la création et le déploiement d’applications en langage naturel. Je place Replit en tête des générateurs non parce qu’il remporte chaque critère, mais parce qu’il rapproche les preuves de construction, d’exécution et de récupération — et parce qu’il est le seul ici étayé par un dossier de projet observé complet.

La documentation de Replit Agent décrit planification, construction, tests et points de contrôle dans le même espace. Cette intégration aide les débutants : une exigence échouée peut être comparée à l’aperçu en cours d’exécution, aux fichiers, au Shell et à un point de contrôle antérieur sans déplacer aussitôt le projet.

Agent peut démarrer en mode Plan, écrire dans plusieurs fichiers, installer des dépendances, déboguer les échecs et améliorer l’application. Captures d’écran, fichiers et notes Canvas peuvent fournir un contexte visuel ou métier difficile à exprimer dans un prompt. Replit réunit aussi bases de données, authentification, Secrets, Git et Deployments : un projet peut passer de rien à une application publiée avec données persistantes sans chaîne d’outils locale préalable. Ses points de contrôle peuvent couvrir code, contexte de l’agent, tâches et état de la base connectée, au-delà d’un simple diff textuel.

Documentation officielle de première application Replit, consultée le 20 août 2026. La capture situe l’espace Agent et Preview ; elle ne prouve pas qu’une application générée satisfait ses exigences.

L’exécution du cours a aussi montré la limite de cette commodité. Un aperçu soigné ne prouvait pas l’exigence « aucune dépendance externe cachée ». Une analyse des fichiers a trouvé des liens Google Fonts inutilisés, et l’export ciblé s’est révélé vérifiable mais impossible à reconstruire indépendamment, faute d’informations sur les dépendances de l’espace. Replit restait utile ; les preuves s’arrêtaient simplement avant la reproductibilité.

Pour obtenir rapidement un parcours utilisateur exécutable et le tester dans l’espace, je commencerais par Replit. Je ne considérerais toutefois pas « Download source » comme une preuve de reproductibilité. Exporter les fichiers et reconstruire le même état sur une autre machine sont deux contrôles distincts.

Lovable : édition visuelle avec backend géré

Lovable est issu du projet open source gpt-engineer et de son ancien produit Web commercial, GPT Engineer. C’est désormais une plateforme Web full-stack en langage naturel destinée aux créateurs non techniques et aux équipes logicielles. Lorsque ma principale inconnue est « Combien de fois cette interface changera-t-elle ? » plutôt que « Comment concevoir l’architecture ? », Lovable rejoint ma sélection.

Lovable conserve édition visuelle, services full-stack et transfert du code sur un même parcours. Visual Edits permet de sélectionner un élément dans l’interface exécutée, d’en ajuster texte, couleur et espacement, puis de reporter le résultat dans le code. Pour les données dynamiques, Lovable Cloud fournit PostgreSQL, authentification, Storage, Realtime et Edge Functions ; Supabase reste une autre voie prise en charge. Les API externes authentifiées passent par Secrets et des fonctions serveur, sans exposer les identifiants au navigateur.

Sa combinaison distinctive est la sélection visuelle associée à la synchronisation GitHub bidirectionnelle : une modification visuelle ne reste pas une maquette isolée, et le code peut rejoindre un processus classique de branches et de collaboration. La publication crée un instantané explicite ; les changements ultérieurs de l’éditeur ne remplacent donc pas silencieusement la version en ligne. Les projets Cloud admissibles peuvent également séparer données et configuration Test et Live.

Article officiel Lovable Visual Edits du 13 mars 2025. Il montre l’interface d’édition visuelle, pas la qualité ni la portabilité du code obtenu.

Les nouvelles applications Lovable créées depuis le 13 mai 2026 utilisent TanStack Start avec rendu côté serveur ; les anciennes restent des projets React et Vite aux exigences d’hébergement différentes. Je retiendrais Lovable pour des applications Web souvent retouchées visuellement et ayant besoin tôt de connexion ou de données. Si la migration facile est impérative, trouver le code dans GitHub ne suffirait pas : je suivrais aussi le déplacement de la base, des utilisateurs, des fichiers et des Secrets.

v0 : de la génération d’interfaces aux projets complets

v0 est l’agent de développement par IA de Vercel, initialement connu pour générer des interfaces et composants React. Il s’est étendu aux projets full-stack tout en conservant une approche du design liée à Vercel. Je le comparerais directement à Lovable : les deux conviennent aux itérations visuelles, tandis que le parcours le plus solide de v0 passe par React, GitHub et Vercel.

v0 transforme texte, wireframes ou captures en interfaces fidèles, puis travaille sur le frontend, les routes API et les intégrations de bases dans un éditeur complet de type VS Code. Le Design Mode permet de sélectionner un élément dans le véritable aperçu et de l’ajuster avec des contrôles ou des instructions en langage naturel. Appliquer la modification crée une nouvelle version du projet, dont le code peut être comparé, rétabli ou affiné.

Son processus Vercel et GitHub est déterminant. Un Project partage déploiements, domaines, variables d’environnement et intégrations entre plusieurs conversations. Une fois GitHub connecté, chaque conversation travaille dans une branche dédiée, tout message modifiant le code crée automatiquement un commit, et le résultat rejoint main par une pull request plutôt que par un push direct. Les intégrations de bases comprennent Neon, Supabase et Upstash.

Documentation officielle de v0, consultée le 20 août 2026. Cette capture recadrée situe Design Mode ; utilisez le diff du projet obtenu, et non le contrôle lui-même, pour juger la modification.

Lorsque React et Vercel sont déjà choisis et que le projet dépend d’une landing page, d’un tableau de bord ou d’une interface précise, je classerais v0 en bonne place. Cette même intégration définit sa limite : un déploiement Vercel très direct ne prouve pas qu’un autre hébergeur n’exigera aucune adaptation. Je testerais encore formulaires, autorisations, données et états d’échec après l’obtention du premier bel écran.

Bolt : le navigateur comme environnement d’exécution JavaScript

Bolt.new est le générateur d’applications par IA de StackBlitz. Il repose sur WebContainers, un environnement WebAssembly qui exécute une chaîne Node.js dans le navigateur au lieu de diffuser une machine de développement distante. Voilà pourquoi Bolt mérite une place distincte : il ne promet pas seulement du code généré, mais du code dont l’installation, le démarrage et l’échec sont visibles dans le navigateur.

Le guide de démarrage de Bolt réunit prompt, éditeur, environnement du navigateur et Preview. Son cœur est cet environnement intégré : l’agent crée des fichiers, installe des paquets npm, lance un service Node.js, observe les erreurs et poursuit les corrections sans configuration locale. Si le prompt initial demande explicitement une application mobile, Bolt peut aussi produire un projet compatible avec Expo.

Bolt Cloud ajoute base de données automatiquement créée, authentification, Secrets, Edge Functions et hébergement, avec une adresse bolt.host partageable. Une base peut aussi être revendiquée et gérée via Supabase. Code View, historique des versions et intégration GitHub exposent l’implémentation et offrent une voie de transfert.

Guide de démarrage officiel de Bolt, consulté le 20 août 2026. Il montre le point de départ par prompt, pas le résultat d’une tâche achevée.

J’utiliserais Bolt pour un prototype JavaScript ou Node.js lorsque « exécuter maintenant » importe plus que recevoir seulement le code. Je n’en ferais pas un IDE cloud pour n’importe quel langage backend : PHP et Python sortent de l’environnement documenté, et chaque itération consomme encore des jetons. Je fixerais la pile et le budget avant de commencer.

Base44 : le backend est déjà présent

Base44 est un générateur d’applications en langage naturel désormais exploité par Wix. Il ressemble davantage à une plateforme intégrée d’applications métier qu’à un générateur de design : données, identité, logique backend et hébergement sont présents par défaut. Je l’envisagerais pour un CRM, un outil interne ou une application par abonnement, pas pour une landing page statique.

Le guide de démarrage de Base44 commence lui aussi par un prompt et un aperçu, mais repose surtout sur un backend prêt pour les applications métier. Sa base NoSQL représente les modèles comme des entités et prend en charge les abonnements en temps réel ainsi que les autorisations par ligne et par champ. L’authentification couvre e-mail/mot de passe, fournisseurs sociaux courants et SSO. La logique backend personnalisée s’exécute dans des fonctions serverless Deno et TypeScript.

Base44 répartit les intégrations en plusieurs niveaux. Les actions intégrées génèrent texte ou images, envoient des e-mails et traitent des fichiers ; les connecteurs emploient OAuth pour Google Workspace ou Slack ; les intégrations personnalisées peuvent être générées depuis une description OpenAPI et passer par le backend afin que le navigateur ne reçoive jamais l’identifiant. CRM, applications internes, espaces membres et outils de processus profitent davantage de ces fonctions qu’une page marketing statique.

Documentation officielle de Base44, consultée le 20 août 2026. La capture montre la disposition conversation et aperçu ; les services intégrés et l’export exigent des contrôles distincts.

Ses outils de développement comprennent une vue du code React/Vite, un API Activity Monitor, un processus GitHub, l’export ZIP et une voie de développement local ; l’hébergement intégré fournit HTTPS et domaines personnalisés. J’examinerais ici le sens d’« export » : déplacer frontend et fonctions ne déplace pas automatiquement base, authentification, intégrations ni SDK Base44. Je choisirais Base44 si l’équipe accepte cette dépendance en échange d’une configuration réduite, pas si l’auto-hébergement complet est la première contrainte.

Google AI Studio : lorsque Gemini est le produit

Google AI Studio était à l’origine l’environnement Web de Google pour expérimenter avec les prompts Gemini. Le mode Build l’a étendu au développement Web et Android natif. Je n’en ferais pas une solution universelle simplement parce qu’il peut désormais créer des applications ; son intégration se distingue lorsque Gemini, Android natif ou Cloud Run est déjà central.

La documentation Build actuelle de Google en fait plus qu’un terrain d’essai pour prompts Gemini. Le mode Web crée un frontend React et un environnement serveur Node.js, accepte les paquets npm et les bases accessibles par le réseau, et place la clé API Gemini dans des Secrets côté serveur. L’agent Antigravity gère les modifications entre fichiers et vérifie les mises à jour. Le projet peut rejoindre GitHub, une archive ZIP ou Cloud Run directement.

Le mode Android génère un projet Kotlin et Jetpack Compose natif avec émulateur dans le navigateur, installation sur appareil physique et parcours de test Play. C’est une vraie différence avec la plupart des générateurs Web. Les projets Android restent toutefois côté client : l’environnement serveur et les Secrets des applications Web ne s’y transfèrent pas automatiquement.

Image produit officielle de Google AI Studio d’octobre 2025. Elle montre l’entrée de Build ; les capacités décrites autour ont été revérifiées le 20 août 2026.

J’envisagerais sérieusement cette voie si le comportement texte, image ou Live API de Gemini constitue l’application elle-même, ou si Android natif et Cloud Run sont des cibles explicites. Une application AI Studio partagée permet aux destinataires autorisés de voir et dupliquer son code ; leurs appels Gemini consomment le quota du créateur, et les bases restent des services externes. Je vérifierais séparément « Gemini a été facile à ajouter » et « les données, les coûts et le transfert sont clairs ».

Quand je passe à un agent

Je ne déplacerais pas un projet vers un agent d’apparence plus technique simplement parce que deux prompts ont échoué. Le changement d’outil doit résoudre un problème précis de contrôle ; sinon, il ne fait que déplacer la même demande vague dans un autre champ.

Dans le projet du cours, le motif était concret : l’application visible ne pouvait trancher une question de dépendance au niveau des fichiers. L’état fonctionnel a été conservé, les fichiers pertinents exportés et Codex invité à inspecter avant de modifier. Il a proposé de supprimer exactement trois lignes inutilisées relatives aux polices, en laissant le comportement de l’application et tous les autres fichiers hors du périmètre approuvé.

Cette séquence de Replit à Codex est détaillée dans Vibe Coding pour débutants. Elle ne prouve pas que ces deux marques remportent la comparaison. Elle illustre un seuil réel : changez d’outil lorsque l’affirmation suivante exige une autre forme de preuve et de contrôle.

Agents de code

Lorsqu’un dépôt existe, j’attends davantage d’un agent. « Tâche terminée » apporte peu d’informations. Je veux voir plan, limite d’autorisation, fichiers modifiés, diff, résultats des commandes, nouveau test du comportement et voie de récupération.

Codex : un travail organisé autour de modifications vérifiables

Codex est l’agent de code d’OpenAI, conçu pour comprendre les bases de code, construire et tester des fonctionnalités, corriger des bugs et examiner des modifications. Il existe sur ordinateur, en CLI, dans l’IDE et dans le cloud plutôt que dans un éditeur unique. Ici, le nombre de points d’entrée m’importe moins que le maintien du périmètre, des commandes et du diff final dans une même chaîne de revue.

Le processus Codex est centré sur la modification de fichiers, l’exécution de commandes et de contrôles, puis la revue du diff. Un environnement local peut agir directement dans l’arborescence active, un worktree Git isoler des changements parallèles et un environnement cloud confier une tâche à un bac à sable distant. Le terminal intégré et la surface Review relient sortie des commandes, fichiers modifiés et diffs ligne par ligne à une même tâche.

Les conventions du dépôt et procédures récurrentes peuvent être inscrites dans AGENTS.md, les Skills et les Plugins afin de ne pas répéter à chaque prompt les règles de lint, de test, de documentation ou de publication. Autorisations et bac à sable déterminent les fichiers, réseaux et outils externes accessibles à l’agent. À mesure que cette surface s’étend, l’objectif, les zones protégées et les commandes d’acceptation doivent être plus explicites.

Démonstration Codex préparée pour le cours, reconstruite à partir du projet conservé et du diff exact de trois lignes. Elle montre l’action de revue consignée, pas l’écran d’exécution original.

Dans le dossier du cours, je pouvais vérifier non pas « le projet est corrigé », mais une suppression circonscrite de trois lignes comparée à l’original conservé. Je choisirais Codex pour un correctif, un refactoring, un test, une revue ou une tâche vérifiable en plusieurs étapes dans un dépôt existant. Avec seulement une idée et aucune structure de projet, je commencerais par un générateur.

Claude Code : priorité au terminal et forte extensibilité

Claude Code est l’environnement de programmation agentique d’Anthropic. Né dans le terminal avec une infrastructure fournissant contexte du projet, outils, autorisations et boucle d’exécution, il couvre maintenant aussi bureau, IDE, Web et automatisation. Si je sais déjà lire commandes shell et diffs Git et veux intégrer mes propres règles d’ingénierie à la boucle, il me semble plus naturel qu’une interface de génération figée.

Claude Code comprend des outils pour fichiers, recherche de code, commandes shell, Git, recherche Web et diagnostics. Sa boucle rassemble le contexte, agit et vérifie. Le mode Plan limite l’exploration aux outils en lecture seule ; Default et Auto-accept règlent les modifications et commandes exigeant une approbation. Un point de contrôle pris avant chaque modification de fichier peut être restauré avec double Esc ou /rewind, mais les effets sur bases distantes, déploiements et API échappent à cette récupération.

Le produit dépasse un panneau de conversation dans le terminal. CLAUDE.md porte les conventions persistantes, les Skills regroupent les processus à la demande, MCP relie les services externes, les Hooks exécutent des scripts déterministes autour des événements, et Subagents ou Agent Teams déplacent le travail dans des contextes séparés. Cela convient aux équipes à l’aise en CLI qui veulent intégrer leurs règles à la boucle. Chaque extension ajoute aussi contexte, autorisations ou maintenance.

Capture produit officielle d’Anthropic, consultée le 20 août 2026. Elle identifie le processus dans le terminal, sans vérifier une modification particulière du dépôt.

Je ne sous-estimerais pas Claude Code parce que le terminal n’offre pas d’aperçu visuel permanent, ni ne le surestimerais parce que son interface semble technique. Ce processus ne me convient que si je peux lire les commandes proposées, inspecter le diff Git et distinguer les points de contrôle locaux de l’historique durable.

Cursor : passer progressivement de la complétion aux agents

Cursor est un éditeur de code centré sur l’IA créé par Anysphere. Il est parti de la conversation, de la complétion et de l’édition conscientes de la base de code avant d’intégrer des agents locaux et cloud. Sa distinction utile n’est pas seulement de « posséder un agent », mais de permettre d’augmenter progressivement l’autonomie : complétion, modification ciblée, puis tâche déléguée plus vaste.

Le processus actuel de Cursor couvre trois échelles. Tab prédit des complétions multilignes et multifichiers, Inline Edit modifie le code sélectionné, et Agent recherche dans la base, modifie plusieurs fichiers, exécute des commandes et corrige les erreurs. Ask est en lecture seule, Manual ne modifie que les fichiers explicitement sélectionnés et les modes Custom combinent outils choisis et instructions spécialisées. Nul besoin de lancer une tâche très autonome pour chaque petite modification.

Review Diffs permet l’inspection fichier par fichier, Rules conserve les conventions du projet et MCP relie les outils externes. Les Checkpoints enregistrent automatiquement les changements de l’agent. Pour le travail à distance, Background Agents clone un dépôt GitHub dans un environnement Ubuntu isolé, installe les dépendances, exécute les tests et pousse une branche séparée ; interfaces Web, mobile et Slack peuvent lancer ou suivre ces exécutions.

Image de la documentation officielle Cursor, consultée le 20 août 2026. Elle montre la surface de revue Agent, sans établir que la modification affichée est correcte.

Si je lis et modifie déjà du code dans un éditeur et veux passer graduellement de la complétion au travail d’agent, Cursor est naturel. Ses points de contrôle locaux ne couvrent que les changements de l’agent, omettent les modifications manuelles et sont nettoyés automatiquement ; ils ne remplacent donc pas Git. Comme les environnements en arrière-plan accèdent à Internet et exécutent automatiquement des commandes, je contrôlerais séparément autorisations du dépôt, Secrets et exposition aux injections de prompt.

Windsurf : le processus à deux niveaux de Cascade et Devin

Windsurf est l’IDE agentique de Cognition, développé avec son agent cloud autonome Devin. D’où une conception à deux niveaux : travail synchrone avec Cascade dans l’éditeur, puis délégation des tâches longues à des agents cloud. Cette orchestration est séduisante pour surveiller plusieurs tâches, mais peut être excessive pour une petite modification.

Windsurf 2.0 commence toujours dans l’éditeur. Cascade se place à côté du code, planifie, recherche et modifie les fichiers, appelle des outils, lit les diagnostics et utilise points de contrôle et rétablissements en cas d’échec. L’éditeur propose des modèles de plusieurs fournisseurs. Code Maps visualise les relations entre fichiers et symboles, tandis que Preview exécute les changements Web dans l’environnement où ils ont été produits.

La nouveauté distinctive de la version 2.0 est Agent Command Center. Sa vue Kanban réunit agents locaux et cloud, tandis que Spaces organise sessions, pull requests, fichiers et contexte par projet. Un plan établi avec un agent local peut être transféré à Devin, qui poursuit dans sa propre VM avec bureau, navigateur et terminal. Windsurf sert donc à la fois le travail immédiat dans l’éditeur et les tâches longues en arrière-plan.

Image de la documentation officielle Cascade, consultée le 20 août 2026. Elle situe l’agent dans l’éditeur ; l’interface Windsurf 2.0 actuelle intègre aussi plus largement Devin.

La combinaison Cascade local et Devin cloud m’intéresse pour mener plusieurs tâches, mais rend aussi autorisations et facturation moins lisibles. Édition locale, exécution distante, choix du modèle et limites d’usage peuvent suivre des règles différentes. Je vérifierais la portée des points de contrôle avant toute restauration, puis les limites du dépôt, du réseau et des identifiants avant un transfert cloud.

Application GitHub Copilot : des sessions dans le processus GitHub

GitHub Copilot s’est d’abord fait connaître par la complétion dans l’éditeur. L’application GitHub Copilot autonome est devenue disponible pour tous en juin 2026, faisant passer l’unité de travail d’une suggestion à une branche, une issue ou une pull request. Son public le plus évident n’est pas tout utilisateur de GitHub, mais les équipes déjà structurées autour des issues et PR qui veulent plusieurs sessions parallèles.

Chaque session peut s’exécuter dans son propre worktree Git, le dépôt local actuel ou un bac à sable cloud hébergé par GitHub, avec une branche dédiée. Plusieurs tâches avancent sans se disputer la même arborescence, et une issue peut passer directement à l’implémentation, à la revue du diff, au commit et à la pull request.

Le mode Interactive s’arrête pour collaborer, Plan soumet un plan à approbation et Autopilot peut écrire le code, tester et itérer sans attendre. Chaque session peut utiliser un modèle et un effort de raisonnement différents ; Auto choisit selon la tâche, et des fournisseurs externes peuvent être ajoutés avec la clé API de l’utilisateur. Terminal intégré, outils de navigation, Quick Chat et historique des sessions soutiennent exécution et revue.

Annonce officielle GitHub du 17 juin 2026. Elle montre l’application Copilot autonome, pas la complétion en ligne dans un éditeur.

Si le code est déjà sur GitHub et le travail quotidien organisé autour d’issues et de pull requests, je testerais rapidement l’application Copilot. Worktrees locaux, dossiers locaux directs et bacs à sable cloud ont toutefois des limites d’isolation, d’accès aux ressources et de coût différentes. Autopilot peut avancer sans attendre ; j’effectuerais néanmoins la revue finale.

Google Antigravity : plans et captures comme livrables de revue

Google a présenté Antigravity en novembre 2025 comme plateforme centrée sur les agents couvrant éditeur, terminal et navigateur. Antigravity 2.0 a ajouté un centre de commande autonome tout en conservant IDE, CLI et SDK. Il rejoint ma sélection non pour son nombre d’entrées, mais parce que plans, diffs, captures et enregistrements deviennent des livrables commentables.

L’application autonome lance et surveille plusieurs agents locaux et tâches planifiées ; Antigravity IDE permet aux agents d’utiliser éditeur, terminal et navigateur. Le point distinctif est la façon dont les livrables intègrent la boucle de contrôle.

Avant de coder, un agent peut créer un Implementation Plan et une Task List acceptant des commentaires comme un document. Pendant l’implémentation, il produit des diffs ; après, un Walkthrough décrit changements et tests. Un sous-agent de navigateur peut parcourir l’application et joindre captures ou enregistrement. Le Codelab officiel de Google montre aussi Undo à un instant précis et l’envoi à l’agent d’un diagnostic IDE ou d’une erreur sélectionnée du terminal.

Codelab officiel Google Antigravity, consulté le 20 août 2026. Il montre un plan en attente de revue ; il ne prouve pas que l’implémentation ultérieure lui correspond.

Je retiendrais Antigravity si un comportement d’interface doit être vérifié dans un navigateur ou si je souhaite des preuves de planification et visuelles à côté du code. Davantage de livrables n’implique pas automatiquement une meilleure preuve, et certaines politiques laissent l’agent continuer sans attendre Proceed. Je relierais encore, un par un, plan, diff, capture et enregistrement à la consigne.

Ce que le prix dissimule

J’ai écarté les prix mensuels des tableaux principaux, car ils donnent une fausse impression de comparabilité. Les produits facturent l’abonnement, les messages, crédits, jetons, usages de modèle, calculs, déploiements ou une combinaison. Un prix mensuel affiché faible peut mener à une exécution interrompue ; une offre plus chère peut inclure du crédit modèle ou calcul facturé séparément ailleurs.

Avant de choisir une offre, comparez trois faits plutôt qu’un prix mensuel :

1. l’offre la moins chère incluant le processus nécessaire, comme builds complets, export Git, agents en arrière-plan ou bacs à sable cloud ;
2. l’unité réellement mesurée — jetons, crédits, messages, appels de modèle, calcul ou effort d’agent ;
3. les frais séparés d’hébergement, de base, de modèle ou de déploiement qui persistent après la génération.

Consultez les tarifs officiels et l’écran de paiement juste avant de payer. Un test de coût équitable consigne la dépense de votre propre tâche circonscrite ; il ne suppose pas que l’offre au prix affiché le plus bas l’achèvera.

Deux outils exclus

Je n’ai pas retenu deux outils historiquement importants après la disparition de leur parcours pour nouveaux utilisateurs. Firebase Studio a désactivé la création d’espaces et les inscriptions le 22 juin 2026 avant sa fermeture du 22 mars 2027, et oriente les nouveaux projets vers Google AI Studio ou Antigravity. La documentation de migration Firebase le rend impropre à une recommandation pour débuter.

GitHub Spark a également cessé d’accepter de nouveaux utilisateurs et de nouvelles applications en août 2026. La documentation Spark actuelle de GitHub demande aux utilisateurs existants d’exporter leur travail. Ces deux produits peuvent compter dans l’histoire de la catégorie, mais pas dans une comparaison principale destinée à quelqu’un qui choisit aujourd’hui.

Comment je choisirais

Je ne désignerais pas de vainqueur général à partir de ce tableau. Un même produit peut être pertinent dans une ligne et inutilement complexe dans une autre. Pour un premier projet, je sélectionnerais deux produits d’une même ligne, confirmerais que la fonctionnalité nécessaire figure dans l’offre actuelle et construirais un parcours utilisateur complet dans chacun avant d’élargir le périmètre.

Pour vous exercer avant d’engager un vrai projet, le cours AILesson Vibe Coding pour débutants suit une application fictive depuis le cahier des charges jusqu’à l’aperçu, puis la réparation ciblée, l’inspection des fichiers, la modification circonscrite par un agent, la vérification et un transfert honnêtement non public. Il s’arrête avec les preuves : la démonstration n’est pas présentée comme prête pour la production, reproductible indépendamment ni déployée publiquement.

Quel que soit l’outil, conservez la même règle d’acceptation. Un bel écran est un résultat candidat. La confiance ne grandit que lorsque comportement, changements, contrôles, voie de récupération et état du transfert sont assez visibles pour être inspectés par vous ou la personne suivante.

Références

• Documentation de Replit Agent — planification, tests, points de contrôle et espace intégré.
• Documentation Lovable sur le déploiement et la propriété — services gérés, propriété du code GitHub, hébergement et limites de migration.
• Présentation de Bolt — construction dans le navigateur, bases, authentification et hébergement.
• FAQ de v0 — éditeur 2026, intégration Git, projets et modifications de Preview.
• Outils de développement Base44 — accès au code, services backend, intégrations, GitHub et développement local.
• Documentation Build de Google AI Studio — modes Build Web et Android actuels, export et déploiement.
• Documentation Codex — compréhension du projet, modifications, commandes, contrôles et revue.
• Fonctionnement de Claude Code — outils intégrés, mode Plan, autorisations et points de contrôle.
• Documentation Cursor Agent — complétion, outils Agent, contexte du projet et processus de revue.
• Windsurf 2.0 et documentation Cascade — éditeur actuel, orchestration d’agents, planification, outils, points de contrôle et diagnostics.
• Sessions de l’application GitHub Copilot — modes de session, modèles, branches et espaces isolés.
• Codelab Google Antigravity — interfaces produit, actions dans le navigateur, planifications et travail guidé par les livrables.