App Intents vs MCP : la question du routage

Deux protocoles, App Intents et MCP, permettent tous deux à un agent extérieur de piloter le domaine d’une app. Ils ne se réduisent pas l’un à l’autre. La question est de savoir ce qui va où, et pourquoi chaque protocole constitue la bonne réponse pour son propre appelant.

Apple a livré les App Intents pour donner à Apple Intelligence une surface typée et déclarative permettant de piloter des apps tierces sans toucher à leur interface.¹ Anthropic a livré le Model Context Protocol pour donner à n’importe quel LLM une surface typée, médiée par un serveur, permettant de piloter n’importe quel outil sans toucher à son interface.² Les formes se ressemblent. Les appelants, non. Les traiter comme une surface unique produit une architecture qui ne satisfait ni l’un ni l’autre.

Les deux articles précédents de ce cluster traitaient chaque protocole séparément : les App Intents dans App Intents, la nouvelle API d’Apple vers votre app, MCP dans Deux écosystèmes d’agents, une seule liste de courses. L’article présent porte sur la question du routage. Quand une capacité reçoit-elle un AppIntent, quand reçoit-elle un outil MCP, quand reçoit-elle les deux, et qu’est-ce qui reste exposé uniquement à l’intérieur de l’app ?

TL;DR

• Les App Intents sont la seule voie vers Apple Intelligence, Siri, Shortcuts et la pile de suggestions du système. Le système les rend disponibles dès l’installation et au fil des mises à jour de l’app ; la donation et l’indexation des App Shortcuts les font remonter dans Spotlight et dans les suggestions de Siri.
• Les outils MCP sont la voie vers tout LLM non Apple (Claude, ChatGPT, Gemini, modèles locaux). Le transport se fait en stdio ou en Streamable HTTP, .mcpb étant un format d’empaquetage qui embarque couramment un serveur stdio local ; l’hôte charge les outils au démarrage de la session. La révision courante de la spécification est 2025-11-25, et une release candidate du 2026-07-28 réorganise le protocole autour d’un cœur sans état⁶⁷.
• Les deux protocoles convergent sur un schéma typé, une forme entity → action → result et la résolution des paramètres. Ils divergent sur l’identité, la persistance, la latence et la surface de rendu.
• La règle de routage : si la capacité est quelque chose qu’un utilisateur pourrait demander à Siri ou invoquer depuis Spotlight, ce sont les App Intents. Si la capacité est quelque chose qu’un développeur pourrait brancher dans une session Claude Code ou dans une exécution d’agent externe, c’est MCP. La plupart des apps ont besoin des deux pour le même domaine.

Deux protocoles, la même forme

Les deux protocoles définissent un contrat d’opération entre un appelant extérieur et le domaine d’une app. Ce contrat comporte trois parties : le schéma (ce que l’appelant peut demander), le résolveur (comment l’app trouve les entités que le schéma nomme) et l’action (ce qui s’exécute et ce qui revient).

Les App Intents expriment le contrat en Swift. La surface du protocole, ce sont AppIntent, AppEntity et AppEnum, avec les macros @Parameter qui pilotent le schéma et func perform() qui renvoie le résultat.³ Le schéma est généré à la compilation et embarqué dans l’app à l’installation. Apple Intelligence, Siri, Shortcuts et Spotlight lisent tous le même schéma et acheminent une requête typée par le même point d’entrée perform().

MCP exprime le contrat en JSON-RPC sur stdio ou Streamable HTTP. La surface du protocole, ce sont les méthodes tools/list et tools/call, chaque outil déclarant un nom, une description et un inputSchema (la spécification 2025-06-18 a ajouté un outputSchema facultatif pour les retours structurés, et la révision 2025-11-25 établit JSON Schema 2020-12 comme dialecte par défaut, ajoute les icônes d’outils en métadonnées et formalise la gouvernance au-delà d’Anthropic).⁴⁶ Un hôte MCP (Claude Desktop, Claude Code, Cursor, l’app de bureau ChatGPT) découvre les outils au démarrage de la session et les appelle par leur nom avec une charge utile JSON. L’hôte exécute le modèle ; le serveur exécute l’outil. Le protocole est par ailleurs en pleine transition : la release candidate du 2026-07-28 rebâtit MCP autour d’un cœur sans état qui tourne sur une infrastructure HTTP ordinaire, déplace les travaux de longue durée dans une extension Tasks et ajoute une interface rendue côté serveur via MCP Apps⁷. L’argument de routage exposé ci-dessous survit intact à cette révision, car rien là-dedans ne change l’identité de l’appelant.

La forme est la même : schéma, résolveur, action. La différence tient à qui exécute chaque pièce et à l’endroit où passe la frontière de confiance. Les App Intents s’exécutent dans le processus de l’app, sur l’appareil de l’utilisateur, sous les entitlements de l’app, le système assurant l’acheminement des appels. Les serveurs MCP s’exécutent là où le développeur a choisi de les faire tourner (stdio local, HTTP hébergé, bundle embarqué), le LLM hôte assurant l’acheminement des appels sur un ensemble d’outils non borné.

Un troisième appelant, de même forme, mérite d’être nommé parce qu’il complète le tableau : le modèle embarqué derrière le framework Foundation Models d’Apple appelle le code de l’app via son protocole Tool, une capacité nommée, décrite et typée comme les deux autres. Une couche de domaine bien taillée alimente ces trois surfaces sans savoir laquelle appelle.

Là où les deux protocoles divergent

Au-delà de la forme apparente, quatre différences opérationnelles comptent pour le routage :

Identité et persistance. Les App Intents parlent en types AppEntity que le système peut stocker, présenter et re-résoudre plus tard. L’entrée d’eau que j’enregistre aujourd’hui par Dis Siri, note 250 ml dans Water survit aux redémarrages, se synchronise entre les appareils iCloud de l’utilisateur et peut être référencée plus tard par d’autres intents (Montre-moi les entrées d’eau d’hier). Le système suit l’identifiant d’entité à travers tous ces appels,³ et iOS 27 étend l’histoire au matériel : une entité conforme à SyncableEntity porte un identifiant cohérent entre les appareils d’un utilisateur, si bien que Siri peut passer une conversation portant sur le même objet de l’iPhone au Mac puis à la Watch.⁸ MCP est lui-même un protocole à état, doté d’une gestion de cycle de vie, et Streamable HTTP prend en charge des identifiants de session pour la continuité de connexion, mais l’identité durable du domaine reste une affaire de serveur ; il n’existe pas d’équivalent, au niveau du protocole, aux identifiants AppEntity sur lesquels un modèle hôte pourrait s’appuyer d’une session à l’autre. MCP propose les resources pour les données de référence persistantes, et la spécification 2025-11-25 ajoute des tasks expérimentales pour suivre des requêtes durables, mais l’identité des objets du domaine demeure une responsabilité côté serveur plutôt qu’un contrat de premier ordre du protocole.⁴⁶ La discipline sous-jacente est celle qui s’applique dans la couche de données de l’app elle-même : des identifiants stables qui survivent au processus, traités pour SwiftData dans la discipline de schéma.

Latence et batterie. Le corps perform() d’un App Intent s’exécute dans le contexte de l’app ou d’une extension d’app, sur l’appareil. Tout usage du réseau vient du code propre à l’app ou de la couche Apple Intelligence/Siri environnante, pas du contrat d’intent lui-même. Une action typée, sur l’appareil, qui renvoie un résultat typé, est rapide dans le cas courant. Les outils MCP, même locaux, passent par un cadrage JSON-RPC sur stdio avec une frontière de processus distincte, et les outils MCP distants coûtent des allers-retours HTTP. Le budget de latence n’est pas le même. Un App Intent note 250 ml peut s’achever dans la fenêtre d’un tour de parole avec Siri. Un outil MCP distant peut devenir le goulot d’étranglement d’une session Claude Code.

Surface de rendu. Les App Intents renvoient des résultats qu’Apple Intelligence rend dans l’interface du système : une bannière sur l’écran verrouillé, une réponse de Siri, une sortie de Shortcuts, un résultat Spotlight. L’app ne maîtrise pas la façon dont le résultat se présente. Les outils MCP renvoient des blocs de contenu (texte, images, audio, ressources embarquées ou contenu structuré) que le modèle hôte lit et dont il décide de la présentation. Une session Claude Code pourra citer le résultat au développeur, le résumer ou l’injecter dans un appel suivant. La décision de rendu se joue au niveau du modèle.

Découvrabilité. Apple Intelligence rend les App Intents disponibles dès l’installation ; la donation et l’indexation des App Shortcuts font remonter les intents dans les recherches Spotlight et les suggestions de Siri en fonction du comportement de l’utilisateur, et les mises à jour de l’app comme les entités dynamiques ajustent la surface au fil du temps. L’utilisateur ne tape jamais un nom d’outil. Les hôtes MCP lisent les outils au démarrage de la session ; c’est l’utilisateur (ou le prompt système) qui décide des outils que le modèle peut voir. Côté MCP, la découverte est une configuration explicite ; côté App Intents, c’est une inférence implicite du système.

Les deux protocoles divergent sur l’identité, la latence, le rendu et la découverte : quatre propriétés qui découlent d’une seule distinction fondamentale. Les App Intents servent un agent de niveau système que l’utilisateur n’a pas configuré. MCP sert un agent de niveau session que le développeur, lui, a configuré. Appelants différents, obligations différentes.

La règle de routage

La carte des capacités d’une app dotée des deux protocoles ressemble à ceci :

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

La règle de routage tient en trois questions, dans l’ordre.

La capacité est-elle quelque chose que l’utilisateur demanderait à Siri ou invoquerait depuis Shortcuts ? Si oui, la capacité a besoin d’un App Intent. Note 250 ml d’eau, Démarre une méditation, Ajoute des bananes à ma liste, Combien je pesais hier sont des intents parce que l’utilisateur pourrait les dire à voix haute, les taper dans Spotlight ou les enchaîner dans Shortcuts. L’App Intent n’est pas optionnel pour ces capacités ; rien d’autre ne vous mène à la surface d’agent maison d’Apple Intelligence.

La capacité est-elle quelque chose qu’un agent externe devrait pouvoir piloter ? Si oui, la capacité a besoin d’un outil MCP. Ajouter un article à la liste de courses depuis une session Claude Code, Lire l’état de Get Bananas dans le contexte d’un agent Cursor, Déclencher un workflow depuis un LLM distant utilisateur d’outils sont des outils MCP, parce que l’appelant n’est pas Apple Intelligence ; l’appelant est le LLM que le développeur a branché. L’outil MCP peut envelopper la même fonction Swift de la couche de domaine que celle qu’appelle l’App Intent, mais la surface du protocole est du JSON-RPC sur le transport choisi par le développeur.

La capacité doit-elle survivre à une session unique, avec une identité stable et connue du système ? Si oui, la voie des App Intents est le choix naturel, car le système vous offre gratuitement l’identité AppEntity, la prise en charge des requêtes et une sémantique de persistance. Si non, l’outil MCP peut renvoyer un bloc de contenu, laisser l’identité durable à la discrétion du serveur et s’épargner le coût de la modélisation d’entités.

La plupart des capacités non triviales d’une app tombent dans la colonne les deux. Une capacité de journalisation de l’eau dans Water possède un AppIntent (pour que Siri puisse prendre la dictée) et un outil MCP (pour qu’une session Claude Code puisse compléter les données depuis un journal exporté). Les deux voies partagent une fonction Swift ; la fonction ignore quel appelant l’a invoquée.⁵

Dans le code, la forme se présente comme une méthode de domaine et deux enveloppes d’adaptateur qui l’appellent toutes les deux :

// Domain layer (Swift, no protocol assumptions)
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 1: App Intent (Apple Intelligence / Siri / Shortcuts)
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)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// 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)")

Les deux adaptateurs ne se ressemblent pas parce que leurs appelants diffèrent. La fonction qu’ils appellent, elle, est la même.

Ce qui reste dans l’app

Un petit ensemble de capacités, important malgré tout, doit rester privé à l’app. Les router vers l’un ou l’autre protocole est une erreur.

Les capacités d’état d’interface. « Ouvre le troisième onglet », « descends tout en bas », « surligne cette ligne » ne sont pas des opérations de domaine. Ce sont des primitives d’interaction. Les App Intents en couvrent une partie via OpensIntent et Shortcuts, mais le genre s’y prête mal ; l’utilisateur veut généralement un résultat, pas une navigation. La prise en charge de la navigation d’interface par MCP est encore pire : le modèle ne pilote pas un écran, il pilote un outil.

Les capacités qui exigent la présence physique d’une personne. Prise de photo, authentification biométrique, saisie de données personnelles sensibles, tout parcours qui oblige l’utilisateur à regarder l’écran et à toucher. Le CameraCaptureIntent d’Apple existe pour les parcours d’appareil photo, mais l’intention de conception est de lancer une activité de capture au premier plan, pas d’accorder à un agent un accès en arrière-plan à la caméra. La règle honnête pour les deux protocoles : caméra, biométrie et saisies sensibles doivent s’exécuter en interface au premier plan, avec confirmation explicite de l’utilisateur, et non comme des appels d’intent ou d’outil silencieux. Gardez ces capacités derrière l’interface de l’app et laissez l’agent conduire l’utilisateur jusqu’à l’écran, pas au travers.

Les travaux de fond de longue durée. Les deux protocoles se sont dotés ici de vraies primitives, et le calcul est passé de « jamais » à « avec la machinerie du protocole, délibérément ». Côté Apple, le LongRunningIntent d’iOS 27 permet à un intent de dépasser la limite système de 30 secondes en arrière-plan, à condition qu’il rapporte sa progression (le protocole affine ProgressReportingIntent), les Live Activities affichant cette progression⁸. Côté MCP, la spécification 2025-11-25 ajoute des tasks expérimentales pour les requêtes durables, avec interrogation périodique et récupération différée du résultat, promues en extension Tasks dans la release candidate du 2026-07-28⁶⁷. La frontière honnête, désormais : servez-vous de ces primitives quand l’appelant a lancé le travail et compte le suivre ; gardez le travail derrière l’interface de l’app quand la « progression » attendue par un consommateur est plus riche qu’un pourcentage, ou quand un modèle hôte laisserait expirer sa chaîne de raisonnement à force d’attendre. La requête a été mise en file, voici l’écran de suivi reste la bonne valeur de retour pour tout ce qui est ouvert.

Tout ce qui touche aux données d’un autre utilisateur. Dans les deux protocoles, la frontière de confiance est l’agent appelant. Apple Intelligence s’exécute sous le compte iCloud de l’utilisateur. MCP s’exécute sous les identifiants que le développeur a branchés. Les opérations qui s’étendent à plusieurs utilisateurs (partage, accès multi-comptes, actions d’administration) ne sont sûres par aucun des deux protocoles, parce que l’identité appelante est la mauvaise identité.

Ce que je construirais autrement

Sachant la règle de routage ci-dessus, je concevrais la couche de domaine d’une app Swift comme je conçois aujourd’hui les API à la frontière d’un service. Les méthodes de domaine prennent des entrées typées et renvoient des sorties typées, sans aucune hypothèse de protocole cuite dedans. Les App Intents enveloppent finement les méthodes de domaine avec le schéma @Parameter et la colle perform(). Les outils MCP enveloppent finement ces mêmes méthodes de domaine avec un schéma JSON et le cadrage stdio. Les deux protocoles sont de fins adaptateurs ; le travail se trouve dans le domaine.

Deux conséquences en découlent.

L’identité de l’appelant relève du domaine, pas du protocole. Le corps de l’App Intent reçoit des paramètres résolus par le système et s’exécute dans un contexte où l’utilisateur est passé par le parcours d’invocation d’intent du système. Le corps de l’outil MCP reçoit les identifiants que l’hôte a arrangés. Tous deux les transmettent à la méthode de domaine sous la forme d’un argument caller explicite. La méthode de domaine applique l’autorisation, les demandes de confirmation et toutes les autres invariantes du domaine. Aucun des deux protocoles n’a le droit de faire comme si l’appelant était l’utilisateur.

Les deux adaptateurs exposent le même jeu d’affordances. Le choix des capacités à exposer à tel ou tel appelant est consigné dans deux manifestes, et non éparpillé dans du code de protocole. Ajouter une capacité, c’est une méthode de domaine, deux enveloppes d’adaptateur, deux entrées de manifeste. Retirer une capacité est symétrique. La matrice ci-dessus devient un vrai fichier.

La frontière de la plateforme Apple pour les prochaines années n’est pas de choisir un protocole. La frontière, c’est de traiter les deux comme des contrats orthogonaux qui se composent sur la même couche de domaine. Les agents d’Apple Intelligence ont un jeu d’obligations envers l’utilisateur (ils s’exécutent sur l’appareil, ils parlent Siri, ils rendent via le système). Les agents LLM externes ont un autre jeu d’obligations envers le développeur (ils s’exécutent n’importe où, ils parlent JSON-RPC, ils rendent via le modèle que le développeur a choisi). Les deux méritent une surface typée vers votre app. Aucun ne mérite d’en être la seule surface.

Quand ne pas construire les deux

L’argument coupe dans les deux sens. Certaines apps ont besoin d’un protocole et pas de l’autre.

Les utilitaires purement grand public, sans surface développeur. Une lampe torche. Un identificateur de chants d’oiseaux. Un mètre ruban en réalité augmentée. L’utilisateur voudra peut-être l’invoquer via Siri (les App Intents sont utiles), mais aucun développeur ne le branchera dans un workflow LLM (MCP serait cosmétique).

Les outils purement destinés aux développeurs, sans surface utilisateur final. Un serveur MCP de formatage de code. Un outil de recherche dans un dépôt. Un inspecteur de versions de paquets. L’utilisateur, ici, c’est le développeur dans une session Claude Code ; Siri et Apple Intelligence n’ont aucun rôle.

Les apps qui ne servent bien aucune des deux classes d’agents. Les jeux très interactifs, les apps multijoueur en temps réel, les apps dont la valeur consiste à être dans l’app et à l’écran. Aucun protocole n’y convient ; la bonne réponse, c’est une excellente app et aucun contrat d’agent.

La décision n’est pas un seul ou les deux par défaut. La décision, c’est à quoi sert cette app et qui d’autre pourrait vouloir piloter son domaine. La réponse peut être aucun, un seul ou les deux. Le coût d’en construire un est faible si la couche de domaine est bien taillée. Le coût de construire les deux, par-dessus cette couche de domaine, est faible lui aussi. Le coût de ne pas en construire un alors que le cas d’usage l’exige, c’est l’absence complète de la capacité sur cette surface d’agent.

Ce que ce motif implique pour la pile Apple sous iOS 26+

Deux enseignements.

1. Traitez les App Intents et MCP comme des contrats orthogonaux sur le même domaine, et non comme des protocoles concurrents. Apple Intelligence, Siri, Shortcuts et Spotlight forment une classe d’appelants aux obligations de niveau système. Claude, Cursor, ChatGPT et les autres forment une seconde classe d’appelants aux obligations de niveau session. Les deux méritent un accès typé. La couche de domaine en dessous, elle, ne change pas.

2. La règle de routage porte sur qui appelle, pas sur ce qui s’exécute. L’App Intent et l’outil MCP peuvent appeler la même fonction Swift. Ils diffèrent par les obligations que porte l’appelant, par le rendu qu’ils reçoivent en retour et par la persistance qu’ils attendent. Soignez la fonction ; gardez les couches de protocole minces.

Le cluster Apple Ecosystem au complet : les App Intents typés pour Apple Intelligence, les serveurs MCP pour les agents multi-LLM, les Live Activities pour la machine à états de l’écran verrouillé, les motifs Liquid Glass pour la couche visuelle, et la livraison multiplateforme pour la portée inter-appareils. Le hub se trouve dans la série Apple Ecosystem. Pour le contexte plus large d’iOS avec des agents IA, voyez le guide du développement d’agents iOS.

Questions

Quand construire un App Intent plutôt qu’un outil MCP pour la même capacité ?

Construisez un App Intent quand la capacité doit atteindre Apple Intelligence, Siri, Shortcuts ou Spotlight. Construisez un outil MCP quand la capacité doit atteindre des LLM externes (Claude, ChatGPT, agents dans Claude Code ou Cursor). Pour les capacités de domaine qui doivent servir les deux classes d’appelants, construisez les deux, sous forme de fins adaptateurs au-dessus d’une méthode de domaine Swift partagée.

Les App Intents et les serveurs MCP se font-ils concurrence ?

Non. Les App Intents sont la voie vers la pile d’agents maison d’Apple ; MCP est la voie vers tous les autres LLM. Apple Intelligence n’appelle pas d’outils MCP, et les agents LLM externes ne peuvent pas invoquer directement des App Intents (ils passent par le système). Les deux protocoles servent des classes d’appelants différentes, avec des modèles de confiance différents, des budgets de latence différents et des surfaces de rendu différentes.

Une même app peut-elle exposer son domaine par les deux protocoles ?

Oui, et la plupart des apps non triviales qui visent une portée d’agent complète devraient le faire. Get Bananas (traité dans l’article sur le serveur MCP) et Water (traité dans l’article sur les App Intents) en sont des exemples précoces. Le motif consiste en une couche de domaine en dessous, avec des adaptateurs App Intent et des adaptateurs d’outils MCP au-dessus. Les deux adaptateurs appellent les mêmes fonctions Swift.

Quel état Apple Intelligence suit-il que MCP ne suit pas ?

Apple Intelligence suit l’identité AppEntity d’un appel à l’autre, d’une session à l’autre et à travers les redémarrages, et, avec le SyncableEntity d’iOS 27, entre les appareils de l’utilisateur⁸. Le modèle d’entités donne au système des références persistantes que l’utilisateur peut enchaîner d’un intent à l’autre. MCP est lui-même un protocole à état, doté d’une gestion de cycle de vie et d’identifiants de session en Streamable HTTP, mais l’identité durable du domaine relève d’une responsabilité côté serveur et non d’un contrat de premier ordre du protocole ; le modèle hôte n’obtient pas de la surface du protocole d’identifiant équivalent à une AppEntity. La notion de resources de MCP et les tasks expérimentales de la spécification 2025-11-25 prennent en charge les données de référence persistantes et les requêtes durables, mais toutes deux opèrent à cette même couche détenue par le serveur⁶.

Y a-t-il des capacités que je ne devrais exposer par aucun des deux protocoles ?

Oui. Les capacités d’état d’interface (ouvre cet onglet, descends jusqu’ici), les capacités qui exigent la présence physique d’une personne (prise de photo, authentification biométrique, saisies sensibles) et les opérations qui s’étendent aux données de plusieurs utilisateurs doivent rester derrière l’interface de l’app : aucun des deux protocoles ne porte les signaux de confiance nécessaires pour opérer sans risque d’un utilisateur à l’autre. Les travaux de fond de longue durée sont l’exception qui a bougé : le LongRunningIntent d’iOS 27 et l’extension tasks de MCP leur donnent désormais de vraies primitives, alors exposez-les délibérément par cette machinerie et ne gardez derrière votre propre interface que le travail ouvert, plus riche qu’une barre de progression.

Références