Rares sont les éditeurs de solutions PIM qui n’ont toujours pas passé le cap du cloud et ne proposent qu’une version on premise de leur application. Si certains ont dès le début fait le pari du SaaS by design, tel l’éditeur français Quable ou l’américain Salsify, certains ont préféré opter dans un premier temps pour le PaaS, offrant plus de souplesse à l’intégration. Mais la tendance actuelle va vers une uniformisation vers le full SaaS, ce qui ne va pas sans contrainte sur une architecture globale d’un système d’information. C’est ce que nous allons voir dans cet article.
Mais, avant tout, rappelons ce que signifient les termes On Premise, PaaS et SaaS.
On parle tout d’abord d’On Premise (qu’on traduirait littéralement par “sur site”), lorsque la solution va s’intégrer au sein même de l’infrastructure du client, qui a donc la responsabilité de son installation et sa maintenance.
Avec le PaaS (Platform as a Service), l’éditeur met à disposition sa propre infrastructure cloud pour héberger l’application. Cela permet au client de partager une partie de la responsabilité avec l’éditeur qui gère l’infrastructure et le client (ou son intégrateur) qui reste en charge de la maintenance du logiciel (y compris les montées de version) et des données.
Enfin, le SaaS (Software as a Service) est un mode de fonctionnement dans lequel non seulement l’infrastructure cloud est gérée par l’éditeur, mais également toute la partie logicielle. Cela permet de déporter toute la responsabilité de l’hébergement et la maintenance à l’éditeur.
Avec ce mode SaaS, le PIM va pouvoir évoluer de manière transparente pour le client : il n’y a plus de montée de version à gérer. Et ce ne sont pas des versions annuelles ou bi-annuelles, mais plutôt une amélioration continue avec des mises à jour mensuelles, hebdomadaires, voire même quotidiennes. Ce qui permet de bénéficier au plus vite des évolutions fonctionnelles ou des correctifs (de sécurité par exemple).
Le schéma suivant résume bien les différents niveaux d’engagement et de responsabilité du fournisseur de service en fonction du choix d’hébergement de la solution :
Si pour certains le choix de l’on premise ne se discute pas, par une volonté de maîtriser et sécuriser l’intégralité de leur système d’information, on voit que le mode SaaS est très séduisant en permettant la délégation d’une grande partie des responsabilités. Il faut bien sûr y associer une dimension financière, car l’hébergement PaaS / SaaS est fort logiquement un poste supplémentaire de frais. Et ces derniers temps ont vu de fortes augmentations des tarifs pratiqués par les éditeurs de solutions SaaS (cf l’article du Monde Informatique Gartner appelle à la vigilance sur la hausse des tarifs des solutions SaaS) »). Il est donc nécessaire de bien étudier les gains apportés par les solutions SaaS vis-à-vis des frais que cela implique relativement au coût de mise en œuvre et de maintenance de toute une infrastructure interne.
Un autre aspect important entrant en ligne de compte dans ces choix d’infrastructure est le besoin de customiser la solution PIM. Bien entendu, au début de tout projet, tout le monde est aligné pour intégrer la solution choisie dans ses fonctionnalités natives sans y apporter de customisation. Et c’est là qu’une mission de cadrage et choix de solution en amont prend toute sa valeur, afin d’opter pour la solution qui répond au mieux aux attentes client.
Mais malgré tout, bien souvent, les contraintes du système d’information ou les exigences des équipes métier font qu’il n’y a pas d’autre choix que d’ajouter des développements spécifiques. Cela peut être dans le but de gérer des flux de données entrants ou sortants si le système d’information ne dispose pas d’une brique de type ESB ou ETL, ou bien pour étendre les fonctionnalités natives de l’outil et ainsi répondre à des processus métiers spécifiques.
Si on reprend une architecture basée sur une intégration on premise, on voit que les développements spécifiques vont naturellement pouvoir se greffer sur l’application.
Dans le cas du PaaS, si l’application est hébergée en dehors du SI client, il y a tout de même accès pour y ajouter des couches de spécifiques.
Et c’est là où le SaaS, si simple et pratique par essence, devient un peu plus complexe…
La mise en place de connecteurs ne peut plus se faire sur l’infrastructure dédiée au PIM. Il est nécessaire de mettre en place un middleware, soit dans le SI interne, soit sur une brique externe, qui va devoir porter la logique métier de ces interfaces.
L’intégration doit donc se faire en mode full API, car très peu de solutions autorisent encore un accès SSH ou sFTP, ce qui rend l’usage des imports/exports en mode fichier caduque. Ces APIs doivent donc être un socle ultra stable et indépendant des montées de versions qui peuvent donc être très fréquentes. S’il peut y avoir des ajouts fonctionnels, il faut à tout prix éviter de modifier la signature d’une méthode d’API, au risque de mettre en péril les intégrations qui ont été basées sur celle-ci.
Pour aller plus loin dans les possibilités d’intégration d’un PIM via API, certains éditeurs proposent des APIs en mode événementiel (c’est le cas par exemple d’Akeneo), qui va permettre d’inverser la logique de déclenchement : ce n’est plus le middleware qui appelle le PIM pour lui faire faire quelque chose, mais le PIM qui va notifier le middleware d’un événement (une création produit faite par un utilisateur, un changement de statut, …) afin qu’il puisse déclencher une action à son tour.
Aussi, toute personnalisation de l’outil, surcharge graphique de l’interface par exemple, ne peut plus être faite. Les APIs offertes par les solutions SaaS sont très souvent uniquement orientées sur la partie traitement des données, sans proposer de quoi ajouter des fonctionnalités dans l’interface utilisateur et de personnaliser l’expérience utilisateur (impossible via API de rajouter un bouton, d’ajouter une entrée de menu, de pousser des notifications custom, …).
Retours d’expérience
Un de nos clients, distributeur dans l’alimentaire en B2B, possède un PIM Akeneo en PaaS connecté, entre autres, à un ERP SAP on premise et à une marketplace Mirakl en SaaS.
Afin de réduire les coûts liés aux montées de versions du PIM (1 version majeure / an) et incité par la stratégie de l’éditeur visant à privilégier leur version SaaS, il souhaiterait donc passer son PIM de l’offre PaaS à SaaS.
Des travaux ont été entamés dans cette optique pour déporter certains connecteurs, dont celui avec l’ERP, présents sous forme de bundles (extensions développées spécifiquement sur la plateforme PIM) vers l’ESB interne au SI.
Mais la question reste entière sur la manière de connecter la future version SaaS du PIM avec Mirakl qui est également en SaaS. L’interface est actuellement gérée depuis un bundle “sur le PIM”, qui propose une interface de configuration et gère les appels aux APIs de Mirakl. Ce qui nous amène pleinement dans la problématique de notre second retour d’expérience.
Pour le compte d’un éditeur d’une solution de traduction, nous développons depuis plusieurs années leur connecteur vers une des solutions PIM du marché (voir notre article). Ces 2 solutions étant sur un modèle SaaS, il n’est pas possible d’y ajouter une part de développement spécifique pour gérer l’interfaçage, la logique métier qui va avec et l’écran de configuration, minimale mais indispensable au paramétrage de la connexion entre les instances SaaS. Nous avons donc développé une application tierce pour gérer tout ça, très simple et basée sur Symfony.
Mais la question importante à ce stade est “où héberger cette application” ?
Il n’apparaît pas concevable pour un client ayant fait le choix d’utiliser 2 solutions SaaS pour s’abstraire de la problématique d’infrastructure, de finalement avoir à héberger une application pour faire le lien entre elles. Dans notre cas, c’est l’éditeur de la solution de traduction, à l’initiative du connecteur, qui a fait le choix d’héberger cette application tierce et de proposer ce service à ses utilisateurs.
La vision de Clever Age
On l’a vu, chaque mode d’hébergement présente des avantages et des inconvénients et il n’y a pas vraiment de “bonne” solution. On note une tendance des éditeurs à aller de plus en plus vers le SaaS, qui apporte beaucoup de souplesse de part et d’autre. Et nous encourageons ce mouvement lorsqu’il est en accord avec le mindset des DSI, car c’est un réel gain pour nos clients de s’abstraire des problématiques techniques liées à l’hébergement et se concentrer sur les fonctionnalités, là où sont les véritables valeurs ajoutées apportées par ces solutions. De plus, les solutions SaaS sont un pilier essentiel des architectures MACH (ou “composables”).
Pour autant, le SaaS ne sera pas forcément compatible avec un contexte projet exigeant si les fonctionnalités de la solution ne répondent pas suffisamment aux attentes et nécessitent une part de customisation. Il faut également être vigilant quant aux interdépendances entre les solutions lors de montées de versions, où les différents connecteurs mettent parfois plusieurs mois à se mettre à niveau (ce qui a pu être le cas lors de l’arrivée de Magento 2 par exemple).
Il est donc très important de confronter les différentes pistes d’architecture aux besoins et contraintes que vont avoir chaque projet PIM. Toutes ces caractéristiques doivent être étudiées en amont du projet lors d’une phase préalable de cadrage, qui va permettre de sélectionner la solution qui offrira la couverture fonctionnelle la plus proche des besoins exprimés et répondra au mieux aux contraintes d’intégration au système d’information.
