L'onglet qui fait mal, c'est celui marqué facturation. Vous l'ouvrez après qu'un prototype ait soudainement des utilisateurs, et la construction bon marché du vendredi commence à ressembler à une location. J'ai vu cela des deux côtés : Deluxe Astrology a grandi au-delà de 91 000 pages parce que nous pouvions déplacer des pièces quand le trafic explosait, tandis qu'un client (appelons le projet Meridian, un SaaS de commande de nourriture) a livré un bel MVP sur un app builder géré, puis a passé tout le mois de mars 2024 à démêler l'authentification de l'hébergement. Trois mois. Un onglet de facturation. Les outils sont brillants maintenant. Base44 peut ressembler à un bureau fini. Lovable vous remet du code avec les bonnes clés. Claude Code s'installe dans votre dépôt comme un senior qui ne dort jamais. Mais la question coûteuse n'est pas celle de savoir quel démo gagne mardi après-midi. C'est ce que coûte partir quand votre projet dépasse sa première maison.
Quelle est la différence entre un app builder IA et un agent de codage IA ?
Vous devriez clarifier cette distinction avant de dépenser un seul centime, car elle change tout en aval. Un app builder IA possède toute la pile et vous remet une application fonctionnelle. Un agent de codage IA travaille dans une base de code que vous possédez déjà et vous remet des commits. Le backend vit avec le builder. Avec un agent, il vit avec vous.
Cette seule phrase est le cadre pour tout ce qui suit. Trois niveaux se situent au-dessus.
Le premier niveau est les app builders gérés : Base44, Lovable. Vous décrivez ce que vous voulez, la plateforme le construit, et l'app est en ligne avant que vous finissiez votre thé. Le deuxième niveau est le codage agentique dans votre propre dépôt : Claude Code, Cursor. Vous avez déjà une base de code, l'agent l'édite, exécute les tests et ouvre des pull requests. Le troisième niveau est les modèles ouverts que vous exécutez vous-même ou via API : Qwen3 Coder, Kimi K2 et K3. Contrôle maximum, responsabilité maximum.
La question qui compte vraiment n'est donc pas celle de savoir quel niveau produit la meilleure démo. C'est ce que vous devez physiquement reconstruire quand vous dépassez le niveau par lequel vous avez commencé.
---
Où Base44 gagne-t-il ?
Vous voulez livrer quelque chose de complet vendredi sans toucher à un fichier de config, et Base44 est le chemin le plus rapide. Point final.
Auth, base de données, hosting et intégrations arrivent en bundle. Vous ne les câblez pas ensemble. Ils arrivent câblés. La fonctionnalité Superagents gère les builds multi-étapes autonomes, vous pouvez donc lui confier un brief raisonnablement détaillé et revenir à quelque chose qui fonctionne surtout. Wix a acquis Base44, ce qui est un vrai signal de distribution et de longévité pour une plateforme gérée, pas une note de bas de page à parcourir rapidement.
La tarification va de 0 à 16, 40, 80 et 160 USD par mois. L'offre gratuite est suffisamment utilisable pour valider une idée en un week-end. L'offre 40 USD couvre la plupart des outils internes ou des preuves de concept clients sans se sentir à l'étroit (et je l'ai testé sur au moins 4 briefs clients différents l'année passée, y compris un où le brief entier a changé un jeudi soir et la reconstruction a quand même atterri avant midi vendredi).
Le frontend est exportable. Le backend, par design, reste sur la plateforme. Ce n'est pas un piège caché. C'est une décision de scope. Si votre projet est un dashboard interne pour une équipe de 5 personnes, ou une build de validation que vous devez montrer aux investisseurs avant de vous engager sur une vraie stack, posséder le backend est un problème résolu que vous n'avez pas besoin de résoudre à nouveau.
Bon, le type de projet que Base44 convient vraiment : les prototypes clients avec des deadlines serrées, les outils internes qui servent une petite audience, la validation MVP où l'hypothèse pourrait être fausse et toute la chose pourrait être jetée en 6 semaines.
---
Où Lovable gagne-t-il ?
Vous voulez posséder du vrai code que vous pouvez confier à un développeur sans qu'il ne fixe une export de plateforme en se demandant ce qu'il regarde, et Lovable vous donne exactement ça.
L'output est React, TypeScript et Tailwind. Une vraie stack standard et transférable. L'export GitHub est natif, pas un workaround. Ça veut dire qu'à partir du moment où un vrai développeur rejoint votre projet, il peut cloner le repo et commencer sans apprendre un système propriétaire d'abord. Pas de conversations gênantes lundi matin sur le format de tout. Et il y a un vrai soulagement là-dedans, si vous avez jamais été la personne qui a dû expliquer une export de plateforme à un contracteur sceptique à neuf heures du matin.
Les chiffres d'adoption valent la peine d'être énoncés clairement parce qu'ils reflètent du vrai feedback du marché, pas des communiqués de presse. Lovable a environ 8 millions d'utilisateurs, à peu près 200 millions USD en ARR, et une valorisation autour de 6,6 milliards USD selon les rapports. Ce n'est pas un produit dont vous vous inquiétez de voir disparaître un jeudi après-midi.
La tarification est basée sur les crédits : une offre gratuite, puis des plans mensuels à 25 et 50 USD. Les modèles basés sur les crédits récompensent l'itération disciplinée. Si vous savez ce que vous construisez et que vous promptez clairement, vous allez plus loin par euro dépensé. Si vous itérez de façon désordonnée avec des pivots fréquents, vous brûlez les crédits plus vite. Honnêtement, la discipline que le modèle exige n'est pas toujours mauvaise.
L'hosting est séparé du code. Vous pouvez déployer l'app React exportée n'importe où vous voulez, ce qui est le bon choix si vous êtes sérieux sur le fait de garder les options ouvertes. Consultez nos notes sur l'hosting pour Lovable, v0 et les apps Jamstack pour les détails.
Le type de projet qui convient : quelque chose que vous avez l'intention de garder et de faire croître. Un produit SaaS auquel vous prévoyez d'embaucher des développeurs. Une livrable client où le client voudra éventuellement prendre possession.
---
Où Claude Code et Cursor gagnent-ils ?
Vous avez déjà une base de code, et le travail devant vous c'est du changement, pas de la création. C'est là que Claude Code et Cursor ont leur place.
Les deux opèrent comme des boucles agentiques à l'intérieur de votre repo. Ils lisent les fichiers à travers tout le projet, planifient une séquence d'édits, lancent vos tests et présentent le diff pour révision. Le gain de productivité n'est pas dans la génération de boilerplate. C'est dans le raisonnement inter-fichiers qui signifiait autrefois un après-midi d'archéologie minutieuse à travers des dossiers que personne n'a documentés correctement.
J'utilise Claude Code pour l'automatisation du pipeline de contenu à travers la build de 91 000 pages de Deluxe Astrology et pour les scripts d'automatisation SEO qui alimentent les 137 000 listings de Not Another Sunday. La chose avec laquelle je lui fais le plus confiance est exactement le genre de tâche que personne ne veut faire manuellement : toucher 12 fichiers pour changer un contrat de données, ou refactoriser un module de rate-limiting écrit dans la pression du deadline en janvier 2022 qui maintenant rend tout le monde tranquillement nerveux. Personne ne touche ce module volontairement. L'agent s'en fout.
Cursor ajoute la couche d'intégration IDE, ce qui compte si votre équipe est plus à l'aise à rester dans un environnement visuel plutôt qu'un terminal. Les deux sont vraiment des outils différents avec des forces différentes. J'ai écrit en détail sur ces différences dans Claude Code vs Codex vs Cursor et dans la comparaison plus large des outils AI dev pour 2026.
Les projets pour lesquels ce tier convient : les bases de code en production, les systèmes legacy avec une logique gênante, n'importe quoi où les tests existent et vous voulez qu'ils restent verts, et les builds multi-repo où l'agent a besoin de raisonner à travers les frontières.
Alors, lequel de ces types de projet ressemble à votre situation actuelle ?
---
Où les modèles ouverts comme Qwen3 Coder et Kimi K2 s'inscrivent-ils ?
Vous accordez de l'importance au coût par token, à la résidence des données ou à l'auto-hébergement, et vous êtes prêt à faire un peu plus de travail d'infrastructure pour y arriver. C'est le point d'entrée honnête pour cette catégorie.
Les chiffres de benchmark rapportés méritent d'être cités comme signaux, non comme parole d'évangile. Kimi K2.6 obtient environ 80,2 % sur SWE-bench Verified et 66,7 % sur Terminal-Bench 2.0 selon Moonshot AI. Qwen 3.6 Plus atteint environ 78,8 % sur SWE-bench Verified selon Alibaba Cloud. Kimi serait également en tête sur Frontend Code Arena. Je n'ai pas exécuté ces benchmarks moi-même. Je reprends ce que les laboratoires ont publié, et les benchmarks évoluent assez vite pour que tout chiffre ici soit traité comme une direction plutôt que comme une destination.
Ce que j'ai réellement utilisé, c'est Kimi K3 pilotant un script d'audit d'interface utilisateur sur un lot de quelque 60 pages d'accueil fin 2024. Le modèle est rapide, le coût de l'API est bas, et pour les tâches structurées avec des résultats clairs, il fonctionne bien dans une boucle agentique. Ce n'est pas un benchmark. C'est un seul cas d'usage, et vous devriez le pondérer en conséquence.
Voilà la question avec l'auto-hébergement : cela compte pour certaines catégories de travail. Les données de santé, les dossiers financiers, tout ce pour quoi votre équipe juridique aimerait avoir une conversation tranquille si vous les envoyiez à une API tierce. Les poids ouverts vous donnent la possibilité d'exécuter l'inférence sur votre propre infrastructure, ce qui change entièrement la conversation de conformité.
Pour la vue d'ensemble de quel modèle correspond à quel rôle, combien de modèles d'IA vous devriez réellement exécuter et les meilleurs modèles de codage IA en 2026, voir plus loin. En résumé : les modèles ouverts sont une véritable option prête pour la production en 2026. Pas un compromis.
---
Quel est le coût de passer d'une catégorie à l'autre plus tard ?
Passer au niveau supérieur est toujours possible. Toujours, et la question est ce que vous portez et ce que vous reconstruisez.
Pensez-y comme à un inventaire en 3 parties : ce qui se transfère proprement, ce qui nécessite une réécriture, et ce que vous abandonnez parce que c'était spécifique à la plateforme et n'a pas d'équivalent ailleurs. Le tableau ci-dessous modélise le chemin réaliste pour chaque transition.
| Catégorie que vous quittez | Ce qui se transfère | Ce que vous reconstruisez | Effort approximatif |
|---|---|---|---|
| Builder géré (backend Base44) | Code frontend (s'il est exporté), schéma de base de données, logique métier que vous avez documentée | Câblage d'authentification, logique côté serveur, intégrations, pipeline de déploiement | Semaines à mois selon la complexité |
| Builder à code maîtrisé (Lovable) | Codebase React / TypeScript / Tailwind complète, historique GitHub | Backend si vous en avez ajouté un séparément, toute configuration d'hébergement spécifique à la plateforme | Jours à une semaine pour un développeur compétent |
| Outils de dépôt agentiques (Claude Code, Cursor) | Codebase entier, suite de tests, config CI | Échange de modèle seulement si vous changez de fournisseur, bibliothèques de prompts | De quelques heures à quelques jours |
| Modèle ouvert via API | Prompts, intégrations, schémas de sortie | Infrastructure auto-hébergée si passage à on-premise | De quelques jours à quelques semaines selon vos compétences en infrastructure |
La lecture honnête de ce tableau, c'est que le passage de Base44 au code maison est l'effort le plus considérable, précisément parce que la logique backend et l'authentification n'ont jamais été les vôtres. Ce n'est pas une critique de Base44. C'est le bon compromis pour les projets qu'il convient : si vous avez validé une hypothèse et l'hypothèse était correcte, le coût de reconstruction est un impôt sur le succès, pas un échec. Il vaut la peine de le dire clairement.
Le passage de Lovable aux outils agentiques est véritablement peu coûteux parce que vous possédez du vrai code. Cette portabilité, c'est en partie ce pour quoi vous payez 25 ou 50 USD par mois.
Mais une chose à préciser : l'automatisation spécifique à la plateforme, les Superagents dans le cas de Base44, ne se portent pas. Vous recréez le comportement, pas l'automatisation elle-même.
---
Comment choisir ?
Votre contrainte est le point de départ. Pas la liste des fonctionnalités.
Validation de fin de semaine ou MVP jetable
Utilisez Base44. L'objectif est de savoir si l'idée vaut la peine d'être poursuivie. Le coût de sortie est acceptable parce que si vous vous trompez, vous abandonnez le projet, et si vous avez raison, le budget de reconstruction vient de la traction. Le fait que le backend reste sur la plateforme n'a pas d'importance si le produit ne survit pas aux 6 prochaines semaines.
Outil interne pour une petite équipe
Base44 à nouveau, ou Lovable si votre équipe inclut quelqu'un qui voudra modifier le frontend au fil du temps. Les outils internes n'ont rarement besoin de migrer. Ils doivent être maintenus. La codebase exportable de Lovable rend cette conversation de maintenance plus facile quand elle survient inévitablement, et elle survient toujours.
Livrable client qui doit survivre à la prestation
Lovable est le bon choix ici. Vous remettez au client un repo GitHub avec du vrai code React. Il peut engager n'importe quel développeur sur la planète pour le poursuivre. La plateforme n'est pas sur le chemin critique après la transition. La propriété est le produit, pas seulement l'application.
Codebase en production existante
Tier deux. Claude Code ou Cursor. Vous ne reconstruisez pas un système qui fonctionne sur un builder. Vous intégrez des agents dans le repo que vous avez déjà. Si vous ne savez pas certain quel outil agentique convient à votre workflow, le post vibe-coding model team explique comment réfléchir à la sélection de modèles pour différents rôles dans une équipe.
Contraintes de confidentialité ou sensibilité aux coûts à grande échelle
Tier trois. Modèles ouverts, auto-hébergés ou via une API à bas coût. Vous acceptez davantage de responsabilité en infrastructure en échange du contrôle des données et d'une meilleure économie unitaire en volume. Les chiffres de référence de Kimi et Qwen suggèrent que l'écart de performance entre les modèles propriétaires et ouverts s'est réduit au point où c'est un vrai choix, pas un repli.
Et le motif à travers les 5 : énoncez le coût de sortie avant de vous engager envers l'outil. Si vous pouvez dire « si ça grandit, voici ce que je dois reconstruire et voici approximativement ce que ça coûte », vous avez pris la décision les yeux ouverts. Avez-vous réellement écrit cette phrase par écrit ? Ça prend environ 3 minutes et ça vous épargne bien des situations de mars 2024.
---
FAQ
Base44 ou Lovable est meilleur pour un fondateur non technique ?
Les deux sont conçus pour les créateurs non techniques, donc votre vraie différence se joue après. Si vous ne voulez jamais toucher au code ou penser à un serveur, Base44 vous garde tout en géré. Si vous voulez la possibilité de confier votre projet à un développeur plus tard sans grosse réécriture, le codebase React exportable de Lovable rend cette conversation plus facile et moins chère. C'est une conversation qui vaut le coup d'avoir tôt, pas après 6 mois de construction.
Pouvez-vous exporter votre code depuis un éditeur d'applis piloté par IA ?
Lovable exporte le frontend React, TypeScript et Tailwind complet directement sur GitHub, et vous en êtes propriétaire. Base44 rend le frontend exportable aussi, le backend restant sur la plateforme par conception. La différence pratique c'est qu'avec Lovable vous pouvez prendre le frontend entier vers n'importe quel hébergeur ou développeur. Avec Base44 vous gardez l'interface et reconstruisez le côté serveur si vous bougez.
Les modèles de codage open source sont-ils suffisamment bons pour la production en 2026 ?
Oui, pour une large gamme de tâches. Kimi K2.6 est rapporté autour de 80,2% sur SWE-bench Verified, et Qwen 3.6 Plus autour de 78,8%, tous deux compétitifs avec les modèles propriétaires leaders sur les tâches de codage structuré. L'auto-hébergement ajoute une surcharge d'infrastructure, mais pour les charges de travail sensibles aux coûts ou aux données, le rapport performance-coût est véritablement convaincant en 2026 d'une façon qu'il ne l'était pas il y a deux ans. Traitez les benchmarks comme des signaux directionnels et testez sur votre propre charge de travail. Toujours.
Avez-vous encore besoin d'un développeur si vous utilisez un éditeur d'applis piloté par IA ?
Pour un outil interne basique ou un MVP de validation, probablement pas au départ. À mesure que la complexité grandit, oui. Les éditeurs IA gèrent bien la construction initiale. Ils gèrent les décisions produit ambiguës, les intégrations inhabituelles et le débogage de performance considérablement moins bien. Un développeur devient précieux non pas parce que l'éditeur échoue mais parce que les exigences du produit finissent par dépasser ce que n'importe quel éditeur automatisé, géré ou agentique, peut raisonner sans jugement humain dans la boucle.
Cet onglet facturation est révélateur. Si vous pouvez imaginer bouger sans drame, vous avez choisi le bon palier pour maintenant. Si la pensée vous fait refroidir votre café, la plateforme fait son travail un peu trop bien. Commencez là où le travail est léger, gardez les portes visibles, et laissez les benchmarks être des rapports météo plutôt que des commandements. Les bons outils rendent le départ ennuyeux. L'ennui est sous-estimé.