Archives par mot-clé : Analyse

Généraliser ? Oui, mais pas trop !

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, …
Avantage de l’approche : généraliser permet (doit permettre…) de construire un système plus évolutif, apportant plus de pérennité.
Mais cette approche est a des limites. On ne doit pas généraliser n’importe quoi.
Certains éléments, généralisés à mauvais escient, vont pousser dans la mauvaise direction, soit en contraignant à prendre des solutions bien plus chères, ou vont induire des choix d’architecture qui ne seront pas en phase avec les réels besoins de l’entreprise. Au bout du compte, cela peut coûter bien plus cher sans apporter aucun gain.
Alors, on fait quoi ?
Je n’ai pas de réponse « industrielle » à cette question !

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é ;).

Programmation graphique ?

Cela fait des années qu’on oppose programmation graphique à programmation textuelle.

A mon sens, c’est le même sujet, quand il s’agit de programmation ou d’analyse.

On peut faire de l’analyse avec des textes clairs, ou avec de joli schémas.

Donc, est-ce une bonne idée de faire de jolis dessins ?

Les dessins permettent-ils de complètement définir un sujet, plus facilement qu’avec du texte ?

Certains le pensent, comme ces solutions UML, qui promettent « la fin de la programmation » : Vous faites les différents schémas, et hop, un générateur de code va tout générer, et c’est fini.

Je dois dire que je ne suis pas en phase avec cette approche… Je n’y crois pas, et je pense que, quand on rentre dans les détails, les schémas finissent par être trop complexes.

Cela n’empêche pas que, pour moi, certains schémas sont très bien pour clarifier les échanges.

J’utilise principalement deux diagrammes UML : le diagramme de classe et les scénarios.

Le diagramme de classe est une bonne façon pour montrer la structure des données. C’est un modèle bien plus intuitif qu’un schéma relationnel.

Sa limite est qu’il intègre des données très différentes : l’héritage est une notion associée aux classes (ce sont les classes qui héritent les une des autres) alors que les liens sont en fait des liens entre les objets. Mais c’est pas grâve, on s’en sort très bien ;). Pour ma part, quand je peux, je sépare les schémas d’héritage des liens entre les objets.

L’autre schéma, les scénarios d’usages, permet de montrer un « exemple d’échanges » entre plusieurs objets.

C’est un schéma sympa, qui permet de comprendre la dynamique entre plusieurs objets.

Sa limite est de ne montrer qu’une option, parmi un ensemble de possible beaucoup plus vaste.

En particulier, il ne faut surtout pas utiliser de tels schémas pour les cas d’erreurs.

Sinon, je trouve qu’on fait de belles analyses avec… word.

Après pas mal d’années d’expérience, je trouve que le plus efficace, pour décrire un sujet, c’est de décrire, avec du texte donc, les différents cas.

Pour simplifier ces textes, je rajoute, en entête du « cas », un ensemble d’hypothèses.

C’est une manière, un peu artificielle, de simplifier le traitement d’un cas donné.

Exemple pour le e-commerce : processsus achat.

Et bien avec ma méthode, au lieu d’avoir un seul flux d’analyse, je découpe, en prenant les différentes hypothèses :

  • Compte existant et déjà identifié
  • Compte existant et non identifié
  • Nouveau client

L’énorme avantage est que cela permet de simplifier énormément la lecture de chaque cas.

Autre point : j’ai pris l’habitude, quand c’est possible, de séparer l’analyse « normale » de l’analyse des cas d’erreurs.

Là aussi, c’est un peu artificiel, mais ça permet de « séparer les variables » : on commence par s’intéresser au cas « normal », puis on s’intéresse aux cas « limites ».