Parce que oui, en 2026, on a toujours besoin de lire des mails depuis du code. Pas pour envoyer des newsletters à la chaîne (on a Mailer pour ça, merci bien), mais pour automatiser des tâches chiantes : trier des tickets, archiver des factures, ou même répondre à des demandes de support comme un robot bien élevé. Le problème ? L’IMAP, c’est un peu comme le SQL des années 90 : puissant, mais bordélique à utiliser sans une bonne librairie. Heureusement, Webklex/php-imap existe, et c’est une pépite.
Pourquoi Webklex/php-imap et pas un truc « moderne » ?
Parce que les alternatives, franchement, c’est soit du bricolage maison avec imap_* (et ses joies de gestion d’erreurs), soit des solutions overkill comme Horde_Imap_Client qui te font installer 42 dépendances pour lire un seul mail. Webklex, lui, c’est simple, bien documenté (oui, ça existe), et ça s’intègre proprement dans Symfony sans te forcer à réinventer la roue.
Autre avantage : il gère les connexions persistantes, les reconnexions automatiques, et même les flags IMAP comme un grand. Pas besoin de bidouiller des try/catch à n’en plus finir pour gérer les timeouts ou les serveurs qui plantent. Et surtout, il expose une API claire, sans te noyer sous des couches d’abstraction inutiles. Bref, c’est du PHP comme on l’aime : efficace et sans chichis.
Installation et configuration : le strict minimum
D’abord, on installe le paquet via Composer :
composer require webklex/laravel-imap
Oui, le paquet s’appelle laravel-imap, mais non, il ne dépend pas de Laravel. C’est juste un choix de nommage douteux (merci, l’écosystème PHP). Pour Symfony, on va créer un service dédié. Voici un exemple de configuration basique dans config/services.yaml :
services:
Webklex\IMAP\Client:
arguments:
$options:
host: '%env(IMAP_HOST)%'
port: '%env(int:IMAP_PORT)%'
encryption: '%env(IMAP_ENCRYPTION)%' # ssl ou tls
validate_cert: true
username: '%env(IMAP_USERNAME)%'
password: '%env(IMAP_PASSWORD)%'
protocol: imap
Rien de sorcier : on injecte les paramètres depuis le .env, et hop, le client est prêt à l’emploi. Pour les plus paranoïaques, vous pouvez aussi stocker les identifiants dans un vault comme Hashicorp Vault ou AWS Secrets Manager, mais on va pas se mentir, pour un petit projet, un .env bien sécurisé suffit.
Récupérer et déplacer des mails : des exemples qui servent à quelque chose
Passons aux choses sérieuses. Voici comment récupérer les 10 derniers mails non lus de la boîte de réception :
$client = $this->get('Webklex\IMAP\Client');
$client->connect();
$folder = $client->getFolder('INBOX');
$messages = $folder->messages()->unseen()->limit(10)->get();
foreach ($messages as $message) {
echo $message->getSubject()."\n";
echo $message->getTextBody()."\n";
// Marquer comme lu
$message->setFlag(['\Seen']);
}
Simple, non ? La méthode unseen() filtre les mails non lus, limit(10) évite de charger 5000 mails en mémoire, et get() exécute la requête. Pour déplacer un mail vers un dossier d’archives (parce que oui, on archive encore des mails en 2026) :
$archiveFolder = $client->getFolder('Archives');
$message->move($archiveFolder);
Et voilà. Pas besoin de bidouiller des UIDs ou des flags obscurs : la librairie gère tout ça pour toi. Bien sûr, dans un vrai projet, tu vas vouloir encapsuler ça dans un service dédié, avec des logs, des retries, et peut-être même un système de queue pour éviter de bloquer ton API pendant 30 secondes si le serveur IMAP met du temps à répondre. Mais ça, c’est une autre histoire.
Les pièges à éviter
D’abord, les connexions IMAP sont lentes. Très lentes. Si tu fais une requête IMAP dans une API Symfony, prépare-toi à des timeouts ou à des utilisateurs impatients. Solution ? Utilise un worker (Symfony Messenger, RabbitMQ, ou même un simple cron) pour traiter les mails en arrière-plan. Ton API répondra en 50ms au lieu de 5 secondes, et tout le monde sera content.
Ensuite, les flags IMAP. \Seen, \Flagged, \Deleted… Ces petits drapeaux sont pratiques, mais ils peuvent vite devenir un enfer si tu les utilises sans comprendre leur comportement. Par exemple, \Deleted ne supprime pas immédiatement le mail : il le marque pour suppression, et il faut appeler expunge() pour le virer définitivement. Oublie cette étape, et tu te retrouves avec une boîte mail pleine de mails fantômes.
Enfin, les pièces jointes. Webklex gère les pièces jointes, mais si tu veux les stocker sur S3 ou un autre service, prépare-toi à écrire un peu de code. La librairie te donne accès aux fichiers en tant que Attachment, mais c’est à toi de les uploader où tu veux. Exemple :
$attachments = $message->getAttachments();
foreach ($attachments as $attachment) {
$fileContent = $attachment->getContent();
// Upload vers S3, un filesystem local, etc.
}
Rien de compliqué, mais c’est un détail qui peut vite devenir chiant si tu ne l’anticipes pas.
Conclusion : Webklex, le couteau suisse de l’IMAP en PHP
Webklex/php-imap, c’est un peu comme un bon couteau suisse : ça ne fait pas le café, mais ça fait bien ce pour quoi c’est conçu. Pas de fioritures, pas de dépendances inutiles, juste une API propre pour interagir avec un serveur IMAP depuis Symfony. Si tu as besoin de lire, trier ou archiver des mails depuis ton backend, c’est clairement la librairie que je te recommande.
Bien sûr, ça ne remplacera pas un vrai système de tickets (comme Zendesk ou Freshdesk) si tu gères du support client à grande échelle, mais pour des tâches simples ou des automatisations ponctuelles, c’est parfait. Et surtout, ça te permet de garder le contrôle sur tes données, sans dépendre d’une API tierce qui peut changer ses tarifs ou ses conditions du jour au lendemain.
Alors oui, l’IMAP, c’est vieux, c’est lent, et c’est parfois frustrant. Mais avec Webklex, au moins, c’est moins douloureux.