# Une coupure de courant pendant une action d'agent auditée laisse un résultat inconnu

Une coupure de courant pendant une action d'agent auditée ne produit pas un échec unique. Elle crée un problème de preuve. L'agent, la passerelle locale, le système d'exploitation, le réseau et le service distant peuvent chacun s'arrêter à un moment différent. Si vous réduisez cette situation à « échec » parce que l'agent n'a pas reçu de réponse, vous finirez par relancer une action qui a déjà eu lieu.

Cette erreur est facile à commettre parce que les journaux ressemblent à une histoire. L'enquêteur voit une action approuvée, une requête sortante, puis un trou. Ce trou semble apporter une conclusion. Ce n'est pas le cas. Il correspond à un intervalle où plusieurs résultats très différents restent possibles. La bonne réponse dépend du système qui détient le fait recherché.

C'est là qu'une piste d'audit devient utile. Elle doit conserver ce que le système local sait, prouver que les enregistrements conservés n'ont pas été modifiés discrètement et rendre l'incertitude visible. Elle ne peut pas transformer une réponse perdue en preuve qu'une écriture de base de données, un paiement, un déploiement ou une commande distante n'a pas eu lieu.

## Un délai d'attente est une lacune de preuve, pas un échec confirmé

Un délai d'attente indique qu'un participant n'a pas observé de réponse exploitable avant son échéance. Il ne dit pas si la destination a reçu la demande, commencé le travail, validé l'effet de bord ou perdu la réponse sur le chemin du retour.

Séparez ces résultats dans les notes d'incident et dans toute interface qui décrit les actions des agents :

- **Échec confirmé :** la destination ou l'exécuteur local a fourni une preuve durable indiquant que l'opération a été refusée ou annulée.
- **Réussite confirmée :** le système qui gère l'état modifié a renvoyé un accusé de réception et une lecture ultérieure confirme l'état attendu.
- **Résultat inconnu :** l'action a peut-être eu lieu, mais les preuves disponibles ne permettent pas de le déterminer.
- **Non tenté :** la passerelle a refusé l'action avant de la transmettre à un exécuteur ou à un moyen de transport.

« Inconnu » ne signifie pas « probablement échoué ». C'est un état opérationnel distinct. Il faut suspendre les nouvelles tentatives automatiques, préserver les preuves, interroger le système faisant autorité, puis décider si une action compensatoire ou une nouvelle tentative est sûre.

N'utilisez « partiellement réussi » que lorsque vous pouvez nommer la sous-opération terminée et celle qui ne l'est pas. Un pipeline de déploiement qui a créé un artefact sans le promouvoir donne un résultat partiel si les deux faits sont vérifiés. Une demande qui disparaît après l'écriture d'octets dans une socket a un résultat inconnu, même si elle semblait simple.

La RFC 9110 fait la même distinction dans les termes du protocole. Elle permet de rejouer automatiquement les méthodes idempotentes après une défaillance de communication, car répéter l'opération prévue produit le même effet prévu. Elle déconseille de relancer automatiquement une demande non idempotente, sauf si le client peut établir que la demande originale n'a pas été appliquée ou si l'application rend les répétitions sûres. C'est une règle sémantique, pas une astuce de transport.

Une passerelle d'actions d'agent doit rapporter précisément les faits locaux. « Demande envoyée, fin non observée » est utile. « Action échouée » est une affirmation que le processus local n'est peut-être pas autorisé à faire.

## Une coupure de courant sépare une action en plusieurs limites de durabilité

Une action peut franchir plusieurs limites avant qu'un résultat final soit visible. Écrivez-les avant les tests, car un test qui ne fait tomber qu'un processus donne une confiance trompeuse.

Une action HTTP typique comporte au moins ces limites :

1. La passerelle accepte une intention autorisée et l'enregistre localement.
2. Elle construit la requête authentifiée et commence à la transmettre.
3. Le service distant reçoit suffisamment de données pour commencer le traitement.
4. Il valide son effet de bord et crée un accusé de réception.
5. La passerelle reçoit la réponse et enregistre le résultat observé.

Une action SSH suit un chemin comparable, mais l'hôte distant peut commencer une commande avant que le client local connaisse son code de sortie. Il peut aussi lancer un travail qui survivra à la session. Une connexion TCP ou SSH réussie ne dit presque rien sur le point où la commande s'est arrêtée.

Les écritures locales ont leurs propres limites. Un processus peut ajouter un événement d'audit, le système d'exploitation peut accepter cet ajout dans son cache, le système de fichiers peut ordonner les métadonnées et les données, puis le stockage peut rendre les octets résistants à une coupure. Ces événements ne sont pas interchangeables.

La spécification POSIX de `fsync()` indique que l'appel demande le transfert des données en attente d'un fichier ouvert vers son périphérique de stockage et qu'il ne revient qu'une fois l'opération terminée ou une erreur signalée. Sa justification précise aussi que l'assurance réelle dépend de l'implémentation et de la configuration du stockage. Une application ne peut donc pas déduire la sécurité face à une coupure simplement parce qu'un appel d'écriture a réussi.

Pour l'enquête, attribuez à chaque enregistrement une classe de preuve au lieu de traiter tous les horodatages comme également durables :

| Classe de preuve | Ce qu'elle permet d'établir | Ce qu'elle ne permet pas d'établir |
| --- | --- | --- |
| Intention acceptée | La passerelle a accepté de tenter une action précise | Qu'une demande a quitté la machine |
| Distribution commencée | La passerelle a commencé l'exécution locale ou le transport | Que la destination a reçu toutes les données |
| Accusé de réception distant | La destination affirme avoir accepté ou validé une opération | Que le système local a conservé l'accusé avant le plantage |
| Enregistrement local de fin | La passerelle a observé et enregistré un résultat | Que l'état distant n'a pas changé par la suite |
| Lecture de rapprochement | Une requête ultérieure a observé l'état de la destination | Le moment exact du changement, sauf si la destination le consigne |

Cette distinction est volontairement stricte. Une ligne indiquant « envoi de la demande » est une preuve de distribution, pas de livraison. Un corps de réponse conservé en mémoire est une preuve d'observation, pas une preuve locale durable tant que le chemin de persistance n'a pas résisté au modèle de défaillance testé.

## Attribuez une identité à chaque effet de bord avant de tester les pannes

Un enquêteur ne peut pas rapprocher une action interrompue si le système distant ne dispose d'aucun moyen stable de l'identifier. Ajoutez une identité d'opération avant d'écrire un test de chaos, pas après l'apparition du premier doublon en production.

Utilisez deux identifiants lorsque c'est possible :

- un identifiant d'action généré localement, qui désigne la tentative unique de la passerelle ;
- un identifiant reconnu par la destination, comme une clé d'idempotence, un jeton de demande, un identifiant de déploiement ou une référence de transaction.

Ils peuvent contenir la même valeur aléatoire, mais ne signifient pas forcément la même chose. L'identifiant d'action désigne un enregistrement d'audit local. L'identifiant distant n'est utile que si la destination le conserve avec l'effet de bord et permet de retrouver l'état obtenu.

Pour une API qui prend en charge les clés d'idempotence, rendez l'identité explicite dans la demande et enregistrez une empreinte du contenu utile. Cette empreinte permet de détecter la réutilisation accidentelle d'une ancienne clé avec une demande modifiée.

```http
POST /v1/releases HTTP/1.1
Host: deploy.example.internal
Idempotency-Key: 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1
Content-Type: application/json

{
  "operation_id": "8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1",
  "service": "catalog",
  "artifact": "sha256:3c1f...",
  "environment": "production"
}
```

Ne consignez pas l'en-tête d'autorisation, le jeton bearer ni un corps complet susceptible de contenir des secrets. Enregistrez la méthode, l'identité de la destination, les métadonnées sûres de la demande, l'identifiant d'action, l'identifiant d'opération et l'empreinte du contenu. Il faut assez de preuves pour comparer les tentatives, sans créer une seconde fuite d'identifiants dans le système d'audit.

Un enregistrement d'intention peut ressembler à ceci :

```json
{
  "event": "intent_accepted",
  "action_id": "act_01JX8F3Z6Z",
  "operation_id": "8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1",
  "channel": "http",
  "destination": "deploy.example.internal",
  "method": "POST",
  "path": "/v1/releases",
  "payload_sha256": "3c1f...",
  "authorization": "approved_for_session"
}
```

Cet enregistrement évite une erreur fréquente : comparer une nouvelle tentative à la première uniquement par horodatage et point d'accès, ignorer un artefact ou un compte différent, puis déclarer les deux opérations équivalentes.

Pour SSH, placez l'identifiant d'opération là où l'hôte distant peut le conserver. Une commande shell peut l'inclure dans ses journaux structurés, un script de déploiement peut l'écrire dans un enregistrement de version, ou un wrapper distant peut refuser un identifiant déjà utilisé. Ne vous fiez pas à la seule transcription du client SSH.

```sh
ssh deploy@host.example.internal \
  '/usr/local/bin/release --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1 --artifact sha256:3c1f...'
```

Si la commande démarre un travail en arrière-plan, demandez au processus de conserver l'identifiant d'opération avant toute modification. Sinon, une déconnexion peut laisser un hôte encore actif sans moyen fiable de retrouver le travail.

## Simulez les interruptions aux limites qui changent la décision

Un test utile arrête le processus aux points qui conduisent à des décisions différentes. Terminer aléatoirement un client en boucle permet de trouver des bugs, mais n'explique pas le sens du journal.

Construisez une destination de test capable de se mettre en pause à des phases contrôlées et de répondre à une requête de rapprochement par identifiant d'opération. Elle n'a pas besoin d'être complexe. Elle doit distinguer demande reçue, effet de bord validé et réponse envoyée.

Commencez par cinq cas :

1. **Plantage avant la persistance de l'intention.** L'action doit être absente du journal local durable et de la destination. Si la destination a changé, l'ordre des opérations est incorrect ou un autre composant a lancé l'action.
2. **Plantage après la persistance de l'intention, avant la distribution.** La piste doit montrer une action acceptée sans enregistrement de distribution. Elle ne peut être classée comme non tentée que si la passerelle peut prouver qu'elle ne l'a jamais remise à un transport ou à un exécuteur.
3. **Plantage pendant la transmission.** La destination peut ne rien voir, recevoir une demande partielle ou recevoir une demande complète. Classez le résultat comme inconnu, sauf si la destination fournit un refus ou une consultation définitive.
4. **Plantage après la validation distante, avant la persistance locale de la fin.** La destination doit montrer l'opération comme terminée alors que le journal local ne contient pas d'événement de fin. C'est le test qui révèle les nouvelles tentatives dangereuses.
5. **Plantage après la persistance locale de la fin, avant réception de la réponse par l'agent.** La piste locale contient la réponse même si l'agent pense avoir subi un délai d'attente. Une nouvelle session doit consulter l'enregistrement au lieu de lancer aveuglément une seconde opération.

Un banc d'essai local peut coordonner la passerelle et un service de test avec des fichiers de pause nommés. L'implémentation exacte varie, mais le contrat du test reste le même. Le banc doit indiquer la limite atteinte avant l'interruption et conserver l'état de la destination pour le rapprochement.

```sh
# Terminal 1: start the test destination with controlled pauses.
./test-api --pause-after=commit --state-file ./tmp/remote-state.json

# Terminal 2: run one authorized action with a known operation ID.
./gateway-test invoke \
  --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1 \
  --pause-file ./tmp/client-dispatch.pause

# When the destination reports "committed", terminate the local process.
kill -9 "$(pgrep -f 'gateway-test invoke')"

# Terminal 3: inspect the destination without issuing another mutation.
./test-api lookup 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1
```

`kill -9` teste le plantage d'un processus. Il ne teste ni le comportement du stockage lors d'une coupure brutale ni l'annulation d'une action déjà acceptée par le service distant. Cette limite est utile pour apprendre à classer les résultats : elle oblige l'équipe à ne pas considérer la disparition de l'appelant comme une preuve sur l'appelé.

Pour tester réellement une coupure, utilisez une machine jetable ou un environnement virtualisé permettant de reproduire les arrêts brutaux en toute sécurité. Ne débranchez pas un poste contenant l'unique copie d'un coffre de production, de matériel d'audit ou d'un répertoire de travail. Conservez pour chaque exécution la version exacte, le mode de stockage, les entrées de test et la source de temps. Un résultat sans ce contexte n'est qu'une anecdote.

## Une piste d'audit doit dire ce qu'elle sait et conserver ce qu'elle ignore

Un bon enregistrement d'audit ressemble à un ensemble d'affirmations dont la portée est claire. Il ne prétend pas connaître les systèmes qu'il ne peut pas observer.

Pour une action interrompue, enregistrez des événements distincts plutôt que d'écraser un statut mutable. Une séquence en ajout seul peut représenter la réalité sans inventer de réponse finale :

```text
intent_accepted     action=act_01JX8F3Z6Z op=8b4d... principal=agent-process
transport_started   action=act_01JX8F3Z6Z channel=http
outcome_unobserved  action=act_01JX8F3Z6Z reason=local-process-terminated
reconciled_success  action=act_01JX8F3Z6Z receipt=rel_4921 source=remote-api
```

La troisième ligne ne doit pas dire `remote_failed`. Elle indique seulement que la passerelle n'a pas observé de résultat final. La quatrième ajoute une affirmation ultérieure provenant de la source qui gère l'état de la version.

Cette distinction rend aussi la détection des falsifications plus utile. Une chaîne de hachage peut révéler les modifications apportées au matériel d'audit conservé, mais elle ne peut pas recréer un événement qui n'a jamais atteint le stockage durable. Si une machine perd l'alimentation entre un appel sortant et une écriture dans le journal, une chaîne intacte peut s'arrêter proprement avant le résultat de l'action. Ce n'est pas forcément une chaîne rompue, mais une lacune qui doit être rapprochée.

Sallyport projette ses journaux Sessions et Activity depuis un journal d'audit chiffré, chaîné par hachage et sans accès en écriture, et `sp audit verify` vérifie cette chaîne hors ligne sur le texte chiffré. L'enquêteur peut ainsi vérifier si l'historique local conservé a été modifié, tout en laissant le résultat distant aux preuves distantes lorsque c'est nécessaire.

Conservez séparément les preuves d'autorisation et les preuves de résultat. Une approbation montre qu'une personne ou un contrôle configuré a permis l'action. Elle ne montre pas que l'action s'est terminée. Mélanger ces affirmations transforme une modification de production approuvée mais interrompue en modification déclarée à tort comme terminée.

La même prudence s'applique aux horodatages. Les horloges murales aident à corréler les systèmes, mais n'établissent pas un ordre global lorsque les machines divergent ou que les tampons retardent les écritures. Si l'ordre compte, enregistrez des numéros de séquence dans chaque journal, conservez les identifiants d'accusé distants et capturez les horodatages propres au service pendant le rapprochement.

## Les appels réseau exigent un rapprochement distant

Lorsqu'un appel HTTP perd sa réponse, la destination est généralement l'autorité qui sait si l'état demandé a changé. Interrogez-la avant toute nouvelle tentative et utilisez une requête assez précise pour distinguer cette opération d'un travail similaire.

L'ordre de rapprochement le plus sûr est le suivant :

1. Recherchez l'identifiant d'opération ou la clé d'idempotence sur la destination.
2. Si elle renvoie une opération terminée, comparez les identifiants de ressources et l'empreinte du contenu avec l'intention originale.
3. Si elle renvoie un refus enregistré, conservez cette réponse comme preuve d'échec.
4. Si elle n'a aucun enregistrement, vérifiez si l'API documente un traitement différé, des files asynchrones ou la création tardive de l'enregistrement avant de relancer.
5. Ne relancez que lorsque les sémantiques du point d'accès et les preuves rendent la répétition sûre.

Ne considérez pas `GET` comme une vérification inoffensive simplement parce qu'il s'agit d'une méthode sûre. Certaines API dissimulent un travail derrière un point de lecture et certains caches de réponse prennent du retard sur le chemin d'écriture. Vérifiez le contrat du fournisseur et, si possible, récupérez la ressource ou l'enregistrement précis de l'opération créée plutôt que de rechercher dans une liste par date.

Les méthodes HTTP fournissent des indications, mais ne suffisent pas à déterminer le comportement applicatif. Une requête `PUT` peut être idempotente au niveau HTTP alors que le serveur envoie des courriels en double, facture deux fois l'utilisation ou déclenche un hook de déploiement à chaque réception. La RFC 9110 précise que l'idempotence concerne l'effet demandé, tandis que le serveur peut conserver des journaux distincts ou produire d'autres effets de bord. L'identité documentée par le propriétaire de l'API compte donc davantage qu'un verbe dans une bibliothèque cliente.

« Relancez chaque délai d'attente deux fois » est une mauvaise recommandation. Elle peut transformer un problème de transport temporaire en mouvement d'argent doublé, création de compte en double ou double mise en production lorsque le point d'accès ne permet pas une répétition sûre. Une politique de nouvelle tentative doit nommer le type d'opération, le mécanisme d'idempotence, le délai maximal et les preuves autorisant la relance.

Si un service distant n'offre ni recherche ni idempotence, la réponse honnête peut être qu'il est impossible de résoudre automatiquement le résultat. Créez alors un processus compensatoire, par exemple une file d'examen humain contenant l'empreinte exacte de la demande et un compte en lecture seule permettant d'inspecter l'état concerné.

## Les commandes SSH nécessitent une preuve de l'hôte distant

Une session SSH interrompue laisse souvent plus d'ambiguïté qu'un appel d'API, car la commande peut s'exécuter de l'autre côté après la disparition du client. Un code de sortie perdu ne signifie pas que la commande a échoué. Il signifie que l'observation manque.

Évitez une seule longue ligne shell qui effectue plusieurs modifications sans points de contrôle. Divisez le travail distant en opérations dotées d'identifiants et d'un état durable. Un wrapper de déploiement peut, par exemple, enregistrer `received`, `validated`, `applied` et `completed` pour un identifiant donné, puis fournir une commande d'état en lecture seule.

```sh
/usr/local/bin/release-status \
  --operation-id 8b4dbdb6-61e1-49ea-a5b5-9ae225eb2af1
```

Le wrapper doit écrire son état avant de commencer une action non répétable, et non après. S'il alloue une ressource cloud, publie un paquet ou bascule le trafic, il doit conserver l'accusé du fournisseur avec le même identifiant d'opération. S'il ne le peut pas, placez l'opération derrière une file distante qui en est capable.

Méfiez-vous des pièges de nettoyage shell comme preuves de récupération. Un piège local ne s'exécute pas après une coupure brutale. Un piège distant peut ne pas s'exécuter après un arrêt forcé et peut s'exécuter alors qu'un processus enfant continue. Le nettoyage peut limiter les dégâts, mais il ne prouve pas l'état final.

N'utilisez un marqueur distant que lorsque ce marqueur et l'effet de bord ont un lien significatif. Une ligne ajoutée à `/tmp/action-done` ne prouve pas qu'une migration de base de données a été validée. Une entrée dans une table de migration écrite dans la même transaction fournit une meilleure preuve. Un enregistrement créé par le contrôleur de déploiement est encore plus fiable.

Sallyport fait passer SSH par son assistant sans état `sp-ssh` intégré, mais la même règle s'applique : l'enregistrement local établit ce que la passerelle a tenté et observé. Seul l'hôte distant, ou le système modifié par la commande, peut trancher un résultat distant non observé.

## Suivez une version interrompue comme le ferait un enquêteur

Supposons qu'un agent demande une version de production par un point d'accès HTTP. La passerelle enregistre une intention autorisée avec l'identifiant d'action `act_01JX8F3Z6Z`, l'identifiant d'opération `8b4d...`, l'empreinte d'artefact `3c1f...` et une approbation de session. Elle commence la demande. Le service de version valide celle-ci et attribue l'accusé `rel_4921`. Avant que la réponse n'atteigne la passerelle, l'ordinateur portable perd l'alimentation.

Après le redémarrage, la transcription de l'agent indique un délai d'attente. La piste locale s'arrête à `transport_started`. Celui qui considère cette ligne comme une preuve d'échec soumet la même version avec un nouvel identifiant d'opération. Le service crée une seconde version. Si le point d'accès active immédiatement la version, la seconde demande est peut-être seulement bruyante. Si elle déclenche une migration irréversible, le coût peut être élevé.

L'enquête correcte commence par le gel de la nouvelle tentative automatique pour `act_01JX8F3Z6Z`. Vérifiez la chaîne d'audit locale. Notez le dernier événement conservé, les preuves de terminaison du processus local, la destination, l'empreinte du contenu et l'identifiant d'opération. Interrogez ensuite le service de version pour `8b4d...`.

Trois résultats sont utiles :

- Le service renvoie `rel_4921` avec l'empreinte `3c1f...`. Classez l'action originale comme une réussite confirmée après rapprochement. L'absence de fin locale reste une lacune d'audit, pas une raison de rejouer la version.
- Le service renvoie un refus durable lié à `8b4d...`. Classez l'action comme un échec confirmé. Conservez la raison du refus avant de décider si une demande corrigée est nécessaire.
- Le service ne renvoie aucun enregistrement. Vérifiez s'il met les demandes en file avant de créer les enregistrements d'opération et si le chemin de consultation peut être en retard. S'il ne peut pas exclure un traitement différé, conservez le résultat inconnu et transmettez le dossier au lieu de relancer aveuglément.

Ce qui ne tranche pas le cas : le délai d'attente de l'agent, l'arrêt du processus de la passerelle ou l'approbation humaine de l'action. Ces faits comptent, mais aucun ne gère l'état de la version.

Cette analyse révèle aussi une exigence de conception. Si la destination ne peut pas rechercher par identifiant d'opération, la passerelle doit éviter les actions non répétables sans supervision contre cette destination ou imposer une procédure de rapprochement humain. La qualité de l'audit ne compense pas une API qui ne permet pas d'identifier durablement ses propres effets de bord.

## Les règles de nouvelle tentative doivent rester assez étroites pour les mauvais jours

Une politique de nouvelle tentative doit dire davantage que « relancer en cas d'erreur réseau ». Présentez-la sous forme de tableau de décision que l'implémenteur et l'intervenant peuvent suivre.

| Type d'action | Preuve après interruption | Nouvelle tentative automatique ? | Protection requise |
| --- | --- | --- | --- |
| Requête en lecture seule | Aucune réponse | Généralement oui | Nouvelles tentatives limitées et délais de la destination encadrés |
| Mise à jour idempotente | Aucune réponse | Oui, si la destination respecte une identité stable | Même identité de ressource et même contenu |
| Création ou déclenchement | Aucune réponse | Seulement après rapprochement ou avec idempotence documentée | Recherche distante par identifiant d'opération |
| Mouvement d'argent ou modification destructive | Aucune réponse | Non | Examen humain et vérification de l'état faisant autorité |
| Commande SSH avec effets de bord | Session perdue | Non | État de l'opération distante et refus des doublons |

Ne laissez pas les agents inventer un nouvel identifiant d'opération pendant la récupération. C'est un générateur subtil de doublons. Si une relance est valide, réutilisez la même identité reconnue par la destination et prouvez que le contenu correspond à l'intention originale. Si la modification souhaitée a changé, il s'agit d'une nouvelle action qui mérite une nouvelle décision d'autorisation.

Définissez un état final pour les actions non résolues. « Inconnu, rapprochement en attente » vaut mieux qu'une tâche qui réessaie indéfiniment parce que la machine d'état n'admet pas l'incertitude. Attribuez à cet état un responsable, une échéance et une procédure d'escalade.

## Préservez les preuves avant que les systèmes n'effacent la réponse

La première heure suivant une interruption est celle où les services distants possèdent encore les traces de requêtes, les entrées de file et le contexte récent des opérateurs. Capturez les faits avant la rétention des journaux, l'expiration des caches ou un autre déploiement.

Conservez le matériel d'audit local dans sa forme originale et vérifiez-le avant d'en copier des extraits dans un ticket. Notez l'identifiant d'action, l'identifiant d'opération, la destination, l'empreinte du contenu, l'autorisation, le dernier événement local et l'heure du redémarrage. Recueillez ensuite l'enregistrement distant, la révision de la ressource, l'identifiant de demande du fournisseur et la source de temps du service.

Ne réparez pas l'historique en ajoutant un faux événement de fin. Ajoutez un événement de rapprochement ultérieur qui indique sa source et ses preuves. Les enquêteurs doivent voir la limite originale, car elle indique ce que le système savait à ce moment-là.

La leçon durable est inconfortable mais simple : une action auditée peut être correctement autorisée, soigneusement consignée et tout de même avoir un résultat distant inconnu après une coupure de courant. Créez les identités d'action, les accusés distants et les chemins de rapprochement avant de laisser un agent autonome effectuer un travail qui ne peut pas être exécuté deux fois sans risque. Lorsque la lumière s'éteint au mauvais moment, ces choix déterminent si votre équipe enquête sur une lacune ou crée un second incident.