Le temps réel est devenu la quête de nombreux acteurs du Retail: obtenir à tout moment et en tous lieux des données actualisées sur les clients, les transactions ou encore les stocks, être en mesure d’échanger des informations de manière synchrone entre différents systèmes, … tout cela fait miroiter de nombreuses opportunités business et permet de développer de nouvelles stratégies, notamment Retail. En effet, la connaissance client est enrichie, l’expérience client peut être plus personnalisée, la supply chain peut être optimisée, le suivi et les statistiques reflètent davantage la réalité, la prise de décision en est facilitée. Ces opportunités sont désormais rendues possibles par le recours aux APIs. Très peu développées, il y a encore quelques années, les APIs ont connu un véritable boom dans de nombreux secteurs et notamment le retail, on observe donc une démocratisation de ces dernières. Néanmoins, leur utilisation ne doit pas être une fin en soi et se doit d’être réfléchie.
Le contexte client
C’est dans ce contexte que OneTeam a accompagné un de ses clients pour l’aider à définir ses besoins de temps réel et veiller à développer les APIs en bonne intelligence.
Cette technologie entend donc satisfaire les besoins d’immédiateté de l’utilisateur avec l’avantage d’extirper des outils traditionnels certes robustes mais qui souffrent de lenteur en termes de développement. En effet, qui n’a jamais entendu dire dans la bouche d’un éditeur « Ce besoin n’est pas prévu dans la roadmap de cette année, il ne pourra être étudié que l’an prochain et donc, disponible au mieux dans deux ans. C’est la situation à laquelle nous avons été confrontés. Notre client souhaitait, initialement, pouvoir échanger des données « clients » en temps réel entre le site e-commerce et les points de vente afin de développer un programme fidélité omnicanal.
La solution et son périmètre
La solution proposée a été de développer une sur-couche capable de communiquer par web service. Grâce à cela, il devenait possible de mettre à disposition la totalité des informations disponibles dans le POS auprès d’applications tierces d’une part et de pouvoir alimenter le POS avec des données externes, et ce, en temps réel.
« Le temps réel peut dégrader les performances applicatives. »
Cependant, il convient de souligner que la quantité n’est pas synonyme de qualité. En effet, plus le volume de données échangées augmente, que ce soit au sein d’un même appel ou en terme de nombre d’appels, plus la base de données applicative est sollicitée. Or, la disponibilité de cette dernière doit être préservée afin de remplir sa fonction première : répondre efficacement à l’activité des points de vente et leur permettre de réaliser des transactions de manière fluide et le plus rapidement possible. Par conséquent, cette contrainte a été la pierre angulaire de la conception d’APIs. Cela a permis de réduire les différents types d’appels et la quantité d’informations échangées par appel. Une communication asynchrone était proposée avant le recours aux APIs et l’utilité de chaque donnée à interfacer était discutée afin de les limiter au strict nécessaire. Cette nécessité a évidemment donné lieu à de nombreux ateliers de conception et des arbitrages entre le business retail pur et la stratégie omnicanale. Une réflexion approfondie facilitant la prise de décision peut sembler chronophage mais s’avère généralement bénéfique pour la suite du projet.
Ainsi, ces discussions riches et nécessaires ont produit un cahier des charges détaillé et réduit qui offrait des perspectives avantageuses pour les prochaines étapes du projet. Avoir une compréhension précise du besoin ainsi qu’un scope réduit permet de réaliser des spécifications plus explicites d’une part et de réduire les temps de développement, de test et de formation. Afin de répondre aux exigences d’un métier toujours impatient, un mode de développement par lot a été proposé et adopté. Sur les bases de la méthode agile, les besoins ont été priorisés puis inscrits dans plusieurs lots. Cela a donc permis de proposer au métier des fonctionnalités opérationnelles dès la première livraison puis de les enrichir au fur et à mesure des sprints de développements. Cette approche visait également à améliorer la qualité des développements et donc la satisfaction des utilisateurs, car il n’y a rien de pire qu’un rejet de solution dû à un mode opératoire trop contraignant ou générant plus de problèmes que de solutions pour le quotidien de ces derniers.
Des besoins multiples…
Par ailleurs, si le besoin initial était orienté « expérience client », l’accès au temps réels a donné lieu à l’émergence de nouveaux besoins métier bien éloignés de ce périmètre initial. Ils concernaient, en effet, l’optimisation de la gestion des stocks. Avant d’initier le projet, une étude d’opportunité a été effectuée afin d’évaluer la nécessité de recourir aux APIs. Une fois confirmé, il a été proposé pour ce projet d’appliquer la même méthodologie que la précédente en y ajoutant une étape de Proof Of Concept, un POC. Cela était nécessaire d’autant plus qu’en parallèle du développement des APIs, un lourd investissement d’équipement des points de vente y était associé ainsi qu’une charge non négligeable d’accompagnement des équipes sur place était à prendre en compte. Ainsi, l’option de réaliser un POC avant d’envisager un déploiement plus large prenait tout son sens. D’une part, cela offrait la possibilité de valider l’utilité du projet en point de vente, de s’assurer de l’adoption de la solution par le métier et d’évaluer plus précisément le ROI. La réalisation d’un POC permet d’affiner le périmètre du projet, d’adapter ses fonctionnalités et de les perfectionner afin de le rendre encore plus utiles pour le métier.
… et une documentation de qualité
Ces deux cas que sont le programme de fidélité et la gestion des stocks permettent de constater que les APIs peuvent rapidement se développer et ce, sur des thématiques très éloignées : ici, de la relation client à la chaîne logistique. Pris dans la dynamique du projet et dans les contraintes planning, il arrive souvent que la réalisation de la documentation et/ou du partage de la connaissance soit remise à plus tard car cette dernière ne semble pas être capitale pour la mise en production dudit-projet.
« Une documentation riche est nécessaire car elle assure la maintenance évolutive des APIs. »
Or, afin de maintenir et de faire évoluer les systèmes et les modalités de communication, il est nécessaire d’avoir un accès rapide et limpide aux développements qui ont été réalisés. Ce besoin a été partagé avec le client en soulignant qu’il était d’autant plus important lorsqu’il s’agit des APIs. En effet, dès lors qu’un protocole existe permettant d’échanger des données entre plusieurs systèmes, il convient de s’assurer que chaque partie prenante de cet écosystème ait une vision claire et détaillée de cette nouvelle configuration.
Les APIs au défi du long terme
Cela permet d’être capable de la maintenir dans le temps. A la maintenance applicative, s’ajoute la maintenance de l’interopérabilité de ces dernières.
De plus, cette problématique de maintenance permet de rendre compte d’une autre limite du temps réel dans les échanges de données. Il s’agit de l’interdépendance des systèmes. En fonctionnant de manière asynchrone, une application peut communiquer avec d’autres avec un certain délai. Les données échangées sont importantes et nécessaires mais elles ne sont pas un prérequis au fonctionnement de cette dernière. A contrario, si l’appel webservice devient une condition sine qua non à la réalisation d’une tâche, alors en cas de problème de connectivité, d’infrastructure ou de blocage de l’application tierce, le système en question peut devenir lui-même inopérant. Ainsi, un problème même mineur et à priori localisé peut rapidement bloquer un périmètre bien plus large, impactant plusieurs typologies d’activités. Par conséquent, s’il est vrai que dans certains cas, les APIs viennent remplacer des interfaces asynchrones, il est recommandé de garder les APIs pour les besoins confirmés de synchronisation en temps réel et de garder les interfaces de masse pour de la synchronisation journalière et les volumes plus larges.
Cette contrainte d’interdépendance se porte également sur la sécurité du SI. Pour cette dernière, un audit a été fait avec l’équipe dédiée, à travers un test d’intrusion. Cela a permis de mettre en lumière de potentielles vulnérabilités et d’y remédier d’une part et de définir un plan de maintenance en cas d’intrusion malveillante.
Le cadrage encore et toujours…
Ainsi, il est indéniable que les APIs offrent de nouveaux horizons au retail et permettent à ces acteurs de développer de nouvelles stratégies permettant de répondre aux besoins des clients. Ces derniers toujours plus informés, impatients et en quête de personnalisation ne veulent plus d’une offre produit standard, d’un service impersonnel et encore moins attendre. C’est pourquoi l’échange de données en temps réels n’est plus un luxe mais une nécessité pour toute enseigne souhaitant se démarquer.
« Relativiser la nécessité du temps réel, un facteur clé de succès. »
Comme cette quête n’est pas sans risque, ni sans contrainte, il est vital pour la réussite et la pérennité du projet, de définir le besoin en challengeant toujours l’utilité du temps réel en amont. Cet arbitrage sur le recours aux APIs vaut tant pour les nouveaux besoins que pour les flux asynchrones existants. Ce type de projet requiert également de cadrer le périmètre et les parties prenantes de ce dernier afin de couvrir l’ensemble des problématiques métier, IT, sécurité…