« Digital Factory » : aligner gouvernance et technologie pour « faire mieux avec moins »

L’adoption des Plateformes d'Expériences Digitales (DXP) et la maturité atteinte révèlent un constat nuancé : si les gains sont réels, les difficultés le sont tout autant. Ces défis ne concernent pas uniquement la technologie, mais également l’organisation et la gouvernance qui la soutiennent. Rapellons que l’objectif premier visé par la mise en place d’une « Factory » est la rationalisation. Les premiers services doivent absorber la majorité des coûts initiaux afin de les réduire au maximum pour les services suivants. Cette mutualisation des coûts fixes (infrastructure, licences, maintenance) créé des économies d’échelle qui bénéficient à la mise en œuvre des usages suivants. C’est cette logique qui conditionne la rentabilité du modèle.

La gouvernance est un des piliers du modèle, elle est cependant souvent choisie en fonction de contraintes opérationnelles, telles que les plannings, plutôt que sur des critères stratégiques alignés avec la rentabilité. Trois approches dominent :

• Une gouvernance lâche, qui privilégie l’autonomie des équipes mais réduit fortement la rationalisation. 

• À l’inverse, une gouvernance forte, maximise la mutualisation mais impose des cadences séquentielles avec des risques de contentions qui peuvent engendrer des dérives planning. 

• Enfin, la gouvernance hybride, tente de concilier les deux logiques mais au prix d’une complexité (encore) accrue notamment vis-à-vis de la définition des frontières de liberté et le maintien de la cohérence fonctionnelle et technique de la plateforme. 

Par analogie nous pourrions voir la première comme une maison individuelle où les libertés sont maximales, la seconde comme une colocation et la dernière comme une copropriété. S’il est impératif de choisir un modèle il faut le faire en y incluant des acteurs disposant du bon niveau d’arbitrage orienté sur les axes que l’on souhaite privilégier tout en ayant conscience que l’on ne peut pas tout avoir (rentabilité, vélocité, parallélisation, etc.).

Le « core model » peut être défini comme le jeu de services, de composants et d’outils mutualisés entre les usages, c’est le poumon de la rentabilité. Sa définition exige une trajectoire claire, des attendus fonctionnels et techniques précis, et une gouvernance forte pour éviter d’intégrer des usages qui n’apporteraient aucun bénéfice mutualisable. Cette tâche qui constitue l’autre enjeu fort de la « factory » est ardue du fait notamment de la difficulté à percevoir et à définir ce qui est proche, complexe ou couteux. Deux usages proches fonctionnellement peuvent s’avérer en pratique très éloignés techniquement. Par exemple la mise en œuvre d’un site e-commerce monolithique avec gestion des commandes et des factures intégrées n’aura en pratique pas grand-chose à partager avec le même site e-commerce gérant ses produits dans un PIM et ses factures dans SAP. 

Il en va de même pour la complexité. Le service de recherche de Google qui, bien que constitué d’une page et d’un seul champ de saisie, présente une complexité cachée très importante difficile à percevoir en dehors du prisme technologique. Enfin, nous avons l’habitude de penser intuitivement que ce qui est complexe est couteux alors que ce qui est perçu comme simple non. Pour tenter d’illustrer la nuance qu’il peut y avoir, utilisons l’analogie suivante : si une personne essaye de vider une baignoire pleine avec une petite cuillère. Cette tâche pourtant bien que d’apparence simple exige un grand nombre de répétitions peu efficaces qui finirait invariablement par la rendre couteuse. A ce constat s’ajoute d’autres facteurs telles que le biais cognitif identifié par Abraham Maslow dans sa bien connue loi de l’instrument : 

« J'imagine qu'il est tentant, si le seul outil dont vous disposiez est un marteau, de tout considérer comme un clou. » - Abraham Maslow

A ces difficultés viennent s’ajouter les défis technologiques tels que la maintenance et l’évolution de ce « core model » dans un contexte de mutualisation forte. Comment éviter qu’un disfonctionnement ne se propage à tous les usages ? Comment distribuer et versionner efficacement et de manière fiable ce « core model » ? Comment assurer sa maintenance sans exploser les coûts et des délais de livraison dans le temps ? Ces quelques facteurs illustrent la difficulté qui peut exister pour les différents acteurs à réaliser les arbitrages nécessaires en pleine conscience, seul moyen selon moi d’anticiper les difficultés qu’ils poseront par la suite.

En résumé, il faut garder en tête qu’un « core mode » centré sur des fonctionnalités propres à un seul usage ne peut être rentable. Il faut également réaliser que la maintenance fait partie intégrante de la vie d’une plateforme et qu’il faut bel et bien intégrer ces coûts dès le départ et les gouverner finement. Enfin, aucune solution technique ne répond parfaitement à tous ces enjeux il s’agit bien souvent de sélectionner un modèle pour ses avantages et de réduire au possible l’impact de ses inconvénients pour l’organisation qu’il sert.

Face à ses problématiques anciennes, de nouveaux enjeux ont surgi. Dans un contexte où il faut patcher vite et souvent, les architectures et les modèles de gouvernance trop centralisés se révèlent couteux et incapables de suivre les cadences imposées par le business. La transition vers le Cloud souvent réalisée pour les grands groupes via l’adoption de clouds privés « as a service », a exposé les organisations à des difficultés techniques majeures liées à l’adoption des DXP : déploiement en environnements conteneurisés stateless, performances du système de fichier partagé, montée en charge des clusters, autoscaling, etc. Ces obstacles ont généré pour certains d’entre eux des délais excessifs, l’adoption de solutions transitoires coûteuses annihilant tout ou partie des gains attendus. Le marché des compétences accentue encore ces tensions. Malgré des communautés actives à travers le monde, le sourcing peine à répondre à une demande qui demeure forte. Les entreprises font face à une pénurie de profils qualifiés, à une inflation des coûts d’expertise ainsi qu’à une désaffection des nouvelles générations, rebutées par des solutions jugées (trop vite) complexes et vieillissantes. À cela s’ajoute le risque lié aux personnalisations excessives : des architectures ouvertes et mal gouvernées entraînent des coûts de maintenance qui dépassent parfois le coût initial du projet tandis que des architectures trop fermées réduisent trop fortement l’utilisabilité de la plateforme et donc sa capacité à être adaptée et vendue.

« Nous devons choisir avec soin les outils avec lesquels nous travaillons . Certains outils sont adaptables, tandis que d'autres devraient être employés uniquement pour leur usage prévu » - Sharlyn Lauby

Face à ces constats, les éditeurs DXP et notamment Liferay ont adoptés des stratégies de rupture par rapport au passé. Liferay, mise depuis quelques années sur le découplage, la modularisation et une approche orientée Low-Code et SaaS. Cette solution répond aux problématiques d’infrastructure par une offre complète – SaaS, PaaS, on-premise – associée à une plateforme Low-code/No-code performante. Cette architecture sans être trop permissive propose un excellent niveau de personnalisation porté par des technologies non-propriétaires. Ces choix font de Liferay une plateforme unique sur le marché capable de répondre à de nombreux modes de fonctionnement des plus gouvernées au moins gouvernées des plus rationalisées aux plus ouverts. Ce mouvement de Liferay a également permis à certains clients déjà utilisateurs d’envisager des scénarios de transition d’architecture plutôt que de refonte. Cette approche se révèle souvent plus avantageuse en matière de conduite du changement, d’expression de besoin, de réutilisation du code et de la configuration existante, de reprise de données, etc.

Tandis que les organisations s’attèlent à adapter leur gouvernance et leur choix technologiques d’autres défis pointent déjà. Au-delà de l’effervescence du marché, la nécessité de prendre du recul et d’identifier les « uses cases » qui rendent l’intelligence artificielle compatible avec un ROI en « quick win » est difficile.  Cela d’autant plus compte tenu des limites et contraintes que nous connaissons : risques de « vendor locking », d’inflation des coûts, erreurs liées à l’hallucination et au non déterministe, temps de traitement longs, confidentialité des données, pertinence et exactitude du contenu, etc.  Pour le contenu, je demeure convaincu que pour que la pertinence des réponses perdure, il faut dès à présent le penser pour être compréhensible par des LLM, rappelons-le, disposant tous d’une taille de contexte limitée. L’explosion des contenus générés par l’IA impose de repenser les modèles de production : il est illusoire d’imaginer un monde où les IA publient pour les IA. La création doit, ou devrait, rester majoritairement humaine, assistée par l’IA, afin d’éviter une boucle stérile qui freinerait notre propre évolution ainsi que celle des modèles. Force est de constater que la bonne équation définissant cet équilibre est à trouver. 

Le dernier défi est probablement le plus central, il concerne la confidentialité des données. Alors que la bonne solution du modèle d’IA souverain n’est pas tout à fait trouvée, certains de nos clients se tournent vers l’hébergement de modèles d’entreprise capables de garantir cette confidentialité au prix sans doute de performances techniques (encore) moins bonnes et une difficulté à bien suivre les améliorations proposées par les modèles commerciaux. Dans un monde où l’on développe moins, il faut automatiser davantage. Les gains permis par le Low-Code/No-Code et l’IA ne doivent pas être annihilés par des coûts et des délais de mise en production trop élevés. Sur cette question les éditeurs telles que Liferay tentent de fournir des réponses permettant d’éviter une remise en cause pure et simple du modèle Low-Code tel que nous le connaissons.

En définitive, la performance d’une Digital Factory repose sur l’alignement entre gouvernance, « core model » et technologie. Les organisations qui réussiront, seront celles qui sauront arbitrer lucidement entre autonomie et rationalisation, structurer un socle commun réellement mutualisable et moderniser leur équation technologique en tirant notamment parti des bénéfices non pas promis mais tangibles de l’IA. C’est à ce prix qu’elles pourront réduire les coûts, accélérer la cadence de delivery et sécuriser leurs services dans la durée.

Jean-Paul Da Cunha, Directeur technique Digital Platforms, Inetum