Comment concevoir une file de tâches pour les opérations lentes en PHP

Une opération qui prend plusieurs secondes peut laisser une requête HTTP ouverte, consommer les ressources du serveur web et offrir à l’utilisateur une expérience incertaine si la connexion est interrompue. Les processus en arrière-plan en PHP permettent d’accepter le travail et de l’exécuter en dehors du cycle de vie de cette requête. Pour que la solution soit utile, il ne suffit pas d’ajouter une file d’attente : il faut définir ce que reçoit l’utilisateur, comment il consulte l’état et ce qui se passe en cas d’interruption.

Identifier les opérations à exécuter en arrière-plan

Il convient d’évaluer l’impact d’une opération, plutôt que d’appliquer une règle fondée uniquement sur sa durée. Une tâche peut s’y prêter si sa durée est variable, si elle nécessite d’attendre un système externe ou si elle traite de nombreux éléments. On peut citer la génération d’un rapport volumineux, l’importation d’un fichier, la transformation de documents ou la synchronisation de données avec une API.

En revanche, si l’utilisateur a besoin d’une décision immédiate pour continuer — par exemple valider une donnée essentielle avant l’enregistrement — il peut être préférable de conserver cette partie dans la requête et de ne séparer que le travail ultérieur. Certaines tâches lentes exigent également une réponse synchrone pour des raisons métier. L’architecture doit répondre aux besoins du flux, et non transformer chaque opération en tâche asynchrone.

Avant de modifier la conception, déterminez la durée de l’opération, la partie qui prend le plus de temps et ce qui se passe en cas d’échec. Une file d’attente ne corrige pas à elle seule les requêtes inefficaces, les limites mal configurées ni l’instabilité des dépendances externes ; elle peut simplement transférer ces problèmes aux workers en arrière-plan.

Répondre que la tâche est acceptée, sans inventer de résultat

Lorsque le travail est accepté pour une exécution ultérieure, la réponse de l’application doit distinguer clairement les états accepté et terminé. Elle peut renvoyer un identifiant de tâche et indiquer que le traitement est en attente. Elle ne doit pas présenter comme terminé un résultat qui n’existe pas encore.

Une estimation de durée n’est appropriée que si les informations disponibles permettent de la calculer et d’en communiquer l’incertitude. Dans de nombreux systèmes, il est plus honnête d’afficher un état comme « en file d’attente » ou « en cours de traitement » que de promettre une heure de fin. Si la tâche peut être achevée rapidement, l’interface peut tout de même consulter son état et afficher le résultat dès qu’il est disponible, sans bloquer la requête initiale.

Définissez également ce qui se passe en cas d’échec de l’envoi dans la file d’attente : l’application ne doit pas confirmer l’acceptation si elle ne peut pas enregistrer le travail de manière fiable. Le mécanisme précis dépend de l’architecture, mais la réponse et l’état persisté doivent être cohérents.

Définir les états et les transitions valides

Un cycle de vie réduit et explicite facilite l’expérience utilisateur et l’exploitation. On peut, comme base, prévoir les états en_attente, en_cours, annulation_demandee, terminee, en_echec et annulee. Les noms peuvent varier ; les transitions, en revanche, doivent être valides et vérifiables, et non constituer une combinaison libre d’états.

• Transitions normales : en_attente → en_cours puis, depuis en_cours, terminee ou en_echec.
• Annulation avant le démarrage : en_attente → annulee si l’on confirme que le worker n’a pas encore commencé le travail.
• Annulation pendant l’exécution : en_cours → annulation_demandee. À partir de cet état, la tâche passe à annulee si elle est arrêtée en toute sécurité ; elle peut passer à terminee si elle s’est achevée avant que la demande soit traitée, ou à en_echec en cas d’erreur.
• États finaux : terminee, en_echec et annulee ne devraient pas revenir à des états actifs. Si une tâche peut être relancée, créez une nouvelle exécution ou définissez explicitement un cycle différent.

Le système doit empêcher les transitions non autorisées et enregistrer le moment où chaque changement a eu lieu. Si un worker est interrompu et laisse une tâche à l’état en_cours, ne la marquez pas automatiquement comme terminée. Une politique de récupération peut la remettre à l’état en_attente lorsqu’il est sûr de la reprendre, ou la marquer comme en_echec pour examen. Le choix dépend de la possibilité de reprendre le travail sans dupliquer ses effets. La coordination des nouvelles tentatives et l’idempotence nécessitent des décisions spécifiques ; elles ne doivent pas être confondues avec le modèle d’états visible.

Communiquer la progression, le résultat et les erreurs

La progression doit s’appuyer sur des étapes mesurables. S’il est impossible de calculer un pourcentage réel, mieux vaut indiquer la phase (« validation des données », « génération du rapport ») ou conserver l’état « en cours ». Un pourcentage qui reste immobile ou recule sans explication nuit à la confiance.

À la fin, fournissez le résultat métier : par exemple, un récapitulatif des éléments traités ou une référence à la ressource générée, sous réserve des autorisations et de sa disponibilité. L’état de la tâche n’a pas nécessairement à stocker l’intégralité du résultat. Il peut contenir une référence aux données gérées par le domaine de l’application.

En cas d’échec, affichez un message qui aide à choisir l’étape suivante, par exemple corriger un fichier ou réessayer lorsque cela convient. Enregistrez séparément l’erreur technique nécessaire au diagnostic, en limitant son accès. N’exposez pas de traces, d’identifiants d’accès, de chemins internes ni de données sensibles dans l’interface ou dans une API publique.

Traiter l’annulation comme une demande assortie de limites

Annuler une tâche ne signifie pas toujours qu’elle peut être arrêtée immédiatement. Un worker peut être en train d’exécuter un appel externe, d’écrire des données ou de se trouver dans une phase qui ne peut pas être interrompue sans risque. L’interface doit donc distinguer annulation_demandee de annulee : le premier état indique que la demande a été reçue ; le second, que le système a confirmé l’arrêt.

L’implémentation peut vérifier un signal d’annulation à des points sûrs et cesser de lancer les étapes suivantes. Si l’effet a déjà été confirmé dans un système externe, ne prétendez pas qu’il a été annulé. Expliquez à l’utilisateur le résultat auquel il peut s’attendre et consignez l’identité de la personne qui a demandé l’annulation lorsque cette information est pertinente pour l’audit.

Séparer l’enregistrement de la tâche du résultat métier

L’enregistrement d’une tâche sert à coordonner son exécution et sa consultation : il peut inclure un identifiant, un état, des dates, le demandeur et des références de diagnostic. Le résultat métier — par exemple un rapport ou les enregistrements importés — relève du modèle de données qui représente ce résultat.

Cette séparation évite qu’une tâche contenant des informations temporaires devienne l’unique source de données métier. Elle permet également de définir la durée de conservation : combien de temps conserver l’état, quand supprimer un fichier et quelles informations garder pour des obligations opérationnelles ou réglementaires. Les anciens états ne devraient pas s’accumuler sans politique de nettoyage.

Protéger les consultations et limiter la consommation des ressources

La consultation d’une tâche nécessite une autorisation, comme celle de toute autre ressource. L’identifiant ne remplace pas le contrôle d’accès : vérifiez que la personne ou le système à l’origine de la demande peut consulter cette tâche et son résultat. Limitez également la fréquence et le volume des consultations pour éviter les interrogations excessives, et envisagez des notifications si le cas d’usage ne nécessite pas de mises à jour constantes.

L’exécution doit respecter des limites de concurrence et de ressources adaptées au type de travail. Un nombre trop élevé de workers peut saturer la base de données, les services externes ou le stockage ; un nombre trop faible peut entraîner une accumulation de tâches et retarder les résultats. Surveillez le volume en attente, l’ancienneté des tâches et leur durée, ainsi que les erreurs. Ces indicateurs aident à distinguer une dépendance lente d’un problème de capacité.

Tester le cycle complet avant le déploiement

Les tests d’acceptation doivent couvrir le comportement visible et la persistance, et pas seulement vérifier que le worker appelle une fonction. Vérifiez au minimum les scénarios suivants :

• La requête crée une tâche et renvoie une référence sans affirmer qu’elle est déjà terminée.
• Une tâche terminée affiche son état final et permet d’accéder au résultat avec les autorisations appropriées.
• Une tâche en échec communique un message sûr et laisse les informations de diagnostic accessibles à l’équipe autorisée.
• Une tâche abandonnée ou interrompue ne reste pas indéfiniment « en cours » ; il existe un moyen opérationnel de la détecter et de la traiter.
• Une demande d’annulation respecte les phases sûres et ne promet pas d’annuler des effets déjà produits.

Dans un système existant, introduisez le changement pour une opération limitée et validez également l’expérience lorsque la file d’attente est en retard ou indisponible. L’application doit fournir une réponse claire dans ces situations : indiquer qu’elle n’a pas pu accepter le travail, proposer une solution de remplacement sûre ou permettre à l’utilisateur de réessayer. Le choix dépend de l’impact de l’opération et des garanties que l’entreprise peut tenir.

Liste de contrôle pour introduire une file d’attente dans un système existant

Avant d’activer le traitement en arrière-plan, examinez les points suivants avec les équipes responsables de l’application et de son exploitation :

• Périmètre : une opération précise a été choisie et il a été défini quelle partie reste synchrone et quel travail s’exécute en arrière-plan.
• Persistance : l’acceptation de la tâche et son état sont enregistrés de manière cohérente ; une politique couvre les interruptions, la récupération et les changements d’état.
• Contrat avec l’utilisateur : la réponse initiale distingue l’acceptation de l’achèvement, et l’interface explique comment consulter la progression, le résultat et les erreurs.
• Autorisations et données : la consultation d’une tâche ou de son résultat nécessite une autorisation ; les données stockées sont réduites au minimum et l’accès aux diagnostics est restreint.
• Ressources : des limites de concurrence, de durée d’exécution, de mémoire et de fréquence de consultation, adaptées à l’opération et à ses dépendances, ont été fixées.
• Observabilité : il est possible de détecter l’accumulation, les tâches anciennes en cours, les échecs et les durées anormales sans inclure de secrets dans les journaux.
• Conservation : la durée de conservation des états, des résultats, des fichiers et des données de diagnostic a été définie, ainsi que les modalités de leur suppression contrôlée.
• Tests et exploitation : les scénarios de fin, d’échec, d’annulation et d’interruption ont été testés, et l’équipe sait quoi faire si la file n’accepte pas de travail ou prend du retard.

Déployer le code ne signifie pas activer immédiatement tous les flux : vous pouvez introduire progressivement le nouveau chemin d’exécution et vérifier ses indicateurs avant de l’étendre. Maintenez une solution de remplacement adaptée si la file d’attente ou ses workers sont indisponibles ; ne confirmez pas des tâches que le système n’a pas pu enregistrer.