Comment générer une image de partage à la volée côté serveur ?

Un article partagé sans visuel dédié se présente mal : soit le réseau reprend une image quelconque de la page, soit il n'affiche qu'un rectangle vide. Produire un visuel à la main pour chaque publication tient quelques semaines puis s'abandonne, ce qui laisse un site où les premiers articles ont une image de partage et les suivants non. La solution consiste à générer l'image de partage côté serveur, à partir du titre et de quelques éléments de gabarit, puis à la mettre en cache. Le dispositif se construit en une demi journée, il fonctionne ensuite sans intervention, et il produit un résultat homogène sur tout le site.

Ce que les réseaux attendent réellement

Avant d'écrire quoi que ce soit, il faut savoir ce qui sera effectivement affiché, sous peine de produire une image techniquement correcte et visuellement inexploitable. Les différences de traitement entre plateformes sont détaillées dans notre article sur les métadonnées Open Graph et ce que chaque réseau lit vraiment.

Une dimension de référence

Le format large de mille deux cents pixels sur six cent trente est celui que traitent correctement toutes les plateformes, avec un rapport proche de un virgule neuf. Descendre en dessous de six cents pixels de large fait basculer certains réseaux vers un affichage réduit avec une vignette carrée à gauche du titre, ce qui change complètement la présentation. Cette bascule est silencieuse et constitue la première cause d'aperçus décevants, alors même que l'image existe et que les balises sont correctes. La vérification se fait en ouvrant l'image générée et en lisant ses dimensions réelles, contrôle évident que personne ne pense à effectuer parce que la valeur déclarée dans le gabarit paraît suffire.

Le recadrage selon le contexte

La même image sera affichée en format large sur certains fils, en carré dans d'autres contextes, et parfois recadrée sur sa partie centrale. Toute information placée près des bords risque donc de disparaître. La composition doit garder une zone de sécurité généreuse et concentrer le texte au centre, règle simple qui suffit à rendre le visuel exploitable partout sans avoir à produire plusieurs variantes par contenu. Une marge de quatre vingts pixels sur chaque bord constitue un point de départ raisonnable, quitte à l'élargir si les tests montrent des coupes gênantes sur une plateforme donnée.

Le poids et le format

Les plateformes imposent un poids maximal, généralement quelques mégaoctets, très au dessus de ce que produit une image générée. Le format doit rester classique : les formats modernes de compression ne sont pas tous acceptés par les robots de prévisualisation, qui n'évoluent pas au même rythme que les navigateurs. Un format traditionnel bien compressé reste le choix sûr, et le gain de poids d'un format récent n'a de toute façon aucun intérêt sur une image chargée une fois par le robot du réseau. Cette image n'étant pas servie aux visiteurs du site, les considérations habituelles de performance ne s'y appliquent tout simplement pas.

La lisibilité sur petit écran

L'aperçu est majoritairement vu sur mobile, où l'image occupe quelques centimètres. Un titre de quinze mots y devient illisible. La composition doit donc prévoir une taille de caractères importante et une limite de longueur, avec une troncature propre au delà. C'est la contrainte qui structure le plus la conception du gabarit, et l'ignorer produit des visuels parfaits sur un écran d'ordinateur et inutilisables là où ils seront réellement vus. Le contrôle le plus honnête consiste à réduire l'image à la taille d'une vignette de téléphone et à vérifier que le titre reste lisible sans effort.

Ce que voit le robot de prévisualisation

Le robot qui récupère l'aperçu n'exécute pas les scripts, ne se connecte pas et dispose d'un délai court. Toute image produite par le navigateur lui est donc invisible, ce qui exclut d'emblée les solutions fondées sur une génération dans la page. L'image doit exister comme ressource accessible par une simple requête, servie rapidement et sans redirection multiple, faute de quoi le robot abandonne et l'aperçu reste vide. Une image protégée par une authentification, placée derrière une redirection ou servie depuis un environnement de préproduction produit exactement le même résultat, pour des raisons parfois longues à identifier.

Composer l'image côté serveur

La génération repose sur une bibliothèque de traitement d'images, disponible sur la quasi totalité des hébergements. La composition reste volontairement simple, ce qui garantit sa robustesse. La déclaration de l'image auprès des réseaux suit ensuite les mécanismes décrits dans notre article sur la manière de forcer une image de partage par article avec Yoast SEO.

Partir d'un fond fixe

Le plus simple et le plus rapide consiste à préparer un fond aux bonnes dimensions, avec le logo, un aplat de couleur et les éléments graphiques permanents, puis à n'ajouter que le texte variable. Le traitement se réduit alors à ouvrir une image, écrire dessus et enregistrer, opération qui prend quelques dizaines de millisecondes. Cette approche évite en outre les questions de rendu des éléments décoratifs, qui sont laborieuses à programmer et parfaitement triviales dans un outil graphique. Plusieurs fonds peuvent coexister, un par rubrique par exemple, ce qui apporte de la variété sans compliquer le traitement.

Choisir et charger une police

Le rendu de texte demande un fichier de police accessible sur le serveur, dans un format vectoriel classique. La police doit être choisie pour sa lisibilité en grande taille et couvrir les caractères accentués, ce qui élimine une partie des polices décoratives. Le fichier doit être déposé avec le code et non chargé depuis un service distant, la génération devant fonctionner sans accès réseau sortant, condition fréquente sur les serveurs correctement cloisonnés. Il faut également vérifier la licence de la police, toutes n'autorisant pas la diffusion du fichier avec un projet, point administratif qui se règle en amont plutôt qu'après coup.

Découper le texte en lignes

C'est la partie la plus délicate. Le texte doit être réparti sur plusieurs lignes sans couper les mots, en mesurant la largeur réelle de chaque mot avec la police et la taille choisies, et non en comptant les caractères. Un compteur de caractères produit des lignes déséquilibrées dès que le titre contient des majuscules ou des lettres étroites. La mesure réelle est fournie par la bibliothèque et rend le résultat systématiquement propre. Le nombre de lignes doit rester limité à trois ou quatre, au delà desquelles la composition perd tout impact visuel.

Adapter la taille au titre

Un titre court doit s'afficher en grand, un titre long en plus petit. Une réduction progressive de la taille tant que le texte dépasse la zone prévue résout le problème en quelques itérations et donne un rendu bien meilleur qu'une taille fixe. Il faut prévoir une taille minimale en dessous de laquelle le texte est tronqué plutôt que réduit, faute de quoi un titre exceptionnellement long produit un pavé illisible. La troncature doit se faire sur un mot entier et se terminer par des points de suspension, convention immédiatement comprise par le lecteur.

Ajouter les éléments contextuels

Le nom de la rubrique, la date ou l'auteur peuvent compléter la composition, à condition de rester secondaires visuellement. Ces éléments donnent du contexte dans un fil d'actualités où l'image est vue avant le texte. Il faut résister à la tentation d'en ajouter beaucoup : au delà de deux informations secondaires, le visuel devient chargé et perd exactement l'efficacité qu'on cherchait à obtenir en le générant. Le nom du site, lui, mérite d'y figurer systématiquement, un partage étant souvent vu par des personnes qui ne connaissent pas encore la source.

Gérer les caractères particuliers

Les guillemets typographiques, les tirets longs, les caractères non latins et les emojis peuvent ne pas exister dans la police retenue et produisent alors des rectangles vides. Un filtrage préalable, remplaçant les caractères problématiques par des équivalents ou les supprimant, évite ce défaut. Ce point paraît anecdotique jusqu'au premier titre contenant un caractère exotique, qui produit un visuel visiblement cassé et partagé tel quel. La liste des remplacements se complète au fil des cas rencontrés et tient en quelques lignes.

Servir et mettre en cache

Générer à chaque requête serait absurde, l'image ne changeant que si le titre change. Le dispositif doit donc produire un fichier une fois puis le servir comme n'importe quelle ressource statique.

Une adresse stable par contenu

L'image doit être accessible à une adresse déterministe, construite à partir de l'identifiant du contenu. Cette stabilité est indispensable puisque les réseaux mettent en cache l'aperçu de leur côté et ne reviennent pas le chercher. Une adresse changeant à chaque génération produit des partages pointant vers des fichiers disparus, avec des aperçus cassés sur les publications passées, défaut particulièrement pénible parce qu'il est irréversible. Les réseaux conservent en effet l'aperçu tel qu'il était au moment du partage, sans jamais revenir vérifier si la ressource existe encore.

Générer à la demande puis conserver

La première requête sur l'adresse déclenche la génération et l'enregistrement du fichier, les suivantes servent le fichier existant. Ce fonctionnement évite de produire des images pour des contenus jamais partagés et répartit la charge dans le temps. Il suppose seulement que la première requête reste rapide, ce qui est le cas avec une composition simple, et que le répertoire de destination soit accessible en écriture par le serveur. Un contrôle de ce droit d'écriture au démarrage, avec un message clair en cas de problème, évite de longues recherches lorsque rien ne se passe.

Invalider quand le titre change

Une modification du titre doit provoquer la régénération. Le moyen le plus simple consiste à intégrer une empreinte du titre dans le nom du fichier, ce qui produit automatiquement une nouvelle adresse. Cette solution entre toutefois en tension avec la stabilité recherchée, et le compromis raisonnable consiste à conserver l'ancien fichier tout en publiant la nouvelle adresse dans les balises, les partages passés continuant ainsi de fonctionner. Le coût de cette approche se limite à quelques fichiers orphelins, ce qui est parfaitement acceptable au regard du bénéfice.

Prévoir le nettoyage

Les fichiers s'accumulent, chacun pesant quelques dizaines de kilooctets. Sur un site publiant beaucoup, le répertoire atteint plusieurs centaines de mégaoctets en quelques années, ce qui reste modeste mais alourdit les sauvegardes. Un nettoyage périodique des fichiers correspondant à des contenus supprimés suffit, et il vaut mieux exclure ce répertoire des sauvegardes puisque son contenu est entièrement reconstructible à partir des contenus. La même logique vaut pour la synchronisation vers un environnement de test, qui n'a aucune raison de transporter ces fichiers.

Servir sans passer par le moteur du site

Une fois le fichier créé, il doit être servi directement par le serveur web, sans traverser le code applicatif. Cette configuration divise le temps de réponse par un facteur important et met le dispositif à l'abri d'une panne applicative. Elle s'obtient en écrivant le fichier dans un répertoire accessible publiquement, avec une règle de réécriture qui ne renvoie vers le générateur que si le fichier n'existe pas encore. Cette configuration en deux temps est exactement celle qu'utilisent les systèmes de génération de vignettes, et elle a fait ses preuves depuis longtemps.

Vérifier et exploiter

Le dispositif se valide en quelques minutes et mérite ensuite un contrôle occasionnel, les plateformes modifiant régulièrement leurs règles d'affichage.

Les outils de validation

Chaque grande plateforme propose un outil permettant de soumettre une adresse et de voir l'aperçu tel qu'il sera affiché. Ces outils forcent également le rafraîchissement du cache de la plateforme, ce qui est indispensable après une correction. Sans ce rafraîchissement, la plateforme continue d'afficher l'ancien aperçu, parfois pendant plusieurs semaines, et donne l'impression que la correction n'a rien changé. Il faut donc systématiquement forcer le rafraîchissement après chaque modification, et vérifier l'aperçu sur au moins deux plateformes différentes.

Tester les cas limites

La recette doit inclure un titre très court, un titre très long, un titre contenant des accents et des caractères particuliers, et un contenu sans titre. Ces quatre cas révèlent la quasi totalité des défauts de composition. Les tester avant la mise en production évite de découvrir le problème sur une publication importante, moment où la correction arrive toujours trop tard puisque le partage a déjà eu lieu. Automatiser ces quatre contrôles dans un test permet de les rejouer après chaque modification du gabarit, pour un coût de mise en place très faible.

Mesurer le temps de génération

Le temps de production de la première image doit rester en dessous de deux cents millisecondes. Au delà, le risque d'abandon par le robot devient réel, particulièrement sur les plateformes qui appliquent des délais courts. Si la composition demande davantage, il vaut mieux générer les images en tâche de fond à la publication du contenu plutôt qu'à la demande, quitte à produire quelques fichiers inutiles. Cette variante a d'ailleurs l'avantage de rendre le premier partage aussi rapide que les suivants, ce qui supprime définitivement le risque d'abandon.

Le poids des images générées

Une composition simple sur fond uni produit un fichier léger, ce qui est souhaitable même si la contrainte de poids est lâche. La compression doit être réglée une fois pour toutes à un niveau raisonnable, sujet que nous traitons plus largement dans notre article sur la compression des images et le poids des pages.

Prévoir un visuel de remplacement

Si la génération échoue, pour une raison quelconque, le site doit déclarer une image par défaut plutôt que rien. Une image générique aux couleurs du site vaut infiniment mieux qu'un aperçu vide, et cette solution de repli se met en place en une ligne. C'est la précaution la plus rentable de tout le dispositif, puisqu'elle couvre l'ensemble des défaillances imprévues sans avoir à les anticiper. Elle doit toutefois pointer vers un fichier réellement présent et de dimensions correctes, sans quoi le remède reproduit exactement le défaut qu'il devait corriger.

Ce que le dispositif ne fait pas

Une image générée automatiquement reste une image générée : elle assure une présence correcte et homogène, elle ne remplace pas un visuel conçu pour une publication importante. Le bon usage consiste à laisser le dispositif couvrir l'ensemble du site et à permettre la définition manuelle d'un visuel spécifique lorsque le contenu le justifie. Cette combinaison offre le meilleur des deux approches sans imposer un travail graphique sur chaque publication. Dans la pratique, une poignée de contenus par an justifie un visuel dessiné, et tout le reste vit très bien avec la génération automatique. Repérer ces contenus à l'avance, plutôt qu'au moment de la publication, évite de retarder une mise en ligne pour un visuel.