Intégrer Claude aux Apple Foundation Models

 (platform.claude.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Il s’agit d’un package Swift qui connecte Claude comme modèle côté serveur au framework Foundation Models d’Apple, permettant aux développeurs d’appeler Claude via le même chemin de code que pour les modèles on-device d’Apple
  • Grâce au protocole LanguageModel introduit par Apple à la WWDC 2026, il devient possible, avec une API standard unique, de prototyper sur un modèle on-device puis de ne déléguer que les tâches complexes à un modèle cloud, dans une architecture hybride
  • Le point clé est la substituabilité du fournisseur : sans toucher à la logique de session, il suffit de changer la dépendance Swift Package pour passer d’Apple à Claude ou Gemini
  • Ce package, publié par Anthropic sous licence Apache 2.0, constitue le premier exemple concret fonctionnel de cette idée selon laquelle « n’importe quel backend peut être connecté »
  • Les requêtes vont directement de l’app à l’API Claude et Apple n’est pas sur le trajet : l’entreprise ne voit ni les prompts ni les réponses, et les coûts sont facturés directement au compte Anthropic

Pourquoi c’est important

  • Jusqu’ici, intégrer un modèle de langage dans une app iOS supposait de souscrire à une API cloud distincte, gérer des clés, payer à l’usage par token et envoyer tous les prompts hors de l’appareil. À la WWDC 2026, Apple a apporté une réponse à cette friction de longue date
  • Le framework Foundation Models s’étend pour appeler via une API Swift native unique aussi bien les modèles on-device d’Apple Intelligence que Private Cloud Compute ou des clouds tiers comme Claude et Gemini
  • Anthropic a publié un package Swift implémentant ce nouveau protocole. Il sert à transmettre la main depuis les modèles on-device d’Apple vers Claude afin de traiter des workflows plus complexes

Ce qui change pour les développeurs

  • Changer de fournisseur sans modifier le code

    • Après avoir prototypé une app avec un modèle on-device d’Apple, il devient possible de router les requêtes complexes vers Google Gemini ou Anthropic Claude, ou de basculer entre eux, simplement en mettant à jour la dépendance Swift Package Manager, sans modifier la logique de session ni le reste du code de l’app
    • Les modèles on-device servent aux tâches rapides et locales comme le résumé ou l’extraction, avec transfert vers Claude uniquement lorsqu’il faut du raisonnement multi-étapes, de la génération de code, de la recherche web ou de l’exécution de code
    • Dans les deux cas, c’est la même API LanguageModelSession, et il suffit de changer l’argument model: pour basculer

  • Handoff basé sur les types

    • Après ajout au projet et connexion avec une clé API Anthropic, si l’on transmet à une requête Claude la sortie typée d’un modèle on-device d’Apple, le package gère ensuite le streaming, l’appel d’outils et les réponses structurées jusqu’aux vues SwiftUI
    • L’utilisation est suffisamment simple pour retourner des valeurs Swift typées en seulement trois lignes de code grâce à la génération guidée

Structure de confidentialité et de coûts

  • Les requêtes sont envoyées directement de l’app à l’API Claude, et Apple n’est pas dans le chemin de la requête : l’entreprise ne voit ni les prompts ni les réponses
  • L’usage est facturé directement au compte Anthropic selon les tarifs standards de l’API
  • L’app décide elle-même, à chaque session, si elle utilise Claude ou un modèle on-device d’Apple

Vue d’ensemble

  • Apple prévoit de faire passer en open source cet été le framework Foundation Models, son API Swift native pour les modèles on-device lancée en 2025, et avec le nouveau protocole LanguageModel, pratiquement tous les modèles — qu’ils soient d’Apple ou de fournisseurs distants — peuvent alimenter LanguageModelSession derrière une API Swift unique
  • Avec ClaudeForFoundationModels, Anthropic fournit un exemple concret de ce principe de « connexion à n’importe quel backend » en matérialisant le pattern adaptateur
  • Avec le système Dynamic Profiles, Apple permet aux apps de changer de modèle, d’outils et d’instructions au milieu d’une session, et présente cela comme la base de workflows multi-agents
  • Cette intégration reste toutefois en bêta : elle exige iOS, iPadOS, macOS, visionOS, watchOS 27 et Xcode 27, et l’API peut encore évoluer avant la sortie officielle

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Hacker News

  • Apple est en train de contrôler l’expérience utilisateur tout en faisant des LLM une commodité
    C’est une stratégie très cohérente pour une entreprise de hardware : continuer à vendre les meilleures machines pour utiliser l’IA, et cela semble être un bon choix

    • Benedict Evans avait peut-être raison au final. Les modèles de frontière ressemblent de plus en plus aux opérateurs télécoms des années 90
      Ils investissent des milliards de dollars dans l’infrastructure, mais ce sont d’autres entreprises, plus haut dans la pile, qui captent la valeur
    • C’est un peu distinct de l’idée de contrôle de l’expérience utilisateur, mais c’est ce que je préfère comme conséquence de l’IA. Pendant des décennies, les entreprises ont enfermé leurs services derrière des murs et imposé des interfaces nulles, puis en l’espace des 12 derniers mois, MCP est apparu partout et on peut tout utiliser via des interfaces de chat en ligne de commande
      Les entreprises qui ne s’adaptent pas finiront par se faire marteler par des scrapers web DIY basés sur l’IA bricolés par les utilisateurs, puis n’auront d’autre choix que de céder
    • Je ne suis pas sûr que la meilleure machine pour utiliser l’IA soit vraiment la bonne formulation ici. Ces modèles tournent encore côté serveur, non ?
    • Le fait que l’IA finisse par être intégrée au niveau du système d’exploitation est évident depuis des années. Apple l’avait déjà compris lorsqu’ils ont présenté Apple Intelligence pour la première fois
      Dire qu’ils transforment les LLM en commodité est sans doute juste, mais cela reste une fonctionnalité orientée utilisateur qu’ils peaufinent depuis plusieurs années
    • Maintenant, il ne reste plus qu’à transformer le hardware lui aussi en commodité

  • Un package Swift qui permet d’utiliser Claude comme modèle de langage côté serveur dans Apple's Foundation Models framework : j’espérais l’inverse. J’aurais aimé que les fonctionnalités existantes de Claude Code puissent somehow tourner en local sur le Neural Engine de mon laptop
    Avec une puce M2 et 8 Go de RAM, c’est un rêve vain, mais j’y ai cru un instant

    • Il suffit de regarder cette session WWDC. Bien sûr, ça ne peut pas rivaliser avec les modèles de frontière et 8 Go restent bien trop limités, mais Apple a quand même fait une démo de MLX + OpenCode
      https://developer.apple.com/videos/play/wwdc2026/232/
      https://www.youtube.com/watch?v=wykPErJ8M-8
    • Avec OpenCode ou Pi en streaming depuis SSD, on pourrait techniquement avoir toutes les fonctionnalités. Ce serait juste insupportablement lent
    • La plupart des modèles de frontière pour le code semblaient nécessiter entre 300 Go et 1 To pour exploiter toutes leurs capacités
    • Claude Code peut littéralement interroger n’importe quel endpoint voulu, tant qu’il existe une API compatible, via des variables d’environnement
    • Si le cloud était en fait le iCloud privé de l’utilisateur, cela pourrait être acceptable. Si l’utilisateur paie le coût et que cela s’exécute près des serveurs Apple qui stockent déjà ses iPhotos, ce pourrait être une solution très élégante
      Mais en pratique, on se retrouve avec Claude sans même savoir où il est hébergé. Ça peut être dans un datacenter de X-AI, quelque part chez Amazon, personne n’en sait rien

  • Ce n’est pas spécifique à Claude. Les développeurs peuvent aussi créer des apps qui appellent les modèles Gemini de Google hébergés sur serveur
    À la WWDC, Apple a annoncé qu’ils ouvriraient Foundation Models framework à des fournisseurs tiers de modèles cloud. À partir d’iOS 27, macOS 27, iPadOS 27, visionOS 27 et watchOS 27, les fournisseurs de modèles pourront implémenter le nouveau protocole public LanguageModel pour fournir une interface commune pour l’inférence de modèles. Google a permis d’utiliser les modèles Gemini dans Foundation Models framework via le Firebase Apple SDK
    Cela permet une expérience de développement entièrement native. Les modèles Gemini hébergés dans le cloud peuvent se connecter directement à Foundation Models framework via la même API, et comme les modèles Apple sur appareil et les modèles Gemini hébergés dans le cloud se trouvent derrière une surface d’API commune, il devient facile de basculer entre inférence locale et inférence cloud selon le cas d’usage
    https://blog.google/innovation-and-ai/technology/developers-...

    • Le point important, c’est qu’Apple a simplement rebaptisé l’API compatible OpenAI en language model protocol, et avant qu’on soit tous maudits par cette expression horriblement longue, il faut vite se mettre d’accord là-dessus

  • Je suis content qu’Apple ait introduit ce type d’abstraction, mais ma principale inquiétude concerne les modèles locaux
    Par exemple, même si l’on veut utiliser Gemma4, du point de vue de l’utilisateur, si 10 apps téléchargent chacune le même modèle, le téléphone gonfle inutilement
    Je n’ai pas encore compris si Apple a prévu un moyen permettant à plusieurs apps d’utiliser le même modèle présent sur l’appareil. Il faut que ce soit possible sans bidouilles compliquées de namespace ou de permissions
    Je n’ai rien vu qui laisse entendre cela

    • Je pense que c’est précisément ce qu’Apple cherche à éviter. Leur idée semble être que, si l’on a besoin d’intelligence sur l’appareil, « le meilleur modèle est déjà celui qui se trouve sur l’appareil », et que si l’on a besoin de quelque chose de plus spécifique, alors un adaptateur, c’est-à-dire du fine-tuning/LoRA, est la meilleure option
      C’était faux tant que les modèles embarqués étaient très en retard, mais à long terme cela peut encore s’avérer juste
      Plusieurs apps que j’utilise peuvent avoir besoin de Gemma 4 E4B, mais j’utilise des dizaines d’apps et les développeurs peuvent choisir parmi des centaines de modèles. Un cache partagé réduirait un peu l’empreinte si certains se recoupent, mais le problème de fond resterait entier. Si chaque app choisit son modèle, l’explosion de l’espace disque et du swapping mémoire est inévitable
      Il est probablement préférable que le fabricant de l’appareil intègre une valeur par défaut. Il ne s’agit pas d’empêcher l’usage d’autres modèles, mais un défaut partagé pourrait être, pour 99 % des apps, la meilleure solution à la fois pour les développeurs et pour l’expérience utilisateur
      Le plus gros gain de performance vient du fait que le modèle est déjà chargé en mémoire, et le modèle par défaut a bien plus de chances de rester chaud
      Le « meilleur modèle » est généralement, compte tenu de la RAM et de la puissance de calcul, « le meilleur modèle pour cet appareil ». Un développeur ne peut pas tester tous les appareils, mais Apple le peut et le fera
      Chaque modèle doit être optimisé pour le matériel. Ce qui tourne sur l’ANE, Metal ou le CPU est important, et le modèle par défaut sera optimisé
      Si l’on a besoin d’un modèle personnalisé, LoRA est probablement la meilleure option. Cela fait environ 30 MB et permet de conserver tous les avantages ci-dessus
      On peut soutenir qu’il faudrait permettre de remplacer le modèle par défaut, mais cela relève davantage d’un idéal à la Linux que d’Apple, donc je doute qu’on voie cela en pratique. Et il y a aussi de vrais inconvénients. Que ce soit voulu ou non, les prompts finissent par être optimisés pour le modèle visé par le développeur, donc remplacer le modèle système par défaut peut dégrader la qualité de toutes les apps
    • C’est une bonne occasion pour Apple de fournir un protocole universel d’ID de modèle uniques ainsi qu’un espace de stockage partagé afin que les développeurs puissent enregistrer leurs modèles
    • Il faut regarder « Bring an LLM provider to the Foundation Models framework »
      https://developer.apple.com/videos/play/wwdc2026/339
    • Les apps peuvent utiliser le modèle embarqué sur l’appareil fourni par le système via le même framework et la même API. En revanche, il n’existe aucun mécanisme pour dédupliquer entre apps les modèles personnalisés
    • C’est justement ça, foundation models. AICore sur Android fonctionne de la même manière en utilisant Gemma en interne, et les apps interrogent le LLM pour obtenir une réponse au lieu d’embarquer leur propre modèle

  • Je me demande si Apple essaie d’amener les développeurs à utiliser les LLM via sa propre couche d’abstraction d’API. Cela pourrait servir à faciliter une transition fluide le jour où Apple lancera son propre LLM
    Il me semble avoir entendu dire qu’Apple dépense beaucoup pour l’entraînement et que cela pourrait somehow être lié à Siri ou à l’Apple AI actuelle. Ou alors ce n’est qu’une fonction de confort pour les développeurs ; je me demande s’il y a une autre intention derrière

    • Apple a mis en place des mécanismes assez ingénieux pour protéger les données des utilisateurs. J’ai récemment dû travailler sur le suivi in-app, et le système qui masque les détails des utilisateurs dans des cohortes anonymisées via SKAN et la confidentialité différentielle avant de transmettre les événements de tracking à des plateformes tierces était mieux conçu que je ne l’attendais
      Si l’on accorde de l’importance à la vie privée, il y a un intérêt à ce qu’Apple s’interpose
    • Il s’agit d’une nouvelle prise en charge du framework incluse dans reality/mac/iPad/watch/tv/iOS 27. Ils ont dit qu’ils l’ouvriraient en open source plus tard cette année, donc cela devrait aussi être exploitable si l’on déploie Swift côté backend
      L’idée centrale de ce framework est qu’avec une même API, on peut viser le modèle embarqué sur l’appareil, le modèle en ligne hébergé par Apple appelé Private Cloud Computer, ou encore son propre shim pour n’importe quel modèle en ligne hébergé ailleurs
      Cela évite d’avoir à construire sa propre couche d’abstraction du type « ceci avec le modèle local, cela avec Claude » ou d’intégrer soi-même les API d’Anthropic/OpenAI, puisque les appels peuvent être routés dynamiquement via l’API système vers différents modèles ou types de fournisseurs
      Il y a aussi plusieurs aspects pratiques et particularités, comme l’abstraction centralisée des appels d’outils, ou la possibilité de changer dynamiquement de fournisseur ou de modèle au cours d’une session tout en continuant le même transcript
    • D’un point de vue cynique, ou réaliste, cette couche d’abstraction ressemble à une manière typiquement Apple de faire en sorte que l’utilisateur attribue les mérites à Apple Intelligence, même si le LLM réel est fourni par une autre entreprise
    • C’est une lecture sombre, mais pas totalement injustifiée. Apple pourrait plus facilement prélever un paiement sur les modèles fournis par d’autres sociétés et, si elle le souhaite, collecter des données sur la manière dont les utilisateurs emploient des modèles tiers pour constituer un jeu de données destiné à entraîner son propre modèle
      Comme cette API ne fonctionne que sur les appareils Apple, cela fragmente aussi le marché et enferme davantage les utilisateurs, puisque les développeurs doivent adopter ce système pour que cela fonctionne correctement sur iOS
    • Il existe déjà, via ce framework, un modèle embarqué sur l’appareil que les développeurs peuvent utiliser. Claude n’est qu’un modèle supplémentaire qui vient s’y ajouter

  • Apple semble se préparer à l’amélioration de ses modèles embarqués, ce qui est logique si l’on pense au fait qu’ils ont obtenu l’accès à Gemini
    Si les développeurs écrivent tout leur code d’appel à des LLM externes avec ça, ils pourront facilement remplacer les points d’appel individuels quand les modèles d’Apple deviendront plus compétents et couvriront davantage de cas d’usage. L’expérience utilisateur des apps s’améliorera, et les coûts de facturation des développeurs, sur lesquels Apple ne touche pas de commission, diminueront aussi

    • Autrement dit, comme ça ne rapporte pas d’argent, il est peu probable que cela arrive. Apple aurait plutôt intérêt à créer de nouveaux forfaits IA et IA-lite auxquels les gens pourraient s’abonner
      Apple est une entreprise, et on sait tous ce qui préoccupe une entreprise, donc l’utopie où des modèles locaux tournent sur le téléphone semble peu probable
    • Je ne vois pas en quoi utiliser Gemini ferait progresser les modèles embarqués
    • L’expérience utilisateur est une autre manière de dire construction d’écosystème, et c’est probablement ce qu’Apple fait mieux que ses concurrents. Le fait d’avoir aussi le hardware qui va avec ne leur nuit pas non plus
      Ce n’est pas pour rien que Microsoft et Nvidia font équipe

  • Je me demande comment cela s’utilise concrètement dans un logiciel distribué aux utilisateurs. Demander aux utilisateurs de créer et saisir eux-mêmes une clé API représente une barrière bien trop élevée pour offrir une bonne expérience utilisateur

    • Une barrière encore plus grande, c’est de faire accepter à des utilisateurs ordinaires, c’est-à-dire non développeurs, une tarification au token
      Une structure du type « payer une somme dont on ne sait pas combien coûtera une seule question, sans garantie d’obtenir la réponse voulue, puis devoir repayer pour continuer » n’est pas attrayante pour la plupart des gens qui ne sont pas des joueurs. Expliquer à l’utilisateur moyen qu’un simple « merci » à la fin d’une longue conversation peut coûter cher à cause du contexte est encore plus difficile à faire accepter
      Le fait que le coût des tokens fasse le yoyo n’aide pas non plus. Les utilisateurs ordinaires ont besoin d’un coût fixe et n’ont pas envie de dépenser de l’énergie à suivre en permanence l’évolution du monde de l’IA. Des problèmes du genre « le mois dernier, mon abonnement durait bien plus longtemps » ne vont pas dans le bon sens
      Dans la plupart des cas, je pense qu’Apple a raison de considérer que les LLM locaux sont l’avenir
    • C’est vraiment le cas. J’exploite allihat.com, et cela semble toujours être la seule extension Safari qui communique avec Claude, avec une demande assez réelle. Mais les utilisateurs doivent eux-mêmes saisir leur foutue clé API Claude
      Je ne comprends toujours pas complètement les conditions d’Anthropic. On peut bien saisir quelque chose comme setup-token Set up a long-lived authentication token (requires Claude subscription), mais ça ressemble à un piège. Je ne sais pas qui utilise ça, ni si le simple fait de l’utiliser où que ce soit ne constitue pas immédiatement une violation des conditions
      Sur allihat.com, si l’utilisateur ne veut pas utiliser de clé Claude, je lui permets d’utiliser à la place le modèle local d’Apple, et le taux de conversion vers des utilisateurs payants a augmenté d’environ 3x. Mais bien sûr, ce n’est pas un substitut à Claude. J’espérais qu’Apple mette en place un mécanisme servant de proxy Claude à ma place, pour que je n’aie pas moi-même à faire passer ça par mon serveur afin de gérer l’usage de l’API Claude
    • En production, il est indiqué d’acheminer les requêtes via son propre backend avec .proxied
      Apple fournit des modèles d’IA gratuits via ses propres serveurs aux développeurs ayant moins de 2 millions de téléchargements https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
    • Comme avant, il suffit de faire transiter les requêtes via votre propre backend
    • Ce n’est pas l’utilisateur qui fournit une clé API. La documentation explique comment configurer un proxy backend

  • Je comprends que la formule « les requêtes vont directement de l’app à l’API Claude, Apple n’est pas sur le chemin et ne voit ni les prompts ni les réponses » est formulée du point de vue du développeur
    Mais du point de vue du consommateur, c’est juste ridicule

    • Pourquoi ?

  • Microsoft a d’abord cassé le jeu en mettant dans les conditions de Copilot que « Copilot est fourni à des fins de divertissement uniquement », puis en ajoutant aussi pour Copilot dans Excel un avertissement disant d’« éviter d’utiliser COPILOT pour les tâches nécessitant exactitude ou reproductibilité, ou ayant un impact juridique, réglementaire ou de conformité »
    Puis Apple refuse discrètement d’entrer dans la danse sans investir des dizaines de milliards, voire des centaines de milliards, pour créer un LLM concurrent. Bien sûr, ils revendent Claude pour les plus naïfs ou s’appuient sur Gemini, mais Apple sait très bien dans quelle situation on est
    https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
    https://support.microsoft.com/en-US/Excel/copilot-function

  • L’agent de code est déjà en soi une couche imposée, et maintenant on en ajouterait encore une autre. Les agents de code donnent souvent l’impression d’être des vendor managers de SSII des années 90
    Ils promettent tout et n’importe quoi au client, puis mettent la pression sur le pauvre prestataire pour qu’il livre. Les agents de code consomment 10x plus de tokens, comme l’écart entre ce que la SSII facturait au client et ce qu’elle reversait au contractuel. Test simple : une tâche pour laquelle le modèle dépasse la longueur de contexte via un agent de code fonctionne très bien si on la lui demande directement
    Les couches sont un luxe, et elles suppriment le contrôle et la transparence

    • Quand je construirai un agent de code, je n’utiliserai pas ça