Apple Vision Framework : la CV on-device que la plupart des devs ignorent

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 rabattent par défaut sur OpenAI Vision API, Google Cloud Vision ou AWS Rekognition pour des tâches que le framework exécute en millisecondes sur le Neural Engine de l’appareil. Ce choix par défaut reflète plus un biais qu’une évaluation : les APIs cloud donnent une impression d’« IA moderne » et Vision celle de « plomberie de plateforme », alors la plateforme est mise de côté. Ce biais interprète mal ce que la plateforme contient désormais.

Vision est le framework CV local-first. Il s’exécute sur le Neural Engine quand celui-ci est disponible, sur le GPU sinon, et sur le CPU en dernier recours. L’inférence prend 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é API n’existe pas, parce qu’aucune API n’existe. Pour la plupart des travaux de vision par ordinateur d’une app iOS, c’est le bon outil.

TL;DR

• Apple Vision propose plus de deux douzaines d’opérations CV on-device : reconnaissance de texte, détection de visages et de points caractéristiques, estimation de la posture du corps et des mains, 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 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 l’emportent dans un cas précis : 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 agentiques : les résultats de Vision alimentent les App Intents et les appels au LLM on-device de Foundation Models sans aller-retour réseau. L’ensemble du pipeline s’exécute localement.

Ce que Vision contient réellement

Vision regroupe ses opérations en types VNRequest. Une requête est créée, configurée avec des paramètres, alimentée avec une image (ou un CVPixelBuffer, ou un CIImage, ou un CGImage, ou une URL) et 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 sous 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 indications de langue, des listes de mots personnalisées et la confiance des bounding boxes. Le chemin .accurate sous iOS 18+ traite bien le texte imprimé sur les reçus, la signalétique et les documents ; la reconnaissance d’écriture manuscrite est prise en charge dans un sous-ensemble de langues (voir la liste des langues de reconnaissance d’Apple³).

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 renvoie les résultats en 100 à 300 ms localement, gratuitement, sans exfiltration de données.

Détection de visages et points caractéristiques

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

• VNDetectFaceRectanglesRequest renvoie les bounding boxes de chaque visage présent dans l’image.
• VNDetectFaceLandmarksRequest renvoie des régions de points caractéristiques structurées par visage (mâchoire, bouche, yeux, sourcils, nez, pupilles), chacune comportant plusieurs keypoints.
• VNDetectFaceCaptureQualityRequest renvoie un score de qualité par visage (0 à 1) reflétant l’éclairage, la netteté et le centrage. Les apps peuvent l’utiliser pour conditionner la capture d’un selfie ou choisir automatiquement la meilleure image d’une rafale.

Pour la plupart des apps qui doivent trouver des visages, recadrer sur les visages, flouter des visages ou compter des visages, la requête de rectangles est le bon outil. Pour les apps qui animent un élément sur le visage de l’utilisateur (filtres, masques, suivi), les points caractéristiques associés au suivi des pupilles sont le bon outil. Rien de tout cela ne nécessite de fichier de modèle ni d’appel réseau.

Posture du corps et des mains

VNDetectHumanBodyPoseRequest renvoie les 19 articulations nommées de 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 et renvoie des résultats VNHumanBodyPose3DObservation ; la requête utilise les données de profondeur (AVDepthData) lorsque l’appareil les expose pour améliorer la précision, mais ne nécessite pas de scanner LiDAR.⁴ VNDetectHumanHandPoseRequest renvoie 21 points caractéristiques de la main à la résolution des articulations des doigts.

La posture corporelle est ce que les apps de fitness utilisent pour compter les répétitions sans accessoire connecté, ce que les apps AR utilisent pour attacher du contenu virtuel aux mains de l’utilisateur, et ce que les apps de posture utilisent pour évaluer la forme. La posture des mains pilote la reconnaissance de gestes (l’utilisateur lève deux doigts, l’app voit deux doigts). Les deux peuvent s’exécuter à la fréquence des images vidéo sur les iPhone récents, suffisante pour l’AR en direct et la saisie gestuelle. 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 davantage) et renvoie la charge utile brute ainsi que le rectangle englobant. La détection s’exécute en millisecondes et fonctionne dans des conditions de faible luminosité que l’app Camera d’Apple valide déjà.

Segmentation de documents

VNDetectDocumentSegmentationRequest trouve des documents rectangulaires dans une image et renvoie leurs points d’angle, en tenant compte de la perspective. Cette requête est ce que les apps 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 app a besoin d’une UI personnalisée.

Saillance et esthétique

VNGenerateAttentionBasedSaliencyImageRequest renvoie une heatmap des zones où l’attention d’un observateur est la plus susceptible de se concentrer dans une image. VNGenerateObjectnessBasedSaliencyImageRequest renvoie une heatmap des zones où se trouvent les objets. VNCalculateImageAestheticsScoresRequest, ajoutée en tant qu’API publique sous iOS 18¹, renvoie 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 les candidats « Souvenirs » et ce qui alimente les décisions de recadrage automatique.

Classification d’images et embeddings

VNClassifyImageRequest renvoie les top-N étiquettes de catégorie d’une image en utilisant un classifieur intégré couvrant des centaines de catégories d’objets courants.⁵ VNGenerateImageFeaturePrintRequest renvoie 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 app Photos, la fonction « trouver des plats similaires » d’une app de recettes ou la déduplication par similarité d’une app de moodboard fonctionne réellement. L’équivalent cloud, ce sont les embeddings OpenAI CLIP ou Vertex AI de Google ; Vision les renvoie localement, gratuitement.

Suivi d’objets et trajectoires

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

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

Modèles personnalisés via VNCoreMLRequest

VNCoreMLRequest exécute n’importe quel modèle Core ML à travers le pipeline Vision. La requête gère automatiquement le prétraitement (redimensionnement de l’image, conversion d’espace colorimétrique, normalisation) en fonction de la description d’entrée du modèle. Une app entraîne un classifieur personnalisé dans Create ML (une poignée de catégories, une centaine d’images d’exemple 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’app, 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 classifieur personnalisé consiste à héberger le modèle sur un serveur, à payer le calcul d’inférence, à gérer l’API et à accepter la latence réseau. Vision en fait un .mlpackage dans le bundle de l’app et un gestionnaire de requêtes.

Là où les APIs cloud l’emportent réellement

Le territoire de Vision, ce sont les opérations au niveau du pixel : trouver cette chose, classer cette image, reconnaître 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 un LLM multimodal. « Que fait cette personne sur cette image ? » « Ce graphique est-il trompeur ? » « Traduisez ce menu et dites-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 capable de combiner perception visuelle, connaissance du monde et langage. Foundation Models d’Apple (le LLM on-device, traité 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 en one-shot sans données d’entraînement. Le modèle de classification de Vision est figé ; les modèles Core ML personnalisés nécessitent 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 des tâches ponctuelles où collecter des données d’entraînement coûte trop cher, les LLMs cloud sont le bon outil.

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

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

Comparaison honnête de la latence et des coûts

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

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

Le coût se cumule quand une app appelle fréquemment des opérations de vision. Une app 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 agentiques

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

Outils App Intents pour Apple Intelligence. Quand l’app 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 renvoie un résultat structuré. L’orchestrateur d’Apple Intelligence peut appeler l’intent sans envoyer la photo de l’utilisateur sur un serveur. Le billet sur App Intents parcourt le contrat de surface.

LLM on-device Foundation Models. Un pipeline qui a besoin à la fois de perception et de raisonnement exécute d’abord Vision (extraire du texte, trouver des visages, localiser des objets) puis Foundation Models (raisonner sur ce qui a été trouvé, générer un résumé). Les deux étapes s’exécutent on-device. Total des appels réseau : zéro. Le billet sur Foundation Models explique comment appeler le LLM ; ce billet 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. Pas de clé API. Pas d’appel réseau. Pas d’exposition de données à un tiers.

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

Trois ajouts à mentionner, avec un datage prudent par rapport aux notes de version d’Apple² :

Scoring d’esthétique en tant qu’API publique (iOS 18). VNCalculateImageAestheticsScoresRequest renvoie des scores incluant la classification utilitaire et la valeur esthétique, remplaçant ce que les apps de curation photo devaient auparavant approximer avec des modèles Core ML personnalisés.

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

Segmentation de documents avec intégration VisionKit. VNDetectDocumentSegmentationRequest trouve des documents rectangulaires et renvoie les points d’angle ; le VNDocumentCameraViewController de VisionKit enveloppe la capture de documents dans une UI conçue pour les utilisateurs, tandis que DataScannerViewController (iOS 16+) couvre la numérisation en direct du texte et des codes lisibles par machine.⁶

Les capacités phares du framework (visage, texte, posture, codes-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 mis de côté alors que le dossier est clair :

Habitude cloud-first. Le développement IA moderne se fait majoritairement contre des APIs cloud en premier. Les développeurs savent appeler OpenAI ; la surface de VNRecognizeTextRequest plus VNImageRequestHandler plus VNRecognizedTextObservation donne l’impression de plus d’API à apprendre pour ce qui représente, en nombre de lignes, moins de lignes que d’appeler OpenAI Vision (pas d’auth, pas de HTTP, pas de retry, pas de parsing JSON).

Mauvaise appréciation des capacités. Les développeurs qui n’ont pas vérifié le framework récemment supposent qu’il ne couvre que l’OCR et les codes-barres. La liste de catégories ci-dessus représente plus de deux douzaines 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 l’emportent 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, puis de réévaluer la couche de perception une fois le workflow 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 apps iOS 26+

Trois enseignements à retenir.

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

2. Utilisez les APIs cloud pour le raisonnement, pas pour 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 en one-shot sans données d’entraînement. C’est le territoire du cloud ; les lui céder est correct.

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

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

FAQ

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

Le framework Vision est l’API on-device de vision par ordinateur pour iOS, macOS et visionOS. visionOS est le système d’exploitation de l’Apple Vision Pro. Le chevauchement de noms est malheureux. Vision (le framework) s’exécute sur tous les appareils Apple modernes ; visionOS (le système) 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 la posture, générer des embeddings d’images), Vision est presque toujours le bon choix. Il s’exécute en millisecondes, ne coûte rien par inférence et conserve les données utilisateur sur l’appareil. Les APIs cloud ont raison 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’app, 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 la répartition de Vision sur Apple Silicon ?

Vision (et les modèles Core ML qu’il exécute) répartit automatiquement vers le Neural Engine quand celui-ci 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 iPhone modernes (A12 Bionic et ultérieurs), le Neural Engine prend en charge l’essentiel de l’inférence ; le développeur ne configure pas la répartition manuellement.

Quoi de neuf dans iOS 18 et iOS 26 ?

Le résumé prudent, daté par rapport aux notes de version d’Apple : VNCalculateImageAestheticsScoresRequest a été ajoutée en tant qu’API publique sous iOS 18 ; VNRecognizeTextRequest a élargi sa prise en charge multilingue au fil des versions récentes ; le DataScannerViewController de VisionKit (iOS 16+) couvre le texte en direct et les codes lisibles par machine, tandis que VNDocumentCameraViewController couvre la capture de documents. Les capacités phares (texte, visage, posture, codes-barres, embeddings) sont matures depuis plusieurs versions d’iOS.

Références