Product Updates · Parhum Khoshbakht

141 tests, 31 vérifications de conformité, zéro raccourci : comment nous livrons Statnive

La plupart des plugins WordPress exécutent un linter et s'en contentent. Statnive passe par 5 couches de vérification automatisée — des hooks pre-commit aux portes de conformité WordPress.org — avant toute publication. Voici exactement ce que nous vérifions et pourquoi.

Avant d’installer un plugin, vous faites confiance au code de quelqu’un d’autre

Chaque plugin WordPress que vous activez obtient un accès complet à votre base de données, votre panneau d’administration et les données de vos visiteurs. La plupart des pages de plugin affichent une note par étoiles et une date de « Dernière mise à jour ». Ce n’est pas suffisant pour prendre une décision de confiance.

Nous avons construit Statnive pour être le plugin d’analytics en lequel nous aurions confiance sur nos propres sites. Cet article décrit en détail le pipeline de qualité exact que chaque ligne de code Statnive traverse avant d’atteindre votre installation WordPress. Pas de déclarations vagues — des vérifications spécifiques, de vrais chiffres et des mises en garde honnêtes sur ce que les tests automatisés peuvent et ne peuvent pas détecter.

Les chiffres clés : 141 tests unitaires PHP, 31 sections de conformité WordPress.org, 10 portes CI spécialisées, 3 versions PHP cibles et un budget de taille de Tracker de 5 Ko appliqué à chaque build.

Couche 1 : Le hook pre-commit — rien n’entre dans le dépôt sans vérification

Avant même que le code n’entre dans notre dépôt Git, un hook pre-commit exécute deux vérifications sur chaque fichier en staging :

Pour les modifications PHP :

  1. PHPCS (PHP CodeSniffer) valide les fichiers en staging selon les WordPress Coding Standards — le même ensemble de règles qu’utilise WordPress core. Cela détecte l’échappement de sortie non sécurisé, la sanitisation manquante et les motifs de code non standard.
  2. PHPUnit exécute la suite de tests unitaires complète. Les 141 tests doivent tous passer. Un seul échec bloque le commit.

Pour les modifications TypeScript/JavaScript :

  1. Vitest exécute tous les tests des composants React. L’interface du Dashboard ne peut pas régresser sans être détectée ici.

Le hook pre-commit est intentionnellement rapide — il s’exécute en moins de 5 secondes sur la machine d’un développeur. L’objectif n’est pas de remplacer la CI, mais de détecter les erreurs les plus courantes avant qu’elles ne nécessitent un aller-retour vers GitHub. En pratique, cette seule porte détecte environ 80 % des problèmes avant qu’ils ne quittent l’ordinateur portable du développeur.

Couche 2 : Intégration continue — 6 jobs en parallèle à chaque push

Chaque push vers notre branche de développement ou principale, et chaque pull request, déclenche un pipeline CI GitHub Actions avec 6 jobs en parallèle :

JobCe qu’il vérifiePourquoi c’est important
Lint (PHP 8.2, 8.3, 8.4)PHPCS + PHPStan niveau 6Standards de codage et sûreté des types statiques sur 3 versions PHP
Tests unitaires (PHP 8.2, 8.3, 8.4)Suite PHPUnitExactitude logique sur 3 versions PHP
Smoke test plancher minimum (PHP 8.0)Lint syntaxique + démarrage autoloaderProuve que le plugin se charge sur la version PHP minimale déclarée
Tracker BuildBuild Vite + vérification taille gzipApplique le budget gzippé de 5 Ko sur le Tracker d’analytics

Pourquoi 4 versions PHP ?

Les sites WordPress tournent sur PHP 8.0 à 8.4 dans la réalité. Une fonction qui fonctionne sur PHP 8.4 peut se comporter différemment sur PHP 8.0 — les valeurs de paramètres par défaut, les règles de coercition de type et les fonctionnalités dépréciées varient selon les versions. Nous testons sur les trois versions où notre suite de tests complète s’exécute (8.2, 8.3, 8.4) et vérifions séparément que le code de production se parse et démarre au moins sur PHP 8.0 — le minimum déclaré dans notre en-tête de plugin.

Le budget de 5 Ko du Tracker

Le Tracker JavaScript qui collecte les vues de pages sur votre site a une limite de taille stricte : 5 120 octets gzippés. Chaque build mesure la sortie et fait échouer le pipeline si le Tracker dépasse ce budget. Ce n’est pas arbitraire — notre benchmark de performance a montré que la taille du Tracker corrèle directement avec l’impact LCP. Le budget nous oblige à maintenir le chemin critique minimal et à différer les fonctionnalités non essentielles à un script secondaire async.

# Extrait de notre workflow CI — la vérification de taille du Tracker
- name: Verify tracker size
  run: |
    MAX_SIZE=5120  # 5KB in bytes
    GZIP_SIZE=$(gzip -c public/tracker/statnive.js | wc -c)
    if [ "$GZIP_SIZE" -gt "$MAX_SIZE" ]; then
      echo "::error::Tracker size (${GZIP_SIZE}B) exceeds limit (${MAX_SIZE}B)"
      exit 1
    fi

PHPStan au niveau 6

PHPStan est un outil d’analyse statique qui trouve des bugs sans exécuter le code. Le niveau 6 (sur 10) détecte les incompatibilités de types, les variables indéfinies, les types de retour incorrects et les chemins de code morts. Nous l’exécutons avec l’extension phpstan-wordpress, qui comprend les signatures des hooks WordPress, les types de retour des filtres et les contrats de méthode $wpdb. Combiné à l’application de $wpdb->prepare(), c’est notre principale défense contre les injections SQL — l’analyseur statique signale toute requête qui concatène des entrées utilisateur au lieu d’utiliser des instructions préparées.

Couche 3 : Conformité WordPress.org — 10 portes spécialisées

C’est là que le pipeline de qualité de Statnive diverge de la plupart des plugins WordPress. Au-delà du linting et des tests standards, nous exécutons 10 portes de conformité conçues spécifiquement pour faire respecter les directives de plugins WordPress.org — les mêmes règles que l’équipe de révision vérifie manuellement lors de la soumission.

La plupart des développeurs de plugins découvrent ces règles quand leur soumission est rejetée. Nous les avons automatisées afin que les violations soient détectées à chaque commit :

Portes de sécurité

Gardes ABSPATH — Chaque fichier PHP doit vérifier defined('ABSPATH') avant de s’exécuter. Cela empêche l’accès direct aux fichiers du plugin via URL, ce qui pourrait exposer les chemins serveur ou exécuter du code en dehors du contexte WordPress. Notre porte scanne chaque fichier .php dans l’arborescence source et échoue si un fichier est dépourvu du garde.

Motifs interdits — Un scan automatisé bloque les fonctions PHP dangereuses que WordPress.org rejette explicitement : eval(), exec(), shell_exec(), system(), passthru() et curl_init(). Il détecte aussi les balises courtes PHP, le json_encode() brut (doit utiliser wp_json_encode()), et les chemins wp-content codés en dur.

Conformité WP API — Vérifie que tous les scripts et feuilles de style utilisent le système enqueue de WordPress plutôt que des balises <script> ou <link> codées en dur. Scanne aussi les accès aux superglobales non sanitisées ($_GET, $_POST, $_REQUEST) — l’une des principales raisons pour lesquelles WordPress.org rejette les soumissions de plugins.

Portes d’intégrité

Cohérence readme & version — La version du plugin doit correspondre à trois endroits : le tag Stable dans readme.txt, l’en-tête de statnive.php et la constante PHP STATNIVE_VERSION. Une incohérence signifie que WordPress afficherait le mauvais numéro de version — source de confusion pour les utilisateurs et signal d’alarme pour les réviseurs. Cette porte valide aussi le nombre de tags (max 5), la longueur de la description courte (max 150 caractères), la présence du fichier LICENSE et la section de divulgation des services externes.

Validation du ZIP de distribution — Construit le fichier ZIP réel qui serait uploadé sur WordPress.org, puis valide son contenu. Les fichiers obligatoires doivent être présents (statnive.php, readme.txt, LICENSE, src/Plugin.php, source de Tracker non minifiée). Les fichiers interdits doivent être absents (node_modules/, .git/, composer.json, tests/, phpunit, fichiers de configuration). La taille du ZIP doit rester sous 25 Mo.

Parité des en-têtes — Valide que les 11 champs d’en-tête de plugin requis sont présents et cohérents. Vérifie que la version WordPress Tested up to se trouve dans les 2 versions mineures de la version stable actuelle — une valeur obsolète signale un plugin non maintenu et peut affecter le classement dans la recherche WordPress.org.

Portes d’architecture

Bloqueurs d’architecture — Scanne les motifs qui indiquent des violations de politique : appels HTTP de retour au serveur dans les hooks d’activation (les utilisateurs ne doivent pas voir de requêtes réseau lorsqu’ils activent un plugin), hooks de mise à jour automatique personnalisés (WordPress.org gère les mises à jour) et bases de données MaxMind GeoIP intégrées (les utilisateurs doivent fournir leur propre clé de licence).

Limite Freemium — La version gratuite de WordPress.org ne doit pas contenir de code de blocage de licence. Cette porte scanne les motifs comme isPro(), checkLicense(), trial_expires et premium_only — s’assurant que le build .org est genuinement gratuit, et non un essai bridé.

Audit des services externes — Extrait chaque domaine https:// référencé dans le code source PHP, puis vérifie que chacun est documenté dans la section Services externes de readme.txt. Toute connexion externe non documentée fait échouer le build. C’est ainsi que nous garantissons la transparence sur le flux de vos données.

Obtenez Statnive : du code en qui vous pouvez avoir confiance

Chaque vérification décrite dans cet article s’exécute automatiquement à chaque modification. Aucun humain n’a à se souvenir d’exécuter le scan de sécurité ou de vérifier la cohérence des versions — le pipeline l’impose. Installez Statnive depuis WordPress.org et observez le résultat : des analytics rapides et privées sur votre propre serveur.

Couche 4 : WordPress Plugin Check — plus strict que nécessaire

Le Plugin Check (PCP) est un outil officiel de l’équipe WordPress.org qui exécute les mêmes vérifications automatisées que l’équipe de révision. La plupart des plugins configurent PCP pour échouer uniquement sur les erreurs.

Statnive échoue sur les erreurs ET les avertissements.

C’est un choix délibéré. Les avertissements PCP signalent souvent des problèmes légitimes — utilisation de fonctions dépréciées, lacunes d’accessibilité, préoccupations de performance — qui ne bloquent pas techniquement la soumission mais dégradent la qualité du plugin au fil du temps. En traitant les avertissements comme des erreurs, nous détectons des problèmes que d’autres plugins livrent.

La porte PCP s’exécute sur le répertoire de distribution construit (pas sur l’arborescence source), en utilisant PHP 8.0 — le minimum déclaré. Cela signifie que nous testons exactement ce que les utilisateurs installeraient, sur la version PHP la plus ancienne que nous supportons.

Couche 5 : La porte de publication — 31 sections avant toute sortie de version

Avant une publication, la porte complète combine tout ce qui précède en une seule décision passe/échoue :

Portes de test statiques (toutes doivent passer) :

PorteVérificationOutil
S-1WordPress Coding StandardsPHPCS
S-2Analyse de type statiquePHPStan niveau 6
S-3Tests unitaires + intégration PHPPHPUnit
S-4Tests de composants ReactVitest
S-5Plugin Check officielPCP (erreurs + avertissements)

Portes de conformité grep (17 vérifications de motifs automatisées) :

PortesCe qu’elles appliquent
C-1Gardes ABSPATH sur chaque fichier PHP
C-2Validation du fichier de licence
C-3, C-4Pas de retour serveur à l’activation, pas de paywalls cachés
C-5Structure readme, parité des versions, divulgation des services externes
C-6Pas d’accès aux superglobales non sanitisées
C-7Pas de bases de données GeoIP intégrées
C-8, C-9, C-10Pas de mise à jour personnalisée, pas de bibliothèques core intégrées, pas de CDN externe
C-11, C-12Nettoyage Cron à la désactivation, fonction de désinstallation présente
C-13Structure du répertoire d’assets SVN
C-14Intégrité et taille du ZIP
C-15La création de tables en base de données suit le format dbDelta
C-16Toutes les chaînes visibles par l’utilisateur sont internationalisées
C-17Hooks WordPress Privacy API enregistrés

Au-delà des portes automatisées, chaque publication comprend une revue manuelle couvrant les budgets de performance, la compatibilité navigateur, l’accessibilité (WCAG 2.2 AA), la clarté UX admin, la sécurité de mise à niveau/migration et la gestion des erreurs. La liste de contrôle complète s’étend sur 31 sections à travers 3 niveaux de sévérité :

  • CRITIQUE — portes automatisées qui bloquent le pipeline de publication
  • BLOQUANT POUR LA PUBLICATION — vérifications manuelles devant passer avant de taguer une version
  • PORTE DE QUALITÉ — standards que nous nous imposons, révisés mais indicatifs

Sécurité et confidentialité : vérifiées par le pipeline, pas seulement promises

De nombreux plugins d’analytics répertorient les fonctionnalités de sécurité et de confidentialité sur leur page marketing. Nous préférons montrer comment ces promesses sont mécaniquement appliquées :

Toutes les requêtes SQL utilisent des instructions préparées. L’extension WordPress de PHPStan signale tout appel de méthode $wpdb qui concatène des entrées utilisateur au lieu d’utiliser $wpdb->prepare(). Cela est détecté au moment de l’analyse statique — avant que le code ne s’exécute jamais.

Pas de Cookie, localStorage ou de fingerprinting. Les portes de conformité scannent les fonctions de définition de Cookie et les API de stockage navigateur. La suite de tests unitaires vérifie que le payload du Tracker ne contient que des identifiants de visiteur hachés et non réversibles.

Salts rotatifs quotidiens. Le même visiteur produit un hash différent chaque jour, empêchant le suivi inter-journalier. Cela est couvert par des tests unitaires dédiés qui vérifient l’unicité des hashs à travers les rotations de salts.

Signatures HMAC sur les payloads du Tracker. Chaque hit de vue de page est signé avec une clé générée côté serveur. La vérification de signature est testée dans la suite unitaire — les payloads invalides ou falsifiés sont rejetés.

Transparence des services externes. La porte CI extrait chaque domaine externe du code source et vérifie qu’il apparaît dans la divulgation readme.txt. Si un développeur ajoute un appel HTTP vers un nouveau domaine, le build échoue jusqu’à ce que le domaine soit documenté.

Ce que les tests automatisés ne peuvent pas détecter

Nous croyons en la transparence sur les limites, pas seulement sur les capacités.

Les tests automatisés vérifient que le code se comporte correctement dans des conditions connues. Ils ne peuvent pas détecter :

  • La confusion UX subtile — un graphique de Dashboard techniquement correct mais trompeur pour les utilisateurs non techniques
  • Les cas limites de performance — une requête rapide avec 1 000 lignes mais qui se dégrade à 100 000. Nous avons des tests de charge k6 pour les chemins critiques, mais ils ne peuvent pas couvrir toutes les formes de données
  • Les conflits dans l’écosystème WordPress — interactions de plugins ou de thèmes qui n’apparaissent que sur des configurations d’hébergement spécifiques. Nous testons sur WP 6.4 jusqu’au trunk, mais l’écosystème WordPress compte 60 000+ plugins
  • Les vulnérabilités zero-day — aucune quantité d’analyse statique ne peut prévenir l’exploitation de vecteurs d’attaque précédemment inconnus

Nous atténuons ces lacunes avec une revue manuelle à chaque publication, un dépôt GitHub public où chacun peut auditer le code, et une surveillance active des forums de support WordPress.org pour les rapports provenant d’installations réelles.

Pourquoi nous avons publié ceci

La recherche montre que plus de 50 % des développeurs de plugins WordPress ne corrigent pas les vulnérabilités signalées avant la divulgation publique. Les plugins passent des années sans mises à jour. Les utilisateurs n’ont aucun moyen de distinguer un plugin bien maintenu d’un plugin abandonné, si ce n’est les notes par étoiles et les dates de « Dernière mise à jour ».

Nous pensons que l’écosystème WordPress mérite de meilleurs signaux. Publier notre pipeline de qualité est une façon de relever la barre — tant pour nous-mêmes (maintenant que c’est public, nous ne pouvons plus ignorer silencieusement des vérifications) que pour l’écosystème (d’autres développeurs de plugins peuvent adopter des pratiques similaires).

Si vous évaluez des plugins d’analytics pour votre site WordPress, nous vous encourageons à poser la question à chaque candidat : comment testez-vous ? Quelles vérifications s’exécutent avant une publication ? Puis-je voir la configuration CI ?

L’intégralité du code de Statnive est open source sur GitHub. Chaque fichier de workflow, chaque test, chaque porte de conformité décrite dans cet article est auditables publiquement.

Essayez Statnive

Tout cet ingénierie existe pour servir un seul objectif : vous donner des analytics en lesquelles vous pouvez avoir confiance sur votre propre serveur WordPress. Pas de transferts de données à des tiers, pas de Cookie, pas de scripts de suivi qui ralentissent votre site.

Installez Statnive gratuitement depuis WordPress.org — vos données restent sur votre serveur, vérifiées par 141 tests et 31 vérifications de conformité à chaque publication.

Obtenir Statnive gratuitement