Un modèle de données flexible servant de base au système PIM vaut son pesant d'or

Cela vaut la peine de regarder au-delà des apparences

Les systèmes d’information reposent nécessairement sur une base de données. Il en va naturellement de même pour le Product Information Management (PIM). On dit généralement que les bases de données ont une « durée de vie » au moins trois fois plus longue que le logiciel lui-même, c’est-à-dire l’interface et les programmes. La base de données est le fondement, le moteur ; les modifications importantes sont – si tant est qu’elles soient techniquement possibles – très complexes à mettre en œuvre. Il en résulte, pour l’éditeur de logiciels, qu’il convient de développer la base de données avec le plus grand soin, et pour l’utilisateur, qu’il vaut la peine de jeter un œil sous la surface. Au cours de ma carrière, j’ai constaté à plusieurs reprises que des éditeurs de logiciels avaient dû abandonner leur projet, notamment parce qu’ils n’avaient pas conçu leur base de données de manière optimale et que la migration entraînait des efforts considérables.

Le « responsable de la base de données »

Je dois avouer que la première fois que j’ai été confronté aux modèles de données dans la pratique, cela m’a paru fastidieux. En tant que jeune développeur, je voulais créer rapidement une superbe interface dotée de nombreuses fonctionnalités, mais j’ai d’abord été freiné par l’administrateur de la base de données. Je « devais » passer en revue toutes les structures de données avec lui, champ par champ, et bien sûr, il y avait une multitude de questions sur le pourquoi et le comment. Le résultat était représenté graphiquement (« diagramme entité-relation ») et je devais ensuite attendre que le modèle de données soit implémenté dans la base de données et déployé.

Au fil du projet, j’ai alors compris à quel point cette approche était judicieuse : tous les autres développeurs disposaient ainsi d’un modèle prédéfini et robuste et pouvaient utiliser les données de manière uniforme, sans qu’il soit nécessaire de passer par d’autres itérations.

J’en ai tiré deux enseignements :

1.) Il est indispensable d’avoir un « responsable » central pour la base de données ; j’ai fini par me rallier à cette idée.

2.) Il faut éviter la création fastidieuse des champs, c’est un aspect que je souhaitais améliorer et rendre plus flexible.

Le modèle de données flexible

Que signifie « modèle de données flexible » ?

La flexibilité signifie avant tout que l'utilisateur peut effectuer des extensions de manière autonome. En d'autres termes, sans l'intervention du « responsable de la base de données ». Il faut donc une sorte de « modèle de métadonnées » permettant d'étendre les champs (« attributs »), les structures (« tables ») et les liens (« relations ») :

• Les champs stockent du contenu.
  Dans le contexte du PIM, par exemple, des textes et des traductions, des caractéristiques (par exemple des chiffres), des images, des documents et des vidéos. Les extensions typiques consistent à ajouter un nouvel attribut, une nouvelle catégorie de texte ou une nouvelle catégorie d'image. L’utilisateur doit pouvoir effectuer ces opérations de manière autonome et simple. Et ce, sans aucune limite quant au nombre de nouveaux champs. Dès qu’un nouveau champ est créé, il doit être immédiatement visible partout : dans la maintenance des données, dans les interfaces, dans la production print et dans toutes les formes de mise à disposition des données. J’avais d’ailleurs esquissé l’idée de base de ce modèle d’attributs flexible avec un ami au bar, puis je l’avais testée dans Access (ça a très bien fonctionné :-).
• Les structures sont généralement représentées sous forme d’arborescence. Il va sans dire qu’elles doivent être facilement extensibles et personnalisables (sans restriction) en fonction des contenus. Dans le contexte du PIM, il s’agit impérativement de la structure de gestion des produits ainsi que des structures de sortie pour le site web, la boutique, les portails et les supports imprimés. Cependant, d’autres structures plus complexes peuvent également compléter utilement le PIM, par exemple une structure de configuration servant de base aux configurateurs. Des structures pour les classifications standard telles qu’ECLASS et ETIM. Des structures permettant l’illustration de formats XML comme BMEcat. Des structures pour la gestion des données de coupe pour les outils. Et bien d’autres encore. L’idée de base de notre modèle de structures flexible revient à notre premier responsable des bases de données ; ce qu’il a baptisé « objet de structure » en est la clé de voûte. De cette manière, il est également possible de modéliser des situations en fonction des besoins des clients (prêtes à être mises en production !), ce que nos clients apprécient beaucoup. Bien sûr, le principe décrit ci-dessus pour les champs s’applique ici aussi : les nouvelles structures doivent être immédiatement visibles partout.
• Les relations sont représentées sous forme de liaisons. C’est en fait l’objectif principal de la base de données : créer du contenu une seule fois et le réutiliser fréquemment. Bien sûr, cela est également possible sans base de données – mais uniquement sous forme de copie, c’est-à-dire sans lien avec le contenu d’origine. Et les copies finissent par mener leur propre vie, comme nous le savons tous. Dans le cas le plus simple, les relations peuvent consister en des liens entre des images, des documents et des textes, d’une part, et des articles, des groupes de produits, etc., d’autre part. Ou encore des liens entre des accessoires, des pièces de rechange et des nomenclatures. Dans le cas des nomenclatures, les « attributs de liaison », tels que le numéro de position et la quantité, jouent également un rôle ; et dans le cas des emballages, ce sont les dimensions, le poids, le code EAN, etc. Un modèle de données flexible devrait être librement configurable en fonction de ce type de relations.

La flexibilité se manifeste dans tous les domaines

Outre les aspects décrits, vous devriez veiller globalement à choisir un système PIM flexible. Prêtez une attention particulière à l’évolutivité de ces éléments : langues et pays, formats numériques et unités de mesure, catalogues et gammes de catalogue, listes des prix et attributs de prix, formats de texte et caractères spéciaux.
La flexibilité se manifeste d’ailleurs également dans les programmes en aval : quel est le degré de flexibilité de la mise à disposition des données ? Les services API et les exportations de données pour les boutiques en ligne, les sites web et d’autres systèmes peuvent-ils être facilement adaptés ? Quel est le degré de flexibilité de Printengine ? Autrement dit, les modèles de mise en page destinés à être utilisés dans InDesign peuvent-ils être facilement adaptés et étendus, ou des connaissances en programmation (« scripting ») sont-elles nécessaires ?

Le défi

Je ne veux pas cacher qu'un tel « modèle de métadonnées » est très exigeant. En effet, l'évaluation est plus complexe, car il faut d'abord passer par les métadonnées. Ce dilemme doit bien sûr être résolu, car sans performance, la flexibilité n'a aucun sens. La bonne nouvelle : c'est faisable !

La configuration du modèle de données nécessite en outre une interface qui guide l'administrateur PIM ; les modifications effectuées doivent être immédiatement visibles dans tous les programmes.

Conclusion

Vérifiez l'évolutivité (illimitée) du modèle de données, tant au niveau du contenu que de la structure. C'est un peu comme le moteur d'une voiture. N’hésitez pas à jeter un œil sous le capot ! C’est-à-dire sous l’interface utilisateur. En effet, l’interface utilisateur évolue sans cesse, tandis que le modèle de données lui-même est très pérenne. Et seul un modèle de données flexible vous permettra d’être bien préparé pour l’avenir. Et pour finir, encore une recommandation : demandez combien de bases de données sont utilisées pour l’ensemble de la solution système. La réponse devrait être : une seule base de données. En effet, l’utilisation de plusieurs bases de données engendre des copies, des redondances, des incohérences et, surtout, un surcroît de travail inutile.