Contrôles d’intégrité d’une passerelle d’actions locale

Une passerelle d’actions locale n’est saine que lorsqu’elle sait refuser la mauvaise action, exécuter la bonne action contrôlée et laisser des preuves qui résistent à un examen. Un simple moniteur de processus au vert ne prouve presque rien de tout cela. Il vous indique qu’un processus possède un PID. Il ne dit pas si le coffre est verrouillé, si un agent peut atteindre la passerelle, si les identifiants injectés fonctionnent encore ou si la piste d’audit a enregistré l’appel.

Cette distinction compte avec Sallyport, car l’application, la porte du coffre, la décision d’autorisation, l’action externe et le journal d’audit chiffré sont autant de points de défaillance distincts. Les traiter comme un seul signal générique de « santé » crée le pire type de supervision : celle qui reste au vert alors que le contrôle sur lequel vous comptez ne fonctionne plus.

Construisez cela comme une petite suite de validation, pas comme un empilement de contrôles de ports. La suite doit utiliser des cibles de test sans danger, renvoyer des preuves qui ne contiennent pas de secrets et classer correctement un coffre verrouillé. Si une personne doit déverrouiller le coffre avec Touch ID, votre supervision doit signaler clairement cet état au lieu d’essayer de le contourner.

Une application en cours d’exécution n’est que la première condition

Une sonde de disponibilité doit répondre à une question précise : le Mac local peut-il démarrer l’application de passerelle et la maintenir en fonctionnement ? Elle ne doit pas faire croire qu’un processus actif prouve que les actions externes fonctionnent.

Pour une application de barre des menus, commencez par un contrôle local qu’un superviseur peut exécuter sans identifiants. Le nom exact du processus et l’emplacement de l’installation peuvent varier selon les versions. Gardez donc ces valeurs dans un seul fichier de configuration local au lieu de les disperser dans les scripts. Une sonde shell élémentaire peut ressembler à ceci :

#!/bin/sh
set -eu

APP_NAME="Sallyport"

if ! pgrep -x "$APP_NAME" >/dev/null 2>&1; then
  open -a "$APP_NAME"
  sleep 2
fi

if pgrep -x "$APP_NAME" >/dev/null 2>&1; then
  printf 'app=ready\n'
  exit 0
fi

printf 'app=unavailable\n' >&2
exit 2

Cette sonde formule volontairement une revendication modeste. open -a demande à macOS de lancer une application et pgrep observe un processus après cette demande. Cela ne prouve pas que l’application a terminé son initialisation, que son coffre peut répondre à une requête ou que son shim MCP peut accepter un client. Apple décrit Launch Services comme l’interface système utilisée pour lancer et activer les applications. C’est pourquoi il vaut mieux lancer l’application par l’intermédiaire du système d’exploitation que de coder en dur le chemin de son bundle.

Gardez une sortie structurée et sobre. app=ready suffit pour un ordonnanceur. Ne versez pas la sortie de ps dans un journal central où les arguments de commande, les noms d’utilisateur ou les détails de processus sans rapport deviendraient un encombrement permanent.

Un processus peut exister tout en étant bloqué. Il peut aussi être absent parce que le Mac est en veille, qu’aucune session n’est ouverte ou qu’il redémarre après une mise à jour. Votre règle d’alerte doit prévoir un délai de grâce pour ces situations attendues. Une vérification qui alerte quelqu’un chaque fois qu’un ordinateur portable ferme son capot sera désactivée, et elle ne sera alors d’aucune aide lors d’une véritable panne.

Le signal de disponibilité utile est donc local et limité : l’application a démarré, elle est restée présente pendant un court délai de stabilisation et un client MCP peut commencer une session. Le dernier point relève d’une sonde distincte, car il teste une autre frontière.

L’état du coffre doit être un résultat explicite

Un coffre verrouillé est sain lorsqu’il refuse les actions. Qualifier cet état de panne confond le comportement de sécurité avec une défaillance du service.

La porte du coffre de Sallyport est absolue : lorsqu’il est verrouillé, toute action est refusée. Sur le matériel macOS compatible, elle utilise Secure Enclave et Touch ID. Un contrôle doit respecter cette règle. N’écrivez pas un script qui saisit des mots de passe dans une interface, stocke un jeton de contournement biométrique ou considère qu’une session de bureau déjà déverrouillée prouve que le coffre doit l’être aussi.

Utilisez quatre états de résultat au lieu d’un booléen :

• ready : l’application est disponible, le coffre est déverrouillé et les contrôles contrôlés peuvent s’exécuter.
• locked : l’application est disponible, mais le coffre refuse correctement les actions.
• denied-unexpectedly : le coffre est déverrouillé, mais l’action de test prévue a été refusée.
• unavailable : l’application ou son chemin MCP local ne peut pas répondre.

Ce vocabulaire évite une erreur opérationnelle fréquente. Les équipes planifient souvent une sonde avec identifiants pendant la nuit, constatent des échecs après le verrouillage de l’écran et affaiblissent le système jusqu’à ce qu’il puisse se déverrouiller seul. Elles n’ont pas amélioré la supervision. Elles ont supprimé la décision humaine que le coffre était précisément conçu pour exiger.

Le schéma pratique comporte deux parties. Une tâche autonome enregistre la disponibilité de l’application et le refus d’un coffre verrouillé. Une personne, ou une session de poste contrôlée ayant déjà reçu une approbation humaine, lance les contrôles avec identifiants après le déverrouillage. Enregistrez la raison dans la sortie :

{
  "run_id": "hc-2026-07-22T141501Z-8f29",
  "app": "ready",
  "vault": "locked",
  "http": "skipped",
  "ssh": "skipped",
  "audit": "verified",
  "reason": "credentialed checks require an unlocked vault"
}

L’identifiant d’exécution n’est pas un secret. Il donne aux opérateurs un élément stable à comparer plus tard avec l’enregistrement d’activité. N’utilisez pas un nom d’utilisateur, un numéro de série de machine, une URL de point d’accès ou un libellé d’identifiant comme identifiant d’exécution.

L’autorisation par session et l’approbation de chaque appel doivent aussi être traitées séparément. Un nouveau processus d’agent peut nécessiter une approbation de session et un identifiant peut demander une approbation à chaque utilisation. C’est le comportement attendu, pas un test instable. Votre exécuteur doit préciser s’il est conçu pour une session approuvée ou si une personne approuvera chaque appel. Un délai d’attente silencieux n’apporte aucune information à l’enquêteur suivant.

Utilisez des cibles de test qui prouvent l’injection des identifiants

Un contrôle HTTP doit appeler un point d’accès conçu pour valider un identifiant de test précis et renvoyer un résultat fixe qui ne contient pas de secret. Tester une URL publique prouve seulement que le réseau fonctionne. Cela ne dit rien sur le choix de l’identifiant prévu par la passerelle, son insertion dans le bon en-tête ou son maintien à l’écart de l’agent.

Mettez en place un petit service qui accepte un seul chemin, une seule méthode et une seule forme d’identifiant. Stockez le secret de test attendu côté service. Stockez le même secret dans le coffre de la passerelle. Le client qui déclenche l’action ne doit jamais recevoir le secret et le service ne doit jamais le renvoyer dans sa réponse.

Le contrat de réponse peut être aussi réduit :

{
  "check": "agent-gateway-http",
  "result": "ok",
  "request_id": "7d7a0f3c"
}

Le service doit renvoyer 401 lorsque l’identifiant est absent ou incorrect, 405 pour une mauvaise méthode et 200 uniquement lorsque l’identifiant attendu est arrivé. Générez request_id sur le service et gardez-le opaque. Ne le dérivez pas de l’en-tête d’autorisation ni d’une partie de la requête entrante.

Utilisez un chemin dédié comme /agent-gateway-canary. N’ajoutez pas le contrôle à un point d’accès de production existant. Les points d’accès de production accumulent avec le temps des comportements, des limites de débit, des redirections, des règles de négociation de contenu, de mise en cache, de facturation et d’autorisation. Une route de test peut rester volontairement simple.

La RFC 9110 définit la sémantique des méthodes de requête et classe GET, HEAD, OPTIONS et TRACE parmi les méthodes sûres. En HTTP, « sûr » signifie toutefois que l’action demandée ne doit pas modifier l’état prévu de la ressource. Cela ne veut pas dire que l’appel est sans conséquence pour votre compte, vos journaux, vos quotas ou les comportements en aval. Une API peut enregistrer un GET, facturer une requête ou déclencher un effet secondaire dû à une mauvaise implémentation. Construisez une route dont vous pouvez inspecter le comportement côté serveur, au lieu de faire confiance à un verbe familier.

Une mauvaise recommandation fréquente consiste à utiliser curl avec un jeton d’API de production comme contrôle d’intégrité. Cette solution est populaire parce qu’elle tient en une ligne. Elle est incorrecte, car l’historique shell, l’inspection des processus, les journaux CI et les sorties d’erreur créent trop d’endroits où un jeton bearer peut apparaître. Elle contourne aussi le comportement que vous devez tester si la passerelle injecte normalement elle-même les identifiants.

Votre exécuteur doit appeler la passerelle par le même chemin MCP que celui utilisé par un agent. N’inventez pas de client HTTP de secours pour le contrôle. Gardez l’appel propre au transport derrière un adaptateur local, car les noms d’outils et les formats de requête peuvent changer. L’adaptateur reçoit une action logique, demande à la passerelle connectée à MCP de l’exécuter et n’émet que le résultat normalisé.

{
  "action": "http_canary",
  "target": "canary-api",
  "method": "POST",
  "path": "/agent-gateway-canary",
  "expected_status": 200,
  "expected_check": "agent-gateway-http"
}

L’adaptateur doit masquer les secrets en cas d’échec. Il peut signaler http_status=401, transport_error=timeout ou response_schema=invalid. Il ne doit pas afficher les en-têtes sortants, le corps de la requête, une URL complète avec ses paramètres de requête ni la réponse brute sans avoir vérifié que ces données sont sûres.

Une réussite HTTP doit prouver l’action prévue

Un 200 seul constitue une preuve faible. Le contrôle doit valider la réponse du service, la méthode et l’identité de la cible, afin qu’une redirection, une page de proxy ou un dispositif de test obsolète ne produise pas une fausse réussite.

Faites en sorte que la réponse de test identifie le contrôle sans identifier un identifiant. Comparez quelques champs exacts :

status=200
check=agent-gateway-http
result=ok
request_id=7d7a0f3c

Le vérificateur doit accepter tout request_id syntaxiquement valide, puis l’enregistrer avec l’identifiant d’exécution. Il doit rejeter un champ manquant, un corps qui annonce une réussite avec un statut qui n’est pas 2xx et un type de contenu inattendu. Un portail captif, une page d’erreur de proxy d’entreprise ou un enregistrement DNS mal aiguillé renvoient souvent une réponse HTTP valide. Il s’agit d’une réussite du transport, pas de l’action.

La documentation de curl souligne un point connexe : sans --fail ou --fail-with-body, curl ne considère pas un statut HTTP comme 404 ou 401 comme une erreur de commande. Ce comportement convient à un client de transfert général, mais il piège les personnes qui écrivent des moniteurs ne regardant que le code de sortie de curl. Si votre adaptateur utilise curl en interne, récupérez à la fois le résultat du processus et le statut HTTP, puis décidez de la réussite selon votre contrat explicite.

Ne laissez pas un contrôle suivre automatiquement les redirections, sauf si elles font partie de la conception prévue du point d’accès. Une redirection peut envoyer l’appel de test vers une page de connexion qui renvoie 200, ou vers un autre hôte que vous ne vouliez pas contacter. Fixez l’origine HTTPS dans la configuration, validez le certificat avec la pile client habituelle et n’enregistrez l’identité du pair final que si cet enregistrement ne peut pas révéler de détails réseau sensibles.

Les délais d’attente doivent avoir des libellés distincts. Une erreur DNS, un refus TCP, un échec de validation TLS, un refus de la passerelle, un 401 en amont, un 500 en amont et une réponse qui ne correspond pas n’ont pas les mêmes responsables. Si l’exécuteur les appelle tous http=failed, vous perdrez les dix premières minutes de chaque incident à chercher où la requête s’est arrêtée.

Un enregistrement d’échec utile ressemble à ceci :

{
  "run_id": "hc-2026-07-22T141501Z-8f29",
  "check": "http_canary",
  "outcome": "failed",
  "stage": "upstream_response",
  "http_status": 401,
  "request_id": null,
  "secret_material": "redacted"
}

La ligne secret_material rappelle aux personnes qui lisent l’enregistrement que le contenu est masqué, mais elle ne prouve pas que le masquage a fonctionné. Prouvez-le avec des tests : faites délibérément rejeter l’identifiant de test par la cible, capturez stdout et stderr de l’exécuteur et recherchez le secret de test dans ces fichiers. Il ne doit pas apparaître. Répétez avec un JSON incorrect, un délai d’attente, un échec TLS et une erreur d’outil côté agent. Les chemins d’erreur sont ceux par lesquels les secrets s’échappent le plus souvent.

SSH a besoin d’une cible cloisonnée, pas d’un shell de connexion

Un contrôle SSH doit prouver l’authentification et l’exécution d’une commande sur un compte dédié dont le serveur refuse d’exécuter des commandes arbitraires. Une connexion réussie à un hôte administratif général prouve trop de choses dans la mauvaise direction : elle donne au compte de supervision un shell utilisable.

Créez un compte distinct comme gateway-health sur un hôte de test contrôlé. Donnez-lui une commande forcée dans authorized_keys ou une restriction équivalente côté serveur. La commande forcée doit ignorer la commande d’origine, écrire un horodatage et un identifiant d’exécution opaque dans un fichier d’audit local, puis renvoyer une réponse constante.

Une entrée authorized_keys conceptuelle ressemble à ceci :

command="/usr/local/libexec/gateway-health",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAA... gateway-health

La clé publique appartient à l’identité de test de la passerelle. La clé privée reste dans le coffre. Le texte AAAA... est volontairement incomplet, car vous devez générer votre propre matériel cryptographique et non copier un exemple dans un fichier de production.

La commande serveur doit éviter de renvoyer $SSH_ORIGINAL_COMMAND, les variables d’environnement ou les informations d’authentification. Elle peut renvoyer un format fixe :

{"check":"agent-gateway-ssh","result":"ok","receipt":"c2b91a"}

Si vous avez besoin d’un identifiant d’exécution pour la corrélation, transmettez un jeton opaque dans la commande envoyée et faites valider par la commande forcée un format strict, comme des caractères hexadécimaux d’une longueur fixe. N’acceptez jamais une chaîne arbitraire et ne l’écrivez pas dans une commande shell, un nom de fichier ou une ligne de journal. Mieux encore, laissez le serveur générer le reçu et rapprochez les enregistrements par fenêtre temporelle pendant l’enquête.

Le contrôle doit échouer si le serveur autorise un shell interactif, transfère un port, alloue un TTY ou exécute une autre commande que la commande forcée. Ce sont des régressions de configuration. Elles méritent une gravité différente de celle d’un simple délai d’attente réseau, car elles modifient l’exposition de l’identifiant de test.

Ne réutilisez pas l’identité SSH servant aux déploiements. La réutiliser facilite la mise en place du contrôle, puis transforme une défaillance de supervision en problème d’accès étendu. Un identifiant de supervision doit avoir une seule fonction, un seul compte cible et aucune permission au-delà de la production du reçu.

Sallyport envoie les actions SSH par l’intermédiaire de son utilitaire sans état intégré sp-ssh. Votre test doit donc passer par le chemin d’action normal de la passerelle au lieu d’invoquer une clé privée locale avec OpenSSH. Sinon, vous n’aurez vérifié que l’hôte et le compte. Vous aurez ignoré la frontière des identifiants qui doit être prouvée.

La vérification de l’audit est une assertion distincte

Une action de test réussie et une piste d’audit valide sont deux affirmations différentes. Vérifiez-les toutes les deux.

L’enregistrement d’activité vous indique que la passerelle a enregistré une action donnée. L’enregistrement de session vous renseigne sur l’exécution de l’agent et permet de révoquer cette exécution. Aucun des deux ne doit remplacer la vérification de l’effet distant, car une requête peut être journalisée avant un échec en amont. À l’inverse, un système distant peut recevoir une requête alors que le chemin de journalisation local échoue au mauvais moment. Il faut de la corrélation, pas de l’optimisme.

Pour chaque action HTTP ou SSH réussie, recueillez trois éléments de preuve qui ne contiennent pas de secret :

• l’identifiant d’exécution de supervision généré par l’exécuteur ;
• le reçu opaque ou l’identifiant de requête généré par le service de test ;
• l’horodatage local de l’action, enregistré en UTC.

Examinez ensuite le journal d’activité pour vérifier les métadonnées de l’action qu’il est sûr de conserver, comme le canal, le résultat de l’action, l’alias de la cible et l’heure. N’attendez pas du journal qu’il contienne les identifiants en clair. Il ne le devrait pas. Ne lui demandez pas non plus de reproduire le corps de la réponse distante. Le reçu appartient au système de test distant, pas au coffre de secrets de la passerelle.

Sallyport projette ses journaux Sessions et Activity depuis un journal d’audit chiffré, enchaîné par hachage et aveugle en écriture. Exécutez sa vérification d’intégrité hors ligne comme une partie indépendante de la suite :

sp audit verify

Une commande réussie doit être enregistrée sous audit=verified. Un résultat différent de zéro constitue un incident d’intégrité jusqu’à preuve du contraire. Cette vérification n’a pas besoin de la clé du coffre, ce qui la rend adaptée à un contrôle local autonome, même lorsque le coffre est verrouillé.

Ne réduisez pas la vérification d’audit à « un fichier journal existe ». L’existence du fichier ne détecte presque rien. Un fichier tronqué, des enregistrements remplacés, une chaîne rompue ou un processus d’écriture arrêté après le démarrage peuvent tous coexister avec un chemin qui paraît normal dans Finder.

Une autre erreur facile consiste à vérifier seulement la validité de la chaîne d’audit. Une chaîne peut être valide tout en ne contenant pas l’événement attendu si la passerelle n’a jamais tenté l’action. Associez la vérification de la chaîne à une assertion de présence de l’événement après chaque action de test. Définissez une fenêtre raisonnable d’arrivée pour la projection locale et signalez séparément un retard et une absence d’événement. Une mise à jour tardive du journal peut nécessiter une enquête, mais elle n’est pas identique à une écriture échouée.

Gardez l’exécuteur en dehors de la frontière de confiance qu’il contrôle

L’exécuteur de supervision doit orchestrer les actions et évaluer les preuves. Il ne doit pas détenir d’identifiants, analyser les fichiers du coffre ou lire l’état applicatif contenant des secrets.

Une organisation pratique comporte quatre éléments :

1. Un ordonnanceur local lance un petit exécuteur sous un compte macOS dédié.
2. L’exécuteur vérifie la présence de l’application et appelle un adaptateur MCP local.
3. L’adaptateur demande des actions de test nommées par l’intermédiaire de la passerelle et renvoie des résultats structurés dont les secrets sont masqués.
4. L’exécuteur vérifie l’intégrité de l’audit et écrit un court rapport dans un répertoire local protégé.

Le compte dédié ne doit pas avoir accès aux fichiers de données du coffre. Apple place les données d’assistance des applications macOS non isolées dans le répertoire ~/Library/Application Support de l’utilisateur courant, mais un moniteur ne doit pas supposer qu’il peut ou doit inspecter ces fichiers. Le contrôle a besoin du comportement, pas d’une copie du contenu du coffre.

Gardez la configuration déclarative et exempte de secrets. Cet exemple donne à l’exécuteur suffisamment d’informations pour valider les résultats sans divulguer d’identifiants :

checks:
  http_canary:
    target_alias: canary-api
    expected_status: 200
    expected_check: agent-gateway-http
    timeout_seconds: 10
  ssh_canary:
    target_alias: canary-ssh
    expected_check: agent-gateway-ssh
    timeout_seconds: 10
  audit:
    command: sp audit verify
    timeout_seconds: 15

Les alias de cible sont importants. Un alias est moins sensible qu’une URL complète ou qu’un nom d’hôte, et il vous oblige à rendre explicite la sélection de la cible dans la configuration de la passerelle. Si un opérateur modifie un alias, le contrôle d’action doit montrer qu’une revue de configuration est nécessaire avant de commencer silencieusement à tester un autre endroit.

Ne donnez pas à l’exécuteur le droit d’approuver un nouveau processus d’agent. L’autorisation par session est activée par défaut pour une bonne raison. Le premier appel d’un nouveau processus d’agent indique son autorité de signature dans la carte d’approbation, et l’approbation ne vaut que pour cette exécution. Si vous avez besoin de contrôles planifiés après l’approbation d’une personne, mettez en place un processus client de supervision durable et examiné. Si le processus s’arrête, attendez-vous à ce que l’exécution suivante demande de nouveau une approbation.

Ce choix est un peu moins pratique qu’un compte d’automatisation caché toujours approuvé. Il empêche aussi un nouvel exécutable d’obtenir une autorisation simplement parce qu’il a copié la ligne de commande du contrôle de supervision.

Un contrôle en échec doit fournir un diagnostic utile

La plupart des échecs de supervision d’une passerelle viennent d’une dérive de configuration ordinaire. Le danger tient à la rapidité avec laquelle on réagit en affaiblissant les contrôles au lieu de localiser la frontière défaillante.

Considérons une séquence réaliste. L’application fonctionne. Le coffre est déverrouillé. Le test HTTP renvoie 401. Le premier réflexe consiste à coller le jeton de test dans un shell et à appeler directement le point d’accès. Ne faites pas cela. Vous prouveriez que le jeton fonctionne, mais vous contourneriez le coffre et créeriez un nouveau chemin de fuite du secret.

Examinez plutôt les preuves dans cet ordre :

1. Vérifiez que l’adaptateur MCP local a atteint la passerelle et reçu un résultat d’action, au lieu d’expirer avant l’envoi.
2. Vérifiez que l’alias de cible sélectionne toujours l’identifiant stocké et la configuration de point d’accès prévus.
3. Consultez les journaux du service de test pour l’identifiant de requête opaque, la méthode, la route et la raison du rejet. Ne journalisez pas la valeur d’autorisation reçue.
4. Inspectez le journal d’activité pour trouver la tentative d’action correspondante et vérifiez la chaîne d’audit avec sp audit verify.
5. Faites tourner l’identifiant de test si la revue de configuration montre que sa valeur attendue a changé ou qu’il a pu être exposé.

Cette séquence distingue quatre échecs qui paraissent autrement identiques : un mappage de cible incorrect, un secret révoqué ou renouvelé, un échec d’injection de la passerelle et une modification de configuration du service en amont. Elle évite aussi l’incident que l’on provoque soi-même lorsqu’un opérateur « teste » un secret dans un terminal, puis le retrouve dans l’historique shell, un tampon de défilement ou un paquet de support.

Classez la gravité selon le contrôle qui a échoué. Une application indisponible relève de la disponibilité. Un coffre verrouillé qui refuse une action est informatif, sauf si un contrôle approuvé était attendu à ce moment-là. Une action de test qui réussit alors que le coffre indique qu’il est verrouillé constitue un incident de sécurité. Une chaîne d’audit rompue est également un incident de sécurité, même si les deux cibles de test renvoient toujours un succès.

Ne masquez pas ces catégories derrière un seul badge rouge ou vert. L’opérateur qui voit vault=locked, audit=verified et http=skipped sait exactement quoi faire. Celui qui voit health=warning commence à deviner.

Le programme minimal utile comporte deux voies

Exécutez fréquemment les contrôles sans secret, puis lancez les actions de test avec identifiants de manière mesurée et délibérée. Ces deux voies produisent moins de bruit et fournissent de meilleures preuves.

La voie autonome peut s’exécuter chaque fois que le Mac est censé être éveillé. Elle vérifie que l’application est présente, qu’un coffre verrouillé refuse une action, que le chemin MCP peut renvoyer une réponse classifiée et que sp audit verify réussit. Aucun de ces contrôles ne doit nécessiter l’extraction d’un identifiant ou le déverrouillage du coffre.

La voie avec identifiants s’exécute après le déverrouillage du coffre par une personne et l’approbation de la session du client de supervision si nécessaire. Elle effectue une action HTTP de test, une action SSH de test, confirme les reçus distants, vérifie les enregistrements d’activité locaux correspondants et vérifie de nouveau la chaîne d’audit. Utilisez une cadence modérée. Chaque action avec identifiants devient un événement d’audit et un événement de service distant. Un contrôle chaque minute crée donc du bruit sans apporter beaucoup plus de confiance.

Exécutez cette voie après les changements de configuration des identifiants, des alias de cible, des outils d’agent, des permissions macOS, des contrôles réseau ou de l’application de passerelle. Ce moment permet de détecter les changements les plus susceptibles de perturber l’exécution des actions. Il fournit aussi à la personne chargée de la revue un relevé clair avant et après.

La règle est simple : une suite de contrôles doit prouver les contrôles sur lesquels vous comptez. Si elle peut seulement prouver qu’une icône d’application se trouve toujours dans la barre des menus, appelez-la sonde de disponibilité et arrêtez-vous là. Ne prétendez pas qu’elle prouve que des agents autonomes peuvent agir en toute sécurité.