Automatiser une opération ne signifie pas toujours l’exécuter sans intervention. Si une action peut modifier des données importantes, appliquer une condition commerciale, transférer des fonds ou affecter des tiers, il peut être nécessaire d’attendre qu’une personne l’autorise. Un flux d’approbation humaine dans les automatisations PHP met en place ce contrôle sans transformer le processus en une chaîne informelle de messages et de décisions difficiles à reconstituer.
L’essentiel n’est pas d’ajouter un bouton « approuver », mais de définir ce qui est proposé, qui peut décider, sur la base de quelles informations, pendant combien de temps et ce qui se passe ensuite. Le système doit pouvoir expliquer chaque état et empêcher qu’une approbation ancienne ou dupliquée déclenche une action différente de celle qui a été examinée.
Décider quand suspendre une opération
Un examen a posteriori permet de détecter les problèmes après l’exécution de l’action. Une approbation préalable, en revanche, interrompt l’exécution jusqu’à ce qu’une décision soit prise. Il convient d’exiger une autorisation lorsque l’impact potentiel, la difficulté à annuler l’action ou le degré d’incertitude dépasse le niveau accepté pour l’automatisation.
Évaluez chaque opération à l’aide de questions concrètes : peut-elle modifier une donnée difficile à récupérer ? Affecte-t-elle de l’argent, des droits, des accès ou des engagements envers des clients ? Existe-t-il une règle vérifiable qui permettrait de l’exécuter de manière autonome ? Quels seraient les dommages causés par une erreur et de combien de temps dispose-t-on pour réagir ? Une opération courante, réversible et limitée pourrait être exécutée automatiquement et enregistrée en vue d’un examen. Une action exceptionnelle ou à fort impact peut nécessiter une autorisation préalable à son exécution.
Évitez d’appliquer le contrôle humain à tout par défaut. Une file d’attente saturée entraîne des retards et favorise les approbations mécaniques. Définissez des seuils et des exceptions, puis mesurez les éléments en attente, les délais d’attente, les refus et les expirations afin de repérer les règles qu’il serait utile d’ajuster. La décision doit reposer sur le risque réel, et pas seulement sur le fait qu’une opération soit techniquement possible.
Définir ce qui est proposé et ce qui peut être autorisé
La personne chargée de l’examen doit comprendre l’effet de l’opération, sans avoir à déchiffrer un objet interne PHP. Présentez la valeur actuelle et celle qui est proposée, le motif, l’origine des données, les conséquences pertinentes et toute limitation. Si la décision dépend d’une règle, affichez les explications nécessaires pour l’appliquer. Masquez ou protégez les données personnelles qui ne sont pas nécessaires.
Séparez la commande de proposition de l’autorisation. La proposition décrit l’action et ses paramètres ; l’autorisation permet d’exécuter cette proposition précise. Elle ne doit pas accorder de permissions générales ni permettre à la personne qui approuve de modifier discrètement les paramètres. Si des modifications sont nécessaires, la personne chargée de l’examen peut en demander ; le système crée alors une proposition mise à jour, qui doit être soumise aux règles d’autorisation applicables.
Appliquez le principe du moindre privilège : limitez les personnes autorisées à créer, approuver, rejeter ou annuler des propositions, et vérifiez ces permissions côté serveur à chaque transition. Lorsque le risque le justifie, exigez que la personne qui propose une opération ne puisse pas l’autoriser elle-même. Cette séparation doit être mise en œuvre dans la logique des permissions, et ne pas reposer uniquement sur la dissimulation des boutons dans l’interface.
Modéliser explicitement les états et les transitions
Représentez le processus sous la forme d’une machine à états. Un ensemble initial utile peut inclure pending, approved, executing, rejected, changes_requested, expired, cancelled et executed. Une proposition en attente peut être approuvée, rejetée, annulée ou expirer ; une proposition approuvée ne peut passer à l’exécution que si elle est toujours valide ; une proposition en cours d’exécution peut aboutir à l’état exécuté ou revenir à un état permettant une reprise s’il est établi qu’aucun effet ne s’est produit. Une proposition exécutée ne peut pas être approuvée à nouveau.
Enregistrez l’état actuel ainsi qu’un historique immuable des décisions et des transitions. Consignez l’identifiant de la proposition, l’ancien et le nouvel état, l’acteur, la date et l’heure, le motif et la référence à la version des données examinées. Ne remplacez pas l’historique lors de la mise à jour de l’enregistrement : il est nécessaire pour auditer les événements et diagnostiquer les défaillances.
En PHP, centralisez les transitions dans un service de domaine ou un composant équivalent. Évitez que différents contrôleurs modifient directement l’état au moyen de mises à jour génériques. Validez la transition et les permissions dans une transaction, le cas échéant, et rejetez les actions incompatibles avec l’état actuel. Cette structure réduit les erreurs de concurrence et facilite le test des règles sans dépendre de l’interface.
Éviter les approbations obsolètes et les exécutions en double
Les données peuvent changer pendant qu’une proposition est en attente. Une personne ne doit pas autoriser une condition qui ne correspond plus à l’opération qui sera exécutée. Enregistrez une version, une date de mise à jour ou une empreinte des champs pertinents au moment de la création de la proposition. Lors de l’approbation, vérifiez-la à nouveau par rapport à l’état en vigueur.
La vérification au moment de l’approbation ne suffit pas : les données peuvent encore changer avant l’application de l’opération. Juste avant l’exécution, comparez de nouveau la version ou l’empreinte en vigueur à celle qui a été approuvée. En cas de différence, interrompez le processus, invalidez l’autorisation pour cette proposition et demandez une nouvelle décision sur les données mises à jour. Selon le risque, vous pouvez afficher les différences et exiger une confirmation explicite, mais ne réutilisez pas automatiquement l’approbation précédente.
Une expiration limite la durée de validité de la décision. À son échéance, marquez la proposition comme expirée et exigez une nouvelle autorisation pour poursuivre. Chaque nouvelle tentative doit vérifier que l’autorisation est toujours valide ; ne réutilisez jamais une autorisation expirée pour reprendre ou répéter l’exécution.
L’approbation doit se rapporter à une proposition identifiable et ne pas constituer un signal réutilisable. Pour éviter que deux workers concurrents exécutent la même proposition, prenez en charge ou verrouillez de manière atomique sa transition de approved à executing : un seul worker peut la prendre en charge si la proposition est toujours approuvée et valide. Dans cette protection locale, vérifiez également l’idempotence et enregistrez l’identifiant unique de l’opération avant de poursuivre. Cela évite les doublons au sein du système, mais une transaction de base de données ne garantit pas à elle seule qu’une API externe n’appliquera un effet qu’une seule fois.
Si l’action a lieu dans un autre service, utilisez une clé d’idempotence acceptée et traitée de manière idempotente par ce service, si elle est disponible. Enregistrez l’identifiant de corrélation, la tentative et les réponses. Si la réponse est perdue ou si le résultat est inconnu, ne répétez pas l’effet à l’aveugle : consultez l’état distant à l’aide de cet identifiant ou rapprochez le résultat à partir de données fiables. S’il est impossible de confirmer si l’effet s’est produit, interrompez les nouvelles tentatives automatiques et transmettez le cas à une personne chargée de l’exploitation. Une défaillance connue avant l’envoi de la requête peut autoriser une nouvelle tentative, à condition de vérifier à nouveau l’état et l’autorisation.
Si un worker échoue et laisse une proposition à l’état executing, ne la marquez pas automatiquement comme exécutée et ne la renvoyez pas sans diagnostic. Un processus de récupération doit déterminer si l’effet s’est produit, en s’appuyant sur le journal local et, le cas échéant, en consultant le service distant. S’il confirme que l’effet ne s’est pas produit, il peut ramener la proposition à un état permettant son exécution, uniquement après avoir vérifié à nouveau sa validité, les données et l’autorisation ; si le résultat reste inconnu, il doit la maintenir bloquée et faire remonter le cas.
Concevoir une file opérationnelle et une solution manuelle de secours
La file doit permettre de trouver les éléments en attente selon leur ancienneté, leur impact, leur responsable et leur date d’expiration, et afficher le contexte qui motive la décision. Expliquez pourquoi un cas est bloqué et quelle action convient : attendre, demander des modifications, annuler ou faire remonter le cas. L’interface doit également indiquer clairement ce qui se passera en cas d’approbation, et pas seulement proposer des boutons de décision.
Définissez une solution de secours en cas de défaillance d’une dépendance, comme le service de notifications ou une intégration nécessaire à l’exécution de l’action. Il est possible de conserver la proposition en attente et de prévoir une procédure contrôlée permettant à une personne autorisée d’examiner le cas dans le système opérationnel disponible. La procédure manuelle doit respecter les mêmes vérifications, consigner l’acteur et le motif, éviter une exécution en parallèle et rapprocher le résultat lorsque l’intégration est rétablie.
Ne transformez pas une panne technique en approbation implicite. Si l’identité, les permissions ou les informations nécessaires ne peuvent pas être vérifiées, le système doit échouer de manière sécurisée : suspendre le processus, informer et faire remonter le cas. Définissez qui peut débloquer le processus, comment cette intervention est documentée et quelles tâches doivent être examinées une fois le service rétabli.
Tester le flux et surveiller son fonctionnement
Testez les règles métier et les parcours complets : approbation, rejet, demande de modifications, expiration, annulation et nouvelles tentatives. Ajoutez des tests de permissions pour confirmer qu’une personne non autorisée ne peut pas modifier l’état, ainsi que des tests de concurrence pour vérifier que deux décisions simultanées ne déclenchent pas deux exécutions.
Incluez des cas où les données changent pendant l’attente ou juste avant l’exécution, où l’exécution à distance échoue après l’acceptation de la requête et où une réponse est perdue alors que l’effet s’est produit. Vérifiez que la prise en charge atomique garantit qu’un seul worker exécute la proposition, que les nouvelles tentatives rejettent les autorisations expirées et que chaque intervention manuelle laisse une trace suffisante. En production, surveillez le volume et l’ancienneté des éléments en attente, les expirations, les erreurs d’exécution et les cas nécessitant un rapprochement.
Un flux bien conçu maintient la supervision humaine là où elle apporte du contrôle, sans faire reposer la sécurité sur la mémoire des équipes. Des états explicites, des permissions séparées, des données examinées toujours à jour, une exécution idempotente et une procédure claire en cas de défaillance transforment une approbation informelle en un processus vérifiable.
