Le problème qu'on ne veut pas admettre
Tout développeur PHP a vécu la scène : il faut tester une idée rapide, vérifier le comportement d'un service, valider une requête complexe. Et là, les mauvaises habitudes s'enchaînent — une route jetable, un dd() planqué dans le code, une commande Artisan qu'on supprimera demain.
Ces solutions fonctionnent, mais elles ont toutes le même défaut : elles sortent du contexte réel de l'application. Tinker redémarre à chaque erreur, les routes temporaires finissent parfois en production par accident, et les scripts one-shot encombrent le projet sans jamais vraiment documenter ce qu'ils font.
C'est exactement le problème qu'adresse l'article de Jefferson Silva sur dev.to : et si PHP avait son propre équivalent du Jupyter Notebook, capable de booter le framework entier et d'exposer un environnement persistant, interactif et contextualisé ?
Un REPL qui connaît vraiment votre projet
L'outil présenté — le Task Runner de DDLess — fonctionne différemment des REPL classiques. Il démarre votre framework (Laravel, Symfony, WordPress, ou tout projet PHP custom) et maintient un environnement vivant où tout est disponible : modèles Eloquent ou entités Doctrine, services, configuration, connexions base de données.
On écrit du PHP, on exécute, on voit le résultat. Pas de fichier temporaire, pas de fausse route, pas de redémarrage.
Cette approche n'est pas sans rappeler ce que les data scientists font quotidiennement dans Jupyter : un notebook qui garde l'état en mémoire, accumule les résultats, et permet d'itérer vite sans tout reconstruire à chaque fois.
Cas concrets où ça change vraiment la donne
Exports de données sans commande dédiée
L'exemple le plus parlant de l'article : un export CSV de 17 000 enregistrements avec un formatage métier spécifique. Classiquement, on crée une commande Artisan, on la référence, on l'exécute, on la supprime. Ou on sort PHPSpreadsheet dans un contrôleur qu'on ne devrait jamais exposer.
Avec un Task Runner project-aware, on écrit directement la logique dans l'environnement bootée :
$this->export('points_of_sale', function ($page) {
$records = PointOfSale::with(['segment', 'adfLevel'])
->offset($page * 500)
->limit(500)
->get();
if ($records->isEmpty()) return null;
return $records->map(fn ($r) => [
'Name' => $r->business_name,
'Segment' => $r->segment?->name ?? '-',
'Active' => $r->active ? 'Yes' : 'No',
]);
});
Les modèles sont disponibles, les relations chargées, la pagination gérée — et rien de tout cela ne pollue le dépôt git.
Debugging et inspection sans modifier le code source
Dans un workflow Symfony classique, comprendre pourquoi un service se comporte mal implique souvent d'injecter des logs, de recharger, de lire, de recommencer. Dans un environnement REPL bootée sur le container de services, on instancie directement le service concerné, on lui passe des données de test, on inspecte l'output — sans toucher au code de production.
C'est un gain de temps significatif, mais surtout un gain de clarté : on travaille sur le vrai code, dans le vrai contexte, sans couche d'indirection artificielle.
Prototypage de logique métier complexe
Avant d'implémenter une fonctionnalité lourde — un pipeline de traitement, une règle de facturation, une migration de données — pouvoir itérer librement dans l'environnement réel permet de valider les hypothèses sans écrire une ligne de code définitif. C'est l'équivalent d'un brouillon interactif, mais avec accès à la vraie base et aux vrais services.
Ce que ça implique pour un projet Symfony
Sur nos projets Symfony chez MulerTech, plusieurs patterns bénéficieraient directement d'un tel outil :
- Messenger : tester l'envoi et la consommation de messages sans déployer un worker de test
- Doctrine : explorer des requêtes DQL complexes avec les vrais repositories, pas une connexion PDO nue
- Services injectés : valider le comportement de services avec des dépendances réelles (mailer, HTTP client, cache)
- Fixtures ciblées : générer des jeux de données précis pour un scénario de test sans passer par les fixtures complètes
L'idée n'est pas de remplacer les tests unitaires ou fonctionnels — mais de combler le gap d'exploration qui existe entre "j'ai une idée" et "j'écris le test".
Conclusion
Le Jupyter Notebook a transformé la façon dont les data scientists explorent et documentent leur travail. L'idée de transposer ce paradigme au développement PHP — avec un REPL qui boot le vrai framework, garde l'état, et expose l'environnement complet — répond à un vrai besoin.
DDLess Task Runner est une proposition concrète dans cette direction. Elle mérite l'attention de tout développeur PHP qui a déjà écrit une route temporaire "juste pour tester un truc".
💡 Article original : What if PHP had its own Jupyter Notebook? par Jefferson Silva sur dev.to.
