Charger les boutons de partage sans script tiers

Les boutons de partage fournis par les plateformes sociales sont commodes : on copie un fragment de code, on obtient un bouton à l'identité officielle, avec parfois un compteur. Ce confort se paie en secondes de chargement, en requêtes vers des domaines tiers et en dépôt de traceurs sur des visiteurs qui n'ont rien demandé. Or la fonction rendue, ouvrir une fenêtre de partage prérempli, ne demande aucun script : un lien construit selon le bon format suffit. Cet article détaille ce que coûtent réellement les widgets officiels, comment produire des boutons équivalents et quels compromis subsistent.

Ce que coûtent les widgets officiels

Le coût est rarement mesuré avant d'être subi, parce qu'un bouton paraît trop petit pour peser. Les chiffres racontent autre chose et ils se vérifient facilement sur n'importe quelle page équipée. Le mécanisme général de ces coûts est décrit dans notre article sur le code tiers et l'impact des scripts externes.

Un jeu de quatre boutons officiels charge en moyenne entre deux cent et six cent kilooctets de JavaScript, répartis sur autant de domaines distincts. Chacun de ces domaines demande une résolution de nom, une négociation de connexion sécurisée et un aller retour réseau avant même que le premier octet utile n'arrive. Sur une connexion mobile de qualité moyenne, ces préliminaires consomment à eux seuls plusieurs centaines de millisecondes. Le bouton lui même, une fois affiché, occupe quarante pixels de côté. Le rapport entre le coût consenti et la surface obtenue est probablement le plus défavorable de toute la page.

Ce chargement intervient en général dans la partie basse de la page, là où les boutons sont placés, mais les scripts sont souvent appelés depuis l'en tête, ce qui les rend bloquants. Le temps avant premier affichage significatif en pâtit directement, avec un effet mesurable sur les indicateurs d'expérience. Les décalages de mise en page provoqués par l'apparition tardive des boutons dégradent en outre la stabilité visuelle, autre indicateur suivi de près. Ce décalage est d'autant plus pénalisant qu'il survient au moment où le visiteur commence à lire, donc là où il est le plus perceptible.

Le troisième coût est juridique et il concerne le dépôt de traceurs. Ces widgets déposent des identifiants permettant à la plateforme de reconnaître le visiteur sur votre site, y compris s'il ne clique pas et s'il n'a pas de compte. Cette collecte suppose un consentement préalable dans plusieurs contextes réglementaires. Nous ne sommes pas juristes et ce point mérite d'être vérifié auprès d'un conseil compétent, la conséquence pratique étant qu'un widget officiel doit généralement être bloqué tant que le consentement n'a pas été recueilli, ce qui le rend inopérant pour une bonne part des visiteurs.

Le compteur de partages, seul argument fonctionnel réellement propre aux widgets, a par ailleurs perdu beaucoup de son intérêt. Plusieurs plateformes ont cessé de l'exposer, et lorsqu'il subsiste, un compteur affichant deux partages produit l'effet inverse de celui recherché. La preuve sociale ne fonctionne qu'au dessus d'un certain seuil, ce que la plupart des pages n'atteignent jamais. Renoncer au compteur est donc rarement une perte. Les sites qui en avaient un l'ont d'ailleurs souvent retiré d'eux mêmes, pour cette raison précise, bien avant de reconsidérer les widgets.

Reste l'argument de l'apparence officielle, qui a sa valeur : les visiteurs reconnaissent les icônes et les couleurs. Cet argument ne justifie pas les widgets, puisque rien n'empêche de reproduire ces éléments visuels avec des images vectorielles intégrées à la page. La reconnaissance visuelle est obtenue pour quelques centaines d'octets au lieu de plusieurs centaines de kilooctets. C'est exactement le compromis que l'on cherche. La reconnaissance ne tient qu'à la forme et à la couleur du pictogramme, deux caractéristiques qu'un fichier vectoriel reproduit fidèlement.

Le principe du lien de partage

Chaque plateforme expose une adresse de partage acceptant des paramètres. Ouvrir cette adresse affiche une fenêtre de publication préremplie avec le lien et parfois le texte fournis. C'est ce que fait le widget officiel, avec quelques centaines de kilooctets de code autour. Un lien ordinaire produit le même résultat. Le visiteur ne perçoit aucune différence, puisque la fenêtre qui s'ouvre est celle de la plateforme dans les deux cas.

La construction du lien suit toujours le même schéma : une adresse de base propre à la plateforme, puis un ou plusieurs paramètres contenant l'adresse de la page et éventuellement un texte d'accompagnement. Ces valeurs doivent être encodées pour l'adresse, faute de quoi tout caractère spécial casse le lien. Cet encodage est la source d'erreur la plus fréquente et il se règle par une fonction disponible dans tous les langages. Une apostrophe ou un point d'interrogation dans un titre suffit à révéler l'oubli, ce qui rend le test facile à mener.

L'adresse partagée doit être l'adresse canonique de la page et non celle affichée dans le navigateur, qui peut contenir des paramètres de suivi ou de session. Partager une adresse comportant un identifiant de campagne pollue les statistiques de tout le monde et peut même exposer des informations personnelles si un paramètre de session s'y trouve. Ce point mérite une vérification explicite lors de la construction du lien. La règle consiste à toujours partir de l'adresse canonique déclarée dans l'en tête de la page plutôt que de l'adresse courante.

Les paramètres à passer varient selon la plateforme : certaines acceptent uniquement l'adresse, d'autres acceptent un titre, un texte ou une image. Ceux qui ne sont pas acceptés sont simplement ignorés, ce qui permet de construire les liens sans crainte d'erreur. Il vaut mieux fournir peu et juste, plutôt que beaucoup et approximatif, la plateforme récupérant de toute façon le titre et l'image depuis les métadonnées de la page.

Ces métadonnées constituent d'ailleurs le point qui détermine réellement l'apparence du partage. Le titre, la description et l'image affichés dans la publication proviennent des balises de la page, pas du bouton. Un bouton parfait sur une page mal balisée produit un partage laid, et l'inverse n'existe pas. Le travail utile porte donc bien plus sur ces balises que sur le mécanisme du bouton, sujet que nous prolongeons dans notre article sur la manière de générer l'image de partage côté serveur.

L'ouverture dans une fenêtre séparée était autrefois obtenue par un script appelant une fonction d'ouverture dimensionnée. Un attribut indiquant l'ouverture dans un nouvel onglet suffit aujourd'hui, accompagné des mentions de sécurité qui empêchent la page ouverte d'accéder à la page d'origine. Le confort est équivalent et le code se réduit à un attribut. Sur mobile, le comportement est d'ailleurs préférable, le système gérant lui même le retour vers la page d'origine.

Consentement, traceurs et blocage conditionnel

Le remplacement des widgets par des liens simplifie considérablement la question du consentement, au point de la faire disparaître dans la plupart des configurations. Comprendre pourquoi demande de revenir sur ce qui déclenche l'obligation, sujet directement lié au fonctionnement décrit dans notre article sur le cookie informatique et son fonctionnement.

Un widget officiel dépose des identifiants et transmet l'adresse de la page consultée à la plateforme dès l'affichage, avant toute action du visiteur. C'est cette transmission passive, et non le partage lui même, qui déclenche les obligations. Un lien, à l'inverse, ne provoque aucune requête tant que personne ne clique dessus. Le visiteur qui clique accomplit une action explicite dont la conséquence est évidente, ce qui change complètement la nature de l'échange.

Nous ne sommes pas juristes et l'appréciation d'une situation particulière revient à un conseil compétent. Le constat technique, lui, est net : passer du widget au lien supprime des requêtes tierces au chargement, donc supprime la collecte associée. C'est un argument qui se vérifie en deux minutes avec les outils de développement du navigateur, ce qui le rend facile à documenter.

Les sites qui conservent des widgets officiels doivent en pratique les charger conditionnellement, après recueil du consentement. Cette mécanique fonctionne et elle produit un effet secondaire souvent ignoré : les boutons n'apparaissent pas pour les visiteurs ayant refusé, ce qui crée un affichage incohérent et une zone vide dans la page. Les liens simples, eux, s'affichent pour tout le monde et fonctionnent identiquement.

Reste le cas des outils de mesure de partage proposés par certains prestataires, qui remplacent les widgets officiels par leur propre solution. Ils règlent le problème d'apparence et déplacent la collecte vers un autre tiers, sans la supprimer. L'arbitrage dépend alors de la valeur réellement accordée aux statistiques obtenues, valeur qui mérite d'être questionnée au vu de ce qu'elles mesurent effectivement.

Construire le composant

La mise en place tient en une poignée de décisions, chacune ayant des conséquences sur l'accessibilité et sur la maintenance. Le composant se construit une fois et se réutilise sur l'ensemble du site.

Le balisage se compose d'une liste de liens, chacun portant l'icône de la plateforme et un intitulé accessible du type partager sur telle plateforme. L'icône seule, sans intitulé, prive les visiteurs utilisant une technologie d'assistance de toute information sur la destination. Le texte peut être masqué visuellement tout en restant présent dans le document, technique standard et sans inconvénient. Cette précaution coûte une classe de style et elle est régulièrement omise. Elle profite également aux visiteurs qui naviguent au clavier, l'intitulé apparaissant alors dans la barre d'état du navigateur.

Les icônes doivent être intégrées directement dans la page sous forme vectorielle plutôt que chargées depuis une bibliothèque externe. Une bibliothèque d'icônes complète pour afficher quatre pictogrammes reproduit exactement le problème que l'on cherchait à supprimer. Les logos officiels sont disponibles auprès de chaque plateforme et leur usage est encadré par des règles d'identité qu'il vaut mieux respecter. Quatre icônes vectorielles pèsent moins de deux kilooctets au total.

Le choix des plateformes proposées mérite d'être fait à partir des données plutôt que par habitude. Afficher huit boutons dont six ne servent jamais encombre la page et dilue l'attention. Les statistiques de provenance indiquent d'où viennent réellement les visiteurs et donc où ils sont susceptibles de partager. Deux ou trois boutons bien choisis produisent plus de partages que huit boutons alignés. Ce constat vaut sur tous les types de contenus et il est facile à vérifier en comptant les clics par bouton pendant un mois.

Le partage par courriel et la copie du lien méritent une place, souvent supérieure à celle des réseaux eux mêmes sur les contenus professionnels. Le premier se construit avec un lien de messagerie portant un objet et un corps préremplis. Le second demande quelques lignes de script utilisant l'interface de presse papier du navigateur, avec un retour visuel confirmant la copie. Ce sont les deux fonctions les plus utilisées sur les contenus techniques et documentaires.

Le partage natif des systèmes mobiles constitue enfin un complément intéressant. Une interface standardisée permet d'ouvrir le sélecteur de partage du système, qui propose les applications réellement installées sur l'appareil. Elle n'est disponible que dans certains contextes et sur certains navigateurs, ce qui impose de vérifier sa présence et de retomber sur les liens classiques sinon. Sur mobile, elle offre la meilleure expérience possible pour un coût de quelques lignes.

Les cas particuliers à prévoir

Quelques situations sortent du modèle simple et méritent une décision explicite plutôt qu'un comportement laissé au hasard. Les traiter dès la construction du composant évite des surprises lors du déploiement sur l'ensemble du site.

Certaines plateformes n'exposent pas d'adresse de partage utilisable, ou l'ont retirée. Dans ce cas, la seule option honnête consiste à ne pas proposer de bouton pour cette plateforme plutôt qu'à bricoler un contournement fragile. Un bouton qui ouvre une page d'erreur nuit davantage à l'image du site que son absence. Cette vérification se fait au moment du choix des plateformes retenues.

Les applications de messagerie constituent un cas intéressant, car elles représentent une part importante des partages réels et restent invisibles dans les statistiques. Plusieurs d'entre elles exposent une adresse de partage fonctionnant sur mobile et ouvrant l'application installée. Les proposer sur mobile, et les masquer sur ordinateur où elles n'ont pas de sens, demande une simple règle de style conditionnelle. C'est souvent le bouton le plus cliqué sur les contenus grand public.

Les pages à accès restreint ne devraient pas afficher de boutons de partage, puisque le destinataire du lien ne pourra pas consulter la page. Cette évidence est régulièrement ignorée sur les espaces clients construits à partir du même gabarit que les pages publiques. Une condition sur le statut de la page règle la question et évite des messages de support inutiles.

Les contenus mis à jour fréquemment posent enfin la question de l'adresse partagée. Partager l'adresse d'une page de liste dont le contenu change quotidiennement produit un partage dont le sens se perd en quelques jours. Lorsque le contenu le permet, faire pointer le partage vers une version stable ou datée préserve la valeur du lien dans le temps. Ce choix relève de l'éditorial autant que de la technique.

Vérifier, mesurer et maintenir

Le remplacement se vérifie sur trois plans, et la mesure du gain sert autant à valider le travail qu'à convaincre les équipes attachées aux widgets officiels.

Le contrôle fonctionnel consiste à cliquer chaque bouton et à vérifier que la fenêtre de publication s'ouvre avec le bon lien, le bon titre et la bonne image. Ce test doit être refait sur mobile, où le comportement diffère, et depuis une page dont le titre comporte des caractères accentués ou une apostrophe. C'est précisément sur ces caractères que les défauts d'encodage se révèlent. Un quart d'heure suffit à couvrir l'ensemble. Consigner ces vérifications dans une courte liste permet de les rejouer à l'identique après toute modification du gabarit.

Le contrôle de performance se mène en comparant deux mesures de la même page, avant et après. La différence porte sur le poids total, le nombre de requêtes, le nombre de domaines contactés et le temps avant affichage. Sur une page équipée de quatre widgets, le gain se situe couramment entre quatre cent kilooctets et un demi mégaoctet, avec plusieurs centaines de millisecondes récupérées sur mobile. Ces chiffres, relevés sur le site réel, valent tous les arguments théoriques.

Le contrôle des traceurs consiste à ouvrir la page dans une fenêtre vierge et à examiner les identifiants déposés ainsi que les domaines contactés. Après remplacement, aucun domaine tiers ne doit être appelé tant que le visiteur n'a pas cliqué. Cette vérification prend deux minutes et elle documente concrètement la réduction de collecte obtenue, information utile pour la documentation de conformité du site.

La maintenance se réduit à peu de chose : les adresses de partage changent rarement, mais elles changent. Une plateforme peut modifier le nom d'un paramètre ou abandonner une fonction. Une vérification annuelle des boutons, inscrite au même calendrier que les autres contrôles techniques du site, suffit largement. Un lien de partage cassé passe autrement inaperçu pendant des mois, personne ne signalant ce type de défaut.

Reste enfin la question du suivi des partages, que le widget officiel ne réglait pas davantage. Compter les clics sur vos propres boutons est possible avec l'outil de mesure déjà en place, en déclarant un événement au clic. Ce comptage indique combien de visiteurs ont ouvert la fenêtre de partage, sans jamais dire combien ont effectivement publié. Cette limite est inhérente au mécanisme et il vaut mieux l'annoncer clairement que de laisser croire à une mesure exacte du nombre de partages réalisés.