Base44 est une plateforme web qui transforme une description en langage naturel en application fonctionnelle. L’éditeur associe une conversation avec l’IA, un aperçu interactif et un tableau de bord.
Vous avez utilisé cet outil ? Notez-le
Vous avez utilisé cet outil ? Notez-le
Base44 est une plateforme web qui transforme une description en langage naturel en application fonctionnelle. L’éditeur associe une conversation avec l’IA, un aperçu interactif et un tableau de bord. Il peut produire des pages, des entités de données, des formulaires, des règles d’accès, des fonctions côté serveur, des intégrations et une version publiée. La documentation officielle le présente à la fois comme un créateur no-code et comme un backend utilisable par une interface externe au moyen de son SDK JavaScript et de sa CLI.
Cette intégration réduit fortement le travail de mise en place : l’équipe n’a pas à choisir séparément un hébergeur, une base, un fournisseur d’authentification et un système de fonctions pour tester une première idée. Elle ne supprime toutefois ni la définition du produit, ni la modélisation des données, ni la sécurité, ni les essais. Une application produite rapidement peut sembler achevée alors que ses permissions, ses erreurs ou son comportement avec des données réelles ne le sont pas.
Le parcours de démarrage documenté part d’une demande formulée dans le chat, montre les pages et les données générées dans l’aperçu, puis donne accès aux réglages du tableau de bord avant la publication sur une adresse Base44. Les documents destinés aux développeurs ajoutent le stockage, l’authentification, les mises à jour en temps réel, les fonctions, les intégrations et l’hébergement gérés. Il s’agit donc de véritables applications web avec état et rôles, pas seulement de maquettes statiques.
Pour autant, il faut résister à la tentation d’attribuer au produit une capacité aperçue dans un ancien tutoriel ou une formule commerciale différente. Les modèles disponibles, les quotas, les fonctions bêta et les droits de chaque forfait évoluent. Le présent texte distingue ce qui est documenté, ce qui a été annoncé pour plus tard et ce qui relève d’une recommandation de mise en œuvre.
Wix a annoncé l’acquisition de Base44 le 18 juin 2025 et a indiqué que Base44 continuerait à fonctionner comme produit et activité distincts. C’est un événement historique établi, pas la preuve que tous les services Wix sont intégrés ni qu’une fonction particulière est activée dans chaque compte Base44. Pour une décision technique, la documentation Base44 et le workspace réel restent les références.
En juin 2026, TechCrunch a par ailleurs rapporté le début du déploiement de Base1, un modèle spécialisé. Le mot « déploiement » est important : il ne garantit ni une disponibilité identique dans tous les comptes ni un coût fixe. Vérifiez le sélecteur et l’affichage des crédits dans l’éditeur au moment où l’équipe choisit un modèle.
Le mode Default applique une demande à l’application. Le mode Discuss sert à clarifier le besoin ou comparer des options sans modifier le projet. Le mode Edit permet de sélectionner des éléments de l’aperçu et de travailler sur leur présentation. Les différences entre modification manuelle et intervention de l’IA ont aussi une incidence sur les crédits, d’où l’intérêt de choisir le mode adapté avant chaque demande.
Discuss est utile pour faire explir un schéma de données, les rôles ou les risques avant une transformation coûteuse. Edit convient aux ajustements visuels ciblés. Default doit recevoir une demande testable : rôle concerné, état initial, règle, résultat attendu et exclusions. Une consigne précise coûte souvent moins qu’une succession de corrections vagues.
Base44 fournit des entités persistantes et une interface pour examiner les enregistrements. Sa documentation développeur décrit une couche NoSQL, des mises à jour en temps réel, l’authentification, des fonctions TypeScript, des intégrations et l’hébergement. Une interface externe peut également utiliser ce backend par le SDK, ce qui élargit le produit au-delà de l’éditeur conversationnel.
Le modèle de données doit être revu avant de multiplier les écrans. Séparez l’identité du profil public, définissez les états autorisés et ajoutez une relation d’organisation à chaque donnée privée d’une application multi-tenant. Une table bien affichée n’est pas sûre si sa règle de lecture accepte les enregistrements d’un autre client.
Le flux officiel couvre l’authentification gérée, la visibilité de l’application, les utilisateurs invités, les rôles utilisateur et administrateur et les permissions de données. Il documente aussi la fonction permettant d’agir comme un autre utilisateur pour tester la vue et les droits. L’authentification prouve une identité ; l’autorisation détermine ce que cette identité peut lire ou modifier. Il faut tester les deux séparément.
La documentation actuelle précise qu’un flux d’authentification entièrement personnalisé et des écrans intégrés totalement en marque blanche ne sont pas disponibles ; la marque blanche est présentée comme planifiée. Toute exigence concernant un fournisseur d’identité, le SSO ou le branding doit donc être confirmée dans les documents et le forfait du moment, sans extrapoler à partir d’une mention secondaire.
Les fonctions backend conviennent aux appels sensibles, aux webhooks, aux opérations privilégiées et aux transformations qui ne doivent pas s’exécuter dans le navigateur. Les intégrations sont réparties entre actions intégrées, connecteurs à autorisation gérée et intégrations de workspace importées depuis une spécification OpenAPI. Les identifiants gérés côté serveur ne doivent pas être recopiés dans le code client, les prompts ou les données ordinaires.
Une intégration n’est complète que lorsque l’équipe a testé l’expiration de l’autorisation, la pagination, les limites de débit, les doublons et les échecs partiels. Notez quel compte possède la connexion, quelles portées ont été accordées et comment une action ayant un effet externe est réconciliée. Un webhook qui touche de l’argent ou un état client doit être vérifié et idempotent.
Pour les applications créées à partir du 6 juillet 2026, la documentation indique que Workflows remplace Automations ; les projets plus anciens peuvent garder l’ancien système. Une application expose l’un ou l’autre, pas les deux. Workflows peut démarrer selon un calendrier, une modification d’entité, une conversation avec un agent dans l’app ou un événement de connecteur, puis enchaîner conditions, attentes et actions avec visibilité sur chaque exécution.
Cette transition rend certains tutoriels obsolètes. Identifiez d’abord la surface présente dans le projet. Définissez ensuite le déclencheur, l’état final et la manière d’éviter qu’une mise à jour ne relance indéfiniment le même workflow. Les effets externes doivent porter une clé ou un état permettant de reconnaître un événement déjà traité.
Chaque app créée reçoit une adresse Base44 et peut être publiée depuis l’éditeur. Les domaines personnalisés sont documentés sur des forfaits éligibles avec HTTPS géré. La publication reste une opération de release : testez les rôles, contrôlez les secrets et les intégrations, conservez une version examinée et connaissez la procédure de retrait ou de retour arrière.
La vue du code, l’export ZIP et la synchronisation GitHub donnent davantage de contrôle aux équipes éligibles. Le workflow GitHub documenté est bidirectionnel et prend en charge le développement local, les branches et les pull requests. Il ne faut pas confondre export du code et reproduction complète de l’infrastructure gérée : l’authentification, la base et l’hébergement Base44 ne deviennent pas automatiquement des composants auto-hébergés.
Base44 documente l’édition depuis un navigateur mobile ainsi que des applications de création iOS et Android. Une application publiée peut fonctionner dans un navigateur mobile ou être ajoutée à l’écran d’accueil. Certaines opérations d’administration restent mieux adaptées au poste de travail ; il faut donc évaluer le mobile comme surface complémentaire, pas comme remplacement certain de tout le tableau de bord.
Sur un forfait éligible, le produit peut analyser la préparation au store et générer des paquets IPA et AAB. Ceux-ci enveloppent l’application web publiée dans une web-view sécurisée : ils ne constituent pas une réécriture native indépendante et n’apportent actuellement ni notifications push natives ni mode hors ligne complet. Les comptes développeur, les fiches, les déclarations de confidentialité et la soumission restent sous la responsabilité du propriétaire.
Un fondateur peut tester un parcours comprenant inscription, saisie, résultat et retour ultérieur sans assembler toute une infrastructure classique. La bonne cible n’est pas une copie instantanée d’un produit mature, mais une tranche verticale : un type d’utilisateur, un objet métier et une action qui produit un résultat mesurable. Les opérations manuelles sont acceptables tant que l’hypothèse principale peut être observée.
Avant d’élargir, vérifiez qu’un nouveau compte retrouve ses données, qu’un rôle interdit ne voit pas l’enregistrement et qu’une erreur n’efface pas l’état. Le prototype n’est probant que si l’interaction et les règles fonctionnent avec des exemples proches de la réalité.
Des équipes peuvent créer des files d’approbation, suivis d’inventaire, check-lists d’onboarding, registres d’incidents ou portails de service. Les entités conservent les dossiers, les rôles séparent les responsabilités et un workflow peut envoyer une alerte ou avancer un état. Ce type de processus spécifique est souvent mal servi par un SaaS généraliste et trop petit pour justifier immédiatement un développement conventionnel.
« Interne » ne signifie pas « sans risque ». Les données du personnel, des clients ou des finances exigent encore permissions, durée de conservation et responsable. Déterminez si Base44 devient le système de référence ou une copie d’un autre service, puis documentez la règle de résolution en cas de conflit.
L’authentification, les rôles et les entités peuvent soutenir un portail où chaque client consulte ses commandes, transmet des documents ou suit une demande. Chaque enregistrement privé doit porter la relation avec son propriétaire ou son organisation. Testez avec deux organisations et tentez de franchir la limite ; une interface personnalisée ne protège rien si la requête sous-jacente retourne les données du voisin.
Pour un portail partenaire, ajoutez une piste des changements et une procédure de retrait d’accès. Les intégrations doivent employer un compte de service clairement détenu et des portées minimales. Les messages d’erreur doivent aider l’utilisateur sans révéler les données ou la configuration d’un autre tenant.
Un workflow peut accuser réception d’un lead, attendre, contrôler un état et prévenir une équipe ; un événement de calendrier peut actualiser une réservation ; une tâche planifiée peut produire un résumé. Le journal d’exécution aide à suivre les étapes, mais il faut toujours prévoir les retries, les événements en double et la déconnexion du service tiers.
Filtrez tôt les événements inutiles afin d’éviter des appels et des crédits sans valeur. Pour une action irréversible, ajoutez une validation humaine ou un rapport de rapprochement. L’automatisation doit rendre l’état compréhensible après une panne, pas seulement réussir pendant la démonstration.
Base44 peut produire un site public, une landing page ou un calculateur avec domaine et hébergement. Il est particulièrement pertinent lorsque le site a aussi besoin de comptes, de préférences sauvegardées, de résultats générés ou d’un workflow derrière un formulaire. Pour un site essentiellement éditorial, comparez tout de même les besoins de contenu, SEO, redirections et accessibilité avec ceux d’un CMS.
Testez les pages avec du texte long, des écrans étroits, la navigation au clavier, les erreurs et les états vides. Un premier écran élégant ne prouve pas qu’un formulaire complexe ni qu’un menu multilingue est utilisable.
« Ajouter une page d’approbation » reste ambigu. « Un manager peut approuver une demande pending de sa propre organisation et l’action enregistre l’auteur et l’heure » donne une règle testable. Séparez la demande fonctionnelle de la retouche visuelle pour repérer plus facilement les régressions.
Ne mélangez pas une refonte de l’authentification, du schéma, du paiement et du design dans le même prompt. Tenez un petit journal externe : exigence, prompt, fichiers ou entités touchés, résultat des tests et release. L’historique du chat apporte du contexte, mais ne remplace pas une documentation durable.
Les messages et les actions d’intégration utilisent des soldes distincts ; modèle, complexité, jobs planifiés et appels tiers influencent la consommation. Planifiez en Discuss, filtrez les déclencheurs bruyants et mesurez le workflow réel pendant l’essai au lieu d’extrapoler depuis le premier prompt.
Documentez entités, données exportées, fonctions, secrets, domaines et hypothèses d’authentification. GitHub ou ZIP aide à comprendre le code, mais ne remplace pas automatiquement le runtime géré. Effectuez un export d’essai et identifiez ce qui remplacerait auth, base, fichiers, workflows et hosting.
Déconnectez une intégration, expirez une autorisation, dupliquez un événement et forcez une étape à échouer. Vérifiez que l’utilisateur obtient un message exploitable et qu’un opérateur peut reprendre ou rapprocher. Pour une suppression, prévoyez confirmation, journal et sauvegarde restaurable.
Base44 convient aux personnes capables de définir utilisateurs, règles et critères, mais qui ne veulent pas assembler toute la stack pour un premier test. Les product managers et designers peuvent dépasser la maquette cliquable et soumettre des rôles et des données réelles à l’équipe technique.
Les opérations gagnent un outil adapté à leur processus ; les agences peuvent livrer des portails ou dashboards bornés si propriété, coûts et maintenance sont fixés ; les développeurs peuvent examiner le code, connecter GitHub ou employer le backend et le SDK. Le produit est moins adapté lorsque l’infrastructure auto-hébergée, le contrôle de la base, le natif profond, le hors-ligne complet ou des garanties réglementaires indépendantes sont non négociables.
L’éditeur, l’aperçu et les applications publiées sont centrés sur le web. La création mobile est documentée pour navigateur, iOS et Android, avec certaines limites administratives. Le SDK permet aussi à une interface externe de consommer les services backend gérés.
Les apps reçoivent une adresse Base44 ; les domaines personnalisés et GitHub dépendent du forfait. Les paquets stores restent des wrappers web et exigent les comptes développeur du propriétaire. Confirmez chaque droit dans le tableau actuel avant d’en faire une exigence contractuelle.
La documentation consultée liste Free, Starter, Builder, Pro et Elite et présente un tableau comparatif. Comme les droits peuvent changer sans que les noms changent, ce guide n’attribue pas un ensemble durable de fonctions à un palier. Vérifiez capacités, limites d’apps et crédits directement dans le tableau et le workspace actuels.
Les messages IA et les actions d’intégration ont des allocations distinctes. Le coût d’un message varie selon le travail et le modèle ; les intégrations et workflows peuvent utiliser l’autre solde. Mesurez l’itération, les tâches planifiées et la maintenance, pas seulement la génération initiale. Les prix et remises n’étant pas reproduits ici, contrôlez la page officielle avant achat.
Lovable et Bolt offrent d’autres approches de génération web orientée prompt. Replit associe agent, environnement de développement et déploiement avec une surface code plus générale. Softr met l’accent sur des composants structurés pour applications métier. Retool et Power Apps ciblent les outils internes et la gouvernance d’entreprise. Un développement conventionnel garde le contrôle maximal du runtime et de la base, au prix d’un effort supérieur.
La comparaison doit porter sur le backend, l’export, Git, les permissions, le design, l’observabilité et la migration, pas sur une seule démonstration. Construisez la même tranche verticale et mesurez corrections, coûts et limites dans chaque option.
Les pages Product Hunt et G2 examinées regroupent des expériences positives et négatives, mais leurs contributeurs se sélectionnent eux-mêmes. Le profil G2 affichait quatre avis et Capterra trois : ces deux échantillons sont trop petits pour une conclusion générale. Utilisez leurs thèmes comme questions de test, jamais comme benchmark contrôlé.
Le scanner vérifie les lacunes de permissions, les identifiants exposés, la vérification du login, les packages vulnérables et les en-têtes du navigateur. Base44 attribue explicitement au propriétaire la revue des réglages et des recommandations. Les documents de confidentialité décrivent stockage US par défaut et options de résidence UE/Royaume-Uni variables, en distinguant stockage et traitement ; ils ne justifient pas d’inventer une certification ou un mode de chiffrement.
Le code et les collections peuvent être exportés selon le forfait, mais auth, base et hosting gérés ne deviennent pas des équivalents auto-hébergés. Les wrappers mobiles n’offrent pas actuellement push natif ni hors-ligne complet. StoreKit et Google Play Billing intégrés, auth en marque blanche et certaines fonctions annoncées doivent être traités comme roadmap jusqu’à confirmation.
Oui. La documentation couvre interface, données persistantes, authentification, fonctions, intégrations, workflows et publication. La préparation à la production dépend néanmoins de la conception, des permissions, des tests et des besoins opérationnels.
Non pour créer et itérer une app simple par chat et édition visuelle. Des compétences techniques deviennent utiles pour contrôler schéma, sécurité, fonctions, intégrations et migration. Code, GitHub, CLI et SDK offrent aussi un chemin développeur.
La documentation actuelle liste Free ainsi que Starter, Builder, Pro et Elite. Limites, crédits et fonctions dépendent du tableau du moment ; vérifiez-le avant d’acheter ou de promettre une capacité.
Les premiers couvrent les interactions de construction ou d’édition par IA ; les seconds couvrent les actions utilisant intégrations et automatisations. La consommation varie selon l’action, le modèle et la complexité.
Les forfaits éligibles documentent ZIP, GitHub et export de données. Ils ne recréent pas automatiquement l’authentification, la base et l’hébergement gérés ; une migration complète demande une architecture dédiée.
Base44 peut analyser l’app et générer les paquets sur un forfait éligible. Le propriétaire fournit ses comptes et gère les fiches et la revue. Le paquet est une web-view sans push natif ni hors-ligne complet.
Définissez visibilité et permissions, protégez les secrets, lancez le scanner et testez chaque rôle avec des comptes distincts. Les applications sensibles nécessitent aussi une revue sécurité et conformité adaptée.
Oui, ils sont documentés sur des forfaits éligibles. Les domaines reçoivent HTTPS géré ; GitHub fournit une synchronisation bidirectionnelle. Confirmez les droits et la propriété du dépôt dans le workspace actuel.
Ce sont deux générations. Les apps créées depuis le 6 juillet 2026 utilisent Workflows selon la documentation, tandis que d’anciennes peuvent garder Automations ; une app n’expose qu’un système.
Il peut convenir si le produit accepte le runtime géré et si l’équipe vérifie permissions, fiabilité, coûts, portabilité et support. Faites un pilote représentatif ; choisissez une stack plus contrôlable si infrastructure, natif profond ou contraintes réglementaires sont impératifs.
Comment utiliser Base44
1. Définir les utilisateurs, les données et le résultat
Écrivez d’abord le problème, les rôles, les informations qu’ils créent, les actions autorisées et le résultat observable. Ajoutez ce qui ne doit pas être construit. Pour une application multi-tenant, demandez explicitement comment l’organisation est enregistrée et comment chaque requête limite les données à ce tenant.
Utilisez Discuss pour faire critiquer ce brief sans modifier le projet. Demandez un schéma, les transitions d’état, les contrôles d’accès et les principaux échecs. Le but est d’éliminer une ambiguïté avant qu’elle se propage dans les pages et les fonctions.
2. Générer une seule tranche de bout en bout
Demandez l’inscription, la création d’un enregistrement, sa lecture par le bon rôle et une action métier significative. Inspectez ensuite l’entité, les champs, la validation et le comportement après rechargement ou nouvelle session. Corrigez le modèle avant d’ajouter toutes les variantes, tableaux de bord ou intégrations.
3. Examiner permissions, secrets et fonctions
Vérifiez séparément create, read, update et delete pour chaque rôle. Placez les clés dans les secrets et les appels sensibles dans une fonction backend ou une intégration gérée. Lancez le scanner de sécurité, lisez chaque résultat et testez avec des comptes fictifs ; les recommandations ne sont pas toutes appliquées automatiquement.
4. Ajouter un service externe à la fois
Contrôlez le compte et les portées, exécutez un cas normal puis simulez une erreur. Testez pagination, limite de débit et duplication. Pour un workflow, écrivez le déclencheur, les conditions, les délais et l’état terminal avant d’ajouter les actions. Une modification large rend la cause d’un échec plus difficile à isoler.
5. Tester avec des données et appareils réalistes
Ajoutez des noms longs, champs vides, caractères spéciaux et valeurs limites. Testez en tant que chaque rôle, puis dans une vraie session de navigateur et sur mobile. Pour un paquet store, validez d’abord la version web publiée, puisque le wrapper reflète son comportement.
6. Préparer et observer une release contrôlée
Exportez les données et le code importants, conservez la version revue, notez le forfait et les connexions, relancez le scanner et vérifiez le domaine. Après publication, créez un compte neuf et surveillez les fonctions, workflows et crédits. Transformez les retours en petits changements vérifiables plutôt qu’en nouvelle demande générale.