Skip to main content
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. 
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

SituationPattern recommandé
Une feature ponctuelle et cibléeView model dédié + session courte
Un chat ou un assistant conversationnelSession persistante + reset
Une feature dépendante de données actuellesTool calling
Une app qui doit rester utilisable sans IAFallback explicite
Une tâche parfois trop lourde pour le modèle localArchitecture 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.

Erreurs & guardrails

Gérer les cas d’échec proprement.

Retour à l'introduction

Revoir la vue d’ensemble du framework.