Créez, modifiez, publiez, puis gérez votre site et votre application depuis leur propre tableau de bord. Chaque fonctionnalité en vraies captures.
Voir les fonctionnalités
Un projet Next.js en React et TypeScript, envoyé dans votre dépôt GitHub. Un changement de la spec fait dans le dépôt revient dans Eqlo.
Voir la page développeurs
Collez une adresse : on vous dit en trente secondes ce que Google voit réellement de vos pages.
Tester une adresseLe vibe coding consiste à décrire un logiciel en langage naturel et à laisser un modèle écrire le code, en acceptant de ne pas relire chaque ligne. Ce n'est ni de la magie ni une mode : c'est une façon de travailler qui fonctionne très bien sur certaines choses et pas du tout sur d'autres.
Le vibe coding est une pratique de développement où l'on décrit en langage naturel ce que le logiciel doit faire, où un modèle produit le code, et où l'on juge le résultat à l'usage plutôt qu'à la lecture. On corrige en redécrivant, pas en modifiant les lignes.
La syntaxe disparaît du chemin. Vous écrivez « un site pour un cabinet à Montpellier, avec les honoraires et un formulaire », et des pages apparaissent. Vous ne saurez pas pourquoi un fichier s'appelle comme il s'appelle, et ce n'est pas un problème tant que le résultat fonctionne.
Le routage, le schéma, les écrans vides et l'intégration continue avancent plus vite. Vous jetez le décor inutile et vous gardez le socle. Ce qui manque encore, c'est la logique métier qui n'existe que chez vous, et c'est précisément là que votre temps a de la valeur.
Le terme a été employé publiquement par Andrej Karpathy, cofondateur d'OpenAI et ancien responsable de l'intelligence artificielle chez Tesla, en février 2025. Il décrivait une façon de programmer où l'on se laisse porter par le dialogue avec le modèle, où l'on accepte le code proposé sans le relire ligne à ligne, et où l'on corrige en redemandant plutôt qu'en éditant.
Le mot a été repris en quelques semaines, d'abord par enthousiasme puis par moquerie, ce qui arrive à tous les termes qui décrivent bien quelque chose. Sa définition d'origine contient déjà la nuance que les deux camps ont oubliée : Karpathy le décrivait pour des projets jetables, pas pour du logiciel de production.
Cette distinction compte toujours : décrire un logiciel à un modèle sert à explorer, pas à livrer. Confondre les deux produit exactement les résultats qui alimentent les moqueries.
Trois usages tiennent debout, et ils ont un point commun : le coût d'une erreur y est faible et le retour est immédiat.
Construire trois versions d'un parcours en une matinée pour voir laquelle tient, puis jeter les deux autres. Le code produit n'a pas besoin d'être durable puisqu'il sert à décider, pas à durer.
Le routage, le schéma de données, l'authentification, les états vides et la configuration de déploiement sont les mêmes dans tous les projets. Les générer prend une heure au lieu d'une semaine, et un développeur reprend ensuite la partie qui compte.
Un outil interne pour six personnes, une page de campagne, un tableau de suivi. Ces besoins réels ne passaient jamais le seuil de priorité d'une équipe technique, et ils restaient dans des tableurs.
Trois limites reviennent systématiquement, et aucune ne se règle en écrivant un meilleur prompt. Les connaître évite de découvrir le problème après trois semaines.
Le code généré fonctionne, donc rien ne signale qu'il est mal organisé. La logique métier se retrouve dans un composant d'affichage, une règle est dupliquée à trois endroits, un nom de champ ne veut plus rien dire. Rien ne casse, jusqu'au jour où il faut changer quelque chose et où chaque modification en casse une autre.
Un paiement bancaire propriétaire, un dossier de santé réglementé, un calcul dont dépend une conformité : ces sujets demandent qu'une personne comprenne chaque ligne et en réponde. Ce n'est pas une question de capacité du modèle, c'est une question de responsabilité.
C'est le mur le plus honnête, parce qu'il concerne l'utilisateur plus que l'outil. Cette façon de travailler suppose d'accepter de ne pas tout relire. Sur un projet jetable, c'est un gain. Sur un projet qui vivra deux ans, c'est un report de dette que quelqu'un paiera.
La différence entre un résultat exploitable et un résultat à jeter tient rarement au modèle. Elle tient à quatre habitudes de rédaction.
Décrivez ce que l'utilisateur fait, pas ce que le code doit être. Un prompt qui parle de composants et de structure produit ce que vous auriez écrit vous-même, en moins bien. Un prompt qui décrit un parcours laisse le modèle organiser le code.
Fais un composant React avec un useState pour la liste et un useEffect pour charger les donnéesUn espace de suivi des commandes. Le client voit ses commandes des douze derniers mois, filtrables par statut : en préparation, expédiée, livrée. Chaque ligne affiche le numéro, la date, le montant et le statut. En cliquant sur une ligne, il voit le détail et le suivi de livraison. S'il n'a aucune commande, une phrase l'invite à visiter le catalogue.Que se passe-t-il quand la liste est vide, quand le chargement échoue, quand il y a deux mille lignes, quand le texte est trop long. Ce sont les trois quarts des corrections que vous feriez ensuite, et elles coûtent une phrase chacune.
Un prompt qui demande cinq changements produit cinq approximations. Un prompt qui en demande un produit un résultat net, et vous pouvez revenir en arrière si ça ne va pas.
Vos statuts, vos rôles, vos unités, votre vocabulaire métier. Un modèle invente des noms génériques, et ces noms se figent dans le schéma. Les corriger après coup est bien plus cher que de les donner tout de suite.
Les deux suppriment l'écriture de code, mais pas de la même façon, et ce qui reste à la fin n'est pas le même objet.
| Code décrit | No-code | |
|---|---|---|
| Ce que vous manipulez | des phrases | des blocs dans un éditeur |
| Ce qui est produit | du code source | une configuration propriétaire |
| Ce que vous récupérez | des fichiers exportables | rien de lisible hors de l'outil |
| Le plafond | la complexité du domaine | ce que l'éditeur a prévu |
| Qui peut reprendre | n'importe quel développeur | un spécialiste de cet outil |
La différence pratique tient en une question : le jour où vous quittez l'outil, partez-vous avec quelque chose. Avec du code, oui. Avec une configuration propriétaire, non.
Le prototype, ce que reçoivent vos développeurs, le no-code et les offres.
Andrej Karpathy l'a employé publiquement en février 2025, pour décrire une façon de programmer où l'on accepte le code proposé sans le relire ligne à ligne. Sa définition d'origine visait des projets jetables, pas du logiciel de production.
Oui, des fichiers source ordinaires que n'importe quel développeur peut ouvrir. C'est la différence principale avec le no-code, qui produit une configuration propriétaire illisible hors de son outil.
Non pour obtenir un résultat, oui pour juger de sa qualité. Quelqu'un qui ne lit pas le code peut publier un site ou un outil interne. En revanche, il ne voit pas si la logique est au bon endroit, et cela se paie plus tard.
Pour le socle, oui. Pour la logique métier d'un produit qui vivra plusieurs années, non sans revue. La bonne pratique est de traiter chaque génération comme une contribution externe : branche dédiée, relecture, tests, puis fusion.
Demander cinq choses dans un seul prompt. Le modèle produit cinq approximations et vous ne savez plus ce qui a cassé quoi. Une demande par échange, avec la possibilité de revenir en arrière, va beaucoup plus vite au total.
Il applique les pratiques courantes, mais il ne remplace pas un audit. Sur tout ce qui touche à l'argent, aux données personnelles ou à l'authentification vers des systèmes externes, faites relire par quelqu'un dont c'est le métier.
Une question de degré. Un assistant complète pendant que vous écrivez et vous relisez chaque suggestion. La pratique décrite ici assume de ne pas relire et de juger à l'usage. Les deux cohabitent chez la plupart des développeurs.
En partie. Vous décrivez et Eqlo construit, mais l'IA n'improvise pas le code de chaque site : elle rédige une description structurée, qu'un compilateur transforme en pages en vérifiant les mêmes règles de qualité à chaque fois. Le bouton GitHub, présent sur toutes les offres, envoie cette description et un projet Next.js complet dans votre dépôt.
Gratuit pour commencer, sans carte bancaire. Le bouton GitHub envoie le projet dans votre dépôt, quelle que soit l'offre.