En bref : l'analyse statique examine le code PHP sans l'exécuter et trouve ainsi des erreurs de types, des variables non définies, du code mort et des appels sur des valeurs potentiellement vides. Les deux outils répandus sont PHPStan (niveaux de règles 0 à 10) et Psalm (niveaux d'erreur 1 à 8, avec en plus une analyse de taint pour les flux de données dangereux). Ils trouvent des erreurs dans votre application, non dans l'interpréteur PHP ; contre des failles comme PHP2Shell, seule la mise à jour de PHP aide.
Qu'est-ce que l'analyse statique ?
Un test exécute du code et compare le résultat. L'analyse statique, elle, lit le code comme un contrôleur très minutieux et déduit des types, des valeurs de retour et des appels où quelque chose peut mal tourner. Elle trouve des erreurs même dans des branches qu'aucun test n'atteint jamais.
Pour les décideurs, l'intérêt est simple : les erreurs trouvées avant la mise en production coûtent une fraction de celles que les clients remarquent. Pour les développeurs, c'est un compagnon permanent, qui tourne dans l'environnement de développement et dans le pipeline CI. Si l'analyse s'alarme lors d'une modification, celle-ci n'est pas acceptée tant que l'erreur n'est pas corrigée. Ainsi, aucun nouvel héritage ne s'accumule, tandis que l'existant est résorbé progressivement. Avec les tests avec PHPUnit et Pest, elle forme le socle de la qualité du code.
PHPStan : niveaux de règles de 0 à 10
PHPStan s'installe comme dépendance de développement et nécessite PHP à partir de 7.4 pour fonctionner :
composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src tests
Sans autre indication, PHPStan ne vérifie que le strict nécessaire. Vous réglez la rigueur via onze niveaux, chacun incluant ceux du dessous :
| Niveau | Ce qui est vérifié en plus (sélection) |
|---|---|
| 0 | classes et fonctions inconnues, mauvais nombre d'arguments, variables toujours non définies |
| 3 | types de retour et types affectés aux propriétés |
| 5 | types des arguments lors des appels de fonctions et de méthodes |
| 6 | indications de types manquantes |
| 8 | appels de méthodes et accès aux propriétés sur des valeurs pouvant être null |
| 10 | traitement le plus strict de mixed, y compris en cas de types manquants |
Avec --level max, c'est toujours le niveau le plus élevé qui s'exécute. La documentation avertit toutefois qu'une mise à niveau de PHPStan peut alors apporter de nombreux nouveaux messages. Une découverte typique à partir du niveau 8 :
<?php
function kundenname(?Kunde $kunde): string
{
return $kunde->name(); // PHPStan : appel sur une valeur qui peut être null
}
Introduire PHPStan sans déluge d'erreurs : la baseline
Dans les projets qui ont grandi, PHPStan signale souvent des centaines d'endroits à un niveau élevé. La baseline résout le problème : elle enregistre tous les messages existants dans un fichier, et PHPStan ne signale plus ensuite que les nouvelles erreurs.
vendor/bin/phpstan analyse --level 6 src tests --generate-baseline
Vous intégrez le fichier généré phpstan-baseline.neon à la configuration :
includes:
- phpstan-baseline.neon
parameters:
level: 6
paths:
- src
- tests
L'existant reste ainsi documenté de façon visible, tandis que le nouveau code doit être propre dès le départ.
Psalm et l'analyse de taint
Psalm poursuit des objectifs similaires à ceux de PHPStan. Les niveaux vont en sens inverse : 1 est le plus strict, 8 le plus indulgent, le défaut est 2. Psalm nécessite PHP à partir de 8.2 et se met en place ainsi :
composer require --dev vimeo/psalm
./vendor/bin/psalm --init
./vendor/bin/psalm --taint-analysis
L'analyse de taint est particulièrement intéressante pour la sécurité. « Taint » signifie souillure : Psalm marque les données issues de sources qu'un attaquant peut contrôler, comme $_GET, $_POST, $_COOKIE, $_REQUEST ou php://input. Il suit ensuite si ces données arrivent sans protection à des endroits dangereux, appelés puits (sinks) : sortie avec echo, include, header ou requêtes SQL. Parmi les catégories intégrées figurent notamment sql, html, shell, include, eval, ssrf et unserialize.
<?php
// Psalm signale un flux de $_GET vers la sortie HTML (catégorie html)
echo 'Hallo ' . $_GET['name'];
// Corrigé : échapper la sortie selon le contexte
echo 'Hallo ' . htmlspecialchars($_GET['name'] ?? '', ENT_QUOTES, 'UTF-8');
La documentation de Psalm énonce ouvertement les limites : l'analyse suppose que l'échappement est correct. Des erreurs subtiles, par exemple des guillemets manquants autour d'un attribut HTML, peuvent malgré tout laisser des failles. Psalm recommande donc des requêtes paramétrées pour SQL et des templates sensibles au contexte pour HTML. Les résultats peuvent être produits au format SARIF, que comprend notamment GitHub Code Scanning.
Analyse statique et sécurité après PHP2Shell
Une délimitation honnête s'impose ici. PHP2Shell, c'est-à-dire CVE-2026-109618 et CVE-2026-109619, se trouve dans l'interpréteur PHP. Aucun outil qui lit le code de votre application ne trouve ces failles, et aucune modification de code ne les comble. Seule la mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 le fait.
L'analyse statique contribue néanmoins à la sécurité, à trois niveaux :
- Capacité de mise à niveau : elle trouve le code qui ne fonctionne plus sur les nouvelles versions de PHP. L'obstacle à passer de 8.1 ou 8.2 à une version prise en charge s'en trouve réduit.
- Failles propres : l'analyse de taint trouve les chemins d'injection SQL, de cross-site scripting ou d'inclusion de fichiers. Le projet PHP précise dans sa politique de sécurité que des entrées non vérifiées transmises à des fonctions comme
mysqli_query()ne sont pas une erreur de PHP, mais relèvent de la responsabilité de l'application. - Robustesse : de nombreuses erreurs fatales proviennent d'appels sur null ou de mauvais types. À propos de CVE-2026-109619, php.net conseille expressément de corriger dans l'application les erreurs fatales déclenchables de l'extérieur.
L'analyse statique ne remplace pas une revue de code de sécurité par des humains, mais elle la rend plus efficace, car les erreurs de routine sont écartées au préalable.
Comment PHP SOS aide-t-il concrètement ?
Dans le cadre de l'audit de sécurité et test d'intrusion, nous procédons ainsi :
- Mettre en place les outils : PHPStan ou Psalm avec le niveau adapté et une baseline, intégrés à votre pipeline existant.
- Évaluer les découvertes de sécurité : nous examinons les résultats de l'analyse de taint et distinguons les vrais risques des fausses alertes.
- Préparer la mise à niveau : nous montrons quels endroits bloquent un passage à une version de PHP prise en charge.
- Transmettre les résultats : vous recevez une liste priorisée avec les emplacements de code concrets pour votre équipe ou votre agence.
Questions fréquentes
Quelle est la différence entre PHPStan et Psalm ?
Les deux vérifient les types et trouvent des erreurs sans exécution. PHPStan compte ses niveaux de 0 (souple) à 10 (strict), Psalm de 8 (souple) à 1 (strict). Psalm intègre une analyse de taint pour les problèmes de sécurité.
Puis-je introduire PHPStan dans un vieux projet ?
Oui. Avec une baseline, PHPStan enregistre tous les messages existants dans un fichier et ne signale ensuite que les nouvelles erreurs. L'équipe démarre ainsi sans déluge d'erreurs et résorbe progressivement l'héritage.
L'analyse statique trouve-t-elle PHP2Shell ?
Non. PHP2Shell se trouve dans l'interpréteur PHP, non dans votre code. Seule la mise à jour de PHP aide. L'analyse statique aide toutefois à préparer le code aux nouvelles versions de PHP, de sorte que la mise à jour soit plus rapide.
Quel niveau faut-il choisir ?
Pour débuter, un niveau bas sans baseline ou un niveau plus élevé avec baseline. Plus important que le chiffre : que l'analyse s'exécute automatiquement à chaque modification et ne laisse pas passer de nouvelles erreurs.