Qu’est-ce qui change vraiment le jour où une extension jusque-là développée en interne par deux personnes accueille un premier contributeur extérieur à l’agence ? La réponse tient rarement dans la technique pure : le code ne change pas de nature du jour au lendemain. Ce qui change, c’est tout ce qui n’était jamais écrit parce que tout le monde le savait déjà.
Cette checklist rassemble ce qu’il faut mettre en place avant d’accepter une contribution externe sur une extension d’agence, sans viser une publication sur WordPress.org : le cadre reste privé, réservé à un cercle de développeurs identifiés, mais soumis aux mêmes exigences de rigueur qu’un projet ouvert.
Écrire ce qui n’était jamais écrit
Le premier réflexe consiste à rédiger un guide de contribution, même court. Il doit répondre à des questions concrètes : quelle convention de nommage pour les fonctions et les classes, quel préfixe utiliser pour éviter les collisions, quelle structure de dossiers respecter, quel style de commit est attendu. Un développeur externe ne devine pas ces conventions ; il les applique seulement si elles sont écrites quelque part.
# Convention de nommage — extension-facturation
- Préfixe des fonctions : fact_
- Préfixe des classes : Fact_
- Namespace racine : Agence\Facturation
- Un fichier = une classe, nommé Class-nom-de-la-classe.php
- Tests unitaires obligatoires pour toute fonction de calcul de montantMettre en place une revue systématique, sans la transformer en goulot
La revue de code devient non négociable dès qu’un contributeur externe touche à une extension partagée entre plusieurs sites clients. L’enjeu n’est pas de douter de sa compétence, mais de vérifier que sa modification n’entre pas en conflit avec des contraintes qu’il ne connaît pas forcément, comme un hook déjà utilisé ailleurs dans le parc ou une option dont le format ne peut pas changer sans casser des sites existants.
Pour que cette revue ne devienne pas un frein, il faut définir à l’avance ce qui déclenche systématiquement une revue approfondie, et ce qui peut être validé rapidement :
- Toute modification touchant une fonction publique ou un hook déjà documenté déclenche une revue approfondie.
- Une correction de faute d’orthographe ou de traduction peut être validée sans délai.
- Toute nouvelle dépendance externe (bibliothèque Composer, appel à une API tierce) est soumise à validation avant tout développement, pas après.
Fournir un environnement de test partagé
Sans environnement commun, chaque contributeur teste sur sa propre configuration locale, avec sa version de PHP, ses extensions actives et parfois des données de test différentes. Le résultat classique : « ça marche chez moi », suivi d’un bug en recette qui ne se reproduit pas facilement.
La solution la plus simple reste un environnement conteneurisé versionné avec le dépôt, qui fixe la version de PHP, de MySQL et les extensions WordPress actives par défaut. Un fichier de configuration Docker Compose minimal, accompagné d’un jeu de données de démonstration, suffit pour la majorité des extensions métier.
Ce que révèle souvent l’absence de cet environnement
Sur plusieurs projets d’agence, l’ouverture à un contributeur externe a révélé des dépendances implicites à la configuration du serveur de production, jamais documentées : une limite de mémoire particulière, un module PHP activé par défaut sur l’hébergement historique, ou une variable d’environnement définie manuellement par un développeur senior des années plus tôt. Un environnement partagé oblige à rendre ces dépendances explicites.
Définir un périmètre de contribution clair
Toutes les parties d’une extension ne se prêtent pas également à la contribution externe. Le cœur métier, celui qui calcule un montant ou applique une règle réglementaire, mérite un accès plus restreint qu’un module d’affichage ou une traduction. Séparer explicitement les zones « ouvertes » des zones « sensibles » dans le guide de contribution évite bien des malentendus.
- Identifier les modules à risque métier ou réglementaire élevé et les exclure du périmètre ouvert dans un premier temps.
- Ouvrir en priorité les modules d’affichage, de traduction et d’intégration avec des services tiers non critiques.
- Réévaluer périodiquement ce périmètre à mesure que la confiance avec le contributeur se construit.
La règle qui a le mieux fonctionné chez nous : un contributeur externe commence toujours par un module périphérique, jamais par le cœur de calcul, même s’il en a la compétence technique.
Ce qu’on observe après quelques mois
Les agences qui ont formalisé ce cadre rapportent un bénéfice inattendu : la documentation écrite pour un contributeur externe finit par servir en interne aussi, notamment lors de l’arrivée d’un nouveau salarié. Ce qui semblait être une contrainte imposée par l’ouverture du projet devient, avec le temps, une meilleure organisation générale du code.
Pour aller plus loin
Ouvrir une extension à un contributeur externe n’est jamais une décision purement technique. C’est avant tout une décision d’organisation : écrire ce qui était implicite, fixer un périmètre de confiance progressif, et donner à chacun les mêmes outils pour vérifier son travail avant qu’il n’atteigne la production.
