Un auteur de plugin qui ne mesure rien travaille à l'aveugle : il ignore quelles versions de PHP il doit encore supporter, quelles fonctionnalités sont utilisées, et quelles erreurs se produisent sur des configurations qu'il ne possède pas. Un auteur qui mesure mal détruit la confiance de ses utilisateurs et s'expose juridiquement. Entre les deux, il existe une conception défendable — et elle tient à des choix précis, pas à des intentions.
Poser la question dans le bon sens
La mauvaise question est « quelles données pourrais-je collecter ? ». Techniquement, un plugin actif dispose d'un accès complet au site : contenu, utilisateurs, commandes, configuration. La capacité technique ne dit rien de la légitimité.
La bonne question est : « quelle décision cette donnée va-t-elle m'aider à prendre ? »
Ce critère élimine l'essentiel. Connaître la répartition des versions de PHP permet de décider quand relever la version minimale — décision réelle, donnée justifiée. Connaître le nombre d'articles d'un site n'oriente aucune décision de développement : c'est de la curiosité, pas de la mesure.
Appliqué honnêtement, ce filtre réduit généralement une liste initiale d'une vingtaine de champs à cinq ou six.
Trois catégories, trois régimes
Ce qui décrit l'environnement technique
Version du plugin, version du cœur applicatif, version du langage, modules activés, langue de l'interface, type de serveur. Ces données décrivent une configuration, pas une personne. Agrégées, elles ne permettent pas d'identifier un site particulier.
C'est le socle légitime d'une télémétrie. Il répond à des questions concrètes : peut-on abandonner le support d'une ancienne version ? Une fonctionnalité récente est-elle réellement adoptée ? Une mise à jour a-t-elle provoqué une vague d'erreurs ?
Ce qui décrit le site ou son propriétaire
Nom de domaine, adresse email, liste des extensions installées, thème utilisé, volumes de contenu. Ces données peuvent être utiles — savoir quelles extensions cohabitent aide à reproduire un conflit — mais elles identifient une installation précise.
Leur collecte suppose un accord explicite, obtenu par une case décochée par défaut, accompagnée d'une description exacte de ce qui sera transmis. Une case pré-cochée n'est pas un consentement : c'est un défaut de conception qui, en droit européen, ne vaut rien.
Ce qui ne doit jamais quitter le site
Contenu des publications, données des visiteurs, identifiants, clés d'interface de programmation, adresses IP brutes, informations commerciales. Aucune fonctionnalité de plugin ne justifie leur transmission à un serveur tiers.
Ce dernier cercle mérite d'être formulé explicitement dans la documentation, parce que c'est précisément ce que les utilisateurs redoutent. L'écrire noir sur blanc lève la principale objection.
Un test simple avant d'ajouter un champ : seriez-vous à l'aise si la liste complète des données transmises était publiée sur votre site, en clair ? Si la réponse hésite, le champ n'a rien à faire là.
La conception technique
Ne jamais bloquer le site
Une télémétrie qui ralentit le site qu'elle observe est une régression. Trois règles s'imposent :
- Envoi non bloquant, hors du cycle de rendu d'une page.
- Délai d'attente court — quelques secondes au maximum.
- Échec silencieux. Si le serveur ne répond pas, il ne se passe rien : aucune erreur affichée, aucune tentative répétée en boucle.
Un envoi hebdomadaire, planifié par le système de tâches différées, suffit largement. Une transmission à chaque chargement de page est disproportionnée et se remarque immédiatement dans les outils de mesure de performance.
Rendre l'opposition réellement accessible
Le moyen de refuser doit être visible, pas enfoui dans un onglet secondaire. Une case sur la page de réglages principale, accompagnée d'un lien vers la description complète de la collecte, constitue le minimum acceptable.
Un détail fait toute la différence : afficher exactement ce qui est envoyé, plutôt qu'une formule vague du type « données d'utilisation anonymes ». Cette formule est le signal le plus fiable qu'une collecte n'est pas assumée.
Documenter publiquement
Une page dédiée listant chaque champ transmis, sa raison d'être et sa durée de conservation transforme une source de méfiance en argument de confiance. Elle coûte une heure de rédaction et se révèle utile lors des relectures du dépôt officiel, où la transparence de la collecte fait partie des points examinés.
Côté serveur : la conservation
La collecte n'est que la moitié du sujet. Ce qui est fait des données ensuite compte tout autant.
- Séparer les envois bruts des agrégats. Les premiers ne sont utiles que quelques semaines ; les seconds constituent la mémoire longue et ne contiennent aucune donnée individuelle.
- Purger automatiquement. Une conservation illimitée est indéfendable et transforme une base technique en risque permanent.
- Ne pas indexer ce qui identifie. Si un identifiant d'installation est stocké, il ne devrait pas cohabiter avec des données permettant de retrouver le site.
Un point d'entrée de collecte est par ailleurs une surface d'attaque : ouvert, non authentifié, il accepte des données arbitraires. Une limitation de débit et une validation stricte du format ne sont pas optionnelles.
L'erreur la plus fréquente
Elle ne concerne pas les données, mais leur interprétation. Une télémétrie n'observe que les installations qui n'ont pas refusé la collecte — population qui n'est pas représentative.
Les utilisateurs les plus techniques désactivent davantage. Les sites soumis à des contraintes réglementaires fortes refusent systématiquement. Les installations sur des configurations anciennes ou restreintes échouent parfois à transmettre. Les mesures surreprésentent donc les configurations standard et les utilisateurs peu regardants.
Conclusion pratique : ces chiffres servent à repérer des tendances et des ruptures, pas à établir des vérités. « Aucune installation ne rapporte cette version de PHP » ne signifie pas qu'aucune ne l'utilise ; cela signifie qu'aucune de celles qui rapportent ne l'utilise. La nuance a fait prendre de mauvaises décisions à des projets bien plus importants qu'un plugin.
Ce que la contrainte apporte
Concevoir une télémétrie sous contrainte de transparence produit un effet secondaire inattendu : elle devient meilleure. L'obligation de justifier publiquement chaque champ élimine ceux qui n'auraient jamais servi, réduit le volume à traiter, simplifie le stockage et rend les tableaux de bord lisibles.
Une collecte que l'on peut publier intégralement, sans gêne, est presque toujours plus utile qu'une collecte exhaustive dont personne n'ose montrer le détail.