Aperçu gratuit Open Graph et cartes sociales

Qu'est-ce que le link unfurling et pourquoi est-ce important ?

Lorsque vous collez une URL dans Facebook, Twitter, LinkedIn, Slack, Discord, iMessage ou WhatsApp, la plateforme envoie un robot vers cette URL, lit les balises meta dans l'en-tête de la page et affiche une carte d'aperçu avec un titre, une description et une image. Cet aperçu s'appelle un unfurl, une carte de lien ou une carte sociale selon la plateforme. C'est la première chose que chaque visiteur voit avant de décider de cliquer. Une carte bien rendue améliore considérablement le taux de clics par rapport à un simple lien bleu, et une carte cassée tue l'engagement.

Le système repose sur le protocole Open Graph, que Facebook a publié en 2010 pour donner aux plateformes de partage un moyen standardisé d'extraire un aperçu propre. Open Graph définit un espace de noms de balises meta préfixées par og: — og:title, og:description, og:image, og:url, og:type, et une longue liste de champs optionnels pour la vidéo, l'audio, les articles et les produits. Twitter a construit son propre protocole Twitter Card par-dessus en 2012, avec un espace de noms twitter: qui remplace Open Graph lorsque les deux sont présents. LinkedIn, Slack, Discord et la plupart des applications de messagerie lisent directement Open Graph et y ajoutent leurs propres particularités.

Chaque plateforme applique sa propre logique de rendu. Facebook et LinkedIn affichent une image hero avec le titre et la description en dessous, occupant environ quatre lignes dans le fil. La carte summary_large_image de Twitter affiche une grande image hero avec le nom d'hôte de l'URL en dessous. Slack affiche une pièce jointe compacte avec une petite vignette inline. Discord affiche une carte qui intègre toute vidéo ou tout élément audio lorsque le type est défini. iMessage affiche une carte en format vertical avec une image carrée. Le même ensemble de balises meta les alimente toutes, mais le résultat visuel varie suffisamment pour que prévisualiser sur chaque surface séparément soit la seule façon de détecter les problèmes.

Le coût d'un unfurl cassé est réel. Un tweet de campagne sans image obtient une fraction de l'engagement de celui avec une carte. Un post LinkedIn qui affiche une icône globe générique au lieu de l'image hero de l'article paraît inachevé. Un canal Slack où un lien affiche une image en erreur 404 sape la confiance dans le lien lui-même. Aucun de ces problèmes n'est catastrophique isolément, mais pour une équipe marketing ou éditoriale qui publie des dizaines de liens par semaine, la perte cumulée est significative.

Comment utiliser cet outil de prévisualisation

Le prévisualiseur affiche une URL sur toutes les principales plateformes en même temps, vous permettant de repérer les problèmes spécifiques à chaque plateforme sans tester chacune séparément.

Étape 1 — Collez votre URL. Déposez une URL complète dans le champ. Le robot récupère la page, lit l'en-tête et extrait toutes les balises Open Graph et Twitter Card pertinentes. Si la page nécessite une authentification ou est derrière le défi bot de Cloudflare, la récupération échoue et le prévisualiseur affiche l'erreur afin que vous sachiez que l'unfurl échouera également sur les vraies plateformes.

Étape 2 — Examinez les cinq cartes de plateforme. Facebook, LinkedIn, Twitter, Slack et Discord s'affichent côte à côte. Recherchez les images manquantes, le texte tronqué et les recadrages de ratio qui coupent votre image hero. Le prévisualiseur signale les balises obligatoires manquantes en rouge et les dimensions sous-optimales en orange.

Étape 3 — Modifiez et prévisualisez à nouveau. Mettez à jour vos balises meta dans la page source et cliquez sur Actualiser. Le prévisualiseur récupère une copie fraîche sans cache, vous voyez donc immédiatement le nouvel état. Une fois que l'affichage est correct ici, les partages en direct sur les plateformes réelles correspondront — à condition que vous pensiez à invalider les caches de Facebook et LinkedIn après la mise à jour.

Particularités de rendu par plateforme

Les mêmes balises meta produisent des cartes différentes selon les plateformes, car chacune possède son propre moteur de rendu. Connaître ces différences permet de gagner du temps lorsque quelque chose s'affiche mal sur une plateforme mais correctement sur les autres.

Facebook

Facebook lit og:title, og:description, og:image et og:url et affiche une carte hero avec l'image en haut, le titre en gras en dessous, la description en gris et le domaine hôte en petites capitales en bas. L'image est recadrée à un ratio 1,91:1 si elle ne correspond pas. Facebook met le résultat en cache de manière agressive — la première fois qu'une URL est partagée, le robot extrait les balises, et les partages suivants réutilisent la carte mise en cache pendant des heures ou des jours. Pour actualiser, collez l'URL dans le Sharing Debugger et cliquez sur Scrape Again. Il n'existe pas d'autre moyen fiable d'invalider le cache. Le robot Open Graph s'identifie avec l'agent utilisateur facebookexternalhit.

Twitter

Twitter lit twitter:card, twitter:title, twitter:description, twitter:image et twitter:site en premier, se rabattant sur les équivalents og: lorsque la balise twitter: est absente. La valeur de twitter:card détermine le choix de mise en page : summary produit une petite vignette carrée à gauche du titre et de la description, occupant environ un tweet de hauteur verticale ; summary_large_image produit une grande image hero au-dessus du titre avec le nom d'hôte de l'URL en dessous, doublant l'espace visuel. La validation des Twitter Cards a été déplacée dans Twitter Ads en 2022, donc le Card Validator autonome a disparu, mais la plateforme respecte toujours le protocole exactement comme avant.

LinkedIn

LinkedIn lit Open Graph de manière identique à Facebook et affiche une carte hero similaire. Le robot s'appelle LinkedInBot, et il met les résultats en cache pendant environ sept jours, sauf si vous invalidez via le Post Inspector sur linkedin.com/post-inspector. LinkedIn exige que og:image fasse au moins 1200 par 627 pixels (notez la borne inférieure légèrement différente) et pèse moins de 5 Mo. Les images servies en HTTP sont silencieusement ignorées. LinkedIn ignore également les indicateurs og:image:width et og:image:height lors de la validation, donc testez toujours avec une vraie récupération.

Slack

Slack lit Open Graph mais affiche par défaut une pièce jointe plus compacte. og:title devient le titre du lien, og:description devient le corps, et og:image devient une petite vignette inline sur le côté. Les espaces de travail peuvent configurer le comportement des unfurls par canal et par application, ce qui signifie que le même lien peut apparaître comme une carte complète dans un canal et comme une URL en texte brut dans un autre. Slack déduplique également les unfurls dans une courte fenêtre temporelle, donc recoller la même URL après avoir modifié des balises meta affiche souvent la version mise en cache. Les comptes bot et les webhooks entrants ont des paramètres d'unfurl séparés qui peuvent nécessiter une activation explicite.

Discord

Discord affiche les cartes Open Graph comme des embeds dans le message, avec l'image rendue inline comme une hero. Il respecte également og:video et intègre des lecteurs vidéo directement lorsqu'ils sont présents, ce qui fait de Discord l'une des rares plateformes grand public où les balises Open Graph vidéo sont utiles. Les couleurs des cartes proviennent de theme-color dans l'en-tête meta lorsqu'aucune autre couleur n'est spécifiée. Le robot s'appelle Discordbot, et contrairement à Facebook ou LinkedIn, Discord ne met pas en cache de manière agressive — la plupart des modifications se reflètent en quelques minutes.

Exigences de taille d'image par plateforme

La raison la plus fréquente pour laquelle une carte rétrograde vers une vignette ou ne s'affiche pas est l'image. Chaque plateforme a ses propres dimensions préférées et tailles minimales.

Facebook et LinkedIn préfèrent 1200 par 630 pixels avec un ratio 1,91:1. Les deux afficheront une carte avec des images jusqu'à 600 pixels sur le grand côté, mais rétrogradent vers une petite vignette en dessous de ce seuil. La taille du fichier doit rester sous 5 Mo. PNG et JPG fonctionnent tous les deux ; WebP est supporté par Facebook mais pas de manière cohérente par LinkedIn, utilisez donc PNG ou JPG pour og:image.

Twitter préfère 1200 par 675 pixels pour summary_large_image, un ratio 16:9 légèrement plus large. Le minimum est 300 par 157, mais tout ce qui est inférieur à 600 pixels de large produit une dégradation de qualité visible. Pour les cartes summary, l'image est carrée et recadrée à 144 par 144 dans le fil ; concevez en veillant à ce que le centre de l'image porte le sens.

Slack accepte presque n'importe quelle taille et réduit l'image pour l'adapter à une petite vignette. La vignette fait environ 80 par 80 pixels dans le rendu latéral. Les détails d'une image de 1200 pixels de large sont perdus dans cette mise en page, mais la même image fonctionne bien car Slack réduit plutôt que recadre.

Discord affiche l'image en entier inline jusqu'à la plus grande dimension que la surface de chat supporte, généralement jusqu'à 1280 pixels de large sur ordinateur. Les images plus grandes sont réduites en préservant la qualité. Discord recadre les images très hautes à un ratio d'aspect maximum, donc évitez les images en format portrait pour les cartes hero.

Les balises og:image:width et og:image:height sont des indications de dimensions que les robots utilisent pour réserver l'espace de mise en page avant la fin du chargement de l'image. Elles ne modifient pas l'image, mais aident l'aperçu à s'afficher sans décalage de mise en page. Incluez-les toujours lorsqu'elles sont stables, et utilisez les dimensions réelles en pixels du fichier que vous servez.

Erreurs courantes qui nuisent au partage

URL og:image relatives. Open Graph et Twitter Card exigent tous deux des URL absolues. Un chemin comme /og.png est silencieusement rejeté par toutes les plateformes majeures. Utilisez toujours la forme complète https://example.com/og.png.

og:image en HTTP sur une page HTTPS. Mélanger des URL d'images en HTTP dans une page HTTPS amène la plupart des plateformes à ignorer l'image. La carte rétrograde vers une vignette ou s'affiche sans image. Toutes les URL Open Graph doivent être en HTTPS indépendamment du protocole de la page.

og:image:width et og:image:height manquants. Sans indicateurs de dimensions, les robots attendent que l'image se charge avant de décider de la mise en page de la carte. Sur les hébergeurs d'images lents, la plateforme expire et se rabat sur une carte plus petite. Incluez toujours les indicateurs lorsque vous servez une image de taille connue.

og:image identique sur des milliers de pages. Une image partagée unique fonctionne pour la page d'accueil mais rend chaque article identique lors du partage. Les images OG dynamiques générées par template côté serveur à partir du titre et d'un arrière-plan donnent à chaque page une carte distinctive sans travail manuel.

Oublier d'actualiser le cache de Facebook après les modifications. Les modifications apportées après qu'une URL a déjà été partagée sont invisibles jusqu'à ce que vous la rescrapiez via le Sharing Debugger. Les équipes qui mettent à jour les balises meta sans invalider le cache pensent souvent que leurs modifications n'ont pas fonctionné, alors qu'en réalité les plateformes affichent les anciennes versions mises en cache.

Mauvaise valeur de twitter:card. Définir summary alors que vous avez une image hero de 1200 pixels de large produit une petite carte vignette, gâchant l'asset. Définir summary_large_image sans une vraie grande image produit une carte avec un espace vide là où la hero devrait être. Faites correspondre le type de carte à la taille de l'image que vous servez.

Description copiée mot pour mot du corps de la page. Un premier paragraphe tronqué comme og:description convainc rarement de cliquer. Les aperçus de partage sont du texte de vente en 200 caractères ; traitez-les comme tels et rédigez une description qui met en valeur le lien, plutôt que de résumer la page.

Cas particuliers que personne ne mentionne

Les robots Open Graph voient une version différente de votre page de celle que voient les navigateurs. Ils n'exécutent généralement pas JavaScript, ne stockent pas de cookies et expirent plus rapidement qu'une récupération normale. Les applications monopage qui injectent des balises meta côté client via React Helmet ou document.head produisent des cartes vides parce que le robot lit le HTML rendu initialement par le serveur avant l'exécution de tout JS. La solution consiste à rendre les balises meta côté serveur via les métadonnées Next.js, useHead de Nuxt, ou équivalent. Certaines configurations de CDN bloquent également les agents utilisateurs de robots à la périphérie, renvoyant un 403 à facebookexternalhit tout en servant normalement les humains — un bug invisible jusqu'à ce que quelqu'un partage le lien et que la carte ne s'affiche pas.