Siri AI va-t-elle devenir un agent IA ? Apple Intelligence, JSON, API, tool calling et App Actions

Réponse courte : elle agira, sans devenir un agent ouvert

Gardez la définition d’ingénierie, pas les adjectifs de keynote. Un agent a un but, une perception et une action : le modèle choisit l’outil et les arguments ; le runtime exécute et réécrit l’observation. L’ancienne Siri entendait surtout une phrase et ouvrait un raccourci ou une capacité système, presque sans boucle « regarder le résultat, puis décider ». Siri AI 2026 commence à fermer cette boucle : elle choisit une action dans le catalogue App Intents, résout « enregistre ceci dans Notes » avec le contexte à l’écran, et passe une entité à l’Intent suivant d’une app à l’autre. Par le comportement, elle devient un agent de système.

Ce n’est toujours pas l’agent ouvert que vous installez dans un IDE ou un bureau support. La différence, ce n’est pas l’intelligence du modèle, c’est qui trace la frontière des outils. Le catalogue d’un agent ouvert est le vôtre : OpenAI tools[], Anthropic tool_use, MCP tools/list ; les arguments sont presque toujours du JSON. Le catalogue de la Siri système, ce sont les Intents déjà déclarés sur l’appareil, de préférence calés sur un App Schema ; les paramètres sont des types Swift, pas un blob à parser. La clôture vie privée diffère aussi : l’appareil et Private Cloud Compute décident quel contexte peut sortir — pas une ligne de prompt système « tu peux lire Contacts ». Traiter Siri comme « un autre ChatGPT auquel accrocher des fonctions » produit la mauvaise migration : supprimer App Intents, ou appeler l’API Gemini depuis iOS « pour s’aligner sur Cupertino ».

Une phrase : Siri AI deviendra un agent dans le système, pas un runtime d’agent que vous possédez. Vous contrôlez la forme des actions exposées, et le JSON une fois ces actions tombées en HTTP. Les deux sections suivantes séparent produit et contrat, pour que « elle sait faire » ne se lise pas « boucle d’outils ouverte ».

Les trois acquis réels de Siri AI en 2026

La doc développeur Apple et la ligne WWDC26 plient le travail App Intents de Siri en trois capacités. Elles expliquent pourquoi cela ressemble à un agent — et pourquoi vous écrivez encore des Intents au lieu de coller un JSON Schema et de déclarer le travail fini.

1. Atteindre votre contenu : modelez les objets métier en App Entities, calez-les sur un Entity Schema, et contribuez-les à l’index sémantique Spotlight. Alors seulement Siri trouve « cette commande payée » dans le contexte personnel, au lieu d’ouvrir l’accueil.
2. Agir : une fois un Intent calé sur un Intent Schema (commerce, photos, communication et autres domaines pré-entraînés), le langage naturel peut atteindre perform() sans liste de phrases par formulation. Ce sont les app actions que les pages officielles répètent.
3. Lire l’écran : annotez les vues en entités avec View Annotations ou NSUserActivity pour que l’on puisse dire « ceci » et « cela ». Les requêtes inter-apps commencent souvent ici, pas dans un planner que vous avez écrit.

Empilez les trois et les utilisateurs sentent que « Siri sait faire ». Les développeurs sentent que leur app est devenue la boîte à outils de l’agent système. La session WWDC26 Build intelligent Siri experiences with App Schemas fige aussi l’ordre de test : logique d’Intent isolée, puis Raccourcis pour la forme des paramètres, puis Spotlight pour l’index, et seulement ensuite Siri de bout en bout. Sauter les trois premiers et déboguer à la voix seule coûte cher.

La couche modèle bouge aussi ; n’y lisez pas un remplacement de produit. La déclaration conjointe de janvier 2026 a accroché la fondation du prochain AFM à la technologie Gemini ; en juin, Private Cloud Compute s’est étendu sur Google Cloud pour un tool-use agentique plus lourd. L’utilisateur voit encore Siri / Apple Intelligence — pas un badge Gemini, et pas Google Assistant. Pour la stratégie, voir pourquoi Apple s’appuie sur Gemini ; pour la coexistence avec l’extension ChatGPT, la comparaison à trois. Pour vous, ce qui change, c’est l’audace du modèle cloud à enchaîner des actions — pas le nom de famille de votre table de paramètres.

Trois couches : Apple Intelligence, modèles, surfaces développeur

Aplatir « Siri est devenue un agent » en une seule couche fait basculer toutes les décisions suivantes. Séparez au moins trois : le produit vu, où tourne l’inférence, et quel contrat implémente votre code.

Foundation Models est une deuxième ligne. Elle permet à une app de lancer un LanguageModelSession sur l’appareil (et sur le chemin PCC décrit), d’appeler des tools et de contraindre la génération structurée. C’est « votre app est le runtime d’agent », pas « la Siri système est l’agent et frappe votre Intent ». Beaucoup d’apps feront les deux : App Intents pour être trouvées par Siri / Spotlight / Raccourcis ; des Tools pour qu’un modèle on-device vérifie un stock ou remplisse un formulaire. Le branchement HTTP est dans comment un agent Apple atteint apps et API.

Raccourcis colle les couches. Apple Intelligence peut assembler des automatisations multi-étapes en langage naturel ; une fois App Intents adopté, vos actions rejoignent cet écosystème à côté de capacités comme Use Model. Un utilisateur peut dire « trouve les commandes payées, puis écris-les dans Notes » — l’orchestrateur reste le système, pas un planner sur vos serveurs. Chaque jeu de paramètres d’Intent doit tenir seul, car le système peut n’exécuter qu’un hop, ou les réordonner.

App Intents, App Schemas et App Actions

App Intents, ce n’est pas « ajouter de la voix à Siri ». C’est le contrat qu’une app tierce signe avec Apple Intelligence : vous déclarez le contenu offert et les actions possibles ; le système décide quand appeler. Déployé avec iOS 18 et, en 2026, alimentant à la fois Siri, Spotlight, les widgets, Raccourcis et l’agent système. Les équipes qui traitent encore App Intents comme optionnel se trompent de porte d’entrée de l’IA système.

Un App Schema est la forme pré-entraînée de ce contrat. Un Entity Schema dit que c’est une commande, une photo ou une conversation, pour entrer dans l’index sémantique. Un Intent Schema dit que c’est trouver, ouvrir ou partager, pour que le langage naturel touche l’action sans corpus de phrases à maintenir. Les macros Xcode génèrent des squelettes conformes et les vérifient à la compilation. Ratez le domaine et Siri peut encore traiter l’action comme un raccourci ordinaire, pas comme un outil préféré de l’agent. WWDC26 a aussi ajouté des Intents plus longs, l’annulation et des entités synchronisées entre appareils — plus « en boucle », toujours planifié par le système.

« App Actions » est le mot qui dérive. Sur les pages Apple, les app actions sont des capacités exposées via App Intents et exécutées par Siri AI et d’autres surfaces. Ce n’est pas le protocole historique App Actions de Google Assistant, ni les intent filters Android. Les deux produits « laissent un assistant appeler une app » ; champs, catalogues et modèles de confidentialité ne correspondent pas. Dans les docs internes, écrivez « App Intents / App Schema » et laissez « App Actions » au discours utilisateur. Mélangez les noms et un backend ira chercher un JSON-RPC façon Google qui n’existe pas.

Tool calling : agent système vs Tools in-app

Le tool calling / function calling de l’industrie est un seul mécanisme : le modèle ne touche pas la base ; il émet « appelle cette fonction avec ces arguments », et le runtime exécute. En 2026 les enveloppes diffèrent ; les arguments restent un objet JSON. Côté Siri, la même idée devient un Intent typé : le modèle système choisit findOrders, remplit email / status / limit, et entre dans perform(). Si perform() frappe votre API HTTP, vous encodez alors ces champs en JSON. Ne partagez pas un chemin « on parse et on verra » entre les deux hops.

Stockez les charges d’or à la couche intent, pas sous une marque de modèle. Le JSON ci-dessous dit seulement qui a commencé, quel schema, quelle action et quels arguments. runtime.onDevice va bien dans les journaux. Ne le mettez pas dans la validation métier — le repli on-device et le palier cloud complet doivent accepter les mêmes arguments.

{
  "source": "siri-ai",
  "schema": "commerce.findOrders",
  "intent": "findOrders",
  "arguments": {
    "email": "ada@example.com",
    "status": "paid",
    "limit": 5
  },
  "runtime": {
    "surface": "siri",
    "onDevice": false
  }
}

Les mêmes champs métier, dans un agent ouvert que vous possédez, portent une enveloppe tool_calls fournisseur. arguments est souvent une chaîne : JSON.parse d’abord, puis la même Schema. Quand Siri appelle, vous ne voyez pas cette enveloppe — seulement des paramètres typés. Le JSON réapparaît quand vous quittez l’appareil vers votre API.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "findOrders",
    "arguments": "{\"email\":\"ada@example.com\",\"status\":\"paid\",\"limit\":5}"
  }
}

Le contraste est net : le nom est findOrders des deux côtés ; les clés doivent partager une Schema. Le chemin système n’a pas d’id tool_call ; le chemin ouvert n’a pas de domaine App Schema. Ne traitez pas Gemini generateContent, OpenAI tools[] et une table de paramètres App Intent comme valeurs par défaut les uns des autres. Structured Output gouverne la réponse finale, pas les entrées de ce hop ; pourquoi séparer les fichiers est dans AI Structured Output.

JSON, API et validation locale

Plus Siri ressemble à un agent, plus les pannes aussi : hops en plus, champs optionnels remplis, énumérations folles, deux clés manquantes en repli on-device. Un modèle plus fort ne retire pas la validation ; il rend les oublis plus chers. Chaque hop sortant reste parse → Schema → règles métier.

1. Encodez les paramètres d’Intent en JSON et parsez tout de suite ; en échec, journalisez le nom d’intent et les champs bruts et renvoyez une erreur réessayable — ne jetez pas une exception Swift à l’utilisateur.
2. Fixez types, énumérations et required avec une seule Schema Draft 2020-12. Préférez additionalProperties: false pour que les clés en trop du palier cloud ne fuient pas en aval.
3. Porte métier : droits, clés étrangères, plages de dates. Ensuite seulement le service commandes. Si l’agent système réessaie, votre API doit être idempotente.

Alignez trois blobs : l’objet paramètres envoyé par Siri / Raccourcis, le body HTTP que vous émettez, l’objet réellement utilisé côté serveur. Un écart est presque toujours l’adaptateur. Dans le navigateur, utilisez le formateur JSON pour voir les champs ; Validateur JSON Schema pour figer les types ; JSON Diff pour voir les clés perdues en repli on-device face au palier cloud. Partagez les fixtures valid / missing-field / wrong-enum en CI et au débogage Siri sur appareil.

Pour aller plus loin : agents Apple et JSON, qu’est-ce qu’un agent IA, erreurs JSON générées par l’IA, MCP et JSON Schema.

FAQ

Résumé et suite

Siri AI deviendra un agent IA — derrière la clôture du système. Apple Intelligence fournit le contexte personnel, les app actions et la conscience de l’écran ; la couche modèle peut emprunter la technologie Gemini et un PCC plus lourd ; les développeurs passent encore les actions par App Intents et les boucles in-app par Foundation Models Tool. L’enveloppe JSON du tool calling ouvert n’apparaîtra pas sur la requête système. Elle apparaîtra sur votre propre API.

La suite est concrète : listez les App Schemas à adopter, écrivez les paramètres d’Intent et le body HTTP contre une seule Schema, et rejouez valid / champ manquant / mauvaise énumération dans JSONVue. Les marques de modèles bougeront. La forme des actions ne devrait pas.