Construire avec CometAPIBesoin d'une seule API pour plusieurs modèles ?Testez le workflow dans Playground, puis créez une clé API lorsque le modèle et le coût correspondent à votre cas d'usage.
Découvrez comment Lovable développe des applications web, explorez ses fonctionnalités clés et connectez CometAPI via un back-end sécurisé, à l'aide d'un tutoriel pratique consacré à un assistant de rédaction.
Deon GoodwinÉquipe de recherche sur les modèles IA et API
Lovable est une plateforme de développement alimentée par l’IA qui transforme des instructions en langage naturel en code d’application web éditable. Elle aide les fondateurs, designers, équipes produit et développeurs à créer des interfaces, connecter des services backend et publier des applications via une conversation itérative. Ce guide explique ses capacités, l’architecture des projets et une intégration pratique de CometAPI pour un assistant d’écriture. L’intégration ajoute l’inférence de modèle à l’application que vous construisez ; elle n’établit pas un moyen de remplacer l’agent de codage propre à Lovable. Les lecteurs doivent comprendre les requêtes HTTP de base et JavaScript, et disposer d’un projet Lovable et d’un compte CometAPI avant de suivre les étapes d’implémentation.
Key Takeaways
Développement assisté par IA : générer et affiner des applications à partir de prompts en langage naturel.
Capacités full-stack : construire des expériences frontend avec fonctions backend, bases de données, authentification et hébergement.
Architecture moderne : à partir de mai 2026, les nouveaux projets Lovable adoptent TanStack Start (basé sur React) et le SSR.
Revu pour la clarté, l'attribution des sources et la terminologie API actuelle.
Compatibilité CometAPI : ajouter une inférence de modèle externe via une fonction backend sécurisée.
Meilleurs cas d’usage : MVP, assistants IA, outils internes, applications de contenu et portails clients.
What Is Lovable and How Does It Work?
Lovable (lovable.dev) est une plateforme alimentée par l’IA pour créer des applications web full-stack de qualité production en langage naturel. Son site officiel et sa présentation du produit constituent les points d’entrée pour découvrir la plateforme.
Vous décrivez ce que vous voulez dans une interface de chat, et elle génère une application fonctionnelle avec :
Backend, base de données, authentification et stockage (via Lovable Cloud intégré, géré par Supabase)
Intégrations, déploiement et code éditable vous appartenant
Elle prend en charge tout le cycle de vie du produit — du prototypage au déploiement — et peut synchroniser le code avec GitHub, GitLab ou Bitbucket. Elle s’adresse aux fondateurs, chefs de produit, non-développeurs et équipes qui veulent aller vite tout en conservant la propriété du code. Elle est issue du projet open source GPT Engineer (fondé à Stockholm en 2023 par Anton Osika et Fabian Hedin) et a été rebrandée/commercialisée sous le nom Lovable.
How Lovable Turns Prompts Into Applications
Décrire les utilisateurs, pages, fonctionnalités et règles métier de l’application.
Générer la première application et inspecter l’aperçu.
Connecter la base de données, la connexion, les paiements ou des API externes.
Tester le comportement et affiner le code, le design et les workflows.
Publier ou continuer à maintenir le code de l’application exportée.
L’article d’ingénierie de Lovable du 1er juin 2026 décrit la migration vers TanStack Start (basé sur React) et le rendu côté serveur pour les nouveaux projets à partir du 13 mai 2026. Les projets existants React + Vite conservent leur architecture antérieure ; vérifiez le projet réel avant de choisir une implémentation via fonction serveur ou Edge Function.
Lovable Technical Specifications
Spécification
Lovable
Catégorie
Constructeur d’applications web avec IA
Interaction principale
Prompts en langage naturel
Framework pour nouveaux projets
React et TanStack Start
Rendu
Rendu côté serveur pour les nouveaux projets
Architecture antérieure
React + Vite
Backend
Lovable Cloud et intégrations prises en charge
Authentification et base de données
Pris en charge
API externes
Connecteurs et requêtes API personnalisées
Intégration IA
Lovable AI et API de modèles externes
Accès au code
Code généré et workflows GitHub
Collaboration
Espace de travail et fonctionnalités de projet
Déploiement
Options intégrées et externes prises en charge
Lovable est une plateforme de développement d’applications, pas un modèle de base. Par conséquent, les paramètres, fenêtres de contexte, débits de tokens et scores MMLU ne décrivent pas Lovable en tant que tel. Ils concernent les modèles d’IA spécifiques impliqués dans le développement ou l’inférence.
Can You Configure CometAPI in Lovable?
Oui — au sein des applications générées avec Lovable. CometAPI peut gérer des requêtes de modèle depuis une fonction backend protégée. Cela est distinct du fait de changer le LLM qui propulse l’agent de codage propre à Lovable.
Vous pouvez intégrer CometAPI dans des applications construites avec Lovable, à condition que les modèles et interfaces sélectionnés soient pris en charge.
Cela ne signifie pas que vous pouvez remplacer directement le modèle proxy de développement utilisé par Lovable lui-même.
Si votre objectif est de contrôler quels modèles votre application appelle, vous devez configurer le routage des modèles dans votre propre code côté serveur.
Intégration
Compatibilité
Explication
Fonctionnalités IA dans une application générée
Oui
Requêtes API côté serveur protégées
Chatbot ou assistant d’écriture
Oui
Appeler des modèles de chat CometAPI pris en charge
Application multi-modèles
Oui
Configurer les IDs de modèles dans le routage backend
Remplacer le modèle interne de codage de Lovable
Non établi comme paramètre standard
La sélection du modèle de l’agent interne est séparée
Service backend via CometAPI
Oui
Intégration HTTP personnalisée ou fonction serveur
API de gestion d’espace de travail Lovable
Séparée
Gère les ressources de la plateforme, pas l’inférence de modèle
L’explication par Lovable de l’orchestration interne des modèles décrit le fonctionnement du routage de son agent de développement. L’intégration CometAPI ci-dessous concerne l’inférence applicative ; cet article ne revendique pas un paramètre CometAPI documenté pour cet agent interne.
How the Lovable and CometAPI Architecture Works
Lovable prend en charge cela de deux manières principales pour les applications que vous construisez :
Secrets (recommandé pour un usage direct)
Stockez votre clé CometAPI comme secret de projet (par ex., COMETAPI_KEY ou OPENAI_API_KEY). Demandez à Lovable, dans le chat du projet, d’intégrer l’API via une Edge Function sécurisée. La clé reste côté serveur et n’est jamais exposée dans le navigateur.
Connecteur personnalisé
Créez un connecteur personnalisé dans le catalogue Connectors de l’espace de travail. Configurez l’URL de base (https://api.cometapi.com/v1), l’authentification (jeton Bearer ou en-tête personnalisé), puis ajoutez une connexion en collant votre clé CometAPI. Les requêtes passent par la passerelle de connecteurs de Lovable, gardant les identifiants chiffrés et hors de votre code.
Notes :
Les fonctionnalités IA intégrées pour les applications utilisent les clés gérées par Lovable et consomment des crédits d’espace de travail. Vous ne pouvez pas les remplacer par une clé CometAPI (ou d’un autre fournisseur).
Pour les appels IA externes à l’intérieur de votre application (chatbots, génération, etc.), l’approche par secrets ou connecteur personnalisé fonctionne et facture l’utilisation à votre compte CometAPI plutôt qu’aux crédits Lovable.
À la date de la dernière documentation, rien n’indique une prise en charge native/pré-intégrée de CometAPI dans le catalogue de connecteurs de Lovable ; vous la configurez comme une intégration générique compatible OpenAI ou API personnalisée.
En bref : Lovable est un puissant constructeur d’applications “vibe-coding” / prompt-to-full-stack, et oui — vous pouvez configurer et utiliser une clé CometAPI de manière sécurisée pour les fonctionnalités IA au sein des applications que vous créez avec lui.
Le navigateur envoie l’entrée au backend de l’application. Le backend lit un secret, appelle CometAPI et renvoie le résultat. Ne placez jamais de clés API privées dans des composants React ou dans tout autre code côté client.
How to Build an AI Writing Assistant With Lovable and CometAPI
L’exemple suivant construit SmartWrite, un assistant d’écriture IA avec une zone de texte, une sélection de ton et une requête CometAPI côté serveur. Choisissez le pattern boundary TanStack pour un projet récent ou le point d’entrée complet de Supabase Edge Function pour un projet plus ancien. Choisissez une seule implémentation backend correspondant à votre projet, configurez ses secrets et confirmez un modèle de chat pris en charge dans votre compte CometAPI. Avant de publier, exécutez l’exemple avec vos propres secrets de projet et un modèle de chat disponible sur votre compte.
Build a responsive AI writing assistant named SmartWrite.
Include a dashboard, a large prompt box, a tone selector
(Professional / Friendly / Concise), a Generate button,
and an output panel with Copy and Clear controls.
Use a clean responsive design with loading states and errors.
Implement AI generation only through a secure server function.
Never expose API credentials to the frontend.
Do not ship mock AI responses.
Step 2: Configure the CometAPI Credential
Générez une clé dans votre compte CometAPI et vérifiez un ID de modèle de chat disponible sur ce compte. Ce tutoriel utilise une intégration directe côté serveur, avec COMETAPI_API_KEY et COMETAPI_MODEL en configuration serveur. Suivez le mécanisme d’accès aux secrets pris en charge par le backend de votre projet généré.
Configuration example: Where to Store and Use CometAPI Credentials
Pour connecter CometAPI de façon sécurisée, demandez à Lovable de créer une intégration côté serveur et de solliciter la clé API via son formulaire sécurisé de secret. Vous pouvez aussi gérer les secrets de projet sous More → Settings → Secrets. Pour un backend Supabase externe, configurez plutôt les secrets dans Supabase. Voir le guide officiel Lovable sur les Secrets.
Respectez ces quatre exigences :
Stocker et lire les clés API uniquement sur le serveur. Ajoutez COMETAPI_API_KEY via l’interface sécurisée des Secrets du projet. Lisez-la exclusivement depuis les secrets serveur ou l’injection d’exécution. Ne mettez jamais la clé dans le code frontend, les variables d’environnement accessibles par le navigateur, les messages de chat ou les captures d’écran.
Garder la configuration API hors des requêtes frontend. Configurez COMETAPI_MODEL côté serveur avec un ID de modèle CometAPI vérifié. Le frontend ne doit envoyer que prompt et tone. Validez les requêtes selon ces champs autorisés et rejetez les propriétés inattendues, notamment config, apiKey et model. Ne laissez jamais les clients fournir des clés API arbitraires ni remplacer la configuration de modèle côté serveur.
Utiliser la bonne méthode d’accès aux secrets selon le runtime. L’implémentation doit correspondre à l’environnement backend réel du projet. Les déploiements basés sur Workers utilisent des liaisons injectées, tandis que les Supabase Edge Functions accèdent aux secrets via Deno.env. N’assumez pas que process.env, Deno.env et les liaisons Workers sont interchangeables. Vérifiez la manière dont les secrets sont injectés avant d’implémenter le handler d’API.
Vérifier la protection des secrets après la mise en production. Inspectez le bundle JavaScript de production, l’onglet Network des DevTools du navigateur et les logs de l’application. Confirmez que les clés API n’apparaissent jamais dans les assets côté client, les charges utiles des requêtes, les réponses, les URLs ou les logs. Vérifiez également que les requêtes CometAPI s’exécutent côté serveur et que les tentatives de contournement de la configuration protégée sont rejetées.
Un secret enregistré ne signifie pas automatiquement que l’intégration est sécurisée ou fonctionnelle. L’intégration est prête uniquement lorsque les appels API côté serveur fonctionnent, que les requêtes client ne peuvent pas outrepasser les paramètres protégés et que les vérifications en production confirment que les identifiants restent privés.
Utilisez le schéma d’architecture suivant pour identifier la frontière frontend-backend et l’emplacement des identifiants protégés. Le schéma est conceptuel, ce n’est pas une capture de l’interface des paramètres de Lovable.
Prompt to give Lovable
Connectez SmartWrite directement à CometAPI via une fonction backend authentifiée. Demandez-moi COMETAPI_API_KEY dans un formulaire sécurisé de secret et utilisez COMETAPI_MODEL pour l’ID de modèle exact que je fournis. Envoyez des requêtes POST vers https://api.cometapi.com/v1/chat/completions uniquement depuis le serveur. Acceptez prompt et tone, validez-les, appliquez des limites par utilisateur et retournez uniquement le texte généré au frontend. Utilisez le runtime backend déjà présent dans ce projet. Ne placez pas d’identifiants dans le chat, le code frontend ou les requêtes navigateur. Ne générez pas de résultats fictifs. Expliquez comment tester l’intégration et affichez des erreurs assainies en cas d’échec.
Lovable prend également en charge des connecteurs personnalisés gérés. Les instructions ici utilisent volontairement la voie d’intégration directe documentée dans son guide d’intégration d’API, afin qu’elles correspondent au helper côté serveur ci-dessous.
Step 3: Test the CometAPI Chat Endpoint
Depuis un terminal Bash de confiance, définissez localement COMETAPI_API_KEY et COMETAPI_MODEL, puis testez POST sur https://api.cometapi.com/v1/chat/completions. Le guide officiel des requêtes CometAPI documente l’URL de base, l’authentification Bearer et le format de réponse de chat. Sélectionnez un modèle prenant en charge cet endpoint ; la compatibilité ne garantit pas toutes les fonctionnalités ou paramètres du fournisseur.
# Set COMETAPI_API_KEY securely in this terminal before running.
# Replace the model value with a chat model verified in your account.
export COMETAPI_MODEL="YOUR_VERIFIED_CHAT_MODEL_ID"
: "${COMETAPI_API_KEY:?Set COMETAPI_API_KEY first}"
curl --fail-with-body --max-time 45 \
https://api.cometapi.com/v1/chat/completions \
-H "Authorization: Bearer $COMETAPI_API_KEY" \
-H "Content-Type: application/json" \
--data "$(printf '{"model":"%s","messages":[{"role":"user","content":"Write a customer welcome email."}],"stream":false}' "$COMETAPI_MODEL")"
Point de contrôle : une réponse réussie contient choices[0].message.content. Si l’authentification échoue ou si le modèle n’est pas disponible, corrigez cela avant de connecter l’interface utilisateur. Ne collez pas d’identifiants complets ni de prompts privés dans des captures de diagnostic.
Step 4: Connect CometAPI Through a Secure Backend
Lovable prend en charge deux architectures backend :
Nouveaux projets (TanStack Start) : utilisez createServerFn pour traiter les requêtes API côté serveur.
Anciens projets React + Vite : utilisez des Supabase Edge Functions pour les appels API côté serveur.
Choisissez l’implémentation qui correspond à l’architecture de votre projet.
Stockez COMETAPI_API_KEY et COMETAPI_MODEL comme liaisons Workers côté serveur. Si votre déploiement utilise un autre adaptateur, servez-vous de son mécanisme d’accès aux secrets.
Ajoutez COMETAPI_API_KEY et COMETAPI_MODEL aux secrets du projet Supabase, puis déployez la fonction.
Dans les deux approches, gardez les identifiants API côté serveur. Les applications de production doivent également implémenter l’authentification, la validation des entrées et des limites d’utilisation par utilisateur.
Step 5: Connect the Lovable Interface
TanStack Start client
import { generate } from "./server/writing.functions";
const { text } = await generate({ data: { prompt, tone } });
// Render text as text content, not as trusted HTML.
React + Vite client
// Use the existing, signed-in Supabase client generated for your project.
const { data, error } = await supabase.functions.invoke("generate-writing", {
body: { prompt, tone },
});
if (error) throw new Error("Generation failed. Please try again.");
const text = data.text;
Utilisez le client correspondant à la branche choisie. TanStack utilise son endpoint RPC généré ; Supabase utilise la fonction generate-writing déployée. Aucun besoin d’inventer une route /api/generate séparée. Le navigateur peut envoyer le jeton de session applicative pour l’authentification, mais ne doit jamais envoyer l’identifiant privé CometAPI ni un objet de configuration. Affichez des états de chargement, d’échec et de réessai dans l’interface.
Step 6: Test and Publish the Application
Après publication, testez l’URL en ligne plutôt que de vous fier uniquement à l’aperçu de l’éditeur. Utilisez un identifiant de test privé et gardez les captures et preuves exemptes de valeurs sensibles. Effectuez ces vérifications avant un accès plus large :
Inspectez le JavaScript compilé côté navigateur, les source maps et la configuration publique pour la clé CometAPI privée. Faites une recherche locale sans imprimer la clé dans une sortie de terminal partagée ni la sauvegarder dans des rapports. Un nom de variable seul n’est pas une preuve de fuite de valeur.
Inspectez les requêtes réseau du navigateur, y compris les charges utiles, en-têtes et réponses d’erreur. La requête ne doit contenir que les entrées d’écriture autorisées et les données d’authentification de l’application ; l’en-tête d’autorisation privé CometAPI appartient uniquement à la requête serveur-vers-fournisseur.
Passez en revue les logs des fonctions, les logs applicatifs, les traces de monitoring et les rapports d’erreurs. N’enregistrez pas de clés, jetons Bearer, objets de configuration ou corps d’erreur complets de l’amont. Si une clé a été exposée, révoquez-la et remplacez-la, puis retirez l’élément d’exposition avant de retester.
Essayez des requêtes non authentifiées et avec session expirée ; elles doivent être rejetées avant tout appel au fournisseur. Soumettez apiKey, config ou model comme champ supplémentaire et vérifiez le rejet. Testez des prompts vides et surdimensionnés, un ton invalide, des pannes du fournisseur et votre quota par utilisateur déployé.
Confirmez qu’une requête valide et connectée produit du texte avec le modèle sélectionné. Enregistrez la version de déploiement et des résultats de test assainis (succès/échec) ; les exemples n’établissent pas que votre propre déploiement a passé ces vérifications.
What Can You Build With Lovable and CometAPI?
Projet
Rôle de CometAPI
Fonctionnalités possibles
Assistant d’écriture IA
Rédiger et reformuler du contenu
Sélection de ton, modèles, éditeur
Résumeur de documents
Résumer du texte extrait
Téléversements, questions-réponses sur documents, points clés
Service client
Classer et rédiger des réponses
Triage des tickets, réponses suggérées
Assistant d’analytique
Expliquer des données métier
Tableaux de bord KPI, insights en langage naturel
Des prompts normaux produisent des réponses lisibles.
Les prompts vides et surdimensionnés sont rejetés en toute sécurité.
Les identifiants API n’apparaissent jamais dans le panneau réseau du navigateur.
Les pannes de modèle renvoient des messages d’erreur non sensibles.
Les utilisateurs authentifiés disposent de limites de requêtes et d’un suivi d’activité.
La mise en page se comporte correctement sur desktop et mobile.
Ce sont des modèles de projet suggérés, pas des affirmations sur des déploiements achevés ou évalués indépendamment.
FAQ
Comment une application multi-tenant doit-elle empêcher l’affichage des enregistrements d’un client dans la réponse IA d’un autre client ?
Dérivez l’identité du tenant et de l’utilisateur depuis la session serveur vérifiée, puis restreignez chaque recherche en base avant de constituer le contexte du modèle. Ne faites jamais confiance à un ID de tenant fourni par le navigateur et ne comptez pas sur une instruction de prompt pour faire respecter l’accès. Lorsque c’est possible, ajoutez des politiques de lignes (row-level) et vérifiez-les avec deux comptes de test. Testez les IDs d’enregistrements, résultats de recherche, fichiers exportés et historiques de conversation pour éviter tout accès croisé.
Quand la génération augmentée par la recherche (RAG) est-elle préférable au fait d’insérer directement des documents dans chaque prompt ?
Utilisez la recherche lorsque le corpus est trop grand pour être envoyé à chaque fois, change fréquemment ou nécessite une traçabilité au niveau des sources. Parsez et indexez les documents, récupérez un petit ensemble pertinent et joignez des identifiants de source à la réponse. La recherche nécessite tout de même une évaluation : une réponse fluide peut citer un passage non pertinent. Gardez les filtres d’accès dans la requête de recherche et testez des questions dont la réponse est absente. Pour un petit document stable, un contexte direct peut être un point de départ plus simple.
Comment ajouter le streaming sans afficher des réponses tronquées ou trompeuses ?
Traitez le streaming comme une fonctionnalité de transport distincte, pas comme un simple remplacement de stream: false. Confirmez le format de streaming du modèle choisi, faites relayer les événements par le backend et gérez les fragments partiels, l’annulation, les timeouts et les pertes de connexion dans l’UI. Marquez une réponse interrompue comme incomplète et laissez l’utilisateur relancer explicitement. Évitez d’afficher le texte streamé comme HTML de confiance. Testez sur le chemin d’hébergement publié, car des intermédiaires peuvent bufferiser un flux qui semblait fonctionner en local.
Que doit vérifier une politique de repli avant de basculer vers un autre modèle ?
Définissez les échecs qui justifient un retry ou un repli, puis vérifiez si l’alternative prend en charge le même endpoint, les instructions, le schéma d’outils et le format de sortie. Gardez les retries bornés et évitez de changer de modèle en silence pour des workflows nécessitant un comportement consistant. Évaluez le repli sur des prompts représentatifs, y compris les cas de refus et de sortie mal formée. Si la sortie du modèle déclenche une action externe, protégez cette action par une confirmation séparée ou une règle d’idempotence afin qu’une génération relancée ne puisse pas répéter l’action.
Quelles preuves une équipe doit-elle conserver avant de promouvoir une fonctionnalité IA d’un pilote à un usage régulier ?
Conservez un jeu d’évaluation versionné avec les comportements attendus, la configuration du modèle et du prompt, des métadonnées de requêtes expurgées, et des enregistrements des cas d’échec. Définissez des critères d’acceptation pour l’exactitude factuelle, la forme des réponses, la latence et les frontières d’accès ; comparez les résultats après des changements de modèle ou de prompt. Pour des entrées sensibles, décidez en amont de ce qui peut être transmis et conservé avant d’activer la fonctionnalité. Ce sont des contrôles d’ingénierie suggérés, pas des garanties que Lovable ou CometAPI assurent un résultat réglementaire particulier.
Conclusion: Is Lovable Worth Using?
Lovable facilite la traduction d’idées en applications web fonctionnelles. Son outillage full-stack et ses intégrations externes sont particulièrement utiles pour valider rapidement des concepts produit. CometAPI ajoute une voie flexible pour l’inférence de modèles dans des workflows IA de chat, d’écriture, d’analytique et autres.
Commencez par une petite application sécurisée, testez la connexion CometAPI, révisez le code généré, puis développez après avoir prouvé la fiabilité de l’expérience cœur.
