"On n'arrive plus à recruter en PHP."
C'est une phrase que j'entends souvent en mission, côté direction. Un poste ouvert depuis des mois, deux ou trois candidats en six semaines, et la moitié qui ne rappelle pas. Le constat tombe, fatigué : le vivier est sec.
Derrière, presque toujours, la même conclusion. PHP serait mort, il n'y aurait plus de développeurs, le langage aurait fait son temps. C'est une explication rassurante : si c'est le marché qui se ferme, ce n'est pas votre faute.
Sauf qu'elle est fausse. Et confondre "je n'arrive pas à recruter" avec "il n'y a plus de devs PHP", ça coûte cher : on cherche la solution au mauvais endroit pendant des mois.
Le vrai problème est ailleurs. Il est moins flatteur, mais il a un énorme avantage : il est réparable.
Non, le marché du PHP n'est pas mort
Commençons par les chiffres, ils tranchent vite.
Le baromètre AFUP 2025, l'enquête de référence de la communauté PHP française, donne un salaire moyen autour de 51 900 € brut par an. En hausse de 7 % sur un an, la plus forte progression depuis 2020. Un marché qui augmente les salaires de 7 %, ce n'est pas un marché qui s'éteint. C'est un marché tendu, où la demande dépasse l'offre. Et tendu, ce n'est pas mort, c'est même l'inverse.
Deuxième donnée : PHP fait toujours tourner de l'ordre de trois sites sur quatre côté serveur. On peut trouver ça démodé, ça reste l'épine dorsale d'une grande partie du web. On ne déserte pas une techno qui fait vivre autant de projets.
Troisième point, le plus oublié. Le PHP de 2026 n'a plus grand-chose à voir avec celui qu'on moquait il y a dix ans. PHP 8 a rattrapé puis dépassé PHP 7 : typage strict, performances revues, syntaxe moderne. Le langage est bien vivant, et plutôt agréable à écrire.
D'où le pivot. Si le marché paie de mieux en mieux, si la techno est partout et qu'elle s'est modernisée, et que malgré tout vous, vous galérez à recruter, le problème n'est pas "le PHP". C'est plus précis que ça. Et plus personnel.
Vous ne recrutez pas "en PHP". Vous recrutez pour ce code.
Voici la distinction qui change tout.
"Recruter un développeur PHP" et "recruter quelqu'un de prêt à travailler sur votre PHP", ce sont deux marchés différents. Même intitulé de poste, candidat radicalement différent.
Le premier, le PHP moderne, se porte bien. Du 8.x typé, une base testée, Symfony ou Laravel maintenus à jour, une CI qui tourne. Pour ce poste, vous avez le choix. Les bons développeurs s'y bousculent, parce qu'on y travaille bien.
Le second, c'est l'autre annonce. Celle qui dit en filigrane : "venez maintenir notre PHP 7.1, des contrôleurs de 800 lignes, zéro test, des dépendances avec dix versions de retard." Là, le vivier ne s'est pas asséché. Il n'a quasiment jamais existé.
Et ce portrait, je ne l'invente pas pour les besoins de la démonstration. C'est la description fidèle d'un legacy type, tel que je le retrouve en audit : des fichiers qui dépassent les 800 lignes, pas de typage, un ratio de tests proche de zéro, un composer.lock qu'on n'ose plus toucher. J'en ai détaillé un cas complet dans à quoi ressemble vraiment un legacy figé sur PHP 7.
Le même candidat dirait oui au premier poste et non au second. Ce n'est pas le langage qui le fait fuir. C'est ce qu'on lui demande d'accepter avec.
Pourquoi un bon développeur décline votre legacy
Passons de l'autre côté de la table, sans mépris ni pour le décideur qui recrute, ni pour le candidat qui refuse. Juste pour comprendre.
Un développeur senior en entretien a appris à lire les signaux. En une heure, il évalue trois choses, et chacune peut le faire dire non.
Le filet, d'abord. Du code sans tests, c'est du code qu'on modifie en apnée : la moindre correction peut casser autre chose ailleurs, sans prévenir. Il n'a pas envie d'être celui qui fait tomber la prod un vendredi soir parce qu'une zone non couverte a lâché. Travailler sans filet, ce n'est pas excitant. C'est juste stressant.
Son CV, ensuite. Deux ans sur du PHP 7.1 non typé, ce sont deux ans de compétences qui datent de 2014. Pendant ce temps, le marché écrit du 8.x typé et testé. Un bon dev pense à son employabilité d'après : un poste, c'est aussi ce qu'il vaudra en partant.
L'onboarding, enfin. Quand livrer la première ligne suppose des semaines à déchiffrer une classe de 800 lignes, le message est clair. Le délai avant le premier commit, les bons le lisent comme un thermomètre de la santé du code.
Rien de tout ça n'est un caprice. C'est quelqu'un qui évalue un risque de carrière et qui répond rationnellement.
Et ça ne s'arrête pas à l'embauche. Le constat que j'entends le plus en mission, c'est : "mon équipe ne veut plus toucher au legacy." Même les gens en place décrochent. Le legacy ne fait pas que repousser les candidats, il use ceux qui restent.
Le cercle vicieux
Le pire, c'est que la situation ne reste pas stable. Elle s'aggrave toute seule.
Regardez l'engrenage. Le code fait peur, donc les bons candidats passent leur chemin. Vous recrutez alors ce qui reste : des juniors qu'il faut former, ou des prestataires de passage qui facturent une prime de risque et repartent au bout de six mois. Ni les uns ni les autres n'ont le temps de redresser le fond. Donc le code empire. Donc il fait encore plus peur. Donc le recrutement suivant est encore plus dur.
Chaque tour de manivelle resserre l'étau.
On a l'habitude de chiffrer la dette technique en jours de maintenance et en bugs. C'est juste, mais incomplet. La dette technique se chiffre, et l'une de ses lignes les plus chères ne se lit pas dans le code : c'est la difficulté à recruter. Une monnaie qu'on n'avait pas vue venir.
Chaque mois où l'on repousse la modernisation ne coûte pas que des heures de dev. Il coûte en attractivité. Votre dette technique est devenue une dette de recrutement, et celle-là, aucune rallonge de salaire ne la rembourse vraiment.
Moderniser, c'est votre meilleure stratégie de recrutement
La bonne nouvelle, c'est que le levier est entre vos mains. Pas dans le marché, pas dans les grilles de salaire. Dans votre code.
Rendre une base "hireable", capable d'attirer un bon développeur, c'est le levier de recrutement le plus durable que je connaisse. Un PHP 8 typé, un filet de tests sur les flux sensibles, une CI à chaque commit : ce poste-là, vous n'avez presque plus besoin de le vendre. Un bon dev reconnaît tout de suite un environnement où il pourra travailler sereinement.
Et il ne s'agit pas de tout réécrire. La réécriture totale est souvent le piège inverse, aussi coûteux que l'immobilité. Dans la plupart des cas, il suffit de remonter la version, de poser un filet là où ça compte, et de découper les premières zones critiques. Remonter un legacy sur PHP 8 de façon outillée, c'est le premier pas concret, et il est plus accessible qu'on ne le croit.
Le code n'a pas besoin d'être parfait. Juste de ne plus faire peur.
Et le bénéfice joue dans les deux sens : un code qu'on n'a plus honte de montrer en entretien attire les candidats, et il retient ceux qui sont déjà là. On ne recrute pas seulement mieux. On garde mieux.
Bref
Soyons honnêtes jusqu'au bout. Moderniser ne remplira pas votre poste demain matin, c'est un chantier, pas un coup de baguette. Et augmenter le salaire ne règle pas le fond : le mercenaire bien payé encaisse la prime et repart quand même, parce que ce qui le fait fuir n'est pas sur la fiche de paie. C'est un investissement, pas un sparadrap.
Mais c'est le seul levier qui tient dans la durée.
Alors si vous galérez à recruter en PHP, ne blâmez pas le marché, il se porte bien. Ne blâmez pas le langage, il s'est modernisé sans vous. Regardez plutôt ce que vous demandez concrètement à un candidat d'accepter en signant. C'est presque toujours là que ça se joue. Et ça, je le répète, ça se répare.