Un développeur seul sur un projet WordPress peut se permettre une certaine souplesse dans son organisation. Une équipe de quatre ou cinq personnes qui interviennent sur le même site pendant des mois, en revanche, a besoin de règles explicites — pas par bureaucratie, mais parce que l’absence de convention se traduit toujours, tôt ou tard, par un conflit de fusion douloureux ou une régression silencieuse.
Voici comment on structure le travail d’équipe sur nos projets suivis dans la durée, après plusieurs ajustements consécutifs à des incidents bien réels.
Une convention de branches simple et non négociable
On utilise une variante allégée de Git Flow, avec trois types de branches clairement identifiés par leur préfixe :
feature/nom-de-la-fonctionnalitepour tout développement en cours, jamais déployé directementfix/description-du-bugpour les corrections, y compris les correctifs urgentsmainetdevelopcomme branches protégées, jamais de commit direct, uniquement via fusion de pull request
Les branches protégées sur GitHub ou GitLab empêchent techniquement tout commit direct ou toute fusion sans revue — la convention seule ne suffit jamais, il faut aussi l’appliquer techniquement, sans quoi elle finit oubliée sous la pression d’un délai serré.
La revue de code, un filet de sécurité assumé
Toute fusion vers develop ou main nécessite l’approbation d’au moins un autre développeur, et deux pour tout ce qui touche à la structure de la base de données ou à la logique de paiement sur nos projets e-commerce. Ce n’est pas une question de confiance envers l’auteur du code : c’est la reconnaissance que personne ne repère toutes ses propres erreurs, et qu’un regard extérieur détecte régulièrement des problèmes qui auraient autrement atteint la production.
# Modèle de description de pull request qu'on utilise systématiquement
## Quoi
Description courte de ce que fait ce changement.
## Pourquoi
Le contexte ou le ticket qui justifie ce changement.
## Comment tester
Étapes précises pour vérifier que ça fonctionne.
## Points d'attention pour le relecteur
Ce qui mérite une attention particulière (migration de données,
changement de comportement existant, etc.)Ce modèle, imposé via un fichier .github/pull_request_template.md, réduit considérablement les allers-retours entre auteur et relecteur : la majorité des questions qu’un relecteur poserait spontanément trouvent déjà leur réponse dans la description.
Documenter les décisions, pas seulement le code
On tient, pour chaque projet suivi plus de quelques mois, un court document de décisions d’architecture — pourquoi Bedrock plutôt qu’une structure classique, pourquoi tel choix de plugin de cache plutôt qu’un autre, pourquoi telle exception à nos conventions habituelles. Sans cette trace, la même question revient régulièrement, posée par un nouveau membre de l’équipe qui n’a pas le contexte historique.
| Élément documenté | Où |
|---|---|
| Choix d’architecture (Bedrock, plugin de cache, etc.) | Fichier DECISIONS.md à la racine du dépôt |
| Procédure de déploiement | README du dépôt, avec le script associé |
| Convention de nommage des branches et commits | Contributing.md, lié depuis le README |
| Accès et identifiants des environnements | Gestionnaire de mots de passe partagé, jamais dans Git |
Le rôle d’un mainteneur technique par projet
Sur les projets qui accueillent plus de trois développeurs, on désigne systématiquement un mainteneur technique référent — pas nécessairement le plus expérimenté, mais celui qui connaît le mieux l’historique du projet. Son rôle n’est pas de tout valider personnellement, mais d’arbitrer les désaccords entre développeurs sur des choix structurants, et de garder une vision d’ensemble que personne d’autre n’a le temps de maintenir au quotidien.
Une convention qui n’est écrite nulle part n’existe pas vraiment. Elle vit dans la tête de celui qui l’a instaurée, et disparaît avec lui le jour où il quitte le projet ou l’équipe.
Standards de code automatisés plutôt que discutés en revue
On a délibérément retiré les questions de style de code (indentation, espacement, conventions de nommage) des discussions de revue de code, en les déléguant entièrement à des outils automatisés — PHP CodeSniffer avec les standards WordPress, ESLint pour le JavaScript. Une revue de code doit porter sur la logique et l’architecture, jamais sur des points qu’un outil peut trancher instantanément et sans subjectivité.
En résumé
Organiser une équipe autour d’un site WordPress tient moins à l’outillage qu’aux conventions qu’on impose de façon cohérente : nommage de branches, revue de code systématique, documentation des décisions structurantes. Ces règles paraissent contraignantes au premier abord, mais elles évitent, sur la durée, la majorité des incidents qu’on a connus sur des projets moins encadrés.
