Fini les var_dump() en production : automatisez leur détection avec PHPStan

Cela arrive dans toutes les équipes. Un développeur ajoute un var_dump() ou un dd() le temps d'une session de débogage, la pull request passe en revue sans que personne ne le remarque, et le code atterrit en production. Résultat : des données sensibles exposées dans les logs, une expérience utilisateur dégradée, parfois un incident de sécurité.

Ce problème n'est pas une question de compétence individuelle. C'est une question de processus. Et les processus, ça s'automatise.

Cet article vous présente une approche concrète pour éliminer ce risque une bonne fois pour toutes, en intégrant une extension PHPStan dans votre pipeline CI.

Le problème : des règles informelles qui ne tiennent pas dans le temps

Dans un projet PHP/Symfony qui grandit, les dérives sont prévisibles :

• Des fonctions de débogage (var_dump, dd, dump, print_r) oubliées dans le code livré.
• Des appels directs à la base de données dans des contrôleurs, court-circuitant la couche de services.
• Des violations d'architecture entre les couches (domaine, application, infrastructure) qui s'accumulent silencieusement.

Les revues de code humaines sont utiles, mais elles sont faillibles. La fatigue, la rapidité des cycles de livraison et le volume de modifications font que ces problèmes passent régulièrement entre les mailles du filet.

PHPStan est déjà l'outil de référence pour l'analyse statique en PHP. Il détecte les erreurs de types, les appels à des méthodes inexistantes, les variables non définies. Mais imposer des règles métier ou architecturales personnalisées — comme « interdire var_dump dans toute la base de code » — nécessite soit d'écrire une règle PHPStan sur mesure (chronophage), soit de se contenter des options limitées de la configuration native.

La solution : l'extension phpstan-forbidden-nodes

L'extension open source phpstan-forbidden-nodes, présentée par Rajmund sur dev.to, répond directement à ce besoin. Elle permet de définir des patterns interdits via une configuration YAML, sans écrire une seule ligne de PHP supplémentaire.

Installation

composer require --dev rajmundtoth0/phpstan-forbidden-nodes

Ajoutez ensuite l'extension à votre fichier phpstan.neon :

includes:
  - vendor/rajmundtoth0/phpstan-forbidden-nodes/extension.neon

Configuration des règles

La puissance de cette extension réside dans sa simplicité de configuration. Voici un exemple concret adapté à un projet Symfony :

parameters:
  forbidden_node:
    nodes:
      - type: Expr_FuncCall
        functions:
          - var_dump
          - dd
          - dump
          - print_r
          - var_export

Avec cette configuration, PHPStan produira des erreurs explicites lors de l'analyse :

Forbidden function var_dump() used in App\Service\UserService.php:42
Forbidden function dd() used in App\Controller\ProductController.php:18

Ces erreurs bloquent le pipeline CI exactement comme une erreur de type classique.

Règles concrètes à appliquer dans vos projets Symfony

Au-delà des fonctions de débogage, cette approche permet d'encoder des règles d'architecture directement dans votre toolchain. Voici des exemples directement applicables en contexte Symfony :

Bloquer les fonctions de débogage

- type: Expr_FuncCall
  functions:
    - var_dump
    - dd
    - dump
    - print_r

Interdire die() et exit() hors des scripts CLI

- type: Expr_FuncCall
  functions:
    - die
    - exit

Signaler les appels eval()

- type: Expr_Eval

Ces règles constituent une première couche de protection immédiatement opérationnelle. Elles peuvent être enrichies progressivement selon les besoins du projet.

Intégration dans votre pipeline CI

Pour que ces règles aient un effet réel, elles doivent s'exécuter automatiquement à chaque pull request. Voici un exemple d'intégration avec GitHub Actions :

name: Static Analysis

on: [pull_request]

jobs:
  phpstan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'

      - name: Install dependencies
        run: composer install --no-interaction

      - name: Run PHPStan
        run: vendor/bin/phpstan analyse --no-progress

Avec cette configuration, toute pull request contenant une fonction interdite sera automatiquement bloquée. La revue de code humaine peut alors se concentrer sur ce qui a réellement de la valeur : la logique métier, la lisibilité, les choix d'architecture.

Le même principe s'applique avec GitLab CI, Bitbucket Pipelines ou n'importe quel autre système d'intégration continue.

Le ROI pour les équipes et les décideurs

Pour un lead dev ou un CTO, la question n'est pas seulement technique. Elle est aussi économique. Voici ce que cette mise en place apporte concrètement :

Réduction des incidents en production Un var_dump() oublié peut exposer des données utilisateurs dans les logs ou interrompre une réponse JSON. Ce type d'incident génère du temps de débogage, parfois une communication de crise, et entame la confiance des utilisateurs.

Préservation de la qualité architecturale Les violations de couches s'accumulent. Une règle automatisée qui les bloque dès la PR empêche la dette technique de s'installer progressivement. Il est toujours moins coûteux de corriger tôt.

Onboarding simplifié Les règles documentées dans la configuration PHPStan servent aussi de guide implicite aux nouveaux développeurs. Plutôt qu'un wiki à maintenir, les conventions sont encodées dans l'outillage.

Coût d'implémentation faible La mise en place initiale représente moins d'une heure de travail. La maintenance est quasi nulle. Le rapport effort/bénéfice est particulièrement favorable.

Conclusion

Interdire les var_dump() en production n'est pas une question de confiance envers les développeurs. C'est une question de systèmes fiables. Les meilleurs développeurs font des erreurs d'inattention — c'est pour cela que les pipelines CI existent.

L'extension phpstan-forbidden-nodes offre une solution légère, configurable et immédiatement opérationnelle pour encoder vos conventions de code dans votre outillage. Combinée à PHPStan et à un pipeline CI bien configuré, elle constitue un filet de sécurité robuste qui libère votre équipe des vérifications manuelles répétitives.

Chez MulerTech, nous recommandons systématiquement ce type d'approche à nos clients pour sécuriser la qualité du code livré sur le long terme. Si vous souhaitez mettre en place ce type de garde-fou sur votre projet Symfony, n'hésitez pas à nous contacter.

Source originale : Stop shipping var_dump() to production — enforce it with PHPStan par Rajmund sur dev.to. Dépôt GitHub de l'extension : rajmundtoth0/phpstan-forbidden-nodes