# Une piste d'audit des approbations peut-elle prouver qui a approuvé une action d'agent ? Un enregistrement d'approbation qui indique seulement « approuvé » ne répond pas à la question qui compte après qu'un agent a touché à la production : qui a autorisé quelle action, avec quelle autorité et que s'est-il passé ensuite ? Il consigne un moment rassurant dans une interface, puis laisse l'enquêteur déduire le reste. Une piste d'audit des approbations doit conserver la chaîne qui relie un processus d'agent à une décision humaine, cette décision à l'utilisation d'un identifiant, puis l'utilisation de cet identifiant à une requête HTTP ou une commande SSH exécutée. Si ces éléments figurent dans des enregistrements séparés sans liens durables, un responsable peut construire un récit plausible. Il ne peut pas le prouver. Cette distinction devient problématique lorsque l'action a réussi, mais que personne ne se souvient de l'avoir approuvée, lorsqu'un agent a redémarré au milieu d'une tâche ou lorsque quelqu'un demande si un clic et une confirmation Touch ID avaient la même signification. Ce n'est pas le cas. Les traiter comme interchangeables produit un journal qui semble complet jusqu'au premier véritable examen. ## Un événement d'approbation doit répondre à plus que « oui » Un événement d'approbation utile indique ce que la personne a approuvé, pourquoi le système l'a demandé, comment la décision a été prise et où l'autorisation s'arrête. Le clic visible sur le bouton n'est qu'un champ parmi d'autres. Enregistrez ces informations au moment de la décision : - Un identifiant d'approbation unique et un horodatage avec décalage. - La méthode d'approbation, par exemple `click` ou `touch_id`. - Le compte local ou une autre identité connue de l'approbateur, ainsi que les éléments utilisés pour cette attribution. - La portée de l'autorisation : une session ou une seule utilisation d'un identifiant pour un appel. - La demande à l'origine de l'invite, identifiée par un identifiant stable de requête ou d'appel. N'écrivez pas `user=alex` simplement parce qu'une machine possède un compte nommé Alex. C'est peut-être la meilleure attribution disponible et elle mérite d'être enregistrée, mais appelez-la par son nom : contexte du compte local. Si une invite biométrique a abouti, indiquez qu'une donnée biométrique enregistrée sur cet appareil a autorisé l'événement. Ces formulations sont plus solides que « quelqu'un nommé Alex l'a approuvé », car elles ne prétendent pas que le journal sait plus qu'il ne sait réellement. NIST SP 800-171 Rev. 3 fournit un bon point de départ pour le contenu d'un audit : horodatages, adresses source et destination, identifiants d'utilisateur ou de processus, descriptions des événements, contrôles d'accès applicables et résultats. Le document précise aussi que les enregistrements détaillés peuvent inclure les commandes privilégiées et les identités individuelles derrière les comptes partagés. C'est un socle pertinent pour les actions d'agents, pas une conception complète. Un flux d'approbation d'agent doit traiter les relations entre la décision, l'identifiant et l'appel comme des données de premier ordre. L'erreur la plus courante consiste à enregistrer l'approbation comme un attribut de l'action finale, par exemple `approved=true`. Cela réduit un événement à une étiquette. Vous perdez le délai entre la demande et la décision, l'origine de la décision, la portée du consentement et toute révocation ultérieure. Il devient aussi impossible de distinguer une approbation humaine d'une autorisation par défaut, d'une autorisation mise en cache ou d'une règle d'automatisation. Une décision doit avoir son propre enregistrement, même lorsque la réponse est négative. Une invite refusée peut expliquer pourquoi un agent n'a pas effectué un déploiement. Une invite expirée peut expliquer pourquoi l'agent a réessayé. Un coffre verrouillé peut expliquer pourquoi le système a refusé d'effectuer un appel réseau. Ces événements sont très différents et un responsable ne devrait pas avoir à en déduire la différence à partir de l'absence d'un enregistrement de réussite. ## Cinq identités pour garder une chronologie fiable Une chronologie complète nécessite cinq identités distinctes. Les combiner permet d'économiser des colonnes dans un tableau, mais détruit le sens de l'enquête. La première est le **processus de l'agent**. Enregistrez un identifiant de processus ou d'exécution, l'exécutable ou l'autorité de signature du code qui l'a lancé, ainsi que ses heures de début et de fin. Une personne doit pouvoir répondre à la question : « Quel programme en cours a demandé cela ? » Le nom d'un projet ou une transcription de discussion ne suffit pas. Deux copies du même agent de programmation peuvent fonctionner en même temps, l'une pouvant être anodine tandis que l'autre pointe vers un autre dépôt. La deuxième est la **session**. Une session est la relation limitée entre un processus d'agent et la passerelle. Elle doit avoir son propre identifiant, car un processus peut effectuer de nombreux appels et l'autorisation de session peut s'appliquer à plusieurs d'entre eux. Lorsque le processus se termine, la session doit prendre fin. Si un nouveau processus démarre plus tard, il doit créer une nouvelle session, même s'il possède le même exécutable, le même compte local et la même description de tâche. La troisième est le **contexte de l'approbateur**. Il comprend le compte de l'appareil, tout utilisateur authentifié de l'application et la méthode d'approbation. Ne faites pas porter au champ de l'approbateur des faits qu'il ne peut pas établir. `local_account=maya`, `method=touch_id` et `device_id=...` sont explicites. `human=maya` affirme davantage. Dans certains environnements cette affirmation est raisonnable, mais dans d'autres, un poste partagé ou un bureau déverrouillé la rend immédiatement fragile. La quatrième est la **référence de l'identifiant**. Elle désigne l'autorité utilisée par la passerelle, pas le secret lui-même. Un identifiant opaque stable, une étiquette lisible, le canal et le type d'identifiant suffisent généralement pour examiner l'activité. Un jeton bearer n'est pas un champ d'audit. L'empreinte d'une clé privée SSH peut elle-même devenir un contexte sensible. Déterminez donc si les enquêteurs en ont besoin avant de la diffuser dans les journaux ordinaires. La cinquième est **l'opération exécutée**. Pour HTTP, il s'agit de l'identité de destination résolue, de la méthode de requête, du chemin normalisé, de certains éléments non sensibles de la requête, du statut de réponse et des temps d'exécution. Pour SSH, il s'agit de l'identité de l'hôte, du compte distant, de la commande ou d'un condensat de la commande approuvée, du code de sortie et des temps d'exécution. L'événement doit indiquer ce qui a été exécuté, pas seulement ce qui était demandé. Ces identités forment un graphe, pas une ligne plate : ```text agent_process -> session -> approval_decision -> credential_use -> executed_call ``` Une interface d'activité peut présenter ce graphe sur une seule ligne lorsque l'utilisateur a besoin d'aller vite. Conservez tout de même les liens sous-jacents. L'affichage sert aux personnes qui parcourent une journée de travail. Les identifiants servent à celle qui devra expliquer un appel six semaines plus tard. ## Un clic et Touch ID ne sont pas les mêmes preuves Un clic enregistre une interaction avec un contrôle d'approbation dans l'interface actuelle. Touch ID enregistre une autorisation biométrique réussie par le système d'exploitation, en plus de l'interaction qui l'a déclenchée. Les deux peuvent autoriser une action. Ils ne devraient pas partager une valeur vague comme `approved_manually`. Utilisez un champ de méthode explicite avec un ensemble contrôlé de valeurs. Par exemple : ```json { "approval_id": "apr_01J8K4VY5Q", "occurred_at": "2026-07-22T14:18:06.184Z", "decision": "approved", "method": "touch_id", "approver": { "local_account": "maya", "identity_assurance": "device_account_and_biometric" }, "scope": "credential_use", "session_id": "ses_01J8K4TE0M", "requested_call_id": "call_01J8K4VPM2" } ``` Les noms exacts des champs ne sont pas sacrés. La séparation l'est. `method` indique comment l'approbation a abouti. `identity_assurance` indique ce que le système peut raisonnablement affirmer au sujet de la personne. `scope` indique ce que la décision autorisait. `requested_call_id` relie l'approbation à une demande qui existait avant que la personne ne voie une invite. Un clic peut être le bon choix pour une confirmation simple, surtout lorsqu'une personne surveille déjà le travail d'un agent. Touch ID ajoute une étape locale de confirmation plus forte pour une opération sensible, mais ne fournit pas à lui seul une identité d'entreprise, la raison de la décision ni l'approbation de tous les appels ultérieurs. Si une équipe a besoin de l'approbation d'un salarié identifié par un fournisseur d'identité externe, elle doit utiliser un flux qui enregistre l'assertion de ce fournisseur. N'empruntez pas silencieusement ce niveau de confiance à un événement biométrique local. L'erreur inverse est tout aussi grave : traiter Touch ID comme un élément décoratif. Si une action exigeait une approbation biométrique et que le journal réduit l'événement à `approved=true`, l'enregistrement ne peut pas montrer que le contrôle le plus strict a réellement été exécuté. L'examen perd une preuve qui permettrait de distinguer une confirmation délibérée d'un clic accidentel sur une invite de session trop large. Enregistrez soigneusement les tentatives biométriques infructueuses. Une piste d'audit doit généralement indiquer que l'action demandée n'a pas été approuvée, mais elle n'a que rarement besoin de chaque échec d'authentification au niveau du système d'exploitation. Un événement utile est `decision=denied_or_cancelled`, `method=touch_id`, accompagné d'une raison comme `user_cancelled` lorsque la plateforme fournit cette distinction. Ne transformez pas une passerelle d'actions en collecteur de télémétrie biométrique. ## Le consentement de session et celui par appel n'ont pas la même portée L'autorisation de session permet à un processus d'agent défini de fonctionner après qu'une personne a examiné son identité. L'approbation par appel donne son accord pour une seule utilisation d'un identifiant et une seule opération. Appeler les deux « approbation » sans enregistrer leur portée rend la chronologie trompeuse. Imaginez un processus d'agent qui démarre à 09:00. La passerelle affiche une carte d'autorisation présentant l'autorité de signature du code du processus. Un développeur clique sur « approuver ». À 09:20, l'agent effectue une requête HTTP avec un identifiant dont la configuration n'exige pas de confirmation par appel. Cet appel peut être autorisé parce que la session reste autorisée. La bonne chronologie présente deux faits distincts : 1. À 09:00, le développeur a approuvé la session `ses_...` pour la durée de vie de ce processus. 2. À 09:20, cette session a utilisé l'identifiant `cred_...` pour effectuer l'appel `call_...`. Elle ne doit pas inventer une approbation humaine à 09:20. Le développeur n'a pas vu ni approuvé cet appel précis. L'autorisation précédente le couvrait. Modifiez maintenant un seul réglage : l'identifiant exige une approbation à chaque utilisation. À 09:20, la passerelle demande une nouvelle confirmation et le développeur l'approuve avec Touch ID. Le nouvel événement doit pointer vers `call_...`, indiquer `scope=credential_use` et inclure `method=touch_id`. L'approbation de session reste pertinente, car elle explique pourquoi l'agent pouvait accéder à la demande d'identifiant. Elle ne remplace pas la seconde décision. Cette distinction compte surtout lorsqu'un agent effectue un appel surprenant en fin de session. Si le journal indique « approuvé » à côté de cet appel, le responsable doit savoir si cela signifie qu'une personne a approuvé l'exécutable trente minutes plus tôt ou cette utilisation précise de l'identifiant trois secondes plus tôt. Ces deux faits ont des conséquences très différentes pour la conception des invites, les réglages des identifiants et la réponse aux incidents. Ne résolvez pas l'ambiguïté en exigeant une approbation pour chaque appel. Cette recommandation est populaire parce qu'elle semble sûre et produit un nombre de lignes rassurant. Elle habitue aussi les personnes à approuver des invites répétitives sans les lire, puis les empêche de distinguer l'appel exceptionnel des appels habituels. Activez l'approbation par appel pour les identifiants dont l'utilisation exige une confirmation humaine récente. Gardez l'autorisation de session activée par défaut afin de rattacher le processus de l'agent à une limite d'approbation identifiable. Une révocation doit elle aussi avoir une portée. Si un opérateur révoque une session, écrivez l'événement de révocation contre cette session et enregistrez l'heure d'effet. Ne remplacez pas l'ancienne approbation. Si un utilisateur désactive ou supprime un identifiant, enregistrez ce changement séparément. Une chronologie d'audit doit montrer pourquoi un appel ultérieur a été refusé sans réécrire l'historique pour faire disparaître l'autorisation passée. ## Les enregistrements d'identifiants doivent désigner l'autorité sans l'exposer L'enregistrement d'utilisation d'un identifiant est l'endroit où de nombreuses équipes font un compromis dangereux : elles ajoutent des éléments secrets pour faciliter une enquête. C'est un mauvais choix. Les journaux sont copiés, indexés, exportés et conservés plus longtemps que le processus qui les a générés. Un secret dans un journal d'activité transforme chaque lecteur du journal en détenteur d'identifiant. Attribuez à chaque identifiant stocké un identifiant opaque et immuable, comme `cred_01J8K...`. Associez-lui une étiquette qui aide une personne à reconnaître son usage, comme `payments-readonly` ou `staging-deploy`. Enregistrez le canal et le mode d'injection, par exemple `http_bearer`, `http_custom_header` ou `ssh_key`. Cela donne à l'enquêteur assez de contexte pour poser la bonne question sans copier la clé dans l'enregistrement. Un événement pratique d'utilisation d'un identifiant peut ressembler à ceci : ```json { "credential_use_id": "use_01J8K4WHD7", "occurred_at": "2026-07-22T14:18:06.221Z", "credential": { "id": "cred_01J7ZB7F8P", "label": "inventory-production", "channel": "http", "injection": "bearer" }, "session_id": "ses_01J8K4TE0M", "approval_id": "apr_01J8K4VY5Q", "call_id": "call_01J8K4VPM2", "secret_exposed_to_agent": false } ``` Le champ `secret_exposed_to_agent` peut sembler redondant lorsque la conception de la passerelle le garantit. Conservez-le si la chronologie peut inclure plusieurs chemins d'exécution ou des migrations. Il rend cette propriété de sécurité vérifiable dans le même enregistrement que l'action. Si tous les chemins pris en charge offrent la même garantie, le champ peut être implicite dans la conception du système et documenté une seule fois. Séparez la sélection de l'identifiant de son utilisation. Un agent peut demander un identifiant par son étiquette, mais aucun identifiant n'a été utilisé tant que la passerelle n'a pas commencé l'opération sortante. Cela compte pour les refus. Si Touch ID est annulé avant que la requête ne quitte la machine, écrivez un appel tenté et un événement d'approbation refusée. N'écrivez pas d'utilisation réussie de l'identifiant. Sinon, votre décompte d'audit indiquera qu'un identifiant de production a été utilisé alors qu'il ne l'a pas été. Pour SSH, évitez de traiter un alias d'hôte comme l'identité complète de la destination. `prod-db` est lisible, mais les alias peuvent changer. Enregistrez la cible configurée et les éléments d'identité de l'hôte que votre flux de connexion vérifie. Si l'agent a demandé `prod-db` mais que la cible résolue était différente, cette différence appartient à l'enregistrement d'exécution. C'est exactement le genre de détail qui compte après un mauvais déploiement. ## L'appel exécuté prouve que l'action a eu lieu L'approbation prouve le consentement. La sélection de l'identifiant prouve l'autorité visée. Seul un enregistrement d'exécution indique si la passerelle a tenté l'opération vers l'extérieur et quel résultat elle a reçu. Pour les appels HTTP, enregistrez l'opération sous une forme normalisée. Conservez la méthode de requête, l'origine de destination ou l'identité du service, le chemin canonique, les noms de certains champs de requête lorsque cela est utile, le statut de réponse, les horodatages de début et de fin ainsi qu'une référence vers le résultat. Décidez précisément quels champs de requête et de réponse peuvent être conservés. Les en-têtes d'autorisation, les cookies, les valeurs qui ressemblent à des jetons, les corps complets de requête et les corps bruts de réponse ne doivent pas apparaître dans une chronologie d'activité générale. Un condensat de requête peut aider à prouver que la charge utile approuvée et celle exécutée correspondaient, mais seulement si vous définissez exactement ses entrées. Hacher un corps JSON sans normaliser l'ordre des champs crée de fausses différences. Hacher un corps contenant une petite valeur prévisible peut malgré tout aider un attaquant à confirmer ses suppositions. Utilisez un condensat pour corréler l'intégrité lorsque la charge utile est déjà protégée ailleurs, pas comme solution universelle de gestion du contenu. Pour SSH, journalisez le compte distant, l'identité de la destination, la représentation de la commande, le code de sortie ainsi que les heures de début et de fin. Une ligne de commande complète peut contenir des secrets dans des affectations d'environnement, des URL temporaires ou des arguments. Un compromis raisonnable consiste à stocker une commande rendue sûre pour l'examen courant et une représentation complète protégée ou un condensat pour l'enquête. N'affirmez pas qu'un condensat constitue une preuve lisible. Il indique que deux valeurs correspondent, mais ne dit pas à l'enquêteur ce que la commande a fait. RFC 5424 sépare l'horodatage et l'identité du message des données structurées, car les analyseurs ont besoin de champs fiables plutôt que de prose à interpréter. Son format d'horodatage contient également un décalage et autorise les fractions de seconde. Vous n'avez pas besoin d'émettre du syslog, mais la leçon de conception reste valable : gardez les types d'événements et les champs de corrélation structurés, puis réservez le texte humain aux explications. Utilisez des types d'événements distincts. `call.requested`, `call.dispatched`, `call.completed` et `call.failed_before_dispatch` en disent plus qu'un événement `call` surchargé dont le champ d'état change de signification. Ces enregistrements supplémentaires permettent de répondre à des questions comme : un délai d'attente réseau est-il survenu après l'injection de l'identifiant ? Une validation locale a-t-elle bloqué la demande auparavant ? Le service distant a-t-il renvoyé une réponse ? Le temps seul ne suffit pas à établir l'ordre entre plusieurs machines. Utilisez des horodatages UTC avec décalage et conservez un numéro de séquence monotone dans chaque journal d'audit local. Si l'API distante renvoie son propre identifiant de requête, enregistrez-le comme valeur de corrélation distante. L'enquêteur pourra ainsi comparer la chronologie locale aux enregistrements du fournisseur sans prétendre que les horloges sont parfaitement synchronisées. ## Une chronologie défaillante se cache dans les journaux de réussite ordinaires Imaginez un agent de déploiement qui reçoit l'autorisation de session à 10:02. Il lit un dépôt, prépare une version, puis appelle un endpoint de déploiement en production à 10:17. L'endpoint accepte la demande. À 10:18, le développeur remarque que le mauvais environnement a été sélectionné. Un journal faible contient ceci : ```text 10:02 approved agent 10:17 deployment API call succeeded ``` Ce journal ne répond presque à rien. L'appel de 10:17 était-il couvert par l'approbation de 10:02 ? L'identifiant exigeait-il une seconde invite ? Quel processus a effectué l'appel ? L'agent a-t-il utilisé l'identifiant de déploiement prévu ou un jeton plus large ? Le système a-t-il envoyé la requête en production, ou une redirection ou une erreur de configuration l'y a-t-elle menée ? La personne a-t-elle cliqué sur « approuver », utilisé Touch ID ou n'a-t-elle jamais vu d'invite liée à l'action ? Une chronologie utile se présente plutôt ainsi : ```text 10:02:11 session.opened ses_71 process=proc_44 signer=known_authority 10:02:14 approval.approved apr_02 method=click scope=session session=ses_71 account=maya 10:17:03 call.requested call_88 POST deploy.example/release target=production session=ses_71 10:17:04 credential.selected use_53 credential=cred_prod_deploy call=call_88 10:17:04 call.dispatched call_88 destination=deploy.example 10:17:06 call.completed call_88 status=202 remote_request=req_914 ``` Cet enregistrement peut établir que l'agent disposait d'une autorisation de session valide, mais qu'il n'avait pas reçu d'approbation spécifique pour l'appel. Ce n'est pas la preuve que le déploiement était souhaité. C'est une preuve du fonctionnement du contrôle. L'équipe peut alors décider si l'identifiant de production doit exiger une approbation par appel, si l'invite doit afficher plus clairement l'environnement cible ou si l'agent ne devrait tout simplement pas avoir accès à cet identifiant. Ajoutez maintenant une confirmation par appel. La bonne entrée supplémentaire n'est pas une nouvelle ligne générique `approved`. Elle doit indiquer l'appel approuvé et sa portée : ```text 10:17:04 approval.approved apr_03 method=touch_id scope=credential_use session=ses_71 call=call_88 credential=cred_prod_deploy account=maya ``` Si l'agent réessaie après un délai d'attente, attribuez au nouvel essai un nouvel identifiant d'appel. Il peut réutiliser une autorisation de session existante, mais une règle d'identifiant par appel doit créer une nouvelle exigence d'approbation pour cet essai. Enregistrer la nouvelle tentative comme s'il s'agissait de l'appel initial donne à tort l'impression qu'une seule confirmation couvrait deux actions externes. ## L'intégrité de l'audit constitue une affirmation distincte Un journal d'audit peut être assez complet pour expliquer une séquence tout en restant facile à modifier. Il peut être conçu comme inscriptible uniquement à la suite et permettre malgré tout à un administrateur ou à un logiciel malveillant disposant d'un accès local de supprimer les lignes gênantes. Traitez le contenu et l'intégrité comme deux propriétés distinctes. Un journal chaîné par hachage relie chaque enregistrement au précédent par un condensat cryptographique. Si vous modifiez un ancien enregistrement, la chaîne ultérieure n'est plus vérifiable. C'est utile, car une vue d'activité exportée peut être comparée au journal sous-jacent au lieu d'être acceptée sur confiance. Cela ne prouve pas que le système d'origine a enregistré chaque événement, qu'un rédacteur compromis n'a pas créé de faux enregistrements ni qu'une approbation valide était une bonne décision. Ce sont des affirmations différentes qui exigent des contrôles différents. Vérifiez l'intégrité à la frontière où les preuves quittent le système. Un enquêteur doit pouvoir prendre le flux d'enregistrements chiffré, effectuer une vérification hors ligne et savoir si la séquence est intacte sans exposer les identifiants simplement pour valider une chaîne. Le résultat de la vérification doit indiquer la plage contrôlée, l'état de la chaîne et la première séquence en échec si la vérification échoue. Sallyport produit ses journaux Sessions et Activity à partir d'un seul journal d'audit chiffré, chaîné par hachage et inscriptible à l'aveugle, et `sp audit verify` peut vérifier la chaîne hors ligne sur le texte chiffré sans clé de coffre. Cette organisation compte, car la décision de session et l'opération individuelle restent des vues d'une même preuve, et non des récits modifiables séparément. N'utilisez pas la vérification d'intégrité comme raison de conserver indéfiniment des données excessives. La durée de conservation, le contrôle d'accès et la rédaction restent importants. Un journal parfaitement préservé et rempli de secrets n'attend qu'une requête pratique pour devenir un incident. Définissez qui peut consulter les enregistrements bruts, qui peut les exporter, combien de temps ils restent disponibles et quels champs peuvent apparaître dans les vues courantes. ## Construire la chronologie autour des jointures, puis tester les cas difficiles Une revue de schéma doit commencer par une question directe : un enquêteur peut-il partir d'une action exécutée et remonter jusqu'à l'approbation sans deviner ? Si ce n'est pas le cas, ajoutez l'identifiant manquant avant de perfectionner l'interface d'activité. Exécutez une petite matrice de tests sur l'implémentation. Une grande simulation n'est pas nécessaire. Il faut des cas qui exposent les erreurs de portée et d'ordre : - Démarrer un nouveau processus d'agent, approuver sa session par un clic et effectuer un appel sans risque. - Utiliser un identifiant qui exige une approbation par appel, l'autoriser avec Touch ID et vérifier que l'appel pointe vers cette approbation. - Annuler l'invite biométrique et vérifier qu'aucun enregistrement d'utilisation réussie de l'identifiant n'apparaît. - Terminer le processus d'agent, le redémarrer et vérifier que le nouveau processus ne peut pas hériter de l'ancienne autorisation de session. - Provoquer une erreur distante après l'envoi et vérifier que la chronologie distingue l'envoi de l'achèvement. Examinez le résultat dans les deux sens. Commencez par l'approbation et listez chaque action qui en dépend. Puis commencez par l'appel exécuté et remontez jusqu'au processus, à la session, à la décision et à l'identifiant. La première vue révèle les autorisations plus larges ou plus longues que prévu. La seconde révèle les appels dont les preuves sont absentes ou ambiguës. Le vocabulaire de l'interface doit être aussi précis que le modèle de données. « Session approuvée par clic » est clair. « Identifiant de déploiement en production approuvé avec Touch ID pour cet appel » est clair. « Approuvé » est un mot d'état décoratif qui demande au lecteur d'inventer les détails les plus importants. La première fois que quelqu'un demande qui a approuvé une action d'agent, ne lui donnez pas une capture d'écran avec un badge vert. Donnez-lui une chronologie qui montre le processus, la méthode de décision, la portée, l'autorité de l'identifiant, l'appel exact et le résultat. Tout ce qui est en dessous peut être pratique lors d'une démonstration. Cela ne résistera pas lorsque l'action aura de l'importance.