Un développeur PHP senior, ce n'est pas celui qui aligne Laravel, Symfony et douze ans d'expérience sur son CV. C'est celui dont on peut reprendre le travail un lundi matin sans lui passer un coup de fil. Beaucoup de dirigeants ne regardent ce critère qu'en dernier, au moment où il devient le seul qui compte.
Pourquoi la liste des technos ne prouve presque rien
On me dira que les technos comptent, qu'il faut bien un critère de tri, et qu'un profil qui ignore votre framework vous fera perdre du temps. Un peu, oui. Mais la liste d'outils est la partie du CV la plus facile à gonfler et la plus difficile à vérifier : quelques semaines sur un projet suffisent pour écrire une ligne. Les années d'expérience, elles, mesurent un temps passé, pas ce qu'il en est resté.
Prenons une PME de distribution dont l'outil de commandes a été écrit par un seul freelance, excellent sur le papier. Il part pour un autre contrat. Le code tourne, mais personne n'ose y toucher : aucun test ne dit ce qui casserait, aucune page n'explique comment l'installer. C'est une façon très répandue de se retrouver prisonnier de son propre logiciel, et nous y revenons dans notre article sur changer de prestataire sans rien perdre.
Ce qu'on peut vérifier soi-même
Demandez d'abord à voir le code livré. Pas une démo léchée : un projet en production, même ancien, présenté avec l'accord de son client. Nul besoin d'être développeur pour repérer l'essentiel. Les noms de variables se lisent-ils comme du langage courant ou comme des initiales ? La règle de calcul d'une remise est-elle écrite à un seul endroit, ou recopiée dans six écrans ? Un senior écrit pour celui qui viendra après lui. Cela se voit vite, pourvu que quelqu'un de technique regarde avec vous.
Viennent ensuite les tests. Inutile d'exiger un pourcentage de couverture, ce chiffre ne dit pas grand-chose. Cherchez plutôt si les règles qui touchent à l'argent (prix, TVA, remises, relances) sont protégées par des tests automatiques, ces petits scripts qui vérifient à chaque modification que rien n'a bougé là où il ne fallait pas. Un développeur qui n'en écrit jamais ne vous fait pas gagner de temps. Il le déplace vers votre futur.
Reste la documentation, avec un test tout bête : donnez le projet à quelqu'un d'autre, demandez-lui de l'installer sur une machine vierge en suivant uniquement ce qui est écrit. S'il bute à la deuxième étape, vous avez votre réponse. Même exigence pour la reprise : le dépôt Git doit être à votre nom, l'hébergement aussi, et le déploiement doit pouvoir se refaire sans rituel secret. Quand nous reprenons une application existante, ce sont les premières choses que nous cherchons, bien avant la version de PHP.
Dernier signe, moins technique. Un senior pose des questions sur votre métier avant de parler d'outils. Si la première discussion porte sur vos commandes, vos exceptions, vos habitudes de saisie plutôt que sur le framework, bon signe. C'est tout l'enjeu d'une analyse des besoins avant de développer.
Et s'il ne peut rien montrer ?
L'objection est sérieuse : beaucoup de code est couvert par la confidentialité, et un freelance honnête ne peut pas ouvrir le dépôt d'un ancien client. Soit. Demandez-lui alors de raconter un projet qui s'est mal passé, et ce qu'il ferait autrement aujourd'hui. Celui qui assure que tout s'est toujours bien déroulé n'a sans doute pas beaucoup livré. Les seniors ont des cicatrices, et savent les décrire avec précision.
Si le doute persiste, proposez une courte mission payée plutôt qu'un engagement long : une petite fonctionnalité réelle, livrée avec ses tests et sa notice, sur un dépôt qui vous appartient. Quelques jours payés pour éviter des mois regrettés. C'est ainsi que nous aimons démarrer chez Making Digital, sur pièces, avant de bâtir une application sur mesure qui engage votre activité pour des années. Et si vous voulez regarder un code existant à plusieurs avant de choisir, écrivez-nous.
Questions fréquentes
Faut-il être développeur pour juger le travail d'un développeur PHP ?
Non, mais mieux vaut se faire accompagner pour lire le code. Vous pouvez en revanche contrôler seul l'essentiel : le dépôt est-il à votre nom, la documentation permet-elle d'installer le projet, des tests existent-ils sur vos règles de calcul ?
Freelance ou agence pour développer un logiciel métier ?
Les deux fonctionnent si le travail reste reprenable. Un freelance seul concentre le risque sur une personne, une équipe le répartit, mais dans les deux cas les mêmes garde-fous s'appliquent : code, tests, documentation et accès à votre nom.
Quelles pièces réclamer à la fin d'une mission de développement ?
Le dépôt Git complet avec son historique, les accès à l'hébergement et aux services tiers, une notice d'installation et de déploiement, ainsi que les tests automatiques. Sans ces éléments, le logiciel vous est livré mais pas vraiment remis.