WineDataSystem choisit de stocker le catalogue des vins français dans des graphes

Objectif n°1 : concevoir un PIM adapté aux spécificités de l'industrie du vin

Les premières années vont voir la start-up réaliser des développements en fonction des besoins de chacun de ses clients. "Mon associé, directeur technique de WineDataSystem, était un spécialiste des technologies Microsoft", explique Aymeric Fournier. "Nous avons commencé à développer en ASP, mais comme certains de nos clients n'étaient pas sous Windows, nous avons été amenés à développer des outils sous d'autres langages." Après être passé par la case PHP/MySQL, la start-up fait le choix Windev et PostgreSQL pour réaliser ses développements. "Nous avons développé en Windev pour un courtier en vin qui souhaitait un produit spécifique mais nous avons très rapidement trouvé les limites de l'outil, car nous voulions créer des interfaces Web avancées."

En 2014, la start-up se lance dans une unification de ses outils autour du progiciel de gestion OpenERP. "Nous avons notamment pensé à un logiciel de PIM existant, Akeneo, mais nous avons préféré développer nous-mêmes notre PIM." Un membre de l'équipe informatique propose alors d'utiliser non plus une base SQL, mais une base de données de graphes. "En un week-end, il a monté un pilote avec Neo4j plutôt intéressant. Il était parvenu à recréer un des traitements importants pour WineDataSystem : le dédoublonnage des fichiers.  C'était la preuve que c'était une solution qui allait nous permettre d'aller vite, être performants et surtout évolutifs."

Le projet Neo4j a été lancé voici un an et demie et, après avoir monté un prototype qui s'est avéré probant, le projet de migration des développements Windev sur Neo4J est lancé. L'outil développé en interne est intégré à OpenERP et il se présente comme une surcouche à l'ERP Open Source. "Nous générons les devis, les factures avec OpenERP mais tout ce qui vient en amont comme charger et rechercher les tarifs est réalisé sur Neo4J. C'est quelque chose qu'utilisent les courtiers en vins."

La base de données de graphes simplifie les recherches d'information

L'un des problèmes auquel doit faire face la start-up, c'est devoir retrouver rapidement un vin en base de données alors que multiples orthographes son possibles. "Château Latour" qui devient "Chat. Latour », sans compter les erreurs qui ne sont pas rares avec les petites appellations bien moins connues. Sur ce plan, les commerciaux en vin et les négociants font bien peu d'efforts de normalisation.

Un très grand cru comme Château Angélus est une appellation St Emilion grand cru et non pas une appellation St Emilion. Ce genre de négligence peut poser des problèmes en après-vente. "Nous devions coder des requêtes SQL extrêmement complexes pour aboutir à quelques résultats seulement. Dès que nous ajoutions des champs dans telle ou telle table, il fallait revoir notre copie et réécrire la requête. J'ai été séduit par cette possibilité qu'offrent les graphes : pouvoir ajouter des champs librement sans avoir à revoir les requêtes, parcourir le graphe librement pour retrouver l'information."

Un atout : Un modèle de donnée qui peut être étendu simplement

Autre contrainte, la diversité des types de données réclamés par les courtiers. Un négociant qui cherche un "Château Angélus" sur la place de Bordeaux va faire une recherche sur les tarifs intégrés par les négociants sur la plateforme. La requête est simple : Trouver un Château Angélus millésime 2009 à moins de 300 euros et disponible en plus de 1 200 bouteilles. Le type de requête facile à coder en SQL.

Parfois, la recherche va beaucoup plus loin car le négociant peut demander un vin qui a eu une bonne note d'un critique, un vin qu'il est autorisé à proposer à la grande distribution aux Etats-Unis. Il faut alors aller chercher l'information dans une "white list", tenir compte du régime douanier des vins, etc. "Ce sont toutes ces subtilités qui rendent les modèles de données très complexes. Tous nos clients sont sur le même référentiel, mais chacun a une manière de représenter l'information qui lui est propre. Plutôt que de faire passer tout le monde sous les fourches caudines d'un même modèle de données, le référentiel des vins est commun et chaque client peut charger des données spécifiques répondant à son besoin." Passer du modèle relationnel aux graphes impose une montée en compétence

Le choix de la base de données Neo4j a tout d'abord suscité un vif intérêt de la part des développeurs."Après une phase d'euphorie, nous sommes passés à une phase d'optimisation. Nous nous sommes alors rendu compte par la suite que le modèle de données initial n'était pas toujours très adapté à certains des usages de notre base de données. Il aurait été possible de faire beaucoup mieux que ce que nous avons fait au départ." Ainsi, dans un premier temps les développeurs n'ont pas typé les relations entre objets. Ce n'est que plus tard que l'équipe projet a réalisé que des informations pouvaient être placées directement sur les relations. Une possibilité qui aurait pu simplifier grandement certains traitements. "C'est une logique un peu différente et sur laquelle nous sommes toujours en apprentissage."

Actuellement 50 000 références produits sont stockées dans le référentiel WineDataSystem, soit environ 300 000 nœuds de données. Chaque fichier chargé par un courtier représente 1 500 lignes en moyenne. Une vingtaine de clients de la start-up sont connectés à l'outil dont 3 qui l'utilisent intensivement.

Auparavant hébergée sur des serveurs dédiés chez Online, toute l'infrastructure a été basculée dans le Cloud voici un mois. Elle est aujourd'hui hébergée par AWS. Pour le fondateur de WineDataSystem, "la migration Neo4j a été un non événement. Sur Neo4j, déplacer une base de données, c'est du copier/coller" .