Fonctionnalités d’un DAM polyvalent

La façon dont un DAM met l’ensemble de ses ressources à disposition des consommateurs (utilisateurs ou programmes) revêt beaucoup d’importance, selon la nature des domaines à servir. Lire la suite…

Comme la DAM Foundation l’explique dans son article, un système DAM doit réduire le temps passé par les utilisateurs pour chercher et trouver les assets et donc disposer de bons moteurs de recherche ou d’une gestion de preview optimisée.

Dans le cas d’un petit nombre d’utilisateurs et d’assets, la gestion est possible sans une solution DAM, avec un volume disque réseau ou un dossier partagé. Dès que les assets montent en volume et les utilisateurs se multiplient, une solution pour la gestion de ces actifs est désirable. Mais quelles fonctionnalités considérer en priorité ?

Les 10 caractéristiques que la DAM Foundation trouve essentielles pour une solution DAM sont pertinentes. Il nous semble cependant intéressant de faire un focus sur les 7 fonctionnalités suivantes.

Caractéristiques DAM

1. Gestion des utilisateurs, accès privé versus accès public

La plupart des solutions DAM sont accessibles depuis un browser standard. Reste la question de savoir si le site est privé ou public. S’il est public, les assets sont exposés sur le web,  et alors la qualité de l’authentification utilisateur et la sécurisation des transferts et API deviennent vraiment stratégiques. Il importe de pouvoir gérer très finement les droits, et de disposer de fonctions pour déléguer l’administration de manière maitrisée :

  • qui peut créer un utilisateur (et avec quels droits)
  • qui peut accéder à tel dossier ou collection
  • qui peut downloader (et quoi, avec quelle résolution, selon quel rythme…), uploader
  • renommer, déplacer, toucher aux classifications, à la hiérarchie des dossiers
  • éditer les métadonnées, créer des liens entre assets…

Autre point, la scalabilité et la tenue en charge : un DAM exposé au public doit être très solide, c’est-à-dire supporter n’importe quelle charge sans se planter, et donc savoir tirer profit d’une architecture cloud moderne. Il doit également produire des statistiques d’utilisation.

2. Interfaces utilisateur

Un DAM peut se présenter à l’utilisateur sous la forme d’un dossier (ex. DropBox, GoogleDrive …) ou d’un volume réseau monté (CIFS, CMIS, WEBDAV, …), voire d’une forme hybride réunissant les qualités de l’un et de l’autre. Ce type d’accès aux données est très apprécié des utilisateurs qui >produisent des assets : cela leur permet d’utiliser le DAM au travers de leurs outils métiers.

Si le DAM n’offre pas d’interface de type disque ou dossier, il n’aidera guère les utilisateurs qui produisent les assets, qui auront à downloader les assets sur lesquels ils travaillent, ce qui est contraignant et peut en outre rendre difficile la gestion des liens entres fichiers.

Pour les utilisateurs qui consomment les assets, il semble assez clair que l’idéal est d’utiliser le DAM dans un browser web, technique qui permet aujourd’hui de créer des interfaces efficientes et ergonomiques, et ne nécessitant aucune installation.

3. Upload simplifié

Les procédures d’upload doivent permettre d’accepter des fichiers en masse (zip typiquement), ainsi que le drag & drop. Il semble également important qu’un DAM accepte par défaut n’importe quelle nature de fichier (sauf peut-être une limite sur la taille maximum), et sache détecter les erreurs de signatures (MAC/WIN) vis-à-vis du contenu réel : c’est en effet à ce moment-là que le DAM analyse le contenu des fichiers pour lancer des procédures plus ou moins complexes visant à extraire ou construire les vignettes, le texte inclus pour l’indexation, les métadonnées…

Attention aux entrées massives de plusieurs utilisateurs au même moment ! Cela arrivera, et il faut que le DAM arrive à réguler sa charge, tout en répartissant ses efforts entre les utilisateurs, de manière à ce qu’un utilisateur ajoutant un simple fichier n’ait pas à attendre qu’une entrée massive soit terminée avant de le voir arriver … Ce genre de test en dit long sur la qualité de l’architecture interne d’un DAM.

4. Streaming vidéo

La capacité à assurer du streaming vidéo nativement est un plus. Un Dam peut aussi prendre en charge une notion de « publication » et alors, choisir de confier cette tâche à un serveur spécialisé, privé ou public (ex. YouTube).

5. Gestion des flux

La possibilité d’appliquer des processus (workflows de validation, de rangement, de publication…) sur les assets peut s’avérer indispensable. Par workflow, nous entendons ici la capacité par le DAM à permettre aux administrateurs de changer le comportement « par défaut » du DAM, pour pouvoir lui demander des comportements spécifiques.

Un exemple : analyse des fichiers entrés dans un dossier donné. Acceptation selon les caractéristiques du fichier (ex. taille image, résolution vidéo, présence de propriétés et/ou valeurs dans les métadonnées…), déplacement vers un autre dossier si accepté, ou refusé, ou lancement d’une tache todolist, …

6. Ouverture

Un DAM est un centre de ressources destinées à être exposées.

Tous les DAM exposent eux-mêmes leurs propres données, mais ils ne sont pas toujours pensés pour être utilisés aisément par d’autres logiciels. Un DAM doit offrir un panel d’API complet et sécurisé, pour offrir ses services auprès d’autres logiciels.

Il devrait aussi proposer des « frames », c’est-à-dire des vues que d’autres logiciels peuvent agréger dans leurs interfaces – sans programmation et de manière simple. Un DAM devrait également exposer et documenter ses CSS.

7. Gestion des versions, des doublons, des doubles noms

La gestion des versions apporte beaucoup de sécurité et de confort aux utilisateurs : quelle sécurité que de pouvoir restaurer directement dans le dossier dans lequel on se trouve la version précédente (ou la version N) d’un fichier ! De même, un audit des actions (qui a ouvert le fichier, qui l’a modifié et quand…) peut s’avérer indispensable.

Les assets ajoutés devraient décoder s’ils existent déjà (par leur contenu), afin d’éviter ou d’aider à gérer les doublons.

Les doubles noms doivent être détectés et renommés automatiquement ou être refusés (attention aux entrées massives). L’indexation doit être transparente : automatique, sans blocage pour l’utilisateur.

 


Auteur :

David Lantier, consultant J2S