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

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

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.