PHPStan et Psalm résolvent le même problème, l’analyse statique de code PHP, avec des philosophies suffisamment proches pour qu’on se demande légitimement lequel choisir sur un projet WordPress. Nous avons fait tourner les deux outils, sur les mêmes plugins clients, pendant plusieurs mois, avec l’extension szepeviktor/phpstan-wordpress d’un côté et le plugin psalm/plugin-wordpress de l’autre. Voici ce que cette comparaison a révélé, au-delà des arguments théoriques que l’on trouve habituellement dans les comparatifs.
Cet article ne cherche pas à désigner un vainqueur absolu : les deux outils ont leur place, et nous expliquons pourquoi nous finissons par les utiliser ensemble sur certains projets plutôt que de trancher définitivement.
Installation et écosystème WordPress
Côté PHPStan, l’extension szepeviktor/phpstan-wordpress est mature et largement adoptée, avec des stubs qui couvrent la quasi-totalité des fonctions du cœur WordPress. L’installation se limite à deux paquets Composer et un fichier phpstan.neon :
composer require --dev phpstan/phpstan szepeviktor/phpstan-wordpressCôté Psalm, le plugin officieux psalm/plugin-wordpress existe également et remplit un rôle équivalent, mais avec une communauté plus restreinte autour de son usage spécifique à WordPress. L’installation ajoute une étape supplémentaire, l’activation explicite du plugin dans la configuration :
composer require --dev vimeo/psalm psalm/plugin-wordpress
vendor/bin/psalm-plugin enable psalm/plugin-wordpressDifférences de comportement observées
Sur des fonctions manipulant des tableaux WordPress complexes, par exemple les tableaux d’arguments passés à register_post_type() ou à WP_Query, Psalm s’est montré plus strict et plus précis dans nos tests : il détecte des clés de tableau mal orthographiées que PHPStan, au niveau que nous utilisions, laissait parfois passer. En contrepartie, cette précision accrue génère aussi davantage de faux positifs sur du code WordPress qui manipule des tableaux de façon dynamique, un schéma pourtant courant dans le cœur lui-même.
PHPStan, de son côté, s’est révélé plus simple à intégrer progressivement grâce à son système de niveaux (0 à 9), qui permet de monter en rigueur pas à pas sur un projet existant. Psalm propose un mécanisme comparable avec ses niveaux d’erreur, mais nous l’avons trouvé moins intuitif à calibrer pour une équipe qui découvre l’analyse statique.
Un exemple concret de divergence
Sur ce code, extrait d’un plugin client qui enregistre un type de contenu personnalisé :
register_post_type( 'evenement', array(
'public' => true,
'has_archve' => true,
'supports' => array( 'title', 'editor' ),
) );La clé has_archve contient une faute de frappe évidente (il manque le i d’archive). PHPStan, même à un niveau élevé, ne signale rien par défaut, car il ne connaît pas la structure exacte attendue du tableau d’arguments de register_post_type(). Psalm, avec son plugin WordPress et ses définitions de types plus détaillées pour cette fonction, a effectivement signalé la clé inconnue dans nos tests, ce qui nous a permis de repérer l’erreur avant qu’elle ne parte en production.
Tableau comparatif
| Critère | PHPStan + phpstan-wordpress | Psalm + plugin-wordpress |
|---|---|---|
| Maturité de l’extension WordPress | Élevée, très largement adoptée | Correcte, communauté plus restreinte |
| Facilité de montée en rigueur progressive | Très bonne (niveaux 0 à 9) | Bonne, mais moins intuitive |
| Détection de clés de tableau incorrectes | Limitée | Meilleure sur les cas testés |
| Faux positifs sur du code WordPress dynamique | Modérés | Plus fréquents |
| Vitesse d’exécution sur un plugin moyen | Rapide | Comparable |
Pourquoi nous finissons par utiliser les deux
Sur nos projets les plus critiques, en particulier ceux qui manipulent beaucoup d’arguments de configuration WordPress (types de contenu, taxonomies, requêtes), nous avons pris l’habitude de faire tourner PHPStan en continu dans la CI, comme vérification rapide et peu bruyante, et de lancer Psalm ponctuellement, en local, lors de revues de code approfondies ou avant une mise en production importante. Cette approche évite de doubler le temps de CI sur chaque push, tout en profitant de la précision supplémentaire de Psalm quand elle compte vraiment.
- PHPStan en continu, en CI, à un niveau raisonnable (5 ou 6), pour un retour rapide et peu de bruit.
- Psalm ponctuellement, avant une release majeure, pour une passe plus fine sur les zones sensibles.
- Aucun des deux ne remplace les tests PHPUnit : ils détectent des classes différentes de problèmes, sans jamais vérifier le comportement réel du code exécuté.
Sur nos projets, nous ne recommandons jamais de choisir un seul outil « pour de bon ». La question qui compte vraiment n’est pas « lequel est meilleur », mais « quel budget de temps l’équipe peut-elle consacrer à l’analyse statique cette semaine », et la réponse évolue selon les projets.
Notre verdict
PHPStan et Psalm restent deux outils solides pour l’analyse statique sur WordPress, avec des forces qui se complètent plus qu’elles ne s’opposent. PHPStan gagne sur la facilité d’adoption progressive et la maturité de son extension WordPress, Psalm gagne sur la précision de détection dans certains cas concrets comme les tableaux d’arguments mal orthographiés. Pour une agence qui découvre l’analyse statique, PHPStan reste le point d’entrée le plus simple ; pour une équipe déjà mature sur le sujet, ajouter Psalm en complément apporte une couche de vérification supplémentaire qui a déjà évité de vraies erreurs sur nos projets.
