DAM Headless et API

Le DAM, producteur et consommateur d’API dans un monde headless

Pour assurer sa mission de « Single Source of Truth » des médias, le DAM doit pouvoir s’intégrer avec les applications clés au sein du système d’information. Comment une architecture DAM headless et l’exposition des API étendues du DAM favorisent-elles l’intégration de la plateforme au SI de l’entreprise ?

Un DAM d’entreprise n’est pas une île isolée au sein du système d’information (SI). Au contraire, en tant que « Single Source of Truth » pour la gestion des médias, il est partie prenante de ce SI, donc fortement intégré avec ses principales applications.

Par exemple :

Vis-à-vis de ces systèmes, le DAM d’entreprise est à la fois un fournisseur et un consommateur d’informations. Son intégrabilité doit être la plus forte possible pour garantir à la fois la cohérence des contenus (notamment pour les informations des produits), leur distribution (sur les bons frontaux et canaux) ou encore leur personnalisation. Pour y parvenir, le DAM s’appuie sur deux piliers fondamentaux : le headless et les API.

Le DAM d’entreprise, nativement headless (et nous n’avons pas perdu la tête)

La notion d’architecture dite headless a émergé fin 2018. Son essor est intimement lié au besoin de servir depuis un même back office différents frontaux : sites web, app mobiles, réseaux d’écrans… Des CMS headless ont émergé pour répondre à cet enjeu de l’omnicanal. Leur caractéristique ?  Là où un CMS « classique » voit son back office couplé avec un frontal web (une interface de restitution des contenus), le CMS headless s’apparente à un back office sans frontal.  Si les contenus sont organisés et édités dans le back office, il revient aux développeurs de concevoir des frontaux capables de consommer les contenus qui y sont. À cette fin, le CMS headless vient avec un jeu d’API qui permet d’invoquer ses contenus. Un tel CMS peut donc servir différents frontaux développés avec des technologies variées.

Si la distinction entre couplé et headless fait encore sens pour les CMS, elle n’est pas utilisée en tant que telle pour une solution de Digital Asset Management. Pour une raison simple : le DAM est nativement headless puisque c’est sa mission originelle de mettre les contenus qu’il héberge à disposition de tous les canaux. Ceux que l’on connaît aujourd’hui et ceux, encore inconnus, qui s’imposeront demain. Cela implique une forte capacité à modifier les formats de ces contenus, mais également la capacité à les diffuser dans les meilleures conditions.

Attention aux raccourcis : cette intégration du DAM au sein d’une architecture headless n’est pas une affaire de disponibilité de plugin pour un CMS ou un autre. Le plugin peut sembler être, en apparence, une facilité pour explorer depuis un CMS l’arborescence des assets d’un DAM mais il ne dit rien de la capacité à vraiment mobiliser et diffuser les contenus de la solution de Digital Asset Management.

Le DAM, autant producteur que consommateur d’API

Ce qui compte ici c’est la richesse de l’API proposée par le DAM pour invoquer les « bons » contenus. Comprendre : passer au DAM les informations requises pour afficher une vidéo dans le format technique adéquat (résolution, ratio, encodage…), avec la langue utilisée, avec ou sans sous-titre, etc. C’est en offrant une telle profondeur que l’API peut réellement donner corps à ce que l’on nomme le Content as a Service (CaaS) : la capacité à mobiliser un asset avec des caractéristiques précises depuis n’importe quel point d’appel du SI.

Cette profondeur de requêtage à travers des API, le DAM en a aussi besoin vis-à-vis des applications tierces. De fait, pour servir au mieux une plateforme eCommerce par exemple, le DAM a tout intérêt à s’appuyer sur la taxonomie des produits (pour classer et/ou taguer les assets). Ce qui suppose d’être en capacité de requêter le PIM ou l’ERP pour y puiser ces informations. De même pour les informations d’audience : pour être en mesure de personnaliser le contenu pour un client logué sur une plateforme, encore faut-il que le DAM puisse récupérer des informations clés (pays, langue, historique d’achats, préférences…) auprès d’un CRM ou d’une CDP.

En d’autres termes, un DAM d’entreprise est aussi une plateforme d’intégration : un environnement qui permet d’exploiter les API mises à disposition par d’autres applications pour mieux restituer ses contenus à travers… ses propres API. Un producteur et un consommateur d’API au sein d’architectures de contenus qui adoptent de plus en plus le modèle headless. Avec un objectif à l’horizon : capitaliser sur les contenus pour mieux répondre aux enjeux d’une relation prospect et client omnicanal.

Découvrez pourquoi investir dans une solution de Digital Asset Management.


efficitur. massa venenatis, elit. consequat. commodo Praesent id ipsum