# Checklist avant d’ouvrir une extension propriétaire à des développeurs externes

> Faut-il vraiment donner un accès complet au dépôt avant d'avoir vérifié ces points ? Pour une agence qui externalise une partie du développement, la liste de vérifications avant de partager le code.

- Auteur : Clément Hadrot
- Publié le : 2025-09-26
- Mis à jour le : 2025-09-26
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/checklist-extension-proprietaire-developpeurs-externes/

## L’essentiel

- Un accès complet au dépôt n'est jamais le premier réflexe à avoir
- La documentation interne doit exister avant l'arrivée du prestataire
- Les secrets doivent être hors du dépôt avant tout partage

Faut-il donner un accès complet au dépôt Git dès le premier jour d'une collaboration avec un développeur externe ? La réponse la plus sûre est non — pas avant d'avoir vérifié une série de points qui, une fois oubliés, deviennent bien plus difficiles à corriger une fois le code déjà partagé. Cette checklist s'adresse à une agence qui externalise une partie du développement d'une extension propriétaire, sans pour autant la vendre en marque blanche.

Elle ne couvre pas la publication sur WordPress.org, qui impose ses propres règles de revue et de licence : ici, il s'agit d'un code qui reste la propriété de l'agence, partagé à des fins de développement, pas de distribution.

## 1. Vérifier qu'aucun secret ne traîne dans l'historique Git

Un dépôt actif depuis plusieurs années contient presque toujours, quelque part dans son historique, une clé d'API ou un mot de passe commité par erreur puis supprimé dans un commit ultérieur — sans que cela n'efface la trace dans l'historique. Un simple `git log -p` ciblé sur des motifs suspects, ou un outil de recherche de secrets dans l'historique complet, doit être exécuté avant tout partage d'accès.

```
git log --all -p | grep -iE "(api[_-]?key|secret|password|token)\s*=\s*['\"]"
```

Si un secret est trouvé, sa simple suppression du fichier actuel ne suffit pas : il doit être révoqué et régénéré, l'historique restant consultable par quiconque a accès au dépôt complet.

## 2. S'assurer que les identifiants de production ne sont jamais versionnés

Les constantes de connexion à la base de données, les clés de chiffrement propres à l'environnement de production, ou les identifiants d'un service tiers ne doivent exister que dans un fichier de configuration local, ignoré par Git, jamais dans le code partagé. Un fichier `wp-config-sample.php` ou un fichier d'exemple de constantes suffit à documenter la structure attendue sans exposer de valeur réelle.

## 3. Documenter l'architecture avant l'arrivée du prestataire, pas après

> L'essentiel à retenir : Un accès complet au dépôt n'est jamais le premier réflexe à avoir ; La documentation interne doit exister avant l'arrivée du prestataire ; Les secrets doivent être hors du dépôt avant tout partage

Un développeur externe qui découvre un code sans aucune documentation passe ses premiers jours à reconstituer, par lecture pure, une architecture que l'équipe interne connaît déjà par cœur. Un document court — schéma des principales classes, liste des hooks exposés, conventions de nommage des capacités personnalisées — réduit ce temps d'appropriation de façon significative, et évite surtout que le prestataire ne réinvente une convention déjà en place ailleurs dans le code.

## 4. Définir précisément le périmètre d'accès accordé

Un accès complet au dépôt n'est pas toujours nécessaire. Un accès limité à une branche de fonctionnalité, avec revue de code obligatoire avant fusion vers la branche principale, protège à la fois la stabilité du produit et la confidentialité des parties du code non concernées par la mission confiée.

- Accès en lecture seule au dépôt complet, en écriture uniquement sur une branche dédiée.
- Revue de code obligatoire avant toute fusion, y compris pour des correctifs mineurs.
- Environnement de test isolé, sans copie de données de production réelles.

## 5. Vérifier la licence des dépendances tierces incluses

Certaines dépendances embarquées dans une extension propriétaire ont été choisies sous une licence compatible avec un usage interne, mais qui devient problématique dès qu'un tiers externe y a accès et peut potentiellement les réutiliser ailleurs. Un audit rapide du fichier `composer.json` et de son verrou associé permet de vérifier qu'aucune dépendance ne pose de problème dans ce nouveau contexte de partage.

## 6. Prévoir la révocation d'accès dès la fin de mission

La procédure de révocation doit exister avant même que l'accès ne soit accordé, pas être improvisée le jour où la mission se termine. Elle couvre l'accès au dépôt, mais aussi les accès annexes souvent oubliés : environnement de préproduction, outil de suivi de tickets, éventuel accès à un service de déploiement continu.

## 7. Anonymiser tout jeu de données de test transmis

Si le prestataire a besoin d'un jeu de données réaliste pour reproduire un comportement, ce jeu de données doit être anonymisé avant transmission — noms, e-mails et identifiants remplacés par des valeurs factices générées, plutôt qu'un export brut de la base de production. Un script de transformation systématique, exécuté à chaque nouvel export, évite qu'une donnée personnelle réelle ne circule inutilement.

## En résumé

Sept vérifications suffisent à couvrir l'essentiel avant d'ouvrir une extension propriétaire à un développeur externe : historique Git purgé de tout secret, identifiants de production hors du dépôt, documentation d'architecture prête en amont, périmètre d'accès précisément défini, licences des dépendances vérifiées, procédure de révocation planifiée, et données de test anonymisées. Aucun de ces points ne demande d'outil coûteux — seulement de la discipline appliquée avant le partage, plutôt qu'après un incident.