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 ça évite de réinventer toute la plomberie.
Pourquoi Webklex/php-imap ?
On pourrait évidemment utiliser directement les fonctions imap_* de PHP, mais on se retrouve rapidement à gérer soi-même les connexions, les dossiers, les UID, les flags et une bonne partie des cas tordus du protocole IMAP. Pour quelques lignes de code ça passe, pour une vraie intégration dans une application Symfony, ça devient vite pénible.
Webklex/php-imap ajoute une couche objet beaucoup plus agréable à utiliser. On manipule des clients, des dossiers, des messages et des pièces jointes sans avoir à parler directement le dialecte parfois un peu poussiéreux d’IMAP.
Attention toutefois à un détail qui prête facilement à confusion : Webklex propose également webklex/laravel-imap. Celui-là est destiné à Laravel et ajoute l’intégration avec le framework. Dans une application Symfony, ce n’est pas celui qu’on veut. On utilise directement le package PHP qui sert de moteur derrière cette intégration.
Installation et configuration : le strict minimum
On installe donc le bon paquet :
composer require webklex/php-imap
Pas de laravel-imap ici. Pour créer une connexion, Webklex fournit un ClientManager auquel on passe la configuration du compte IMAP :
use Webklex\PHPIMAP\ClientManager;
$cm = new ClientManager();
$client = $cm->make([
'host' => $_ENV['IMAP_HOST'],
'port' => (int) $_ENV['IMAP_PORT'],
'encryption' => $_ENV['IMAP_ENCRYPTION'],
'validate_cert' => true,
'username' => $_ENV['IMAP_USERNAME'],
'password' => $_ENV['IMAP_PASSWORD'],
'protocol' => 'imap',
]);
$client->connect();
Dans un projet Symfony, l’idée n’est évidemment pas de mettre ça au milieu d’un contrôleur. Le plus propre est d’encapsuler le client dans un service dédié et de récupérer les paramètres depuis les variables d’environnement ou les secrets Symfony.
Le .env peut par exemple contenir :
IMAP_HOST=imap.example.com IMAP_PORT=993 IMAP_ENCRYPTION=ssl IMAP_USERNAME=support@example.com IMAP_PASSWORD=change-me
Pour du développement local, ça suffit largement. En production, évite évidemment de versionner les identifiants avec le projet : variables d’environnement, secrets Symfony ou gestionnaire de secrets feront très bien le boulot.
Récupérer des mails : enfin la partie intéressante
Une fois connecté, on peut récupérer la boîte de réception et rechercher les messages non lus :
$folder = $client->getFolder('INBOX');
$messages = $folder
->messages()
->unseen()
->limit(10)
->get();
foreach ($messages as $message) {
echo $message->getSubject() . "\n";
echo $message->getTextBody() . "\n";
$message->setFlag('\Seen');
}
On retrouve ici l’intérêt de la librairie : le code reste compréhensible. unseen() filtre les messages non lus, limit(10) évite de récupérer toute la boîte mail et get() exécute réellement la requête.
Pour déplacer ensuite un message dans un dossier d’archives :
$message->move('Archives');
Pas besoin de manipuler directement les UID ou d’envoyer soi-même des commandes IMAP au serveur. C’est précisément le genre de détails qu’on préfère laisser à la librairie.
Dans une vraie application, on encapsulera évidemment tout ça dans un service : récupération des messages, extraction des informations utiles, logs, gestion des erreurs et éventuellement déplacement du message une fois son traitement terminé.
Les pièges à éviter
Premier problème : IMAP reste un protocole réseau et un serveur mail peut prendre son temps. Faire la récupération d’une boîte directement pendant une requête HTTP Symfony n’est donc généralement pas une excellente idée.
Pour un traitement régulier, mieux vaut utiliser un worker avec Symfony Messenger, un cron ou une commande Symfony exécutée périodiquement. L’application web reste rapide et la récupération des mails travaille tranquillement en arrière-plan.
Deuxième point : les flags IMAP. \Seen, \Flagged, \Deleted… Ils permettent de suivre l’état d’un message, mais il faut garder en tête que leur comportement dépend aussi du serveur IMAP. En particulier, marquer un message avec \Deleted ne signifie pas forcément qu’il disparaît immédiatement : la suppression définitive passe généralement par une opération d’expunge.
Enfin, il y a les pièces jointes. Webklex permet de les récupérer facilement :
$attachments = $message->getAttachments();
foreach ($attachments as $attachment) {
$fileContent = $attachment->getContent();
// Stockage local, S3, traitement du fichier, etc.
}
La librairie récupère la pièce jointe, mais elle ne peut évidemment pas deviner ce que ton application veut en faire. À toi ensuite de la stocker, de l’analyser ou de l’envoyer vers un autre service.
Et les fameux rate limits ?
C’est aussi là qu’IMAP peut être intéressant par rapport à certaines API de fournisseurs de messagerie. On dialogue directement avec le serveur IMAP avec un protocole standard, sans construire toute l’application autour d’une API propriétaire.
Ça ne veut pas dire qu’on peut massacrer le serveur avec une connexion toutes les 100 ms. Les fournisseurs peuvent toujours limiter le nombre de connexions simultanées, couper les sessions trop agressives ou imposer leurs propres restrictions. Mais pour un worker qui relève raisonnablement une boîte mail toutes les quelques secondes ou minutes, IMAP reste une solution simple et prévisible.
Conclusion : vieux protocole, problème toujours actuel
Webklex/php-imap ne transforme pas IMAP en technologie sexy de 2026, et ce n’est probablement pas son objectif. Il rend simplement le protocole beaucoup moins pénible à utiliser depuis PHP.
Pour une application Symfony qui doit surveiller une boîte de support, récupérer des factures, traiter automatiquement certaines demandes ou alimenter un workflow interne, ça fait parfaitement le boulot. On garde une intégration relativement simple, on évite de dépendre d’une API propriétaire et surtout on ne passe pas son après-midi à manipuler des commandes IMAP à la main.
Alors oui, IMAP est vieux, parfois lent et pas toujours très élégant. Mais pour lire des mails depuis Symfony, Webklex/php-imap permet au moins de faire ça proprement. Et surtout : sans installer Laravel au passage.