Fin de PEAR : sortir Mail et DB d’un vieux PHP avant la 8.7

require_once 'Mail.php'; : si cette ligne existe quelque part dans votre code, sans chemin ni autoloader, elle dépend d’une installation PEAR faite un jour sur le serveur, souvent par quelqu’un qui n’est plus là. Le projet PHP vote en ce moment la fin de son soutien à PEAR et le retrait de son installeur des sources de PHP, avec PHP 8.7 en ligne de mire. Rien ne casse le jour du vote, mais c’est le moment où une dépendance oubliée devient une dette datée. Ma position : ce chantier se fait maintenant, à froid, en une ou deux journées pour la plupart des applications, plutôt qu’en urgence le jour où l’image Docker de la 8.7 refusera de construire.

Ce que le vote décide, et quand

La RFC « End PEAR Project Endorsement », rédigée par Nick Sdot (version 1.0.0 du 27 août 2026), est en vote depuis le 5 octobre. Le scrutin se clôt le 19 octobre à 13 h 15 UTC et demande une majorité des deux tiers. Le 12 octobre au matin, la page affiche 31 voix pour, aucune contre : l’issue ne fait guère de doute.

Le constat de la RFC est sévère. D’après les métadonnées de PEAR relevées le 22 juin 2026, 534 des 603 paquets sont marqués non maintenus, et 63 des 69 restants n’ont pas été mis à jour depuis longtemps. Dans la discussion sur externals.io, l’auteur précise que seuls six paquets publient encore sur PEAR : trois relèvent de l’infrastructure de PEAR lui-même, deux autres viennent d’être marqués non maintenus, et le dernier, Net_SMTP, est aussi publié sur Packagist.

Ce que la RFC propose, concrètement :

Un point rassurant tiré de la discussion : go-pear.phar et les URL pear.php.net/rest/* resteront servis sur le même domaine depuis l’archive statique. Un pear install dans une CI ne tombera donc pas en panne le 20 octobre. Il installera simplement du code que plus personne ne corrige.

Le vrai sujet : PEAR est souvent invisible

Dans une vieille application, PEAR n’apparaît presque jamais dans le composer.json, par construction. Il est ailleurs : dans le include_path du php.ini, dans un Dockerfile, dans un script de provisionnement, ou dans un répertoire lib/ copié il y a dix ans. C’est ce qui le rend dangereux : la dépendance existe, mais aucun outil d’audit ne la voit. composer audit ne signalera jamais une faille dans un Mail.php installé par pear install.

Trois familles de paquets reviennent le plus souvent dans les vieux codes : l’envoi de mails (Mail, Mail_Mime, Net_SMTP), l’accès aux bases (DB, MDB2) et quelques utilitaires (Log, HTTP_Request2, Spreadsheet_Excel_Writer pour les exports). Le signe distinctif est double : des require de fichiers en CamelCase.php sans chemin, et des appels à PEAR::isError() pour tester le retour d’une fonction, la gestion d’erreur d’avant les exceptions.

Faire l’inventaire en trois commandes

Voici les trois recherches que je lance en premier. Elles visent le code, puis la gestion d’erreur propre à PEAR, puis tout ce qui construit l’environnement :

# 1. Les require sans chemin d'un fichier en CamelCase (Mail.php, DB.php, Mail/mime.php)
grep -rnE "^\s*(require|include)(_once)?\s*\(?\s*['\"][A-Z][A-Za-z]+(/[A-Za-z_]+)*\.php['\"]" src/

# 2. La gestion d'erreur à la mode PEAR
grep -rnE "PEAR::|PEAR_Error|isError\(" src/

# 3. Les installations dans les Dockerfiles, scripts et recettes de provisionnement
grep -rnE "\b(pear|pecl) (install|upgrade|channel-discover)" docker/ deploy/ .github/

Sur un petit projet de test reproduisant ces usages (un envoi de mail avec Mail et Mail_Mime, une connexion avec DB, un Dockerfile basé sur php:8.3-fpm), ces trois commandes ont été exécutées et ont remonté les cinq lignes attendues, sans faux positif. Sur un vrai dépôt, la première produira du bruit si votre code charge ses propres classes par des require relatifs : triez à la main, la liste reste courte.

Complétez par deux vérifications côté serveur : php -r 'echo get_include_path();' sur chaque environnement (un chemin comme /usr/share/php ou /usr/share/pear est un indice), et la liste des paquets installés avec pear list là où la commande existe encore.

Passer à Composer sans réécrire le code

Bonne nouvelle : la plupart des paquets PEAR encore utilisés existent sur Packagist sous le préfixe pear/, et ils déclarent un include-path dans leur composer.json. Composer ajoute alors leurs répertoires au include_path de PHP au chargement de vendor/autoload.php. Vos require_once 'Mail.php'; continuent de fonctionner sans changer une ligne.

composer require pear/mail pear/mail_mime pear/net_smtp pear/db

<?php
// en tête du point d'entrée, avant tout require historique
require __DIR__.'/vendor/autoload.php';

require_once 'Mail.php';      // résolu dans vendor/pear/mail
require_once 'DB.php';        // résolu dans vendor/pear/db

Sur le projet de test, avec PHP 8.3.6 et Composer 2.8.12, après cette commande, class_exists() renvoie true pour Mail, Mail_mime, DB et PEAR, et le include_path commence bien par les répertoires de vendor/pear/. Packagist propose aujourd’hui pear/mail en 2.0.0 (janvier 2024), pear/net_smtp en 1.12.2 (janvier 2026), pear/mail_mime en 1.10.13 (août 2026) et pear/db en 1.12.3 (novembre 2025).

Cette étape ne modernise rien, et c’est voulu. Elle fait passer la dépendance d’un état invisible à un état déclaré, versionné dans composer.lock et vu par composer audit. La documentation de Composer qualifie include-path de pratique dépréciée, réservée aux projets legacy, tout en précisant que la fonctionnalité ne devrait pas disparaître. C’est exactement l’usage : une passerelle, pas une destination.

La destination, ensuite, se choisit paquet par paquet. Mail et Net_SMTP vers Symfony Mailer, DB et MDB2 vers PDO ou Doctrine DBAL, Spreadsheet_Excel_Writer vers PhpSpreadsheet. Avant de remplacer l’envoi de mails, figez son comportement : capturez les messages produits par l’ancien code (en-têtes, encodage des sujets accentués, découpage des lignes, pièces jointes) avec un serveur SMTP de test, puis comparez avec le nouveau. C’est sur ces détails, pas sur l’API, qu’une bascule de bibliothèque de mail casse en silence.

L’autre moitié : pecl install dans vos Dockerfiles

C’est le point que je surveillerais de plus près. L’image officielle php de Docker compile PHP avec --with-pear, et son Dockerfile le justifie en une ligne : depuis PHP 7.4, les installeurs pecl et pear sont officiellement dépréciés et demandent cette option explicite. Or la commande pecl fait partie de l’installeur PEAR. Une bonne partie des Dockerfiles PHP contiennent un pecl install redis ou pecl install apcu.

La pull request de Jakub Zelenka sur php-src, citée par la RFC pour le retrait de l’installeur, s’intitule « PECL and PEAR removal ». Elle est encore à l’état de brouillon, et sa liste de tâches prévoit de faire pointer la documentation vers PIE. PIE, l’installeur d’extensions publié par la PHP Foundation, se présente comme le remplaçant de PECL, qu’il qualifie de déprécié ; il fonctionne avec PHP 8.1 ou plus récent.

# aujourd'hui
RUN pecl install redis && docker-php-ext-enable redis

# la cible, d'après la documentation de PIE (unzip, l'extension zip ou git est requis)
RUN --mount=type=bind,from=ghcr.io/php/pie:bin,source=/pie,target=/usr/local/bin/pie \
    pie install --no-cache phpredis/phpredis

La documentation de PIE publie une image Docker qui ne contient que le binaire (étiquette bin pour la dernière version stable) et précise qu’elle n’embarque pas PHP : l’image de base doit le fournir. PIE active ensuite l’extension lui-même, avec docker-php-ext-enable dans l’image officielle. L’important est de repérer ces lignes maintenant et de tester leur version PIE sur une branche, tant que l’ancienne fonctionne encore.

Ce que ce chantier ne règle pas

Passer par Composer ne rend pas le code maintenu. pear/db installé par Composer reste DB, avec sa gestion d’erreur par valeur de retour et son âge. Vous gagnez la visibilité et la reproductibilité, pas la qualité. Ne présentez pas cette étape à votre direction comme une migration terminée.

Certains paquets n’ont pas d’équivalent Composer, ou seulement un fork non officiel. Il faut alors soit copier le code dans le dépôt (en assumant de le maintenir), soit le remplacer tout de suite. Les progiciels qui embarquent leur propre copie de PEAR dans un répertoire lib/ sont un cas à part : le paquet n’est pas installé, il est livré, et c’est à l’éditeur du progiciel de bouger.

Enfin, le calendrier de PHP 8.7 n’est pas encore fixé, et le retrait effectif dépend de la pull request citée plus haut, encore en brouillon. Le vote acte une direction, pas une date de coupure. Cet article s’appuie sur la RFC, la discussion publique et la documentation des projets ; seuls l’inventaire et le passage par Composer ont été exécutés, sur un projet de test et non sur une application en production.

Lundi matin : l’ordre des opérations

1. Lancez les trois recherches sur le code, les Dockerfiles et les scripts de déploiement, et notez chaque paquet PEAR trouvé avec l’endroit où il est installé.
2. Pour chacun, cherchez pear/<nom> sur Packagist. S’il existe, déclarez-le dans composer.json et retirez le pear install correspondant.
3. Ajoutez le require 'vendor/autoload.php' là où il manque, puis faites tourner la suite de tests et un envoi de mail réel vers une boîte de test.
4. Listez vos pecl install et essayez leur équivalent PIE dans une branche, sur la version de PHP que vous visez.
5. Planifiez le remplacement des paquets les plus exposés, en commençant par ceux qui touchent au réseau (SMTP, HTTP) et ceux qui construisent des requêtes SQL.

PEAR a été le premier gestionnaire de paquets de beaucoup d’entre nous ; le laisser partir proprement, c’est surtout s’assurer qu’il ne reste pas, sans qu’on le sache, au cœur de l’envoi des factures.

Sources

• PHP RFC: End PEAR Project Endorsement, wiki.php.net, version 1.0.0 du 27 août 2026, consultée le 12 octobre 2026
• [[VOTE] End PEAR Project Endorsement](https://news-web.php.net/php.internals/132789), php.internals, 5 octobre 2026
• [[RFC] End PEAR Project Endorsement, discussion](https://externals.io/message/132358), externals.io, août à octobre 2026
• PECL and PEAR removal, PR #20124, php-src sur GitHub, brouillon
• Dockerfile de l’image officielle php, docker-library sur GitHub
• PIE, the PHP Installer for Extensions, PHP Foundation sur GitHub
• PIE, Usage, documentation de PIE, branche 1.6.x
• The composer.json schema, include-path, documentation de Composer