> ## 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.

# Patterns d'architecture

> Organiser proprement vos features IA on-device dans une app Swift

Une bonne intégration de Foundation Models repose moins sur un prompt parfait que sur une architecture propre. Le but est de garder des features lisibles, testables et isolées.

***

## Pattern 1 : un view model par feature

Pour une feature comme :

* résumé de texte
* génération d'idées
* assistant contextuel

gardez un view model dédié avec sa propre session.

```swift theme={null}
import FoundationModels
import Observation

@Observable
@MainActor
final class SummaryViewModel {
    var output = ""
    var errorMessage: String?

    private let session = LanguageModelSession(
        instructions: "You summarize text for intermediate Swift developers."
    )

    func summarize(_ text: String) async {
        errorMessage = nil

        do {
            let response = try await session.respond(
                to: "Résume ce texte en 3 points : \(text)"
            )
            output = response.content
        } catch {
            errorMessage = error.localizedDescription
        }
    }
}
```

Ce pattern limite les effets de bord entre fonctionnalités.

***

## Pattern 2 : session courte pour tâche unique

Si la requête ne dépend pas d'un historique, créez une session courte et jetez-la ensuite.

C'est le bon choix pour :

* un résumé ponctuel
* une reformulation
* une extraction structurée indépendante

Vous évitez ainsi de traîner un contexte inutile.

***

## Pattern 3 : session persistante pour un chat

Pour une conversation multi-tours, conservez la session tant que l'échange reste cohérent.

Prévoyez tout de même :

* un bouton de reset
* une gestion du contexte trop long
* une UI qui montre qu'une conversation est en cours

***

## Pattern 4 : fallback explicite si le modèle manque

Votre architecture doit accepter que la feature ne soit pas disponible.

Le minimum :

* vérifier `SystemLanguageModel.default.availability`
* afficher un état alternatif clair
* éviter de cacher l'erreur derrière un simple spinner infini

***

## Pattern 5 : tool calling pour les données dynamiques

Le modèle système n'a pas vos données métier ni l'état courant de l'app. Si la réponse dépend de ces données, injectez-les via un tool plutôt que d'espérer une "bonne intuition" du modèle.

Exemples :

* lire le calendrier
* chercher une note locale
* lancer une action dans l'app

***

## Pattern 6 : architecture hybride si le local ne suffit pas

Si une tâche dépasse le modèle système, vous pouvez garder Foundation Models côté app pour :

* l'UX Swift native
* la sortie structurée
* la coordination de l'expérience

et appeler un backend externe seulement pour les cas plus lourds.

Ce n'est pas obligatoire, mais c'est souvent un compromis plus raisonnable que de basculer toute l'architecture sur un modèle custom dès le premier jour.

***

## Résumé de décision

| Situation                                          | Pattern recommandé                |
| -------------------------------------------------- | --------------------------------- |
| Une feature ponctuelle et ciblée                   | View model dédié + session courte |
| Un chat ou un assistant conversationnel            | Session persistante + reset       |
| Une feature dépendante de données actuelles        | Tool calling                      |
| Une app qui doit rester utilisable sans IA         | Fallback explicite                |
| Une tâche parfois trop lourde pour le modèle local | Architecture hybride              |

***

## Checklist avant d'intégrer la feature

1. La feature a-t-elle sa propre session ?
2. L'état d'indisponibilité est-il géré dans l'UI ?
3. Les erreurs sont-elles compréhensibles pour l'utilisateur ?
4. La sortie devrait-elle être structurée plutôt que textuelle ?
5. Un tool est-il nécessaire pour éviter d'inventer des données ?

Si ces cinq points sont clairs, votre architecture est déjà sur de bonnes bases.

***

<CardGroup cols={2}>
  <Card title="Erreurs & guardrails" icon="triangle-exclamation" href="/mlx/foundation-models/error-handling">
    Gérer les cas d'échec proprement.
  </Card>

  <Card title="Retour à l'introduction" icon="house" href="/mlx/foundation-models/introduction">
    Revoir la vue d'ensemble du framework.
  </Card>
</CardGroup>