À 17 h 55, l’application prépare le bilan d’un dossier pour sa responsable. À 18 heures, cette personne quitte le périmètre et ses droits sont retirés. À 18 h 20, un worker envoie l’e-mail préparé, avec le rapport en pièce jointe. Le portail refuse correctement toute nouvelle connexion au dossier, mais le document vient de sortir par un autre chemin. Le retrait des droits n’a pas atteint la file d’envoi.
Concrètement, une autorisation vérifiée à la mise en file ne vaut pas nécessairement autorisation d’envoi plus tard. Entre les deux, le destinataire, le périmètre et le contenu peuvent changer. Le traitement différé doit prendre une décision d’envoi à partir d’informations adaptées au moment où il divulgue les données.
Ce cas concerne les applications métier sur mesure qui envoient rapports, exports et notifications sensibles. Nous suivons un portail fictif de dossiers techniques. Les horaires servent à montrer la course entre retrait d’accès et expédition ; ils ne décrivent pas un incident client.
La conception d’un portail client ou extranet B2B doit traiter ensemble les droits de consultation, les documents et les notifications qui en sortent.
Définir ce que le destinataire est autorisé à recevoir
Une notification peut annoncer l’existence d’un événement, contenir un résumé ou transmettre le document complet. Ces niveaux ne présentent pas la même exposition. Un objet d’e-mail mentionnant un client ou un projet confidentiel peut déjà révéler une information, même sans pièce jointe.
La politique doit préciser qui peut recevoir quoi et pour quelle finalité. Une notification interne liée aux droits du portail ne suit pas forcément la même règle qu’un message contractuel dont l’envoi possède une autre justification. La suppression d’un rôle ne doit donc pas déclencher une règle indistincte sur toutes les communications.
Dans quel cas refaire la décision à l’exécution
Le contrôle est particulièrement important lorsque l’envoi dépend d’une appartenance actuelle à une équipe, d’un mandat sur un dossier ou d’une permission temporaire. Il s’applique aussi aux traitements repris après une panne : un message préparé la semaine précédente peut ne plus avoir de destinataire légitime aujourd’hui.
La fiche OWASP sur l’autorisation recommande de contrôler les permissions côté serveur sur les accès concernés. Pour ce parcours différé, nous en déduisons une décision explicite au moment de préparer la divulgation, au lieu de réutiliser aveuglément le résultat calculé à la création de la tâche.
Conserver une intention d’envoi sans figer tous les droits
Une tâche peut conserver l’identité du dossier, la version du document, le motif de notification et l’identité logique du destinataire. Le worker retrouve ensuite les éléments nécessaires à sa décision. Copier dans la file une liste d’adresses et un indicateur « autorisé » rend le traitement simple, mais fige un état qui peut devenir périmé.
Il faut néanmoins conserver ce qui doit être historique. Si le message porte sur la version 4 d’un rapport, le worker ne doit pas remplacer silencieusement cette version par la version 7. Le contenu à notifier et le droit de le recevoir sont deux dimensions distinctes : l’une peut être figée, l’autre doit être réévaluée selon la politique.
Identifier une personne sans se limiter à son adresse
Une adresse e-mail peut changer ou être partagée. Le dossier conserve l’identité applicative du destinataire et résout l’adresse autorisée au moment prévu par le parcours. En cas de changement, le produit doit décider s’il envoie vers l’adresse actuelle, demande une validation ou annule l’envoi. Cette décision ne doit pas provenir d’un simple remplacement de chaîne.
Pour une boîte collective, le problème est différent : l’application ne maîtrise pas toujours ses membres. Le propriétaire de la boîte et le niveau d’information autorisé doivent être connus. Envoyer une pièce sensible à une liste de diffusion ne devient pas sûr parce qu’un utilisateur individuel possédait les droits à la création du message.
Tester quatre décisions autour du retrait d’accès
Dans le portail fictif, le rapport R-42 est lié au dossier D-8. Alice quitte l’équipe à 18 heures ; Benoît la remplace, mais ne reçoit pas automatiquement les notifications qui lui étaient destinées. Le worker traite ensuite les tâches en attente avec la politique définie.
| Tâche | État observé | Décision |
|---|---|---|
| Rapport pour Alice | Accès au dossier retiré avant le contrôle d’envoi. | Envoi annulé pour ce motif, sans exposer le rapport. |
| Rapport pour Benoît | Accès valide, mais aucune intention d’envoi ne le désigne. | Ne pas rediriger automatiquement le message d’Alice. |
| Notification pour Chloé | Permission valide, adresse vérifiée selon le parcours. | Préparer la communication autorisée. |
| Ancien échec repris | Politique ou accès impossible à vérifier. | Attente ou refus contrôlé ; aucun envoi par défaut. |
Le statut annulé doit être visible dans le suivi sans devenir une alerte technique répétée. Un retrait d’accès peut être un résultat normal. En revanche, l’impossibilité de consulter les droits à cause d’une panne mérite un état distinct et une reprise bornée.
Le changement de responsable ne justifie pas une substitution automatique de destinataire. Le rapport peut contenir une information destinée personnellement à Alice ou correspondre à une action qu’elle avait demandée. Le produit doit définir une nouvelle intention d’envoi si la transmission à Benoît est nécessaire.
Choisir entre pièce jointe et consultation protégée
Une pièce jointe acceptée par le système de messagerie quitte le contrôle direct du portail. Retirer ensuite l’accès au dossier ne retire pas les copies déjà envoyées. Lorsque le besoin le permet, une notification minimale menant à une consultation authentifiée réduit cette dépendance : le portail peut vérifier les droits au moment de l’ouverture.
Le lien doit toutefois mener à un accès réellement protégé. Une URL longue et difficile à deviner peut rester utilisable par toute personne qui la possède. Sa durée, ses possibilités de révocation et son rattachement au destinataire doivent être compris avant de la présenter comme équivalente à une connexion au portail.
Ne pas déplacer les données sensibles dans l’aperçu
Un e-mail sans pièce jointe peut encore contenir le nom du dossier, le montant du devis ou une phrase confidentielle. Concevez ensemble l’objet, l’aperçu affiché et le corps. Le niveau de détail doit être celui que la politique autorise à sortir du portail.
Le choix dépend aussi du service attendu. Un utilisateur peut avoir besoin d’un document hors connexion ou d’un envoi formel. Dans ce cas, la pièce jointe reste possible si le parcours l’autorise ; il faut simplement assumer la frontière d’expédition et ne pas promettre une révocation ultérieure que le système ne contrôle pas.
Traiter la course entre contrôle et remise à la messagerie
Refaire le contrôle juste avant l’envoi réduit le risque, mais ne crée pas automatiquement une opération indivisible entre la base des droits et le prestataire de messagerie. Un retrait peut intervenir après la vérification et avant l’acceptation du message. Cette fenêtre doit être discutée selon la sensibilité des données.
Une application peut organiser une décision d’envoi avec un état et une version d’autorisation, puis coordonner les retraits avec les envois non encore remis. Cela demande un protocole explicite. Ajouter un verrou local ne suffit pas si l’envoi externe continue après la libération du verrou ou si un autre processus ignore cette règle.
Nommer la frontière après laquelle le rappel n’est plus garanti
Le standard SMTP, RFC 5321 décrit le transfert de responsabilité après l’acceptation du message. Cette acceptation n’est pas une preuve que le destinataire l’a lu. Elle marque néanmoins une étape différente d’un message encore conservé uniquement dans la file de l’application.
Le support doit distinguer « en attente », « annulé avant remise », « accepté par la messagerie » et les informations de livraison disponibles. Une option d’annulation ne doit pas afficher un succès certain sur un message déjà remis à un système que l’application ne peut plus contrôler.
Reprendre les erreurs sans retrouver une ancienne autorisation
Une reprise repasse par les contrôles appropriés. Elle ne doit pas réutiliser un résultat favorable calculé avant une panne de plusieurs heures. Le journal conserve la raison du premier échec, la tentative suivante et la décision d’autorisation propre à cette tentative.
Si le prestataire a accepté le message mais que la réponse a été perdue, un nouvel envoi peut créer un doublon. Utilisez les références et mécanismes de consultation proposés par le fournisseur, puis traitez les résultats inconnus selon une politique définie. L’idempotence locale seule ne prouve pas qu’aucun e-mail n’est parti.
Mesurer les annulations légitimes et les pannes séparément
Le nombre de messages annulés après retrait d’accès peut démontrer le bon fonctionnement du contrôle. Il ne doit pas être mélangé avec les erreurs de messagerie. À l’inverse, une file de messages dont les droits ne peuvent plus être vérifiés signale un problème d’exploitation à traiter.
La revue périodique des accès aide à décider quels droits retirer. Le parcours d’envoi doit ensuite appliquer ces décisions aux tâches encore actives, sinon la revue corrige le portail tout en laissant une voie de sortie différée.
Erreurs fréquentes : un contrôle juste, placé trop tôt
Le premier piège est de considérer l’utilisateur connecté comme preuve suffisante pour tous les futurs traitements qu’il déclenche. Ses droits peuvent changer, tout comme le périmètre du dossier. Le worker doit comprendre quelle autorité il utilise au moment d’agir.
Le deuxième est de faire envoyer tous les rapports par un compte technique très privilégié sans vérifier leurs destinataires. Le compte peut avoir besoin de lire le document pour le produire ; ce droit technique ne signifie pas que toutes les adresses de la tâche peuvent le recevoir.
Le troisième est de masquer l’incertitude derrière un bouton « rappel ». Lorsque l’application ne contrôle plus les copies, elle doit expliquer l’état réel et suivre la procédure d’incident appropriée. La conception du parcours avant l’envoi est plus fiable qu’une promesse de récupération après coup.
Plan d’action : exercer un retrait pendant une file d’attente
Commencez par classer les notifications selon leur contenu et leur fondement d’autorisation. Pour chacune, indiquez ce qui est figé à la création et ce qui doit être relu à l’exécution. Le modèle d’habilitations métier fournit le vocabulaire des actions et des périmètres à vérifier.
Préparez ensuite une tâche contenant une vraie version de document dans un environnement de recette, puis suspendez son consommateur. Retirez le droit, changez le responsable et redémarrez le traitement. Contrôlez l’absence de divulgation, le motif d’annulation et le fait qu’aucun destinataire de remplacement n’a été inventé.
Exercez la panne du service de droits et la réponse perdue du service d’e-mail. Les deux situations doivent produire des états différents. Faites aussi ouvrir le lien par un utilisateur non autorisé et par l’ancien destinataire après retrait, afin de vérifier la protection au moment de la consultation.
Enfin, faites lire les états par le support. Il doit pouvoir expliquer ce qui a été préparé, annulé ou remis à la messagerie sans consulter le contenu confidentiel du rapport. Cette lisibilité permet de traiter les demandes de reprise sans contourner les contrôles pour « débloquer » la file.
- Annuler la divulgation si le destinataire n’a plus le droit requis avant la remise du message.
- Différer l’envoi lorsque la politique ne peut pas être vérifiée ; ne pas interpréter une panne comme une autorisation.
- Traiter une acceptation de messagerie au résultat incertain avant de réémettre, en conservant la référence de la première tentative.
Relier la notification aux décisions d’habilitation
Le modèle de droits que le worker doit appliquer
Les permissions doivent représenter des actions et des périmètres métier, pas seulement des rôles techniques. Cette lecture aide à définir le droit de recevoir un document et à le distinguer du droit technique du worker de lire les données nécessaires à sa production. Définir les habilitations métier.
La revue qui retire les droits devenus inutiles
Une revue d’accès produit des décisions à appliquer au système. Elle doit aussi permettre de retrouver leurs effets sur les traitements en attente. Le rapprochement entre retrait et annulation d’envoi évite de conclure à une fermeture complète depuis le seul écran de connexion. Organiser la revue périodique des accès.
Conclusion : autoriser la divulgation au bon moment
Le traitement différé crée une distance entre l’intention et l’envoi. Cette distance suffit pour qu’un droit valide devienne périmé. La file doit donc conserver une intention compréhensible et permettre une décision adaptée à l’exécution.
Le portail, le message et la messagerie possèdent des frontières différentes.
Dawap accompagne la conception de vos applications métier et leurs traitements différés en reliant droits, documents et exploitation. Le bon résultat est une notification utile qui respecte encore son destinataire au moment où elle quitte le système.
