La parole est aux speakers : Loïck Piera

Publié le

Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Sous le capot de Castor, le task runner PHP

Castor, c’est ce task runner open source que nous avons créé chez JoliCode pour exécuter des tâches aussi simplement qu'avec make.

Derrière cette simplicité apparente, le projet cache une mécanique interne plus riche qu’il n’y paraît :

  • une bonne quantité d’exemples qui servent à la fois d’inspiration pour les utilisateurs, d’illustration pour la documentation, mais surtout de suite de tests automatisés ;
  • une documentation toujours à jour avec les fonctionnalités ;
  • un système de release avec phars et binaires construits automatiquement.

Dans ce talk, je vous emmène sous le capot de Castor pour montrer comment tout cela s’articule, les choix techniques qui ont guidé sa conception, et quelques astuces glanées au passage.

E.S.G.I.
22/05/2026
12:00-12:20

Quand on touche à l’outillage, la Developer Experience est scrutée à la loupe. Est-ce que concevoir pour des ‘faiseurs d’outils’, c’est s’exposer au public le plus impitoyable ?

C’est un public exigeant, oui, parce que sur un outil comme Castor, la Developer Experience n’est pas un bonus : c’est le cœur du produit.
Mais cette exigence commence chez nous. Nous sommes les premiers utilisateurs de Castor. Il est utilisé au quotidien par nos équipes, y compris par des devs en dehors de la « core-team », et qui ne s’intéressent pas à ses internals. Pour eux, l’outil doit être évident dès la première utilisation. Il doit fonctionner sans configuration excessive, sans surprise, et avec des comportements cohérents.
Cela nous oblige à être très rigoureux sur la conception interne. Si la structure est floue ou les règles implicites, ça se ressent immédiatement dans l’usage : dans la documentation, dans l’autocomplétion, dans la manière dont on découvre les tâches disponibles. Une bonne DX n’est pas une couche ajoutée après coup, c’est la conséquence directe d’un modèle clair et stable.
Au final, concevoir un outil d’outillage, c’est surtout chercher à réduire la friction au maximum. Si on y parvient pour nos propres équipes, c’est généralement bon signe pour toutes les autres.

Il existe Make, Ant, des scripts Bash… Pourquoi est-ce important pour un·e dev PHP d’avoir un outil écrit en PHP pour gérer ses tâches ? C’est une question de confort ou de puissance ?

Ce n’est pas une croisade contre Make, Bash. Ces outils ont fait leurs preuves et restent parfaitement adaptés dans beaucoup de contextes.
En revanche, ils supposent d’être à l’aise avec un autre paradigme, un autre écosystème, parfois un autre modèle mental. Pour beaucoup de devs PHP, surtout ceux qui travaillent principalement dans cet univers, écrire du Bash avancé ou maintenir un Makefile complexe n’est ni naturel ni agréable. Ce n’est pas une question de compétence, mais d’habitude et de contexte.
Proposer un task runner en PHP, c’est offrir une alternative viable à ceux qui vivent déjà dans cet écosystème. Ils bénéficient de leurs outils habituels : IDE, autocomplétion, refactoring, analyse statique, tests. Ils peuvent structurer leurs tâches avec les mêmes abstractions que leur code applicatif. On ne leur demande pas de changer de langage pour orchestrer leur projet.
L’objectif n’est pas de remplacer Make pour tous les devs et tous les workflows du monde. C’est d’apporter une solution cohérente et intégrée pour celles et ceux qui travaillent déjà en PHP et veulent que leur outillage parle le même langage que leur application.

Avec les outils IA, on fait de moins en moins d’intervention manuelles sur nos projets et on a donc de moins en moins besoin d’un task runner. Est-ce que ce genre d’outil a un avenir à tes yeux ?

L’IA change la manière dont on écrit du code, mais elle ne supprime pas le besoin de structurer l’exécution d’un projet.
Un task runner ne sert pas uniquement à éviter de taper des commandes à la main. Il formalise les conventions d’un projet : comment on build, comment on teste, comment on déploie, comment on maintient. Il offre un point d’entrée stable et partagé, que ce soit pour un humain, un script ou demain une IA.
De notre côté, on réfléchit déjà à la manière d’intégrer des approches comme le MCP pour permettre à des agents d’interagir proprement avec Castor. L’idée n’est pas de contourner l’outil, mais au contraire d’en faire une couche d’orchestration claire, sur laquelle l’automatisation peut s’appuyer.
Plus l’automatisation progresse, plus il devient important d’avoir un centre de gravité explicite dans le projet. Sinon, on accumule des scripts générés et des conventions implicites. À mes yeux, les task runners ne disparaissent pas avec l’IA : ils deviennent l’interface structurante entre le projet et les différentes formes d’automatisation.

Une conférence présentée par

Loïck PIERA
Loïck PIERA
Développeur web chez JoliCode, Loïck travaille au quotidien avec PHP, Symfony, JavaScript, React. Pratiquant une veille quotidienne, Loïck surveille particulièrement les évolutions de PHP et Symfony, mais s’intéresse aussi à tout ce qui touche au Web, aux bonnes pratiques de développement, etc. Il participe à différents projets Open Source et, au sein de JoliCode, a l’occasion de mettre en pratique son goût pour la qualité et le travail bien fait.

Autres interviews