Foundation Models depuis Python : la CLI fm

Pendant un an, le grand modèle de langage on-device d’Apple est resté derrière un mur : vous ne l’atteigniez que depuis Swift, et uniquement à l’intérieur d’une application construite dans Xcode¹. macOS 27 abat ce mur. Apple livre désormais un outil en ligne de commande nommé fm, préinstallé avec le système, ainsi qu’un SDK Foundation Models pour Python que vous installez avec pip¹. Le modèle qui exigeait autrefois un projet, une compilation et un LanguageModelSession en Swift compilé répond maintenant à une commande shell d’une seule ligne et tourne à l’intérieur d’un notebook Jupyter. Eric Gourlaouen, ingénieur dans l’équipe Foundation Models Framework, a résumé ce basculement sans détour lors de la session 334 de la WWDC26 : « jusqu’à présent, ces modèles n’étaient disponibles que depuis du code Swift »¹. Le changement n’est pas un nouveau modèle. Le changement, c’est que ce même modèle on-device devient soudain scriptable, automatisable et évaluable depuis l’extérieur d’une application, sans clé API et sans coût cloud¹.

En bref

• macOS 27 inclut fm, un outil en ligne de commande préinstallé pour l’Apple Foundation Model on-device. Ses sous-commandes comprennent respond (un prompt unique vers stdout), chat (session interactive) et schema (définir une sortie structurée)¹.
• fm respond propose des options pour le modèle (basculer vers Private Cloud Compute), pour une entrée image et pour un schéma de sortie structurée ; --help liste les autres¹.
• Le SDK Python atteint le même modèle on-device depuis Python ; il requiert Python 3.10 ou une version ultérieure, Xcode installé et un Mac Apple Silicon, et s’installe via pip ou un autre gestionnaire de paquets¹.
• Le SDK reflète le framework Swift : un LanguageModelSession sur lequel vous appelez respond, l’appel d’outils, et la génération guidée via le décorateur fm.generable passé à fm.respond comme argument de génération¹.
• Les deux surfaces utilisent par défaut le modèle on-device toujours disponible et peuvent opter pour le plus grand modèle Private Cloud Compute, plus performant mais soumis à des limites d’utilisation¹.
• Le bénéfice, c’est le prototypage et l’automatisation : des scripts shell qui trient les fichiers selon leur sens, et des pipelines d’évaluation en Python qui notent des variantes de prompts avec Pandas et matplotlib¹.

L’outil en ligne de commande fm

Ouvrez Terminal sous macOS 27 et tapez fm : l’outil affiche les commandes qu’il prend en charge¹. Apple en met trois en avant. fm respond envoie un prompt au modèle et renvoie une réponse. fm chat démarre une conversation interactive. fm schema crée un schéma pour une sortie structurée¹. L’usage le plus simple possible est celui qu’Eric a démontré en premier : tapez fm respond, saisissez un prompt, appuyez sur Entrée, et lisez la réponse du modèle dans le terminal un instant plus tard¹.

Les deux commandes de premier niveau se répartissent selon une ligne nette : exploration contre scripting. fm chat sert à prendre un premier pouls du modèle. Vous posez une question, vous enchaînez, et la conversation se maintient, avec ses propres commandes slash : /model bascule la conversation vers le modèle Private Cloud Compute, et /save enregistre la conversation pour la reprendre plus tard¹. Lorsque vous préférez une réponse en ligne que vous pouvez capturer, comme dans un script, vous vous tournez plutôt vers fm respond, qui écrit la sortie du modèle sur stdout¹.

C’est dans fm respond que vivent les options. Eric en a nommé trois explicitement. Une option de modèle envoie le prompt au modèle Private Cloud Compute plutôt qu’au modèle on-device par défaut. Une option d’image inclut une image dans le prompt. Et une option de schéma s’associe à fm schema object pour contraindre la sortie à une structure que vous avez définie¹. Il a noté qu’il en existe d’autres, et a renvoyé à l’option d’aide pour toutes les lister¹. La transcription nomme les options par leur rôle plutôt que par l’orthographe exacte de chaque drapeau (la seule forme littérale montrée à l’écran est fm schema object) ; ainsi, lorsque je décris une option ci-dessous, je décris le comportement documenté, sans inventer de chaîne de drapeau.

Le choix du modèle est la décision la plus importante. Par défaut, fm utilise le modèle on-device livré avec macOS, toujours disponible¹. Vous pouvez basculer vers l’Apple Foundation Model sur Private Cloud Compute, qu’Eric a décrit comme « un modèle bien plus grand que le modèle on-device, donc plus performant sur les problèmes complexes », au prix de limites d’utilisation¹. Le réglage par défaut est le bon point de départ : il est gratuit, local et sans plafond. Vous montez en gamme vers Private Cloud Compute quand une tâche est réellement assez difficile pour le justifier.

Construire un script d’automatisation

La démonstration de tri de fichiers est l’argument le plus clair en faveur de l’intérêt d’une CLI. Eric avait un dossier de projet rempli de versions brouillon et finales d’éléments, et voulait un script reproductible qui conserve les versions finales, les sauvegarde et déplace les brouillons vers un disque d’archives¹. Le difficile n’est pas de déplacer les fichiers. Le difficile, c’est de décider quel fichier est un brouillon quand les noms sont en désordre. Comme il l’a formulé, appeler un modèle de langage depuis le script lui permet de « trier les fichiers brouillon des fichiers finaux » même lorsque « les noms sont en désordre et difficiles à trier de façon prévisible »¹.

La forme se généralise à toute automatisation de type « jugement sur une liste ». Le script charge les fichiers du répertoire de travail, puis demande au modèle, via fm respond, de trier cette liste en deux groupes : fichiers finaux et fichiers brouillon¹. Pour rendre la sortie exploitable, il définit au préalable un schéma avec fm schema object décrivant deux champs, une liste de finaux et une liste de brouillons, et passe ce schéma à fm respond via l’option de schéma¹. Le modèle renvoie sa réponse en JSON, et le script la lit pour copier les finaux vers une sauvegarde et déplacer les brouillons vers les archives¹.

L’étape de sortie structurée est celle qui porte tout l’édifice. Une réponse en texte libre forcerait le script à analyser de la prose, la partie fragile de tout pipeline shell qui dialogue avec un LLM. En déclarant le schéma avec fm schema object et en récupérant du JSON, le script obtient un contrat sur lequel il peut agir directement¹. C’est le même motif que les développeurs Swift connaissent sous le nom de génération guidée, exposé ici comme une option de CLI¹. Toute tâche qui se termine par « faire quelque chose de déterministe à partir de la décision du modèle » réclame exactement cette forme : prompt, schéma, JSON, action.

Le SDK Python

La seconde surface s’adresse à une autre personne, à un autre moment. Comme l’a dit Eric, « si vous êtes ingénieur en machine learning, vous utilisez peut-être plus Python que Swift », et le SDK « facilite l’utilisation du modèle on-device dans votre code Python »¹. L’argument repose sur l’écosystème de Python : « Python possède un riche écosystème de paquets open source pour le machine learning et la science des données », ce qui signifie que vous pouvez écrire des pipelines d’évaluation et « exploiter ces paquets pour quantifier la qualité de votre fonctionnalité »¹.

L’installation comporte quatre prérequis, tous énoncés dans la session. Il vous faut Python 3.10 ou une version ultérieure, Xcode installé et un Mac Apple Silicon, et vous installez le SDK via pip ou tout autre gestionnaire de paquets de votre choix¹. Les prérequis Apple Silicon et Xcode sont le signe que le paquet est une liaison vers le même modèle on-device que celui qu’exécute le système, et non une API hébergée.

L’API paraîtra familière à quiconque a utilisé le framework Swift², et c’est voulu : « les API et les abstractions paraîtront vite familières »¹. Vous lancez un prompt en créant un LanguageModelSession, en passant éventuellement des instructions, puis en appelant session.respond avec votre prompt ; le résultat contient la sortie du modèle¹. Le SDK transpose les fonctionnalités centrales du framework : les entrées texte et image, les réponses en streaming, l’appel d’outils pour que le modèle puisse interagir avec votre code, et la génération guidée pour une sortie structurée¹.

Deux de ces fonctionnalités ont été traitées concrètement. Pour l’appel d’outils, Eric a défini un outil que le modèle peut appeler pour récupérer les dernières commandes d’un utilisateur, « afin de pouvoir fournir des informations plus personnalisées », selon le même motif que le protocole Tool du framework Swift¹. Pour la génération guidée, il a utilisé le décorateur fm.generable pour définir la structure de sortie souhaitée, un objet ItemsSuggestion, et l’a passé à fm.respond comme argument de génération¹. Le décorateur est l’équivalent Python de la macro @Generable de Swift, et l’argument de génération est la façon dont vous transmettez au modèle la forme que vous voulez récupérer. Comme la transcription les montre par leur rôle et leur nom d’objet plutôt qu’en imprimant le corps complet de la classe, considérez ItemsSuggestion comme le nom donné dans l’exemple à une structure que vous définiriez vous-même.

Pipelines d’évaluation : la vraie raison d’utiliser Python

L’étude de cas est le moment où le SDK Python cesse d’être un simple confort pour devenir une méthode. Eric construisait une fonctionnalité destinée à prédire ce qu’un utilisateur veut ajouter à son panier de courses, et il avait trois implémentations de prompt différentes : une minimale, une plus descriptive, et une détaillée qui énonçait une liste complète de règles¹. La question à laquelle tout prompt engineer est confronté est de savoir laquelle est réellement la meilleure, et la réponse honnête exige de la mesure, pas du goût.

Apple est explicite : les développeurs Swift ont leur propre réponse ici. Le framework Evaluations est livré avec Xcode 27 et facilite la création d’évaluations ainsi que le suivi de la précision d’une fonctionnalité au fil des itérations¹. Le SDK Python est la voie parallèle pour les data scientists qui vivent dans les notebooks. Eric a mené toute l’analyse depuis Jupyter¹.

Le pipeline se lit comme une boucle d’évaluation ML classique pointée vers le modèle on-device. D’abord, il a utilisé un grand modèle serveur pour générer des données d’évaluation, lui fournissant des entrées et une sortie attendue pour chacune¹. Ensuite, pour chaque entrée, il a généré des sorties à partir de chacune des trois implémentations de prompt et a stocké les entrées et les sorties sous forme de lignes dans un DataFrame Pandas¹. Puis, des fonctions de jugement adossées à un modèle serveur ont noté chaque sortie selon des critères qu’il avait choisis, et ces métriques sont retournées dans le DataFrame¹. Enfin, matplotlib a transformé les notes en graphiques¹.

Les graphiques ont raconté une histoire qu’aucune contemplation des prompts n’aurait révélée : le prompt détaillé atteignait un taux élevé d’erreurs de génération, qu’Eric a attribué au fait d’atteindre la taille maximale de la fenêtre de contexte du modèle ; les deux prompts moins détaillés ajoutaient des articles superflus au panier tandis que le détaillé en ajoutait moins ; le prompt détaillé manquait davantage d’articles attendus ; et le prompt minimal hallucinait le plus d’articles¹. Chaque prompt avait un mode de défaillance différent, et seule la mesure les a fait apparaître. C’est là l’argument en faveur de toute l’approche. « Avec Python, je peux faire ces itérations rapidement directement depuis mon notebook, sans avoir à reconstruire tout le projet », a déclaré Eric¹.

Quand recourir à chacun

Quelques règles découlent des contrats ci-dessus.

Recourez à fm respond quand un script shell a besoin d’un jugement. Trier des noms de fichiers en désordre, classer une ligne d’entrée, extraire un champ d’un texte non structuré. Associez-le à fm schema object et à l’option de schéma pour que le script agisse sur du JSON au lieu d’analyser de la prose¹.

Recourez à fm chat quand vous explorez, pas quand vous scriptez. C’est la façon la plus rapide de prendre un premier pouls de la manière dont le modèle gère vos prompts, avec /model pour passer à Private Cloud Compute et /save pour conserver une session¹.

Recourez au SDK Python quand vous voulez mesurer, au-delà du simple appel. Dès l’instant où vous avez plus d’un prompt et où vous devez savoir lequel est meilleur, la boucle notebook + Pandas + matplotlib est l’outil, car le modèle on-device est assez gratuit et local pour faire tourner tout un jeu d’évaluation sans facture¹.

Par défaut, le modèle on-device ; montez vers Private Cloud Compute de façon délibérée. Le modèle on-device est toujours disponible et sans limite d’utilisation. Private Cloud Compute est plus grand et meilleur sur les problèmes complexes, mais comporte des limites d’utilisation : réservez-le donc aux tâches qui le méritent¹.

Prototypez ici, livrez en Swift. Le cadrage d’Eric lui-même est que vous pouvez utiliser ces outils « aux côtés de votre projet Xcode, comme moyen de prototyper et d’évaluer des prompts », ou « seuls, pour utiliser le modèle de manières inédites »¹. L’exemple de l’application de courses prototype des prompts en Python « avant de les implémenter en Swift »¹. La CLI et le SDK raccourcissent la boucle entre l’idée et la preuve ; l’application reste l’endroit où la fonctionnalité atterrit.

FAQ

Qu’est-ce que l’outil en ligne de commande fm ?

fm est un outil en ligne de commande préinstallé avec macOS 27 qui atteint l’Apple Foundation Model on-device depuis l’application Terminal¹. Ses sous-commandes comprennent respond pour envoyer un prompt au modèle et afficher une réponse, chat pour démarrer une conversation interactive, et schema pour définir une sortie structurée. Vous l’exécutez sans clé API et sans coût cloud, car le modèle par défaut s’exécute on-device¹.

Comment obtenir du JSON structuré à partir de fm ?

Définissez un schéma avec fm schema object, puis passez ce schéma à fm respond via son option de schéma. Le modèle renvoie sa réponse en JSON conforme au schéma, sur lequel un script peut agir directement au lieu d’analyser du texte libre¹. Le mécanisme est la version CLI de la génération guidée du framework¹.

Que requiert le SDK Foundation Models pour Python ?

Python 3.10 ou une version ultérieure, Xcode installé et un Mac Apple Silicon¹. Vous l’installez via pip ou un autre gestionnaire de paquets de votre choix. Les prérequis Apple Silicon et Xcode reflètent le fait que le SDK se lie au même modèle on-device que celui qu’exécute le système, plutôt que d’appeler une API hébergée¹.

En quoi le SDK Python diffère-t-il du framework Swift ?

C’est le même modèle et une API délibérément familière dans un autre langage. Vous créez un LanguageModelSession, appelez respond, exposez des outils et utilisez la génération guidée via le décorateur fm.generable passé à fm.respond comme argument de génération¹. La raison de choisir Python, c’est l’écosystème : Pandas, matplotlib, Jupyter et le reste de la pile de science des données pour des pipelines d’évaluation que Swift n’atteint pas aussi directement¹.

Quand dois-je utiliser Private Cloud Compute plutôt que le modèle on-device ?

fm et le SDK utilisent tous deux par défaut le modèle on-device, toujours disponible et sans limite d’utilisation¹. Basculez vers Private Cloud Compute, via l’option de modèle de fm respond ou la commande /model de fm chat, lorsqu’un problème est assez complexe pour nécessiter le plus grand modèle, en acceptant qu’il comporte des limites d’utilisation¹.

Le cluster complet Apple Ecosystem : l’explication du framework Foundation Models pour la fondation Swift que ces outils reflètent ; les contrôles d’appel d’outils d’iOS 27 pour la façon dont le modèle utilise les outils ; le workflow agentique de Foundation Models pour le choix entre modèle on-device et modèle plus grand ; et les agents de codage de Xcode 27 pour le versant IDE d’un workflow centré sur les agents. Le hub se trouve dans la série Apple Ecosystem. Pour une vue d’ensemble de la création d’iOS avec des agents, consultez le guide de développement d’agents iOS.