Blog / Article #76
Pourquoi <?php declare(strict_types=1); est le garde du corps que ton code Symfony mérite

star

18 Août 2026
PHP avec declare(strict_types=1), symbolisant la robustesse du typage strict.

Imaginez un monde où PHP ne transforme pas gentiment '42' en 42 quand ça lui chante, où null ne se faufile pas comme un ninja dans vos calculs, et où une fonction qui attend un int ne se retrouve pas avec une string parce qu’un dev a oublié de valider son input. Ce monde existe : il s’appelle declare(strict_types=1);. Et si vous ne l’utilisez pas dans vos projets Symfony, vous jouez avec le feu. Ou pire, avec les conversions implicites de PHP.

Le typage strict, ou comment PHP a appris à dire non

PHP a longtemps été le langage qui disait oui à tout. Besoin d’additionner un string et un int ? Pas de problème, on va deviner ce que tu veux. Résultat : des bugs aussi prévisibles qu’un épisode de Game of Thrones écrit par un stagiaire. Avec declare(strict_types=1);, PHP arrête de jouer les devinettes et devient un langage qui respecte les types que vous déclarez. Enfin.

Dans Symfony, où les contrôleurs, services et entités s’enchaînent comme les wagons d’un TGV, une erreur de typage peut se propager silencieusement avant d’exploser en production. Le typage strict agit comme un filet de sécurité : si vous passez un string là où un int est attendu, PHP lève une TypeError immédiatement. Pas de « mais ça marchait en local », pas de « on verra en prod ». Juste une erreur claire, au moment où vous écrivez le code, quand il est encore temps de la corriger sans réveiller toute l’équipe à 3h du matin.

Symfony et strict_types : un mariage de raison

Symfony est un framework qui aime les bonnes pratiques. Il pousse à l’utilisation des types (via les annotations, les attributs ou les fichiers YAML), mais sans strict_types, ces efforts sont réduits à néant. Prenez un contrôleur Symfony classique :

<?php

declare(strict_types=1);

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;

class LuckyController extends AbstractController
{
    public function number(): Response
    {
        $number = random_int(0, 100);
        return $this->render('lucky/number.html.twig', [
            'number' => $number,
        ]);
    }
}

Si vous omettez declare(strict_types=1);, rien ne vous empêche d’écrire $number = 'quarante-deux'; et de laisser Twig gérer le bordel. Avec strict_types, PHP vous rappellera gentiment que random_int() retourne un int, et que 'quarante-deux' n’en est pas un. Merci, PHP, on avait presque oublié.

Autre cas d’usage : les services. Symfony utilise massivement l’injection de dépendances, et sans typage strict, une erreur de type dans une interface ou une classe peut passer inaperçue jusqu’à ce qu’un utilisateur tombe dessus. Avec strict_types, le conteneur de services vous alertera dès la compilation si vous essayez de passer un UserRepository là où un LoggerInterface est attendu. Pratique, non ?

Les arguments bidons contre strict_types (et pourquoi ils sont nuls)

Certains diront : « Mais ça casse la compatibilité ascendante ! ». Vrai, mais seulement si votre code repose sur des conversions implicites douteuses. Si c’est le cas, le problème n’est pas strict_types, c’est votre code. PHP 8 a d’ailleurs renforcé le typage avec des fonctionnalités comme les union types et les mixed, ce qui rend strict_types encore plus pertinent.

D’autres rétorqueront : « Ça ralentit le développement, il faut tout valider manuellement ». Faux. Le temps que vous passez à déboguer une conversion implicite foireuse en production est bien plus long que celui nécessaire pour ajouter un (int) ou un strval() explicite. Et puis, avouez que c’est plus satisfaisant d’écrire du code qui veut dire quelque chose plutôt que de laisser PHP deviner vos intentions.

Enfin, il y a ceux qui pensent que strict_types est « trop strict ». Comme si écrire du code robuste était une option. Si vous préférez les surprises, achetez un billet de loterie. En développement, les surprises, on les réserve aux fonctionnalités, pas aux bugs.

Comment l’activer sans se prendre la tête

Activer declare(strict_types=1); dans Symfony est aussi simple que d’ajouter une ligne en haut de vos fichiers PHP. Mais pour éviter de le faire manuellement à chaque fois, voici quelques astuces :

  • Utilisez un PHP-CS-Fixer ou un PHP_CodeSniffer pour l’ajouter automatiquement à tous vos fichiers.
  • Configurez votre IDE (PHPStorm, VSCode) pour qu’il l’ajoute par défaut dans les nouveaux fichiers.
  • Si vous utilisez Symfony 6 ou supérieur, le squelette de base inclut déjà strict_types dans les fichiers générés. Profitez-en.

Et si vous travaillez sur un projet legacy ? Commencez par l’activer dans les nouveaux fichiers, puis migrez progressivement les anciens. Rome ne s’est pas construite en un jour, et votre code non plus.

En résumé, declare(strict_types=1); n’est pas une option, c’est une évidence. C’est le genre de fonctionnalité qui vous fait gagner du temps, de l’énergie, et surtout, qui vous évite de passer pour un dev qui laisse PHP faire n’importe quoi. Alors, la prochaine fois que vous ouvrez un fichier PHP dans votre projet Symfony, demandez-vous : « Est-ce que je veux que mon code soit robuste, ou est-ce que je veux jouer à la roulette russe avec les conversions implicites ? ». Spoiler : la bonne réponse est dans le titre de cet article.

Publié le 18/08/2026 · 5 min de lecture Partager X LinkedIn

← Précédent Git hooks : phpstan et phpunit en pre-commit pour sauver ta ci (et ton karma)