Développer une app Mac avec Foundation Models : guide 2026

Le développement Mac avec Foundation Models doit commencer par une tâche mesurable, et non par un agent complexe. En 2026, vous pouvez concevoir une même fonction autour du modèle Apple exécuté sur l’appareil, de Private Cloud Compute, d’un modèle tiers ou de Core AI ; cette souplesse impose toutefois un jeu d’évaluation et un chemin de repli dès le premier prototype.

Cette méthode convient aux développeurs Swift qui ajoutent le résumé, l’extraction, le dialogue ou l’appel d’outils à une application Mac existante. Elle s’adresse également aux indépendants qui construisent un agent local prioritaire et aux équipes qui doivent tester plusieurs versions de macOS, configurations matérielles et fournisseurs de modèles.

Calendrier de travail : avant le 25 août 2026, vérifiez les exigences documentées par Apple et séparez les fonctions confirmées des éléments encore susceptibles de changer pendant la période de test de macOS 27. Cette semaine, choisissez une seule tâche, créez un jeu d’évaluation minimal, puis exécutez-le sur votre Mac cible avant d’ajouter une interface conversationnelle ou une chaîne d’outils.

Dernière mise à jour : 25 août 2026. Les informations de disponibilité et de comportement ont été vérifiées dans la documentation Apple Developer et les notes de version de macOS 27.

Cette semaine ou plus tard : fixer le périmètre avant le code

Le premier choix oppose une démonstration impressionnante à une fonction vérifiable. Pour une application audio, vous pouvez extraire les intervenants et les thèmes d’un entretien. Pour un outil vidéo, vous pouvez produire des chapitres à partir d’un script. Pour un logiciel de design, vous pouvez convertir une demande libre en propriétés structurées. Ces tâches se mesurent mieux qu’un agent auquel on demanderait simplement d’être « intelligent ».

Commencez par quatre éléments :

l’entrée exacte : texte, transcription, métadonnées ou combinaison de ces données ;
la sortie attendue : texte court, liste, objet structuré ou action proposée ;
les données sensibles qui doivent rester sur l’appareil ;
le comportement prévu lorsque le modèle est indisponible, lent ou incorrect.

Votre premier jeu d’évaluation peut contenir des exemples ordinaires, des entrées ambiguës, des langues différentes, des contenus incomplets et des demandes interdites. L’objectif n’est pas de représenter tout votre produit. Il est de rendre visible une régression avant qu’un utilisateur ne la découvre.

Pour chaque exemple, conservez la demande, la sortie attendue, les critères d’acceptation et le résultat obtenu. Une extraction de dates peut être jugée sur la présence des champs, tandis qu’un résumé doit être vérifié sur la fidélité, l’absence d’informations inventées et la longueur maximale. Ne mélangez pas ces critères dans une note globale impossible à interpréter.

Apple décrit Foundation Models comme une interface destinée à générer du contenu et à réaliser des tâches à partir du modèle système. Consultez la documentation générale de Foundation Models avant de figer vos abstractions Swift. Les noms d’API, les autorisations et les conditions de disponibilité peuvent encore évoluer pendant le cycle de test de macOS 27.

Première étape : créer la première fonction Mac avec Foundation Models

Pour créer le premier composant d’une application Mac, réduisez la session au minimum. Une demande, une réponse, un traitement d’erreur. Ne commencez pas par l’historique permanent, les appels parallèles et une dizaine d’outils.

La forme générale ressemble à ceci :

swift

import FoundationModels

func resumer(_ texte: String) async throws -> String {
    let session = LanguageModelSession()
    let demande = """
    Résumez le texte suivant en trois points factuels.
    N'ajoutez aucune information absente du texte.

    \(texte)
    """

    let reponse = try await session.respond(to: demande)
    return reponse.content
}

Ce fragment illustre la séparation utile entre la tâche et l’interface utilisateur. Il ne constitue pas un projet de production complet. Reportez-vous aux exemples du guide Apple consacré aux fonctions génératives pour adapter la session au contexte réel de votre application.

Avant d’afficher la réponse, votre code doit vérifier que le modèle est utilisable dans l’environnement courant. Une application distribuée ne doit pas supposer que la machine possède le modèle requis, que l’utilisateur a accepté toutes les conditions nécessaires ou que le système dispose des ressources attendues. La documentation Apple sur les mises à jour de Foundation Models doit servir de référence lorsque vous traitez les changements liés au système.

Prévoyez quatre résultats distincts, plutôt qu’un seul message « erreur » :

le modèle est disponible et la réponse peut être affichée ;
la génération est interrompue et peut être relancée ;
la sortie ne respecte pas le format demandé ;
aucun modèle admissible n’est disponible.

Cette distinction améliore la récupération. Une sortie mal structurée peut être régénérée avec une consigne plus stricte. Une indisponibilité du modèle doit plutôt déclencher le repli prévu, sans demander silencieusement à l’utilisateur de réessayer indéfiniment.

Sortie structurée et réponse progressive

Un résumé affiché progressivement ne se traite pas comme un objet métier. Pour un export, une fiche de montage ou une commande de recherche, vous avez besoin de champs validables. Définissez alors un schéma restreint : titre, éléments, avertissements et statut. Refusez les champs inconnus et vérifiez les valeurs avant de les enregistrer.

La réponse progressive améliore la perception d’attente, mais elle ne garantit pas que le résultat final soit complet. Conservez donc un état intermédiaire, une possibilité d’annulation et une validation finale. Si l’utilisateur ferme la fenêtre pendant une transcription audio, l’application doit pouvoir abandonner la session sans laisser une opération marquée comme terminée.

Modèle local ou Private Cloud Compute : critères de sélection

Le modèle exécuté sur l’appareil est généralement le premier candidat pour les contenus sensibles, les fonctions hors connexion et les interactions qui doivent rester prévisibles même sans réseau. Il limite également la dépendance à un service distant, mais il ne faut pas lui attribuer automatiquement les tâches qui exigent un contexte volumineux ou un raisonnement spécialisé.

Private Cloud Compute constitue une autre voie documentée par Apple pour les traitements qui ne sont pas adaptés à l’exécution locale. Vérifiez les conditions d’accès et les garanties annoncées dans la documentation officielle de Private Cloud Compute. Ne présentez pas ce chemin comme un simple « modèle plus puissant » : la disponibilité réseau, la confidentialité, les délais et la politique de conservation doivent entrer dans votre décision.

La comparaison doit partir du même jeu d’évaluation :

Données privées et mode hors connexion : privilégiez l’appareil, avec une sortie dégradée si le modèle manque.
Contexte plus lourd ou raisonnement plus exigeant : évaluez Private Cloud Compute lorsque votre politique de confidentialité et votre architecture réseau l’autorisent.
Compétence spécialisée ou fournisseur déjà intégré : utilisez un modèle tiers derrière une interface indépendante du reste de l’application.
Besoins de contrôle plus bas niveau : examinez Core AI et ses possibilités documentées, sans confondre cette couche avec une promesse de performance universelle.

La décision ne doit pas reposer sur le nom du modèle. Mesurez la fidélité, le taux de sorties valides, la durée jusqu’au premier résultat, la durée totale, le coût d’une requête distante et le comportement sans connexion. Pour l’audio et la vidéo, ajoutez la conservation des timecodes, des noms propres et des indications de locuteur. Une réponse élégante mais inutilisable dans votre montage n’est pas une réussite technique.

Foundation Models et modèles tiers : une passerelle d’intégration indépendante

Foundation Models ne doit pas devenir une dépendance dispersée dans toutes les vues de votre application. Créez une couche de service qui reçoit une tâche métier et renvoie un résultat validé. Cette couche peut sélectionner le modèle local, Private Cloud Compute, Core AI ou un fournisseur tiers sans modifier le contrôleur de votre éditeur vidéo ou de votre outil de design.

Une interface interne peut suivre cette logique :

swift

enum SourceMode {
    case appareil
    case cloudPrive
    case tiers
}

struct DemandeIA {
    let texte: String
    let mode: SourceMode
}

protocol MoteurGeneration {
    func executer(_ demande: DemandeIA) async throws -> ResultatIA
}

Le protocole LanguageModel aide à comprendre la séparation entre le modèle et le code qui l’utilise. Pour un service tiers, conservez les mêmes contrats de sortie, les mêmes validations et les mêmes règles de consentement. Ne transmettez jamais un document sensible à une route distante simplement parce que le modèle local a échoué, sans informer l’utilisateur et appliquer votre politique de données.

Cette architecture permet aussi de tester les modèles avec une seule commande. Le jeu d’évaluation envoie chaque cas aux sources admissibles, puis compare les résultats selon des critères identiques. Vous voyez alors si un modèle tiers améliore réellement l’extraction ou s’il produit seulement des réponses plus longues.

Pour les coûts, séparez les postes : appels distants, stockage temporaire, journalisation, transfert des fichiers audio ou vidéo, environnement de test et temps d’analyse des échecs. Une estimation sans ces éléments donne une fausse impression de rentabilité.

Outils contrôlés ou agent autonome : règles de sécurité

Un outil ne doit pas être défini comme une simple fonction que le modèle peut appeler à volonté. Décrivez son entrée, son résultat, ses autorisations, ses effets de bord et sa possibilité d’annulation. L’outil « rechercher dans le projet » ne présente pas le même risque que « supprimer une séquence » ou « publier une version ».

Apple documente le protocole Tool ainsi que le flux d’extension avec appel d’outils. Utilisez ces documents pour vérifier la forme exacte des déclarations dans le SDK retenu, car les détails d’API ne doivent pas être déduits d’un exemple ancien.

Pour une première version, appliquez ces règles :

limitez les outils visibles à ceux nécessaires à la tâche ;
validez les arguments avant toute exécution ;
refusez les chemins de fichiers qui sortent de l’espace autorisé ;
affichez une confirmation avant une action destructive ou externe ;
rendez l’opération annulable lorsque cela est possible ;
imposez une limite de boucles et un délai d’expiration ;
journalisez la demande, l’outil choisi, le résultat et l’erreur récupérable.

Le test important n’est pas seulement « l’outil fonctionne-t-il ? ». Il faut aussi vérifier que le modèle choisit de ne pas l’appeler lorsque les informations manquent, qu’il demande une précision lorsque plusieurs fichiers correspondent et qu’il s’arrête après un échec. Dans un logiciel audio, une commande de déplacement doit par exemple pouvoir être prévisualisée avant de modifier la session.

Les problèmes connus de macOS 27 et de Foundation Models peuvent concerner la disponibilité, les permissions ou l’évolution des sorties. Construisez donc un délai d’expiration, une confirmation humaine et un repli vers une opération manuelle. Un agent qui ne sait pas s’arrêter est un défaut de produit, même si sa démonstration initiale est convaincante.

Évaluation locale ou Mac distant : procédure pour tester Foundation Models

Vous ne pouvez pas conclure qu’une fonction est prête parce qu’elle fonctionne sur le Mac du développeur. Il faut tester les sorties, les langues, l’interruption réseau, l’absence du modèle et les changements après mise à jour du système.

Si vous ne disposez pas d’un Mac compatible, séparez deux besoins. Pour vérifier le comportement général de votre interface, des simulations locales peuvent suffire. Pour confirmer la disponibilité réelle de Foundation Models, l’exécution du modèle et les autorisations système, il faut un Mac correspondant à la configuration et à la version de macOS visées. Une machine virtuelle ou un simple test de compilation ne remplace pas cette validation.

Un environnement Mac distant isolé est pertinent lorsque plusieurs développeurs doivent reproduire le même scénario ou lorsque votre équipe doit comparer plusieurs versions de macOS. Vous pourrez exécuter les mêmes entrées, conserver les journaux et éviter de modifier la machine de production du développeur. Pour organiser une procédure plus large, consultez aussi notre guide sur le choix entre puissance locale et infrastructure distante pour l’IA.

Avant de réserver ou de préparer cet environnement, vérifiez :

la version de macOS et son état de disponibilité ;
l’accès au compte développeur et aux outils nécessaires ;
la capacité à installer la version de votre application ;
le mode d’accès distant, par terminal ou bureau distant ;
l’effacement des fichiers et identifiants après chaque campagne ;
la possibilité de répéter exactement le même jeu d’évaluation.

Pour une équipe qui automatise la compilation et les validations, un environnement distant doit donc être traité comme une machine de test éphémère : image documentée, accès limité, données synthétiques et nettoyage vérifiable après la campagne. Il ne doit pas devenir un espace permanent où des identifiants de signature ou des fichiers clients restent accessibles à tous les membres de l’équipe.

La liste de contrôle avant la mise en production

Utilisez cette liste pour décider si votre prototype peut passer à une phase d’intégration plus large :

[ ] Une tâche unique et mesurable est décrite dans le dépôt.
[ ] Le jeu d’évaluation contient des entrées normales, ambiguës, incomplètes et sensibles.
[ ] La sortie attendue possède des critères de validation explicites.
[ ] Le code distingue modèle indisponible, sortie invalide, interruption et erreur réseau.
[ ] Les exigences de macOS 27, du SDK et de l’appareil ont été vérifiées dans les documents Apple récents.
[ ] Le choix entre modèle local, Private Cloud Compute, Core AI et modèle tiers est justifié par les tests.
[ ] Les données envoyées hors de l’appareil sont annoncées et autorisées.
[ ] Chaque outil vérifie ses arguments et ses permissions avant exécution.
[ ] Les opérations risquées demandent une confirmation et peuvent être annulées.
[ ] Les appels d’outils interrompus et les boucles excessives disposent d’une sortie contrôlée.
[ ] Les tests couvrent le changement de langue et les différences de formulation.
[ ] Une machine Mac compatible a validé le modèle réellement utilisé.
[ ] Les journaux ne contiennent pas de contenu sensible inutile.
[ ] Le jeu d’évaluation peut être relancé après chaque mise à jour du système ou du modèle.

Cette liste répond également à une question souvent négligée : tester un outil ne signifie pas seulement vérifier son résultat nominal. Vous devez provoquer une autorisation refusée, un fichier absent, un réseau interrompu et une réponse structurée incomplète. Ces cas révèlent les défauts de conception plus vite qu’une démonstration réussie.

Déploiement local, distant ou hybride : critères de choix

Le tableau suivant ne remplace pas votre évaluation. Il sert à choisir un premier axe de déploiement avant d’ouvrir une campagne de tests plus complète.

Option	Cas d’usage prioritaire	Points à vérifier	Repli conseillé
Modèle sur l’appareil via Foundation Models	Résumé privé, extraction hors connexion, assistance dans un éditeur audio ou vidéo	Disponibilité du modèle, format de sortie, évolution après mise à jour	Fonction manuelle ou modèle tiers avec consentement
Private Cloud Compute	Tâches demandant davantage de contexte ou une capacité distante documentée	Réseau, politique de données, authentification, délai et indisponibilité	Modèle local pour une demande réduite
Core AI	Intégration spécialisée et contrôle plus fin de la chaîne de traitement	API disponibles, compatibilité système, maintenance du modèle	Traitement déterministe ou service secondaire
Modèle tiers	Besoin multiplateforme, spécialisation ou infrastructure existante	Transfert de données, coût par requête, contrat, quotas et formats	Message explicite et reprise manuelle
Mac distant isolé	Tests de versions, validation de disponibilité et automatisation d’équipe	Image système, accès, nettoyage, reproductibilité et stockage des journaux	Report de campagne ou appareil local compatible

La meilleure option peut changer selon la fonction. Un résumé de notes de production peut rester local, tandis qu’une recherche sémantique sur un corpus volumineux pourra nécessiter une voie distante. Pour les équipes qui structurent déjà leur chaîne de développement, notre guide de flux de programmation assistée par IA aide à intégrer les règles, les validations et les responsabilités humaines autour de cette couche.

Après la sortie : maintenir le comportement, pas seulement l’API

Une mise à jour de macOS peut modifier les réponses d’un modèle exécuté sur l’appareil, même si votre code compile encore. Conservez donc la version du système, la version du modèle lorsqu’elle est exposée, la version de la consigne, le schéma de sortie et le résultat de chaque outil. Ces informations permettent de distinguer une régression du modèle d’un changement dans votre propre code.

Ne journalisez pas automatiquement les documents complets. Préférez un identifiant de cas, des métriques de validation, la catégorie d’erreur et un extrait expurgé lorsque cela suffit. Pour une application de design ou de montage, les métadonnées techniques peuvent souvent être conservées sans enregistrer le contenu créatif lui-même.

Après chaque mise à jour importante, relancez au minimum :

les cas de sortie structurée ;
les demandes dans les langues prises en charge ;
les appels d’outils à risque ;
les scénarios sans réseau ;
les scénarios où le modèle est indisponible ;
les vérifications de confidentialité et d’autorisation.

Si votre équipe développe plusieurs compétences autour d’un agent, évitez de transformer chaque consigne en règle implicite. Le cadre de conception des compétences pour les outils de développement assistés par IA peut vous aider à isoler les responsabilités, les entrées et les conditions d’arrêt, même si votre application finale utilise Foundation Models.

Pour une équipe qui doit comparer macOS 27 avec une version antérieure ou préparer une nouvelle configuration, la location d’un Mac distant est surtout intéressante sur une période ciblée : validation d’une version bêta, campagne de non-régression, intégration continue ou reproduction d’un défaut. Elle est moins adaptée à une charge lourde permanente qui justifierait l’achat d’une machine dédiée, ou à un projet nécessitant un accès physique continu à des périphériques audio, vidéo ou USB.

Un poste local offre une disponibilité immédiate et un contrôle direct des périphériques, mais il immobilise du matériel et complique la comparaison de plusieurs environnements. Une infrastructure généraliste peut être flexible, mais elle ne reproduit pas nécessairement le comportement du modèle système ni les permissions propres à macOS. Pour un cycle de test limité, Hashvps permet donc de préparer un environnement Mac isolé, de répéter le même jeu d’évaluation et de libérer les ressources à la fin de la campagne. La bonne décision consiste à réserver cette approche aux tests et aux déploiements temporaires qui exigent réellement plusieurs environnements, plutôt qu’à remplacer systématiquement un poste de travail stable.

Commencez par votre jeu d’évaluation, puis choisissez la source de modèle et l’environnement capables de répondre à ses critères. Si vous devez exécuter cette campagne en parallèle sur plusieurs versions de macOS, préparez un environnement Mac isolé pour la durée exacte des tests et supprimez les données de travail dès la validation terminée.