# Une CLI interne d’agence qui enchaîne wp-cli, Composer et Git en une commande

> Concevoir un petit outil maison qui orchestre plusieurs commandes répétitives de mise en route de projet, au-delà d'un script Bash ou d'un Makefile isolé.

- Auteur : Clément Hadrot
- Publié le : 2023-03-13
- Mis à jour le : 2023-03-13
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/cli-interne-agence-wp-cli-composer-git/

## L’essentiel

- Une commande unique masque la complexité de plusieurs outils
- Architecture en sous-commandes extensible dans le temps
- Distribuée à toute l'équipe comme un vrai outil versionné

Un script Bash maison ou un Makefile suffisent pour automatiser la mise en route d'un projet unique. Mais dès qu'une agence accumule plusieurs de ces automatisations, pour des besoins différents (initialisation de projet, synchronisation de base, publication d'une release, audit de sécurité), ces scripts isolés commencent à se multiplier sans cohérence d'ensemble : chacun avec sa propre syntaxe d'appel, son propre emplacement dans les projets, sa propre logique de gestion d'erreurs. La solution retenue ici a été de construire une vraie CLI interne, nommée simplement `agence`, qui regroupe l'ensemble de ces automatisations derrière une interface de sous-commandes cohérente.

Cette CLI ne remplace ni WP-CLI, ni Composer, ni Git : elle les orchestre, en enchaînant leurs appels respectifs derrière une commande unique adaptée aux besoins récurrents de l'agence.

## Choisir le langage de la CLI

PHP s'est imposé naturellement comme langage d'implémentation, l'équipe étant déjà à l'aise avec ce langage et Composer permettant une distribution simple via un package interne, sur le même modèle qu'un package WP-CLI. Le framework Symfony Console, léger et éprouvé, structure les sous-commandes sans réinventer la gestion des arguments et des options.

## Architecture des sous-commandes

> L'essentiel à retenir : Une commande unique masque la complexité de plusieurs outils ; Architecture en sous-commandes extensible dans le temps ; Distribuée à toute l'équipe comme un vrai outil versionné

```
agence-cli/
├── bin/
│   └── agence
├── src/
│   ├── Command/
│   │   ├── InitCommand.php       # agence init
│   │   ├── SyncCommand.php       # agence sync
│   │   └── ReleaseCommand.php    # agence release
│   └── Application.php
└── composer.json
```

## Un exemple de sous-commande

```
namespace AgenceCli\Command;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Process\Process;

class InitCommand extends Command {
    protected static $defaultName = 'init';

    protected function execute( InputInterface $input, OutputInterface $output ): int {
        $output->writeln( '<info>Clonage du dépôt...</info>' );
        (new Process(['git', 'clone', $input->getArgument('repo')]))->mustRun();

        $output->writeln( '<info>Installation Composer...</info>' );
        (new Process(['composer', 'install']))->mustRun();

        $output->writeln( '<info>Création de la base locale...</info>' );
        (new Process(['wp', 'db', 'create']))->mustRun();

        $output->writeln( '<info>Projet prêt.</info>' );
        return Command::SUCCESS;
    }
}
```

La classe `Process` de Symfony permet d'appeler `git`, `composer` et `wp` comme des sous-processus classiques, en capturant leur code de sortie pour interrompre l'exécution proprement en cas d'échec, plutôt que de continuer sur un état incohérent comme le ferait un script Bash mal gardé.

## Distribuer la CLI à toute l'équipe

Comme pour un package WP-CLI, la distribution passe par un Packagist privé interne, avec une installation globale sur chaque poste :

```
composer global require agence/cli
agence init https://github.com/agence/nouveau-projet.git
```

Chaque mise à jour de la CLI, publiée sous un nouveau tag versionné, se propage à toute l'équipe via une simple commande de mise à jour Composer globale, sans distribution manuelle de fichiers.

## Différence avec un Makefile ou un script Bash

| Critère | Makefile / script Bash | CLI interne dédiée |
| --- | --- | --- |
| Portée | Généralement un seul projet | Toute l'agence, tous projets |
| Gestion d'erreurs | Dépend de la rigueur du script | Structurée, avec codes de sortie |
| Distribution des mises à jour | Copie manuelle ou submodule Git | Composer global, versionné |
| Ajout d'une nouvelle fonctionnalité | Modification directe du script | Nouvelle classe de commande isolée |

> La bascule vers une vraie CLI ne se justifie qu'à partir du moment où plusieurs scripts distincts commencent à se marcher dessus ou à diverger d'un projet à l'autre. Avant ce seuil, un Makefile fait très bien l'affaire.

## Le coût à assumer

Cette architecture demande un vrai investissement initial de conception, largement supérieur à celui d'un script Bash, et introduit une dépendance de plus à maintenir dans le temps (mises à jour de Symfony Console, compatibilité PHP). Elle n'a de sens que si le nombre d'automatisations internes justifie une vraie structuration, avec un propriétaire clairement identifié côté équipe pour la faire évoluer.

## En résumé

Une CLI interne bien conçue transforme une collection dispersée de scripts en un vrai outil d'agence, cohérent et versionné, qui orchestre WP-CLI, Composer et Git derrière une interface unique. C'est un investissement qui ne se justifie qu'à partir d'un certain volume d'automatisations récurrentes, mais qui, une fois ce seuil dépassé, change radicalement la façon dont l'équipe interagit avec ses outils du quotidien.