Un nouveau développeur arrive dans l’équipe un lundi matin. Sur le papier, il doit être capable de contribuer dès l’après-midi. Dans la pratique, sans préparation, sa première journée se résume souvent à chercher des accès manquants, deviner une configuration non documentée, et attendre qu’un collègue plus expérimenté ait le temps de répondre à ses questions entre deux réunions. Cette checklist décrit les huit étapes concrètes qui permettent, sur un projet WordPress existant, d’obtenir un environnement local fonctionnel avant midi, sans improvisation.
Elle suppose qu’un minimum de documentation de projet existe déjà (accès, README) ; son objet est justement de fixer ce minimum de façon reproductible pour chaque nouvel arrivant, quel que soit le projet sur lequel il ou elle atterrit.
1. Un document d’accès centralisé, préparé avant l’arrivée
Avant même le premier jour, la personne responsable de l’onboarding prépare un document unique listant : l’accès au gestionnaire de mots de passe de l’équipe, l’invitation au dépôt Git, l’accès à l’hébergement de démonstration si besoin, et les identifiants d’un compte de messagerie interne. Improviser cette liste le jour même fait perdre un temps précieux dès la première heure.
2. Cloner le dépôt et lire le README avant de toucher au code
Le README du projet doit répondre, sans détour, à trois questions : quel outil d’environnement local utiliser (Docker, Local, un script maison), quelle commande lance le projet, et où trouver un dump de base de données à jour. Si le README ne répond pas à ces trois questions, c’est le premier signal que la documentation du projet doit être corrigée, indépendamment de l’onboarding en cours.
3. Installer les outils de base du poste
- Un gestionnaire de versions PHP/Node (asdf, nvm) ou l’environnement Docker requis par le projet.
- WP-CLI, indispensable pour l’import de base et les commandes courantes.
- Le client Git configuré avec la bonne clé SSH déjà ajoutée au dépôt distant.
4. Lancer l’environnement local
Que ce soit via un docker-compose up, un import dans Local, ou un script maison, cette étape doit se limiter à une seule commande documentée. Si elle en demande plusieurs, la checklist du projet doit les lister dans l’ordre exact, sans supposer de connaissance implicite du fonctionnement interne.
5. Importer une base de données récente
wp db import dump-recent.sql
wp search-replace 'https://production.exemple' 'https://monprojet.test' --all-tablesUn dump vieux de plusieurs mois complique inutilement la compréhension du contenu réel du site : dans l’idéal, ce dump est régénéré automatiquement chaque semaine par une tâche planifiée, avec anonymisation des données sensibles si le projet le justifie.
6. Vérifier l’accès aux extensions premium
Les extensions premium liées à une licence (page builder, extension SEO, extension e-commerce) doivent être installées automatiquement via Composer et un dépôt Satis interne, ou documentées explicitement si elles nécessitent une activation manuelle avec une clé de licence partagée par l’équipe.
7. Faire tourner la suite de tests, même minimale
Lancer les tests existants, même s’il ne s’agit que de quelques vérifications PHPUnit basiques, confirme que l’environnement fonctionne réellement dans les mêmes conditions que le reste de l’équipe, plutôt que de se fier uniquement à l’apparence visuelle du site dans le navigateur.
8. Faire une première contribution guidée
La matinée se termine idéalement par une tâche simple et bien délimitée (corriger un texte, ajuster un style mineur) suivie d’une revue de code par un collègue. Cette première contribution valide que l’environnement complet fonctionne, du code local jusqu’à la pull request, et rassure la nouvelle recrue sur sa capacité à être productive dès le premier jour.
Le signe qu’un onboarding fonctionne bien : la personne qui accueille le nouvel arrivant n’a presque rien à faire d’autre que répondre à des questions ponctuelles, parce que la documentation porte l’essentiel de la charge.
Ce qui fait échouer un onboarding rapide
Les causes les plus fréquentes d’un onboarding qui déborde sur l’après-midi, voire sur plusieurs jours : un README obsolète qui ne correspond plus à l’environnement réellement utilisé, des accès demandés au dernier moment plutôt qu’anticipés, et un dump de base de données introuvable ou corrompu. Aucune de ces causes ne relève d’un problème technique complexe ; elles relèvent toutes d’un manque de préparation en amont de l’arrivée.
Pour aller plus loin
Cette checklist gagne à être versionnée directement dans le dépôt du projet, sous forme d’un fichier ONBOARDING.md distinct du README général, mis à jour à chaque changement d’outillage. Un onboarding qui tient en une matinée n’est pas un coup de chance : c’est le résultat direct d’une documentation maintenue avec la même rigueur que le code lui-même.
