L'entrée d'image dans Foundation Models sous iOS 27

iOS 26 a offert aux apps un grand modèle de langage embarqué capable de lire et d’écrire du texte. iOS 27 donne des yeux à ce même modèle. Lors de la WWDC26, Apple a confirmé que le modèle de langage système embarqué « acquiert également des capacités Vision, ce qui ouvre des catégories entières de nouvelles applications »¹, et la manière d’accéder à ces capacités est presque décevante de simplicité : vous placez une image dans l’invite, à côté des mots, comme pièce jointe, et vous posez votre question. Pas de pipeline Vision distinct, pas de changement de modèle, pas de nouveau type de session. L’invite qui ne portait qu’une chaîne de caractères porte désormais une image elle aussi, et le modèle répond sur les deux.

Pourquoi cette faible surface d’API fait-elle la une ? L’entrée d’image n’est pas une API satellite greffée sur Foundation Models. Apple la décrit comme « un prolongement naturel des prompt builders existants »¹, ce qui signifie que chaque concept déjà appris sous iOS 26 (les sessions, la génération guidée, le protocole Tool) continue de fonctionner sans changement dès qu’une invite devient multimodale⁴. Si vous n’avez pas encore croisé LanguageModelSession, commencez par l’explication du framework Foundation Models, puis revenez.

TL;DR

• Le modèle embarqué d’iOS 27 accepte l’entrée d’image. Vous insérez une pièce jointe image dans votre invite aux côtés du texte, et le modèle répond aux questions portant sur l’image¹².
• Les pièces jointes image peuvent être créées à partir de divers types : UIImage, NSImage, CGImage, les types Core Image, les pixel buffers CoreVideo et les URL de fichiers¹.
• Le modèle prend en charge les images de toute taille et de tout ratio, vous n’avez donc pas à rogner ni à ajouter de marges pour obtenir une forme précise ; en revanche, les images plus grandes consomment davantage de tokens et augmentent la latence¹.
• Foundation Models confère au LLM une grande polyvalence sur une image ; le framework Vision offre une analyse figée, rapide et finement ajustée. La recommandation d’Apple est de les combiner par l’appel d’outils plutôt que de choisir².
• Le modèle serveur Private Cloud Compute prend lui aussi en charge l’entrée d’image, avec une fenêtre de contexte de 32K (contre 4K en embarqué), si bien que les invites multimodales portant du texte et plusieurs images disposent d’espace pour respirer³.

Ce qui a changé : l’invite s’est dotée d’une image

Dans la session 241, le cadrage d’Apple est précis. Le modèle embarqué « est plus intelligent ; meilleur en logique et en appel d’outils », et par-dessus cette intelligence il gagne désormais Vision¹. La démo interroge le modèle sur une photo d’origami : « Il vous suffit d’insérer une pièce jointe image dans votre invite, avec du texte. Le modèle peut alors répondre aux questions portant sur l’image »¹. L’ordre compte. Texte et image vivent dans la même invite, le modèle lit l’invite entière, et la réponse raisonne sur les deux.

L’ensemble des types source est assez large pour que vous n’ayez que rarement à convertir quoi que ce soit vous-même. Apple en énumère six : les pièces jointes image « peuvent être créées à partir de divers types, dont UIImage, NSImage, CGImage, les types Core Image, les pixel buffers CoreVideo et les URL de fichiers »¹. Une UIImage tout droit sortie de PhotosPicker, une CGImage que vous avez déjà rendue, une trame récupérée de l’appareil photo sous forme de CVPixelBuffer, ou un fichier sur disque par URL : tout cela constitue une entrée valable. La transcription nomme les types d’entrée mais pas les signatures exactes des initialiseurs de pièce jointe ; traitez donc la liste des types comme le contrat, et laissez l’autocomplétion de Xcode remplir le site d’appel une fois sur le SDK d’iOS 27.

Voici une contrainte contre laquelle vous n’avez pas à lutter : la forme. « Le modèle prend en charge les images de toute taille et de tout ratio, vous n’avez donc pas besoin de rogner ni d’ajouter des marges pour obtenir une forme particulière »¹. Un long reçu, un panorama large et une miniature carrée sont tous acceptables tels quels. Le coût est celui que l’on attend de tout modèle au budget de tokens : « Les tailles d’image arbitraires sont autorisées, mais gardez à l’esprit que les images plus grandes consommeront davantage de tokens et entraîneront plus de latence »¹. Une image n’est pas un contexte gratuit. Elle puise dans le même budget que votre texte, ce qui constitue la première décision de conception que le multimodal vous impose, et la raison pour laquelle la taille du contexte (abordée plus bas) devient déterminante.

Parce que l’entrée d’image s’appuie sur le prompt builder existant, toute la mécanique d’iOS 26 demeure intacte. La génération guidée façonne toujours la sortie en un type @Generable. Le protocole Tool permet toujours au modèle d’appeler votre code. Le streaming continue de diffuser. Le modèle a gagné un sens, pas un nouveau modèle de programmation.

Le lien avec la compréhension d’image : Foundation Models et Vision ne sont pas rivaux

La session 237, « Les nouveautés de la compréhension d’image », est l’endroit où Apple trace la ligne entre les deux façons d’analyser une image, et cette distinction est ce qu’il y a de plus utile dans l’une ou l’autre présentation pour décider quoi construire. L’ouverture en dit long : l’ordre du jour de la présentatrice s’est volatilisé, elle photographie ses pense-bêtes et demande « à un grand modèle de langage de générer un ordre du jour. C’est assez facile à faire avec le framework Foundation Models. Heureusement, cette année, Foundation Models prend en charge les entrées d’image »². Voilà tout l’argumentaire du versant descriptif du multimodal : légender des images, suggérer des améliorations de décoration intérieure à partir de la photo d’une pièce, générer une recette à partir d’une photo de réfrigérateur. Le verdict de la présentatrice sur les points forts du LLM : « Les modèles tendent à bien réussir les tâches descriptives »².

Vient ensuite la comparaison honnête. « Le framework Foundation Models s’appuie sur de grands modèles de langage, qui peuvent faire presque tout ce que vous leur demandez. En comparaison, les frameworks traditionnels de traitement d’image, comme Vision, utilisent un ensemble figé d’API de vision par ordinateur. Les API Vision sont finement ajustées pour des tâches spécifiques, qu’elles accomplissent vraiment très bien. Et Vision est rapide. Souvent assez rapide pour analyser des trames vidéo en temps réel »². Lisez cela comme une règle d’aiguillage. Une question ouverte sur une image fixe, dont vous attendez du langage en retour ? Foundation Models. Une tâche spécifique et bien définie, à la cadence des trames vidéo (détection de visage, posture, saillance, segmentation) ? Vision. Le LLM est un généraliste qui réfléchit ; l’API Vision est un spécialiste qui s’exécute.

La chute d’Apple, c’est que vous n’avez pas à choisir : « vous n’avez pas toujours à choisir entre Vision et Foundation Models pour analyser vos images. Il existe un moyen de tirer parti de l’expertise de Vision avec la polyvalence de Foundation Model, grâce à l’appel d’outils »². L’appel d’outils d’iOS 27 prend désormais en charge les arguments image. Lorsqu’un modèle ne parvient pas à identifier quelque chose par lui-même (la présentation prend l’exemple de l’identification de plantes), il appelle un outil et, « plutôt que de passer l’image entière en argument, le modèle passe plutôt une référence vers l’image »². Cette référence, une ImageReference, « doit être une référence vers une image existante de la session de chat en cours »², que l’outil résout en pièce jointe à travers l’historique de la session, prête à l’analyse. La boucle de contrôle ainsi que les OCRTool et BarcodeReaderTool intégrés font l’objet de l’article compagnon, le contrôle de l’appel d’outils sous iOS 27 ; ici, le propos est plus restreint : l’entrée d’image et les outils à argument image sont deux couches d’une même pile multimodale, et elles se composent.

Le multimodal sur Private Cloud Compute : même invite, plus d’espace

La session 319 s’ouvre en confirmant d’un coup les deux moitiés de l’histoire multimodale. Le modèle embarqué « prend désormais en charge l’entrée d’image, suit mieux les instructions et appelle vos outils personnalisés »³, et pour les cas plus lourds il existe un nouveau modèle serveur sur Private Cloud Compute. Si multimodal et PCC appartiennent à la même conversation, c’est à cause de la taille du contexte. Apple énonce les chiffres sans détour : « Le modèle embarqué offre 4k, et avec PCC vous obtenez 32K »³. Une image puise des tokens dans ce budget¹ ; ainsi, une invite portant du texte et plusieurs images est précisément le genre de charge utile qui met 4K sous tension et tient confortablement dans 32K.

La démo du résumeur rend l’adéquation concrète. « J’ai ici une app qui résume un article à l’aide du modèle PCC. Je peux sélectionner un fichier markdown, et nous prenons le texte et les images, nous les transmettons à une LanguageModelSession et nous générons un résumé. Cela fonctionne à merveille avec la grande taille de contexte qu’offre PCC »³. Texte et images, une session, une invite. Le coût de migration de l’embarqué vers le serveur tient en une ligne : Apple montre qu’« en ne changeant qu‘1 seule ligne de code, vous pouvez basculer vers le nouveau modèle serveur sur PCC »³, car « le framework Foundation Models propose une API Swift unifiée, quel que soit le modèle avec lequel vous dialoguez »³. La génération guidée avec Generable et l’appel d’outils « fonctionnent exactement de la même façon avec le modèle PCC qu’avec le modèle embarqué »³.

PCC ajoute le raisonnement, dont l’embarqué est dépourvu, et le raisonnement a un coût pertinent pour le multimodal : « le raisonnement, c’est du texte supplémentaire que le modèle génère. Il consomme donc des tokens. Cela compte dans votre limite de taille de contexte »³. Associez un raisonnement approfondi à plusieurs images en pleine résolution dans une même invite, et vous dépensez le budget de 32K par les deux bouts. Les détails plus fins (les trois niveaux de raisonnement, la gestion de la limite quotidienne via quotaUsage et isLimitReached, l’entitlement que vous demandez sur le site développeur) relèvent de l’analyse approfondie de Private Cloud Compute ; l’enseignement multimodal, c’est que la même invite porteuse d’image s’exécute sur les deux modèles, et que le modèle serveur existe pour le moment où l’invite dépasse les capacités de l’appareil.

Adopter l’entrée d’image

Une courte liste de contrôle qui découle des contrats ci-dessus.

Commencez en embarqué, mesurez, puis décidez. Le conseil d’Apple est de choisir le modèle « sur la base de données, pas seulement d’impressions »³, et elle avertit que « vous pourriez être surpris de voir à quel point le modèle embarqué se débrouille bien sur certaines tâches, surtout avec le modèle mis à jour cette année »³. Une légende ou une requête du type « qu’est-ce que cet objet » n’aura peut-être jamais besoin de PCC. Tournez-vous vers le modèle serveur lorsque l’invite porte plusieurs images ou un texte long qui déborde la fenêtre embarquée de 4K³.

Choisissez le type source le moins coûteux pour votre pipeline. Vous pouvez fournir au modèle une UIImage, une NSImage, une CGImage, un type Core Image, un CVPixelBuffer ou une URL de fichier¹. Si une trame existe déjà sous forme de pixel buffer issu de l’appareil photo ou de fichier sur disque, transmettez-la directement plutôt que de faire un aller-retour par UIImage.

Traitez la résolution de l’image comme un bouton de budget, non comme un cadran de qualité. Toute taille et tout ratio sont permis¹, alors résistez au rognage excessif pour la forme. Mais comme les images plus grandes coûtent plus de tokens et plus de latence¹, réduisez une photo de 48 mégapixels avant qu’elle n’entre dans une invite quand la tâche (lire ce panneau, quelle est cette pièce) n’a pas besoin de chaque pixel.

Aiguillez par la tâche, non par réflexe. Le travail descriptif, ouvert, à sortie langagière va vers Foundation Models ; le travail de vision par ordinateur figé, rapide, en temps réel va vers Vision ; quand vous avez besoin des deux, appelez Vision depuis l’intérieur d’un outil Foundation Models². Les deux frameworks sont des couches complémentaires, et l’outil à argument image est la couture qui les relie.

Conservez la vérification de disponibilité. L’entrée d’image s’appuie sur le même modèle, et ce modèle n’est « disponible que sur les appareils Apple Intelligence »³. Vérifiez l’API de disponibilité et dégradez en douceur là où Apple Intelligence est absent³.

FAQ

Comment envoyer une image au modèle Foundation Models sous iOS 27 ?

Vous insérez une pièce jointe image dans votre invite aux côtés du texte, à l’aide du prompt builder existant, puis vous demandez au modèle de répondre. Apple décrit l’API comme « un prolongement naturel des prompt builders existants » : créez une session, « insérez simplement une pièce jointe image dans votre invite, avec du texte », et « le modèle peut répondre aux questions portant sur l’image »¹. Aucun pipeline Vision distinct ni aucun nouveau type de session n’entre en jeu.

Quels types d’image puis-je passer à Foundation Models ?

Les pièces jointes image peuvent être créées à partir de UIImage, NSImage, CGImage, des types Core Image, des pixel buffers CoreVideo et des URL de fichiers¹. La transcription énumère ces types source ; elle ne détaille pas chaque signature d’initialiseur, laissez donc le SDK d’iOS 27 fournir le site d’appel exact.

Dois-je redimensionner ou rogner les images avant de les envoyer ?

Non. « Le modèle prend en charge les images de toute taille et de tout ratio, vous n’avez donc pas besoin de rogner ni d’ajouter des marges pour obtenir une forme particulière »¹. Le compromis porte sur le coût, pas sur la légalité : « les images plus grandes consommeront davantage de tokens et entraîneront plus de latence »¹, aussi réduire une très grande photo est-il une décision de budget lorsque la tâche n’a pas besoin de la pleine résolution.

Quand devrais-je utiliser Vision plutôt que Foundation Models pour une image ?

Utilisez Vision pour les tâches figées, bien définies et critiques en vitesse. Apple note que Vision « utilise un ensemble figé d’API de vision par ordinateur », est « finement ajustée pour des tâches spécifiques » et est « souvent assez rapide pour analyser des trames vidéo en temps réel », tandis que Foundation Models « peut faire presque tout ce que vous lui demandez » et excelle aux tâches descriptives². Quand vous voulez les deux, appelez un outil adossé à Vision depuis une session Foundation Models via l’appel d’outils².

L’entrée d’image fonctionne-t-elle avec le modèle serveur Private Cloud Compute ?

Oui. Apple confirme que le modèle embarqué « prend désormais en charge l’entrée d’image »³, et la démo PCC transmet « le texte et les images » d’un document à une LanguageModelSession pour le résumer³. La même API Swift unifiée s’exécute sur les deux modèles, si bien que la même invite porteuse d’image fonctionne en embarqué ou sur le serveur au prix d’une seule ligne. Le contexte de 32K de PCC (contre 4K en embarqué) offre plus d’espace aux invites multi-images³.

L’ensemble du cluster Apple Ecosystem : l’explication du framework Foundation Models ; le LLM embarqué ; le contrôle de l’appel d’outils sous iOS 27 ; et l’analyse approfondie de Private Cloud Compute. Le point central est la série Apple Ecosystem. Pour un contexte plus large d’iOS avec des agents d’IA, consultez le guide de développement d’agents iOS.