Vibe coding ou no-code : comparatif sur un mini CRM

Pour choisir entre vibe coding et no-code, regarde d’abord qui maintiendra l’application dans six mois. Le no-code convient mieux à un outil métier standard sans équipe technique ; le vibe coding devient pertinent pour un produit sur mesure dont tu veux posséder le code, à condition d’accepter les tests, la sécurité et la maintenance. Entre les deux, une approche hybride est souvent la plus rationnelle.

Les deux promesses se ressemblent pourtant beaucoup : « décris ton application, l’IA écrit le code » d’un côté, « assemble ton application sans écrire de code » de l’autre. Le vibe coding vient d’un post d’Andrej Karpathy publié le 2 février 2025 ; le no-code, plus ancien, repose sur des briques visuelles testées et maintenues par un éditeur.

Alors, si tu veux construire un outil pour ton activité aujourd’hui, laquelle des deux voies prendre ? Le match no-code vs vibe coding ne se juge pas sur des démos : la bonne façon de répondre, c’est de donner le même cahier des charges aux deux méthodes et de regarder ce qui se passe à chaque étape, où ça avance, où ça coince, combien ça coûte sur un an, et surtout qui possède quoi à la fin.

C’est le programme de cet article, avec un mini CRM comme banc d’essai, Airtable côté no-code, Lovable côté vibe coding, et un verdict final qui dépend de ton profil plutôt que d’une préférence de chapelle. Aucune ligne de code à écrire pour suivre, c’est promis, on est là pour décider, pas pour développer.

Le cahier des charges commun : un mini CRM en six exigences

Une comparaison honnête commence par un objectif identique et mesurable des deux côtés. Le mini CRM est un bon banc d’essai : assez simple pour être terminé, assez riche pour toucher les points qui fâchent, les automatisations, les données, le partage.

Voici les six exigences, chacune vérifiable par oui ou non :

Six lignes, rien d’exotique : c’est le quotidien d’un indépendant ou d’une petite équipe commerciale. Et pourtant, chaque méthode va buter sur des lignes différentes de ce tableau, ce qui est exactement ce qu’on cherche à observer. Deux ateliers, le même plan, des accrocs différents : deux remix du même morceau, même mélodie, prods différentes.

Le chemin no-code : le CRM dans Airtable

Commençons par la voie la plus ancienne, celle dont les limites sont les mieux connues. Airtable se présente comme un tableur relié à des vues : tu crées une table Contacts avec tes colonnes typées, et les exigences 1, 2 et 3 tombent presque toutes seules. La vue kanban groupée par statut donne le pipeline en quelques clics, une table Activités liée aux contacts porte les notes horodatées. Cette première phase est la force historique du no-code : la structure existe avant toi, tu la remplis.

L’import CSV, exigence 5, est natif lui aussi. C’est à partir de l’exigence 4, la relance, que la pente change. Il faut passer par les automatisations d’Airtable, comprendre leur logique de déclencheur et de condition, et découvrir au passage que le champ « dernière activité » ne se calcule pas tout seul : il faut le construire. Rien d’infranchissable, mais tu n’assembles plus des briques, tu apprends un système.

L’exigence 6, le partage, fait apparaître la vraie ligne de facture. Le deuxième utilisateur qui modifie des fiches est un « collaborateur », et d’après la grille officielle des plans Airtable, chaque collaborateur du plan Team coûte 24 dollars par mois, ou 20 en facturation annuelle, relevé en juillet 2026. Le plan gratuit existe, mais il plafonne à 1 000 enregistrements par base : un CRM actif y sera à l’étroit en quelques mois, le plan Team monte à 50 000.

Un plafond moins connu mérite d’être noté au passage, parce qu’un CRM finit toujours par accumuler des pièces jointes, devis en PDF, contrats scannés : le stockage de fichiers est limité à 1 Go par base en gratuit et 20 Go en Team, d’après la même grille. Des devis de quelques Mo pièce, multipliés par des centaines de contacts, y creusent leur chemin plus vite qu’on ne l’imagine.

Bilan de ce chemin : les exigences structurelles coulent de source, l’automatisation demande un apprentissage, et le coût est proportionnel aux humains, pas à l’usage. Retiens ce dernier point, il sera inversé en face.

Le chemin vibe coding : la même app par prompts

Sur l’autre chemin, la première impression est spectaculaire, et il faut la dépasser. Tu ouvres Lovable, tu écris « crée un CRM avec des contacts, un pipeline kanban et des notes d’activité », et une application apparaît, avec une vraie interface, en quelques minutes. Les exigences 1, 2 et 3 semblent réglées avant d’avoir bu ton café.

Semblent. Parce que le cycle réel du vibe coding prend la forme d’une boucle, dont chaque tour se paie :

Chaque tour de boucle consomme un crédit, la monnaie des outils de vibe coding. D’après la grille relevée en juillet 2026, le plan gratuit de Lovable donne 5 crédits de construction par jour, plafonnés à 30 par mois, et le plan Pro coûte 25 dollars par mois pour 100 crédits mensuels.

Une nuance d’usage découle directement de ce compteur : le rythme. Avec les crédits quotidiens du plan gratuit, un projet du soir avance par petites sessions, quelques échanges puis on reprend demain, ce qui convient très bien pour apprendre. Le jour où tu construis pour de vrai, avec une échéance, le plan payant cesse d’être une option, parce qu’une session de débogage sérieuse consomme en une heure ce que le gratuit donne en une semaine.

La boucle se corse aux exigences 4 et 6, exactement là où le no-code demandait son apprentissage, mais pour une raison différente : la relance et le multi-utilisateurs exigent une base de données et une authentification. L’IA te proposera de brancher un service de base de données, te guidera, et c’est généralement là que les tours de boucle s’accumulent : une migration qui échoue, une règle de sécurité mal générée, une correction qui casse ce qui marchait la veille. Le phénomène a un nom chez les habitués, la régression, et il constitue la vraie ligne de coût du vibe coding : ce que tu paies, au fond, ce sont les allers-retours bien davantage que l’application elle-même. La régression, c’est le taximètre qui tourne pendant que la voiture recule.

En échange de cette friction, tu obtiens quelque chose que l’autre chemin ne donnera jamais : du code. La documentation Lovable décrit une synchronisation bidirectionnelle avec GitHub, disponible sur tous les plans : chaque modification part dans ton dépôt, et ce qu’un développeur pousse dans le dépôt revient dans l’outil. Ton application est un vrai projet React que n’importe quel développeur peut ouvrir demain. Carré.

Le protocole pour les départager toi-même

Tu remarqueras que je ne t’ai donné aucun chronomètre, aucun « 47 minutes contre 2 h 30 ». C’est volontaire : je n’ai pas de mesure faite dans des conditions comparables à te montrer, et un faux chiffre précis est pire qu’une absence de chiffre. À la place, voici le protocole pour produire les tiens, en une après-midi :

1. Prends le tableau des six exigences tel quel, sans en ajouter.
2. Fais les deux builds le même jour, dans l’ordre que tu veux, en notant trois choses par exigence : le temps passé, le nombre d’interventions où tu as dû chercher de l’aide hors de l’outil, et si tu as abandonné l’exigence.
3. Arrête chaque build à 2 heures, même inachevé. Le plafond fait partie de la mesure : l’important est de voir jusqu’où chaque méthode t’emmène dans un budget de temps réaliste, et un build inachevé est un résultat en soi.
4. Une semaine plus tard, rouvre les deux versions et modifie quelque chose de petit : ajouter un champ « budget » sur la fiche contact. Le temps de cette modification vaut plus que tout le reste : il prédit ta vie avec l’outil.

La quatrième étape est celle que tous les comparatifs sautent, parce qu’elle demande de revenir. C’est pourtant elle qui sépare un outil qu’on a réussi à utiliser une fois d’un outil avec lequel on peut vivre.

Le coût réel sur douze mois

Le protocole mesure ton temps, il reste à compter l’argent, et la comparaison des montants est moins intéressante que la comparaison des logiques. Les deux méthodes ne facturent pas la même chose.

La dernière ligne du tableau est celle qui change la nature de la dépense. Chez Airtable, tu loues un service : tant que tu paies, tout fonctionne, le jour où tu arrêtes, il reste un export CSV. Chez Lovable, tu paies un artisan à la tâche : ce qui est construit t’appartient, et l’abonnement ne conditionne que la suite de la construction. Aucun des deux modèles n’est moralement supérieur, mais ils ne répondent pas à la même question, et beaucoup de déceptions viennent d’avoir répondu à l’une en croyant répondre à l’autre. Choisis ta question avant de choisir ton camp.

Il manque une ligne à ce tableau, la plus difficile à chiffrer et souvent la plus lourde : ton temps. Les heures passées à construire, corriger et faire évoluer l’outil ont la valeur de ce que tu aurais facturé à la place. C’est précisément ce que le protocole de la section précédente mesure, et c’est pour ça que sa quatrième étape, la petite modification une semaine plus tard, pèse plus que le prix des abonnements dans une décision honnête.

Propriété et lock-in : qui possède quoi à la fin

Puisque la vraie différence est là, regardons-la en face, avec les documentations officielles plutôt que les slogans. Le spectre de la propriété a deux extrêmes documentés.

À une extrémité, Bubble, l’un des constructeurs d’applications no-code les plus établis, écrit noir sur blanc dans sa documentation sur la propriété que les applications ne peuvent tourner que sur sa plateforme et qu’aucun export du code n’est possible, parce qu’aucun code n’est généré. Les données sortent en CSV, le design peut être exporté, la logique reste. L’éditeur s’engage, en cas de disparition, à ouvrir le code source de la plateforme elle-même, un engagement qu’il faut saluer, et qui confirme au passage à quel point la question est sérieuse.

Airtable occupe le milieu du spectre : tes données sortent proprement, ta structure se réplique ailleurs à la main, tes automatisations se réécrivent. À l’autre extrémité, Lovable pousse l’intégralité du code dans ton dépôt GitHub dès le plan gratuit.

Posséder le code semble donc l’argument massue du vibe coding. Il mérite d’être regardé avec un peu de philosophie, au sens propre : posséder un code qu’on ne sait pas lire, c’est comme posséder un livre dans une langue qu’on ne parle pas. La propriété est réelle, tu peux le prêter, le confier à un traducteur, le déménager. Mais tant que personne dans ton équipe ne le lit, sa valeur d’usage dépend d’un tiers, développeur ou IA. La propriété du code est un droit de sortie, pas une autonomie. C’est déjà beaucoup : un droit de sortie change ta position de négociation face à tous tes fournisseurs. Ce n’est simplement pas la liberté totale que le marketing suggère.

Maintenabilité : six mois plus tard

Le droit de sortie se paie d’une responsabilité d’entretien, et c’est le critère que les démos ne montrent jamais, parce qu’il n’existe pas le jour de la démo. Projetons les deux CRM six mois plus tard.

Côté no-code, l’outil a évolué sans toi, et c’est double tranchant. Les correctifs de sécurité, la montée de version, la compatibilité navigateur : l’éditeur s’en charge, tu n’y as jamais pensé. En échange, l’interface a peut-être changé, une fonctionnalité que tu utilisais a été déplacée ou replafonnée, et tu n’as pas eu ton mot à dire. Tu habites un appartement bien géré : entretien inclus, murs porteurs intouchables. Et le proprio repeint quand il veut, y compris ton mur préféré.

Côté vibe coding, rien n’a bougé, et c’est le problème. Les dépendances de ton code ont vieilli, une faille a peut-être été publiée dans l’une d’elles, et personne ne mettra à jour quoi que ce soit tant que quelqu’un, toi, un développeur, ou toi armé de l’IA, ne rouvrira le projet. Le code t’appartient, donc les bugs aussi, version dépôt Git du vieux constat de Notorious B.I.G., plus d’argent, plus de problèmes : plus de code, plus de responsabilités.

C’est ici que la logique de possession, si tu la suis jusqu’au bout, débouche sur une compétence qui s’apprend : héberger et entretenir ses propres services. La démarche complète, serveur, sauvegardes, mises à jour maîtrisées, est exactement ce que couvre le guide pour auto-héberger sa stack d’automatisation sur un VPS, et une application sortie de Lovable peut finir sa vie sur la même machine, chez toi.

Le verdict par profil

Tous les critères sont posés, il ne reste qu’à les croiser avec la seule variable qui manquait : toi. Quatre profils couvrent la plupart des situations.

Freelance ou commerçant sans appétence technique : Airtable, sans hésiter. Ton CRM est un outil, pas ton produit. La location d’une structure entretenue est exactement ce qu’il te faut, et les plafonds du plan Team sont loin pour un carnet de clients individuel. Garde tes soirées pour tes clients, pas pour des mises à jour de dépendances.

Indie hacker qui construit son produit : vibe coding. Ton application est ton actif, le code au chaud dans ton dépôt est la seule version de toi-même que tu pourras faire grandir, montrer à un investisseur ou confier à un futur associé. Accepte d’avance les boucles de régression, elles font partie du prix.

PME avec une personne côté ops : commence no-code, et garde le vibe coding pour le jour où une limite réelle est atteinte, un plafond d’enregistrements, un besoin que les briques ne couvrent pas. La migration dans ce sens est banale, l’inverse est un deuil.

Agence ou intégrateur : les deux, et la vraie compétence devient le diagnostic, savoir lequel recommander à quel client. Un client sans équipe technique à qui on livre du code généré est un client qu’on abandonne en réalité, même si le dépôt GitHub fait professionnel sur la facture.

Les pièges des deux chemins

Chaque voie a ses chausse-trappes récurrentes, et les connaître d’avance vaut mieux que les découvrir facturées.

Côté no-code. Le plafond d’enregistrements se rappelle à toi au pire moment, un import qui échoue en fin de mois : surveille la jauge avant qu’elle ne te surveille. Le partage « lecture seule » qui devient « il faudrait qu’il puisse modifier » transforme un invité gratuit en siège payant, budgète les sièges au réel dès le départ. Et l’automatisation construite dans l’outil ne déménage jamais : le jour du départ, seules les données te suivent.

Côté vibe coding. Les crédits fondent dans les boucles d’erreurs, pas dans les réussites : un après-midi à déboguer une authentification consomme plus qu’une semaine de petites évolutions, formule tes prompts comme des rapports de bug précis plutôt que des « ça ne marche pas ». La démo locale n’est pas une mise en production : base de données, sauvegardes et nom de domaine restent à ta charge une fois l’application sortie. Et relis au moins les écrans qui touchent aux données personnelles avant d’envoyer de vrais contacts dedans : tu es responsable de ce que l’application collecte, pas l’IA qui l’a écrite.

Quand le projet dépasse quelques écrans, les règles répétées dans chaque prompt finissent par se contredire. Un CLAUDE.md bien structuré fixe alors les commandes, conventions et interdits du dépôt une fois pour toutes ; il ne remplace pas la revue du code, mais réduit les écarts entre deux sessions de l’agent.

Un piège commun aux deux, enfin : reconstruire un outil qui existe déjà. Avant de bâtir le mini CRM des six exigences, vérifie qu’un tableur partagé ne suffisait pas. La meilleure application est parfois celle qu’on n’a pas construite.

Les limites de cette comparaison

Ce banc d’essai a un périmètre, et il est étroit par construction. Un mini CRM ne teste ni la montée en charge, ni le mobile natif, ni les intégrations profondes avec un système existant : sur ces terrains, les deux méthodes révèlent d’autres visages, et le no-code lourd type Bubble comme le développement assisté sérieux type Claude Code méritent leur propre comparaison. Les agents de code capables de s’outiller eux-mêmes, comme ceux qu’on branche sur un serveur MCP maison, déplacent d’ailleurs déjà la frontière entre les deux mondes.

Les prix cités ont une date, juillet 2026, et une espérance de vie courte : les grilles tarifaires de ce secteur bougent plusieurs fois par an, vérifie-les avant de décider. Enfin, les outils eux-mêmes évoluent vite, dans les deux camps : une faiblesse pointée ici peut être corrigée dans six mois, la logique de fond, elle, louer une structure ou posséder un chantier, bougera beaucoup moins.

Un cas hybride a d’ailleurs son propre banc d’essai : l’AI Workflow Builder de n8n, qui applique la promesse du vibe coding aux workflows d’automatisation eux-mêmes. Et si tu fais le protocole des six exigences, viens poster tes mesures sur le hub lesnocodeurs : quelques dizaines de résultats réels vaudront mieux que tous les comparatifs, celui-ci compris.