Oui, exécuter en production du PowerShell généré par l'IA est sûr, mais uniquement avec une étape d'approbation devant. Un script écrit par un assistant n'est pas plus dangereux qu'un script écrit par un ingénieur à seize heures un vendredi. Ce qui le rend risqué, c'est que la plupart des organisations n'ont aucune règle qui le couvre. Il existe un processus de changement pour une règle de pare-feu et un processus de livraison pour une application, puis il y a un script arrivé dans une fenêtre de conversation et exécuté avec un jeton Global Administrator. Le contrôle manquant n'est pas un réglage de modèle. C'est un approbateur nommé, une liste définie de ce que cette personne vérifie, et une trace de ce qui a été exécuté et pourquoi.
Nous détenons ISO 27001, ISO 9001, ISO/IEC 42001 et Cyber Essentials, ce texte vient donc des questions qui nous ont été posées en audit.
La défaillance, c'est le point de validation manquant, pas le modèle
L'essentiel du débat sur l'IA en exploitation porte en réalité sur la qualité du modèle, et c'est le mauvais débat. La même organisation exécute déjà des scripts venus de prestataires, de forums, et de collaborateurs partis en 2019. La provenance n'a jamais été le contrôle. La revue, si.
Ce qui change vraiment, c'est le débit. Un ingénieur peut désormais produire vingt plans de remédiation plausibles en un après-midi, la contrainte se déplace donc de la production vers la revue, et la revue est précisément la partie que personne n'a dotée en effectifs. Un plan qui se lit avec assurance et cite les bonnes cmdlets passe sous le nez d'un relecteur fatigué, parce que rien n'y est manifestement faux. Ce qui manque, c'est un périmètre borné, et une absence se repère plus difficilement qu'une erreur.
La première question n'est donc pas « peut-on faire confiance à l'IA » mais « que vérifie réellement la personne qui clique sur approuver ».
Le point de validation est le produit : tout ce qui précède est un brouillon, et tout ce qui suit est une preuve.
Trois voies d'autonomie
Savoir si l'IA « a le droit d'agir » est la mauvaise question, car la réponse diffère selon la tâche. Répartissez le travail en trois voies, en accordant la voie au flux de travail plutôt qu'à l'outil.
Lecture seule. Analyse de journaux, rédaction de documentation, explication de ce que fait une politique. Rien ne change d'état, le mode de défaillance est donc une mauvaise réponse plutôt qu'une mauvaise action. Tout commence ici.
Proposer et approuver. L'assistant produit le plan et le script ; un humain le lit et l'exécute. L'essentiel du travail d'exploitation utile appartient ici, et c'est là que vit le point de validation. L'approbation doit être un acte laissant une trace. Si le processus se résume à « l'ingénieur y jette un œil et l'exécute », c'est la troisième voie avec des étapes en plus.
Exécuter dans le cadre d'une politique. L'assistant applique le changement à l'intérieur d'une frontière préautorisée : un ensemble défini d'opérations, un périmètre cible défini, un plafond de rayon d'impact et des conditions d'arrêt automatiques. Les bons candidats sont étroits, répétitifs, réversibles et surveillés, comme l'application d'une récupération de licences documentée sur des comptes déjà confirmés comme sortants.
Un flux de travail mérite la troisième voie une fois qu'il a tourné dans la deuxième assez souvent pour devenir ennuyeux : approuvé de façon répétée sans modification, déterministe, borné structurellement plutôt que par un filtre saisi à la main, et testé de façon réversible. Rétrogradez à la moindre surprise, et ne transférez jamais une voie à une tâche qui lui ressemble.
Ce que le relecteur vérifie réellement
C'est la liste qui manque à la plupart des politiques. Placez-la à côté du bouton d'approbation et faites consigner au relecteur les vérifications effectuées.
Périmètre et filtres. Qu'est-ce que cela touche, et qu'est-ce qui définit cet ensemble ? Un filtre saisi à la main est une promesse ; une appartenance de groupe revue est une frontière. L'incident classique, c'est un filtre qui correspond silencieusement à tout parce qu'une propriété était nulle sur plus d'objets que prévu.
Opérations destructrices. Cherchez remove, delete, disable, reset, et toute écriture dans une configuration de production. Se tromper sur une lecture coûte peu ; sur une écriture, non.
Prise en charge du mode simulation. Y a-t-il un aperçu, et cet aperçu a-t-il été exécuté et lu ? En PowerShell cela signifie une véritable gestion de ShouldProcess pour que -WhatIf fonctionne, pas un commentaire affirmant que le script est sûr.
# Unbounded: matches every disabled account in the tenant, no preview, no confirmation
Get-MgUser -Filter 'accountEnabled eq false' -All | Remove-MgUser
# Bounded: a reviewed membership defines the scope, and the preview runs first
$leavers = Get-MgGroupMember -GroupId $ConfirmedLeaversGroupId -All
$leavers | ForEach-Object { Remove-MgUser -UserId $_.Id -WhatIf }
Idempotence. Si cela s'exécute deux fois, la seconde exécution ne fait rien ou fait des dégâts ? Demandez ce que produit une reprise après un échec partiel, car c'est le cas courant.
Rayon d'impact. Non pas « est-ce correct » mais « si c'est faux, combien de personnes s'en aperçoivent et à quelle vitesse ». Une attribution de licence et une politique d'accès conditionnel donnent des réponses très différentes.
Sous quelle identité cela s'exécute. La vérification que les gens sautent. Si le travail s'exécute dans la session privilégiée d'un ingénieur, chaque entrée de journal dit qu'un humain l'a fait. Le travail sans surveillance appartient à une identité de charge de travail ne portant que les permissions nécessaires à la tâche, la même discipline que le questionnaire actuel impose aux comptes de service dans notre checklist des échecs automatiques Microsoft 365.
Chemin de retour arrière. Qu'est-ce qui annule cela, et quelqu'un l'a-t-il testé ? Restaurer depuis une sauvegarde n'est pas un chemin de retour arrière pour un objet d'annuaire, et ce qui est irréversible demande une approbation plus élevée, pas plus rapide.
Ce que disent les référentiels, et ce qu'ils vous laissent
Ni ISO 27001 ni Cyber Essentials ne contiennent une mesure disant « vous ne devez pas exécuter de scripts générés par l'IA ». En attendre une est une erreur, car les obligations s'appliquent déjà et n'emploient simplement pas le mot.
ISO 27001:2022 demande un changement maîtrisé, une journalisation permettant de reconstituer les événements, une séparation des accès privilégiés et une gestion de configuration définie. Une action provenant d'un assistant est un changement et exige la même autorisation et la même trace que n'importe quelle autre. ISO/IEC 42001 va plus loin et demande un système de management autour de l'usage de l'IA : finalité définie, rôles définis, appréciation des risques et surveillance du comportement en pratique.
Cyber Essentials se moque pour l'essentiel de la façon dont un script a été écrit. Ce qui l'intéresse, c'est que l'accès administratif soit séparé et que les comptes capables d'appliquer le changement soient maîtrisés. Le lien est indirect mais réel : dès qu'un assistant a besoin d'un privilège permanent pour être utile, vous avez créé exactement l'identité durablement élevée que le référentiel n'apprécie pas.
Ce qu'ils vous laissent, c'est le jugement : aucun d'eux ne vous dira quelles opérations relèvent de la troisième voie, et ce qu'un évaluateur demande, c'est le raisonnement et la trace derrière cette décision. Notre correspondance entre les paramètres Microsoft 365, Cyber Essentials et ISO 27001 couvre le tableau des mesures sous-jacentes.
L'enregistrement de preuve qu'un évaluateur accepte
Une approbation qui ne laisse aucune trace n'a pas eu lieu. Un enregistrement exploitable par action exécutée contient le déclencheur, l'intention du demandeur dans ses propres mots, l'artefact approuvé en entier plutôt qu'un résumé, l'outil et la version qui l'ont produit, le relecteur nommé et les vérifications qu'il a consignées, la décision et son horodatage, l'identité exécutante, le périmètre cible résolu au moment de l'exécution, le résultat y compris les échecs partiels, et tout retour arrière effectué.
Deux propriétés comptent plus que l'exhaustivité. L'enregistrement doit être interrogeable, car un évaluateur pose une question sur une plage de dates plutôt que sur un dossier. Et il doit survivre aux journaux de la plateforme elle-même, qui expirent plus tôt que la plupart des gens ne le supposent.
Là où cela casse
Les comptes d'administration partagés. L'enregistrement d'approbation nomme une personne, l'enregistrement d'exécution nomme un compte, et rien ne les relie. Corrigez d'abord les comptes.
L'assistant agissant avec les identifiants d'un humain. Pratique, et cela détruit l'attribution. Chaque journal en aval montre alors une personne effectuant des actions qu'elle n'a peut-être pas lues attentivement.
La rétention des journaux. Votre enregistrement d'approbation peut vivre des années tandis que la trace plateforme de ce qui a changé expire en quelques semaines. Vous prouvez que quelqu'un a approuvé quelque chose et vous ne parvenez pas à prouver ce que cela a fait.
L'accès délégué chez les fournisseurs de services managés. Quand le travail atterrit dans un tenant client via un accès délégué, décidez quel côté détient l'enregistrement d'approbation et comment le client l'obtient, aux côtés de ce qu'il faut rapporter chaque mois.
L'approbation de façade. Si le relecteur approuve tout en quelques secondes, le point de validation est décoratif. Mesurez le taux de modification, pas le taux d'approbation.
Une séquence d'adoption avec des conditions d'arrêt
- Inventoriez ce qui se passe déjà. Des scripts générés par l'IA sont déjà exécutés. Il vous faut la situation de départ honnête.
- Rédigez la checklist du relecteur. Les sept vérifications ci-dessus. Arrêtez-vous si vous ne pouvez pas nommer qui relit.
- Faites tout passer par la voie proposer et approuver pendant un trimestre. Arrêtez-vous si le taux de modification est proche de zéro, car cela signifie que personne ne lit.
- Donnez au travail sans surveillance sa propre identité. Pas de Global Administrator permanent, pas de comptes partagés, des permissions cadrées par flux de travail. Rien de ce qui suit ne fonctionne sans cela.
- Promouvez deux ou trois flux de travail, avec des conditions d'arrêt fixées à l'avance : un plafond de nombre d'objets, un seuil d'erreurs, un blocage hors heures ouvrées.
- Revoyez chaque trimestre et rétrogradez sans hésiter.
Comptez deux trimestres. La partie lente n'est jamais la technologie ; c'est de s'accorder sur qui détient la décision.
La place d'EtherAssist
C'est autour de ce point de validation qu'EtherAssist est construit. Il produit le plan et le script avec le contexte d'exploitation d'un parc Microsoft derrière lui, retient le travail à une étape d'approbation humaine, et écrit l'enregistrement d'exécution de l'autre côté, de sorte qu'approbation et preuve forment un seul artefact plutôt que deux systèmes à rapprocher plus tard.
C'est ce que couvre notre parcours opérations agentiques : exécution cadrée avec approbation humaine et piste d'audit, distincte du travail plus large d'exploitation informatique et conformité. Si le moteur est un audit à venir, conformité ISO et préparation à l'audit correspond mieux, et ce que l'IA agentique signifie pour les équipes IT pose le vocabulaire. EtherAssist coûte GBP 16.00 par utilisateur et par mois avec un essai de 14 jours, un vrai flux de travail peut donc passer par le point de validation d'abord.
Découvrez les opérations agentiques pour voir comment exécution cadrée, approbation humaine et enregistrement de preuve s'articulent dans un seul flux de travail.