Le framework Vision d'Apple : ce qui est intégré et pour lequel la plupart des développeurs se tournent vers les APIs cloud

Le framework Vision d’Apple, celui sans le suffixe « OS », propose plus de deux douzaines d’opérations de vision par ordinateur exécutées sur l’appareil. La plupart des développeurs iOS se tournent par défaut vers l’API OpenAI Vision, Google Cloud Vision ou AWS Rekognition pour des tâches que le framework effectue en quelques microsecondes sur le Neural Engine de l’appareil. Ce choix par défaut reflète davantage un biais qu’une évaluation : les APIs cloud font « IA moderne » tandis que Vision fait « plomberie de la plateforme », alors la plateforme est ignorée. Ce biais méconnaît ce que la plateforme contient désormais.

Vision est le framework de CV local-first. Il s’exécute sur le Neural Engine quand il est disponible, sur le GPU sinon, et sur le CPU en dernier recours. L’inférence se fait en quelques millisecondes pour la plupart des opérations. Le framework ne coûte rien par appel. Les données ne quittent jamais l’appareil. La clé d’API n’existe pas, parce qu’aucune API n’existe. Pour la majorité du travail de vision par ordinateur que fait une application iOS, c’est l’outil approprié.

TL;DR

• Apple Vision propose plus de deux douzaines d’opérations de CV sur l’appareil : reconnaissance de texte, détection de visages et points de repère, estimation de pose corporelle et de la main, lecture de codes-barres, segmentation de documents, embeddings d’images, saillance, détection d’animaux, contours, trajectoires, flux optique, et un exécuteur pour n’importe quel modèle Core ML.
• Chaque opération s’exécute en quelques millisecondes sur le Neural Engine, ne coûte rien par appel, ne nécessite aucun réseau et ne produit aucune télémétrie tierce.
• Les APIs cloud gagnent dans un cas spécifique : le raisonnement sémantique complexe sur une image (un LLM multimodal qui comprend un graphique, un mème ou l’intention d’un document). Pour les opérations au niveau du pixel (trouver des visages, lire du texte, détecter une main), Vision l’emporte sur le coût, la latence et la confidentialité.
• Le lien avec les workflows d’agents : les résultats de Vision alimentent les App Intents et les appels au LLM Foundation Models sur l’appareil sans aller-retour réseau. L’ensemble du pipeline s’exécute localement.

Ce que contient réellement Vision

Vision regroupe ses opérations sous forme de types VNRequest. Une requête est créée, configurée avec des paramètres, alimentée d’une image (ou CVPixelBuffer, ou CIImage, ou CGImage, ou URL), puis exécutée. Les résultats reviennent sous forme d’observations attachées à la requête. Les catégories ci-dessous couvrent le territoire du framework tel qu’il existe à partir d’iOS 26.

Reconnaissance de texte

VNRecognizeTextRequest effectue de l’OCR. La requête prend en charge recognitionLevel (.fast pour les flux caméra en direct, .accurate pour la numérisation de documents), des indices de langue, des listes de mots personnalisées et la confiance des boîtes englobantes. Le chemin précis sur iOS 18+ rivalise avec les APIs OCR commerciales sur les reçus, panneaux et documents imprimés ; la reconnaissance de l’écriture manuscrite est prise en charge dans plusieurs langues.

let request = VNRecognizeTextRequest { request, error in
    guard let observations = request.results as? [VNRecognizedTextObservation] else { return }
    let lines = observations.compactMap { $0.topCandidates(1).first?.string }
    print(lines.joined(separator: "\n"))
}
request.recognitionLevel = .accurate
request.usesLanguageCorrection = true
request.recognitionLanguages = ["en-US"]

let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

La même opération via l’API OpenAI Vision coûte environ une fraction de centime par appel en mode basse définition et nettement plus en mode haute définition, prend 1 à 3 secondes aller-retour, et envoie l’image vers les serveurs d’OpenAI. Vision retourne les résultats en 100 à 300 ms localement, gratuitement, sans exfiltration de données.

Détection de visages et points de repère

Trois couches d’analyse de visage sont fournies dans Vision :

• VNDetectFaceRectanglesRequest retourne les boîtes englobantes pour chaque visage dans l’image.
• VNDetectFaceLandmarksRequest retourne les régions de points de repère structurées par visage (mâchoire, bouche, yeux, sourcils, nez, pupilles), chacune avec plusieurs points clés.
• VNDetectFaceCaptureQualityRequest retourne un score de qualité que l’application Caméra utilise pour le timing de capture des selfies.

Pour la plupart des applications qui ont besoin de trouver des visages, recadrer sur les visages, flouter des visages ou compter des visages, la requête de rectangles est l’outil approprié. Pour les applications qui animent quelque chose en fonction du visage de l’utilisateur (filtres, masques, suivi), les points de repère plus le suivi des pupilles sont les outils appropriés. Rien de tout cela ne nécessite un fichier de modèle ou un appel réseau.

Pose corporelle et de la main

VNDetectHumanBodyPoseRequest retourne les 19 articulations nommées dans VNHumanBodyPoseObservation.JointName⁴ (nez, cou, épaules, coudes, poignets, hanches, genoux, chevilles, oreilles, yeux, racine) avec des coordonnées 2D et une confiance par articulation. VNDetectHumanBodyPose3DRequest étend la topologie dans l’espace 3D sur les appareils équipés d’un scanner LiDAR. VNDetectHumanHandPoseRequest retourne 21 points de repère de la main à la résolution des articulations des doigts.

La pose corporelle est ce que les applications de fitness utilisent pour compter les répétitions sans appareil portable, ce que les applications AR utilisent pour attacher du contenu virtuel aux mains de l’utilisateur, et ce que les applications de posture utilisent pour évaluer la forme. La pose de la main pilote la reconnaissance de gestes (l’utilisateur lève deux doigts, l’application voit deux doigts). Les deux fonctionnent à 60 ips sur un Neural Engine d’iPhone récent. Les équivalents cloud sont Google MediaPipe ou des APIs propriétaires de fitness-tech, que le framework remplace.

Codes-barres et QR

VNDetectBarcodesRequest lit les symbologies dont la plupart des workflows de retail et d’inventaire ont besoin (QR, PDF417, Aztec, Code 128, Code 39, EAN-13, ITF14, Data Matrix, GS1 DataBar, et plus) et retourne la charge utile brute ainsi que le rectangle englobant. La détection s’effectue en quelques millisecondes et fonctionne dans des conditions de faible luminosité que l’application Caméra d’Apple valide déjà.

Segmentation de documents

VNDetectDocumentSegmentationRequest trouve les documents rectangulaires dans une image et retourne leurs points de coin, en tenant compte de la perspective. C’est ce que les applications de scanner de documents utilisent pour recadrer et redresser le document en une image plate. Le framework VisionKit d’Apple enveloppe la requête plus une UI, mais l’opération sous-jacente est appelable directement quand une application a besoin d’une UI personnalisée.

Saillance et esthétique

VNGenerateAttentionBasedSaliencyImageRequest retourne une carte de chaleur indiquant où l’attention d’un spectateur est susceptible de se concentrer dans une image. VNGenerateObjectnessBasedSaliencyImageRequest retourne une carte de chaleur indiquant où se trouvent les objets. VNCalculateImageAestheticsScoresRequest, ajoutée comme API publique dans iOS 18¹, retourne des scores de qualité esthétique incluant une classification utilitaire (mémos, captures d’écran) et une valeur esthétique. Ces scores sont ce que Photos utilise pour faire émerger des candidats « Souvenirs » et ce qui alimente les décisions de recadrage automatique.

Classification d’images et embeddings

VNClassifyImageRequest retourne les N premières étiquettes de catégorie pour une image en utilisant un classificateur intégré (plus de 1 000 catégories à partir d’un modèle entraîné sur des données à l’échelle du web). VNGenerateImageFeaturePrintRequest retourne un vecteur de caractéristiques (l’embedding du modèle) adapté à la recherche par similarité d’images.

Les embeddings sont la manière dont une application Photos, le « trouver des plats similaires » d’une application de recettes, ou la déduplication par similarité d’une application de moodboard fonctionnent réellement. L’équivalent cloud, c’est les embeddings OpenAI CLIP ou Vertex AI de Google ; Vision les retourne localement et gratuitement.

Suivi d’objets et trajectoires

VNDetectTrajectoriesRequest suit les objets en mouvement à travers les images et retourne des ajustements de trajectoire parabolique (une balle lancée, une flèche tirée). VNTrackObjectRequest suit un objet délimité manuellement à travers une séquence vidéo.

Les trajectoires sont la primitive sous-jacente pour les applications sportives (suivi d’une balle de baseball, d’un ballon de basket, d’une balle de tennis). La détection fonctionne sur un flux AVFoundation en direct et retourne les résultats en temps réel.

Modèles personnalisés via VNCoreMLRequest

VNCoreMLRequest exécute n’importe quel modèle Core ML via le pipeline Vision. La requête gère automatiquement le prétraitement (redimensionnement d’image, conversion d’espace colorimétrique, normalisation) en fonction de la description d’entrée du modèle. Une application entraîne un classificateur personnalisé dans Create ML (une poignée de catégories, une centaine d’images d’échantillon par catégorie, dix minutes d’entraînement) ou télécharge un modèle publié, dépose le .mlpackage dans le bundle de l’application et l’exécute via Vision avec trois lignes de code.

let model = try VNCoreMLModel(for: MyClassifier(configuration: .init()).model)
let request = VNCoreMLRequest(model: model) { request, error in
    let results = request.results as? [VNClassificationObservation]
    print(results?.first?.identifier, results?.first?.confidence)
}
let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

L’équivalent cloud pour un classificateur personnalisé consiste à héberger le modèle sur un serveur, payer pour le calcul d’inférence, gérer l’API et accepter la latence réseau. Vision le transforme en un .mlpackage dans le bundle de l’application et un gestionnaire de requêtes.

Là où les APIs cloud gagnent vraiment

Le territoire de Vision, ce sont les opérations au niveau du pixel : trouve cette chose, classifie cette image, reconnais ce texte. Le framework ne fournit pas de raisonnement sémantique complexe sur le sens d’une image. Trois cas où les APIs cloud sont le bon choix :

Compréhension par LLM multimodal. « Que fait cette personne dans cette image ? » « Ce graphique est-il trompeur ? » « Traduis ce menu et dis-moi quels plats sont végétariens. » Aucune de ces questions n’est au niveau du pixel. Elles requièrent un grand modèle multimodal pour combiner perception visuelle, connaissance du monde et langage. Foundation Models d’Apple (le LLM sur l’appareil, abordé dans Foundation Models on-device LLM) commence à gérer une partie de cela sur l’appareil, mais pour le raisonnement complexe, GPT-4o, Claude Sonnet ou Gemini l’emportent encore.

Tâches personnalisées one-shot sans données d’entraînement. Le modèle de classification de Vision est figé ; les modèles Core ML personnalisés requièrent des données d’entraînement. Un LLM multimodal peut répondre à « est-ce une photo d’un chat avec un nœud papillon ? » sans avoir vu un seul exemple d’entraînement étiqueté. Pour le prototypage ou les tâches ponctuelles où collecter des données d’entraînement coûte trop cher, les LLMs cloud sont l’outil approprié.

Intelligence documentaire au-delà de l’OCR. L’OCR de Vision retourne du texte. Une API d’intelligence documentaire (AWS Textract, Google Document AI, Azure Form Recognizer) retourne des champs structurés : numéro de facture, date, articles, totaux. La structuration est la valeur ajoutée, pas l’OCR. Pour des workflows documentaires à forte valeur, les APIs cloud sont généralement appropriées ; pour « lis ce reçu et sors le texte », c’est Vision.

Le schéma : le cloud gagne sur le raisonnement et sur les APIs verticales hautement spécialisées ; Vision gagne sur les primitives de perception.

Comparaison honnête de latence et de coût

Un pipeline d’inférence représentatif s’exécutant sur iPhone 16 Pro (puce A18 Pro) :

Les chiffres ci-dessus sont dérivés des benchmarks publics d’Apple et de mesures rapportées par les développeurs ; le message est l’ordre de grandeur, pas le chiffre exact. Les avantages de Vision résident dans le coût (zéro par appel), dans la latence de queue (pas de gigue réseau) et dans la confidentialité (les données ne quittent jamais l’appareil).

Le coût se cumule lorsqu’une application appelle fréquemment des opérations de vision. Une application de retouche photo qui traite 100 images par session coûte de l’ordre de plusieurs dollars par session via les APIs cloud, et zéro via Vision.

Le lien avec les workflows d’agents

Vision se marie naturellement avec deux idées du cluster déjà publiées :

Outils App Intents pour Apple Intelligence. Quand l’application expose une capacité « Trouver des visages dans mes photos » ou « Lire le texte d’une capture d’écran » via un AppIntent, la méthode perform de l’intent exécute Vision localement et retourne un résultat structuré. L’orchestrateur d’Apple Intelligence peut appeler l’intent sans envoyer la photo de l’utilisateur vers un serveur. L’article sur les App Intents parcourt le contrat de surface.

LLM Foundation Models sur l’appareil. Un pipeline qui a besoin à la fois de perception et de raisonnement exécute Vision en premier (extraire le texte, trouver les visages, localiser les objets) et Foundation Models en second (raisonner sur ce qui a été trouvé, générer un résumé). Les deux étapes s’exécutent sur l’appareil. Total des appels réseau : zéro. L’article sur Foundation Models explique comment appeler le LLM ; cet article soutient que Vision est ce qui l’alimente sans aller-retour cloud.

let textRequest = VNRecognizeTextRequest()
textRequest.recognitionLevel = .accurate

let handler = VNImageRequestHandler(cgImage: receiptImage, options: [:])
try handler.perform([textRequest])

let extractedText = (textRequest.results ?? [])
    .compactMap { ($0 as? VNRecognizedTextObservation)?.topCandidates(1).first?.string }
    .joined(separator: "\n")

let llmResponse = await foundationModel.generate(
    "Summarize this receipt as JSON with merchant, total, and date fields:\n\(extractedText)"
)

L’ensemble du pipeline s’exécute sur l’appareil. Aucune clé d’API. Aucun appel réseau. Aucune exposition de données à des tiers.

Ce qui a mûri au cours des deux dernières versions

Trois ajouts à mentionner, datés de manière conservatrice par rapport aux notes de version d’Apple² :

Notation esthétique comme API publique (iOS 18). VNCalculateImageAestheticsScoresRequest retourne des scores incluant la classification utilitaire et la valeur esthétique, remplaçant ce que les applications de curation photo devaient auparavant approximer avec des modèles Core ML personnalisés.

OCR multilingue amélioré. VNRecognizeTextRequest a élargi son support des écritures non-latines au fil des versions récentes, réduisant l’écart avec les services OCR cloud qui avaient historiquement une couverture multilingue plus solide. La documentation Apple sur la reconnaissance de texte liste les langues prises en charge actuellement³.

Segmentation de documents avec intégration VisionKit. VNDetectDocumentSegmentationRequest trouve les documents rectangulaires et retourne les points de coin ; le DataScannerViewController de VisionKit enveloppe la requête avec une UI conçue pour la numérisation de documents en direct.

Les capacités phares du framework (visage, texte, pose, code-barres, embeddings) sont matures depuis plusieurs versions d’iOS. Le schéma : étendre plutôt que réinventer.

Pourquoi la plupart des développeurs ignorent Vision

Trois raisons pour lesquelles le framework est ignoré malgré un argumentaire clair :

Habitude cloud-first. La plupart du développement IA moderne se fait d’abord contre des APIs cloud. Les développeurs savent comment appeler OpenAI ; la surface d’API de VNRecognizeTextRequest plus VNImageRequestHandler plus VNRecognizedTextObservation ressemble à plus d’API à apprendre pour ce qui est, en pratique, moins de lignes de code.

Mauvaise estimation des capacités. Les développeurs qui n’ont pas regardé le framework récemment supposent qu’il ne couvre que l’OCR et les codes-barres. La liste de catégories ci-dessus comprend plus d’une dizaine de capacités, dont plusieurs n’ont pas d’équivalent cloud-natif et plusieurs égalent les APIs commerciales sans le coût.

Divergence prototype-production. Les APIs cloud gagnent au stade du prototypage initial (une commande curl pour obtenir un résultat), et le prototype est transformé en pipeline de production sans réévaluation. Le bon mouvement est de prototyper avec ce qui est le plus rapide et de réévaluer la couche de perception une fois que le workflow est réel.

La solution n’est pas de refuser les APIs cloud ; la solution est de savoir ce que la plateforme contient pour que le choix soit réel.

Ce que ce schéma signifie pour les applications iOS 26+

Trois enseignements.

1. Préférer Vision par défaut pour les primitives de perception. Trouver des visages, lire du texte, détecter des codes-barres, exécuter une estimation de pose, obtenir des embeddings d’images. Le framework s’exécute en quelques microsecondes sur le Neural Engine, ne coûte rien, ne laisse aucune trace de données chez un tiers. Pour les opérations de CV au niveau du pixel, le framework est le bon point de départ.

2. Utiliser les APIs cloud pour le raisonnement, pas la perception. Un LLM multimodal qui comprend le sens d’une image, une API verticale d’intelligence documentaire qui extrait des champs structurés, une tâche personnalisée one-shot sans données d’entraînement. C’est le territoire du cloud ; le lui céder est correct.

3. Associer Vision à Foundation Models pour des pipelines entièrement sur l’appareil. La perception (Vision) alimente le raisonnement (LLM sur l’appareil). Le pipeline s’exécute localement de bout en bout, sans clés d’API, sans gigue réseau et sans télémétrie quittant l’appareil. L’article du cluster sur Foundation Models couvre la moitié LLM ; Vision est la moitié d’entrée.

Le cluster Apple Ecosystem complet : les App Intents typés ; les serveurs MCP ; la question du routage ; Foundation Models ; la distinction entre LLM runtime et outillage ; les trois surfaces ; le pattern de source unique de vérité ; Two MCP Servers ; les hooks pour le développement Apple ; les Live Activities ; le contrat runtime watchOS ; les internes de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les patterns Liquid Glass ; la livraison multi-plateformes ; la matrice des plateformes ; ce sur quoi je refuse d’écrire. Le hub se trouve à la série Apple Ecosystem. Pour le contexte plus large iOS-avec-agents-IA, consultez le guide iOS Agent Development.

FAQ

Quelle est la différence entre Apple Vision et visionOS ?

Le framework Vision est l’API de vision par ordinateur sur l’appareil pour iOS, macOS et visionOS. visionOS est le système d’exploitation pour Apple Vision Pro. Le chevauchement de noms est malheureux. Vision (le framework) s’exécute sur tous les appareils Apple modernes ; visionOS (l’OS) s’exécute spécifiquement sur le matériel Vision Pro.

Quand utiliser Vision plutôt que l’API OpenAI Vision ou Google Cloud Vision ?

Pour les tâches de perception au niveau du pixel (trouver des visages, lire du texte, détecter des objets, compter des éléments, estimer une pose, générer des embeddings d’images), Vision est presque toujours le bon choix. Il s’exécute en quelques millisecondes, ne coûte rien par inférence et garde les données utilisateur sur l’appareil. Les APIs cloud sont appropriées quand la tâche requiert un raisonnement sémantique complexe sur le sens d’une image, ou quand une API verticale d’intelligence documentaire fournit des champs structurés au-delà de l’extraction de texte.

Puis-je exécuter mon propre modèle Core ML via Vision ?

Oui. VNCoreMLRequest enveloppe n’importe quel modèle Core ML et gère automatiquement le prétraitement. Déposez le fichier .mlpackage dans le bundle de l’application, instanciez le modèle, enveloppez-le dans un VNCoreMLModel et exécutez-le via un gestionnaire de requêtes. Le même gestionnaire peut exécuter plusieurs requêtes en parallèle, y compris les requêtes Vision intégrées et le modèle Core ML personnalisé.

Comment fonctionne le dispatch de Vision sur Apple Silicon ?

Vision (et les modèles Core ML qu’il exécute) dispatche automatiquement vers le Neural Engine quand il est disponible, se rabat sur le GPU sinon, et sur le CPU en dernier recours. Le framework choisit le chemin le plus rapide pour l’appareil et l’opération. Pour la plupart des iPhones modernes (A12 Bionic et ultérieurs), le Neural Engine gère l’essentiel de l’inférence ; le développeur ne configure pas le dispatch manuellement.

Qu’est-ce qui a été ajouté récemment ?

Le résumé conservateur, daté par rapport aux notes de version d’Apple : VNCalculateImageAestheticsScoresRequest a été ajoutée comme API publique dans iOS 18 ; VNRecognizeTextRequest a élargi son support multilingue au fil des versions récentes ; le DataScannerViewController de VisionKit enveloppe la numérisation de documents dans une UI conçue. Les capacités phares (texte, visage, pose, codes-barres, embeddings) sont matures depuis plusieurs versions d’iOS.

Références