> ## Documentation Index
> Fetch the complete documentation index at: https://docsmlx.otterly.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Foundation Models

> Utiliser le modèle de langage système d'Apple depuis Swift

<Note>
  Foundation Models donne accès au modèle de langage système d'Apple via le module `FoundationModels`. Votre app n'embarque pas elle-même les poids du modèle. Vérifiez toujours la disponibilité au runtime. Les APIs citées ici sont documentées par Apple pour iOS 26.0, iPadOS 26.0, macOS 26.0, visionOS 26.0 et Mac Catalyst 26.0 ou plus.
</Note>

## Ce que c'est, simplement

**Foundation Models** est le framework Swift qui vous permet d'utiliser le modèle système on-device d'Apple dans une app.

Pour un développeur Swift, c'est souvent l'entrée la plus simple vers l'IA générative sur Apple :

* API Swift native
* modèle fourni par le système
* génération de texte
* sortie structurée avec `@Generable`
* streaming
* tool calling

Le point d'entrée principal est `LanguageModelSession`.

```swift theme={null}
import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(
    to: "Explique en deux phrases quand utiliser une sortie structurée."
)

print(response.content)
```

***

## Ce que le framework couvre réellement

Foundation Models n'est pas juste un `respond(to:)`. En pratique, vous assemblez plusieurs briques :

* `SystemLanguageModel` représente le modèle système, sa disponibilité, ses langues prises en charge et sa taille de contexte.
* `LanguageModelSession` porte le transcript, les instructions, les tools et l'état `isResponding`.
* `@Generable` et `@Guide` servent à demander une sortie structurée plutôt qu'un bloc de texte.
* `streamResponse(to:)` sert à afficher une réponse progressivement.
* `Tool` permet au modèle d'aller chercher des données ou de déclencher des actions dans votre app.

Vu comme ça, le framework ressemble moins à un chat prêt à l'emploi et plus à une boîte à outils Swift pour intégrer un modèle système.

***

## Quand utiliser Foundation Models

Choisissez Foundation Models si :

* vous développez une app Swift sur une plateforme Apple compatible
* le modèle système Apple suffit à votre cas d'usage
* vous voulez une intégration native et rapide
* vous préférez éviter de gérer vous-même des poids de modèle

Exemples de cas d'usage adaptés :

* reformuler ou résumer du texte
* produire une réponse courte et contextualisée
* classer ou structurer une information
* enrichir une UI avec une fonctionnalité générative locale

***

## Ce que le framework fait bien

<CardGroup cols={2}>
  <Card title="Swift natif" icon="swift">
    L'API s'intègre naturellement avec SwiftUI, Observation et la concurrence Swift.
  </Card>

  <Card title="Sortie structurée" icon="table-columns">
    Vous pouvez demander des objets Swift plutôt que du texte brut.
  </Card>

  <Card title="Streaming" icon="bolt">
    La réponse peut arriver progressivement pour une meilleure UX.
  </Card>

  <Card title="Tools" icon="wrench">
    Le modèle peut appeler votre code pour accéder à des données ou déclencher des actions.
  </Card>
</CardGroup>

***

## Deux use cases Apple à connaître

Apple documente aussi des **use cases** pour `SystemLanguageModel`. Deux cas sont particulièrement utiles à connaître :

* `.general` pour les tâches de génération classiques : expliquer, résumer, reformuler, répondre ou utiliser des tools.
* `.contentTagging` pour classer et organiser du contenu, plutôt que produire une réponse conversationnelle.

```swift theme={null}
import FoundationModels

let generalModel = SystemLanguageModel(useCase: .general)
let taggingModel = SystemLanguageModel(useCase: .contentTagging)
```

Si votre feature consiste surtout à étiqueter, router ou classer du texte, pensez à ce second use case avant de construire un pseudo-chat.

***

## Ce qu'il ne faut pas lui demander

Foundation Models n'est pas le bon choix si vous avez besoin :

* d'un modèle open weight précis
* de fine-tuning local
* d'une très grande fenêtre de contexte
* d'un raisonnement long ou très spécialisé

Dans ces cas-là, regardez plutôt :

* [MLX](/mlx/introduction) pour des modèles open weight sur Apple Silicon
* un backend local via `mlx-lm`, Ollama ou `llama.cpp`
* éventuellement un service cloud si la tâche dépasse clairement le modèle système

***

## Foundation Models vs MLX

| Question                                | Foundation Models       | MLX                                  |
| --------------------------------------- | ----------------------- | ------------------------------------ |
| Quel modèle utilisez-vous ?             | Le modèle système Apple | Un modèle open weight de votre choix |
| Qui gère les poids ?                    | Le système              | Vous                                 |
| API principale                          | Swift                   | Python et Swift                      |
| Fine-tuning                             | Non                     | Oui                                  |
| Bon choix pour une feature Swift rapide | Oui                     | Pas toujours                         |

Ces deux approches sont complémentaires. Beaucoup de produits commencent avec Foundation Models, puis ajoutent MLX seulement quand ils ont besoin d'un modèle personnalisé.

***

## Le premier réflexe à adopter

Avant d'écrire votre feature, vérifiez toujours deux choses :

1. le modèle est-il disponible sur l'appareil ?
2. la langue et le cas d'usage sont-ils compatibles ?

La page suivante vous montre comment le faire proprement.

<Card title="Disponibilité du modèle" icon="circle-check" href="/mlx/foundation-models/availability">
  Vérifier la disponibilité avant d'appeler le modèle.
</Card>