Amazon Bedrock AgentCore MCP Apps fait passer l’IA interactive au-delà du simple texte

Amazon Web Services a publié un modèle complet Amazon Bedrock AgentCore MCP Apps, transformant un serveur MCP unique en interface interactive pour plusieurs hôtes IA. Cette publication du 11 septembre est importante, car elle fait évoluer les intégrations conversationnelles au-delà des réponses textuelles sans lier le service sous-jacent à un seul produit de chat.

L’exemple d’AWS permet aux utilisateurs de parcourir un inventaire fictif de locations, d’effectuer une réservation, de consulter une location en cours et de finaliser un retour. Certaines réponses apparaissent sous forme de cartes HTML interactives dans la conversation. D’autres restent en texte brut lorsqu’une interface apporterait peu de valeur.

L’enjeu principal n’oppose pas AWS à un autre fournisseur de cloud. Il concerne une couche applicative indépendante des hôtes face aux intégrations sur mesure que les développeurs construisent actuellement pour ChatGPT, Claude et d’autres clients IA. AWS fournit une infrastructure d’exécution gérée, tandis que l’extension MCP Apps définit la manière dont les hôtes compatibles découvrent et affichent l’interface.

Cette séparation porte une promesse séduisante : construire une fois le serveur et le widget, puis proposer une expérience cohérente partout où l’extension est prise en charge. Elle soulève aussi l’incertitude centrale. La portabilité du protocole ne garantit pas automatiquement un comportement identique selon les hôtes, une sécurité prête pour la production ou une large adoption par les utilisateurs.

Amazon Bedrock AgentCore MCP Apps relie les outils aux widgets

Le nouveau modèle AWS relie des outils invoqués par le modèle à des interfaces que les utilisateurs peuvent consulter et utiliser au sein d’une conversation avec une IA.

L’application d’exemple, appelée Unicorn Rentals, commence par une requête en langage naturel visant à afficher les locations disponibles. Au lieu de renvoyer un inventaire textuel, l’hôte affiche des cartes avec des images, des noms, des descriptions, des tarifs horaires et la disponibilité.

Un utilisateur peut ensuite demander à réserver une licorne donnée. L’application enregistre la transaction et affiche une confirmation comprenant l’identifiant de réservation et les détails de la location. Une autre requête récupère la location en cours, tandis qu’une dernière la restitue et calcule le montant total.

Le thème fictif rend la démonstration accessible, mais le modèle d’interaction s’applique aux logiciels métier courants. Un service de voyage pourrait afficher des options de vol, tandis qu’un système de support pourrait présenter des tickets et des contrôles de statut. Un outil d’analyse pourrait renvoyer un graphique avec des filtres au lieu de décrire chaque point de données en prose.

MCP Apps est une extension du Model Context Protocol, une norme par laquelle les hôtes IA découvrent et invoquent des outils externes. Les réponses MCP traditionnelles peuvent déjà inclure du texte, des images, des ressources et des données structurées. L’extension ajoute une méthode standardisée pour fournir des interfaces interactives aux côtés de ces résultats.

Selon la spécification MCP Apps, un outil peut identifier une ressource d’interface utilisateur qu’un hôte compatible récupère et affiche dans un cadre isolé. L’hôte transmet les résultats de l’outil à cette interface et assure la médiation des communications ultérieures.

L’implémentation AWS associe un outil à son widget via le champ _meta.ui.resourceUri. Un résultat d’outil contient structuredContent, qui fournit au widget les données nécessaires à l’affichage. Cette organisation maintient la déclaration de l’interface liée à l’outil sans intégrer l’interface entière dans chaque réponse.

Les widgets sont enregistrés comme ressources MCP. L’hôte découvre les outils et ressources disponibles grâce aux appels de protocole standard, puis lit la ressource HTML appropriée lorsqu’il doit présenter une interface.

AWS distribue le serveur sous la forme d’une application TypeScript utilisant le SDK MCP officiel et l’extension @modelcontextprotocol/ext-apps. Il fonctionne via un serveur Express.js dans un environnement Node.js 22 sur AgentCore Runtime.

L’implémentation de référence de l’entreprise expose quatre outils principaux : lister l’inventaire, réserver une location, consulter les réservations et restituer une location. Elle inclut également les ressources de widget nécessaires aux réponses visuelles.

Il ne s’agit pas simplement d’un traitement visuel de la sortie d’un chatbot. L’interface reste intégrée à un flux de travail médié par un agent. Le modèle interprète la demande, choisit un outil et aide à faire progresser la tâche, tandis que le widget offre aux utilisateurs une surface plus précise pour examiner les résultats.

Cette combinaison répond à une faiblesse fondamentale des logiciels reposant uniquement sur le chat. Le texte fonctionne bien pour les explications et les confirmations brèves. Il devient inefficace lorsque les utilisateurs doivent comparer plusieurs éléments, examiner des enregistrements structurés ou faire des choix aux conséquences importantes.

L’adaptateur léger est le pari architectural

AWS considère le serveur MCP comme un adaptateur de protocole léger, laissant les règles métier et les enregistrements durables dans des services backend conventionnels.

L’exemple ne place pas toutes les responsabilités de l’application dans le déploiement AgentCore. Une fonction AWS Lambda dédiée gère les requêtes d’inventaire et les opérations de réservation, tandis qu’Amazon DynamoDB stocke les données de l’application.

Le serveur MCP fait la traduction entre un hôte IA et cette couche métier. Il publie les outils, décrit les ressources d’interface disponibles, envoie les requêtes au backend et renvoie des résultats structurés.

Cette frontière est au cœur de la conception. Les services métier existants n’ont pas besoin de comprendre MCP, la découverte de widgets ou le rendu par les hôtes. Ils peuvent continuer à exposer des API standard ou des opérations SDK derrière l’adaptateur.

Une entreprise pourrait remplacer la fonction Lambda de démonstration par des services exécutés sur Amazon ECS ou Amazon EKS. Elle pourrait également connecter l’adaptateur à des systèmes hors d’AWS, à condition que le serveur puisse les atteindre et s’authentifier correctement.

Cette approche limite la quantité de logique applicative couplée au protocole conversationnel. Les règles d’inventaire, la validation des transactions et la persistance des données restent réutilisables par les sites web, les applications mobiles, les tableaux de bord internes et d’autres clients.

La couche de widgets peut également évoluer indépendamment. Une équipe pourrait revoir la conception d’une carte produit, introduire un graphique ou ajouter un formulaire d’évaluation sans déplacer le processus métier sous-jacent dans l’hôte.

Cette séparation a des conséquences pratiques pour l’adoption. De nombreuses entreprises ne reconstruiront pas des systèmes de transaction établis autour d’une nouvelle interface IA. Elles sont plus susceptibles de placer une couche de protocole contrôlée devant des services qu’elles exploitent déjà.

Le même raisonnement s’applique aux flux de travail liés aux connaissances. Les équipes doivent souvent combiner des documents, des résultats d’outils et des décisions d’utilisateurs sans déplacer chaque source dans une seule interface. Une base de connaissances consultable peut préserver les documents sources tandis qu’un agent interactif expose des actions ciblées par-dessus.

AgentCore Runtime fournit l’environnement d’exécution géré pour l’adaptateur. AWS indique que l’environnement gère le provisionnement de l’infrastructure, la mise à l’échelle, la gestion de l’état de santé et l’isolation des sessions. Il prend en charge MCP comme mode de protocole natif plutôt que de traiter chaque requête comme du trafic web générique.

La documentation AWS explique qu’un déploiement MCP écoute normalement sur 0.0.0.0:8000/mcp. L’environnement peut prendre en charge des serveurs Streamable HTTP sans état ou avec état, selon que l’application nécessite des fonctionnalités de protocole en plusieurs étapes.

Le fonctionnement sans état convient aux outils dont les appels peuvent être autonomes. Le fonctionnement avec état prend en charge les flux impliquant de la sollicitation d’informations, de l’échantillonnage, des notifications de progression ou d’autres interactions dépendant d’une session continue.

Cette distinction importe pour les applications interactives. Une carte affichant des résultats de recherche peut nécessiter peu d’état de protocole persistant. Un processus d’approbation ou de configuration en plusieurs étapes peut exiger une continuité entre plusieurs actions utilisateur.

AgentCore Runtime ajoute un identifiant de session MCP lorsqu’une requête n’en contient pas. Cela aide les requêtes associées à atteindre la même session d’exécution, mais ne dispense pas l’application de sa responsabilité concernant l’identité utilisateur.

AWS avertit explicitement qu’AgentCore n’applique pas l’association entre un utilisateur et un identifiant de session. Le backend client doit maintenir cette association et empêcher un utilisateur de présenter la valeur de session d’un autre utilisateur.

L’approche de l’adaptateur léger réduit donc le couplage au protocole, mais n’élimine pas l’architecture applicative. Les équipes ont toujours besoin de règles d’autorisation, de validation des entrées, de journaux d’audit, de gestion des erreurs backend et de protections pour les transactions.

Les interfaces indépendantes des hôtes mettent les intégrations sur mesure sous pression

La pression concurrentielle principale s’exerce sur les couches applicatives propres à chaque hôte, qui obligent les développeurs à reconstruire des interfaces similaires pour chaque client IA.

Avant MCP Apps, plusieurs projets abordaient les interfaces conversationnelles à travers différents schémas et SDK. Un développeur pouvait créer une application pour un hôte, mais un autre pouvait exiger des métadonnées, des règles de rendu ou des méthodes de communication différentes.

La communauté MCP a introduit son extension Apps afin de créer un modèle d’interface partagé. Sa proposition initiale s’appuyait sur les travaux de MCP-UI, du Apps SDK d’OpenAI et de contributeurs associés à OpenAI comme à Anthropic.

La proposition d’extension présentait les interfaces interactives comme une capacité fréquemment demandée. Elle identifiait également l’interopérabilité et des modèles de sécurité cohérents comme des raisons de standardiser.

AWS traduit désormais cette spécification en un parcours de déploiement géré. Son exemple place le serveur MCP sur AgentCore Runtime et l’expose via AgentCore Gateway. Un hôte compatible reçoit un point de terminaison unique plutôt qu’un ensemble de ressources propres à AWS.

Cela crée une distinction significative entre le choix de l’infrastructure et le choix de la distribution. Une équipe peut déployer le serveur sur AWS sans sélectionner un modèle AWS ni un hôte conversationnel détenu par AWS.

AgentCore prend lui-même en charge plusieurs frameworks et modèles. AWS positionne son environnement comme une infrastructure pour des agents construits avec des frameworks tels que Strands Agents, LangGraph, CrewAI et d’autres piles de développement.

Pour MCP Apps, toutefois, la forme de neutralité la plus importante se situe à la frontière du protocole. L’hôte IA invoque des outils et demande des ressources d’interface sans nécessiter un accès direct à la fonction Lambda ou à la table DynamoDB.

AWS indique que le même serveur Unicorn Rentals fonctionne avec ChatGPT, Claude et d’autres hôtes prenant en charge l’extension. Cette précision est importante. La neutralité des hôtes s’applique aux clients compatibles, et non à toutes les interfaces de chat utilisées.

La prise en charge peut également différer selon la version du client, l’environnement d’exploitation et les fonctionnalités activées. Les développeurs doivent vérifier la matrice actuelle des hôtes avant de promettre qu’une interface apparaîtra partout.

Même parmi les hôtes compatibles, des messages de protocole identiques ne garantissent pas une présentation identique. Les hôtes contrôlent leur mise en page conteneur, leur sandbox, leurs autorisations, leur comportement en matière d’accessibilité et certaines parties du modèle d’interaction.

Le serveur peut fournir le même code de widget et les mêmes données structurées. Le produit environnant détermine toujours la manière dont les utilisateurs autorisent les connexions, découvrent l’application, approuvent les appels d’outils et passent entre le chat et les contrôles de l’interface.

C’est pourquoi l’annonce met les intégrations sur mesure sous pression sans les remplacer immédiatement. Un SDK spécifique à un hôte peut exposer des fonctionnalités indisponibles via une extension partagée. Il peut aussi offrir une intégration plus étroite avec la navigation, le système d’identité ou le canal de distribution de l’hôte.

La voie neutre offre un avantage différent. Elle concentre l’investissement applicatif dans le serveur, le contrat de données et le widget, plutôt que de dupliquer ces composants pour chaque hôte.

Cela peut améliorer le pouvoir de négociation des développeurs et des acheteurs en entreprise. Si une application reste utile d’un hôte à l’autre, changer l’interface conversationnelle devient moins coûteux. Le backend et la majeure partie du travail d’interface peuvent rester inchangés.

L’effet dépendra de la poursuite de l’alignement des fournisseurs d’hôtes autour de l’extension. Une norme acquiert de l’influence grâce à des implémentations compatibles, un comportement fiable et des applications utiles, et non par sa seule publication.

La passerelle gérée résout l’accessibilité, pas la confiance

AgentCore Gateway rend un serveur MCP accessible via un point de terminaison géré, mais le modèle d’accès de l’exemple exige un renforcement délibéré avant la mise en production.

L’architecture AWS place un AgentCore Gateway entre les hôtes d’IA externes et le runtime. La passerelle transmet les requêtes au runtime par le biais d’une connexion authentifiée avec AWS Signature Version 4 utilisant son rôle d’exécution.

Dans l’exemple, les requêtes entrantes vers la passerelle n’utilisent aucune authentification. AWS Web Application Firewall applique alors une liste blanche d’adresses IP, des règles gérées de détection des menaces et des limites de débit autour du point de terminaison public.

Cette configuration simplifie une démonstration, car un hôte externe n’a pas besoin d’identifiants AWS. Elle ne doit pas être interprétée comme une conception universelle d’authentification pour la production.

Le dépôt de l’exemple comporte un avertissement clair : il n’est pas destiné à la production sans revue de sécurité, tests et renforcement appropriés. Cet avertissement est important, car l’application effectue des actions et ne se limite pas à la récupération d’informations.

Un catalogue de produits en lecture seule limite les dommages potentiels. Réserver, retourner, acheter, modifier des paramètres ou approuver une opération peut affecter des données persistantes et entraîner des conséquences financières ou opérationnelles.

Une liste blanche d’adresses IP peut restreindre l’accès, mais elle n’établit pas l’identité d’un utilisateur final. Une infrastructure de sortie partagée peut également rendre les règles fondées sur les adresses IP moins précises qu’une autorisation au niveau du compte ou de l’utilisateur.

Les équipes de production doivent déterminer où s’arrête l’authentification et où commence l’autorisation. Une connexion d’hôte peut prouver quel service a envoyé une requête, tandis que l’application doit toujours déterminer quel utilisateur peut consulter ou modifier chaque enregistrement.

Le serveur doit valider chaque argument d’outil au lieu de supposer que le modèle a généré une requête sûre. Il doit également appliquer l’autorisation dans le backend plutôt que de s’appuyer sur le widget pour masquer les actions indisponibles.

Le code du widget mérite le même niveau d’examen que tout autre code d’application web. Les hôtes MCP affichent ces interfaces dans des cadres isolés, ce qui limite l’accès direct à la page de l’hôte. L’isolation ne valide ni la logique métier ni le traitement des données de l’application.

Le widget reçoit des sorties d’outils structurées et peut communiquer par l’intermédiaire d’un pont médié par l’hôte. Les équipes doivent limiter le contenu, les destinations réseau et l’accès aux outils à ce dont l’interface a réellement besoin.

L’injection de prompt reste pertinente, car les modèles peuvent rencontrer du texte non fiable avant de sélectionner ou d’appeler un outil. Une interface bien conçue ne rend pas un outil dangereux sûr. Les actions sensibles nécessitent toujours des contrôles déterministes et, le cas échéant, une confirmation explicite.

Les conseils de sécurité d’AWS décrivent des microVM dédiées pour les sessions de runtime serverless. Selon la documentation, chaque session reçoit des ressources de calcul, de mémoire et de système de fichiers isolées.

Ces mêmes conseils clarifient la frontière de responsabilité partagée. Les propriétaires d’applications restent responsables du périmètre IAM, de la sécurité des dépendances, de la gestion des identifiants, de la validation des entrées, des règles réseau et de l’association entre session et utilisateur.

Les identifiants du rôle d’exécution au sein d’une session de runtime exigent également un traitement prudent. Le code exécuté dans la microVM peut accéder aux identifiants fournis à cet environnement. Les politiques de moindre privilège restent donc essentielles.

La passerelle ne doit avoir l’autorisation d’invoquer que le runtime prévu. La politique de ressources du runtime doit rejeter les invocations directes par des principaux non liés. Les services backend doivent restreindre séparément ce que le runtime peut leur demander.

L’observabilité doit traverser ces couches. Les équipes ont besoin d’une journalisation suffisante pour relier la requête de l’hôte, la transaction de passerelle, la session de runtime, l’appel d’outil, l’opération backend et l’identité utilisateur sans exposer de contenu sensible.

Cela devient particulièrement important lorsqu’une requête conversationnelle produit plusieurs appels d’outils. Une réservation échouée peut résulter du comportement de l’hôte, du traitement du protocole, de la politique de passerelle, du code du runtime, de la validation backend ou d’une contention sur les données.

Les composants gérés réduisent le travail d’infrastructure, mais ils ne regroupent pas ces responsabilités en un seul contrôle. L’aptitude à la production dépendra de la clarté avec laquelle les équipes définissent et testent chaque frontière.

La portabilité dépend toujours du comportement de l’hôte

Les MCP Apps expliquées au niveau du protocole constituent des ressources portables, mais la véritable portabilité doit résister aux différences de découverte, d’autorisations, de rendu et de mises à jour.

La démonstration AWS soutient la version la plus forte de l’argument en faveur de la portabilité. Un serveur publie les outils, les identifiants de ressources, le HTML du widget et les résultats structurés. Les hôtes compatibles consomment ce package via le même protocole.

Le serveur n’a pas besoin d’une implémentation de logique métier distincte pour chaque hôte. Il évite également de servir un bundle de widget différent uniquement parce que l’utilisateur a commencé la tâche dans un autre client compatible.

Pourtant, un format de transport partagé n’est que la première couche de compatibilité. Les utilisateurs traversent tout un parcours produit avant qu’un widget n’apparaisse.

Ils doivent connecter le serveur, s’authentifier, comprendre les autorisations demandées, découvrir la capacité pertinente, puis formuler ou initier une action. Après le rendu, ils doivent interpréter l’interface et terminer le flux de travail.

Chaque hôte peut rendre ces étapes différentes. L’un peut privilégier la découverte conversationnelle, tandis qu’un autre propose un répertoire d’applications. L’un peut demander une confirmation pour chaque action externe, tandis qu’un autre regroupe les approbations.

La mise en page responsive constitue un autre test. Un widget adapté à une large conversation sur ordinateur peut sembler à l’étroit sur mobile. La navigation au clavier, les lecteurs d’écran, le contraste des couleurs et le comportement du focus doivent également fonctionner dans le cadre de l’hôte.

La gestion des échecs demande une attention particulière. Si une requête backend expire, l’interface doit expliquer l’état sans laisser entendre qu’une opération a réussi. Les actions relancées ne doivent pas créer accidentellement de transactions en double.

Le versioning introduit une complication supplémentaire. Un serveur peut mettre à jour son widget et ses schémas d’outils tandis que certains hôtes mettent des ressources en cache ou prennent en charge une version plus ancienne de l’extension. Les tests de compatibilité doivent couvrir à la fois les mises à niveau planifiées et les états de déploiement partiel.

La documentation officielle de l’extension indique que les hôtes rendent les ressources d’interface dans des iframes isolées et échangent des messages via l’App Bridge. Cela fournit une base commune pour la communication et l’application des politiques.

Elle ne prescrit pas chaque détail visuel. C’est une limite raisonnable pour une extension ouverte, mais elle laisse aux développeurs la responsabilité de tester la même application dans plusieurs implémentations clientes.

La question n’est donc pas de savoir si un code identique peut circuler. Elle consiste à savoir si la tâche obtenue reste compréhensible, sûre et fiable lorsqu’elle atteint chaque hôte.

L’exemple AWS utilise également un service de location fictif avec un modèle de données compact. Les applications réelles impliqueront des ensembles de résultats plus volumineux, des autorisations de compte, des données réglementées, la localisation et des parcours d’exception complexes.

Ces exigences peuvent révéler des dépendances cachées envers l’hôte. Une conception peut s’appuyer sur un viewport, un flux d’authentification, un sélecteur de fichiers, une capacité de navigateur ou un modèle d’approbation spécifique qu’un autre hôte ne fournit pas.

Les développeurs devraient définir la portabilité comme un niveau de service testé plutôt que comme une affirmation binaire sur le protocole. Le contrat d’outil central doit se comporter de manière cohérente, tandis que les différences de présentation propres à l’hôte doivent rester limitées et documentées.

Un programme de test utile exécuterait les mêmes tâches critiques sur chaque hôte pris en charge. Les équipes devraient comparer les taux d’achèvement, le comportement en cas d’erreur, les demandes d’autorisation, les performances de rendu, l’accessibilité et les effets secondaires backend.

Le résultat pourrait justifier un widget partagé pour la plupart des flux de travail et une expérience spécifique à l’hôte pour quelques fonctionnalités spécialisées. Cette issue préserverait tout de même une grande partie de la valeur d’un serveur commun.

Trois signaux mettront à l’épreuve le pari des AgentCore MCP Apps

La prochaine phase sera décidée par les déploiements en production, la cohérence inter-hôtes et des modèles de sécurité qui vont au-delà de l’exemple public.

Le premier signal est de savoir si les organisations adaptent l’architecture à de véritables services transactionnels. Une démonstration prouve que les composants se connectent. Un déploiement de production teste ensemble l’identité, l’autorisation, l’observabilité, la latence, le versioning et la reprise après échec.

Des exemples publics impliquant des données propres à un compte renforceraient l’argument. Il en irait de même pour des implémentations qui placent l’adaptateur MCP devant un service existant sans imposer de changements backend majeurs.

Des preuves d’utilisation en production soutiendraient la thèse AWS de l’adaptateur léger. Si les équipes déplacent à plusieurs reprises la logique applicative vers des couches d’hôte personnalisées, cela suggérerait que l’extension n’exprime pas encore une part suffisante de l’expérience.

Le deuxième signal est une prise en charge cohérente parmi les principaux hôtes d’IA. Les développeurs devraient surveiller les listes de compatibilité des clients, la prise en charge des versions d’extension et les retours d’équipes exécutant le même widget dans plusieurs environnements.

Une matrice d’hôtes en croissance renforcerait l’argument selon lequel les MCP Apps peuvent devenir une couche de distribution. D’importantes différences comportementales l’affaibliraient, même si chaque client reste techniquement compatible.

La métrique pertinente est l’accomplissement de la tâche, et non une case à cocher. Les utilisateurs doivent pouvoir se connecter, découvrir, comprendre et terminer le même flux de travail sans formation propre à l’hôte.

Le troisième signal est l’émergence de conceptions de sécurité de production reproductibles. Celles-ci doivent couvrir l’authentification utilisateur, l’association des sessions, l’autorisation des actions, la politique du widget, les pistes d’audit et la protection contre un contexte de modèle non fiable.

AWS documente des options IAM et OAuth pour invoquer AgentCore Runtime. Son exemple privilégie une démonstration accessible, tandis que ses conseils de production attribuent une responsabilité importante au propriétaire de l’application.

Des architectures de référence claires pour des MCP Apps publiques authentifiées réduiraient cet écart. Des revues de sécurité indépendantes et des modèles de déploiement fourniraient des preuves plus solides que les seules affirmations sur l’infrastructure.

Les développeurs devraient également suivre l’évolution des sessions AgentCore Gateway. La documentation AWS indique que les sessions MCP gérées par la passerelle peuvent préserver l’état et réduire les initialisations répétées. Les fonctionnalités avec état exigent des contrôles attentifs de l’identité et du cycle de vie.

Pour les acheteurs en entreprise, la décision immédiate n’est pas de remplacer chaque interface par du chat. Il s’agit de déterminer si une surface conversationnelle interactive peut réutiliser des services métier établis sans créer une nouvelle pile applicative isolée.

Pour les développeurs, l’exemple AWS offre un point concret pour tester cette proposition. Remplacez le service Lambda fictif par une API interne contrôlée, gardez les premiers outils en lecture seule et comparez le comportement entre les hôtes compatibles.

Documentez chaque hypothèse que le widget formule à propos de son hôte. Traitez les appels d’outils comme des entrées non fiables, associez les sessions à des utilisateurs authentifiés et maintenez l’autorisation au plus près du système propriétaire des données.

Amazon Bedrock AgentCore MCP Apps dispose désormais d’un modèle de déploiement crédible plutôt que d’un simple diagramme de protocole. La question sans réponse est de savoir si les équipes peuvent préserver cette portabilité lorsque de véritables identités, transactions et différences entre hôtes entrent dans le système.

Une prochaine étape judicieuse consiste à choisir un flux de travail structuré que le texte gère mal et à le tester de bout en bout. Un widget interactif réduit-il l’effort utilisateur sur plusieurs hôtes sans affaiblir le contrôle ? Le résultat en dira davantage sur le modèle qu’une autre démonstration soignée.