Extensions premium dans Composer : Satis, dépôts privés et licences propres

La première fois qu’un client demande « pourquoi le déploiement a échoué », la réponse est souvent la même : une extension premium comme ACF Pro ou Gravity Forms, installée jadis à la main par FTP, n’existe nulle part dans composer.json. Composer gère très bien les paquets publics de Packagist, mais les extensions payantes du monde WordPress ne s’y trouvent pas — il faut leur trouver un autre chemin.

Cet article détaille trois approches concrètes pour intégrer ces extensions premium dans une gestion de dépendances Composer propre, sans jamais exposer de clé de licence dans un dépôt versionné. La structure Bedrock, qui a ses propres conventions, ne fait pas l’objet de cette discussion.

Le problème des extensions premium avec Composer

Les extensions gratuites du répertoire officiel sont accessibles via le miroir wpackagist.org, qui republie automatiquement tout le contenu de wordpress.org au format Composer. Les extensions premium, elles, ne sont distribuées que par téléchargement direct sur le compte client, souvent protégé par une clé de licence unique. Composer ne sait pas nativement où aller les chercher.

• ACF Pro propose une URL de téléchargement paramétrée par une clé, exploitable comme dépôt de type package
• Gravity Forms fournit un dépôt Composer privé officiel, authentifié par clé de licence
• D’autres extensions n’offrent qu’un zip à télécharger manuellement, sans aucune API

Méthode 1 : dépôt de type package avec URL paramétrée

Pour ACF Pro, on déclare un dépôt personnalisé dans composer.json qui décrit où trouver l’archive :

{
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "advanced-custom-fields/advanced-custom-fields-pro",
        "version": "6.0.0",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "https://connect.advancedcustomfields.com/v2/plugins/download?token={%ACF_PRO_KEY}"
        },
        "require": {
          "composer/installers": "^2.0"
        }
      }
    }
  ]
}

Le jeton {%ACF_PRO_KEY} est remplacé au moment de l’installation par une variable définie dans le fichier auth.json, jamais commité :

composer config --global http-basic.connect.advancedcustomfields.com token "VOTRE_CLE"

Ou plus simplement, en variable d’environnement lue par un script de déploiement CI qui écrit auth.json à la volée juste avant composer install.

Méthode 2 : dépôt Composer privé officiel

Gravity Forms propose un vrai dépôt Composer hébergé, avec authentification HTTP par clé de licence :

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://asset-manager.gravityforms.com"
    }
  ],
  "require": {
    "gravityforms/gravityforms": "^2.7"
  }
}

L’authentification se configure dans auth.json, généré dynamiquement :

{
  "http-basic": {
    "asset-manager.gravityforms.com": {
      "username": "VOTRE_CLE_LICENCE",
      "password": ""
    }
  }
}

Méthode 3 : Satis, un miroir privé maison

Pour les extensions qui ne proposent aucune API et se limitent à un zip téléchargeable, Satis — l’outil officiel de Composer pour créer un miroir statique — devient la solution la plus robuste. On héberge un petit dépôt Satis sur un serveur privé, alimenté manuellement à chaque nouvelle version de l’extension :

{
  "name": "monagence/satis-prive",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/monagence/wrapper-extension-x" }
  ],
  "require": {
    "monagence/extension-x": "*"
  }
}

La commande satis build satis.json web/ génère un répertoire statique servable par n’importe quel serveur HTTP, protégé par une authentification basique. Chaque projet client référence ensuite ce miroir comme dépôt Composer additionnel.

Ne jamais committer une clé de licence

Le piège classique : coller la clé ACF Pro directement dans composer.json « pour que ça marche vite », puis l’oublier là pour toujours dans l’historique Git. Même après suppression, la clé reste consultable dans les anciens commits tant que l’historique n’est pas réécrit.

Sur chaque nouveau projet, je vérifie systématiquement que auth.json figure dans .gitignore avant même d’écrire la première ligne de code applicative. C’est un réflexe qui coûte dix secondes et qui évite des révocations de licence en urgence.

Bonnes pratiques pour la gestion des secrets :

1. Ajouter auth.json au .gitignore dès l’initialisation du projet
2. Stocker les clés dans le gestionnaire de secrets de la CI (variables protégées GitHub Actions, GitLab CI/CD variables)
3. Générer auth.json à la volée pendant le pipeline, juste avant composer install
4. Documenter dans le README interne où récupérer chaque clé, sans jamais la reproduire en clair

En résumé

Composer sait parfaitement gérer les extensions premium WordPress, à condition de choisir la bonne méthode d’accès selon ce que propose l’éditeur — URL paramétrée, dépôt privé officiel, ou miroir Satis maison en dernier recours. Dans tous les cas, la règle ne change jamais : la clé de licence vit dans un secret de CI ou un auth.json local ignoré par Git, jamais dans l’historique du projet.