Introduction
laravel/doctor est le package officiel qui diagnostique les problèmes courants de configuration, d’environnement et d’infrastructure dans une application Laravel. La version 0.1.0 est sortie le 28 juillet 2026. Chaque diagnostic est une vérification unitaire. Par exemple, on peut vérifier « Laravel peut-il écrire dans le répertoire storage ? » et obtenir l’un des statuts prévus. Lorsqu’un correctif sûr et déterministe est possible, il est proposé automatiquement ; sinon (par exemple un échec de build d’assets), une marche à suivre (remediation) est présentée.Exécution
Une fois le package installé, la commande Artisandoctor est disponible.
--fix.
.env, génération de APP_KEY, désactivation du mode debug en production, ajout de .env à .gitignore, création du storage:link, ajustement des permissions d’écriture dans storage, etc.
Les correctifs ne sont disponibles que dans les formats de sortie CLI et « agent ». Pour les formats JSON et GitHub, la commande refuse
--fix afin de garantir que le rapport machine-lisible n’entraîne aucune modification de l’application.--bail interrompt l’exécution au premier diagnostic en échec ou en erreur.
Statuts des diagnostics
Chaque diagnostic renvoie l’un des statuts suivants.
Par défaut, un
fail ou un error fait sortir la commande en échec. Avec --fail-on=warn, les avertissements font aussi échouer ; avec --fail-on=never, la commande se contente de rapporter les problèmes.
Sélection des diagnostics
Vous pouvez sélectionner ou exclure des diagnostics par nom de classe, par groupe, par package ou par joker de package.Modes d’environnement
Une filesync est raisonnable en développement local, mais en production cela signifie que les jobs sont exécutés de manière synchrone dans la requête HTTP. Pour tenir compte de ce type de nuance, Doctor résout l’application dans l’un des deux modes suivants : local ou production.
Les noms d’environnement standard de Laravel (
local, production, staging) sont détectés automatiquement. Pour d’autres noms, groupez-les par mode dans le fichier de configuration.
Diagnostics fournis en standard
Doctor est livré avec une suite de diagnostics couvrant notamment :- Environnement — présence du
.env,APP_KEY, version de PHP, extensions requises, timezone. - Composer — installation des dépendances, optimisation de l’autoloader, correction automatique du
composer.lock. - Configuration — lecture et mise en cache du fichier de configuration, valeurs requises par les drivers activés.
- Base de données — accessibilité des connexions, existence du fichier SQLite, exécution automatique des migrations en attente.
- Cache, files, scheduler, sessions — accessibilité des drivers configurés, détection d’une file
syncen dehors du mode local. - Storage — accessibilité du disque par défaut, permissions d’écriture des répertoires nécessaires, présence du
storage:link. - Sécurité — cohérence entre le mode debug et l’environnement, présence du
.envdans.gitignore, audit des dépendances Composer.
Créer un diagnostic personnalisé
Il suffit d’étendreLaravel\Doctor\Diagnostic et d’implémenter la méthode check(). La commande Artisan make:diagnostic permet aussi de générer le squelette.
APP_KEY et la génère si elle est absente.
fixOptions(). Le CLI affiche alors une liste de choix et la valeur sélectionnée est transmise à fix().
Skip — leave unfixed). Si un libellé « conserver l’état actuel » est plus explicite, précisez-le via decline.
Helpers de diagnostic
Comme de nombreuses applications ou packages écrivent le même type de vérifications, Doctor fournit des helpers pour les motifs les plus courants dans l’espace de nomsLaravel\Doctor\Support.
Le helper Configured lit défensivement une valeur de configuration. Un diagnostic doit pouvoir inspecter une application dont la configuration est cassée sans lever d’exception avant d’avoir pu rendre son rapport ; contrairement aux accesseurs typés du dépôt de configuration, ces méthodes ne lèvent pas d’exception face à un type inattendu.
ActiveDrivers résout les drivers « wrappers » (comme un canal de log par défaut stack ou un mailer failover) vers les canaux ou mailers concrètement utilisés.
Details met en forme les preuves à joindre via withDetails(). Details::bullets() transforme une liste de chaînes en puces, Details::failures() en messages d’échec clefés, et Details::processOutput() sélectionne le flux de sortie le plus pertinent d’un processus terminé.
Exécution programmatique
Vous pouvez appelerDoctor::run() sans passer par la commande Artisan.
fixUsing. Le callback reçoit le diagnostic en échec qui propose un correctif ; renvoyer false saute le correctif, true applique le correctif standard, ou renvoyer une valeur d’option applique ce choix spécifique. Une fois un correctif appliqué, Doctor relance le diagnostic pour refléter l’état dans le rapport.
Formats de sortie et compatibilité avec les agents IA
Par défaut, Doctor produit une sortie CLI lisible, mais vous pouvez choisir un format JSON ou des annotations GitHub Actions.fixable: true peuvent être résolus en relançant avec --fix. Pour tester ce format hors d’un agent, exécutez AI_AGENT=test php artisan doctor.
Conclusion
laravel/doctor permet, via une simple commande php artisan doctor, d’identifier rapidement les problèmes de configuration, d’environnement et d’infrastructure d’une application. Sa bonne intégration avec les agents de code IA — via une sortie conforme aux conventions de Laravel PAO — en fait aussi un candidat sérieux pour les pipelines CI/CD et les workflows d’auto-remédiation pilotés par un agent.
Dépôt laravel/doctor
Le code source et les dernières informations.