← Tous les articles
Mer. 3 juin 2026 · 4 min de lecture

📡 Laravel PAO : la sortie optimisée pour les agents IA

# Laravel # PAO # PHP # IA # Tooling
Laravel PAO

📚 Introduction

Faire collaborer un agent IA avec une stack PHP suppose qu’il puisse lire la sortie des outils : tests qui échouent, alertes PHPStan, suggestions Rector, retour d’une commande Artisan. Le problème, c’est que ces sorties sont historiquement conçues pour des humains : couleurs ANSI, alignement à la colonne, séparateurs visuels, formats hétérogènes.

Laravel PAO (Agent-Optimized Output) règle ce problème. C’est un wrapper qui réécrit en temps réel la sortie des outils PHP courants dans un format structuré, déterministe et économe en tokens. Et malgré le nom, il fonctionne avec n’importe quel projet PHP : Laravel bien sûr, mais aussi Symfony, Laminas, ou un projet vanilla qui utilise PHPUnit.

🧩 Les outils couverts

PAO sait reformater la sortie de :

  • PHPUnit et Pest (les tests unitaires et fonctionnels).
  • Paratest (l’exécution parallèle des suites de tests).
  • PHPStan (l’analyse statique).
  • Rector (la modernisation automatique de code).
  • Artisan (les commandes Laravel), avec un module dédié qui reconnaît les outputs courants.

À chaque fois, l’idée est la même : retirer le bruit visuel, normaliser le format, et présenter l’essentiel à l’agent.

🚀 Mise en place

Installation classique :

composer require laravel/pao --dev

Et on préfixe ses commandes habituelles :

# À la place de
./vendor/bin/pest
 
# Faire
./vendor/bin/pao pest
 
# Idem pour PHPStan, Rector, Paratest, Artisan
./vendor/bin/pao phpstan analyse
./vendor/bin/pao rector process --dry-run
./vendor/bin/pao artisan migrate --pretend

La sortie devient lisible par un agent sans transformation supplémentaire. Plus besoin de lui demander de “parser” le tableau ASCII de PHPUnit ou de comprendre les couleurs ANSI de PHPStan.

🤖 L’effet concret côté agent

Sur une session Claude Code, voici ce que PAO change concrètement.

Avant PAO, demander “lance les tests et corrige ce qui échoue” produit une longue sortie ANSI, dont l’agent doit extraire à la main les tests en erreur, les fichiers concernés et les messages d’assertion. Les tokens dépensés sont importants, et la précision parfois discutable.

Avec PAO, la sortie est déjà structurée : un objet par test échoué, avec son nom, son fichier, sa ligne, son message et son diff. L’agent attaque directement la correction, sans la phase de parsing. Sur une grosse suite, on observe une réduction nette de la consommation de tokens et un taux de succès plus élevé sur les corrections proposées.

🧠 Combiner PAO avec Boost

C’est la combinaison qui rend l’écosystème vraiment cohérent. Laravel Boost expose l’application Laravel comme un serveur MCP exploitable par l’agent : routes, modèles, schéma de base, exécution Tinker. PAO complète le tableau en exposant la sortie des outils du même projet dans un format que l’agent comprend nativement.

Sur un workflow typique :

  1. L’agent demande à Boost l’état du schéma et des modèles.
  2. Il propose une migration ou une refonte.
  3. Il lance ./vendor/bin/pao pest pour vérifier que les tests passent.
  4. Il lance ./vendor/bin/pao phpstan analyse pour s’assurer qu’il n’a pas introduit de régression statique.
  5. Sur échec, il interprète directement la sortie PAO et corrige.

La boucle “code → test → corrige” se ferme dans une seule conversation, sans qu’on ait à recopier les sorties à la main.

🛠️ Au-delà de l’agent : un format utile aussi pour la CI

Un effet secondaire intéressant : la sortie PAO est aussi un excellent format pour la CI. JSON structuré, pas de dépendance aux couleurs ANSI, facilement parsable par des post-processors. On peut envisager :

  • Publier le résultat de PHPStan sous forme de checks GitHub précis (fichier et ligne par finding).
  • Croiser le résultat de Pest avec les commentaires de PR pour annoter directement les tests cassés.
  • Stocker l’historique d’évolution du coverage ou des findings PHPStan dans un dashboard, sans dépendre d’un fichier de log fragile.

C’est typiquement le type d’évolution qu’on peut intégrer à une pipeline GitHub Actions existante en quelques heures.

⚠️ Quelques précautions

  • Installer en require-dev : comme Pail ou Pint, PAO n’a rien à faire en production.
  • Ne pas pipeline PAO dans un cat | grep : c’est contre-productif. Le format est conçu pour être consommé tel quel par l’agent ou par un parser ciblé.
  • Vérifier les versions des outils sous-jacents : PAO suit les évolutions de PHPUnit, Pest, PHPStan, Rector. Sur un projet avec des versions plus anciennes, vérifier la compatibilité du wrapper.

🎉 Conclusion

Laravel PAO est l’une de ces briques qu’on n’attendait pas mais qui change l’ergonomie une fois adoptée. Pour les équipes qui travaillent avec Claude Code, Cursor ou un agent custom sur un projet PHP, c’est probablement le complément naturel de Laravel Boost : Boost expose l’application, PAO expose les outils, et l’agent peut désormais boucler sur un cycle complet de développement sans intermédiaire.

L’adoption est triviale (un préfixe pao devant les commandes habituelles), réversible immédiatement, et compatible avec n’importe quel projet PHP, pas seulement Laravel. Bref, c’est le genre de package qui mérite d’être ajouté au composer.json cette semaine.

🔗 Liens utiles