• La possibilité de télécharger un seul fichier.
• Par défaut, tous les fichiers numériques téléchargés sont automatiquement convertis en ressources. Lorsqu'un utilisateur télécharge un fichier, certaines métadonnées de base (par exemple, un identifiant de ressource et d'autres paramètres par défaut configurables par l'utilisateur en fonction du type, etc.) sont associées à ce fichier.
• Fonctionnalités permettant de télécharger en masse plusieurs ressources en les regroupant dans un seul fichier compressé, puis en téléchargeant ce dernier.

• Fonctionnalité de téléchargement par glisser-déposer permettant aux utilisateurs de faire glisser un ou plusieurs fichiers depuis un dossier de leur ordinateur local ou de différents appareils.
• Dossier actif ou « surveillé » qui vérifie automatiquement la présence de fichiers à ingérer (mais non à cataloguer).
• Le nom de fichier de la ressource est conservé lorsque l’utilisateur la télécharge, mais le système gère les conflits de nommage (par exemple en stockant le nom de fichier d’origine dans la base de données avant de le renommer avec l’identifiant unique de la ressource).
• Téléchargez un fichier ZIP et conservez-le au format ZIP plutôt que de le décomposer en fichiers individuels.
• Empêchez les utilisateurs de télécharger certains types de fichiers et interdisez-leur de télécharger des logiciels malveillants (par exemple, des applications exécutables). Tout le contenu est analysé à l'aide de systèmes antivirus côté serveur avant d'être validé.

• Des connecteurs permettant de recevoir des fichiers provenant de diverses autres sources, dont au moins deux parmi les suivantes : serveur FTP/SFTP, serveur de messagerie, serveur WebDAV, Dropbox, Box, compartiment Amazon S3 (et fournisseurs de stockage cloud compatibles).
• Des fonctionnalités de téléchargement asynchrone permettant à l’utilisateur de télécharger un fichier sans avoir à attendre que le système le reçoive avant de pouvoir effectuer une autre tâche via le système DAM. Remarque : l’utilisateur ne doit pas avoir à ouvrir d’autres onglets de navigateur, etc., et doit recevoir un e-mail lorsque le téléchargement est terminé. Une application de bureau ou un agent permettant de télécharger automatiquement les fichiers et de les retélécharger de manière transparente en arrière-plan si l’utilisateur les télécharge puis les modifie.
• Des applications mobiles pour iOS/Android permettant de capturer et de télécharger de nouvelles images ou vidéos, ou de télécharger du contenu existant (par exemple, à partir des bibliothèques multimédias intégrées au système d’exploitation mobile), y compris le géomarquage avec la position GPS si l’appareil le prend en charge.
• Intégration à l’Explorateur Windows et au Finder de macOS. Les dossiers locaux sont connectés au DAM et se synchronisent de manière bidirectionnelle afin de permettre, si nécessaire, l’accès depuis l’appareil à une représentation des fichiers et dossiers correspondant à certaines parties du DAM.

• Conservation d’un identifiant unique et unifié pour l’asset principal.
• Un code ID visible par les utilisateurs finaux (de tous niveaux) et sur lequel une recherche peut être effectuée. Les utilisateurs ne doivent pas être obligés de les extraire manuellement en les lisant dans les chaînes de requête des URL ou en exportant des assets, etc.
• L’identifiant unique doit être clairement visible et facilement copiable et collable depuis les fiches d’assets.

• Possibilité de créer des identifiants uniques pour des assets numériques sans qu’une essence (c’est-à-dire un fichier ou d’autres données binaires) existe. Ces enregistrements peuvent être utilisés pour des assets numériques dits « metadata only », par exemple pour représenter des objets physiques ou lorsque les données numériques binaires seront ajoutées ultérieurement.

• Un GUID (Global Unique Identifier) pour toute version, transformation ou déclinaison d’un asset, étant entendu que chacune est également considérée comme un asset, même si elle est regroupée sous un asset source/master. Ces GUID s’ajoutent à l’ID unique de l’asset principal. Le GUID doit rester persistant dans les métadonnées lorsque l’asset est téléchargé, via les normes industrielles appropriées.

• Possibilité de créer des champs de métadonnées de différents types, notamment du texte libre et des champs contrôlés, et de leur attribuer des libellés arbitraires.
• Interface accessible permettant de modifier les valeurs de taxonomie et de mettre globalement à jour toutes les sélections des assets concernés dans le DAM.
• Possibilité de rendre les champs de métadonnées obligatoires.
• Au moins une taxonomie principale avec possibilité d’affecter les assets à un ou plusieurs de ses nœuds.
• Gestion de la taxonomie : ajout, modification et suppression de termes.
• Possibilité pour un administrateur de définir au moins un modèle de métadonnées à partir d’un ensemble de champs qu’il a lui-même définis.

• Définition des types de saisie des champs de métadonnées, notamment champs texte, zones de texte, cases à cocher, boutons radio et menus déroulants.
• Configuration de plusieurs taxonomies utilisables globalement ou pour contrôler la saisie de champs de métadonnées spécifiques.
• Import de taxonomies depuis une source de données tierce aux formats CSV, XML ou JSON.
• Possibilité de définir et configurer plusieurs modèles de métadonnées par un administrateur, par exemple pour les images, vidéos ou types d’assets arbitraires.

• Gestion des versions des taxonomies et possibilité de revenir à une version antérieure (et de mettre à jour tous les assets dans le même processus).
• Liaison dynamique d’une taxonomie à une source de données tierce en temps réel afin que les valeurs de taxonomie changent immédiatement dans le DAM lorsque des mises à jour sont effectuées.
• Modèle de métadonnées orienté classes (adaptatif) : le système doit permettre de définir des modèles ou templates de métadonnées hérités par des templates de métadonnées subsidiaires. Par exemple, un modèle « Products » peut être établi avec un ensemble de champs de base. Un modèle subsidiaire « Regional Products » hérite de « Products » puis ajoute son propre ensemble de champs. Tous ses enfants les acquièrent également. Les modifications apportées à « Products » sont propagées vers les niveaux inférieurs.
• Modèles de métadonnées pour des « objets » non-asset. Il doit être possible de créer des modèles génériques de métadonnées, avec leur propre ensemble de champs, séparés d’un asset mais pouvant être associés à un ou plusieurs assets. Par exemple, un DAM peut disposer d’un objet générique « person » avec des champs tels que nom, âge, couleur des yeux, etc., et un ou plusieurs enregistrements « person » peuvent être associés à un asset. Un DAM marketing/vente peut disposer d’un objet « sales lead » auquel sont associés les assets utilisés dans des documents de présentation commerciale. Pour prendre en charge cette fonctionnalité, les administrateurs doivent pouvoir créer eux-mêmes ces objets ; des types prédéfinis par l’éditeur ne suffisent pas. Le DAM doit offrir un contrôle complet sur la nature de ces modèles de métadonnées d’objets non-asset.
• L’héritage des métadonnées doit permettre aux sous-conteneurs ou sous-assets de remplacer ou de désactiver sélectivement les mécanismes d’héritage.
• L’héritage des métadonnées doit découler de la structure du modèle de métadonnées et le déplacement des assets doit permettre de modifier immédiatement l’héritage, sans détruire les métadonnées. Par exemple, déplacer un fichier d’une classe de métadonnées vers une autre ne doit pas supprimer le premier ensemble de métadonnées ; déplacer ensuite le fichier à nouveau doit donc restaurer les métadonnées d’origine comme prévu.

• Les utilisateurs peuvent saisir les métadonnées de chaque asset sur la base d’un modèle de métadonnées.
• Un groupe d’assets peut avoir tous ses champs de métadonnées modifiés, comme si l’utilisateur saisissait les métadonnées pour la première fois.
• Possibilité d’importer par lots les métadonnées des assets depuis un fichier CSV.
• Possibilité d’exporter par lots les métadonnées des assets au format CSV.

• Les utilisateurs peuvent sélectionner un groupe d’assets et appliquer uniformément des métadonnées à tous, qu’il s’agisse d’un seul champ ou de l’ensemble des métadonnées.
• Les métadonnées d’un groupe d’assets peuvent être ajoutées en utilisant un autre asset comme source ou modèle.
• L’utilisateur peut modifier un seul champ de métadonnées et appliquer la modification au groupe.
• Les utilisateurs disposant des droits d’upload/édition peuvent joindre à une fiche d’asset d’autres fichiers arbitraires tels que des PDF, documents ou fichiers ZIP (par exemple des guidelines de marque pour un logo). Les fichiers joints peuvent, en option, être téléchargés en même temps que l’asset dans un fichier ZIP autonome.
• Une série de noms de fichiers peut être renommée à l’aide de séquences (par exemple numériques) selon un ordre de tri choisi par l’utilisateur. Des parties des noms de fichiers peuvent être alimentées à partir d’autres champs de métadonnées choisis dans le DAM.
• Reconnaissance optique de caractères (OCR) afin de rendre lisible le contenu textuel présent dans des formats d’image raster et de l’indexer pour la recherche.
• Possibilité d’importer par lots les métadonnées au format JSON ou XML.
• Possibilité d’exporter par lots les métadonnées au format JSON ou XML.

• L’utilisateur peut choisir une sélection arbitraire de champs de métadonnées ; seules les modifications apportées à ces champs sont appliquées au lot.
• Lors de l’application de métadonnées par lots ou uniformes à un groupe d’assets, l’utilisateur peut indiquer si le groupe doit ou non être synchronisé. S’il l’est, toute modification apportée à l’un est automatiquement appliquée à tous les autres. Les utilisateurs doivent pouvoir rompre le lien et, éventuellement, limiter la synchronisation à certains champs.
• Les noms de fichiers d’un lot d’assets peuvent être renommés et ces noms seront utilisés lorsque l’utilisateur téléchargera un asset.
• Règles avancées d’ingestion automatisée permettant d’appliquer des métadonnées aux assets lors de l’upload, sur la base d’un modèle de métadonnées et de règles associées. Par exemple, si un asset correspond à un certain type de fichier et est uploadé par un utilisateur appartenant à un groupe donné, une série spécifique de métadonnées peut lui être appliquée. L’utilisateur doit également pouvoir remplacer ces règles.
• Les champs de métadonnées peuvent exister en plusieurs langues, avec potentiellement une traduction automatisée via des services locaux ou cloud.

• Gestion des versions de l’asset numérique principal avec possibilité de revenir à une version antérieure si une mise à jour ultérieure l’a remplacée.

• Gestion des versions de l’asset et de ses métadonnées.

• Possibilité de gérer indépendamment la version des données binaires ou des métadonnées d’un asset ; par exemple, les données binaires peuvent être restaurées tandis que les métadonnées restent celles de l’édition actuelle, même si elles ont été modifiées.
• Une option de restauration qui génère une nouvelle version à la suite de la restauration, afin qu’aucune mise à jour intermédiaire ne soit perdue.
• Une fonctionnalité de rollback permettant de ramener un asset à un instant donné et de supprimer les versions intermédiaires. L’utilisateur doit pouvoir choisir entre ce type de restauration et le précédent (créer une nouvelle version à partir d’une ancienne, l’ajouter à la suite sans supprimer les versions).
• Les modifications de métadonnées peuvent être fusionnées à partir de révisions en conflit afin de créer une nouvelle révision master cohérente.

• Possibilité de contrôler l’ingestion et le téléchargement des assets et d’accepter ou de refuser les demandes correspondantes.
• Possibilité d’établir plusieurs workflows d’ingestion et de téléchargement avec des règles indépendantes.

• Flexibilité permettant de définir des workflows pour un asset ou un groupe d’assets sur la base des métadonnées ou des autorisations des groupes d’utilisateurs.
• Possibilité de voir l’état des demandes de workflow d’ingestion et de téléchargement via des tableaux de bord et de générer des rapports graphiques.
• Notifications de workflow par e-mail ou alertes système (notifications dans la plateforme elle-même).
• Possibilité d’intégrer les workflows à des outils d’approbation tiers (par exemple pour la validation d’illustrations).

• Possibilité de créer plusieurs modèles de workflow utilisables dans différents scénarios.
• Approbation par lots des demandes de workflow pour les utilisateurs disposant des autorisations requises.
• Fonctionnalité de discussion permettant à plusieurs approbateurs et demandeurs d’échanger des messages à propos d’un processus de workflow pour un asset donné.
• Possibilité d’étendre le workflow pour gérer des besoins personnalisés au moyen de plug-ins, hooks ou scripts pilotés par API, sans devoir implémenter une édition personnalisée du cœur du DAM.

• Possibilité de lire les métadonnées intégrées et de permettre aux utilisateurs de les consulter.

• Fonctionnalités permettant de mapper les métadonnées intégrées vers des champs de métadonnées que l’utilisateur peut modifier, tout en les conservant dans une zone dédiée sous leur forme non modifiée.
• Possibilité d’écrire les métadonnées intégrées à nouveau dans le fichier, automatiquement et sans que l’utilisateur ait à le demander explicitement.

• Possibilité de définir le mapping des métadonnées vers différents modèles de métadonnées, afin qu’une source de métadonnées intégrées puisse être traduite vers différents champs selon son contexte.
• Possibilité d’enregistrer les métadonnées intégrées fournies à l’origine et, sur demande de l’utilisateur, de fournir l’asset avec celles-ci plutôt qu’avec les modifications ultérieures effectuées par les utilisateurs du DAM.
• Prise en charge d’autres formats de métadonnées intégrées que EXIF, IPTC ou XMP.

• Le DAM doit générer un index de toutes les métadonnées utilisées sur les assets en texte intégral et sous une forme non normalisée. Si un champ déroulant contient « Advertising Photos », c’est « Advertising Photos » qui doit être indexé, et non un identifiant numérique.
• La recherche par mots-clés doit prendre en charge les opérateurs booléens, la recherche de phrases complètes et la négation (exclusion de termes).
• La grammaire de recherche par mots-clés doit utiliser les conventions établies par les grands moteurs de recherche Internet (par exemple Google) ou disposer d’instructions clairement définies pour les utilisateurs. Il faut trouver un équilibre entre capacité de recherche et rapidité des résultats, ainsi qu’entre UI et UX.
• L’index textuel doit être régénéré automatiquement sans que les administrateurs aient à lancer cette opération.
• Outre les métadonnées des assets, l’index doit inclure les métadonnées intégrées aux assets et, pour les documents, leur contenu textuel.
• Au moins des filtres de base fondés sur le type d’asset ou le dossier doivent être pris en charge.
• Une fonctionnalité de recherche/navigation par dossier ou hiérarchie doit être prise en charge.

• La recherche par mots-clés doit suggérer automatiquement des mots-clés sur la base d’une combinaison pondérée de l’existence du terme dans les métadonnées des assets et de sa fréquence d’utilisation par les autres utilisateurs de la recherche, afin d’éviter de suggérer des termes qui ne renverraient aucun résultat et de favoriser les suggestions déjà sélectionnées par d’autres utilisateurs.
• Les utilisateurs doivent pouvoir limiter les recherches par mots-clés à certains champs uniquement, s’ils le souhaitent. Par exemple, rechercher uniquement dans un champ de description.
• Les administrateurs doivent pouvoir reconfigurer les filtres et définir des fonctions de recherche personnalisées à partir des métadonnées que leurs utilisateurs doivent pouvoir interroger. Toutes les options de métadonnées doivent être configurables via des interfaces utilisateur en point-and-click ; aucun développeur ou ingénieur système ne doit être nécessaire.
• Les contrôles de filtre doivent être définissables par l’utilisateur et basés sur des menus déroulants, boutons radio, cases à cocher, etc.
• Recherche à facettes : le DAM doit permettre aux administrateurs de configurer et définir des interfaces de recherche à facettes.
• Les administrateurs doivent pouvoir décider si des fonctionnalités ou filtres de recherche sont disponibles pour certains utilisateurs en fonction de leur appartenance à un groupe.
• Il doit être possible de combiner les stratégies de recherche, par exemple en recherchant au sein d’une catégorie ou d’une hiérarchie donnée.
• Le système de recherche doit pouvoir proposer automatiquement des champs ne relevant pas des métadonnées, tels que la taille du fichier, l’heure de création, la taille en pixels, l’orientation et les couleurs dominantes.

• Les utilisateurs doivent pouvoir exclure facultativement tout ou partie des assets de l’indexation textuelle, par exemple lorsqu’un document de 100 000 mots apparaît constamment dans les résultats parce qu’il contient de nombreux mots-clés. Cette fonctionnalité doit pouvoir être désactivée asset par asset.
• Les utilisateurs doivent pouvoir définir si les filtres sont combinés entre eux au moyen d’opérateurs booléens (AND/OR).

• Une URL unique pour chaque asset permettant d’afficher ses détails (sous réserve des autorisations).
• Une URL unique pour chaque asset permettant de le télécharger (sous réserve des autorisations).
• Possibilité de rendre un asset publiquement téléchargeable et de disposer d’une URL statique partageable.
• Des contrôles d’autorisation déterminant quels utilisateurs peuvent rendre des assets publics.
• Fonctionnalités permettant d’envoyer une lightbox/collection d’assets à un autre utilisateur.

• Une URL unique pour chaque version d’un asset.
• Possibilité de rendre publics les proxies et previews des assets ainsi que les URL correspondantes.
• Possibilité d’envoyer une lightbox/collection à un utilisateur externe qui n’a pas besoin de se connecter pour la consulter.
• Possibilité de définir des mots de passe, dates d’expiration et autres restrictions (par exemple adresse IP) afin de restreindre davantage l’accès à une collection lightbox publique.
• Fonctionnalités permettant de rendre les lightboxes/collections publiques pour tous les utilisateurs du système.
• Contrôles de workflow permettant aux administrateurs d’examiner les demandes de publication publique d’assets.
• Fonctionnalités d’autorisation permettant aux administrateurs d’activer/désactiver la publication d’assets pour des utilisateurs, rôles ou groupes.

• Possibilité de publier des assets sur des canaux de réseaux sociaux, par exemple YouTube pour la vidéo.
• Possibilité d’envoyer à un utilisateur une copie de la collection ou un lien vers l’édition de l’expéditeur, afin que les modifications effectuées soient répercutées dans ce que voit le destinataire.
• Fonctionnalités permettant de contrôler la visibilité des lightboxes/collections publiques selon l’appartenance d’un utilisateur à des groupes d’autorisation ou selon son rôle.
• Lorsqu’une lightbox/collection est envoyée à d’autres utilisateurs du système, l’expéditeur peut définir les droits d’édition afin d’autoriser certains utilisateurs à modifier la collection et d’en empêcher d’autres.
• Fonctionnalité de discussion de groupe permettant aux utilisateurs invités à consulter une lightbox/collection de laisser des commentaires à son sujet, par exemple pour discuter des images à utiliser dans un projet issu d’une séance photo.
• Prise en charge d’un Content Delivery Network (CDN) pour permettre la diffusion statique d’assets partagés à grande échelle.

• L’utilisateur peut télécharger un seul asset.

• L’utilisateur peut sélectionner plusieurs assets et les faire regrouper dans un fichier ZIP qu’il peut télécharger.
• Connecteurs permettant d’envoyer des fichiers vers diverses destinations, dont au moins deux parmi : serveur FTP/SFTP, serveur de messagerie, serveur WebDAV, Dropbox, Box, bucket Amazon S3 (et fournisseurs de stockage cloud compatibles).

• Lorsqu’un grand lot d’assets doit être assemblé dans un ZIP et que l’opération peut prendre du temps, le système doit le détecter et soit informer l’utilisateur qu’il recevra un e-mail contenant un lien vers le ZIP une fois prêt, soit augmenter dynamiquement la capacité de traitement pour répondre à la demande dans un délai raisonnable. L’utilisateur ne doit pas avoir à attendre plus de quelques secondes avant de recevoir le ZIP ou d’être informé que son traitement se fera en arrière-plan. Il ne doit pas attendre plusieurs minutes pendant la préparation du ZIP et être empêché d’effectuer d’autres tâches.
• Si un asset ZIP a été uploadé et conservé comme ZIP (sans être décomposé en fichiers composants), l’utilisateur peut voir les fichiers qu’il contient et décider éventuellement d’en télécharger un ou plusieurs.

• Redimensionner les images à une taille donnée.
• Convertir les formats d’image.

• Intégrer un workflow d’approbation au téléchargement pour les assets sélectionnés et permettre aux utilisateurs d’indiquer la raison pour laquelle ils ont besoin d’un asset.
• Configurer des options de conversion prédéfinies afin que les utilisateurs n’aient pas à les spécifier manuellement.
• Changer l’espace colorimétrique d’une image de RGB vers CMYK, et inversement.
• Recadrer une image.
• Définir des points de montage dans la timeline d’une vidéo et supprimer des sections du métrage.
• Utiliser des modèles de machine learning/IA pour suggérer un recadrage, notamment lors du traitement de lots d’images, en privilégiant les zones contenant les sujets principaux plutôt qu’un recadrage centré.

• Appliquer par lots des paramètres de conversion à un groupe d’assets, par exemple au sein d’une collection.
• Définir les autorisations déterminant quels utilisateurs peuvent accéder aux fonctionnalités de modification des assets.
• Définir des points d’origine de recadrage.
• Outils de montage avancés permettant de supprimer, assembler et réordonner des sections vidéo.

• Un champ permet à l’utilisateur de spécifier un asset lié. Le lien est visible lorsque les utilisateurs consultent les détails de l’asset et ils peuvent suivre le lien pour consulter l’asset associé, lequel possède également un lien retour vers l’asset d’origine.

• Plusieurs liens peuvent être créés vers de nombreux assets différents. L’utilisateur peut en ajouter un nombre arbitraire et les assets cibles sont tous liés entre eux.
• La nature du lien peut être décrite et un texte explicatif peut être ajouté.
• L’utilisateur peut télécharger tous les assets liés dans un fichier ZIP.

• L’administrateur peut définir plusieurs types de relations sémantiques ou autres relations ad hoc de métadonnées pouvant exister entre des assets et d’autres entités externes.

• L’utilisateur peut créer un nombre illimité de collections d’assets contenant des sélections arbitraires d’assets.
• Les utilisateurs ajoutent des assets aux collections depuis les résultats de recherche et peuvent choisir dans lesquelles de leurs collections les assets sont stockés.
• Les utilisateurs peuvent copier, supprimer ou déplacer des assets d’une collection à une autre.
• Des fonctionnalités permettent de nommer les collections et d’ajouter des notes à leur sujet, pour l’ensemble de la collection ou pour des assets individuels.
• Les collections peuvent être rendues publiques par les administrateurs, ce qui signifie qu’elles sont consultables (mais non modifiables) par tous les utilisateurs.
• Les collections peuvent être envoyées à d’autres utilisateurs.

• Les utilisateurs peuvent ajouter par lots un groupe d’assets à une collection.
• L’accès aux collections publiques peut être restreint à des groupes d’utilisateurs ou rôles spécifiques.
• Les collections peuvent être envoyées à des personnes qui ne sont pas utilisateurs du système sous forme de lien envoyé par e-mail.
• Les liens vers des collections destinées à des non-utilisateurs peuvent être protégés par mot de passe.
• Chaque collection possède une URL dédiée.
• Un PDF d’une collection peut être généré (ou une « contact sheet ») affichant les miniatures et descriptions des assets dans un format imprimable ou envoyable par e-mail.
• Les collections peuvent être générées et maintenues en définissant des critères de recherche. Elles doivent se mettre automatiquement à jour lorsque de nouveaux résultats apparaissent ou que des résultats existants ne correspondent plus à la logique de recherche utilisée.

• Deux collections ou plus peuvent être fusionnées en une seule.
• Un ensemble de résultats de recherche peut être converti en collection sans devoir les ajouter manuellement un par un.
• Une ou plusieurs collections peuvent être utilisées pour filtrer les recherches, en plus d’autres critères de filtrage.
• Une fonctionnalité de discussion est fournie pour les collections partagées afin que les personnes y ayant accès puissent commenter la collection et/ou les assets individuels qu’elle contient.
• Différents utilisateurs peuvent recevoir des droits d’accès individuels à une collection. Certains peuvent uniquement la consulter, d’autres peuvent ajouter ou retirer des assets.
• Permettre aux utilisateurs de créer en arrière-plan un ZIP d’une collection afin de le télécharger comme ensemble complet d’assets. Le ZIP doit être automatiquement mis à jour si la collection change par la suite.

• Le DAM peut créer une miniature et une preview de taille supérieure d’un asset image, dans un format à chargement rapide tel que JPEG ou PNG.
• Une preview MPEG4 d’un fichier vidéo avec des commandes de lecture permettant de lire et mettre en pause le métrage.
• Les assets abstraits sans type de fichier unique (par exemple les fichiers ZIP) utilisent une icône générique.
• Si le système ne peut pas générer de preview, cela est géré de manière élégante, par exemple avec une preview par défaut, sans revenir au placeholder d’image manquante du navigateur web.
• L’éditeur prend en charge tous les formats d’image et de vidéo courants [annexe requise].

• Plusieurs tailles de preview peuvent être générées et sélectionnées par l’utilisateur.
• Une fonction de zoom permet aux utilisateurs d’afficher les images à différents niveaux de grossissement.
• Les documents peuvent être prévisualisés (notamment PDF, Word et InDesign) sans plug-in.
• L’utilisateur peut parcourir au moins les cinq premières pages d’un document en preview.
• Une fonctionnalité de preview audio est disponible avec commandes lecture/pause.
• Les utilisateurs peuvent remplacer un fichier proxy généré par le système par un fichier de leur choix.

• Une fonctionnalité avancée de preview vidéo est proposée avec avance image par image, recul image par image, lecture au ralenti, lecture inversée et lecture accélérée.
• Différents calques d’un fichier Photoshop peuvent être prévisualisés indépendamment les uns des autres si nécessaire.
• Les utilisateurs peuvent annoter une vidéo et ajouter des commentaires à des sections clés de la timeline.
• Les utilisateurs peuvent annoter des assets image ou document.
• Intégration avec des outils d’annotation d’illustrations, pilotables par les fonctionnalités de workflow du DAM.
• Les utilisateurs peuvent parcourir toutes les pages de la preview d’un document.
• Les assets 3D peuvent être prévisualisés avec des fonctionnalités permettant de faire pivoter les modèles.
• Des previews des fichiers contenus dans un asset ZIP sont fournies afin que l’utilisateur puisse les parcourir.
• Le DAM dispose d’une capacité de plug-in permettant à des tiers d’étendre la gamme des viewers et d’ajouter la prise en charge de types qui ne sont pas proposés par l’éditeur.

• DAM multi-utilisateur, chaque utilisateur disposant d’un compte dédié.
• Possibilité d’attribuer aux utilisateurs un rôle de type lecture seule (recherche, téléchargement), édition (upload et catalogage) ou administrateur (contrôle complet).
• Groupes à un seul niveau permettant d’affecter les utilisateurs à des groupes spécifiques pouvant servir à contrôler l’accès aux assets ou à déclencher des workflows.

• Au moins deux niveaux de groupes afin de permettre leur sous-catégorisation.
• Possibilité d’attribuer aux assets un accès masqué, soumis à autorisation ou sans restriction.
• Possibilité de configurer les autorisations des assets par groupe.
• Contrôle de l’accès aux collections en fonction de l’appartenance à un groupe.
• Définition de workflows en fonction de l’appartenance à un groupe.

• Concepteur de rôles personnalisés permettant de sélectionner des fonctionnalités individuelles et de définir un groupe de rôle personnalisé, avec un nom.
• Fonctionnalités permettant de remplacer les règles de groupe pour des assets individuels.
• Hiérarchie illimitée de groupes avec propagation des autorisations vers les niveaux inférieurs.
• Intégration avec des systèmes ou protocoles d’authentification externes, notamment Active Directory ou SAML.
• Mode d’émulation utilisateur permettant à un administrateur d’endosser l’identité d’un autre utilisateur. Cette fonction doit être accessible à tous les administrateurs et ne pas être limitée aux comptes d’ingénieurs ou développeurs de l’éditeur.
• Permettre aux utilisateurs de créer en arrière-plan un ZIP d’une collection ou d’une autre référence permanente (telle qu’une URL ou un autre emplacement invariant) afin de le télécharger comme ensemble complet d’assets. La collection doit être automatiquement mise à jour lorsqu’elle change.

• Une API utilisant un protocole bien connu tel que REST ou SOAP.
• Une API protégée par un mot de passe ou une autre méthode de contrôle d’accès afin d’empêcher les accès non autorisés.
• L’API prend en charge les opérations en lecture seule : recherche, téléchargement et récupération des détails d’un asset.

• L’API prend en charge la majorité (ou la totalité) des fonctions accessibles aux utilisateurs, notamment recherche, téléchargement, récupération des détails d’assets, gestion des collections, modification des assets, modification des métadonnées, modification des taxonomies, récupération et modification des informations utilisateur, gestion des groupes d’autorisation et génération de données de reporting. Environ 80 % de toutes les fonctionnalités du système doivent être accessibles via l’API.
• L’API utilise un token plutôt qu’un mot de passe en clair pour la connexion.
• Un processus de connexion API dédié est utilisé ; il génère un token de session utilisé pour toutes les opérations autres que la connexion. Le token expire après une période donnée et peut être invalidé.
• L’API est accessible via un compte utilisateur et hérite de toutes les autorisations et appartenances aux groupes de cet utilisateur.
• L’API utilise OAuth ou un protocole similaire pour limiter l’accès à des URL d’applications prédéterminées.

• Interface API-First utilisant le protocole REST. Tout ce que l’utilisateur peut faire via l’interface doit être médié par l’API. L’éditeur doit pouvoir fournir un journal de toutes les commandes API utilisées au cours d’une session d’interaction ; celles-ci doivent être accessibles aux administrateurs.
• L’API peut être étendue par des développeurs tiers à l’aide des fonctionnalités de scripting de l’application.
• L’API prend en charge l’auto-documentation de ses propres méthodes dans un environnement développeur interactif et implémente gRPC ou d’autres standards ouverts universellement connus permettant des bindings indépendants du langage.

• Le DAM dispose d’un SDK (Software Development Kit) qui est essentiellement un wrapper de son API, implémenté dans plusieurs technologies connues telles que JavaScript, Python, Java, PHP, etc.

• L’interface utilisateur front-end peut être modifiée et étendue via la fonctionnalité de scripting de l’éditeur, permettant à des tiers de développer des contrôles d’interface personnalisés. Ceux-ci doivent être directement intégrés à l’interface elle-même et non constituer des pages externes faisant référence au DAM via des iFrames, etc.

• L’application dispose d’un modèle d’objets ouvert et documenté (ou structure similaire) permettant à des développeurs tiers d’implémenter des fonctionnalités étendant l’application au-delà de ce que les développeurs de l’éditeur avaient initialement prévu pour le DAM. Les scripts peuvent être initialisés et appelés à l’aide de contrôles d’interface personnalisés ou, au minimum, via un appel API permettant de les instancier.
• Les événements se produisant dans l’outil peuvent être publiés dans des files de messages AMQP (ou similaires), permettant une intégration synchrone avec des systèmes tiers.

• Le système conserve un enregistrement de base de toutes les connexions des utilisateurs et de la date de création des fichiers d’assets.
• Le journal d’audit conserve les données depuis le premier déploiement du système.
• Le journal d’audit est accessible aux administrateurs du système et ne nécessite pas que l’éditeur génère des rapports pour le compte des utilisateurs. Il est accessible via l’interface utilisateur classique.

• Un journal de tous les événements majeurs existe, notamment connexion, upload d’asset, édition d’asset, recherche et termes de recherche.
• Le journal d’audit peut être filtré par utilisateur spécifique.
• Le journal d’audit peut être téléchargé au format CSV.

• Le journal d’audit utilise l’architecture API-First de l’application pour enregistrer chaque interaction des utilisateurs avec le système.
• Les journaux de toutes les requêtes API peuvent être téléchargés, inspectés et rejoués.
• Tous les rapports sont générés à partir des données du journal d’audit.
• Le journal d’audit peut être résumé et filtré par utilisateur, asset, groupe d’utilisateurs ou entité de métadonnées spécifique, par exemple pour voir tous les événements liés à une catégorie particulière d’assets ou à un groupe d’utilisateurs.
• Le journal d’audit peut être téléchargé au format XML ou JSON, ainsi qu’en CSV.
• Le produit inclut des outils de visualisation de données capables de mélanger et filtrer les journaux d’audit et d’activité, avec une distribution décentralisée aux propriétaires de contenu ou aux groupes plutôt qu’une concentration sur les super-utilisateurs administratifs ou du support IT.

• Le nombre de connexions sur une période donnée.
• Le nombre de nouveaux utilisateurs sur une période donnée.
• Les assets les plus populaires selon les téléchargements, classés par ordre.
• Le nombre d’uploads sur une période donnée.
• Les termes de recherche les plus courants.

• Tous les rapports de base relatifs aux utilisateurs doivent pouvoir être filtrés par groupe d’utilisateurs ou type de rôle.
• Tous les rapports de base relatifs aux assets doivent pouvoir être filtrés par au moins un champ de métadonnées clé.
• La répartition des assets vers des applications/services tiers intégrés, tels que les réseaux sociaux ou les systèmes de gestion de contenu web.
• Le nombre d’assets approuvés pour publication dans le catalogue d’assets, pour ceux uploadés par des utilisateurs qui n’ont pas les droits de le faire.
• Le nombre d’assets approuvés pour téléchargement, lorsque la demande provient d’utilisateurs qui n’y avaient pas directement accès.
• Les rapports de gestion peuvent être planifiés et envoyés par e-mail aux administrateurs à des intervalles définis, par exemple chaque mois ou chaque semaine.

• Les résultats d’une recherche d’assets peuvent servir à définir les critères d’un rapport relatif aux assets.
• Les résultats d’une recherche d’utilisateurs peuvent servir à définir les critères d’un rapport relatif aux utilisateurs.
• Des rapports personnalisés peuvent être générés pour présenter les approbations/rejets de tout workflow concernant un asset ou un utilisateur. Les rapports peuvent être générés à partir des résultats de rejet, d’approbation ou d’autres résultats prédéfinis.

• Le DAM est intégré à au moins un composant tiers de reconnaissance d’image tel que ClarifAI, Google Vision, Amazon Rekognition ou Azure Computer Vision.
• La reconnaissance d’image par IA peut être désactivée globalement ou au cas par cas pour certains assets.

• Le système peut utiliser plusieurs composants de reconnaissance d’image et permettre à l’utilisateur de choisir lequel utiliser.
• Il peut utiliser plusieurs composants de reconnaissance d’image et n’inclure que les mots-clés identifiés par l’ensemble d’entre eux.

• Le DAM dispose d’une boucle de feedback permettant d’utiliser les faux positifs ou autres optimisations pour affiner les résultats des reconnaissances ultérieures en les contextualisant grâce à l’ajout de connaissances spécifiques au domaine.

• L’application web dispose d’un design responsive fonctionnant sur des appareils mobiles tels que téléphones et tablettes, ainsi que dans les navigateurs sur ordinateurs de bureau et portables.

• Application mobile dédiée de base pour Android et iOS permettant de parcourir les assets, d’effectuer des téléchargements et d’utiliser certaines fonctions d’administration limitées telles que les approbations.

• L’application mobile Android ou iOS fournit toutes les fonctionnalités disponibles dans l’application web ou desktop, y compris l’administration, les commandes par lots, etc.

Aucune fonctionnalité à ce niveau pour l'instant.

Aucune fonctionnalité à ce niveau pour l'instant.

Aucune fonctionnalité à ce niveau pour l'instant.