Points clés à retenir
- Listez les besoins en matière de gouvernance, de recherche de ressources, d’approbation, de portail et de droits avant d’évaluer un DAM.
- Listez les besoins en matière de téléversement, de transformation, de formats, d’automatisation et de stockage avant d’évaluer une API de traitement.
- Prenez en compte l’intégration et la responsabilité du cycle de vie lorsque les deux ensembles de besoins doivent être couverts.
Une comparaison avec Bynder ne devient utile qu’après avoir distingué la gestion des ressources de l’exécution des traitements multimédias. Les produits peuvent participer à un même flux de travail tout en servant des utilisateurs différents et en étant responsables d’états différents.
L’essentiel
- Évitez de dupliquer les métadonnées ou l’état d’approbation dans le système de traitement.
Partir des utilisateurs et des décisions, pas du chevauchement des fonctionnalités
Bynder est conçu pour les personnes qui organisent, gouvernent, approuvent, recherchent et distribuent du contenu de marque. Ces activités nécessitent une bibliothèque de ressources, une taxonomie, des autorisations, des portails et des contrôles du cycle de vie. Transloadit est conçu pour exécuter des flux de travail programmables sur les fichiers. L’emploi de termes similaires, comme transformation ou rendu, ne rend pas les produits équivalents.
Interrogez séparément les documentalistes responsables des ressources, les équipes marketing, les designers, les développeurs et les équipes d’exploitation. Un responsable marketing peut avoir besoin de s’assurer qu’une image est approuvée pour une région, tandis qu’un développeur peut avoir besoin de trois dimensions de sortie précises et de noms de fichiers déterministes. Le premier besoin relève de la gouvernance du DAM. Le second peut relever d’un flux de travail de traitement, à condition de pouvoir toujours relier le résultat à la source approuvée.
Décision du DAM
Quelle ressource est approuvée, peut être trouvée et partagée, et est autorisée pour un usage donné.
Décision de traitement
Comment les octets de la source approuvée doivent être validés, transformés, nommés et exportés.
Décision de diffusion
Où les fichiers prêts pour un canal sont servis et comment fonctionnent l’accès, la mise en cache et le remplacement.
Choisir un DAM, un service de traitement ou une combinaison aux responsabilités délimitées
Utilisez Bynder lorsque le problème central est la gouvernance des ressources de marque et la mise à disposition d’une bibliothèque utilisable par les équipes non techniques. Utilisez Transloadit lorsqu’une application possède déjà ses propres enregistrements et a besoin d’une réception pilotée par API, de Steps de transformation reliés entre eux, d’une extraction de métadonnées et d’un export vers le stockage choisi. Transloadit ne fournit ni le catalogue, ni le portail, ni les fonctions de création à partir de modèles, ni l’expérience d’approbation de Bynder.
Utilisez les deux lorsque l’organisation a besoin de sources soumises à une gouvernance et de résultats techniques que Bynder ne devrait pas produire ou diffuser lui-même. Un événement d’approbation de la source constitue un point de passage courant entre les systèmes. L’intégration envoie cette version exacte dans un flux de travail de traitement, puis réinscrit les métadonnées des dérivés dans le système d’origine ou exporte les résultats vers un stockage propre au canal. Aucun des deux systèmes ne devrait dupliquer l’état d’approbation de l’autre.
Éviter le dédoublement des responsabilités de transformation
Les préréglages de rendu du DAM et les Templates de traitement externes peuvent se chevaucher. Si les deux redimensionnent la même source indépendamment, de petites différences de recadrage, de gestion des couleurs, de qualité ou de métadonnées peuvent produire des ressources de marque incohérentes. Attribuez un seul responsable à chaque politique de dérivé nommé et documentez ses entrées, ses dimensions, son format, sa qualité, ses règles de nommage et sa destination.
Versionnez la politique chaque fois que le comportement de génération des résultats change. Les dérivés existants peuvent rester liés à l’ancienne politique, être régénérés délibérément ou expirer selon une règle de cycle de vie. Ne redéfinissez pas silencieusement un résultat en conservant la même étiquette de version. Un registre clair des politiques rend l’assistance et la vérification visuelle plus fiables qu’un ensemble de préréglages aux noms similaires répartis entre les systèmes.
Un dérivé, un responsable
Un seul système devrait mettre en œuvre la recette de référence pour un résultat nommé.
Politique versionnée
Toute modification substantielle du traitement donne lieu à une nouvelle version du flux de travail, qui peut être auditée et faire l’objet d’un retour à la version précédente.
Données de test de référence
Des sources représentatives et des propriétés attendues permettent de couvrir les régressions lorsque la recette change.
Modéliser l’identité pour les consommateurs de ressources courantes et de versions immuables
Certains consommateurs veulent la dernière ressource approuvée. Un portail de marque ou une présentation interne peut volontairement suivre les remplacements. D’autres consommateurs, comme une version compilée et publiée d’une application ou un document réglementé, ont besoin de reproductibilité. Ils devraient référencer la version exacte de la source et du dérivé. Prenez explicitement en charge ces deux sémantiques au lieu de faire en sorte que chaque URL combine ces comportements.
Transmettez l’identifiant de la ressource Bynder, la version de la source et la version de la politique de traitement à travers chaque tâche. Enregistrez l’identifiant de l’Assembly Transloadit et l’identité de l’objet exporté avec le résultat. Les dossiers et les noms de fichiers peuvent changer pour des raisons d’organisation ; ils ne devraient donc pas constituer le seul lien. Lorsque l’approbation change, l’intégration peut identifier les dérivés concernés sans devoir les déduire des chemins.
Prévoir les pics, les limites et la fin asynchrone des traitements
Une migration volumineuse ou l’approbation d’une campagne peut créer un pic bien supérieur au trafic habituel. Faites passer les événements par une file d’attente persistante, plafonnez la concurrence et appliquez une temporisation progressive lorsque l’un ou l’autre système limite les requêtes. Préservez la possibilité de retenter la récupération de la source et l’export vers la destination en cas d’échec. L’échec d’un élément ne devrait pas bloquer les ressources sans rapport ni imposer le redémarrage du lot entier.
Les Assemblies Transloadit exécutent de manière asynchrone des Steps reliés entre eux, et les branches indépendantes peuvent se terminer dans des ordres différents. Utilisez une notification de fin vérifiée ou une vérification d’état, puis réconciliez tous les résultats requis avant de marquer la tâche de l’application comme prête. Les gestionnaires doivent accepter les notifications dupliquées et rejeter les notifications de fin périmées provenant d’une ancienne version de la source.
Longueur de la file d’attente
Indique si les approbations ou les lots de migration arrivent plus vite qu’ils ne peuvent être traités.
Ancienneté de la tâche la plus ancienne
Révèle un délai visible par l’utilisateur qu’une mesure du débit moyen peut masquer.
Nombre de nouvelles tentatives
Aide à distinguer les limites transitoires des échecs persistants liés aux informations d’identification, à la politique ou aux entrées.
Écart de réconciliation
Mesure le nombre de versions approuvées auxquelles manquent les dérivés courants attendus.
Maintenir la gouvernance et la sécurité dans les systèmes qui en sont responsables
Bynder devrait rester le système de référence pour les autorisations, l’approbation, les droits et la conservation lorsqu’il fait office de DAM. L’intégration ne devrait recevoir que les informations nécessaires à son travail. Évitez de copier une taxonomie confidentielle, des informations personnelles ou des URL sources sans restriction d’accès dans les journaux et les rappels. Les fichiers dérivés doivent hériter d’une politique d’accès délibérément définie au lieu de devenir publics simplement parce que le traitement est terminé.
Utilisez des informations d’identification pour la source et la destination qui respectent le principe du moindre privilège. Conservez les secrets d’authentification Transloadit sur des serveurs de confiance, signez les requêtes provenant de clients non fiables et utilisez des Templates enregistrés avec les remplacements de paramètres des Steps désactivés lorsque le traitement doit rester fixe. Vérifiez les signatures des notifications avant de mettre à jour l’état. Validez les propriétés détectées des fichiers et appliquez une analyse antimalware ou une mise en quarantaine lorsque le risque lié au contenu l’exige.
Inclure les métadonnées d’accessibilité et les métadonnées éditoriales
Les dimensions des images et les codecs sont des données techniques. Les textes alternatifs, les sous-titres, les transcriptions et les instructions d’utilisation sont des ressources éditoriales. Gardez-les associés à l’enregistrement de référence et transmettez-les aux systèmes de publication avec les dérivés. Une opération de redimensionnement ne peut pas déterminer la finalité ou le contexte approprié d’une image ; les métadonnées de fichier générées ne devraient donc pas remplacer le contenu d’accessibilité vérifié par une personne.
Vérifiez par des tests que les modèles en aval conservent les textes alternatifs et que la diffusion vidéo préserve les libellés de langue et le minutage des sous-titres. Les images décoratives devraient rester explicitement marquées comme telles par l’interface qui les utilise. Les défauts d’accessibilité surviennent souvent lors du passage entre le DAM, le dérivé et le canal de publication, même lorsque toutes les opérations sur les fichiers réussissent.
Tester le flux de travail le plus risqué dans un projet pilote et chiffrer sa prise en charge
Choisissez un projet pilote avec un volume significatif, une véritable transition d’approbation et plusieurs résultats. Testez le remplacement, la révocation des droits, les événements en double, les sources manquantes, les informations d’identification expirées, les exports partiels et le retour à la version précédente. Examinez les résultats avec les utilisateurs du DAM et les développeurs. Une réponse d’API techniquement correcte ne suffit pas si les documentalistes ne peuvent pas identifier ou récupérer un dérivé dont la production a échoué.
Comparez les coûts de licence et d’administration de Bynder aux coûts d’utilisation du traitement, du stockage, du développement de l’intégration, de la supervision et de l’assistance. Si les deux systèmes sont conservés, incluez le connecteur comme un produit à maintenir, avec un responsable et des attentes de service. Si Bynder est supprimé, incluez le coût de remplacement de sa bibliothèque, de sa gouvernance, de ses portails et de ses flux de travail d’approbation au lieu de ne compter que le nouveau service de traitement.
Détails techniques à connaître
- Bynder fournit des fonctions de taxonomie, de gouvernance, de portails et de gestion du cycle de vie des ressources orientées DAM, tandis que Transloadit fournit une infrastructure programmable d’ingestion et de traitement multimédia.
- Les systèmes peuvent être reliés autour d’un événement d’approbation de la source, les résultats de transformation étant réinscrits comme dérivés dans le système d’origine ou transmis à un stockage propre à chaque canal.
- La conception de l’intégration devrait définir si Bynder ou le stockage en aval est responsable des URL publiques, de l’invalidation du cache, de la conservation des dérivés et du comportement de remplacement.
- Un préréglage de transformation du DAM et un Template de traitement externe peuvent se chevaucher ; la responsabilité devrait donc être explicite pour éviter le travail redondant et les résultats légèrement différents.
- Les limites de débit entrantes et sortantes nécessitent une mise en file d’attente et une temporisation progressive, car une migration ou un lot d’approbation volumineux peut dépasser la capacité habituelle de l’API de l’un ou l’autre système.
- Les références devraient utiliser l’identité d’une version immuable lorsque la reproductibilité exacte est importante, et l’identité de la ressource courante lorsque les consommateurs suivent volontairement les approbations ultérieures.
Une approche pratique
- 1
Interrogez séparément les documentalistes responsables des ressources, les développeurs, les équipes marketing et les équipes d’exploitation.
- 2
Créez une matrice des responsabilités et des systèmes de référence.
- 3
Prototypez le flux de travail technique au volume le plus élevé et le flux de travail de gouvernance au risque le plus élevé.
- 4
Comparez le coût total de l’architecture et la responsabilité opérationnelle plutôt que le seul nombre de fonctionnalités.
Quand Transloadit est utile
Transloadit convient aux produits et aux systèmes internes qui ont besoin d’une réception programmable des fichiers, de transformations en plusieurs étapes et d’une indépendance vis-à-vis du stockage. Il peut enrichir les flux de travail du DAM sans devenir le catalogue de ressources.
Périmètre architectural
Bynder est un DAM d’entreprise et une plateforme de contenu de marque. Transloadit ne remplace ni sa bibliothèque de ressources, ni sa gouvernance, ni son portail, ni ses fonctions de création à partir de modèles, ni son expérience d’approbation.
Questions fréquentes
Transloadit peut-il remplacer Bynder ?
Non. Transloadit peut exécuter des flux de travail de traitement de fichiers, mais ne remplace ni la bibliothèque DAM de Bynder, ni sa taxonomie, ni ses portails, ni sa gouvernance, ni ses fonctions de création à partir de modèles, ni son expérience d’approbation.
Quelle répartition pratique des responsabilités adopter pour une intégration entre Bynder et Transloadit ?
Une version précise et approuvée de la source peut déclencher une Assembly Transloadit. L’Assembly crée des dérivés contrôlés et les exporte, tandis que Bynder reste le système de référence pour l’enregistrement de la ressource et son approbation.
Comment les équipes peuvent-elles éviter les rendus contradictoires ?
Attribuez un seul responsable et une seule recette versionnée à chaque dérivé nommé. Testez cette recette avec des fichiers sources représentatifs et ne maintenez pas de préréglages légèrement différents dans les deux systèmes.
Les intégrations doivent-elles référencer la ressource courante ou une version immuable ?
Utilisez l’identité de la ressource courante lorsque les consommateurs doivent suivre les approbations ultérieures. Utilisez des versions immuables de la source et des dérivés lorsque la reproduction exacte, l’audit ou la stabilité des versions publiées est importante.
Comment encadrer les lots de migration volumineux ?
Utilisez une file d’attente persistante, une concurrence limitée, des tentatives avec temporisation progressive, des clés de tâche idempotentes et une réconciliation. Surveillez l’ancienneté des éléments en attente et les échecs persistants au lieu d’envoyer toute la bibliothèque simultanément.