Ce que signifient ces termes
Toute vérification intégrée dans le parcours d'une requête peut échouer à produire une réponse: une dépendance expire, un signal manque, une clé ne peut pas être récupérée. Ouverture en cas d'échec signifie que la requête se poursuit comme si la vérification n'existait pas. Fermeture en cas d'échec signifie que la requête emprunte le parcours le plus strict: elle est refusée, soumise à un challenge ou envoyée vers un contrôle plus fort déjà en place.
Aucun des deux n'est correct en général. Le bon choix dépend de ce que fait la route et du coût d'une mauvaise décision.
Pourquoi cela compte pour les vérifications d'acteur
Les vérifications d'acteur ajoutent du contexte aux requêtes: si l'interaction semble humaine, assistée par AI, pilotée par un agent ou inconnue. Lorsque ce contexte n'est pas disponible, l'application doit quand même répondre. Deux schémas d'échec sont fréquents:
- Fermeture involontaire en cas d'échec. Un délai d'attente ou un signal manquant est traité comme suspect, et de vrais utilisateurs sont bloqués pendant une panne.
- Ouverture involontaire en cas d'échec sur des actions sensibles. Un résultat manquant est discrètement traité comme humain, et une action à fort impact se poursuit avec moins de contrôle que prévu.
Les deux viennent du fait de laisser le choix implicite. La correction consiste à le décider explicitement, route par route. Notre article sur la conception de politiques au niveau de l'application pour les humains et les agents AI montre comment le comportement en cas d'échec s'inscrit dans une politique par route.
Comment choisir
Une approche pratique consiste à regrouper les routes par niveaux de risque:
- Faible impact (pages publiques, documentation, routes de catalogue en lecture seule): ouverture en cas d'échec. Un résultat d'acteur manquant ne devrait rien changer.
- Impact moyen (inscriptions, envois de formulaires, recherches avec coût): en général, ouverture en cas d'échec avec journalisation, ou application d'une adaptation légère comme une limite de débit standard.
- Fort impact (modifications de compte, exportations de données, actions irréversibles): fermeture en cas d'échec vers votre contrôle plus fort existant, comme une réauthentification ou une confirmation. L'objectif n'est pas de bloquer, mais de revenir au contrôle que vous utiliseriez de toute façon.
Définissez ensuite le même comportement pour les cas associés:
- Délai d'attente: la vérification n'a pas répondu à temps.
- Télémétrie manquante: l'intégration ne s'est pas exécutée ou un signal était absent.
- Unknown: la vérification s'est exécutée mais les éléments n'ont pas permis de conclure.
- Éléments obsolètes: le résultat est ancien et ne doit pas être réutilisé pour une action plus sensible.
Idées reçues courantes
- "La fermeture en cas d'échec est plus sûre." Elle reporte le coût sur les utilisateurs légitimes. Pour les routes à faible impact, fermer en cas d'échec pendant un incident peut causer plus de tort que le risque qu'elle évite.
- "Unknown est un échec." Unknown est un résultat valide. Il mérite sa propre gestion explicite, qui peut ou non correspondre à votre gestion des délais d'attente.
- "Un résultat manquant signifie humain." N'inférez jamais une classe d'acteur à partir de l'absence d'éléments.
Comment Proof of Actor le traite
Proof of Actor n'attribue jamais Human à un délai d'attente ni à un résultat Unknown, et son installation ne bloque rien: les équipes commencent en mode observation. Le comportement d'ouverture ou de fermeture en cas d'échec pour chaque route et niveau de risque relève du choix du propriétaire de l'application, appliqué dans votre propre code via Route. Cela rend l'application des règles prévisible et vous permet de vérifier les résultats avant la mise en service d'une politique.
Lisez comment les décisions de routage s'intègrent, ou demandez un accès anticipé.