Bynder écrit que son extension WordPress fonctionne en l’état avec l’éditeur Gutenberg. Si vos pages se construisent dans Elementor, cette extension y ouvre la sélection d’assets Bynder, et inscrit dans WordPress ce qu’il faut pour que le visuel s’y comporte comme un média WordPress.
Poser une URL de DAM dans un widget Elementor prend dix secondes et coûte cher : l’image perd son srcset, ses dimensions et sa visionneuse, et son texte alternatif cesse d’être relié au référentiel média. Non par défaut de configuration, mais parce que WordPress indexe ses médias par identifiant d’enregistrement, jamais par URL.
L’asset part du DAM, arrive dans le CMS, et se pose dans l’éditeur — en gardant son identifiant.
Bynder décrit ainsi son extension WordPress :
« Out of the box, the WordPress plugin only works with the Gutenberg Editor. The open-source version of the WordPress plugin allows you to make changes to the plugin itself and potentially make it work with other plugins, such as other editors. »
Elementor est un autre éditeur. Cette extension est l’adaptation dont parle cette phrase, et le travail se situe exactement là où l’on ne l’attend pas : pas dans l’appel d’API, mais dans ce qu’Elementor fait de ce qu’on lui donne.
Le constat n’a rien de particulier à un éditeur : plusieurs connecteurs DAM pour WordPress annoncent Gutenberg comme l’éditeur pris en charge, et renvoient les constructeurs de pages à une adaptation. C’est une caractéristique de la façon dont ces connecteurs sont bâtis, pas le défaut de l’un d’eux.
Dans WordPress, un média n’est pas un fichier : c’est un enregistrement. Le type de contenu s’appelle « attachment », le chemin du fichier vit dans la métadonnée _wp_attached_file, et les dérivés générés au dépôt vivent dans le tableau sizes de _wp_attachment_metadata. Toute la chaîne des images adaptatives part de là : wp_get_attachment_image_srcset appelle wp_get_attachment_image_src, qui appelle wp_get_attachment_metadata. Chaque maillon exige l’identifiant d’attachement, et retourne faux sans lui. Un DAM, de son côté, indexe par son propre identifiant et livre des URL de dérivés : les deux référentiels ne se rejoignent nulle part tout seuls.
Elementor n’écrit pas son contenu dans post_content : il sérialise l’arbre entier de la page en JSON, dans la métadonnée _elementor_data. Son contrôle média y stocke nativement le triplet url, id, size — la place pour un identifiant existe donc déjà. Au rendu, Group_Control_Image_Size ne teste pas seulement cet identifiant : il vérifie aussi que la taille demandée figure parmi les tailles enregistrées par WordPress. Les deux réunies, Elementor délègue à wp_get_attachment_image et ajoute la classe wp-image suivie du numéro. Il en manque une — et la taille « Custom » offerte par le panneau n’est pas une taille enregistrée — et il compose lui-même une balise img avec src, alt et chargement différé, rien de plus. L’identifiant est donc nécessaire, pas suffisant.
Le rattrapage du cœur ne rattrape rien. Sur une page qui passe par the_content, WordPress repasse sur le contenu avec wp_filter_content_tags, accroché en priorité 12, donc après l’insertion d’Elementor en priorité 9 : le HTML traverse bien le filet. Mais ce filet cherche l’identifiant dans la classe wp-image, par expression régulière — précisément la classe que la branche sans identifiant n’écrit jamais. Le filet existe, passe au bon moment, et ne trouve rien à quoi se raccrocher. La question n’est donc pas quelle URL servir, mais si l’identifiant survit jusqu’au rendu.
La dépendance ne s’arrête pas au widget Image : la résolution d’une taille pour une image de fond de section ou de conteneur passe par le même contrôle, et n’aboutit qu’en présence d’un identifiant.
Chacune découle d’une contrainte établie plus haut, pas d’une liste de fonctionnalités. C’est ce qui les rend vérifiables : si une décision est mauvaise, la contrainte qui la justifie est publiée juste au-dessus.
La sélection se fait depuis l’éditeur, à travers le composant de sélection d’assets de Bynder, sans quitter la page en construction. Elementor documente l’enregistrement de contrôles tiers : le sélecteur est un contrôle de plein exercice, pas une greffe sur le contrôle natif.
C’est l’engagement central : partout où le visuel doit se comporter comme un média WordPress, un identifiant d’attachement existe — et avec lui le srcset, les tailles enregistrées, le texte alternatif relié au référentiel et la visionneuse. Là où la fraîcheur prime sur ces garanties, le mode référencé reste ouvert : c’est l’arbitrage décrit juste après.
L’arbitrage ne se tranche pas une fois pour toutes. L’extension officielle de Bynder le montre elle-même : elle référence l’asset sur un bloc d’image, mais télécharge réellement le fichier pour l’image à la une, parce que l’API d’image à la une de WordPress exige un identifiant. La même distinction s’applique ici.
Bynder livre à la sélection l’ensemble des URL de dérivés disponibles, et documente que son composant retient par défaut le dérivé « webimage » pour les images. Quel dérivé sert quelle taille est une décision à prendre, et elle se prend une fois, à la configuration.
Le texte alternatif venu du DAM est écrit dans la métadonnée que WordPress interroge, et non dans le seul réglage du widget. La nuance décide de ce qui suit : sans identifiant d’attachement, WordPress ne cherche le texte alternatif nulle part ailleurs que dans le réglage lui-même.
Bynder documente le passage du format /m/ au format /asset/ comme réponse par défaut de ses API depuis la semaine du 30 mars 2026, les liens historiques restant fonctionnels. Une extension qui reconnaîtrait ses propres visuels à la forme de leur adresse aurait vieilli ce jour-là.
Les mécanismes de réécriture d’URL conçus pour WordPress s’appliquent aux filtres de the_content. Le contenu d’une page Elementor vit ailleurs, en JSON dans une métadonnée : ce qui couvre l’un ne couvre pas mécaniquement l’autre, et cela se traite explicitement plutôt que de se découvrir en production.
Les décisions ci-dessus expliquent pourquoi l’extension est bâtie ainsi. Voici ce qu’elle fait une fois installée.
Des widgets Elementor dédiés à l’image, à la vidéo et à la galerie, et un bouton de sélection ajouté au widget Image d’Elementor comme au bloc image de l’éditeur WordPress. On choisit un asset sans changer d’outil, et les contrôles natifs — tailles, légende, lien, visionneuse, style — continuent de fonctionner.
La fenêtre média de WordPress reçoit un onglet « depuis Bynder ». L’asset retenu devient un média manipulable par le reste du site — image à la une, blocs, autres extensions — sans que le fichier soit recopié dans la médiathèque.
Un moteur de migration déplace une médiathèque existante vers le DAM et réécrit le site pour qu’il pointe vers lui. Essai à blanc d’abord, traitement par lots que l’on peut interrompre et reprendre, état d’origine relevé avant chaque écriture, et retour arrière complet. Rien n’est supprimé.
L’activation se fait par site, et les droits obtenus sont signés puis vérifiés localement : une valeur modifiée en base invalide, elle ne débloque jamais. Une coupure du serveur de licences laisse le site fonctionner pendant une période de grâce, et les mises à jour arrivent dans l’écran de mise à jour habituel de WordPress.
Des points d’extension documentés permettent d’adapter le comportement — quel dérivé sert quelle taille, quels widgets reçoivent le bouton, ce qui entre dans une migration — depuis un thème enfant ou une extension maison, donc sans toucher au code livré et sans perdre l’adaptation à la mise à jour suivante. Interface complète en français et en anglais.
Coller une URL fonctionne : l’image s’affiche. Ce qui disparaît est moins visible. Sans identifiant d’attachement, Elementor compose une balise sans srcset, sans sizes, sans largeur ni hauteur, et sans la classe d’ancrage sur laquelle WordPress revient ensuite pour compléter le HTML. Le navigateur télécharge alors la même image pour un téléphone et pour un écran large, et ne reçoit pas dans la balise les dimensions qui lui permettraient d’en réserver la place. C’est exactement le travail que fait cette extension : garder l’identifiant, pour que la branche complète soit prise.
Cela dépend du mode retenu pour cette surface, et c’est une décision à prendre à la configuration plutôt qu’à découvrir après. Un visuel référencé suit son asset ; un visuel importé dans la médiathèque est une copie, et une copie ne se met pas à jour toute seule. Bynder documente par ailleurs une durée d’expiration de cache de son CDN : même en mode référencé, la propagation n’est pas instantanée.
La question mérite d’être posée avant l’achat, pas après. Les visuels importés dans la médiathèque restent : ce sont des attachements WordPress ordinaires. Les visuels référencés dépendent, eux, de l’URL du DAM. C’est l’argument principal en faveur du mode importé sur les surfaces critiques, et l’argument principal en faveur du mode référencé partout où la fraîcheur prime : les deux se défendent, et le choix se fait par surface.
Cela dépend de la voie d’intégration. Elementor documente l’enregistrement de widgets et de contrôles tiers dans sa version de base. En revanche, sa documentation développeur écrit que « the basic version of Elementor does not support active dynamic tags. They are a feature of Elementor Pro » : une intégration qui reposerait exclusivement sur les Dynamic Tags hériterait de cette condition. C’est un point à trancher au regard de votre installation, et je préfère le dire avant.
Non, et les deux ne s’adressent pas au même éditeur. Bynder publie son extension et documente qu’elle fonctionne avec l’éditeur Gutenberg, l’adaptation à d’autres éditeurs passant par sa version open source. Si vous construisez vos pages avec Gutenberg, l’extension de l’éditeur est la première chose à évaluer. Cette extension-ci s’adresse aux sites dont les pages sont construites avec Elementor.
Cela se vérifie plutôt que cela ne se promet. Une installation qui dispose déjà d’une source de médias externe — un autre DAM, un déport vers un stockage objet — fait cohabiter plusieurs extensions sur les mêmes points d’accroche de WordPress et d’Elementor, et ce genre de conflit ne se déduit pas d’une fiche produit. Si c’est votre cas, dites-le au moment de l’essai : cela se constate en quelques minutes sur votre installation, et c’est bien plus tôt que de le découvrir en production.
Ceux qui sont servis sur le site public, oui, et leurs dérivés avec eux : Bynder documente que marquer un asset public ne rend pas ses dérivés publics, et que son composant de sélection a besoin des deux. Ce n’est pas une contrainte de l’extension, c’est le modèle de diffusion du DAM, et il vaut mieux le vérifier sur votre portail avant que pendant.
Dites-moi comment vos pages sont construites et où vivent vos visuels aujourd’hui : le premier échange sert à vérifier que votre portail et votre installation permettent ce dont vous avez besoin, avant toute question de conditions.
Chaque affirmation technique de cette page vient d’une de ces sources, consultées le 30 août 2026. Elles décrivent deux logiciels qui évoluent : si vous lisez cette page longtemps après cette date, vérifiez avant de vous en servir.
Bynder, WordPress et Elementor sont des marques de leurs titulaires respectifs. Elles désignent ici les logiciels avec lesquels l’extension fonctionne : aucune affiliation ni aucun partenariat n’est revendiqué. Pages de marque : Bynder — presse et médias · WordPress — logos · Elementor — logos