Un modèle multimodal apprend à manipuler plusieurs types d'entrées — texte, image, audio, parfois actions — dans un **espace de représentation commun**, de sorte qu'une légende et la photo qu'elle décrit finissent « au même endroit ». C'est le socle des assistants qui « voient », et c'est aussi, en bout de chaîne, ce qui permet à un robot de transformer « range la tasse bleue » en un mouvement de bras. Cet article suit ce fil : comment on fusionne les modalités (CLIP, ViT), comment on branche la vision sur un LLM (projecteur, cross-attention, natif), comment on les entraîne et les évalue, puis comment les **Vision-Language-Action models (VLA)** étendent tout cela à l'action incarnée. ## Fusionner des modalités : l'idée centrale Le problème de base est l'**hétérogénéité** : une image est une grille de pixels, un texte une suite de symboles discrets. Les fusionner suppose de projeter chaque modalité dans un même espace vectoriel où la **proximité géométrique reflète la proximité de sens**, indépendamment du format d'origine. Une fois ce pont posé, un encodeur d'image et un encodeur de texte peuvent « se parler » : on interroge dans une modalité et on récupère dans l'autre. Deux familles cohabitent : - Les modèles **à double encodeur** (style CLIP) gardent deux tours séparées et n'alignent que les vecteurs finaux. Ils sont parfaits pour la **recherche** (texte ⇄ image) et la **classification zero-shot**, mais ils ne *génèrent* rien — ils mesurent une proximité. - Les modèles **à fusion profonde** (les VLM génératifs) injectent les tokens visuels *dans* un LLM, qui raisonne conjointement sur le texte et l'image pour **produire** du langage : décrire, répondre, raisonner. - Les **VLA** prolongent cette seconde famille jusqu'à produire des **actions** plutôt que (ou en plus de) du texte. On parle de **fusion précoce** (early fusion) lorsque les modalités sont mélangées dès l'entrée du réseau, et de **fusion tardive** (late fusion) lorsqu'on n'aligne que des représentations déjà calculées séparément. CLIP est l'archétype de la fusion tardive ; les VLM génératifs penchent vers la fusion précoce, car le LLM doit voir image et texte ensemble pour raisonner. Comprendre ce continuum aide à choisir l'architecture selon la tâche : récupérer, ou générer, ou agir. Au-delà de l'image et du texte, le même principe s'étend à d'autres modalités : - **Audio** (parole, sons d'environnement), aligné lui aussi par contraste sur du texte. - **Vidéo**, traitée comme une séquence d'images avec une dimension temporelle. - **Capteurs robotiques** (profondeur, proprioception, forces) chez les VLA. Le motif est toujours le même : un encodeur par modalité, un alignement vers un espace commun, puis un raisonnement conjoint. C'est cette uniformité qui rend l'approche si fertile. ## CLIP : l'alignement contrastif image-texte CLIP (Contrastive Language-Image Pre-training, OpenAI, 2021) est le modèle fondateur de la fusion image-texte. Son architecture est un **double encodeur** : un encodeur d'image (ViT ou ResNet) et un encodeur de texte (Transformer) projettent chacun leur entrée dans un **espace d'embedding partagé** où images et textes proches par le sens se retrouvent côte à côte. ![Schéma de CLIP : deux encodeurs projettent image et texte dans un espace partagé, et une matrice de similarité maximise la diagonale (paires correctes).](/articles/modeles-multimodaux-et-vision-language-action/clip-contrastive.svg) *Figure : pré-entraînement contrastif de CLIP. Schéma original.* L'entraînement est **contrastif**. Sur un lot de N paires (image, légende), on calcule une matrice N×N de similarités cosinus : la **diagonale** correspond aux bonnes paires, le reste à des négatifs. L'objectif (une perte InfoNCE symétrique, image→texte et texte→image) **rapproche** chaque image de SA légende et **éloigne** toutes les autres. CLIP a été entraîné sur ~400 millions de paires image-texte récupérées du Web, avec des lots gigantesques (la matrice de similarité atteint 32 768 × 32 768). Conséquence remarquable : un **classificateur zero-shot**. Pour classer une image parmi des catégories, on encode chaque catégorie sous forme de phrase (« une photo d'un chien »), on encode l'image, et on choisit la légende de plus forte similarité — sans aucun ré-entraînement. C'est cette aptitude qui a fait de CLIP la brique visuelle de quantité de systèmes ultérieurs (génération d'images, récupération, et… les VLM). Quelques points souvent mal compris à propos de CLIP : - **La normalisation compte.** Les embeddings sont projetés sur la sphère unité avant le calcul de similarité ; produit scalaire et cosinus coïncident alors, et un paramètre de **température** apprise contrôle la « netteté » de la distribution. - **Le contraste est symétrique.** La perte additionne deux termes : trouver la bonne légende pour chaque image *et* la bonne image pour chaque légende. C'est ce qui rend l'espace réversible. - **CLIP n'est pas génératif.** Il ne décrit pas une image : il **mesure** à quel point une image et un texte vont ensemble. La génération viendra des VLM, qui réutiliseront pourtant souvent l'encodeur de vision de CLIP. Pour fixer les idées, le cœur de la perte contrastive tient en quelques lignes : ```python # Pseudo-code : perte contrastive symétrique de CLIP (un lot de N paires) img_emb = l2_normalize(image_encoder(images)) # (N, d) sur la sphère unité txt_emb = l2_normalize(text_encoder(texts)) # (N, d) logits = (img_emb @ txt_emb.T) * exp(temperature) # similarités N×N labels = arange(N) # la bonne paire est sur la diagonale loss_i = cross_entropy(logits, labels) # image → texte loss_t = cross_entropy(logits.T, labels) # texte → image loss = (loss_i + loss_t) / 2 # objectif symétrique ``` ## Pourquoi un espace partagé « fonctionne » Pourquoi est-il raisonnable d'espérer qu'une image et sa description finissent au même endroit ? Parce que le sens est **relationnel**. Dans un espace appris, ce qui compte n'est pas la valeur absolue d'un axe mais la **position relative** : « chat » et « chien » sont proches l'un de l'autre et loin de « avion », que l'on parte d'une photo ou d'un mot. L'entraînement contrastif sculpte exactement cette géométrie : il **tire** les paires qui correspondent et **repousse** celles qui ne correspondent pas, jusqu'à ce que la **structure** de l'espace soit cohérente d'une modalité à l'autre. Deux propriétés en découlent, précieuses pour la suite : - **Compositionnalité.** Des concepts proches partagent des directions communes ; on peut combiner « tasse » et « bleue » de façon partiellement additive, ce qui aide à généraliser à des combinaisons jamais vues. - **Transférabilité.** Un encodeur qui a appris cet espace sur des centaines de millions de paires Web emporte avec lui un « bon sens » visuel réutilisable — c'est ce capital qu'un VLM, puis un VLA, vont recycler au lieu de tout réapprendre. C'est la raison profonde pour laquelle on **réutilise** des encodeurs pré-entraînés (CLIP, SigLIP, DINOv2) plutôt que d'en former de nouveaux : l'alignement coûte cher, autant le capitaliser. ## Encodeurs de vision : du patch au token Côté image, l'outil dominant est le **Vision Transformer (ViT)**. L'idée clé est simple et puissante : découper l'image en **patches** (par ex. 14×14 ou 16×16 pixels), aplatir chaque patch, le projeter linéairement en un vecteur — et traiter cette séquence de vecteurs **exactement comme une séquence de tokens** pour un Transformer. Un patch devient un « mot visuel ». Un ordre de grandeur utile : une image 224×224 en patches 14×14 produit 16×16 = **256 tokens visuels** ; passer à 336×336 en fait grimper le nombre à 576. C'est ce simple calcul qui explique pourquoi la résolution coûte si cher en aval — chaque token supplémentaire alourdit toute l'attention du LLM. Le ViT sort alors une grille de vecteurs (un par patch), porteurs d'information **spatiale** locale. C'est précisément ce dont un VLM a besoin : LLaVA, par exemple, prélève les *grid tokens* d'une couche avant-dernière de CLIP ViT-L/14 pour conserver le détail fin plutôt que de se contenter d'un unique vecteur global. Plus de patches = plus de tokens visuels = plus de détail, mais aussi plus de calcul dans le LLM en aval — un compromis central des VLM modernes. Tous les encodeurs de vision ne se valent pas, et le choix influe fortement sur le VLM final : - **CLIP ViT** apporte une forte alignement **sémantique** (il « sait » que cet objet est un chien), grâce à son pré-entraînement contrastif texte-image. - **SigLIP** remplace la perte softmax de CLIP par une perte **sigmoïde** par paire, plus stable à grande échelle et souvent meilleure à budget égal. - **DINOv2** (auto-supervisé, sans texte) excelle sur la **géométrie** et le détail spatial fin, mais sans ancrage linguistique. D'où une tendance forte : **fusionner deux encodeurs** (par ex. SigLIP + DINOv2) pour cumuler sémantique et précision spatiale — c'est exactement le choix d'OpenVLA, comme on le verra. ## Brancher la vision sur un LLM : trois écoles Comment fait-on « voir » un LLM purement textuel ? Trois stratégies, par fusion de plus en plus profonde. ![Du VLM au VLA : l'image est découpée en patches puis encodée par un ViT, projetée dans l'espace du LLM, fusionnée aux tokens de texte ; le LLM sort du texte (VLM) ou des tokens d'action exécutés par un robot (VLA).](/articles/modeles-multimodaux-et-vision-language-action/vlm-to-vla.svg) *Figure : architecture VLM → VLA et étapes d'entraînement. Schéma original.* **1. Projection (LLaVA).** L'approche la plus simple et la plus répandue. Un **projecteur** — une matrice apprise dans LLaVA 1.0, puis un **MLP à deux couches** avec activation GELU dans LLaVA 1.5 — convertit les vecteurs du ViT en « tokens d'image » qui vivent dans l'espace d'embedding du LLM. On les **préfixe** simplement aux tokens de texte : le LLM consomme alors une séquence mixte, sans modification de son architecture. Léger, efficace, c'est la recette par défaut de la plupart des VLM open source. **2. Cross-attention (Flamingo).** DeepMind insère des **blocs de cross-attention « gated »** entre les couches du LLM. Les requêtes (texte) interrogent les clés/valeurs (vision) ; un *gating* tanh **initialisé à zéro** garantit qu'au départ le modèle se comporte exactement comme le LLM d'origine, puis ouvre progressivement la porte aux signaux visuels — ce qui stabilise l'entraînement. Cette voie gère élégamment plusieurs images entrelacées et de longues séquences. **3. Multimodal natif (GPT-4o, Gemini, Qwen2-VL).** Plutôt qu'ajouter la vision après coup, on entraîne dès le départ un modèle unique qui traite tokens d'image et de texte **de façon uniforme** via la même self-attention, avec des tokens spéciaux pour délimiter le visuel (par ex. `vision_start`/`vision_end`). GPT-4o et Gemini sont décrits comme nativement multimodaux ; leurs détails exacts restent non publiés. C'est la voie qui généralise le mieux mais la plus coûteuse à entraîner. Comment choisir ? En pratique : - La **projection** est imbattable en rapport simplicité/coût : on réutilise un ViT et un LLM existants, on n'entraîne presque rien au départ. C'est pourquoi la quasi-totalité des VLM open source l'adoptent. - La **cross-attention** brille sur les **séquences multi-images** entrelacées (documents, vidéos, dialogues riches en images) et garde le LLM intact au démarrage grâce au gating à zéro. - Le **natif** offre la meilleure fusion et la meilleure généralisation, mais exige un pré-entraînement multimodal de bout en bout — donc des moyens que seuls les grands laboratoires alignent. ## Tokeniser une image Dans les approches « projection » et « natif », l'image finit représentée par une **séquence de tokens** homogène à du texte. C'est ce qui rend les VLM si pratiques : tout le pipeline d'un LLM (attention, génération auto-régressive, KV-cache) s'applique tel quel. Le revers est le **budget de tokens** : une image en haute résolution peut coûter des centaines, voire des milliers de tokens. D'où les techniques de réduction — *pooling*, *resampler* à la Flamingo (Perceiver Resampler compressant une grille variable en un petit nombre fixe de tokens), tuiles à résolution adaptative — pour contenir le coût sans sacrifier le détail utile. ## Entraîner un VLM : aligner puis instruire Le schéma d'entraînement de LLaVA est devenu canonique, en **deux étapes**. - **Étape 1 — alignement de caractéristiques.** On **gèle** l'encodeur de vision ET le LLM, et on n'entraîne **que le projecteur** sur des paires image-légende (595 000 paires filtrées de CC3M pour LLaVA). Objectif : apprendre au projecteur à mapper l'espace visuel vers l'espace du langage. C'est rapide et stable. - **Étape 2 — instruction visuelle.** On **dégèle** le LLM et le projecteur (l'encodeur de vision reste souvent gelé) et on entraîne sur des **dialogues visuels** de plus haute qualité (158 000 conversations synthétiques pour LLaVA). Le modèle apprend à suivre des instructions, décrire, raisonner, répondre à des questions sur l'image. Des modèles plus récents (Qwen2-VL) ajoutent une **troisième étape** et dégèlent progressivement les composants, sur des volumes massifs (de l'ordre de 10^12 tokens). Le principe reste le même : **d'abord aligner les modalités, ensuite enseigner le comportement.** ```python # Pseudo-code : forward d'un VLM de type LLaVA patches = vit(image) # ViT → grille de tokens visuels (spatial) img_tokens = projector(patches) # MLP : espace vision → espace LLM txt_tokens = embed(text) # tokens de texte seq = concat([img_tokens, txt_tokens]) # on PRÉFIXE l'image au texte logits = llm(seq) # le LLM raisonne conjointement answer = decode(logits) # génération auto-régressive de texte ``` ## Évaluer les VLM — et le problème des hallucinations On évalue les VLM sur des questions visuelles (VQA), du *captioning*, du raisonnement spatial, de l'OCR, des graphiques et documents. Mais le risque majeur est l'**hallucination d'objets** : le modèle décrit des éléments **absents** de l'image, par excès de *prior* linguistique (le LLM « complète » selon ce qui est plausible textuellement, pas selon ce qu'il voit). Les causes habituelles : un encodeur de vision gelé qui perd du détail, un déséquilibre entre signal visuel et signal textuel, des données d'instruction biaisées. Les parades : meilleurs encodeurs, plus haute résolution, données de *grounding* (ancrage explicite objet ↔ région), et des benchmarks dédiés (POPE pour l'hallucination d'objets, MMMU pour le raisonnement multimodal exigeant). Règle de prudence : **un VLM fluide n'est pas un VLM fiable** — il faut mesurer le *grounding*, pas seulement la qualité de prose. ## Des VLM aux VLA : ajouter l'action Un **Vision-Language-Action model (VLA)** est un modèle de fondation multimodal qui intègre **vision, langage ET actions**. À partir d'images de caméra et d'une instruction en langage naturel, il **produit des commandes exécutables** par un robot. L'intuition fondatrice : un VLA est un VLM **plus un décodeur d'action**. La perception et le raisonnement sont assurés par le VLM (qui encode images + texte en tokens dans un espace latent partagé) ; un étage final convertit ces tokens en commandes représentant les **degrés de liberté** du robot (déplacements, rotations, ouverture de pince). Le coup de génie qui a lancé le domaine : **traiter les actions comme des tokens**. Si l'on discrétise une action continue (par ex. « avancer de 50 mm ») en un identifiant discret, alors générer une trajectoire revient exactement à **générer du texte** — même architecture Transformer, même objectif auto-régressif, et surtout **transfert** du savoir acquis sur des milliards d'images et de textes du Web vers le contrôle moteur. Concrètement, on **discrétise** chaque dimension d'action (déplacement en x, y, z, rotation, état de la pince) en un petit nombre de **bacs** (souvent 256), chacun associé à un token. Un pas de contrôle devient alors une courte suite de tokens d'action, et le modèle apprend à la **générer** comme il générerait une phrase. À l'inférence, on **dé-tokenise** ces identifiants pour retrouver des consignes continues (couples, vitesses) envoyées au contrôleur bas niveau. L'élégance de l'approche est qu'elle **n'invente rien** côté architecture : c'est un LLM multimodal standard dont on a élargi le vocabulaire. ## Exemple de bout en bout : de l'instruction au geste Suivons « range la tasse bleue » à travers un VLA à tokens d'action : 1. La **caméra** capture la scène ; l'**encodeur de vision** la découpe en patches et produit des tokens visuels. 2. Le **projecteur** les amène dans l'espace du LLM ; ils sont fusionnés avec les tokens de l'instruction. 3. Le **LLM** raisonne conjointement : il « voit » la tasse bleue, comprend l'ordre, planifie. 4. Il **génère des tokens d'action** (Δx, Δy, Δz, rotation, pince) pas après pas. 5. Ces tokens sont **dé-tokenisés** en consignes continues envoyées au contrôleur du bras. 6. Le robot agit ; la nouvelle image revient en entrée, et la boucle recommence. ```text image (patches) ─▶ ViT ─▶ projecteur ─┐ ├─▶ LLM ─▶ tokens d'action ─▶ dé-tokenise ─▶ robot instruction ─────▶ tokens texte ───────┘ ▲ │ └──────── nouvelle image ◀─────────┘ ``` Toute la difficulté pratique tient dans cette **boucle fermée** : chaque itération doit être assez rapide pour que le geste reste fluide, ce qui ramène au défi de latence évoqué plus loin. ## RT-2 : le pionnier RT-2 (Google DeepMind, juillet 2023) a établi le paradigme VLA. Il **co-entraîne** un VLM (sur les backbones PaLI-X et PaLM-E) à la fois sur des données Web et sur des données de robot, en représentant les **actions du robot comme des tokens** au même titre que le langage. Concrètement, une action continue est **discrétisée** en un token (« déplace-toi de 50 mm » devient, par ex., le token n°1247), réutilisant le vocabulaire du modèle. Résultat : RT-2 généralise mieux que son prédécesseur RT-1 à des **tâches nouvelles** et peut enchaîner un raisonnement multi-étapes (chain-of-thought) tirant parti des connaissances héritées du Web — par exemple « choisir l'objet qui sert à enfoncer un clou ». L'apport décisif n'est pas une nouvelle architecture mais une **représentation** : en écrivant l'action dans le même alphabet que le langage, RT-2 fait du contrôle moteur un cas particulier de génération de texte, et hérite « gratuitement » du raisonnement appris sur le Web. ## OpenVLA : l'open source à 7 milliards de paramètres OpenVLA (Stanford et collaborateurs, juin 2024) a rendu le paradigme **ouvert et reproductible**. C'est un modèle de **7 milliards de paramètres** entraîné sur **~970 000 épisodes** de robot issus du dataset **Open X-Embodiment** (couvrant 22 morphologies de robots différentes). Son architecture : - un **encodeur de vision fusionné** combinant **SigLIP** et **DINOv2** (sémantique + détail spatial) ; - un **projecteur** mappant les embeddings visuels vers l'espace du langage ; - un **backbone Llama-2 7B** qui **prédit des tokens d'action** discrets, ensuite dé-tokenisés en commandes continues directement exécutables. OpenVLA **surpasse** des politiques généralistes antérieures (RT-1-X, Octo) et même **RT-2-X** (un VLA fermé de 55 milliards de paramètres) sur de nombreuses tâches — RT-2-X gardant l'avantage sur la généralisation sémantique fine qui exige des connaissances Web. Côté ingénierie, OpenVLA a été entraîné sur **64 GPU A100 pendant 15 jours**, et il se **fine-tune** efficacement : LoRA n'ajuste que **1,4 %** des paramètres tout en égalant le fine-tuning complet — un atout décisif pour l'adaptation à un nouveau robot ou une nouvelle tâche. Pour le praticien, OpenVLA illustre deux leçons concrètes : le choix d'un **encodeur fusionné** (sémantique + spatial) est payant pour la manipulation, et la **quantification** plus LoRA rendent réaliste l'adaptation sur du matériel modeste, sans cluster. ## π0 (pi-zero) : sortie continue par flow-matching π0 (Physical Intelligence, fin 2024) prend l'autre chemin pour la **dextérité haute fréquence**. Plutôt que des tokens discrets, il s'appuie sur un VLM (**PaliGemma**, construit à partir de SigLIP et Gemma) et **génère directement des actions continues** via un réseau de **flow-matching** (cousin des modèles de diffusion). Cela produit des trajectoires fluides à **~50 Hz**, mieux adaptées à des robots à nombreux degrés de liberté et à des gestes fins (plier du linge, manipuler des objets délicats). Le compromis se dessine ainsi : **tokens discrets** = simplicité et héritage direct du LLM, mais granularité limitée ; **sortie continue (diffusion/flow)** = précision et haute fréquence, au prix d'un décodeur plus complexe. Une notion clé revient ici : les *action chunks*. Au lieu de prédire un seul pas, le modèle génère **d'un coup** une courte séquence d'actions futures, ce qui lisse la commande et amortit le coût d'une passe du gros VLM — une astuce centrale pour tenir la cadence temps réel. ## Généralisation et raisonnement incarné La promesse des VLA est la **généralisation incarnée** : parce que le tronc est un VLM pré-entraîné sur le Web, le robot hérite d'un **bon sens visuel et linguistique** qu'aucune démonstration robotique seule ne pourrait fournir. Il peut suivre des instructions inédites, reconnaître des objets jamais vus en démonstration, et raisonner sur la tâche (« range *d'abord* la tasse, *puis* essuie la table »). Le dataset Open X-Embodiment pousse plus loin : entraîner **une seule** politique sur **plusieurs morphologies** pour viser un contrôleur générique, transférable d'un robot à l'autre. ## Défis ouverts - **Latence.** Un LLM de plusieurs milliards de paramètres dans une **boucle de contrôle** temps réel est un défi : générer des tokens est lent, alors que le contrôle exige 10–50 Hz. D'où les sorties continues (π0), la distillation, la quantification, les *action chunks* (prédire plusieurs pas d'un coup). - **Données.** Les démonstrations robotiques sont rares et coûteuses face aux téraoctets de texte/image du Web ; la **télé-opération** ne passe pas à l'échelle. Open X-Embodiment, la simulation et l'apprentissage à partir de vidéos humaines tentent de combler le fossé. - **Sécurité et fiabilité.** Une hallucination dans un chatbot produit une phrase fausse ; dans un VLA, elle produit un **geste**. Garde-fous, détection hors-distribution, arrêts d'urgence et bornes de couple sont indispensables. - **Évaluation.** Mesurer une politique robotique dans le monde réel est lent, bruité et difficilement reproductible — un frein concret au progrès. ## Discret ou continu : récapitulatif Le choix de la **représentation d'action** structure tout le système : - **Tokens discrets (RT-2, OpenVLA).** Avantages : architecture identique à un LLM, héritage direct du pré-entraînement Web, simplicité d'implémentation, fine-tuning par LoRA très efficace. Limite : la granularité dépend du nombre de bacs, et la génération token par token peut brider la fréquence de contrôle. - **Sortie continue / flow-matching (π0).** Avantages : trajectoires fluides, haute fréquence (~50 Hz), bonne dextérité sur de nombreux degrés de liberté. Limite : décodeur plus complexe (diffusion/flow), entraînement et débogage moins « LLM-classiques ». Il n'existe pas de gagnant universel : le bon choix dépend de la **tâche** (préhension grossière vs gestes fins), de la **fréquence de contrôle** exigée, et des contraintes de **calcul embarqué**. ## Au-delà de la robotique La multimodalité ne se limite pas aux bras articulés. Les mêmes briques alimentent : - des **assistants visuels** (décrire une scène, lire un graphique, extraire un tableau d'une capture d'écran) ; - des **agents qui pilotent une interface** (computer use) en « voyant » l'écran et en cliquant ; - la **recherche multimodale** et la modération de contenu (texte + image) ; - l'**accessibilité** (description d'images pour personnes malvoyantes) et l'analyse documentaire (OCR + raisonnement). Le fil conducteur reste identique : projeter des modalités hétérogènes dans un espace commun, puis laisser un Transformer raisonner — que la sortie soit une phrase, un clic ou un mouvement. ## Données et passage à l'échelle Une leçon traverse tout le domaine : **la donnée est le vrai goulot d'étranglement.** Côté VLM, on dispose de **milliards** de paires image-texte sur le Web, ce qui a rendu CLIP et ses successeurs possibles. Côté VLA, on parle de **centaines de milliers** d'épisodes seulement (≈970 000 pour Open X-Embodiment) — plusieurs ordres de grandeur en moins. Trois pistes pour réduire l'écart : - **Mutualiser les morphologies.** Open X-Embodiment agrège des données de 22 robots différents pour entraîner une politique unique ; chaque embodiment profite des autres. - **Co-entraîner sur le Web.** RT-2 mélange données robot et données image-texte généralistes, ce qui injecte du « bon sens » et améliore la généralisation sémantique. - **Apprendre sans téléopération.** Simulation, vidéos humaines et auto-supervision visent à produire du signal d'action sans démonstration humaine coûteuse. Le pari implicite des VLA est que la **mise à l'échelle** qui a transformé le NLP puis la vision finira par transformer le contrôle moteur — à condition de résoudre d'abord la rareté des données d'action. ## Checklist pratique : choisir et construire Pour transformer cette théorie en décisions, une grille de questions à se poser dans l'ordre : 1. **Quelle sortie ?** Récupération/classification → un double encodeur (CLIP/SigLIP) suffit. Description, Q/R, raisonnement → un VLM. Contrôle d'un robot → un VLA. 2. **Quel encodeur de vision ?** Privilégier le **sémantique** (CLIP/SigLIP) pour décrire et raisonner ; ajouter du **spatial** (DINOv2) quand la géométrie compte (manipulation, OCR fin). 3. **Quel mode de fusion ?** **Projection** par défaut (simple, peu coûteux) ; **cross-attention** pour les longues séquences multi-images ; **natif** seulement avec un budget de pré-entraînement conséquent. 4. **Quelle résolution / quel budget de tokens ?** Monter la résolution améliore le détail mais alourdit le LLM ; envisager *pooling* ou *resampler* si le contexte explose. 5. **Discret ou continu (VLA) ?** Tokens discrets pour la simplicité et le transfert Web ; sortie continue (flow/diffusion) pour la haute fréquence et la dextérité fine. 6. **Comment évaluer ?** Mesurer le *grounding* (POPE, MMMU), pas seulement la fluidité ; pour un VLA, prévoir une évaluation réelle, lente mais incontournable. Cette séquence — sortie, encodeur, fusion, résolution, représentation d'action, évaluation — couvre l'essentiel des arbitrages d'un projet multimodal, du moteur de recherche à la politique robotique. ## En résumé La trajectoire est cohérente : **CLIP** apprend à aligner image et texte dans un espace partagé ; le **ViT** transforme l'image en tokens ; un **projecteur** (ou de la cross-attention, ou un entraînement natif) branche cette vision sur un **LLM** ; l'entraînement procède en **alignant** puis en **instruisant** ; et les **VLA** poussent l'idée jusqu'à produire des **actions comme des tokens** (RT-2, OpenVLA) ou des trajectoires continues (π0). Le même principe — projeter des modalités hétérogènes dans un espace commun et laisser un Transformer raisonner dessus — relie la légende d'image au bras robotique. Restent les verrous du monde réel : latence, données, sécurité, évaluation — c'est là que se jouera la prochaine génération de l'IA incarnée.