Une automatisation peut atteindre un point où elle ne doit pas avancer sans décision, donnée ou vérification. Par exemple, elle peut nécessiter une approbation avant de confirmer une opération sensible, ou attendre des informations qu’une personne est la seule à pouvoir fournir. Dans ces cas, le système doit conserver un état récupérable et expliquer ce qui manque, plutôt que de se contenter d’arrêter l’exécution en cours.
Concevoir la mise en pause et la reprise d’une automatisation en PHP implique de séparer l’état du processus de l’exécution du travail. La pause doit être intentionnelle, persistante et auditable ; la reprise doit vérifier que le processus est toujours valide et que les effets déjà appliqués ne sont pas répétés. Cela diffère de la conception d’une file de révision : ici, l’accent porte sur le cycle de vie du flux et sa reprise en toute sécurité.
Distinguer une pause d’une attente ou d’un échec
Tout processus qui n’avance pas n’est pas nécessairement en pause. Un appel à une API qui n’a pas encore répondu correspond à une attente externe. Une erreur réseau peut justifier une nouvelle tentative. Une exception irrécupérable peut mettre fin au processus en le marquant comme ayant échoué. Une pause délibérée signifie, au contraire, que le flux a atteint une limite connue et qu’une condition explicite est nécessaire pour continuer ou se terminer.
Utiliser un état distinct pour chaque situation évite les mauvaises décisions opérationnelles. Réessayer une action en attente d’approbation peut répéter une demande inutile ; traiter une pause légitime comme un échec peut déclencher des alertes ou des politiques de récupération inadaptées. Définissez au minimum des états distincts pour l’exécution, l’attente externe, l’intervention requise, la fin, l’annulation et l’échec. Ajoutez une expiration si l’activité exige qu’une pause cesse d’être valide après un délai.
Avant d’ajouter une pause, précisez ce qui la déclenche et qui peut la résoudre. Une tâche en attente qui s’achève automatiquement à la réception d’une réponse ne nécessite pas toujours une intervention humaine. En revanche, une décision ayant un impact financier, juridique, sur les accès ou sur la sécurité peut en nécessiter une. Cette distinction détermine qui peut agir, quelles preuves conserver et ce qui se passe si personne ne répond.
Persister l’état et le point de reprise
Le processus doit survivre à la fin de la requête PHP, au redémarrage d’un worker et au déploiement d’une nouvelle version du service. Enregistrez dans un stockage persistant un identifiant stable, l’état actuel, l’étape atteinte, le motif de la pause, les références aux données nécessaires et les horodatages pertinents. Le cas échéant, consignez également qui a mis le processus en pause ou l’a résolu, ainsi que la décision prise.
Évitez de n’enregistrer qu’un message comme « en attente d’approbation ». Il ne permet pas d’identifier l’exécution interrompue, l’étape à reprendre ni de savoir si les données ont changé. Représentez plutôt la pause comme une partie du modèle du processus, avec suffisamment de contexte pour valider la reprise. Dans la mesure du possible, conservez des références aux informations sensibles plutôt que de dupliquer inutilement les données ; appliquez des contrôles d’accès et des règles de conservation adaptés à leur nature.
Définissez les transitions autorisées et vérifiez-les côté serveur. Par exemple, un processus dont l’état indique qu’une intervention est requise peut passer à l’exécution, à l’annulation ou à l’expiration ; un processus terminé ne devrait pas repasser à l’exécution à la suite d’une requête ordinaire. Une fonction PHP peut valider la transition, mais la règle doit également être protégée contre les accès concurrents dans la base de données, et pas seulement dans l’interface.
Séparer l’enregistrement du processus de l’exécution
Enregistrer que le processus doit reprendre et exécuter ses étapes sont des opérations liées, mais distinctes. Si l’état est mis à jour et que le processus se termine avant le début du travail, le flux risque de rester bloqué. Si le travail commence avant l’enregistrement de la transition, une nouvelle tentative peut exécuter la même étape. Concevez la coordination de sorte que l’état persistant permette de récupérer le travail en attente.
Une option courante consiste à enregistrer la transition et une instruction de reprise dans une même transaction de base de données, par exemple au moyen du modèle outbox transactionnel. Un worker distinct lit cette instruction et exécute l’étape suivante. Le choix précis dépend de l’architecture ; l’essentiel est que le système puisse détecter le travail non consommé et le récupérer, au lieu de compter sur une requête web qui resterait active.
Les effets externes exigent une attention supplémentaire. Une transaction locale ne peut pas, à elle seule, annuler l’envoi d’un e-mail, la confirmation d’un débit ou un appel déjà accepté par un autre service. Concevez chaque étape avec une clé d’idempotence lorsque le système destinataire le permet, consignez le résultat avant de poursuivre et prévoyez une réconciliation ou une compensation lorsqu’une opération ne peut pas être répétée sans risque. Ne marquez pas une étape comme terminée avant d’en connaître le résultat.
Contrôler la reprise, l’annulation et l’expiration
L’action de reprise doit vérifier l’état en vigueur, l’identité et les autorisations de la personne qui demande l’opération, ainsi que la satisfaction des conditions nécessaires. Il ne suffit pas d’afficher un bouton à une personne autorisée : le serveur doit tout valider à nouveau à la réception de la demande. Si la décision nécessite une justification ou une donnée supplémentaire, validez et conservez ces informations dans le cadre de la résolution.
Traitez également l’annulation et l’expiration comme des transitions explicites, et non comme une suppression de l’enregistrement. L’annulation doit empêcher toute nouvelle étape et préciser si des effets antérieurs ne peuvent pas être annulés. L’expiration doit définir la suite : terminer le processus, demander une nouvelle intervention ou orienter le cas vers une autre action. Le comportement dépend de la règle métier et doit être visible pour les opérations.
Les demandes répétées et les conditions de concurrence sont normales : une personne peut double-cliquer ou deux acteurs peuvent agir presque simultanément. Utilisez une mise à jour conditionnelle, un verrou ou un contrôle de version afin qu’une seule transition valide l’emporte. Une deuxième demande doit renvoyer un résultat cohérent avec l’état actuel, sans réexécuter les effets. Enregistrez un identifiant d’opération ou une clé d’idempotence pour reconnaître les répétitions.
Rendre la pause compréhensible et vérifiable
La vue opérationnelle doit expliquer pourquoi le processus est interrompu, quelle étape reste en attente, quelles informations manquent, qui peut agir et quelles sont les conséquences de chaque option. Évitez les boutons ambigus ou les actions qui combinent approbation, correction des données et reprise. Ne présentez que les informations nécessaires à la décision, avec un accès limité selon le rôle. Un historique des transitions permet de distinguer une attente légitime d’un processus bloqué ou mal configuré.
Testez le flux en provoquant des interruptions avant et après chaque effet externe. Vérifiez qu’un redémarrage ne fait pas perdre la pause, qu’une reprise répétée ne duplique pas les actions et qu’une annulation empêche les étapes suivantes. Incluez des cas où les données ont été modifiées pendant l’interruption, où des autorisations ont été révoquées, ainsi que des cas d’expiration, de réponses tardives et de deux demandes simultanées. Vérifiez également les journaux et les alertes : ils doivent permettre de retrouver le processus et de comprendre l’étape suivante sans exposer de secrets.
Liste de contrôle pour choisir le comportement
- Attendre : une réponse externe est en cours et le système peut continuer automatiquement à sa réception, avec des délais et une récupération définis.
- Mettre en pause pour intervention : une décision ou une donnée explicitement fournie par une personne est nécessaire avant l’exécution des étapes suivantes.
- Réessayer : une défaillance transitoire s’est produite et l’étape peut être répétée sans risque ou est protégée par l’idempotence.
- Terminer : aucune reprise n’est valide, ou le processus est terminé, annulé, expiré ou définitivement en échec.
Avant de déployer le flux, vérifiez que chaque transition est autorisée, que l’état est persistant, que les effets antérieurs ne sont pas répétés et que l’équipe sait comment résoudre la pause. Si vous ne pouvez pas préciser ce qui sera repris, avec quelles données et dans quelles conditions, le processus ne dispose pas encore d’un point de reprise sûr.
