Trois surfaces : humaine, Apple Intelligence, agent

Toute capacité significative dans une application iOS sur iOS 26+ fait désormais face à un maximum de trois surfaces depuis lesquelles elle peut être invoquée. La même fonction Swift qui enregistre un verre d’eau peut être déclenchée par un humain qui appuie sur un bouton, par Apple Intelligence qui route une requête Siri, ou par un agent externe (Claude Code, Cursor, ChatGPT) qui appelle un outil MCP. Trois appelants différents, trois obligations différentes, trois surfaces de rendu différentes. La capacité est la même ; les surfaces, non.

Beaucoup d’erreurs d’architecture iOS proviennent de la conception pour une seule surface, suivie d’une adaptation forcée de la capacité aux autres. Les flux d’interface utilisateur fuient dans les réponses Siri ; les outils d’agent qui sont corrects pour un développeur deviennent des dangers pour les utilisateurs finaux ; les fonctionnalités LLM sur l’appareil supposent un contexte de qualité cloud. Le cluster a cartographié ces surfaces dans des articles individuels. L’article présent est la synthèse : les trois surfaces, leurs différences, la règle de routage, et à quoi doit ressembler la couche de domaine d’une application pour servir les trois sans en compromettre aucune.

Le modèle mental : choisissez une capacité de domaine. Demandez-vous laquelle des trois surfaces devrait pouvoir l’invoquer. Demandez-vous laquelle le peut. Demandez-vous ce dont chaque surface a besoin de la capacité et ce que la capacité doit lui rendre. Les réponses façonnent l’architecture.

TL;DR

• Trois surfaces : humaine (vues SwiftUI, tapotements, gestes, écran), Apple Intelligence (App Intents, Siri, Shortcuts, Spotlight), agent (serveurs MCP, hôtes LLM externes).
• Chaque surface a des obligations différentes : posture de confiance, budget de latence, emplacement de rendu, sémantique de persistance, gestion des erreurs, exigences d’accessibilité.
• La bonne architecture est une couche de domaine sous les surfaces. Chaque surface est un adaptateur mince au-dessus des mêmes fonctions Swift ; la fonction prend un argument typé Caller afin de pouvoir se ramifier sur des règles inter-surfaces (limites de débit, audit, confirmations) sans connaître les détails du protocole de surface.
• Toutes les capacités ne servent pas les trois surfaces. La décision quelle surface est le choix de conception. Cacher des capacités aux surfaces qui ne devraient pas y avoir accès est tout autant une décision produit que les exposer aux surfaces qui le devraient.

Surface un : humaine

La surface humaine, c’est l’écran. L’utilisateur regarde l’application, tapote, fait défiler, fait glisser, balaie, tape. Le framework est SwiftUI (ou UIKit, ou pour certaines charges de travail RealityKit sur visionOS). Le rendu se produit sur l’appareil de l’utilisateur, dans le processus de l’application, en fonction de la palette de couleurs choisie par l’utilisateur, de la taille du Dynamic Type et des paramètres d’accessibilité.¹

Ce dont la surface humaine a besoin de la part d’une capacité :

• Une affordance visuelle. Un bouton, une ligne de liste, un geste de balayage, un menu contextuel. La capacité doit être détectable par la navigation de l’application et stylisée de manière cohérente avec le reste de l’interface utilisateur.
• Un retour en temps réel. Chaque interaction nécessite une réponse visible immédiate. Un bouton qui déclenche une opération de longue durée doit afficher un indicateur de progression, un état activé/désactivé, une animation.
• L’accessibilité. Étiquettes VoiceOver, prise en charge du Dynamic Type, contraste des couleurs, alternatives de contrôle moteur. La surface humaine est celle qui présente les exigences d’accessibilité les plus strictes, car l’utilisateur interagit directement avec le rendu.
• La visibilité des erreurs. Les erreurs atterrissent dans la vue de l’utilisateur. Un échec de sauvegarde affiche une alerte ; un délai d’attente réseau affiche une nouvelle tentative ; un refus d’autorisation affiche un lien vers les paramètres.

Ce que la surface humaine rend en retour à la capacité :

• Une intention utilisateur sans ambiguïté. L’utilisateur a appuyé sur un bouton spécifique ; la capacité sait exactement ce qui a été demandé. Il n’y a pas de couche d’inférence.
• Un budget de latence serré. Un tapotement qui prend plus de quelques centaines de millisecondes pour répondre visiblement semble cassé. La capacité doit être soit rapide, soit conçue pour montrer immédiatement la progression.
• Aucune autorité externe. L’utilisateur est dans l’application ; l’utilisateur est l’agent au sens le plus large (l’humain est celui qui pilote l’action). Pas de LLM tiers, pas d’agent système, juste les mains de l’utilisateur.

La surface humaine est la plus ancienne des trois. Chaque framework iOS, chaque modèle de conception et chaque règle d’accessibilité que la plateforme a accumulés depuis iOS 7 sont au service de cette surface. Les deux autres surfaces sont suffisamment récentes pour que les modèles soient encore en cours d’établissement.

Surface deux : Apple Intelligence

La surface Apple Intelligence est l’agent système. Siri, Shortcuts, Spotlight, la pile de suggestions système. L’utilisateur parle, tape dans Spotlight ou enchaîne une action dans Shortcuts ; le système route la requête à travers le framework App Intents, trouve un AppIntent qui correspond, résout les paramètres et exécute le corps perform() de l’intent. Le framework est App Intents.²

Ce dont la surface Apple Intelligence a besoin de la part d’une capacité :

• Un schéma typé. Les types AppIntent déclarent des propriétés @Parameter ; les types AppEntity fournissent une identité persistante pour les éléments dont le système peut parler ; les types AppEnum nomment des ensembles fermés d’options. Le système lit le schéma au moment de l’installation.
• Une identité qui survit au processus de l’application. Une entrée d’eau que l’utilisateur a enregistrée via Siri hier devrait pouvoir être référencée via Siri aujourd’hui. Le modèle AppEntity donne au système un moyen stable de parler des objets entre les sessions.
• Une gestion silencieuse des erreurs. Les erreurs n’atterrissent pas dans la vue d’un utilisateur ; elles atterrissent dans une réponse Siri, une sortie Shortcuts ou un résultat Spotlight. Le format d’erreur attendu par le système est structuré (le AppIntentError d’Apple plus les throws conformes à LocalizedError), et non visuel.
• L’idempotence sous nouvelle tentative. Le système peut réinvoquer un intent pendant une chaîne Shortcut ou après un échec partiel. Les capacités qui mutent l’état doivent être sûres lors d’appels répétés ou exposer une sémantique claire de « déjà fait ».

Ce que la surface Apple Intelligence rend en retour à la capacité :

• L’identité réelle de l’utilisateur. Le système sait qui est l’utilisateur, l’a authentifié via le système d’exploitation et exécute l’intent dans son contexte. La capacité n’a pas besoin de vérifier l’identité au-delà de ce que fournit le système d’exploitation.
• Un rendu au niveau du système. Le résultat que l’intent renvoie est formaté par le système dans le chrome approprié (bannière d’écran de verrouillage, carte de réponse Siri, sortie Shortcuts). L’application ne contrôle pas la façon dont la réponse se présente.
• La détectabilité sans que votre code ne s’exécute. Les App Intents peuvent être invoqués lorsque votre application n’est pas en cours d’exécution. Le système lit le schéma et fait remonter la capacité de manière proactive.

La posture de confiance : Apple Intelligence est l’agent propriétaire d’Apple. L’utilisateur ne l’a pas configuré ; le système l’a fait. L’utilisateur fait confiance au système d’exploitation ; le système d’exploitation fait confiance au schéma App Intents que votre application a livré via la révision. La chaîne de confiance va de l’OS vers l’application. Les App Intents prennent en charge requestConfirmation(...) et les confirmations en mode premier plan, donc les capacités qui ont besoin d’un « êtes-vous sûr ? » peuvent techniquement y vivre ; le jugement produit, et non la contrainte de plateforme, détermine si les confirmations à haut risque appartiennent à l’intérieur d’un tour Siri ou sur l’écran de l’application elle-même. Tout ce qui est irréversible (suppression de compte, modifications en masse destructrices, paiement) est généralement plus sûr sur la surface humaine, même si les App Intents peuvent demander une confirmation.³

Surface trois : agent

La surface agent est tout autre système alimenté par LLM qui souhaite faire fonctionner le domaine de l’application. Claude Desktop, Claude Code, Cursor, l’application de bureau ChatGPT, Codex CLI, les harnais d’agent personnalisés. Le framework est le Model Context Protocol : un serveur MCP expose le domaine de l’application via des méthodes JSON-RPC tools/call ; l’hôte LLM découvre les outils au début de la session et les appelle par leur nom avec une charge utile JSON.⁴

Ce dont la surface agent a besoin de la part d’une capacité :

• Un contrat JSON-RPC. Nom de l’outil, description, inputSchema, outputSchema optionnel. L’agent lit la description pour décider s’il faut appeler ; il suit le schéma pour formater les arguments.
• Une description utile. Le modèle décide quand utiliser l’outil en fonction de sa description. Traitez la description comme une docstring que vous attendez d’un autre développeur (le modèle) qu’il lise. Des descriptions vagues produisent une mauvaise sélection d’outils.
• Des erreurs sous deux formes. Les erreurs d’exécution d’outil sont renvoyées sous la forme d’un bloc de contenu plus isError: true sur le résultat de l’outil que le modèle lit. Les erreurs au niveau du protocole (requête malformée, outil manquant, échec de transport) sont renvoyées sous forme de réponses error JSON-RPC standard que l’hôte gère. L’auteur de l’outil possède le premier ; le protocole possède le second.
• Une sémantique sans état ou avec état explicite. MCP a un état au niveau du protocole (cycle de vie de la session, ID de session dans Streamable HTTP), mais l’identité de domaine durable est de la responsabilité du serveur, et non une garantie au niveau du protocole. Si le même identifiant doit signifier la même chose entre les sessions, le serveur doit l’imposer.

Ce que la surface agent rend en retour à la capacité :

• L’authentification de l’hôte, et non celle de l’utilisateur. La confiance vient de quiconque a déployé le serveur MCP. Stdio local du développeur : les permissions du système de fichiers du développeur lui-même. HTTP accessible par Internet : quelle que soit l’authentification que le serveur impose. La capacité doit supposer que la revendication d’identité est ce que le serveur lui a donné.
• Une tolérance variable à la latence. L’hôte peut attendre plus longtemps que la surface humaine ou la surface Apple Intelligence. Un appel d’outil qui prend trente secondes est acceptable sur la surface agent et inacceptable sur les autres.
• Aucune surface de rendu. Le résultat est du texte ou des données structurées que le modèle interprète. Pas de chrome, pas d’interface utilisateur, pas de formatage système.

La posture de confiance : le serveur MCP est le contrat du développeur concernant qui a le droit de l’appeler. Deux déploiements du même serveur (stdio local pour le développement, HTTP Internet pour les utilisateurs finaux) ont des postures de confiance très différentes et nécessitent des garde-fous très différents. Le protocole est le même ; le déploiement est l’architecture. Couvert en détail dans App Intents vs MCP : la question du routage et Quand le LLM vit dans votre application vs dans votre outillage.⁵

Les six axes sur lesquels les surfaces divergent

Mettre les trois surfaces dans un tableau de comparaison rend les décisions d’architecture concrètes :

Les divergences se composent. Une capacité conçue pour la surface humaine suppose une latence serrée, un rendu riche, des erreurs gérées par l’application. La forcer à passer par Apple Intelligence fait perdre le contrôle du rendu et ajoute une identité médiée par l’OS. La forcer à passer par la surface agent fait perdre entièrement le rendu et déplace la frontière de confiance vers quiconque a déployé le serveur. La capacité doit être remodelée, pas seulement ré-encapsulée.

La règle d’architecture : couche de domaine sous les surfaces

Le modèle qui survit à travers les trois surfaces est une couche de domaine en dessous d’elles. La couche de domaine consiste en de simples fonctions Swift : entrées typées, sorties typées, aucune hypothèse de protocole. Chaque surface est un adaptateur mince au-dessus du domaine. La même fonction logWater(amount:caller:) soutient le bouton SwiftUI, le perform() de l’App Intent et le gestionnaire d’outil MCP.

L’esquisse (la production réelle ferait conformer WaterEntry à AppEntity pour le retour de l’App Intent, injecterait domain en tant que dépendance plutôt que comme référence de niveau supérieur, et ajouterait le static var title requis sur l’intent) :

// Domain layer (the actual capability)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter A: human surface (SwiftUI button)
Button("Log 250ml") {
    Task {
        let entry = try await domain.logWater(
            amount: .init(value: 250, unit: .milliliters),
            at: .now,
            caller: .human
        )
        // Update view state, show confirmation animation, etc.
    }
}

// Adapter B: Apple Intelligence surface (AppIntent)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>
    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)  // WaterEntry conforms to AppEntity
    }
}

// Adapter C: agent surface (MCP tool handler)
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

Trois appelants. Une fonction de domaine. La fonction de domaine prend un paramètre Caller afin de pouvoir imposer des règles différentes par surface (limites de débit, journalisation d’audit, exigences de confirmation) sans que chaque surface ait à les réimplémenter. Les adaptateurs sont stupides ; le domaine est intelligent.

La forme généralise le modèle à double adaptateur de App Intents vs MCP ; ajouter la surface humaine en tant que troisième classe d’appelant est l’extension naturelle. Le LLM Foundation Models sur l’appareil, lorsqu’il est utilisé à l’intérieur de l’application, se trouve sur la surface humaine (l’utilisateur a invoqué une fonctionnalité dans l’application qui se trouve appeler le modèle) ; le LLM d’exécution n’est pas une quatrième surface, c’est une manière d’exécuter des capacités qui appartiennent déjà à la surface humaine.⁶

Toutes les capacités ne servent pas les trois surfaces

L’exposition égale n’est pas l’objectif. Différentes capacités appartiennent à différentes surfaces.

Capacités qui devraient généralement nécessiter une présence humaine au premier plan. Capture de photo, authentification biométrique, saisie d’informations personnelles sensibles, confirmation de paiement, suppression de compte. L’humain doit regarder l’écran, doit consentir, doit s’authentifier. Apple Intelligence peut techniquement faire passer l’application au premier plan et demander une confirmation ; la surface agent n’a pas de garantie de présence équivalente. Le jugement produit est que ces capacités devraient s’exécuter en tant qu’interface utilisateur de premier plan avec une action délibérée explicite, et non comme un appel d’outil silencieux Siri ou en arrière-plan.

Capacités qui devraient vivre sur les surfaces humaine + Apple Intelligence. La plupart des actions visibles par l’utilisateur. Enregistrer de l’eau, commencer une méditation, ajouter un élément à la liste, me montrer mes entrées de mardi. L’utilisateur peut appuyer sur un bouton ou peut dire « Dis Siri ». Les deux surfaces sont valides ; les deux devraient atteindre la même fonction de domaine.

Capacités qui devraient vivre sur les trois surfaces. Les intégrations inter-processus. Une liste de courses partagée entre l’iPhone de l’utilisateur et une session Claude Code qui importe des recettes. La surface humaine possède l’utilisation quotidienne ; la surface Apple Intelligence possède la portée Siri/Spotlight ; la surface agent possède le flux de travail externe piloté par le développeur ou l’utilisateur.

Capacités qui ne devraient vivre que sur la surface agent. Les imports en masse de développeurs ou d’administrateurs sans flux de révision pour l’utilisateur final, les intégrations avec des systèmes externes, les flux de travail orchestrés par agent qui n’ont aucune expression Siri ou dans l’application. Importer en masse 500 entrées historiques à partir du CSV d’un développeur lors d’un remplissage unique. Les imports de fichiers par l’utilisateur final ont souvent un flux de surface humaine (Shortcuts peut transmettre des fichiers ; un importateur dans l’application peut découper la progression) ; le cas exclusif à l’agent est le flux de travail qui n’a véritablement sa place dans aucune des deux autres surfaces.

La décision est la conception. Énumérer les surfaces qu’une capacité ne sert pas est aussi important qu’énumérer celles qu’elle sert.

Ce que je construirais différemment

Deux modèles que les applications du cluster livrent, ou souhaiteraient avoir livrés.

Faire de Caller un type de première classe dans la couche de domaine. Chaque fonction de domaine publique prend un argument Caller. Le type encode quelle surface a invoqué l’appel (.human, .siri, .mcp(host:)). La logique de domaine se ramifie dessus pour les invites de confirmation, les limites de débit, la journalisation d’audit et les portes d’action sensibles. L’alternative (chaque surface réimplémentant les règles) dérive ; la version centralisée reste cohérente.

Traiter la couverture des surfaces comme une liste de contrôle explicite. Lors de l’ajout d’une capacité, le document de conception énumère lesquelles des trois surfaces devraient l’exposer et lesquelles devraient la refuser. La liste de refus n’est pas une valeur par défaut ; c’est un choix délibéré. Refusé : surface Apple Intelligence, parce que la capacité nécessite une preuve d’attention de l’utilisateur que Siri ne peut pas fournir. Le raisonnement est consigné ; l’audit attrape la dérive plus tard.

Ce que ce modèle signifie pour les applications livrées sur iOS 26+

Trois enseignements.

1. Trois surfaces, trois postures de confiance. Humaine, Apple Intelligence, agent. Chacune a des obligations que les autres n’ont pas. Concevoir pour une seule et adapter de force aux autres produit une mauvaise architecture sur chaque surface.

2. Le domaine en bas ; les adaptateurs en haut. Une fonction Swift par capacité ; des adaptateurs minces par surface ; la fonction prend un paramètre Caller afin de pouvoir imposer des règles spécifiques à la surface en un seul endroit.

3. Toutes les capacités ne servent pas les trois. Cacher une capacité aux surfaces qui ne devraient pas l’avoir est tout autant une décision de conception que l’exposer. La liste de refus mérite sa place.

Le cluster Apple Ecosystem complet : les App Intents typés pour la surface Apple Intelligence ; les serveurs MCP pour la surface agent ; la question du routage entre eux ; Foundation Models pour les fonctionnalités LLM sur l’appareil à l’intérieur de la surface humaine ; la distinction LLM d’exécution vs outillage ; les Live Activities pour la machine à états de l’écran de verrouillage iOS ; le contrat d’exécution watchOS sur Apple Watch ; les internes de SwiftUI pour le substrat de la surface humaine ; le modèle mental spatial de RealityKit pour les scènes visionOS ; la discipline de schéma SwiftData pour la persistance entre surfaces ; les modèles Liquid Glass pour la couche visuelle humaine ; la livraison multiplateforme pour la portée inter-appareils. Le hub se trouve à la Série Apple Ecosystem. Pour un contexte plus large iOS-avec-agents-IA, consultez le guide de développement d’agents iOS.

FAQ

Quelles sont les trois surfaces d’une application iOS ?

La surface humaine (vues SwiftUI, tapotements, gestes, écran), la surface Apple Intelligence (App Intents, Siri, Shortcuts, Spotlight) et la surface agent (serveurs MCP exposés à des hôtes LLM externes comme Claude Code, Cursor, ChatGPT). Chacune a sa propre identité d’appelant, son budget de latence, son emplacement de rendu, sa sémantique de persistance et sa posture de confiance. Une capacité qui souhaite servir plus d’une surface devrait reposer sur une couche de domaine sous des adaptateurs minces par surface.

Chaque capacité doit-elle être exposée aux trois surfaces ?

Non. Certaines capacités sont correctement limitées à une ou deux surfaces. La capture de photos, l’authentification biométrique et les confirmations d’actions sensibles sont généralement préférables en tant que flux de surface humaine au premier plan, car les signaux de confiance (attention de l’utilisateur, action délibérée) y sont les plus fiablement présents. Les opérations en masse pilotées par les développeurs appartiennent à la surface agent seule lorsqu’aucun flux de révision pour l’utilisateur final n’existe. Le choix de conception est de savoir quelles surfaces une capacité sert et lesquelles elle refuse.

Quelle est la différence entre les surfaces Apple Intelligence et agent ?

Apple Intelligence est l’agent propriétaire d’Apple : l’utilisateur invoque Siri, Shortcuts ou Spotlight ; le système route via les App Intents. La confiance vient du système d’exploitation. La surface agent est tout autre hôte LLM : les développeurs exécutent Claude Code ou Cursor, les utilisateurs finaux exécutent Claude Desktop ou ChatGPT. La confiance vient de quiconque a déployé le serveur MCP. Les App Intents sont la surface de protocole pour le premier ; MCP est la surface de protocole pour le second.

Où s’inscrit le LLM Foundation Models sur l’appareil ?

À l’intérieur de la surface humaine. Lorsque l’utilisateur invoque une fonctionnalité dans l’application qui appelle Foundation Models, le LLM d’exécution est l’implémentation d’une capacité de surface humaine, pas une quatrième surface. Le LLM d’exécution n’a pas d’appelant Siri ou d’hôte externe propre. Les outils Foundation Models sont la façon dont le modèle sur l’appareil lit/écrit l’état du domaine de l’application ; l’utilisateur est celui qui pilote l’appel.

Comment le modèle de couche de domaine simplifie-t-il le code multi-surfaces ?

En centralisant les règles. Une seule fonction Swift prend un argument Caller et impose un comportement spécifique à la surface (invites de confirmation, limites de débit, journalisation d’audit) en un seul endroit. Chaque surface est un adaptateur mince (liaison SwiftUI, AppIntent.perform, gestionnaire MCP) qui traduit le protocole de la surface vers la fonction de domaine. La dérive entre les surfaces devient impossible car il y a une seule source de vérité.

Références