Lorsqu’un changement de configuration ou de données métier peut affecter d’autres utilisateurs, une application peut nécessiter qu’une personne le propose et qu’une autre le vérifie avant son entrée en vigueur. Concevoir ce processus comme un workflow d’approbation des changements dans un SaaS PHP demande plus que l’ajout d’un bouton « approuver » : il faut séparer la proposition de la donnée actuelle, protéger chaque transition et définir ce qui se passe si le contexte change pendant que la demande est en attente.
L’objectif est que le système puisse indiquer, de manière vérifiable, ce qui a été demandé, qui l’a examiné, avec quelles permissions et si le changement a été appliqué. La solution doit être proportionnée au risque : un workflow inutile ajoute des frictions, tandis qu’un workflow insuffisant peut permettre des changements incorrects ou difficiles à retracer.
Déterminer quels changements nécessitent une approbation
Commencez par classer les changements selon leur impact, leur portée et la possibilité de les corriger. Toute donnée modifiable n’a pas besoin d’être soumise à une revue. Un utilisateur qui modifie une préférence personnelle à faible impact peut enregistrer directement le changement. En revanche, il peut être pertinent d’exiger une approbation pour modifier une règle de facturation, une configuration partagée par une organisation ou une donnée de référence affectant plusieurs processus.
Définissez des critères produit explicites. Par exemple, demandez-vous si le changement affecte d’autres utilisateurs que la personne qui le propose, s’il peut modifier des montants ou des permissions, si une deuxième personne est requise par une politique interne et combien coûterait une correction. Documentez également les exceptions et les personnes autorisées à les modifier. Évitez de faire de l’approbation un mécanisme général pour des opérations sans rapport avec le cas traité : le périmètre concerne ici les changements de configuration ou de données métier.
La décision doit être appliquée côté serveur, et pas seulement dans l’interface. Masquer un bouton n’empêche personne d’appeler directement un endpoint. L’API doit déterminer si le type de changement nécessite une approbation et appliquer la règle aussi bien aux opérations individuelles qu’aux actions en masse ou aux intégrations susceptibles de modifier la même donnée.
Séparer la demande de la donnée en vigueur
Ne remplacez pas la donnée en vigueur lors de la création d’une proposition. Enregistrez une demande indépendante contenant, au minimum, l’organisation, la ressource concernée, les valeurs proposées, l’état, l’identité de la personne qui l’a créée et la date de création. Selon le produit, il peut aussi être nécessaire d’enregistrer un motif, l’origine de la demande, une date limite ou une version de la donnée d’origine.
Pour représenter les valeurs, vous pouvez enregistrer des champs typés ou une structure sérialisée validée par le serveur. Dans les deux cas, évitez d’accepter une charge utile arbitraire comme s’il s’agissait d’une mise à jour directe. À la réception de la proposition, validez le schéma, les champs autorisés, les formats et les règles métier. Validez de nouveau les éléments pertinents au moment de l’application, car les conditions peuvent avoir changé pendant l’attente.
Cette conception permet de comparer la valeur en vigueur à la valeur proposée sans modifier l’expérience des autres utilisateurs. Elle permet également à l’écran de revue d’afficher une différence compréhensible. Ne présentez pas comme étant en vigueur une valeur qui est simplement en attente ; indiquez clairement quelle est la donnée appliquée et quelle est la proposition.
Modéliser des états et des transitions explicites
Définissez un petit ensemble d’états aux significations précises. Une séquence courante peut inclure proposed (proposée), in_review (en cours de revue), approved (approuvée), rejected (rejetée), expired (expirée) et applied (appliquée). Tous les produits n’ont pas besoin de l’état de revue : si une décision immédiate suffit, il peut être omis. L’essentiel est que chaque état décrive une situation opérationnelle et ne soit pas une étiquette décorative.
Précisez les transitions valides. Par exemple, une proposition peut passer en cours de revue ou être rejetée ; une demande en cours de revue peut être approuvée ou rejetée ; une approbation peut être appliquée si elle est toujours valide. Une demande expirée ne devrait pas pouvoir être approuvée par la même voie qu’une demande active. Les actions non autorisées doivent échouer avec une réponse cohérente, même si l’interface ne propose pas cette option.
« Approuvée » et « appliquée » ne sont pas synonymes. L’approbation consigne une décision ; l’application modifie la donnée en vigueur. Conserver ces deux étapes permet de détecter les échecs d’application et d’afficher les demandes approuvées qui nécessitent encore une intervention. Si le processus peut être achevé dans une seule transaction de courte durée, la décision et l’écriture peuvent être coordonnées, mais le modèle doit continuer à distinguer ce qui s’est produit.
Vérifier les permissions à chaque transition
Autorisez chaque action côté serveur en fonction de l’organisation, du rôle, de la ressource et de l’état actuel. Ne supposez pas que la capacité à créer une demande donne le droit de l’approuver ou de l’appliquer. Ne faites pas non plus confiance à l’identifiant d’organisation envoyé par le client : déterminez le périmètre à partir d’une session ou d’un justificatif d’authentification validé, puis vérifiez que la demande et la ressource relèvent du même périmètre.
Si l’auto-approbation est interdite, vérifiez que l’identité de la personne qui approuve est différente de celle de la personne qui a proposé le changement. Cette règle doit être appliquée lors de la transition, et pas seulement dans la vue. Définissez également ce qui se passe pour les demandes provenant d’administrateurs, d’utilisateurs de service et de processus automatisés ; les exceptions exigent une politique délibérée, et non une omission accidentelle.
Une approbation devrait être liée à une proposition précise. Si son contenu change, l’approbation précédente n’est plus valide : créez une nouvelle version de la demande ou rétablissez un état nécessitant une revue. Modifier discrètement les valeurs après leur approbation rompt le lien entre ce qui a été examiné et ce qui a été appliqué.
Gérer la concurrence, l’expiration et l’application
Pendant qu’une demande est en attente, un autre acteur peut modifier la donnée d’origine. Pour détecter cette situation, enregistrez la version de la ressource ou les valeurs pertinentes au moment de la création de la proposition. Lors de l’application, comparez la version attendue à la version en vigueur. Si elles ne correspondent pas, ne remplacez pas le nouveau changement sans critères : bloquez l’application, signalez un conflit ou demandez une nouvelle revue, selon les règles du produit.
Dans une base de données relationnelle, une transaction peut protéger la lecture de la demande, la vérification de son état et la mise à jour de la ressource. Le modèle concret dépend du moteur et du niveau de concurrence ; un verrouillage pessimiste ou une mise à jour conditionnelle par version peuvent convenir. Dans tous les cas, la transition doit être atomique : deux demandes simultanées ne devraient pas appliquer deux fois le même changement.
Rendez l’application idempotente ou rejetez les nouvelles tentatives de manière sûre. Si des données sont mises à jour dans la base de données et qu’une notification est également envoyée ou qu’un événement est publié, envisagez d’enregistrer l’événement en attente dans la même transaction, puis de le traiter ultérieurement. Cela réduit le risque d’afficher une notification de réussite pour une écriture qui n’a pas été validée.
Définissez également une politique d’expiration : combien de temps une proposition peut rester active, ce qui entraîne son expiration et si elle peut être renouvelée. L’expiration doit être vérifiée côté serveur lors de l’approbation et de l’application ; il ne suffit pas de modifier l’état au moyen d’une tâche planifiée. Si un délai rend les valeurs ou les conditions peu fiables, exigez une nouvelle proposition.
Auditer le workflow et l’exploiter
Conservez un journal indiquant qui a proposé, approuvé, rejeté et appliqué chaque changement, avec les dates, les identifiants de l’organisation et de la ressource, le résultat et le contexte nécessaire à une investigation. Enregistrez une référence à la version proposée et à la décision. Le journal d’audit ne devrait pas pouvoir être modifié depuis les fonctions habituelles d’édition des demandes. Limitez les données consignées à celles qui sont nécessaires et appliquez les politiques d’accès et de conservation du produit.
L’interface opérationnelle doit aider à trouver les demandes en attente, expirées, bloquées par des conflits ou approuvées mais non appliquées. Expliquez la raison du blocage et proposez une voie sûre pour le résoudre ; ne transformez pas un échec d’application en approbation automatique. Les notifications peuvent signaler de nouvelles tâches et des décisions, mais elles ne sont qu’une aide : l’état enregistré et consultable reste la source de vérité.
Tester les invariants, les permissions et les défaillances
Les tests doivent vérifier les règles qui ne doivent jamais être enfreintes. Une demande non approuvée ne modifie pas la donnée en vigueur ; une personne sans accès à l’organisation ne peut ni la lire ni effectuer une transition ; l’auto-approbation échoue si elle est interdite ; et une demande approuvée ne peut pas être appliquée avec un contenu différent de celui qui a été examiné. Ajoutez des tests pour les états terminaux, les demandes expirées et les transitions invalides.
Testez également les situations de concurrence entre deux approbations ou entre une approbation et une modification de la donnée d’origine. Simulez des défaillances pendant l’application et vérifiez que la demande n’est pas marquée comme appliquée si l’écriture n’a pas été validée. Si une tâche fait expirer les demandes, vérifiez que son exécution répétée ne présente aucun risque. Ces tests transforment les règles métier en garanties vérifiables et contribuent à maintenir le workflow lorsque les permissions ou le modèle de données évoluent.
Comme critère de conception, chaque étape doit avoir un responsable, une condition vérifiable et un résultat observable. Si l’équipe ne peut pas expliquer qui est autorisé à effectuer chaque transition, ce qui se passe en cas de changement concurrent ou comment reconstituer une décision, le workflow doit encore être défini avant son passage en production.
