ORIGINE
Un projet, deux versions
Après huit ans comme Product Designer, je me forme au Product Building. Apprendre à livrer un produit, pas seulement à le maquetter. Concevoir et coder des écrans, je savais déjà faire.Le vrai gap était ailleurs. Structurer une base de données et automatiser des processus métier avec des outils tiers, hors du champ design, comme Airtable et Make.
Le Mini CRM pour artisans est mon premier vrai projet Product Builder. Un périmètre volontairement simple, un marché réel, faisable seul, pensé justement pour couvrir une app de bout en bout et pas seulement son interface.
Je l'ai construit une première fois en no-code (Airtable, Bubble, Make), la stack de base de ma formation. Une fois ce socle acquis, j'ai voulu tester une deuxième approche sur exactement le même problème.
Je l'ai reconstruit entièrement en code (Supabase, React, Cursor, Claude Code, Vercel, Make), pour comparer les deux méthodes en conditions réelles plutôt que sur la théorie.
Cette comparaison est le vrai sujet de cette page, le détail est dans la section Méthode.
Nom et identité visuelle
Le nom vient du compagnonnage artisan français. Quelqu'un qui reste à tes côtés, discret mais fiable, plutôt qu'un logiciel qu'on subit. Traduit en anglais pour rester court et facile à prononcer, ça donne Mate, le pote qui couvre tes arrières plutôt que le collègue de bureau.
Ce choix marque aussi une différence volontaire avec les CRM du marché (Salesforce, HubSpot), pensés pour des équipes commerciales.
Mate s'adresse à un artisan seul, pas à une organisation.
CONTEXTE
Pourquoi les artisans
Le secteur artisanal français est un marché massif et sous-équipé numériquement. Il représente 3,7 millions d'entreprises, 4,16 millions de salariés et 623 milliards d'euros de chiffre d'affaires (ISM/U2P, Insee).
Contrairement à une idée reçue, ce n'est pas un secteur technophobe. La majorité des artisans a aujourd'hui une présence en ligne. Le vrai problème est ailleurs. 65 % des TPE françaises utilisent encore des outils non adaptés pour gérer leur relation client (Capterra, 2024). Les CRM généralistes (Salesforce, HubSpot) sont pensés pour des équipes commerciales, pas pour un artisan solo qui gère sa quarantaine de clients depuis son atelier.
Problématique
Sans outil de suivi, un artisan perd du chiffre d'affaires sans s'en rendre compte. Un client qui n'a pas recommandé depuis plusieurs mois n'est jamais relancé, il part chez le concurrent. Une commande en cours sort des radars. Aucune visibilité sur qui rapporte le plus, ni sur quoi relancer en priorité.
Ce que le Mini CRM résout
- Fiche client (contact, historique, notes)
- Historique des commandes par client, avec statut (En cours / Livré / Payé)
- Relance automatique quand une facture livrée n'est pas payée (J+15 souple, J+30 ferme)
- Dashboard : chiffre d'affaires encaissé, commandes en attente, factures à relancer
RECHERCHE
Patterns UX de CRM existants
La majorité des CRM pousse le formulaire de création/édition dans une modal centrée.
Les recommandations UX récentes privilégient plutôt un panneau latéral (drawer) pour ce type d'action. L'utilisateur garde le contexte de la liste en arrière-plan, une modal centrée le lui fait perdre.
J'ai choisi un drawer sur desktop, et un bottom sheet sur mobile pour la même raison. Le drawer s'ouvre systématiquement du même côté que le bouton qui le déclenche, pour limiter le déplacement du curseur entre l'action et la saisie (loi de Fitts).
Accessibilité
Contraste minimum WCAG AA (4.5:1) sur tous les textes. Un statut n'est jamais porté par la seule couleur, toujours accompagné d'un libellé texte. Police Atkinson Hyperlegible, choisie spécifiquement pour sa lisibilité.
Desktop First
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 : une base, trois constructions
No-code : Airtable → Bubble → Make
En parallèle de ma formation, je construisais le CRM avec les outils du programme au fur et à mesure qu'ils étaient enseignés.
J'ai utilisé Airtable pour la base (une structure relationnelle Clients/Commandes, avec un champ Rollup pour le CA total par client et une formule de date pour repérer les clients inactifs), Bubble pour l'interface (CRUD complet, historique de commandes par client, dashboard, un webhook de relance déclenché manuellement), et Make pour l'automatisation.
Interface Airtable
Make reçoit le webhook envoyé par Bubble au clic sur "Envoyer la relance", récupère les informations du client et de la commande, puis déclenche l'envoi d'un email personnalisé via un module Gmail ou Outlook. C'est la brique qui referme la boucle du problème initial. Sans elle, la fiche client existe mais la relance reste manuelle, exactement ce que le projet devait éviter.
Tester chaque outil au fil de la formation, plutôt que de choisir une stack à l'avance, m'a permis de voir concrètement ce que chacun apportait au projet, plutôt que de le lire en théorie.
Interface Make pour le scénario de relance de mail
Le vrai frein n'a pas été la logique métier, c'est la construction d'écran elle-même.
Bubble assemble une interface avec des Groups, des Popups et des Repeating Groups reliés par des expressions du type Current cell's X.
Une gymnastique que Figma ne m'a jamais imposée.
En tant que designer habitué à composer librement, c'est cette rigidité-là qui a coûté le plus de temps, pas la donnée ni l'automatisation.
Interface Bubble
Un détour par Softr
Les lenteurs d'assemblage de Bubble m'ont poussé à tester Softr, découvert dans un autre programme de formation.
Softr se connecte directement à une base Airtable existante, sans duplication de schéma, et construit l'interface à partir de Blocks préfabriqués (liste, fiche détail, formulaire) avec une navigation enregistrement → fiche automatique.
Surprise ! Softr embarque aussi un moteur d'automatisation natif (Workflows), fonctionnellement équivalent à Make.
J'ai reconstruit la relance client sans jamais sortir de l'outil. Donnée, interface et automatisation au même endroit.
Interface de SoftR
Contre mon hypothèse de départ, il est possible d'y faire tout le projet. Mais Softr reste plus rigide visuellement que Bubble. On compose avec des blocs préfabriqués, pas avec des éléments bruts.
Un choix cohérent pour un outil interne ou un portail client à mettre en place vite, pas pour un produit qui doit se différencier visuellement. Pour ça, il fallait revenir au vrai code.
Reconstruire en AI-code
Cœur fonctionnel comparable : avec Cursor et Claude Code, la mise en place de la base (Supabase), de l'authentification et des écrans CRUD (Create, Read, Update, Delete) est allée à une vitesse proche de celle du no-code.
Pendant que le code se générait, je gardais une conversation ouverte avec Claude pour explorer la suite en parallèle, un mode de travail qu'aucun des outils no-code ne permet vraiment.
Le temps total, en revanche, a 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, déploiement." devient "Sécurité des données (Row Level Security), authentification, hébergement et déploiement (Vercel), avec un redéploiement automatique à chaque push GitHub.
À quoi s'ajoute une phase de direction artistique poussée, menée directement en prompts plutôt qu'en maquettes Figma, que je n'avais pas menée avec la même profondeur sur les versions no-code.
Make, lui, n'a pas été remplacé.
Le même scénario (webhook → email de relance) tourne toujours, simplement déclenché depuis la nouvelle application plutôt que depuis Bubble.
Passer au code n'a pas voulu dire tout reconstruire.
Seulement reprendre en main les briques qui avaient vraiment besoin de l'être (base de données, interface, sécurité).
DESIGN
Parcours de relance
Le diagramme ci-dessous montre la boucle complète : connexion, repérage d'une facture à relancer sur le Dashboard, clic sur "Envoyer la relance", déclenchement de l'email par Make, réception par le client, règlement, puis mise à jour automatique du statut, qui referme la boucle vers le Dashboard.
Le dernier maillon de cette boucle, c'est ce que le client reçoit réellement.
ÉCRANS CLÉS
Chaque écran a été retravaillé sur plusieurs rounds. Desktop, puis tablette, puis mobile, puis une passe de modernisation visuelle sur les ombres, les arrondis et la typographie.
Tableau de bord
Vue d'ensemble du chiffre d'affaires encaissé et des factures à relancer, avec accès direct à l'envoi d'une relance. Entre la première version et la version finale, la carte CA devient la métrique mise en avant plutôt qu'une carte parmi d'autres, et "livrées" devient "terminées" pour coller au vocabulaire d'un artisan.
Clients
Liste des clients de l'artisan, avec recherche et accès à la fiche de chacun en un clic.
Fiche client
Informations de contact et historique des commandes d'un client sur un seul écran, avec possibilité de changer le statut d'une commande ou d'en ajouter une nouvelle sans quitter la page.
Création commande
Ajout rapide d'une commande à la fiche client. Description, montant, statut initial.
Démonstration
Design system
Logo
Un mark géométrique minimal, dans l'esprit d'outils comme Cursor, mais pas une lettre ni un monogramme.
Le symbole fonctionne dans deux états. Seul, en icône réduite quand le menu latéral est replié, et associé au nom quand le menu est déplié (icône + "Mate" en toutes lettres).
