36 voix contre 0, avec 5 abstentions. C'est le résultat du vote de septembre 2025 pour arrêter de recommander PECL et orienter tout le monde vers PIE, le PHP Installer for Extensions. Treize mois plus tard, je parie que la plupart des Dockerfiles dont tu t'occupes contiennent encore une ligne pecl install, et je comprends pourquoi. Ce que je défends, c'est que tu devrais virer ces lignes ce trimestre : en ne fixant aucune date de retrait, la RFC te laisse décider du calendrier, et ce sont ceux qui migrent tôt qui façonnent l'écosystème que les autres trouveront en arrivant.

L'argument inverse est solide, alors je vais lui donner tout son poids. La RFC n'a changé que le discours. PECL fonctionne toujours, rien n'est programmé pour être coupé, et supprimer le site ou l'outil exigerait une autre RFC que personne n'a encore écrite. En plus, tous les paquets PECL n'ont pas sauté le pas : PIE ne trouve que les extensions publiées sur Packagist avec "type": "php-ext" dans leur composer.json, donc si l'une des tiennes n'a pas été portée, tu restes coincé sur PECL pour ce build. Attendre ne coûte rien aujourd'hui. Une personne raisonnable avec un backlog chargé se dit « plus tard » et retourne à son sprint.

C'est là que je ne suis pas d'accord. Ce paquet manquant est justement la raison de migrer maintenant, parce que c'est exactement ce que tu as besoin de découvrir. Passe une image de CI à PIE, regarde quelle installation échoue, et tu obtiens une liste précise des extensions dont les mainteneurs ont besoin d'un coup de pouce ou d'une pull request. Pour l'auteur d'une extension, la correction tient surtout dans un manifeste : un nom, le type php-ext (ou php-ext-zend), une licence, une contrainte de version PHP et un bloc php-ext facultatif avec des clés comme extension-name et configure-options. Ça représente un après-midi de travail pour quelqu'un, et une issue polie venant d'un utilisateur qui a vraiment essayé vaut mieux qu'une année de silence de plus. Si tu ne peux pas attendre le mainteneur, pie repository:add vcs te débloque en attendant.

L'ergonomie au quotidien plaide aussi pour la migration. Les noms passent au format Composer, donc xdebug devient xdebug/xdebug, et la recherche se fait sur packagist.org/extensions, ce qui te paraîtra familier si tu as tapé composer require plus souvent que tu n'as déjeuné. Ce que je préfère, c'est que PIE écrit l'INI à ta place. Dans le tutoriel que j'ai lu, basé sur PIE 1.5.2 avec PHP 8.3, il a déposé un fichier conf.d avec priority=80 et une ligne extension=, puis a indiqué que le module était activé et chargé. J'ai vu plus d'un incident en pleine nuit se résumer à un .so parfaitement compilé que personne n'avait jamais activé. Cette catégorie de bugs vient de rétrécir.

Pour les conteneurs, le modèle proposé dans la doc officielle monte en bind mount le binaire depuis l'image ghcr.io/php/pie:bin le temps d'une seule étape RUN, si bien que PIE ne se retrouve jamais dans ton image finale, et des options comme --auto-install-build-tools et --auto-install-system-dependencies répondent aux invites qui bloqueraient sinon un build non interactif. Sur une machine avec plusieurs versions de PHP, --with-php-config te permet de cibler php-config8.2 alors que PIE lui-même tourne sur n'importe quelle version à partir de 8.1, et il affiche l'installation ciblée en tête de chaque commande. C'est mieux que la vieille routine qui consistait à deviner quel phpize arrivait en premier dans le PATH.

Tout n'est pas parfait, et je préfère que tu découvres les points faibles par moi plutôt que par le diff de ta gestion de configuration. La désinstallation supprime le .so mais laisse le fichier INI en place, avec la ligne commentée et une petite note « removed by PIE ». Je trouve ce choix défendable, puisque supprimer un fichier que tu as peut-être modifié à la main serait pire, mais les utilisateurs d'Ansible et de Puppet verront de la dérive et auront besoin d'une règle de nettoyage. Il te faudra aussi les droits root, parce que le module va directement dans le répertoire d'extensions du système, et la doc reste assez discrète sur les privilèges. Les extensions fournies avec PHP comme gd ou mysqli sont également hors périmètre, donc docker-php-ext-install garde son rôle. Rien de tout ça ne t'empêche de livrer.

Au fond, mon argument porte surtout sur qui bouge en premier. Une dépréciation sans échéance ne va au bout que si les utilisateurs créent la pression qu'une date aurait créée, et l'écosystème rejoint Packagist un échec de CI et une issue sympathique à la fois. Les gens de Go feraient remarquer qu'ils n'ont jamais eu besoin d'une étape de compilation pour ça. Soit, nous on a phpize, et maintenant au moins il se lance tout seul.

Alors voici ma question. Quelle est l'extension de ta stack qui maintient en vie une ligne pecl install, et est-ce que tu as déjà prévenu son mainteneur ? J'aimerais voir la liste dans les commentaires, parce que je soupçonne qu'elle est plus courte qu'on ne le pense tous.