Le vibe coding a besoin d’un domaine : enregistrez-le sans interrompre votre élan

Vous avez saisi une instruction, regardé l’arborescence des fichiers se remplir et, trente secondes plus tard, une URL fonctionnelle est apparue dans la conversation. Voilà tout l’intérêt du vibe coding : le temps qui sépare « j’ai une idée » de « quelque chose fonctionne sur Internet » ne dépasse désormais guère une pause-café. Sauf que l’URL affichée se termine par quelque chose comme my-app-a3f9.vercel.app ou my-app.lovable.app : c’est un sous-domaine de plateforme, pas un nom que vous mettriez sur une carte de visite. C’est généralement au moment de passer à un domaine qui vous appartient vraiment que l’élan se brise. Pourtant, rien ne l’impose.

Ce que signifie vraiment le « vibe coding »

Si le terme ne vous est pas encore familier, Wikipédia définit le vibe coding comme « une pratique de développement logiciel assistée par l’intelligence artificielle (IA), dans laquelle le développeur décrit un projet ou une tâche dans une instruction adressée à un grand modèle de langage (LLM), qui génère automatiquement le code source ». Sa particularité ne tient pas seulement au fait que l’IA écrit le code — de nombreux outils plus anciens le faisaient déjà par autocomplétion —, mais au fait que vous acceptez souvent le résultat et poursuivez les itérations en décrivant la modification suivante en langage naturel, plutôt qu’en lisant chaque ligne produite par le modèle. Andrej Karpathy, ancien responsable de l’IA chez Tesla et cofondateur d’OpenAI, a forgé le terme en février 2025. Il s’est répandu si vite que Merriam-Webster l’a signalé comme expression argotique en vogue moins d’un mois plus tard, avant que le Collins English Dictionary ne le désigne comme l’un des mots de l’année.

Il ne s’agit pas de dénigrer cette pratique. Décrire ce que l’on veut et obtenir en retour une application fonctionnelle constitue une manière réellement nouvelle de créer. Les outils conçus autour de cette approche — Cursor, Lovable, Replit, bolt.new, v0, Claude Code — sont devenus suffisamment performants pour qu’obtenir un prototype fonctionnel ne soit plus l’étape la plus difficile. La difficulté, ou du moins la partie qui semble toujours dater de 2015, vient après le « ça marche » : lui trouver un nom et lui attribuer une véritable adresse.

Le dernier kilomètre : du sous-domaine de plateforme à votre propre domaine

Toutes ces plateformes résolvent le même problème de la même façon : publier d’abord, déployer sur un sous-domaine de leur propre domaine, puis laisser la configuration d’un domaine personnalisé comme une étape facultative à effectuer ultérieurement dans un panneau de réglages. C’est le bon choix par défaut — vous ne devriez pas avoir à posséder un domaine avant même de savoir si votre idée fonctionne —, mais cela fait du sous-domaine de la plateforme une étape intermédiaire, pas une destination. Il est moins facile à prononcer, difficile à mémoriser et annonce à quiconque regarde la barre d’adresse : « J’utilise encore l’offre gratuite de l’outil de quelqu’un d’autre. »

Enregistrer le véritable domaine est une petite tâche dans l’absolu — rechercher un nom, l’acheter, configurer quelques enregistrements DNS —, mais c’est la seule étape de toute la boucle du vibe coding qui, traditionnellement, se déroule dans un environnement complètement distinct.

Pourquoi quitter l’éditeur interrompt l’élan

Voici la véritable source de friction : ce n’est pas que l’enregistrement d’un domaine soit difficile, mais qu’il se passe ailleurs. Pour enregistrer un domaine de façon traditionnelle, vous interrompez la conversation avec votre agent de code, ouvrez un onglet de navigateur, arrivez sur la page d’accueil d’un bureau d’enregistrement, lancez une recherche de nom, devez décliner trois options supplémentaires — protection de la vie privée, hébergement de messagerie et créateur de site dont vous n’avez pas besoin —, cherchez quelles cases décocher, payez, puis — et c’est la partie que les guides génériques sur les domaines passent sous silence — déterminez quel enregistrement DNS réclame votre plateforme d’hébergement, retrouvez sa valeur dans un autre tableau de bord et collez-la dans un troisième onglet.

Ce n’est pas une tâche, mais cinq, réparties entre trois produits différents, dont aucun ne sait ce que vous venez de créer ni sur quelle plateforme vous l’avez déployé. Chaque changement de contexte a un coût réel : vous perdez le fil de ce que vous faisiez et risquez de revenir une heure plus tard, après vous être laissé distraire par quelque chose dans l’un de ces autres onglets. Pour une tâche de cinq minutes, la surcharge est considérable.

Enregistrez-le sans quitter la conversation

La solution consiste à traiter le domaine comme le déploiement : un nouvel appel d’outil dans la même conversation, pas une course à faire séparément. L’agent qui a généré la structure de votre application et lancé son déploiement dispose déjà du contexte — le nom de l’application et la plateforme sur laquelle elle fonctionne. Il est donc aussi le mieux placé pour vérifier un nom, l’enregistrer et configurer le DNS.

Réduit à l’essentiel, le parcours comporte trois étapes :

Demandez à l’agent de vérifier le nom. « myapp.com est-il disponible ? » déclenche un appel en lecture seule, qui fonctionne donc même avant que vous ayez connecté quoi que ce soit disposant d’un accès en écriture.
Confirmez et enregistrez. « Enregistre-le pour un an » soumet la commande ; l’agent en suit l’avancement jusqu’à son terme.
Faites-le pointer vers votre déploiement. Donnez à l’agent l’enregistrement demandé par votre plateforme d’hébergement — un enregistrement A pour un domaine racine, un CNAME pour un sous-domaine — et il l’écrit. Si vous confiez entièrement le DNS à votre hébergeur, il redirige plutôt la délégation du domaine au niveau des serveurs de noms.

Voilà la logique générale. Les détails exacts — le fichier de configuration lu par chaque éditeur, les valeurs DNS précises demandées par Vercel et Cloudflare Pages — sont déjà décrits pas à pas dans Démarrage rapide avec Namefi MCP : Claude Code, Cursor et Windsurf, cet article ne les répétera donc pas. Si vous programmez dans autre chose que ces trois éditeurs — OpenAI Codex, Gemini CLI, Claude Desktop ou tout autre outil compatible avec le MCP —, Comment enregistrer un domaine avec votre Agent IA sur Namefi centralise une configuration vérifiée pour chacun d’eux, ainsi qu’un parcours REST brut pour les outils qui ne prennent pas du tout le MCP en charge nativement.

Laissez aussi l’agent proposer des noms

L’étape du choix du nom mérite une mention particulière, car elle rompt souvent l’élan autant que le paiement. Dans le parcours traditionnel, vous imaginez un nom, passez dans l’onglet du bureau d’enregistrement, découvrez qu’il est pris, en trouvez un autre, revenez dans l’onglet, puis recommencez jusqu’à ce qu’un nom convienne ou que vous abandonniez et ajoutiez un chiffre à la fin.

L’API de Namefi propose une vérification de disponibilité en masse. La même référence namefi.io/llms.txt, que chaque agent consulte, la décrit comme un moyen de « passer en revue plusieurs noms à la fois ». Au lieu de tester les candidats un par un, vous pouvez donc transmettre toute une liste à votre agent et savoir lesquels sont réellement disponibles en un seul aller-retour. En pratique, le choix du nom tient alors en une instruction : « L’application est un outil de suivi des habitudes appelé Streaky. Vérifie streaky.com, streaky.app, getstreaky.com et streaky.io, puis dis-moi lesquels sont disponibles. » L’agent exécute la recherche groupée, vous présente le résultat et vous choisissez parmi des noms que vous savez réellement pouvoir obtenir, au lieu de vous attacher à un nom déjà enregistré.

Exemple concret : de l’instruction à l’URL publique

Imaginons que vous ayez passé un après-midi à créer par vibe coding un petit outil — une application de liste de courses partagée, conçue parce que les solutions existantes vous agaçaient. Elle est accessible sur un sous-domaine de plateforme, elle fonctionne, et deux ou trois amis vous demandent le lien. Voici tout le reste de la session, toujours dans la même fenêtre de conversation :

Vous demandez si cartly.app est disponible. Il l’est. Vous dites : « Enregistre-le pour un an et fais-le pointer vers ce que nous venons de déployer. » L’agent soumet l’enregistrement, vérifie régulièrement son état jusqu’à son achèvement, puis consulte votre plateforme d’hébergement — dans son propre tableau de bord, d’un simple coup d’œil — pour savoir quel enregistrement DNS elle exige pour le domaine que vous venez d’acheter. Il s’agit ici d’un enregistrement A, puisque vous utilisez le domaine racine plutôt qu’un sous-domaine www. Vous transmettez cette valeur à l’agent, qui écrit l’enregistrement. Quelques minutes plus tard — le DNS demande un peu de temps pour se propager —, cartly.app mène exactement à l’application que vos amis ont déjà ouverte dans un autre onglet. Temps total passé hors de l’éditeur : zéro. Nombre total d’onglets ouverts qui ne servaient pas déjà à créer l’application : zéro.

Questions fréquentes

Dois-je connaître le DNS pour faire cela ?

Pas plus que vous n’avez besoin de savoir comment fonctionne un index de base de données pour en utiliser un. Votre agent demande à la plateforme d’hébergement quel enregistrement elle attend et l’écrit ; vous confirmez surtout des valeurs au lieu de les composer manuellement.

Cela fonctionne-t-il avec toutes les plateformes de vibe coding, ou seulement certaines ?

L’enregistrement et le DNS sont indépendants de la plateforme : il s’agit d’un domaine et d’un enregistrement DNS, qui fonctionnent de la même manière quel que soit l’outil ayant créé votre application. Seul le type d’enregistrement demandé par votre plateforme d’hébergement varie ; le Démarrage rapide avec Namefi MCP couvre précisément Vercel et Cloudflare Pages.

Le domaine que j’enregistre de cette façon est-il tokenisé ?

Oui, par défaut. Namefi est un bureau d’enregistrement accrédité par l’ICANN. Parallèlement à l’enregistrement standard, il enregistre le domaine sous forme de NFT dans le portefeuille associé à votre clé API, sur Base. Vous obtenez donc à la fois un domaine fonctionnel ordinaire et un titre de propriété on-chain, et non l’un à la place de l’autre.

Que se passe-t-il si le nom exact que je veux est déjà pris ?

C’est précisément le rôle de la vérification de disponibilité en masse décrite plus haut. Transmettez plusieurs candidats à votre agent — différentes variantes de TLD, des préfixes, des synonymes — au lieu de les tester un par un, puis laissez-le vous indiquer ceux qui sont réellement disponibles.

Dois-je créer un compte Namefi avant d’essayer ?

Non. La vérification de disponibilité est en lecture seule et ne nécessite aucune authentification. Vous pouvez donc configurer la connexion et tester un nom avant de générer une clé API ou d’approvisionner quoi que ce soit.

Donnez un nom à votre produit sans quitter votre élan

Le domaine n’est pas un projet distinct : c’est une décision d’infrastructure comparable au choix d’une plateforme d’hébergement. Rien ne justifie qu’il demeure la seule étape de la publication d’une application qui exige encore un onglet de navigateur et un formulaire de paiement. La prochaine fois qu’un agent vous remettra une application fonctionnelle sur un sous-domaine de plateforme, restez dans la conversation et demandez-lui de vérifier un nom.

Générez une clé API Namefi et essayez-la sur ce que vous êtes en train de créer, ou commencez par le guide complet Démarrage rapide avec Namefi MCP : Claude Code, Cursor et Windsurf.

Sources et lectures complémentaires

Wikipédia — Vibe coding (définition, création du terme par Andrej Karpathy en février 2025, chronologie de son adoption)
Namefi — namefi.io/llms.txt (point d’accès de disponibilité en masse, URL du serveur MCP, référence pour l’enregistrement et le DNS)
Namefi — Démarrage rapide avec Namefi MCP : Claude Code, Cursor et Windsurf (configuration par éditeur, parcours complet en cinq étapes, étapes DNS pour Vercel et Cloudflare Pages)
Namefi — Comment enregistrer un domaine avec votre Agent IA sur Namefi (configuration de Codex, Gemini CLI et Claude Desktop, ainsi que parcours REST brut)
Model Context Protocol — modelcontextprotocol.io (présentation du protocole)

Aileen Wright est une étudiante d'une vingtaine d'années qui vit à New York, où le chemin entre le mur d'un musée et la salle de lecture d'une bibliothèque ne demande que quelques pas, mais peut remplir un long après-midi. C'est par l'art et l'histoire qu'elle en est venue à écrire sur les noms : la manière dont un portrait, une pièce de monnaie ou la marge d'un manuscrit peut porter un nom à travers les siècles et en transformer le sens au fil du temps.

La plupart des semaines, on peut la trouver à Central Park, un livre de poche à la main, ou dans le calme d'une salle de lecture publique, à rechercher l'origine véritable d'un nom plutôt que la signification que lui prête une liste de noms. Elle apprend également à coder en autodidacte, ce qui l'a rendue particulièrement attentive à l'orthographe, au classement et aux petits détails qui permettent à un nom de bien traverser les années.

Pour Namefi, elle écrit sur l'histoire et la culture qui se cachent derrière les noms de domaine, sur les récits que portent les marques lorsqu'elles changent de nom, et sur la différence entre une belle histoire et une source vérifiée.