Apple Foundation Models : ce que les développeurs Mac indépendants peuvent faire avec l'IA sur l'appareil

Pendant environ trois ans, chaque développeur indépendant qui voulait livrer des « fonctionnalités IA » devait prendre la même décision inconfortable. Soit payer une facture OpenAI ou Anthropic qui scale linéairement avec les utilisateurs, soit éviter les fonctionnalités IA entièrement. Le calcul pour une app à paiement unique était brutal. Quelques centimes par utilisateur par mois détruisent la marge d’une app à $9.99 à vie en quelques mois.

Le framework Foundation Models d’Apple, annoncé à la WWDC 2025 et livré dans macOS 26 (Tahoe), change le calcul. Le framework donne aux développeurs un accès programmatique au même modèle de langage sur l’appareil qui alimente les fonctionnalités Apple Intelligence sur le Mac de l’utilisateur. Le modèle fonctionne localement. Votre app ne paye pas l’inférence. L’utilisateur n’a pas besoin de clé API. Le texte ne quitte jamais l’appareil.

Cet article est une présentation pratique de ce que les développeurs indépendants peuvent vraiment faire avec le framework, ce qu’il ne fait pas bien, et ce que le changement architectural signifie pour une app Mac concentrée.

Ce que vous obtenez

Le framework expose une LanguageModelSession que vous pouvez solliciter avec du texte. Le modèle répond avec du texte, et optionnellement avec un objet structuré que vous spécifiez avec la macro @Generable. Le mode de sortie structurée est le plus utile pour la plupart des apps car il vous permet de dire « donnez-moi un JSON conforme à ce schéma » au lieu d’essayer d’analyser du texte libre.

Un flux typique ressemble à ceci :

Créer une session avec des instructions système décrivant la tâche du modèle.
Envoyer un message utilisateur.
Lire la réponse structurée.
Utiliser la réponse pour piloter votre app.

Tout fonctionne en millisecondes pour les prompts courts et en quelques secondes pour les longs. Il n’y a pas d’appel réseau. Il n’y a pas de clé API. Il n’y a pas de limite de débit au-delà de ce que l’appareil lui-même peut soutenir.

Le même prompt traité par un LLM cloud (haut) ou par le framework Foundation Models sur l'appareil d'Apple (bas). Le chemin sur l'appareil n'a pas de saut réseau et pas de facturation par appel.

Ce que le modèle fait vraiment bien

Le modèle sur l’appareil est petit comparé à un modèle cloud à la pointe. Ce n’est pas GPT-4. Le traiter comme tel mène à la déception. Là où il brille, c’est dans une classe spécifique de tâches :

Classification. « Cette chaîne est-elle une phrase de date ou non ? » « Dans laquelle de ces cinq catégories cette tâche appartient-elle ? » Ce sont des tâches que le modèle sur l’appareil gère de façon fiable et rapide.
Extraction structurée. Extraire des champs spécifiques d’une entrée en texte libre. « À quelle heure de la journée cette phrase fait-elle référence ? » « Quel est le verbe dans cette phrase ? » Le mode de sortie structurée du framework est conçu pour ça.
Réécriture de texte court. Convertir une note informelle en titre propre, résumer un paragraphe en une phrase, corriger la grammaire d’un brouillon. Le modèle est bon pour les petites transformations de texte contenues.
Changements de ton. Rendre un brouillon plus chaleureux, plus concis ou plus professionnel. Même contrainte : entrées courtes, sorties contenues.

C’est la plupart de ce dont une app de productivité a vraiment besoin. Remarquez ce qui n’est pas sur la liste : génération longue forme, raisonnement complexe, questions de connaissance du monde, génération de code. Le modèle sur l’appareil peut faire ça, mais pas aussi bien qu’un modèle cloud. Si c’est au cœur de votre produit, vous avez encore besoin du cloud.

Ce que le modèle ne fait pas bien

Trois classes de tâches où vous devriez chercher autre chose :

Contexte long. Le modèle sur l’appareil a une fenêtre de contexte plus petite qu’un modèle cloud. Lui donner un document de 50 pages et demander une analyse ne donnera pas de bons résultats. Donnez-lui plutôt l’extrait pertinent.
Écriture créative libre. Il peut faire de l’écriture créative courte, mais vous remarquerez la différence par rapport à un modèle cloud de pointe. Si votre app est un assistant d’écriture pour romanciers, ce n’est probablement pas votre modèle.
Tâches où l’utilisateur attend une qualité à la pointe de l’art. Si vos utilisateurs vont comparer votre sortie à ChatGPT et juger en conséquence, vous allez perdre. Le modèle est excellent pour l’utilité invisible, moins pour les tâches où l’IA est le produit visible.

Le bon cadrage est : utilisez le modèle sur l’appareil pour rendre l’app plus intelligente en arrière-plan, pas pour être le produit visible.

Ce que ça signifie pour la tarification indépendante

La conséquence la plus intéressante du modèle sur l’appareil est l’implication tarifaire. Pendant la majeure partie des trois dernières années, le conseil standard aux développeurs indépendants qui livraient des fonctionnalités IA était « vous devez facturer un abonnement, parce que les coûts d’inférence sont réels et récurrents ». Ce conseil était correct.

Il ne l’est plus pour les apps où l’intelligence sur l’appareil est suffisante. La raison entière pour laquelle une app à paiement unique ne pouvait pas livrer d’IA était le coût récurrent. Si le coût récurrent est nul, le modèle s’effondre. Vous pouvez livrer des fonctionnalités IA dans une app à paiement unique sans faire faillite.

C’est une grande nouvelle pour la petite vague d’apps Mac indépendantes qui essayent de faire revivre le modèle à paiement unique. Nous avons écrit sur la tendance plus large mais la partie IA est l’une des vraies raisons techniques pour lesquelles ça fonctionne en 2026.

Comment commencer

Le framework fait partie du SDK Apple standard sur macOS 26. Il n’y a pas de téléchargement séparé. Il n’y a pas de clé API. Il n’y a pas de compte à créer. Ajoutez import FoundationModels à un fichier Swift, créez une LanguageModelSession, envoyez un prompt, lisez la réponse.

Le modèle est disponible sur les Mac Apple Silicon qui remplissent les conditions système pour Apple Intelligence. Les anciens Mac Intel n’obtiennent pas le framework, donc votre app a besoin d’une stratégie de repli si vous voulez les prendre en charge. Pour la plupart des apps Mac indépendantes qui se livrent aujourd’hui, une vérification de disponibilité et un chemin de dégradation gracieuse suffisent. L’utilisateur sans le modèle obtient la version basée sur les expressions régulières de la fonctionnalité ; l’utilisateur avec le modèle obtient la version plus intelligente.

À quoi ça ressemble dans TodoBar

TodoBar utilise le framework comme solution de repli pour la reconnaissance de dates en langage naturel. Le chemin rapide est les expressions régulières, qui couvrent environ 90 % des phrases de date en moins d’une milliseconde. Quand le chemin regex échoue, le modèle sur l’appareil tente sa chance, avec une latence typique d’environ 50 millisecondes, et retourne une classification structurée de ce que l’utilisateur voulait dire. Nous avons décrit le pipeline complet dans l’article sur l’analyse de dates.

Le modèle est invisible pour l’utilisateur. Il ne sait pas qu’il est là. Il remarque juste que « dans quelques heures » fonctionne de la même façon que « dans 2 heures ». C’est ce à quoi ressemble une bonne IA sur l’appareil.

C’est aussi pourquoi une app à paiement unique de $9.99 peut livrer une fonctionnalité qui aurait nécessité un abonnement il y a un an. Le calcul fonctionne enfin.