Open Source & Outils. PHPStan ou Psalm : le duel de l'analyse statique

PHPStan ou Psalm: le duel de l’analyse statique

En réalité, elle touche à des sujets beaucoup plus concrets: la qualité que l’on veut défendre, la dette héritée que l’on accepte encore de porter, la place de la sécurité dans le cycle de développement et, plus largement, la posture professionnelle que l’on renvoie à une équipe.

Car un outil d’analyse statique ne se contente pas de signaler des erreurs. Il impose une certaine conversation autour du code. Il oblige à décider ce qui mérite d’être corrigé maintenant, ce qui peut attendre, et jusqu’où l’équipe veut aller dans la précision des types et des contrats. C’est là que le comparatif PHPStan Psalm devient intéressant: les deux outils poursuivent un objectif proche, mais ils ne racontent pas exactement la même histoire.

PHPStan mise sur une progression très lisible, une adoption large et un écosystème particulièrement développé. Psalm se distingue par une approche plus directement orientée vers la compréhension fine des flux de données et la détection de risques de sécurité grâce à l’analyse d’altération, ou taint analysis. Le meilleur choix ne dépend donc pas d’un classement abstrait. Il dépend de votre code, de votre équipe et du niveau d’exigence que vous êtes réellement prêt à maintenir dans la durée.

PHPStan: une montée en puissance qui parle aux équipes

PHPStan a construit une grande partie de son succès sur une idée simple: l’analyse statique doit pouvoir entrer dans un projet sans transformer immédiatement la base de code en chantier impossible à contenir.

Son système de niveaux progressifs est, à ce titre, un véritable outil de conduite du changement. Dans la version 1, les niveaux vont de 0 à 9. La version 2 pousse la progression jusqu’au niveau 10, le plus strict. Cette gradation permet de commencer avec des vérifications de base, puis d’augmenter progressivement l’exigence à mesure que le projet et l’équipe gagnent en maturité.

Ce point peut sembler secondaire à une personne qui compare uniquement les capacités techniques des moteurs. Il ne l’est pas du tout sur le marché de l’emploi. Un outil n’a de valeur que s’il est adopté, compris et maintenu. Dans une équipe qui reprend une application ancienne, un niveau intermédiaire correctement intégré vaut souvent mieux qu’une ambition maximale abandonnée au bout de quelques jours.

La logique est particulièrement pertinente dans les projets PHP qui ont grandi par strates: une application métier développée avant l’arrivée massive du typage moderne, un module Drupal personnalisé, une installation WordPress fortement adaptée ou encore une plateforme Laravel dont certaines parties ont été transmises entre plusieurs équipes. Dans ces environnements, le problème n’est pas seulement de détecter les erreurs. Il faut rendre la qualité praticable.

PHPStan permet précisément de construire cette trajectoire. L’équipe peut commencer par les incohérences les plus évidentes, documenter progressivement les paramètres et les valeurs de retour, puis durcir les règles lorsque le code devient plus lisible. Cette approche donne aux développeurs un repère commun, y compris à ceux qui n’ont pas encore une grande expérience de l’analyse statique.

Le bon niveau d’analyse n’est pas celui qui impressionne en démonstration, mais celui que l’équipe saura défendre six mois plus tard.

Un écosystème qui pèse dans la décision

L’autre force de PHPStan tient à son écosystème. L’outil compte plus de 13 900 étoiles sur GitHub et s’appuie sur plus de 200 extensions communautaires. Ces chiffres ne garantissent pas à eux seuls la qualité d’une intégration, mais ils donnent une indication utile sur l’ampleur de l’adoption et sur la probabilité de trouver des extensions adaptées à un environnement courant.

Pour une équipe qui travaille avec Laravel, Symfony, Doctrine, des bibliothèques de paiement ou des composants fortement typés, cet écosystème peut réduire les frictions. Une extension bien choisie aide l’analyse à mieux comprendre les méthodes magiques, les fabriques, les relations entre objets ou certains comportements propres à un framework. Sans ce travail d’adaptation, l’outil risque de produire des alertes qui reflètent mal la réalité du projet.

C’est une nuance que je conseille toujours d’observer en recrutement. Lorsqu’un candidat indique qu’il utilise PHPStan, cela ne dit pas encore grand-chose sur son niveau réel. A-t-il simplement ajouté la commande au pipeline d’intégration continue? A-t-il défini une stratégie de niveaux? Sait-il interpréter une erreur et distinguer un vrai défaut d’une limite de compréhension du framework? A-t-il participé à la réduction progressive de la dette existante?

La compétence se trouve moins dans le nom de l’outil que dans la qualité de la décision qui l’accompagne.

Psalm: une analyse plus attentive aux flux dangereux

Psalm répond à une autre préoccupation. L’outil propose lui aussi une analyse approfondie du code PHP, mais sa fonctionnalité la plus différenciante reste l’analyse d’altération intégrée.

Le principe consiste à suivre la circulation de données potentiellement dangereuses dans l’application. Une entrée utilisateur récupérée dans une requête HTTP, un paramètre provenant d’un formulaire ou une valeur issue d’une source externe peut être marquée comme non fiable. Psalm cherche ensuite à savoir où cette donnée se retrouve et si elle atteint un point sensible sans avoir été correctement contrôlée.

Cette approche permet notamment de détecter des scénarios liés aux injections SQL ou aux failles XSS. Elle ne remplace évidemment pas une revue de sécurité, des tests ciblés ou une politique sérieuse de validation des entrées. Elle apporte néanmoins une forme de vigilance automatisée qui s’intègre directement dans le raisonnement sur le code.

Pour certains projets, cette capacité change la hiérarchie des priorités. Une application éditoriale, une plateforme de commerce, un outil manipulant des données personnelles ou un service exposant de nombreuses entrées publiques n’a pas seulement besoin de savoir si un appel de méthode risque de recevoir un mauvais type. Il faut aussi comprendre comment une donnée circule et à quel moment elle devient dangereuse.

C’est dans ce type de contexte que Psalm peut prendre une longueur d’avance. Non parce qu’il serait mécaniquement meilleur sur tous les sujets, mais parce qu’il pose une question que l’analyse de types classique ne couvre pas toujours avec la même profondeur: cette donnée est-elle digne de confiance au moment où elle atteint cette opération?

Ce que cela change pour un développeur

Sur le terrain, la différence se traduit par une discipline de raisonnement. Avec un outil centré sur les types, on examine principalement les contrats: ce que reçoit une fonction, ce qu’elle renvoie, les propriétés qu’un objet est censé contenir et les chemins d’exécution possibles. Avec l’analyse d’altération, on ajoute une dimension de provenance: d’où vient cette donnée, a-t-elle été nettoyée, et peut-elle atteindre une opération sensible?

Cette distinction est précieuse dans une équipe, mais elle demande aussi un niveau de maturité suffisant. Une alerte de sécurité ne se traite pas comme une simple faute de typage. Il faut comprendre le chemin de données, vérifier le contexte et choisir une correction qui ne donne pas seulement l’impression de satisfaire l’outil.

C’est là qu’un profil PHP expérimenté peut faire la différence en entretien. Il ne récite pas les fonctionnalités de Psalm. Il explique comment une alerte s’insère dans une politique de développement, comment elle est priorisée et comment l’équipe évite de transformer la sécurité en pluie de messages ignorés.

PHPStan contre Psalm: deux philosophies, pas deux camps

Opposer PHPStan et Psalm comme deux solutions incompatibles serait une mauvaise lecture du sujet. Ils peuvent être utilisés ensemble dans une même chaîne d’intégration continue. La vraie question est plutôt de savoir quelle philosophie doit guider l’équipe et quel niveau de complexité elle est prête à absorber.

Ce tableau ne doit pas être lu comme une grille de classement. Il donne plutôt une première indication de la conversation que vous allez devoir avoir avec votre équipe.

Si votre difficulté principale est l’hétérogénéité du code et l’absence de trajectoire commune, PHPStan sera souvent plus facile à faire accepter. Si votre difficulté principale concerne la sécurité applicative et la circulation des entrées externes, Psalm mérite une évaluation sérieuse. Dans un projet mature, les deux approches peuvent aussi se compléter, à condition de ne pas empiler les outils sans définir ce que chacun doit réellement apporter.

Et pour Laravel?

La question de savoir comment configurer PHPStan avec Laravel revient régulièrement, parce que le framework s’appuie sur des mécanismes qui peuvent être difficiles à interpréter pour une analyse statique: conteneur de services, façades, méthodes dynamiques, résolution implicite de dépendances ou conventions qui ne sont pas toujours visibles dans la signature d’une méthode.

La première erreur consiste à installer l’outil et à monter immédiatement le niveau au maximum. La seconde consiste à ajouter des extensions sans comprendre les alertes produites. Une configuration solide commence par la réalité du projet:

• le niveau d’analyse doit correspondre à la qualité actuelle du code, pas à une ambition affichée dans la documentation;
• les extensions doivent aider l’outil à comprendre le framework sans masquer les défauts de conception;
• les règles ajoutées par l’équipe doivent rester lisibles pour les développeurs qui rejoindront le projet;
• le pipeline doit distinguer les erreurs nouvelles de la dette ancienne, faute de quoi chaque exécution rappellera seulement que le projet est imparfait.

Dans un contexte Laravel, PHPStan est souvent choisi pour sa capacité à accompagner progressivement l’équipe et pour la disponibilité d’extensions adaptées à l’écosystème. Cela ne signifie pas que Psalm serait exclu. Cela signifie simplement que l’adéquation opérationnelle est généralement plus importante que la préférence théorique.

La configuration: NEON contre XML, mais surtout une question de gouvernance

La configuration n’est pas le sujet le plus spectaculaire d’un comparatif PHPStan Psalm. Elle détermine pourtant une partie de l’expérience quotidienne.

PHPStan s’appuie principalement sur le format NEON. Psalm utilise des fichiers XML, notamment psalm.xml, pour sa configuration et sa baseline. Aucun de ces formats ne constitue une réponse universelle. Le vrai enjeu est la façon dont l’équipe gère cette configuration: qui la modifie, comment les exceptions sont documentées et à quel moment une règle temporaire doit disparaître?

Dans un projet qui grandit, la configuration devient une forme de contrat collectif. Elle traduit le niveau d’exigence accepté par l’équipe. Une exception non expliquée finit par devenir une habitude. Une règle ajoutée dans l’urgence peut, quelques mois plus tard, empêcher une évolution saine. Le fichier de configuration mérite donc la même attention que le code applicatif: revue, historique, justification et nettoyage régulier.

Pour le candidat qui souhaite valoriser son expérience, c’est un point très concret à préparer. Dire que l’on sait utiliser un outil d’analyse de code PHP est moins convaincant que d’expliquer:

1. comment le niveau initial a été choisi;

2. comment les erreurs ont été classées entre défauts réels, limites de l’outil et dette historique;

3. comment les exceptions ont été réduites;

4. comment l’analyse a été intégrée à la revue de code et à l’intégration continue;

5. comment l’équipe a évité de faire de la configuration un territoire réservé à une seule personne.

Cette capacité à relier l’outil à la vie de l’équipe relève pleinement des soft skills. La communication, la négociation technique et la pédagogie comptent autant que la connaissance de la commande à exécuter.

Le code legacy: la baseline comme acte de lucidité

L’arrivée d’un analyseur statique dans une application ancienne produit souvent un moment de vérité peu confortable. Le rapport contient plus de problèmes que l’équipe ne peut raisonnablement en corriger dans le sprint en cours. Deux réactions sont alors fréquentes: abandonner l’outil ou prétendre que toutes les alertes doivent être résolues immédiatement.

Aucune des deux n’est satisfaisante.

PHPStan propose l’option --generate-baseline, qui permet d’exporter les erreurs existantes dans un fichier de référence. L’équipe peut ainsi intégrer l’outil sans bloquer tout le code hérité. Les erreurs déjà connues sont enregistrées, tandis que les nouveaux problèmes peuvent être traités comme une régression à éviter.

Cette stratégie ne doit pas devenir une manière élégante de ne jamais corriger la dette. Une baseline utile est un point de départ, pas une décharge permanente. Elle doit être suivie, réduite et interrogée. Si elle grossit à chaque évolution, le signal est mauvais: l’outil est présent, mais le niveau de qualité n’est pas réellement piloté.

Psalm propose lui aussi une logique de baseline et s’inscrit dans cette même nécessité de composer avec l’existant. La différence pratique tient notamment au format de configuration et à la manière dont l’équipe organise le suivi. Dans les deux cas, le principe reste le même: ne pas punir le projet pour son histoire, tout en empêchant cette histoire de décider seule de son avenir.

Une baseline bien utilisée protège le présent du projet; une baseline jamais revisitée protège surtout les mauvaises habitudes.

Ce que l’employeur cherche réellement à entendre

Quand une entreprise demande de l’expérience avec PHPStan ou Psalm, elle ne cherche pas toujours une personne capable de réciter une liste de règles. Elle veut généralement savoir si le futur collaborateur saura rendre la qualité compatible avec la livraison.

La question peut être formulée de manière très simple: que faites-vous si l’outil remonte plusieurs milliers d’erreurs sur une application que l’entreprise doit continuer à faire évoluer?

Une réponse crédible ne consiste pas à promettre une correction totale immédiate. Elle commence par une photographie du risque et de la dette, puis propose un périmètre: les fichiers modifiés, les chemins sensibles, les modules les plus exposés ou les erreurs qui peuvent provoquer des comportements incorrects. Ensuite seulement vient la montée en exigence.

Cette posture est particulièrement valorisée dans les équipes qui travaillent sur des CMS, des bibliothèques open source ou des applications dont la maintenance dépasse largement le périmètre d’un seul développeur. La qualité doit survivre aux personnes qui l’ont instaurée. Elle doit donc être formulée dans des règles compréhensibles et transmissibles.

PHPStan Pro: quand l’outil devient un produit d’équipe

PHPStan ne s’arrête pas à sa version open source. PHPStan Pro propose une interface web et un mode d’observation continu. L’offre est affichée à 7 euros par mois pour un développeur seul et à 70 euros par mois pour une équipe allant jusqu’à 25 développeurs.

Le prix n’est pas le sujet principal, même s’il peut entrer dans la grille salariale indirecte d’une petite structure ou dans la négociation des moyens mis à disposition. La question est celle de la valeur opérationnelle: l’interface et l’observation continue permettent-elles à l’équipe de mieux comprendre les erreurs, de suivre leur évolution et de réduire le temps consacré à l’interprétation?

Pour une équipe réduite, la version open source peut largement suffire. Pour une organisation qui veut rendre l’analyse visible à plusieurs profils, le produit complémentaire peut faciliter le pilotage. Mais il ne fera pas le travail de gouvernance à la place des responsables techniques. Une interface plus agréable ne transforme pas une politique confuse en stratégie de qualité.

Ce point mérite d’être dit sans détour: l’achat d’un outil ne règle jamais une absence de décision. Si les alertes ne sont pas priorisées, si personne ne possède la responsabilité de la configuration et si les développeurs sont évalués uniquement sur la vitesse de livraison, PHPStan Pro ne changera pas durablement la qualité du code.

Comment choisir sans se raconter d’histoires

Pour départager PHPStan et Psalm, je recommande de partir de quelques situations très concrètes plutôt que de comparer des listes de fonctionnalités.

Choisissez PHPStan si votre priorité est la progression collective

PHPStan sera souvent le choix le plus naturel si vous devez introduire l’analyse statique dans une équipe hétérogène, avec une base de code importante et des niveaux de pratique différents. Son système de niveaux permet de rendre la progression visible. Son écosystème peut simplifier l’intégration avec les outils et frameworks courants. Sa notoriété facilite aussi le recrutement: le nom est connu, les retours d’expérience sont nombreux et les candidats peuvent plus facilement situer leur niveau.

Cela ne signifie pas qu’il faille se contenter d’une analyse superficielle. Un niveau bas n’est pas une identité permanente. Il doit servir de marche, avec une trajectoire clairement assumée.

Choisissez Psalm si la circulation des données est au centre du risque

Psalm mérite une place prioritaire lorsque les failles liées aux entrées utilisateur, aux données externes et aux frontières entre composants représentent une préoccupation centrale. Son analyse d’altération apporte un angle de sécurité qui dépasse le simple contrôle des types.

Elle sera particulièrement pertinente pour une application dont les données proviennent de nombreuses sources et sont ensuite utilisées dans des opérations sensibles. Là encore, l’outil ne remplace pas les compétences de l’équipe. Il fournit un filet supplémentaire, pas une garantie absolue.

Envisagez les deux si les responsabilités sont clairement séparées

Les deux outils peuvent être exécutés conjointement dans une même intégration continue. Cette possibilité ne signifie pas qu’il faille systématiquement les installer ensemble. Deux analyseurs produisent aussi deux familles de messages, deux configurations et parfois des décisions à arbitrer.

La combinaison a du sens si chaque outil répond à un besoin distinct: l’un structure la qualité et les contrats du code, l’autre approfondit le suivi des données potentiellement dangereuses. Elle devient contre-productive si l’équipe ne sait plus quelle alerte doit être traitée en priorité ou si les développeurs passent plus de temps à maintenir les outils qu’à corriger les causes.

La bonne question n’est donc pas: lequel gagnerait un duel? C’est plutôt: quel risque voulons-nous réduire, et qui s’engage à faire vivre cette décision?

Le choix qui compte en entretien

Pour un développeur PHP, connaître PHPStan ou Psalm représente un avantage, mais savoir en parler avec mesure représente souvent un avantage supérieur. Les recruteurs expérimentés cherchent des signes d’autonomie: la capacité à ne pas confondre rigueur et rigidité, à expliquer une dette sans la normaliser, à proposer une montée en charge sans promettre l’impossible.

Dans votre parcours, vous pouvez présenter le sujet autour de trois éléments:

• la situation initiale du projet et ses contraintes réelles;
• la stratégie d’adoption, avec le niveau choisi, les extensions éventuelles et la gestion de la baseline;
• le résultat organisationnel: revues plus précises, régressions mieux détectées, transmission facilitée ou discussions techniques plus structurées.

Évitez de réduire votre expérience à une liste de commandes. La valeur professionnelle se trouve dans la décision, dans la pédagogie et dans la capacité à maintenir la qualité lorsque la pression de livraison revient.

PHPStan et Psalm sont donc moins des concurrents que deux portes d’entrée vers une pratique plus exigeante du développement PHP. PHPStan offre une trajectoire particulièrement lisible, soutenue par une adoption massive, des niveaux progressifs et un écosystème riche. Psalm apporte une réponse forte aux équipes qui veulent suivre la provenance des données et intégrer plus directement la sécurité dans l’analyse du code.

Si vous devez décider maintenant, commencez par le risque le plus coûteux pour votre projet. Si c’est l’hétérogénéité et la dette, construisez une montée en puissance avec PHPStan. Si ce sont les flux de données non fiables et les vulnérabilités applicatives, examinez sérieusement Psalm. Et si votre équipe est assez mature pour distinguer les rôles de chaque outil, une utilisation conjointe peut être pertinente.

Le choix final ne dira pas seulement quel analyseur vous avez installé. Il dira quel niveau de responsabilité vous êtes prêt à assumer vis-à-vis du code, de vos collègues et des utilisateurs qui lui confient leurs données.