Architecture sans tête et API, les 2 piliers de l'intégrabilité du DAM

Pour remplir sa mission de "source unique de vérité" pour les médias, un DAM doit pouvoir s'intégrer aux applications clés du système d'information.

‍

Un DAM d'entreprise n'est pas un îlot isolé au sein du système d'information (SI). Bien au contraire, en tant que "Source unique de vérité"pour la gestion des médias, il fait partie intégrante de ce SI et est donc fortement intégré à ses principales applications.

‍

Par exemple :

• les différentssystèmes de gestion de contenu (CMS) utilisés pour fournir du contenu aux sites et aux applications 
• Les ERP(Enterprise Resource Planning) et les PIM(Product information Management) qui contiennent des informations précieuses sur la taxonomie des produits.
• le CRM(Customer Relationship Management) et le CDP(Customer Data Platform) qui stockent les informations nécessaires à la personnalisation du contenu

Par rapport à ces systèmes, le DAM d'entreprise est à la fois fournisseur et consommateur d'informations. Son intégrabilité doit être la plus forte possible pour garantir la cohérence des contenus (notamment pour les informations produits), leur diffusion (sur les bons frontaux et canaux) et leur personnalisation. Pour ce faire, le DAM s'appuie sur deux piliers essentiels : l'architecture headless et les API.

‍

Enterprise DAM, nativement headless (et nous n'avons pas perdu la tête)

La notion d'architecture " headless " a émergé fin 2018. Son essor est étroitement lié à la nécessité de servir différentes applications frontales à partir d'un seul back-office : sites web, applications mobiles, réseaux d'écrans, etc. C'est pour répondre à cette problématique omnicanale que le headless CMS a émergé. Sa caractéristique ? Alors qu'un CMS "classique" dispose d'un back-office couplé à un frontal web (une interface de restauration de contenu), le headless CMS s'apparente à un back-office sans front-end. Alors que le contenu est stocké, organisé et publié dans le back-office, c'est aux développeurs de concevoir des frontaux capables de consommer et d'afficher ce contenu. C'est la raison pour laquelle le CMS sans tête est accompagné d'un ensemble d'API capables de présenter le contenu. Ce type de CMS peut ainsi servir différents frontaux développés à l'aide de technologies variées.

‍

Si la distinction entre couplé et headless a encore du sens pour les CMS, elle n'est pas utilisée en tant que telle pour une solution de Digital Asset Management. La raison en est simple : le DAM est nativement headless puisque sa mission première est de rendre le contenu qu'il héberge accessible à tous les canaux. Ceux que nous connaissons aujourd'hui et ceux, encore inconnus, dont nous aurons besoin demain. Cela implique une forte capacité à modifier les formats de ces contenus, mais aussi la capacité à les délivrer dans les meilleures conditions. 

‍

Attention aux raccourcis : l'intégration du DAM dans une architecture headless ne signifie pas qu'un plugin soit disponible pour un CMS ou un autre. Le plugin peut apparaître comme un moyen facile d'explorer, à partir d'un CMS, l'arborescence des actifs d'un DAM, mais il ne dit rien sur la capacité à réellement mobiliser et diffuser le contenu de la solution de Digital Asset Management.

‍

DAM, à la fois producteur et consommateur d'API

L'essentiel ici est la richesse de l'API proposée par un DAM pour invoquer le "bon" contenu. En d'autres termes : transmettre au DAM les informations nécessaires pour afficher une vidéo dans le bon format technique (résolution, ratio, encodage, etc.) avec la langue utilisée, avec ou sans sous-titres, etc. C'est en offrant une telle profondeur que l'API peut véritablement donner corps à ce que l'on appelle le Content as a Service (CaaS) : la capacité à mobiliser un actif avec des caractéristiques précises depuis n'importe quel point d'appel du SI. 

‍

Le DAM a également besoin de cette profondeur d'interrogation via les API pour les applications tierces. En fait, pour servir au mieux une plateforme de commerce électronique, par exemple, le DAM a tout intérêt à s'appuyer sur la taxonomie des produits (pour classer et/ou étiqueter les actifs). Pour cela, il faut pouvoir demander au PIM ou à l'ERP de puiser ces informations. Il en va de même pour les informations relatives à l'audience : pour pouvoir personnaliser le contenu pour un client connecté à une plateforme, le DAM doit pouvoir récupérer des informations clés (pays, langue, historique d'achat, préférences, etc.) à partir d'un CRM ou d'un CDP.

‍

En d'autres termes, un DAM d'entreprise est aussi une plateforme d'intégration : un environnement permettant d'utiliser les API mises à disposition par d'autres applications pour mieux restituer ses contenus via... ses propres API. Un producteur et un consommateur d'API au sein d'architectures de contenu qui adoptent de plus en plus le modèle headless. Avec un objectif en ligne de mire : capitaliser sur les contenus pour mieux répondre aux enjeux d'une relation prospect-client omnicanale.