Interview Ludovic Genest, Responsable Cloud Software Orisha Commerce France

À l’automne 2025, nous avons interviewé Ludovic Genest, Responsable Cloud Software Orisha Commerce France, pour comprendre comment les API transforment la mise en œuvre du recommerce dans le retail.

Dans cet échange, il revient sur les enjeux d’architecture, d’interopérabilité et de gouvernance qui permettent aux enseignes de connecter simplement leurs modules de rachat, d’atelier ou de revente à leur système d’information.

Au sommaire :

• Les principes d’une architecture composable
• Les endpoints essentiels pour le recommerce
• La sécurité et la gouvernance des API
• Les quick wins et retours d’expérience concrets
• Les perspectives à 3 ans pour le retail connecté

Introduction

Re-commerce c’est vendre, réparer, louer, revendre. Nous démarrons une nouvelle gamme de produits pour prendre en main ces actions via des modules. Ces modules ont comme principe de pouvoir s’interfacer avec les produits existants de nos différents filialles (Ginkoia, Openbravo, Fastmag) et donc être indépendant de l’ERP ou du POS. Pour communiquer entre ces modules et l’eRP ou le POS quoi de mieux que des Api.

Chez Ginkoia nous avons complètement changé de philosophie pour maintenant via Ginkoia Api Center mettre à disposition non seulement des Api mais aussi un portail développeurs pour nos clients

Ouvrir nos fonctionnalités Recommerce via des Api va permettre  à un SI d’imaginer des solutions très ouvertes. Pour autant manipuler des Api nécessite des compétences techniques pas uniquement lors de la mise en oeuvre mais aussi dans le temps.  Et comprendre les Api, savoir les utiliser est un vrai challenge qu’il ne faut pas négliger.

Architecture & interopérabilité

Bien dissocier le front et le back afin d’avoir une interface user qui s’appuis sur des API qui peuvent être de différentes origines. Il faut être capable d’avoir des API intermédiaires plus proche du fonctionnel, qui peuvent appeler des API plus unitaire, plus bas niveau dans les couches techniques. Cela afin d’être capable d’utiliser différentes API dans les couches basses provenant de différents système ERP ou POS sans impacter les interfaces et le fonctionnel.

S’assurer que son ERP ou son POS dispose des Api suffisantes. Valider que chaque action fonctionnelle puisse être réaliser par les Api. 

Dans mon atelier je prépare mon bon atelier, ce bon atelier me permet de gérer les travaux, les techniciens , le statut. Mais aussi être capable d’être payé en caisse et automatiquement changer le statut du bon atelier après paiement en caisse. Tout cela via des flux Api/webhook.

Il existe maintenant des outils (service bus) qui permettent d’éviter que les Api s’appellent les unes et les autres. On passe par des services bus, des webhook qui permettent des services Asynchrones et surtout persistants. 

Souvent quand on fait des Api on pense aux Api CRUD (Create, Read, Update, Delete) et on pense avoir fait le job quand on fournit ce type d’Api pour l’ensemble des objets managés par la solution. Mais il manque les Api les plus importantes, les Api fonctionnelles, les Api de recherche multicritère, les Api de traitement par lot.

Endpoints et données critiques

Il faut utiliser des Api CRUD et GraphQL pour donner la capacité de faire des recherches rapide. Il est aussi important d’avoir des niveaux d’abstraction entre des Api couche données et des Api métiers. et il faut évidemment être capable d’exposer les Api métiers et pas les api couches données afin de pouvoir modifier facilement les couches données sans impacter les couches métiers.

On préconise aussi de classifier les Api et d’avoir des comportements différents selon le type de données. par exemple les données MasterData en oppositions des données TransactionsData. Les api MasterData vont surtout devoir être efficientes pour les recherches, fournir des incréments, aider à lire un grand nombre de données (mise en place de cache).

Les api TransactionData vont au contraire valoriser la création à très haute fréquence (mise en place de file d’attente).

La cohérence des données est au centre des enjeux. Et il est très difficile de répondre à cet enjeu. Pour cela il faut définir les bonnes contraintes. Par exemple si on veut avoir des analyses pour comparer les ventes entre les 3 derniers mois s’il manque le dernier ¼ h de données par très grave, par contre si on parle d’analyse de stock, de contrôle de gestion, d’inventaire il faut disposer des données très précises.

Il faut se doter d’outils de contrôle de cohérence. Il ne faut pas les oublier. Par exemple, si vous consolider les données de ventes il faut de temps en temps être capable de lancer des contrôles automatiques qui vont mettre en avant des incohérences et être capable de relancer automatiquement dans un temps calme des synchronisations globales.

Sécurité, gouvernance et conformité

Il faut toujours mettre en place des systèmes d’autorisations, de token. Et s’assurer qu’aucun code ne contient des secrets (URL, login, clé Api) mais passe bien par des mécanismes de coffre fort ou ces informations sont stockées.

La gestion de clé Api que l’on fournis à des applications tierces doit aussi être prise en compte et dans les standards. Il existe plein de solutions à qui l’on peut déléguer ces mécanismes pour éviter de les développer. C’est le travail de l’Api Manager.

Il n’y a pas de spécificité RGPD pour les Api. Il faut respecter les mêmes principes que lors des accès à la base de données directe.

Souvent on oublie les api de nettoyage qui vont supprimer les données personnelles quand elles ne sont plus nécessaires.

Attention aussi aux différents logs que l’on peut mettre en place et qui peuvent contenir des détails d’un appel à une Api qui vont contenir des données personnelles et qu’il faut encadrer.

Il faut passer par un Api manager qui va prendre en charge toutes les fonctionnalités d’un moteur d’Api et éviter surtout de coder ces mécanismes.

Par exemple, on ne va jamais coder un quota d’appels dans une Api, mais bien dans l’Api manager qui va gérer ce quota nativement.

ROI, déploiement & “quick wins”

Il faut prendre le temps, choisir le bon intégrateur ou s’assurer que ces équipes techniques prennent le temps de comprendre la philosophie des Api proposées afin de faire une intégration efficiente.

Il s’agit surtout pour moi d’avoir une bonne vision technique et fonctionnelle afin de mettre en place des solutions fiables et évolutives.

Chez Orisha Passy on propose toujours des ateliers de présentation, cela permet de gagner du temps pour tout le monde. L’intégrateur gagne du temps en évitant de partir dans une mauvaise direction.

Nous disposons de KPI sur les temps de chargement, le nombre de requêtes. Ce sont des Kpis assez classiques qu’il faut surveiller et quand on atteint une volumétrie importante, il faut avoir réfléchi aux optimisations possibles pour les mettre en œuvre.

Par exemple la mise en place de Cache Redis dans plusieurs Api qui partagent des données et cela va limiter les accès à la base de données et réduire les temps de réponse. Par contre cette technique est plus complexe et nécessite une infrastructure Azure plus conséquente. Elle est donc à mettre en œuvre quand la volumétrie le requiert.

Je ne vais pas citer une enseigne, mais je me souviens d’une Api qui permet de créer des commandes clients pour la vente (prise de la commande, création du client, de stockage des produits, émissions de facture).

Et l’intégrateur a voulu l’utiliser pour de la location et donc dans l’ERP il y a eu des ventes de matériel de skis au prix d’une journée de location, avec en plus du de stockage. On voit l’importance de communiquer entre le fonctionnel, la technique, le client, l’intégrateur et le fournisseur d’Api.

Api n’est pas un mot magique qui résout tous les problèmes.

• Conseil 1 : Passer par des api ne dispense pas de faire une conception de son projet
• Conseil 2 : Définir à l’avance les process lors des évolutions (changement de version) avec vos équipes ou l’intégrateur, pour les anticiper et pas les subir
• Conseil 3 : Mettre en place des Mock pour tester les Api et éviter de faire des tests en production.

Vision & perspectives

La part des api va être de plus en plus importante et il va falloir se doter d’outils pour bien suivre ces flux de données, être homogène et cohérent.

Il n’y aura plus de projet sans Api . Attention si les standards n’évoluent pas, les technos et les outils sont en très forte évolution.

Il faut découper ces fonctions métiers et ne plus penser monolithe qui fait tout. C’est très dur car cela oblige à élaborer un système complexe et il ne faut plus penser qu’un logiciel va tout faire. Nous avons plus besoin d’architectes que d’acheteur d’une solution.

Définir des objets et être capable de mettre en place du mapping data driven entre l’objet externes et l’objet interne

Bonus

C’est plus une méthode, définir l’architecture et faire du design first avant tout développement.

Tests de charges et de performances sont trop souvent négligée. J’ai un outil qui me permet d’envoyer mes tickets pour faire du BI. J’ai fait une modif dans mon POS pour envoyer mes tickets à chaque création de tickets.

C’est fonctionnel et puis le premier samedi des soldes mon POS passe de 2 secondes à 45 secondes pour créer un ticket car l’envoi du ticket est trop lent, il y a pleins de retry car l’Api ne répond plus. Dans ce cas des tests de charges auraient mis en avant qu’il fallait déléguer l’envoi des tickets à un autre système que mon POS.