Le 4 septembre 2026, Taylor Otwell a désactivé l’onglet Issues sur la plupart des paquets open source de Laravel. La consigne adressée aux utilisateurs est directe : décrire le bug à un agent de code et ouvrir une pull request, au lieu de rédiger un ticket. Le dépôt principal du framework n’est pas concerné, mais la décision relance le débat sur la maintenance des projets open source à forte audience.
Ce que Taylor Otwell a modifié
Le changement porte sur les paquets first-party de l’écosystème, ceux qui gravitent autour du framework sans en constituer le cœur. Sur ces dépôts, l’onglet Issues de GitHub n’accepte plus de nouveaux tickets. Le dépôt laravel/framework reste en dehors du périmètre : il continue de recevoir des signalements de la manière habituelle.
La justification tient en une phrase, assumée par le mainteneur : un bug se documente désormais mieux par un correctif proposé que par une description laissée en attente. La charge de tri des tickets, souvent citée comme le premier facteur d’épuisement des mainteneurs, se trouve ainsi reportée en amont, du côté de la personne qui rencontre le problème.
« Si vous rencontrez un bug, décrivez-le à un agent de code et ouvrez une pull request. Même si le code n’est pas parfait, ce n’est pas grave : le code peut être itéré. »
« Décrire le bug, ouvrir une PR » : le flux attendu
Le principe déplace le point d’entrée d’une contribution. Là où un ticket ouvrait une discussion, la pull request devient l’unité de signalement : elle porte à la fois la description du problème et une première tentative de résolution. La qualité initiale du correctif passe au second plan, puisqu’il pourra être repris en revue. Concrètement, le parcours proposé s’appuie sur l’outillage en ligne de commande habituel.
# Plus de ticket : une branche, un correctif décrit à un agent, une PR
git checkout -b fix/cas-limite
# le correctif est généré puis relu localement, les tests rejoués
git commit -am "Corrige la gestion du cas limite sur le cache"
# la pull request documente le bug ET propose la solution
gh pr create --fill --base mainSymfony prend le chemin inverse
La mesure tranche avec une partie de l’écosystème PHP. Plusieurs projets, Symfony en tête, conservent au contraire l’ouverture de tickets comme porte d’entrée, en confiant l’écriture du correctif à leurs équipes ou à des outils internes. Deux stratégies opposées se dessinent donc face au même constat : le volume de signalements dépasse la capacité de traitement des mainteneurs bénévoles.
| Projet | Signalement d’un bug | Rédaction du correctif | Rôle confié à l’IA |
|---|---|---|---|
| Paquets Laravel | Pull request directe | Le contributeur | Générer la proposition de correctif |
| Paquets Symfony | Ticket classique | L’équipe du projet | Assister côté mainteneur |
| Dépôt laravel/framework | Ticket classique | Le mainteneur | Non imposé |
Ce que la mesure change pour la contribution
Pour le mainteneur, le gain est immédiat : moins de tickets à trier, un dépôt où chaque entrée arrive déjà accompagnée d’un diff exécutable. Pour le contributeur, l’effort demandé augmente. Signaler un bug ne se résume plus à décrire un symptôme : il faut produire une branche, un correctif et, idéalement, un test. L’agent de code abaisse cette barrière sans la supprimer, et l’approche suppose que la personne concernée dispose d’un tel outil et sait le piloter.
Point de vigilance. Un bug qu’un utilisateur sait décrire mais pas corriger risque de ne jamais être remonté. La bascule peut aussi transférer la charge du tri vers la revue, si l’afflux de pull requests approximatives se substitue à celui des tickets. La traçabilité d’un problème dépend alors de la qualité de la PR qui le porte.
Ce qu’il faut retenir
Laravel ferme les tickets de ses paquets satellites et fait de la pull request assistée par IA la nouvelle porte d’entrée, quand Symfony maintient le ticket et garde la main sur le correctif. Le framework principal, lui, ne bouge pas. Deux visions de la maintenance open source à l’heure des agents de code coexistent désormais, et les prochains mois diront laquelle tient à l’échelle.
Je maintiens quelques dépôts, à une échelle sans commune mesure avec Laravel, et la fatigue du tri de tickets, je la connais. L’idée de recevoir un diff plutôt qu’un « ça marche pas chez moi » a quelque chose de séduisant. Mais je reste prudent : sur mes propres projets, les meilleurs signalements viennent souvent d’utilisateurs qui savent parfaitement décrire un problème sans savoir le résoudre. Fermer cette porte, c’est parier que l’agent de code comblera l’écart pour tout le monde. Le pari est intéressant à observer ; je ne le généraliserais pas encore à un projet dont la communauté n’a pas la culture de la contribution. — Simon Janvier
Pour aller plus loin
Taylor disabled GitHub Issues on most Laravel open-source packages (Laravel News)
