Beaucoup de développeurs et de décideurs tech parlent des LLMs au quotidien sans vraiment comprendre ce qui se passe sous le capot. Le résultat ? Des choix d’architecture hasardeux, des prompts mal calibrés, et une incapacité à diagnostiquer les limites réelles de ces systèmes. Comprendre l’architecture Transformer, c’est se donner les moyens de travailler intelligemment avec ces modèles — et pas seulement de les subir.
Pourquoi l’architecture Transformer a tout changé dans le traitement du langage
Avant 2017, les modèles de traitement du langage naturel reposaient principalement sur des architectures récurrentes (RNN, LSTM). Ces réseaux traitaient le texte mot par mot, de manière séquentielle, ce qui créait deux problèmes majeurs : une difficulté à capturer les dépendances à longue distance dans un texte, et une paralysie à l’entraînement impossible à distribuer efficacement sur GPU.
La publication du papier fondateur Attention Is All You Need (Vaswani et al., Google Brain, 2017) a tout changé. L’idée centrale est radicale : se débarrasser entièrement de la récurrence, et la remplacer par un mécanisme d’attention qui traite toutes les positions d’une séquence simultanément. Ce changement de paradigme a rendu possible l’entraînement à une échelle inimaginable auparavant, ouvrant la voie à GPT, BERT, LLaMA, et à toute la famille des grands modèles de langage que nous utilisons aujourd’hui.
Pour se représenter l’enjeu concrètement : une entreprise française comme Mistral AI, dont nous avons analysé les ambitions face aux géants américains, construit l’intégralité de ses modèles sur des variantes de cette architecture. Comprendre le Transformer, c’est comprendre ce qui fait la force — et les limites — de Mistral 7B, de GPT-4 ou de Gemini Ultra.
Les briques fondamentales du Transformer : anatomie d’un modèle de langage
Un Transformer se décompose en deux grandes parties dans sa version originale : un encodeur et un décodeur. Les LLMs modernes de type génératif (GPT, LLaMA, Mistral) n’utilisent en réalité que la partie décodeur — c’est important à comprendre pour éviter les confusions courantes.
Le mécanisme d’attention multi-têtes (Multi-Head Attention)
C’est le cœur du Transformer. À chaque couche, chaque token (unité lexicale) calcule une relation d’attention avec tous les autres tokens de la séquence. Techniquement, on projette chaque token dans trois vecteurs : Query (Q), Key (K) et Value (V). Le score d’attention entre deux tokens est calculé par le produit scalaire de leurs vecteurs Q et K, normalisé et passé dans une softmax. Ce score détermine la quantité d’information extraite du vecteur V correspondant.
Le qualificatif multi-têtes signifie que ce calcul est réalisé en parallèle dans plusieurs sous-espaces de représentation. Chaque tête capture des relations différentes : une tête peut se spécialiser dans la coréférence (relier « il » à « Pierre »), une autre dans la syntaxe, une autre encore dans la sémantique thématique. C’est cette richesse représentationnelle qui donne au modèle sa capacité à gérer des textes complexes.
L’encodage positionnel : donner un sens à l’ordre des mots
Puisqu’il n’y a plus de récurrence, le modèle ne sait pas intrinsèquement que le mot en position 3 vient avant celui en position 7. On injecte donc un encodage positionnel dans les embeddings d’entrée — une représentation mathématique de la position de chaque token dans la séquence. Les Transformers modernes utilisent des variantes apprises (comme les embeddings positionnels de GPT) ou des formules sinusoïdales. Des innovations comme RoPE (Rotary Position Embedding), utilisé dans LLaMA 2, améliorent la généralisation sur des longueurs de contexte inédites à l’entraînement.
Les couches Feed-Forward et la normalisation
Après chaque bloc d’attention, une couche Feed-Forward (réseau dense à deux couches) affine les représentations token par token. Des mécanismes de Layer Normalization et des connexions résiduelles (skip connections) stabilisent l’entraînement et permettent d’empiler des dizaines de couches sans effondrement du gradient. Un modèle comme GPT-4 comporterait, selon les estimations circulant dans la communauté ML, plus d’une centaine de ces blocs empilés.
Du pré-entraînement au modèle utilisable : les étapes clés de la fabrication d’un LLM
Comprendre l’architecture ne suffit pas si on ignore le processus qui transforme une pile de couches en un assistant conversationnel. Il se déroule en trois phases distinctes.
Phase 1 — Pré-entraînement : Le modèle apprend à prédire le token suivant (ou masqué, selon l’architecture) sur des centaines de milliards de tokens issus du web, de livres, de code. C’est une tâche auto-supervisée : pas besoin d’annotations humaines. C’est aussi la phase la plus coûteuse — plusieurs millions d’euros en infrastructure GPU pour les grands modèles.
Phase 2 — Fine-tuning supervisé (SFT) : On affine le modèle sur des paires instruction/réponse annotées par des humains pour lui apprendre à suivre des consignes. C’est ce qui transforme un modèle de complétion brut en assistant.
Phase 3 — RLHF (Reinforcement Learning from Human Feedback) : Un modèle de récompense, entraîné sur des préférences humaines, guide l’optimisation du modèle via un algorithme de renforcement (typiquement PPO). C’est la phase qui aligne le comportement du modèle sur les attentes des utilisateurs et réduit les sorties toxiques ou incorrectes. OpenAI a popularisé cette approche avec InstructGPT, dont vous pouvez approfondir l’analyse dans notre analyse complète de GPT-5 et de ses capacités.
Les limites structurelles de l’architecture Transformer : ce que même les meilleurs LLMs ne peuvent pas faire
Comprendre le Transformer, c’est aussi comprendre pourquoi ces modèles hallucinent, oublient, ou échouent sur certaines tâches pourtant triviales pour un humain.
La fenêtre de contexte est structurellement limitée. Le coût computationnel de l’attention croit quadratiquement avec la longueur de la séquence (O(n²)). Des solutions comme l’attention glissante (Sliding Window Attention dans Mistral), Flash Attention ou les architectures hybrides Mamba cherchent à contourner ce goulot d’étranglement, mais aucune n’est encore totalement satisfaisante pour les très longues séquences.
Pas de mémoire persistante entre les sessions. Un Transformer ne « se souvient » pas des conversations passées une fois le contexte effacé. Toute la connaissance est encodée statiquement dans les poids du modèle au moment de l’entraînement. C’est pourquoi les architectures RAG (Retrieval-Augmented Generation) et les agents autonomes, que nous avons détaillés dans notre article sur l’essor des agents IA autonomes en entreprise, sont indispensables pour des cas d’usage nécessitant de l’information actualisée.
L’hallucination est une conséquence du mécanisme même. Le modèle génère le token statistiquement le plus probable étant donné le contexte — il n’a aucun accès à une vérité externe, aucun mécanisme de vérification interne. La fluidité du texte généré n’est donc pas un indicateur de sa véracité. C’est la leçon que de nombreuses équipes marketing françaises ont apprise à leurs dépens en déployant des chatbots sans garde-fous.
Ce que les équipes tech françaises doivent retenir pour leurs projets LLM
Mon expérience avec des équipes produit en France montre une erreur récurrente : traiter un LLM comme une boîte noire magique et non comme un système avec des propriétés architecturales précises. Voici les recommandations concrètes que j’applique systématiquement :
- Calibrez votre fenêtre de contexte selon votre cas d’usage réel. Inutile de payer pour 128K tokens si vos documents font en moyenne 2K tokens — vous gaspillez en latence et en coût.
- Ne choisissez pas un modèle sur son score de benchmark seul. Les benchmarks (MMLU, HumanEval…) ne capturent pas les propriétés qui comptent dans votre domaine métier. Évaluez systématiquement sur vos données réelles.
- Intégrez le RAG par défaut pour tout système nécessitant des données récentes ou propriétaires. C’est l’architecture qui compense le mieux les limitations mémorielles du Transformer.
- Documentez vos prompts système comme du code. Ils font partie de l’architecture de votre application au même titre que vos appels API.
Le Transformer reste, à ce jour, l’architecture dominante de l’IA générative. Les variantes (Mamba, RWKV, architectures hybrides) gagnent du terrain, mais aucune n’a encore démontré une supériorité suffisante pour détrôner le paradigme d’attention à grande échelle. Maîtriser ses fondamentaux n’est plus réservé aux chercheurs en ML : c’est une compétence de base pour quiconque prend des décisions techniques ou produit impliquant des modèles de langage.
FAQ : architecture Transformer et LLMs
- Quelle est la différence entre un modèle encodeur (comme BERT) et un modèle décodeur (comme GPT) ?
- Un modèle encodeur traite la séquence entière en bidirectionnel : chaque token voit tous les autres tokens, passés et futurs. Il est excellent pour les tâches de compréhension (classification, extraction d’entités, similarité sémantique). Un modèle décodeur génère token par token, chaque token ne voyant que les tokens précédents (attention causale). C’est l’architecture adaptée à la génération de texte. Les modèles encodeur-décodeur (T5, BART) combinent les deux pour des tâches de transformation comme la traduction ou le résumé.
- Combien de paramètres faut-il pour qu’un LLM soit vraiment performant ?
- La question du nombre de paramètres est moins pertinente que celle de la qualité des données d’entraînement et du ratio tokens/paramètres. Les travaux de Hoffmann et al. (Chinchilla, DeepMind, 2022) ont démontré que les modèles de l’époque étaient sous-entraînés en données par rapport à leur taille. Un modèle de 7 milliards de paramètres entraîné sur des données soigneusement filtrées (comme Mistral 7B) peut surpasser des modèles dix fois plus grands mais moins bien entraînés. La taille brute n’est pas le critère décisif.
- Peut-on faire tourner un Transformer performant en local, sans infrastructure cloud ?
- Oui, et c’est désormais accessible à beaucoup d’équipes. Des modèles quantisés (4-bit, 8-bit via GPTQ, AWQ ou llama.cpp) permettent de faire tourner des modèles de 7B à 13B paramètres sur un MacBook Pro M-series ou une carte graphique grand public de 16 Go de VRAM. Pour des cas d’usage professionnels nécessitant des données sensibles (santé, juridique, finance), cette approche on-premise est souvent indispensable pour des raisons réglementaires — notamment dans le cadre du RGPD et de l’AI Act européen.