Pourquoi nous posons des questions avant de construire des outils par métier
Un garage et un grossiste en tissu n’ont pas les mêmes besoins. Plutôt que de deviner, nous préférons demander — et dire clairement ce qui n’existe pas encore.
Par L’équipe Centrall3603 min de lecture
Centrall360 repose sur une base commune : les conversations, les clients, l’équipe, le catalogue, la page publique. Cette base est la même pour tout le monde, et c’est volontaire.
Au-dessus, les métiers divergent franchement. Un garage reçoit un véhicule, établit un diagnostic, propose un devis, attend un accord, travaille, puis restitue. Un grossiste reçoit une demande de quantité, applique un prix selon le volume, prépare, puis livre. Ce ne sont pas deux variantes du même processus. Ce sont deux processus différents.
Le piège que nous voulons éviter
Le piège serait de forcer les deux dans un même flux « universel ». Le mécanicien devrait alors enregistrer la voiture d’un client comme un « produit » et appeler une réparation une « commande ». Cela fonctionne sur un schéma et échoue dès le premier usage réel.
L’autre piège, symétrique, serait de construire une application différente par métier. On dupliquerait alors les parties les plus délicates — la sécurité des données, la séparation entre entreprises, le consentement — c’est-à-dire précisément celles qu’il ne faut jamais dupliquer.
Ce que nous faisons à la place
Une base commune, et des modules par métier qui ne se construisent qu’une fois qu’on a compris le métier. Pas une fois qu’on a imaginé le métier depuis un bureau.
- Nous rencontrons des entreprises réelles et nous leur demandons de raconter leur dernière demande client, en détail, dans l’ordre.
- Nous nous intéressons surtout à ce qui s’est mal passé la dernière fois, parce que c’est là que se trouve le vrai coût.
- Nous regardons ce qui est déjà utilisé — le cahier, l’album photo, la liste — parce qu’un contournement existant prouve qu’un problème vaut l’effort.
- Nous demandons ce que les gens seraient prêts à payer, en sachant qu’une réponse donnée à voix haute vaut moins qu’un paiement réel.
Le périmètre décrit lors de la publication, le 28 août 2026
Nous préférons annoncer ce qui manque plutôt que de laisser croire. Lors de la publication, le 28 août 2026, nous indiquions que les modules suivants n’étaient pas encore construits : le suivi de réparations et la réception d’appareils ou de véhicules, les commandes et la livraison, la gestion de stock, les rendez-vous, et l’encaissement des paiements de vos clients.
Le périmètre présenté à cette date dans les espaces autorisés : les fiches clients, le catalogue, la page publique et l’historique d’activité. Les conversations WhatsApp réelles nécessitent un canal compatible connecté et vérifié ; le Lab les présente avec des données simulées.
Ce que nous ne ferons pas
Nous ne publierons pas de témoignages inventés, de nombre de clients invérifiable ou de promesse de résultat. Si nous écrivons un jour qu’un outil fait gagner du temps à une entreprise, ce sera parce que cette entreprise nous l’aura dit et aura accepté que nous le citions.
Commentaires
La discussion est ouverte à tout le monde, sans compte et sans nom : chaque commentaire est publié sous « Anonyme ».
Aucun commentaire publié pour le moment. Le vôtre peut être le premier.
Laisser un commentaire
Aucun compte, aucune adresse e-mail et aucun nom ne sont demandés. Les commentaires abusifs, illégaux ou hors sujet peuvent être retirés à tout moment.