Ne pas confondre Client et Utilisateur

Hervé Rincent

Hervé Rincent

1 juin 2021

Client ou utilisateur.

Quelle différence ?

Tout les sépare !

Voici la définition pragmatique qu'en donne Seth Godin :

Customers hear you say, "here, I made this," and they buy or they don't buy. Clients say to you, "I need this," and if you want to get paid, you make it. The key distinction is who goes first, who gets to decide when it's done.

(oui, j'ai traduit "Customer" en "Utilisateur" que je trouvais mieux que "consommateur").

Résumons :

A un client, on dit souvent OUI. Mais on dit souvent NON à des utilisateurs car l'objectif est de conserver un produit standardisé.

A des utilisateurs, on vend beaucoup de fois la même chose. C'est "scalable". Le 2751ème utilisateur aura le même logiciel que tous les autres. On compte sur une logique de volume pour faire fortune grâce à une croissance exponentielle.

Alors que les clients ont des attentes spécifiques qui appellent des services sur-mesure. Difficile de dupliquer ou de mutualiser. La croissance est linéaire : pour augmenter son revenu, il faut embaucher.

Les utilisateurs vivent en Extrêmistan. Les clients habitent en Médiocristan. Si vous ne connaissez pas ces pays, jetez un oeil ici.

Le choix du bon niveau d'abstraction

On ne code pas le logiciel d'un utilisateur comme celui d'un client.

Qu'est-ce qui change ?

Le niveau d'abstraction.

Prenons l'exemple de Notion.so. C'est un outil en SaaS qui fait office de bloc-note, de Word et d'Excel, bref un truc un peu à tout faire.

D'ailleurs, je suis en train d'écrire cet article dans une page Notion. Je suis un utilisateur de Notion.

C'est l'illustration parfaite d'un produit à la croissance fulgurante. Il permet de faire pleins de choses avec un abonnement de quelques euros par mois. Je m'en sers pour tout : gérer mes projets, ma comptabilité, mon temps, mon planning, ma base de connaissance, ....

Et bien Notion n'est pas codé avec des entités très spécifiques, mais avec des blocs. Des sortes de briques de Légo.

Dans le code, on reste volontairement évasif sur ce qu'est un bloc : il possède un id, un type, des propriétés, un contenu. D'ailleurs, si on change le type ( to-do en texte par exemple), on conserve la propriété "checked" même si elle ne sert plus à rien. J'entends d'ici des puristes qui hurlent au fond de la salle.

Car la question n'est pas de savoir s'il faut créer des objets "pages" ou "ligne de tableau".

La priorité est de proposer une façon de manipuler des données suffisamment intuitive pour que chacun y trouve son compte immédiatement.

Comme au bar, c'est l'ambiance qui compte. L'expérience utilisateur. Le sentiment immédiat de réussir à faire un truc que l'on n'arrivait pas à faire facilement avant.

Notion, c'est l'exemple parfait d'un produit pensé pour des utilisateurs.

En quoi est-ce différent d'un outil conçu pour des clients ?

Des entités parlantes pour les clients

Lorsqu'une entreprise qui vend des machines à café vous demande de développer un CRM, le modèle des données sera probablement très différent de celui de Notion.

Dans le code, ça va parler d'entreprises, de contacts, de comptes clients, et de ... machines à cafés.

Contrairement aux utilisateurs, les clients veulent un logiciel qui reflètent leur métier, leur organisation.

Bien sûr, le développeur va conserver un certain degré d'abstraction mais avec un objectif différent : celui de permettre l'ajout de fonctionnalités plutôt que l'ajout d'utilisateurs.

Pour les clients, les entités manipulées par le logiciel seront teintées de règles métier. Par exemple : "à partir d'un objectif, un responsable commercial peut créer un plan d'actions, dont il affecte chaque élément aux membres de son équipe".

Le multi-tenant

Parfois, on code un service pour des clients, mais on veut le proposer ensuite comme un produit pour des utilisateurs.

On y va progressivement. En mode "Lean startup".

Voilà une démarche faussement simple.

On se dit qu'il suffira de répliquer des instances. On clonera le projet d'une entreprise vers une autre entreprise.

C'est l'illusion de scalabilité. Elle semble réelle car on a le même code pour tout le monde. Mais en pratique:

Lorsqu'on développe un produit pour des utilisateurs, il est probable de devoir adopter dès le début une architecture logicielle "multi-tenant" :

Principe d'architecture logicielle permettant à un logiciel de servir plusieurs organisations ("tenant" en anglais, ou "locataire" en français) à partir d'une seule installation. Elle s'oppose à une architecture multi-instance où chaque organisation a sa propre instance d'installation logicielle (et/ou matérielle)

La transition client → utilisateur se traduit souvent par une transition multi-instances → multi-tenant compliquée à réaliser. On doit modifier le modèle des données pour y injecter la notion "d'organisation" ou "d'entreprise".

Sinon, on peut automatiser le gréement d'une nouvelle instance. Une belle cohorte d'autres défis techniques vous attendent. Et on n'échappera pas au développement d'une forme de "superviseur" des instances.

Alors ? Votre projet est-il destiné à des utilisateurs ou à des clients ?

Références :


Continuer la lecture

Débranchez la prise

8 juin 2021

4 min read

Débranchez la prise

Lire l'article
Vectorisez

25 mai 2021

5 min read

Vectorisez

Lire l'article
Inscription à la newsletter

Recevez chaque semaine un article pour réfléchir à votre prochain projet tech/data

gratuit, sans spam, désinscription en 1 clic

Merci ! Regardez dans botre boite mail. Un lien de confirmation n'attend plus que votre clic.
Arghh il semble compliqué de vous ajouter à la liste de diffusion. Et si vous m'envoyiez un mail directement à contact@camilab.co ?