Les agents d’IA autonomes ont besoin d’un nouveau modèle de gouvernance

Google News a mis en avant un titre de SiliconANGLE porteur d’un avertissement clair : les acteurs autonomes de l’IA ont besoin d’une gouvernance conçue pour des logiciels capables d’entreprendre des actions aux conséquences importantes.

Cette distinction est essentielle, car un agent d’IA fait bien plus que générer une réponse. Il peut récupérer des fichiers, appeler des outils, exécuter du code, mettre à jour des enregistrements et communiquer avec d’autres systèmes. Ces capacités transforment une sortie peu fiable en une action potentiellement non autorisée.

Ce titre met en lumière un conflit auquel sont désormais confrontés les responsables technologiques en entreprise. Les entreprises veulent des agents qui fonctionnent avec moins de supervision, alors que de nombreux contrôles de sécurité supposent encore qu’un humain initie chaque action importante.

Les régulateurs, organismes de normalisation et fournisseurs de sécurité ont commencé à combler cette lacune. Leur réponse émergente associe des identités d’agent uniques, des autorisations restreintes, une surveillance continue, des points d’approbation humaine et des mécanismes de récupération.

La question centrale n’est plus de savoir si un modèle produit une phrase inexacte. Elle consiste à déterminer si une organisation peut identifier, contenir, expliquer et annuler les actions d’un agent avant qu’une erreur ne se propage.

Le titre de Google News annonce une évolution plus large de la gouvernance

La gouvernance de l’IA évolue : elle ne se limite plus à superviser les sorties des modèles, mais vise à contrôler des acteurs logiciels dotés d’identités, d’autorisations, d’outils et de responsabilités opérationnelles.

La gouvernance traditionnelle de l’IA générative s’est largement concentrée sur les données d’entraînement, les contenus nocifs, l’évaluation des modèles et l’exactitude des réponses générées. Ces préoccupations restent importantes, mais les agents autonomes introduisent un problème opérationnel différent.

Un agent d’IA peut poursuivre un objectif à travers une séquence de décisions. Il peut choisir des outils, consulter des informations évolutives, réviser un plan et lancer des actions sans demander d’approbation à chaque étape.

Ce comportement crée une chaîne plus longue entre l’instruction initiale de l’utilisateur et le résultat final. Chaque étape supplémentaire introduit un nouveau point où l’intention, le contexte ou l’autorité peuvent dériver.

Imaginons qu’un employé demande à un agent de préparer des documents de renouvellement pour des clients. Un chatbot pourrait rédiger le texte puis attendre. Un agent autonome pourrait récupérer des dossiers de compte, sélectionner des modèles, modifier un contrat et envoyer le dossier.

Ces actions impliquent plusieurs systèmes et de nombreuses limites d’autorisation. Une instruction vague ou un document empoisonné peut affecter l’ensemble de la séquence.

L’élément de Google News est donc bien plus qu’un nouvel avertissement sur les inexactitudes de l’IA. Il reflète un changement structurel dans la manière dont les logiciels fonctionnent au sein des organisations.

Les services logiciels utilisent depuis longtemps des identités machine. Toutefois, ces services exécutent généralement des fonctions prévisibles dans des limites techniques étroites.

Un agent d’IA peut interpréter des objectifs ambigus et choisir parmi plusieurs actions possibles. Son comportement dépend des prompts, des données récupérées, de la mémoire, des sorties du modèle, des outils disponibles et de conditions environnementales changeantes.

L’agent n’est donc ni un employé ordinaire ni un service logiciel conventionnel. Les entreprises doivent néanmoins lui attribuer un propriétaire, définir son autorité et conserver des preuves de son activité.

Cette responsabilité ne peut pas rester implicite. Si plusieurs équipes déploient des agents via différentes plateformes, les responsables de la sécurité ont besoin d’un inventaire complet indiquant où ces agents s’exécutent et à quoi ils peuvent accéder.

AppViewX a illustré cette catégorie de produits émergente en lançant une plateforme d’identité des agents. L’entreprise affirme que son système découvre les agents, cartographie leurs autorisations et surveille leur comportement.

Le produit a été lancé en aperçu privé pour des entreprises qualifiées. Ses affirmations doivent encore être validées dans des déploiements réels, mais sa conception reflète l’orientation du marché.

Le changement important est conceptuel. Les entreprises commencent à considérer chaque agent comme un acteur gouverné plutôt que comme une fonctionnalité invisible au sein d’une application.

Cette évolution crée la tension centrale de l’article. Plus un agent devient utile, plus il nécessite généralement d’accès. Chaque autorisation supplémentaire élargit aussi les dommages possibles après une manipulation, une erreur ou une compromission d’identifiants.

La capacité autonome n’est pas synonyme de pouvoir autorisé

La capacité technique d’un agent ne devrait jamais déterminer ce que l’organisation lui permet de faire.

Les développeurs évaluent souvent les agents à travers leurs taux de réussite, des tests de raisonnement ou des benchmarks d’utilisation d’outils. Ces évaluations décrivent une capacité, mais ne répondent pas à la question de savoir si un agent devrait recevoir une autorité opérationnelle.

Un agent de programmation peut être capable de modifier l’intégralité d’un dépôt. Cela ne signifie pas qu’il devrait fusionner des changements en production sans revue.

Un agent financier peut générer une instruction de paiement valide. Cela ne signifie pas qu’il devrait transférer des fonds au-delà d’un seuil défini.

La gouvernance doit séparer ce qu’un agent peut accomplir de ce qu’il est autorisé à exécuter. Cette séparation devient essentielle lorsqu’un même modèle prend en charge de nombreux agents aux responsabilités différentes.

Le même modèle sous-jacent peut alimenter un assistant de recherche, un agent de support client et un opérateur d’infrastructure. Leurs autorisations devraient différer, car les conséquences de leurs actions diffèrent.

Les organisations appliquent déjà un raisonnement similaire aux employés et aux services logiciels. Un agent du support client ne reçoit pas un accès illimité à la base de données simplement parce qu’il comprend les requêtes de base de données.

Les agents ont besoin du même principe, mis en œuvre par des contrôles techniques. Les autorisations doivent refléter une tâche définie, un responsable métier, un environnement et un impact acceptable.

Le NIST a placé l’identité et l’autorisation au cœur de son initiative sur les normes applicables aux agents, annoncée le 17 février 2026. Cette initiative porte sur les normes, les protocoles ouverts, la recherche en sécurité et l’interopérabilité de confiance.

Le NIST a également décrit des agents capables d’écrire du code, de gérer des communications et d’acheter des biens. Ces exemples montrent pourquoi les politiques de sécurité au niveau du modèle ne peuvent pas gouverner chacune des actions qui en résultent.

Un agent opérant dans plusieurs applications a besoin d’une identité vérifiable. Chaque système destinataire doit savoir quel agent demande l’accès et au nom de qui il agit.

Cette identité doit être liée à une personne responsable ou à une unité organisationnelle. Dans le cas contraire, un journal d’audit peut montrer qu’une action a eu lieu sans établir qui a autorisé l’acteur.

L’autorisation doit également tenir compte de la délégation. Un agent peut créer un sous-agent spécialisé ou appeler un autre agent exploité par un fournisseur externe.

Un simple identifiant utilisateur ne rend pas compte de cette chaîne. L’organisation a besoin de preuves décrivant la demande initiale, l’autorité déléguée, les acteurs intermédiaires et l’action finale.

C’est là que les outils d’identité familiers restent utiles mais incomplets. L’authentification peut vérifier qui présente un identifiant. Elle n’établit pas automatiquement si une action dépendante du contexte correspond à la mission attribuée à l’agent.

Un agent d’approvisionnement authentifié pourrait toujours détourner un outil d’achat valide. Une instruction compromise pourrait l’orienter vers un fournisseur non autorisé alors que chaque identifiant reste techniquement valide.

La gouvernance des agents nécessite donc une autorisation tenant compte de la tâche. Le système doit évaluer l’action demandée par rapport au rôle de l’agent, à son objectif actuel, à la sensibilité des données et à son impact potentiel.

Des identifiants de courte durée peuvent réduire l’exposition. Des périmètres d’outils restreints peuvent empêcher un agent d’utiliser des fonctions sans lien avec sa mission.

Les organisations devraient également séparer l’accès en lecture de l’autorité d’action. Un agent qui a besoin des données de facture pour son analyse n’a pas nécessairement besoin de l’autorisation d’approuver ou de payer des factures.

Ces contrôles ajoutent de la friction, mais une autonomie sans discernement n’est pas l’alternative utile. Le meilleur objectif est une autonomie proportionnée, où la supervision ne diminue qu’après que les preuves justifient cette décision.

Les contrôles d’accès statiques ne peuvent pas gouverner une intention évolutive

Les agents d’IA ont besoin de contrôles d’exécution, car des identifiants valides ne garantissent pas un comportement valide.

Les systèmes d’accès traditionnels demandent généralement si un utilisateur ou un service peut atteindre une ressource. La gouvernance des agents doit également demander ce que l’acteur cherche à faire et si cette action reste dans le cadre de son objectif assigné.

Cette différence devient visible lorsqu’un agent traite du contenu non fiable. Un document, un e-mail, un site web ou une réponse d’outil peut contenir des instructions qui entrent en conflit avec la demande de l’utilisateur.

L’injection de prompt est une attaque qui place des instructions malveillantes dans le contenu traité par un système d’IA. L’agent peut confondre ces instructions avec des directives légitimes.

Un agent de recherche peut lire une page web lui demandant de divulguer des informations stockées. Un agent de support peut rencontrer un message lui ordonnant d’ignorer les règles de vérification des clients.

Le modèle peut rester techniquement fonctionnel tout en suivant la mauvaise instruction. L’authentification seule n’arrêtera pas ce comportement, car l’agent présente toujours une identité valide.

La liste des risques liés aux agents d’OWASP identifie notamment le détournement d’objectif, le mauvais usage des outils, l’abus de privilèges, l’empoisonnement de la mémoire et les faiblesses de la chaîne d’approvisionnement parmi les principales préoccupations.

La liste a recueilli les contributions de plus de 100 chercheurs en sécurité, praticiens, organisations utilisatrices et fournisseurs de technologies. Elle reflète une évolution importante de la réflexion sur la sécurité.

Les défenseurs ne peuvent pas évaluer uniquement le modèle. Ils doivent examiner l’ensemble du système d’agent, y compris les prompts, la mémoire, les outils, les connecteurs, les identifiants, la logique d’orchestration et les communications externes.

L’application de politiques à l’exécution apporte une réponse. Elle évalue une action pendant que l’agent fonctionne, plutôt que de s’appuyer entièrement sur des règles établies lors du déploiement.

Une couche de politique pourrait autoriser un agent d’approvisionnement à préparer une commande, mais exiger une approbation avant sa soumission. Elle pourrait empêcher ce même agent de modifier les coordonnées bancaires d’un fournisseur.

La décision peut également dépendre de la réversibilité. Rédiger une invitation de calendrier est facile à annuler. Supprimer des données de production représente une charge de récupération très différente.

Les actions à fort impact nécessitent des points de contrôle plus robustes. Ceux-ci peuvent inclure une confirmation humaine, un second vérificateur automatisé, des limites de transaction ou une exécution dans un environnement isolé.

Toutefois, l’approbation humaine n’est pas automatiquement significative. Un réviseur ne peut pas prendre une décision éclairée après avoir reçu une demande de confirmation inexpliquée ne contenant qu’un bouton d’approbation.

Le système devrait présenter l’action proposée, les ressources concernées, les éléments justificatifs et les conséquences attendues. Il devrait également révéler toute incertitude ou information contradictoire.

La mémoire ajoute une autre complication. La mémoire d’un agent stocke des faits ou des interactions passées pour une utilisation ultérieure, ce qui permet au comportement de persister entre les sessions.

Cette persistance peut améliorer la continuité, mais elle peut aussi conserver des informations fausses ou malveillantes. Une entrée mémoire empoisonnée pourrait influencer des décisions longtemps après la disparition de l’attaque initiale.

Les organisations ont besoin de contrôles sur les personnes autorisées à écrire dans la mémoire, sur la manière dont les entrées reçoivent une provenance et sur l’expiration des anciens contextes. Les magasins de mémoire sensibles exigent également la même discipline d’accès que les autres données métier.

Cela compte pour les systèmes de connaissances internes. Une base de connaissances consultable devient partie intégrante de l’environnement décisionnel de l’agent lorsqu’elle est connectée via des outils de récupération.

Les manchettes de Google News présentent ces systèmes comme des acteurs autonomes, mais l’autonomie doit rester conditionnelle. Chaque action significative doit suivre un chemin balisé entre l’autorité et l’exécution.

Le véritable enjeu : autonomie contre responsabilité

Les entreprises ne choisissent pas entre des agents utiles et des agents sûrs ; elles décident si l’autonomie peut rester responsable à la vitesse des opérations.

L’argument le plus convaincant en faveur des agents autonomes est l’efficacité. Ils peuvent coordonner des tâches répétitives, fonctionner en continu et réduire les délais entre l’analyse et l’exécution.

L’objection la plus forte concerne l’ampleur potentielle des dommages. Un agent rapide peut répéter une mauvaise action sur de nombreux enregistrements, systèmes ou clients avant qu’une personne ne s’en aperçoive.

Ce risque augmente lorsqu’un agent dispose d’identifiants étendus. Il augmente encore lorsque l’agent peut déléguer du travail ou modifier le contexte utilisé par des agents ultérieurs.

Les fournisseurs de solutions de sécurité réagissent selon des approches différentes. Les spécialistes de l’identité mettent l’accent sur les identités cryptographiques et les privilèges limités. Les entreprises de sécurité des données privilégient la surveillance, la restauration et la protection des informations sensibles.

Les fournisseurs de sécurité cloud se concentrent sur les connexions entre les agents, les applications et les données. Les fournisseurs de plateformes d’agents mettent souvent l’accent sur l’évaluation, la définition de politiques et les contrôles pour les développeurs.

Ces approches se recoupent, mais aucune ne résout seule le problème. Une identité vérifiée n’empêche pas la manipulation des objectifs, tandis que la surveillance comportementale n’établit pas qui a accordé l’autorité.

De même, une étape d’approbation humaine ne peut pas compenser l’absence de traces d’audit. Un outil de restauration ne peut pas annuler toutes les conséquences physiques, financières ou réputationnelles.

L’Infocomm Media Development Authority de Singapour a publié son cadre de gouvernance des agents le 22 janvier 2026. Il structure la gouvernance autour de quatre dimensions pratiques.

Les organisations devraient d’abord limiter les risques en restreignant l’autonomie et les accès. Elles devraient ensuite établir une responsabilité humaine réelle et des points d’approbation.

Le cadre appelle également à des contrôles tout au long du cycle de vie, à des tests de référence et à l’accès à des services inscrits sur liste blanche. Sa dernière dimension porte sur la transparence, la formation et la responsabilité des utilisateurs finaux.

Cette approche reconnaît que la gouvernance des agents ne peut pas relever entièrement du département de sécurité. Les responsables produit définissent le cas d’usage, les développeurs assemblent le système et les dirigeants autorisent le déploiement opérationnel.

Les équipes achats influencent également le risque lorsqu’elles sélectionnent des outils tiers. L’agent d’un fournisseur peut traiter des données d’entreprise par l’intermédiaire de modèles externes, de connecteurs ou de services de mémoire.

Les contrats doivent couvrir la journalisation, la notification des incidents, la conservation des données, les sous-traitants et les changements de système. Les acheteurs doivent comprendre si le fournisseur peut reconstituer le cheminement décisionnel d’un agent après un incident.

Le compromis central ne se résout pas en fixant pour toujours un niveau d’autonomie unique. Les autorisations d’un agent devraient évoluer avec la tâche, l’environnement et les éléments de preuve.

Un nouvel agent peut commencer avec un accès en lecture seule et une approbation obligatoire. Des tests contrôlés concluants peuvent justifier une exécution limitée dans un flux de travail restreint.

Des échecs répétés devraient réduire son autorité. Un comportement inattendu, une dérive de configuration ou une mise à jour du modèle devraient déclencher un nouvel examen.

Cela crée un modèle d’autonomie acquise. L’agent ne reçoit davantage de liberté opérationnelle qu’après que les tests ont démontré un comportement acceptable dans des conditions pertinentes.

Même dans ce cas, les organisations devraient préserver des limites strictes. Certaines actions restent inadaptées à une exécution non supervisée, car leurs conséquences sont difficiles à annuler.

Parmi elles figurent la modification des contrôles d’accès, la publication d’informations réglementées, la cessation d’emploi, le transfert de sommes importantes ou la suppression d’enregistrements primaires.

La frontière exacte différera selon les entreprises. Ce qui doit rester constant, c’est une décision explicite reliant l’autonomie au risque, à la réversibilité et à une responsabilité clairement attribuée.

Ce que les produits de gouvernance actuels ne peuvent toujours pas prouver

Le marché produit des outils de contrôle des agents plus vite que les acheteurs ne peuvent vérifier si ces contrôles fonctionnent entre les modèles, les plateformes et les flux de travail délégués.

Les annonces de produits promettent souvent la découverte, la surveillance, l’application de politiques et une remédiation rapide. Ces fonctions sont précieuses, mais les preuves qui les entourent restent inégales.

Un fournisseur peut démontrer que sa plateforme bloque un appel d’outil connu. Ce test ne prouve pas les performances face à de nouvelles attaques, à des objectifs ambigus ou à des chaînes de délégation complexes.

La découverte pose également un problème difficile. Les agents gérés de manière centralisée sont plus faciles à inventorier, mais les employés peuvent créer des automatisations informelles via des outils de navigateur, des scripts et des services externes.

Ces agents peuvent utiliser des identifiants personnels ou des clés API copiées. Ils peuvent fonctionner en dehors des systèmes surveillés par une console de gouvernance centralisée.

Les organisations font donc face à un équivalent agentique du shadow IT. La différence est que les agents fantômes peuvent initier des actions et créer des automatisations supplémentaires.

Les outils de surveillance doivent distinguer les comportements malveillants des variations légitimes. Les agents suivent souvent des séquences différentes pour accomplir une même tâche, ce qui rend les règles comportementales rigides sujettes aux fausses alertes.

Un trop grand nombre d’alertes peut affaiblir la supervision. Les équipes de sécurité peuvent ignorer des avertissements trop bruyants, tandis que les équipes métier cherchent des moyens de contourner des contrôles qui bloquent fréquemment un travail légitime.

Les explications constituent un autre point faible. Un agent peut produire un récit plausible de son raisonnement sans fournir d’éléments fiables sur le processus qui a généré une action.

Les systèmes d’audit devraient privilégier les événements observables. Les traces utiles comprennent la provenance des entrées, les appels d’outils, les décisions d’autorisation, les accès aux données, les versions de modèles, les résultats des politiques et les sorties finales.

Ces traces doivent rester protégées contre toute altération. Un agent ne devrait pas pouvoir effacer les éléments nécessaires à l’enquête sur son propre comportement.

Les promesses de restauration méritent également d’être examinées avec attention. Restaurer une branche de code supprimée est possible lorsqu’une copie indépendante existe. Rappeler un e-mail externe ou annuler la divulgation d’une information est bien plus difficile.

Certaines actions ne sont que partiellement réversibles. Un paiement peut être annulé, mais la tentative de transfert peut toujours susciter des préoccupations de conformité ou de fraude.

Une plateforme de gouvernance devrait préciser quelles ressources elle peut restaurer et quelles conséquences restent hors de son contrôle. Les acheteurs ont besoin de preuves fondées sur des scénarios, et non d’une promesse générale de restauration.

L’interopérabilité ajoute davantage d’incertitude. Les entreprises utilisent rarement un seul modèle, un seul cadre d’agents ou un seul fournisseur d’identité.

Une politique qui fonctionne sur la plateforme d’un fournisseur peut perdre son contexte lorsqu’un agent appelle un outil externe. Les agents délégués peuvent franchir des frontières organisationnelles et techniques.

Les normes peuvent réduire cette fragmentation, mais elles sont encore en cours de développement. Les travaux du NIST signalent une dynamique, tandis que les mises en œuvre concrètes devront être testées dans de véritables systèmes d’entreprise.

Le Forum économique mondial a indiqué que 82 % des dirigeants prévoyaient d’adopter des agents dans un délai d’un à trois ans. Ce chiffre décrit une intention, et non une adoption en production avérée.

Cette distinction est importante. L’enthousiasme exprimé dans les enquêtes ne démontre pas que les organisations disposent d’inventaires fiables, de contrôles matures ou de retours mesurables.

Les affirmations des fournisseurs doivent donc rester des affirmations jusqu’à ce que des évaluations indépendantes les confirment. Les acheteurs devraient demander des preuves issues de déploiements correspondant à leur propre profil de risque.

Le marché de la gouvernance fait également face à un problème d’incitations. Les plateformes qui vendent davantage d’autonomie vendent souvent les contrôles censés rendre cette autonomie acceptable.

Cette situation n’invalide pas leurs outils. Elle signifie toutefois que les clients ont besoin de tests de sécurité indépendants, d’une responsabilité contractuelle claire et d’une autorité interne leur permettant de restreindre les déploiements.

Trois signaux montreront si la gouvernance des agents gagne en maturité

La prochaine phase se mesurera à l’identité interopérable, à une autonomie fondée sur des preuves et à des déploiements en production récupérables, plutôt qu’à de nouvelles déclarations de politique.

Le premier signal sera la publication de directives de mise en œuvre concrètes dans le cadre de la NIST AI Agent Standards Initiative. Leur valeur dépendra de la capacité des organisations à traduire les normes en contrôles interopérables.

Un résultat utile permettrait à une application de vérifier, au-delà des frontières entre fournisseurs, l’identité d’un agent, l’autorité qui lui est déléguée, le périmètre autorisé et le responsable désigné.

Des champs d’identité communs amélioreraient également la réponse aux incidents. Les enquêteurs pourraient reconstituer quel agent a agi, qui l’a autorisé et si son autorité a changé pendant l’exécution.

Si les normes restent abstraites, les fournisseurs continueront à mettre en œuvre des modèles d’identité incompatibles. Cette fragmentation affaiblirait l’argument en faveur d’une gouvernance centralisée dans des environnements hétérogènes.

Le deuxième signal sera l’adoption de politiques d’autonomie dynamiques. Les entreprises devraient commencer à indiquer comment les autorisations des agents évoluent selon les tests, le risque et les performances observées.

Cela exige des critères mesurables. Les taux d’exécution à eux seuls ne suffisent pas, car un agent peut accomplir une tâche tout en enfreignant une politique ou en exposant des informations protégées.

Les évaluations devraient couvrir l’utilisation non autorisée d’outils, l’injection de prompts, l’empoisonnement de la mémoire, l’utilisation abusive d’identifiants, la délégation et la restauration. Les tests devraient également refléter l’environnement de production réel de l’agent.

Un déploiement mature reliera les résultats d’évaluation aux autorisations. Les tests échoués devraient automatiquement empêcher l’extension de l’autorité tant que la faiblesse n’est pas corrigée et examinée.

Les preuves de cette pratique renforceraient l’argument selon lequel les entreprises peuvent étendre l’autonomie de manière responsable. Des modèles d’autorisation statiques suggéreraient que la gouvernance reste en retard sur le déploiement.

Le troisième signal sera l’existence de preuves publiques sur le confinement et la restauration après incident. Les organisations doivent démontrer qu’elles peuvent détecter une activité nuisible d’un agent et en limiter les conséquences.

Cela ne nécessite pas d’exposer des détails sensibles sur les incidents. Les entreprises peuvent publier des scénarios anonymisés, des évaluations indépendantes et des mesures de performance de restauration.

Des divulgations utiles expliqueraient ce qui s’est passé, quel contrôle l’a détecté, jusqu’où l’action s’est propagée et ce qui a pu être annulé.

Les échecs fourniront également des informations. Un incident impliquant un agent correctement authentifié montrerait pourquoi l’identité seule ne peut pas établir une intention digne de confiance.

Un échec traversant plusieurs agents mettrait à l’épreuve la capacité de la journalisation actuelle à préserver une chaîne complète de délégation. Un résultat irréversible révélerait les limites du marketing autour de la restauration.

Ces signaux comptent davantage qu’un tableau de bord de gouvernance supplémentaire. La technologie doit prouver que les contrôles restent efficaces lorsque les agents opèrent à la vitesse des machines dans des systèmes réels.

Pour les développeurs, l’implication immédiate est claire. L’architecture des agents devrait dès le départ exposer des points de contrôle des politiques, des appels d’outils traçables et des identifiants restreints.

Pour les acheteurs en entreprise, les exigences de gouvernance doivent figurer dans les achats avant le déploiement. Ajouter après coup la responsabilité, l’auditabilité et la restauration, une fois les agents répartis entre les départements, coûtera davantage.

Les travailleurs du savoir sont également concernés. Les agents agissent de plus en plus via leurs comptes, leurs données et leurs outils de communication, créant des conséquences susceptibles d’apparaître sous une identité humaine.

La manchette de Google News identifie correctement la nécessité d’un nouveau modèle de gouvernance. La question plus difficile est de savoir si les organisations imposeront ce modèle avant que l’activité autonome ne devienne une infrastructure ordinaire.

Demandez qui est responsable de chaque agent déployé, quelles actions il peut entreprendre et ce qui se produit lorsque ses instructions changent. Exigez ensuite des preuves que les réponses résistent à une défaillance réelle.