Une bonne partie de mon activité consiste à concevoir, ou aider à concevoir, un système d’information e-commerce.
Pour faire ça, il faut une bonne culture sur ce qu’est un système d’information (ce qui va bien au delà du site Web), connaître les solutions du marché (en tout cas, faire une veille permanente pour en savoir le plus possible), et enfin, et surtout, écouter le client, pour comprendre en détail le besoin.
De mon expérience, qui commence à être bien solide, ce travail demande de comprendre, d’analyser, et de retranscrire ce besoin, dans un doc.
Mais il ne s’agit pas de retranscrire tel quel (sinon, la valeur ajoutée est nulle).
Première chose, quand on conduit l’interview, on doit creuser certains points, valider certaines hypothèses.
On peut aussi, en fonction de la capacité d’écoute de l’interlocuteur, essayer d’infléchir, ou tout au moins « challenger » certains éléments, que l’on sait particulièrement complexes, ou non pertinent.
Enfin, et c’est le sujet de cet article, on doit extrapoler, généraliser la demande du client.
A ce sujet, j’avais rencontré le CTO de Radio France, il y a quelques années.
Il m’avait raconté comment cette faculté de généralisation lui avait juste sauvé la vie : on lui avait demandé la mise en place d’un nouveau système avec des contraintes précises sur les horaires. Il avait pris l’initiative de généraliser la demande, pour traiter plus de cas de figures, sans rien demander à personne. La veille de la mise en exploitation du nouveau système, on lui annonce un changement, qui justement était parfaitement pris en charge par son système !
Bon, mais dans notre monde du e-commerce, cela veut dire quoi généraliser ?
Je vous propose de prendre quelques exemples :
- On vous demande de pouvoir créer deux espaces de vente, orienté marketing (genre Nouveautés et Soldes). La généralisation va consister à dire qu’on peut gérer N espaces de ventes.
- On vous demande qu’un produit puisse être simultanément dans deux catégories du catalogue. Généralisation : un produit peut être dans un nombre quelconque de catégories.
- On vous demande une barre de menus, avec des couleurs associées à chaque menu. Généralisation : on peut ajouter facilement des menus, et changer la couleur avec un seul paramètre.
- On vous présente une page d’accueil, découpée avec des blocs. Généralisation : définir une grille, administrable, qui permettra facilement de faire évoluer la home page (exemple réel, en ligne…)
- Je pourrais multiplier les exemples, sur tous les sujets : CRM, logistique, transporteurs, …
Je pense que c’est la « clé du succès », ce réglage fin, entre ce qui doit être généralisé, et ce qui ne doit pas l’être.
Ce réglage se fait par analyse, synthèse, prenant en compte de très nombreux facteurs : ce que font les solutions du marché, une intuition des réels besoins de l’entreprise, une évaluation sur le coût réel de la mise en oeuvre de la généralisation, …
J’insiste : certaines généralisations se retournent et deviennent des handicapes. Je vais pas balancer, mais je connais des solutions, qui ont été construites avec une volonté évidente de « généricité » et qui sont en fait très complexes à faire évoluer.
Donc, en synthèse : oui, il est fondamental de « prendre de la hauteur » , et de chercher à généraliser, pour construire un système qui sera opérationnel plus longtemps. Il faut juste faire ça avec doigté ;).
D’experience, il est intéressant de généraliser des fonctionnalités, et pour cause on a une dB, qui, si elle et bien conçue, permet de le faire (sinon il y a un problème dans son architecture). Cela ouvre de nouvelles perseptives. Ce que l on généralise très difficilement ce sont des process, parcequ ils en sont tout le contraire, et gerent un cas particulier (en général l’humain). La frontière c’est ce qui rentre dans une équation ou une matrice, et ce qui n’y rentre pas…