Quel poste ouvrir quand une agence de douze personnes décide d’arrêter de confier son parc de soixante sites WordPress à un hébergeur infogéré, pour reprendre la main sur des serveurs qu’elle gère elle-même ? La question s’est posée concrètement l’an dernier, au moment où le coût cumulé des offres infogérées a dépassé ce que coûterait un salaire à temps plein dédié à cette charge.
Ce billet revient sur le recrutement de ce premier poste d’administrateur système interne, les critères qui se sont révélés pertinents et ceux qui ont été abandonnés en cours de route, une fois confrontés à la réalité d’un parc composé presque exclusivement de sites WordPress mutualisés puis progressivement migrés vers des VPS dédiés.
Le profil recherché n’était pas celui affiché initialement
L’offre d’emploi initiale demandait une expérience confirmée en administration de clusters Kubernetes et en infrastructure as code. Après plusieurs entretiens décevants, avec des candidats solides sur ces sujets mais sans jamais avoir touché à un environnement PHP-FPM ou à une base MySQL de production, l’offre a été entièrement réécrite.
Le second jet demandait une expérience généraliste : Linux en administration quotidienne, une base solide en réseau (DNS, TLS, pare-feu), une pratique réelle de MySQL au-delà des requêtes simples, et une aisance avec les outils de scripting shell. L’infrastructure as code (Ansible, Terraform) a été reclassée en compétence secondaire, à acquérir sur place plutôt qu’en prérequis bloquant.
Tester sur un incident rejoué plutôt que sur des questions théoriques
Le test technique le plus discriminant n’a pas été un questionnaire, mais la reproduction d’un incident réel déjà survenu sur le parc : un site qui affichait une page blanche après une mise à jour de plugin, avec un journal d’erreurs PHP-FPM tronqué à dessein pour forcer le candidat à chercher ailleurs (journal MySQL, journal nginx, espace disque disponible).
- Les candidats qui posaient des questions de clarification avant de se jeter sur une commande ont systématiquement mieux performé que ceux qui exécutaient des commandes au hasard.
- Savoir lire un journal d’erreurs PHP et distinguer une erreur fatale d’un simple avertissement s’est révélé plus déterminant que la maîtrise d’un outil d’orchestration avancé.
- La capacité à expliquer, en quelques phrases claires, ce qui vient d’être diagnostiqué compte presque autant que le diagnostic lui-même : ce poste implique de rassurer des chefs de projet non techniques en pleine astreinte.

Le piège du recrutement solitaire sur un poste critique
Une agence qui internalise l’hébergement commet souvent une erreur de structure avant même l’erreur de recrutement : ouvrir un poste unique, sans doublure ni période de transmission avec l’ancien prestataire infogéré. Le premier recrutement de cette agence a bien failli reproduire cette erreur, avant qu’un délai de transition de trois mois avec l’ancien hébergeur ne soit négocié pour permettre une passation encadrée.
Pendant ces trois mois, l’ancien prestataire est resté joignable en astreinte de secours, tandis que la nouvelle recrue prenait progressivement en charge les incidents mineurs, en doublure sur les incidents plus sérieux. Cette période a duré six semaines avant la première astreinte assurée seule, un délai jugé a posteriori nécessaire plutôt qu’excessif au vu de la sensibilité du parc concerné (plusieurs sites e-commerce actifs).
Ce qui aurait dû être anticipé plus tôt
La documentation du parc existant était quasi inexistante côté agence : les accès, les particularités de chaque site, les correctifs déjà appliqués vivaient uniquement dans la tête du gérant qui avait suivi le dossier avec l’ancien hébergeur. Le nouveau salarié a dû reconstruire cette documentation en parallèle de sa prise de poste, ce qui a ralenti son autonomie de plusieurs semaines par rapport au calendrier initialement prévu.
Un parc repris sans documentation coûte, à l’internalisation, le double du temps qu’aurait pris sa rédaction en amont par l’équipe qui le connaissait déjà.
Le salaire proposé a dû être révisé à la hausse
La première fourchette salariale envisagée s’appuyait sur des grilles d’administrateur système généraliste, sans tenir compte de la prime que représente, sur ce marché de l’emploi, une expérience spécifique WordPress à l’échelle d’un parc. Deux candidats solides ont décliné l’offre initiale pour cette raison précise, avant qu’un ajustement de la grille salariale ne permette de conclure le recrutement avec un troisième profil.
Pour aller plus loin
Recruter pour un poste d’administration système dédié à un parc WordPress ne ressemble pas à un recrutement d’administrateur système généraliste classique : la polyvalence pèse plus que la profondeur d’expertise sur un seul sujet, et la capacité à diagnostiquer méthodiquement compte davantage que la connaissance par cœur d’une commande. Le parcours d’intégration, avec une période de doublure suffisamment longue avant la première astreinte solitaire, s’est révélé au moins aussi déterminant que la sélection du candidat elle-même.