Trois sujets reviennent presque toujours dans les offres, et donc dans les questions d'entretien d'un tech lead PHP : la montée de version, la qualité du code et la mise en production. Le poste combine du développement, la revue des merge requests, le choix des outils (PHPStan, Rector, PHP-CS-Fixer) et l'accompagnement des développeurs. Les annonces affichent aussi « lead developer PHP » ou « lead développeur Symfony » pour le même rôle.
Un CV de tech lead PHP liste souvent les mêmes mots. L'expérience réelle se reconnaît au calendrier des versions : un profil qui a mené un passage de Symfony 5 à 6 ou 7 sait parler du journal des dépréciations, des bundles bloquants et de la CI qui teste deux versions à la fois. Celui qui a seulement suivi la montée cite la commande composer update.
Demandez un exemple de revue de code refusée et la raison du refus. Une réponse précise sur une transaction, un appel externe sans timeout ou un N+1 montre plus qu'une liste de principes. Le PDF ajoute 30 questions sur six axes et un cas de 20 minutes.
La stack qu'un tech lead PHP doit maîtriser
PHP 8.4 et 8.5
Les versions supportées fin 2026 vont de PHP 8.2, en correctifs de sécurité jusqu'à fin 2026, à PHP 8.5 sorti en novembre 2025. Un tech lead connaît le calendrier de support et sait dire quand la version en production devient un risque. Il impose le typage strict, les enums et les objets readonly dans le code neuf.
Symfony
Le framework le plus demandé dans les offres de tech lead PHP en France. Les versions LTS (6.4, puis 7.4 sortie en novembre 2025) restent maintenues plusieurs années, les versions intermédiaires quelques mois. La montée d'une LTS à la suivante passe par la suppression des dépréciations, et c'est souvent le tech lead qui la pilote.
Laravel
L'autre grand framework PHP, avec une version majeure par an et deux ans de correctifs de sécurité. Les équipes Laravel utilisent Eloquent, les queues avec Horizon et souvent Livewire ou Inertia côté interface. Un tech lead venu de Symfony doit en connaître les conventions avant d'en fixer les règles.
Doctrine ORM et Eloquent
Les couches d'accès à la base de données de Symfony et de Laravel. Elles cachent le SQL, ce qui produit vite des pages à plusieurs centaines de requêtes. Le tech lead repère ces requêtes en double en revue de code et sait quand repasser en SQL direct pour un traitement de masse.
PHPStan, Rector et PHP-CS-Fixer
PHPStan analyse le code sans l'exécuter et signale les erreurs de type, sur des niveaux de 0 à 10. Rector réécrit automatiquement le code pour une nouvelle version de PHP ou du framework. PHP-CS-Fixer applique le style commun. Ces trois outils dans la CI, et la façon dont ils ont été introduits, en disent long sur un tech lead.
PHPUnit et Pest
Les deux outils de test du monde PHP. PHPUnit est la base, Pest propose une syntaxe plus courte et se répand dans les projets Laravel. La question utile porte sur la répartition entre tests unitaires, tests avec base de données et tests de bout en bout, et sur la durée de la suite.
Symfony Messenger et queues Laravel
Ils sortent les traitements lents de la requête HTTP : envoi de mails, exports, appels à des API tierces. Les messages passent par RabbitMQ, Redis ou la base de données. Un message peut être traité deux fois, donc le code doit le supporter.
Docker, PHP-FPM et FrankenPHP
PHP tourne le plus souvent derrière Nginx avec PHP-FPM, dans des conteneurs Docker. FrankenPHP, soutenu depuis 2025 par la PHP Foundation, ajoute un mode worker qui garde l'application en mémoire entre deux requêtes. Ce mode accélère les réponses mais impose de surveiller l'état partagé.
Le tech lead PHP reste un développeur : il code une bonne partie de son temps, relit les merge requests et tranche les choix techniques de l'équipe, sans rôle de manager hiérarchique dans la plupart des offres. Les annonces demandent Symfony ou Laravel en version récente, une expérience de montée de version, la mise en place d'outils de qualité (PHPStan, Rector, tests), Docker et une CI GitLab ou GitHub. MySQL ou PostgreSQL, Redis et une file de messages complètent la stack. Certaines offres ajoutent un front Vue.js, React ou Angular, ou une part de DevOps. Les certifications Symfony et Zend existent mais restent rares sur les CV, le niveau se vérifie sur des cas tirés du code de l'équipe.
Les compétences à vérifier chez un lead développeur PHP
- Architecture Symfony et Laravel
- Montées de version PHP et framework
- Analyse statique, tests et revue de code
- Performance Doctrine et PHP-FPM
- Traitements asynchrones et sécurité
- Déploiement et production
Cinq questions de revue, de version et de production
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · senior
L'application tourne sous Symfony 6.4 et PHP 8.1. Comment organisez-vous le passage à Symfony 7.4 et PHP 8.4 ?
Une bonne réponsePar étapes, en gardant la production livrable à chaque étape. PHP d'abord : la 8.1 ne reçoit plus de correctifs de sécurité depuis fin 2025, et Symfony 6.4 tourne sous PHP 8.4. Ensuite, vider le journal des dépréciations de la 6.4 (barre de debug, phpunit-bridge en CI), car le passage en 7.x retire tout ce qui était déprécié. Rector applique les changements mécaniques, composer why-not repère les dépendances qui bloquent. La CI teste les deux versions pendant la transition.
Signal d'alerteChanger toutes les versions dans composer.json le même jour et corriger ce qui casse. Ou ignorer les dépréciations jusqu'au jour de la montée.
Question 2 · confirmé
Vous reprenez un projet PHP de 200 000 lignes sans analyse statique. Comment introduisez-vous PHPStan sans bloquer l'équipe ?
Une bonne réponseUn niveau de départ modeste, puis une baseline qui enregistre les erreurs existantes : la CI bloque seulement les nouvelles. Les extensions phpstan-symfony ou Larastan et phpstan-doctrine pour que l'outil comprenne le framework. On monte d'un niveau quand la baseline a fondu, en commençant par le code métier le plus modifié. Les niveaux vont de 0 à 10 depuis PHPStan 2.
Signal d'alerteLe niveau maximal d'un coup avec des milliers d'erreurs à corriger avant toute fusion, ou une baseline qui grossit à chaque merge request sans que personne ne la regarde.
Question 3 · confirmé
Une page de liste Doctrine déclenche 300 requêtes SQL. Comment trouvez-vous la cause et que corrigez-vous ?
Une bonne réponseLe profiler Symfony (ou Debugbar et Telescope côté Laravel) montre les requêtes répétées : un N+1 sur une relation chargée en lazy loading dans la boucle du template. Correction : une jointure avec sélection de la relation dans le QueryBuilder (ou with() en Eloquent), une pagination qui reste correcte avec les jointures, ou une requête qui remplit directement un DTO quand on n'a besoin que de quelques colonnes. Un test qui compte les requêtes évite la régression.
Signal d'alerte« On ajoute du cache » sans regarder les requêtes, ou passer toutes les relations en chargement EAGER dans le mapping.
Question 4 · confirmé
Dans une merge request, un contrôleur de 400 lignes enregistre une commande, envoie un mail et appelle une API de paiement. Que demandez-vous de changer ?
Une bonne réponseSortir la logique dans un service testable sans HTTP, garder le contrôleur pour la requête et la réponse. Mail et appels lents partent en asynchrone (Messenger ou les queues Laravel) après le commit de la transaction, pas au milieu. L'appel au paiement a un timeout, une gestion d'erreur et une clé d'idempotence. Il demande des tests sur le service et explique ses demandes dans la revue, pour que la règle serve aux prochaines MR.
Signal d'alerteUne validation sans commentaire parce que la fonctionnalité marche, ou une demande de réécriture complète sans dire ce qui pose problème.
Question 5 · senior
Il faut renommer une colonne d'une table MySQL de 30 millions de lignes sans couper le service. Comment procédez-vous ?
Une bonne réponseEn plusieurs déploiements (expand puis contract) : ajouter la nouvelle colonne, écrire dans les deux, recopier l'historique par lots depuis une commande, basculer la lecture, puis supprimer l'ancienne colonne dans une version ultérieure. Chaque migration Doctrine ou Laravel reste compatible avec le code de la version précédente, qui tourne encore pendant le déploiement. Il vérifie si l'ALTER se fait en ligne (ALGORITHM=INSTANT ou INPLACE) ou s'il faut un outil comme gh-ost.
Signal d'alerteUn RENAME COLUMN dans la migration du jour, lancé pendant que l'ancien code tourne encore, ou une migration qui verrouille la table sans le savoir.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Tech lead PHP : réponses aux questions de recrutement
Tech lead PHP ou développeur PHP senior : où passe la différence en entretien ?
Le senior résout bien les problèmes qu'on lui confie. Le tech lead décide pour l'équipe : quelle version cibler, quel niveau PHPStan exiger, ce qui bloque une merge request. En entretien, demandez une décision qu'il a prise et défendue, une règle de revue qu'il a mise en place, une montée de version qu'il a planifiée. Un senior répond par son propre code, un tech lead par ce que l'équipe fait différemment depuis son arrivée.
Un tech lead Laravel peut-il encadrer une équipe Symfony ?
Oui, à condition de ne pas fixer de règles avant de connaître le framework. Les principes se transposent : injection de dépendances, tests, files de messages, migrations. Les conventions changent : Doctrine et son unité de travail contre Eloquent et l'Active Record, le conteneur configuré contre les facades. Posez-lui une question Doctrine précise, comme un flush dans un listener ou un N+1 sur une pagination. Prévoyez quelques semaines de prise en main et la relecture d'un pair au début.
Quel exercice donner à un tech lead PHP pendant l'entretien ?
Une revue de code plutôt qu'un algorithme. Préparez une merge request de 150 à 300 lignes tirée de votre domaine, avec quelques défauts plantés : une requête dans une boucle, un appel externe sans timeout, une migration risquée, un test qui ne vérifie rien. Laissez trente minutes pour la commenter. Ce test technique montre ce qu'il repère, l'ordre de ses remarques et la façon dont il les formule pour l'auteur.
Un CV resté sur PHP 7 et Symfony 4 est-il rédhibitoire ?
Pas forcément, mais posez la question du contexte. Certaines équipes maintiennent des applications anciennes sans budget de montée de version. Ce qui compte, c'est la connaissance des versions actuelles et la capacité à mener la migration : journal des dépréciations, Rector, dépendances bloquantes, étapes intermédiaires par les versions LTS. Un profil qui a mené ce chantier sur une vieille base vaut souvent plus qu'un profil qui n'a connu que des projets neufs.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
