Cahier des charges: qu' est-ce qu'un client ? que propose le site ?

Dans beaucoup de cahiers des charges ou spécifications (voir “cahier des chagres comment faire” si le sujet vous intéresse) que nous recevons, 2 des problèmes récurrents est de savoir “qu’ est-ce qu’ un client ?” et “que propose le site ?”

Ces questions peuvent étonner certains ou plonger d’autres dans des interrogations sans fin sur nos capacités mentales  mais c’est pourtant des questions essentielles très rarement examinées comme il le faut.

Il y a tout d’abord le fait de décider QUI est le client pour l’aspect “business” et pour l’aspect “fonctionnalités” —> souvent des sites sont faits POUR les internautes mais les clients, au sens “business” du terme sont les annonceurs ou parfois même les investisseurs . Dans ce cas, la question de savoir vers QUI être orienté n’est pas si innocente que cela. Imaginez que vous sachiez, dans un domaine bien précis que l’audience augmente si vous mettez tel contenu mais que vos annonceurs ne veulent pas de ce contenu …. Il importe surtout que vous ayez la tête claire à ce sujet.

Ensuite, de manière très concrète pour la réalisation d’un système d’informations et donc d’un site Internet (ou extranet ou intranet) transactionnel, il est extrêmement important de définir ce qu’est un client, c’est à dire QUELLES SONT LES CARACTERISTIQUES de la chose “client” dans la base de données (modèle de données pour les spécialistes).

Les choix et options qui sont prises pour ceci, à un stade où personne n’a besoin d’avoir de connaissances techniques, ont une influence sur l’ensemble du site et du business.

Prenons pas un exemple le cas d’un site de e-commerce qui ne fait que vendre.

1) Le client est-il un particulier ou peut-il être aussi une société ?

11) Si le client est un particulier, quelles sont ses caractéristiques ?

– Prénom, nom, email, adresse, téléphone(s), adresse(s) de livraison , date de naissance, pseudo, mot de passe, etc … ??

– Quelle sera la caractéristique qui en fait qqch d’unique ? L’email ? Le pseudo ?

12) Si le client PEUT être une société, quelles sont ses caractéristiques ?

– login, pass, nom, rcs, code APE, etc… ?

– Est-ce que les diverses personnes de la société qui se connecteront auront les mêmes possibilités dans le système ?

– Quelles adresses prendra-t-on en compte ? adresse officielle ? adresse de livraison ? adresse de facturation ?

– Quels contacts “humains” prendra-t-on en compte ?

– Si un établissement de la société est client, et si un deuxième établissement devient ensuite client, le deuxième sera-t-il rattaché au premier ou chaque établissement sera traité comme client à part ? (et dans ce cas, si la société mère demande UNE seule facture commune, comment devra-t-on faire au niveau de la facturation ..)

2) Le client est-il seulement en France ou à l’étranger ?

en CE ou ailleurs ? —> pbs de TVA

3) Quelles autres caractéristiques va-t-on rattacher au CLIENT ?

par qui il a été recommandé ?

son historique ?

etc…

4) si le site vend à des sociétés et à des particuliers, quelqu’un de la société peut-il être client particulier avec le même mail  ou téléphone, etc..

Et nous ne sommes ici que dans un cas tout simple. l’affaire bien évidemment se complique quand le système à créer est un système d’échange ou co-existent des vendeurs, des acheteurs, des partenaires et d’autres systèmes à interfacer.

La question de savoir ce que propose le site est parfois plus difficile à résoudre.

Le site propose-t-il des “produits” ou des “services” ? La réponse à ces questions a des conséquences juridiques car les responsabilités ne sont pas les mêmes suivant qu’on propose un service ou des produits (ne serait-ce que dans les délais de rétractation).

On imagine aussi sans peine les différences juridiques entre Meetic proposant des rencontres entre membres et Meetic proposant juste le moyen de mettre en relation des gens qui s’abonnent pour bénéficier de ces possibilités

Ensuite, il existe des domaines où la TVA n’est pas la même suivant qu’on se pose en fournisseur de services et fournisseur de produits.

Enfin, les caractéristiques du système d’informations à créer ne seront pas les mêmes car l’”engagement” du site devra être géré différemment.

Si un site propose par exemple des livres, il n’aura pas les mêmes fonctionnalités de back-office qu’un site proposant l’achat et la livraison de livres vendus, au sens strict du terme par d’autres. —> les livres vendus par amazon ne suivent pas le même process que les livres vendus VIA amazon.

Notamment en France, ces différences sont à prendre en compte, suivant le domaine.

Autre exemple: dans un cas on devra gérer un stock et dans l’autre cas des disponibilités (éventuellement). Là aussi, les choses se font différemment.

Quand on fait appel à un prestataire extérieur, il est rare que ces questions aient déjà été posées. Le prestataire agit alors de 3 manières différentes.

• Soit il les pose (et il ennuie le client 4 fois sur 5 ce qui a pour conséquence que celui-ci va ailleurs )
• soit il intègre le coût de la réflexion sur ces sujets dans sa cotation (Avez-vous remarqué comme souvent, des commerciaux de SSII ou de web-agencies ou d’ “agences” sans aucune connaissance ni curiosité des choses à faire arrivent à vous faire des cotations en parlant uniquement de généralités comme php, jsp, .net, hébergement, web 2.0, etc..)
• soit il essaie d’imposer un modèle de données qu’il a déjà réalisé ou qui existe déjà sous forme de soft

Très souvent aussi, les demandes ultérieures de changement, causées par l’absence de réflexion sur ces sujets initialement, feront le beurre du prestataire