ÉTUDE DE CAS · PRODUCT BUILDING · Juillet. 2026
Mate
Un mini CRM pour artisans, construit deux fois : en no-code, puis en code. Même problème, deux méthodes, pour savoir ce que chacune coûte vraiment.
Rôle :
Conception, design et build, en solo
Device :
desktop first, puis tablette et mobile
Stack :
Airtable, Bubble, Softr, Make, puis Supabase, React, Claude Code, Vercel
Durée :
4 jours en no-code, 2 en code
En bref
PROBLÈME :
un artisan seul perd du chiffre d’affaires faute de relancer ses clients et ses factures impayées.
RÉPONSE :
un CRM minimal (fiches clients, commandes, relance automatique à J+15 puis J+30) et un tableau de bord centré sur l’argent encaissé.
LE VRAI SUJET :
comparer le no-code et le code sur exactement le même produit.
VERDICT :
écrans aussi rapides à produire dans les deux cas. Le code coûte plus cher, mais donne la main sur la sécurité, la robustesse et le déploiement.
Sommaire
Origine
Un projet, deux versions
Après huit ans comme Product Designer, je me forme au Product Building : livrer un produit, pas seulement le maquetter. Concevoir des écrans, je savais faire. Mon vrai manque était ailleurs : structurer une base de données et automatiser des processus métier.
Le mini CRM pour artisans est mon premier projet de bout en bout. Un périmètre simple, un marché réel, faisable seul.
Je l'ai construit une première fois en no-code (Airtable, Bubble, Make), la stack de ma formation. Puis je l'ai reconstruit entièrement en code (Supabase, React, Claude Code, Vercel), pour comparer les deux méthodes sur un cas réel plutôt qu'en théorie. Cette comparaison est le vrai sujet de cette page.
Nom et identité visuelle
Le nom vient du compagnonnage artisan. Quelqu'un qui reste à tes côtés, discret mais fiable. En anglais pour rester court, Mate, le pote qui couvre tes arrières. C'est aussi une prise de distance avec Salesforce ou HubSpot, pensés pour des équipes commerciales. Mate s'adresse à un artisan seul.
Contexte
Pourquoi les artisans
L'artisanat français pèse 3,7 millions d'entreprises et 623 milliards d'euros de chiffre d'affaires (ISM / U2P, Insee). Ce n'est pas un secteur technophobe : la plupart des artisans sont présents en ligne. Mais 65 % des TPE gèrent encore leur relation client avec des outils inadaptés (Capterra, 2024).
Problématique
Sans suivi, un artisan perd de l'argent sans le voir. Un client qui n'a pas recommandé depuis des mois n'est jamais relancé. Une commande sort des radars. Aucune idée de qui rapporte le plus, ni de quoi relancer en priorité.
Ce que Mate résout
- Une fiche client : contact, historique, notes.
- Les commandes par client, avec un statut (En cours, Terminée, Payée).
- Une relance automatique quand une facture n'est pas payée : J+15 en ton souple, J+30 en ton ferme.
- Un tableau de bord : chiffre d'affaires encaissé, commandes en attente, factures à relancer.
Recherche
Recherche documentaire : analyse du marché de l'artisanat (données ISM / U2P, Insee et Capterra), étude des patterns d'interface des CRM existants et principes d'accessibilité.
Pas d'entretiens avec des artisans sur ce projet. Les choix s'appuient sur ces sources et sur le contexte d'usage.
Drawer plutôt que modal
La plupart des CRM ouvrent leurs formulaires dans une fenêtre centrée. J'ai choisi un panneau latéral sur desktop et un panneau bas sur mobile : l'utilisateur garde la liste sous les yeux. Le panneau s'ouvre du côté du bouton qui le déclenche, pour limiter le trajet de la souris (loi de Fitts).
Accessibilité
Contraste AA sur tous les textes. Un statut n'est jamais porté par la couleur seule, toujours par un libellé. Police Atkinson Hyperlegible, conçue pour la lisibilité.
Desktop d'abord
Contrairement au réflexe "mobile-first" par défaut, j'ai priorisé le desktop. La prise de commande d'un artisan se fait plus souvent au bureau ou à l'atelier qu'en déplacement. Le contexte d'usage réel a pris le dessus sur la convention.
Méthode
No-code : Airtable, Bubble, Make
J'ai construit le CRM avec les outils de ma formation, au fur et à mesure qu'ils étaient enseignés.
- Airtable pour la base : clients et commandes reliés, un champ Rollup pour le CA par client, une formule de date pour repérer les clients inactifs.
- Bubble pour l'interface : création et édition, historique par client, tableau de bord, bouton de relance.
- Make pour l'automatisation : au clic sur « Envoyer la relance », Make récupère le client et la commande et envoie un email personnalisé. C'est la brique qui ferme la boucle.
La base Airtable
L'interface dans Bubble
Le scénario Make de relance
Le vrai frein n'a pas été la logique métier, mais la construction des écrans. Bubble assemble l'interface avec des Groups, des Popups et des Repeating Groups reliés par des expressions. Pour un designer habitué à composer librement dans Figma, c'est cette rigidité qui a coûté le plus de temps.
Un détour par Softr
La lenteur de Bubble m'a poussé à tester Softr. Il se branche directement sur la base Airtable et construit l'interface à partir de blocs tout faits (liste, fiche, formulaire). Surprise : il embarque aussi ses propres automatisations. J'y ai refait la relance sans sortir de l'outil.
Contre mon hypothèse, on peut y faire tout le projet. Mais on compose avec des blocs, pas avec des éléments libres. Bien pour un outil interne à livrer vite, pas pour un produit qui doit se différencier.
Reconstruire en code
Avec Claude Code, la base Supabase, la connexion et les écrans de gestion sont venus presque aussi vite qu'en no-code. Pendant que le code se générait, je gardais une conversation Claude ouverte pour préparer la suite, ce qu'aucun outil no-code ne permet vraiment.
Le temps total a pourtant largement dépassé les quatre jours du no-code. La différence ne vient pas de la vitesse de génération, mais de tout ce que le no-code gère nativement et que le code oblige à construire soi-même : sécurité des données (Row Level Security), authentification, hébergement et déploiement (Vercel), avec une mise en ligne automatique à chaque envoi sur GitHub.
S'y ajoute une direction artistique plus poussée, menée directement en prompts plutôt qu'en maquettes sur Figma.
Make, lui, est resté : le même scénario de relance tourne toujours, déclenché depuis la nouvelle app. Passer au code n'a pas voulu dire tout reconstruire, seulement les briques qui en avaient besoin.
Le bilan en tableau
| Airtable + Bubble + Make | Softr | Code (Supabase, React, Claude Code) | |
|---|---|---|---|
| Durée | 4 jours | 1 jour | 2 jours |
| Interface | Rigide pour un designer (Groups, Repeating Groups) | Blocs tout faits, rapide mais peu différenciant | Liberté totale, direction artistique poussée |
| Sécurité, déploiement | Gérés par l’outil | Gérés par l’outil | À construire : Row Level Security, connexion, Vercel |
| Automatisation | Make, déclenché depuis Bubble | Automatisations intégrées | Make conservé, déclenché depuis l’app |
| Quand le choisir | Apprendre les briques une par une | Outil interne à livrer vite | Produit qui doit se différencier et tenir en production |
Design
Le parcours de relance
La boucle complète :
repérer une facture à relancer sur le tableau de bord, cliquer sur « Envoyer la relance », Make envoie l'email, le client paie, le statut se met à jour et revient au tableau de bord.
Le dernier maillon : ce que le client reçoit.
Écrans clés
Chaque écran a été retravaillé en plusieurs passes : desktop, tablette, mobile, puis une finition sur les ombres, les arrondis et la typographie.
Tableau de bord
Entre la première et la dernière version, le chiffre d'affaires devient la métrique mise en avant, et "livrées" devient "terminées", le mot d'un artisan.
Liste des clients, avec recherche et accès en un clic à chaque fiche.
Contact et historique sur un seul écran. On change un statut ou on ajoute une commande sans quitter la page.
Nouvelle commande en trois champs : description, montant, statut.
Démonstration
Design system
Logo
Un symbole géométrique simple, ni lettre ni monogramme. Il fonctionne seul quand le menu latéral est replié, et avec le nom « Mate » quand il est déplié.
Conclusion
Ce que ce projet m'a appris
- Mes bases SQL m'ont servi à valider, pas à suivre. L'IA m'a surtout aidé là où je ne savais pas encore faire (règles de sécurité Postgres, fonctions protégées). Sur le reste, je relisais et je validais.
- Les choix produit sont restés les miens. Panneau latéral ou fenêtre centrée, desktop d'abord, délai de relance : l'IA proposait des chemins, je tranchais.
- Coder n'accélère pas la production d'écrans. Les bons outils no-code vont aussi vite. L'intérêt est ailleurs : garder la main sur la sécurité, la robustesse et le déploiement.
Là où j'ai dû intervenir
- Sécurité : une fonction Postgres exposée sans restriction, signalée par l'audit Supabase, corrigée en retirant les droits d'exécution par défaut.
- Automatisation silencieuse : le webhook de relance marchait en test, jamais en réel. Cause : un réglage caché de Make (« Immediately as data arrives ») désactivé par défaut, sans message d'erreur.
- Mise en page : sur la fiche client, les boutons d'action étaient coupés à certaines largeurs. Résolu en repensant les boutons (icônes plutôt que texte), pas en changeant un seuil.
- Diagnostiquer avant de corriger : sur un bug d'affichage iOS Safari, plusieurs pistes ne menaient nulle part. J'ai fait diagnostiquer avant de faire corriger, plutôt que laisser l'IA tenter des correctifs à l'aveugle.
Et ensuite
- Plusieurs artisans : la sécurité par propriétaire est déjà en place. Il reste l'inscription et un onboarding.
- Relance par SMS : prévue au départ (Twilio), utile pour les artisans qui lisent peu leurs emails sur le terrain.
- Facturation électronique : hors périmètre tant que les clients sont des particuliers, obligatoire si Mate s'ouvre aux professionnels.
- Logo de l'artisan : pour que Mate reflète son entreprise.
- Prestations prédéfinies : une liste déroulante à la place de la description libre, pour aller plus vite et harmoniser les relances.