Skip to content

Créer un CRM sans code avec l'IA : guide complet

Créer un CRM sans code avec l'IA

Oui, à condition de savoir ce que vous voulez suivre. Un CRM est une plateforme multipage : 12 crédits pour les trois premières pages, puis 3 crédits par page ajoutée. Zugo génère l'interface et les écrans, Supabase stocke les contacts, et chaque ajustement de logique coûte 3 crédits.

La partie difficile n'est pas la génération. C'est de décider, avant de lancer quoi que ce soit, quelles informations vous suivez réellement et lesquelles vous croyez suivre.

Qu'est-ce qu'un CRM généré sait réellement gérer ?

Le cœur du métier, et il est plus petit qu'on ne l'imagine. Une liste de contacts, un statut par contact, un historique d'échanges, une date de relance et quelques filtres. La plupart des indépendants et des TPE n'utilisent rien d'autre, même quand ils paient pour beaucoup plus.

Un CRM construit sur Zugo fait cela correctement : écrans de liste, fiche détaillée, formulaire d'ajout, changement de statut, recherche. Vous obtenez une application qui s'ouvre dans le navigateur et qui contient vos champs à vous, pas ceux d'un éditeur qui a conçu son produit pour un autre secteur.

Ce qu'il ne fait pas d'un seul coup : la synchronisation bidirectionnelle avec une boîte e-mail, le scoring automatique, l'enrichissement de fiches depuis des bases externes. Ces briques existent, mais elles se construisent par étapes, avec des modifications successives, et pas en une phrase.

Le bon critère de décision est simple. Si vous suivez aujourd'hui vos clients dans un tableur et que ce tableur commence à mentir, un CRM généré est largement suffisant. Si vous pilotez une équipe commerciale de quinze personnes avec des règles d'attribution, regardez d'abord les outils du marché.

Quelles données faut-il poser avant de générer quoi que ce soit ?

Ouvrez une feuille et écrivez vos champs à la main. Cette étape prend vingt minutes et détermine tout le reste, parce qu'ajouter un champ après coup coûte une modification à 3 crédits alors que le prévoir au départ ne coûte rien.

Élément Ce qu'il faut décider avant
Contact Personne, entreprise, ou les deux liées
Statut La liste exacte des étapes, dans l'ordre
Historique Notes libres ou événements datés
Relance Date seule, ou date plus responsable
Origine Comment le contact est arrivé chez vous
Montant Devis, contrat signé, ou rien du tout

La colonne des statuts est celle qui pose le plus de problèmes. Beaucoup de gens listent huit étapes et n'en utilisent que trois au bout d'un mois. Prenez les étapes que vous nommez déjà à l'oral quand vous parlez d'un dossier : « à rappeler », « devis envoyé », « signé », « perdu ». Si un nom ne sort pas naturellement, l'étape n'existe pas.

Décidez aussi ce que vous ne suivrez pas. Un CRM qui demande quinze informations à la création d'une fiche finit vide, parce que personne ne remplit quinze champs entre deux rendez-vous. Trois champs obligatoires et le reste facultatif, c'est le format qui survit à l'usage réel.

Comment décrire son CRM pour obtenir une première version utilisable ?

Donnez les champs, les statuts et les écrans. Une description précise produit une application exploitable dès la première construction, une description vague produit une démonstration jolie et inutilisable.

Exemple à adapter : « CRM pour un cabinet de conseil indépendant. Entités : contacts (nom, entreprise, e-mail, téléphone, origine) et opportunités (contact lié, intitulé, montant, statut, date de relance). Statuts : à contacter, échange en cours, proposition envoyée, signé, perdu. Écrans : tableau de bord avec les relances du jour, liste des opportunités filtrable par statut, fiche contact avec historique de notes, formulaire d'ajout rapide. Connexion par e-mail. Interface sobre, dense, lisible sur ordinateur portable. »

Ce paragraphe nomme deux entités, onze champs, cinq statuts, quatre écrans et un mode de connexion. C'est le niveau de détail qui évite les mauvaises surprises. Notre article sur comment écrire un bon prompt décrit la même mécanique appliquée à d'autres projets.

Une précision utile : demandez explicitement l'écran qui vous servira le plus. Pour un CRM, c'est presque toujours la liste des relances du jour, et c'est presque toujours l'écran que les générateurs placent en dernier si personne ne le réclame.

Combien de crédits coûte un CRM sur mesure ?

La grille tient en six lignes, et elle est la même pour un site vitrine et pour une application de gestion.

Action Crédits
Plateforme multipage, trois premières pages 12
Chaque écran supplémentaire 3
Modification sur un projet existant 3
Construction simple d'un projet 6
Construction en mode Hi-Fi 12
Modification en mode Hi-Fi 6

La formule gratuite donne 5 crédits, ce qui ne suffit pas pour une plateforme : elle sert à essayer l'outil sur un projet plus petit. Pro coûte $25 par mois pour 200 crédits, soit environ 16 plateformes multipages, ou 33 constructions, ou 66 modifications. Business coûte $99 par mois pour 800 crédits.

Comptez large sur les modifications plutôt que sur la construction initiale. Un CRM se règle à l'usage : au bout de deux semaines vous voudrez déplacer une colonne, renommer un statut, ajouter un filtre. Regroupez ces demandes par lots, parce que trois corrections envoyées ensemble coûtent 3 crédits et trois corrections envoyées séparément en coûtent trois fois plus.

Faut-il brancher Supabase dès la première version ?

Oui, dès que plusieurs personnes doivent voir les mêmes fiches. Un CRM sans base partagée n'est qu'une maquette, et une maquette de CRM se périme le jour où vous y saisissez de vraies données.

Supabase apporte trois choses au même endroit : la base qui stocke les contacts, la connexion des utilisateurs, et le stockage des fichiers si vous joignez des devis aux fiches. C'est aussi ce qui permet d'ouvrir l'application à un collègue sans lui envoyer une copie du tableur par e-mail. Le détail du branchement est expliqué dans connecter Supabase à un projet Zugo.

Un point que beaucoup découvrent trop tard : les données d'un CRM sont des données personnelles. Nom, téléphone, notes sur des échanges. Vous devez savoir où elles sont hébergées, qui y accède et comment supprimer une fiche à la demande de la personne concernée. Ces trois réponses se préparent au moment de la conception, pas au moment où quelqu'un les réclame.

Si vous préférez commencer sans base et voir d'abord si l'interface vous convient, c'est un choix défendable pour une semaine. Passé ce délai, migrer des données saisies dans une version sans base vers une version avec base coûte plus de temps que le branchement initial.

En quoi un CRM maison diffère-t-il d'un abonnement du marché ?

La comparaison honnête, sans caricature d'aucun côté.

Critère CRM généré sur Zugo CRM du marché
Champs et statuts Exactement les vôtres Ceux prévus par l'éditeur
Mise en route Une plateforme, quelques modifications Compte créé en quelques minutes
Intégrations toutes faites Peu nombreuses Nombreuses et éprouvées
Coût mensuel Formule Zugo, sans coût par siège Souvent facturé par utilisateur
Code source Exportable vers GitHub Non
Fonctions avancées À construire Déjà là

Les outils établis sont meilleurs sur un point précis et il serait malhonnête de le passer sous silence : leur écosystème d'intégrations. Connecter une messagerie, un outil de signature électronique et un logiciel de facturation prend quelques clics chez eux, et demande un travail réel chez vous.

L'avantage du CRM généré est ailleurs. Il colle à votre vocabulaire, il ne facture pas au siège, et vous pouvez exporter le code source le jour où vous voulez le confier à un développeur. Pour une structure de moins de dix personnes avec un processus atypique, cet arbitrage penche souvent du bon côté.

Où sont les limites d'un CRM généré ?

Trois, dites sans détour.

Zugo ne remplace pas une équipe de développement sur un produit complexe. Une logique métier très spécifique, par exemple un calcul de commission à paliers qui dépend de la date de signature et du produit vendu, s'obtient par modifications successives et non par un seul prompt. À partir d'un certain niveau de spécificité, exporter vers GitHub coûte moins cher que continuer par itérations.

La reprise de l'existant reste manuelle. Personne ne devine la structure de votre ancien tableur : vous préparez le fichier, vous alignez les colonnes sur les champs décidés au départ, vous importez. C'est une demi-journée de travail sur un fichier propre et davantage sur un fichier vieux de cinq ans.

La vérification en bac à sable confirme que l'application démarre avant de vous être livrée. Elle ne vérifie pas que vos statuts ont du sens, ni que le champ « montant » contient des montants. Cette relecture vous appartient, et c'est elle qui décide si l'outil sera utilisé ou abandonné en trois semaines.

Que faire de votre côté avant de lancer la construction ?

Trois tâches, dans cet ordre, et aucune ne demande d'ouvrir un outil.

Listez vos champs et vos statuts sur papier, en reprenant les mots que vous employez déjà. Comptez ensuite le nombre de fiches que vous gérez vraiment aujourd'hui : en dessous de cinquante, un CRM peut être plus simple que ce que vous imaginiez. Enfin, choisissez l'écran d'accueil, celui que vous ouvrirez tous les matins.

Lancez ensuite la première plateforme, saisissez cinq fiches réelles et utilisez l'outil pendant deux jours avant de demander la moindre modification. Les corrections qui viennent de l'usage sont utiles, celles qui viennent de la première impression coûtent 3 crédits pour rien.

Gardez votre ancien tableur en lecture seule pendant le premier mois, sans y saisir quoi que ce soit de nouveau. C'est le filet de sécurité qui vous permet de basculer sans stress, et c'est aussi la meilleure façon de vérifier que rien d'important n'a été oublié dans la liste des champs.

Vous pouvez commencer sur zugo.dev, poser vos champs, et voir à quoi ressemble votre processus une fois qu'il tient dans un écran plutôt que dans un tableur.

← Tous les articles