Architecture des LLM : Conception de systèmes pour l'IA en production
Exécuter un modèle est un problème d’infrastructure. Tirer de la valeur d’un modèle est un problème d’architecture.
La couche infrastructure — environnements d’exécution, matériel, points de terminaison API — détermine ce qui est possible. La couche architecture détermine ce qui se produit réellement pour une requête : quel modèle la traite, combien elle coûte, ce qui la valide et comment les échecs sont gérés.
La plupart des systèmes commencent avec un seul modèle et aucune architecture. C’est correct pour le prototypage. Cela devient une faiblesse en production.
L’architecture des LLM couvre les décisions de conception qui transforment « un modèle que je peux appeler » en « un système sur lequel je peux compter ».
Où se situe l’architecture des LLM dans la pile technique
L’architecture des LLM se trouve au milieu d’un modèle à trois couches :
| Couche | Ce qu’elle couvre | Domaine connexe |
|---|---|---|
| Modèles | Environnements d’exécution, service, configuration GPU | Hébergement des LLM · Performance des LLM |
| Architecture | Routage, coût, garde-fous, orchestration | Vous êtes ici |
| Applications | Assistants IA, pipelines RAG, agents | Systèmes IA · RAG |
La couche architecture est souvent ignorée au début. Elle devient essentielle lorsque vous avez plus d’un modèle, plus d’un type de tâche ou plus d’un utilisateur. Chaque modèle d’architecture de ce cluster existe parce que « un modèle pour tout » ne fonctionnait plus.
Carte du cluster
Les cinq sujets de ce cluster se construisent les uns sur les autres. Lisez dans cet ordre pour le parcours le plus logique :
- Vous êtes ici — ce pilier : ce qu’est l’architecture des LLM, comment les pièces s’assemblent
- Prompts — Rédiger des prompts efficaces pour les LLM — les fondations : façonner ce que le modèle reçoit
- Routage — Stratégies de routage des modèles — le répartiteur : quel modèle traite quoi
- Coût — Optimisation des coûts pour les systèmes LLM — budgétisation des jetons, mise en cache, économie locale vs API
- Sécurité — Les garde-fous des LLM en pratique — validation des entrées, filtrage des sorties, conformité
- Orchestration — Conception de systèmes multi-modèles — modèles séquentiels, parallèles, hiérarchiques et d’ensemble
Si vous n’avez le temps que pour un seul, commencez par le routage. C’est le point de décision où l’architecture commence.
Ingénierie des prompts
L’ingénierie des prompts est la couche la plus proche du modèle. Avant le routage, avant la mise en cache, avant les garde-fous — il y a le prompt. Ce que vous envoyez au modèle détermine ce que vous obtenez en retour.
Les techniques pratiques qui comptent :
- Clarté et structure — des instructions claires surperforment un cadrage astucieux
- Exemples spécifiques — les exemples en peu de tirs (few-shot) ancrent le comportement du modèle
- Attribution de rôle — les prompts basés sur des rôles affinent le ton et les contraintes
- Approches variées — différents formats révèlent à quoi le modèle répond
- Gestion du contexte — ce que vous incluez façonne ce que le modèle pondère
L’ingénierie des prompts n’est pas une tâche ponctuelle. C’est une calibration continue entre les exigences de votre tâche et le comportement du modèle.
Approfondissement :
- Rédiger des prompts efficaces pour les LLM — techniques pratiques pour la performance des modèles de langage
Routage des modèles
Une couche de routage décide quel modèle traite quelle requête. Sans elle, chaque requête va vers le même modèle — souvent trop gros pour les tâches simples, trop petit pour les complexes.
Quatre stratégies de routage couvrent la plupart des cas de production :
| Stratégie | Optimiser pour | Idéal lorsque |
|---|---|---|
| Basé sur les capacités | Qualité de la tâche | Charges de travail de complexité mixte |
| Sensible au coût | Dépense de jetons | Systèmes contraints par le budget |
| Sensible à la latence | Temps de réponse | Outils interactifs et chat en temps réel |
| Hybride | Les trois | Systèmes de production avec des contraintes réelles |
Une chaîne de repli gère les échecs : ordonnez les modèles du meilleur au plus fiable, en terminant par un modèle local qui ne peut pas être limité par le débit ou arrêté par une panne d’API.
Approfondissement :
- Stratégies de routage des modèles : Local vs API, Sensible au coût, Sensible à la latence — routage basé sur les capacités, sensible au coût et à la latence avec du code Python
Optimisation des coûts
Les coûts des LLM évoluent linéairement avec l’utilisation. Les stratégies qui réduisent réellement la facture :
La budgétisation des jetons fixe des limites par session, par tâche ou adaptatives. Les budgets adaptatifs suivent l’utilisation réelle et resserrent les allocations au fil du temps.
L’inférence locale change complètement la structure des coûts. Après l’amortissement du matériel, les modèles locaux tournent au coût de l’électricité. Un GPU à une utilisation modérée rembourse son investissement en quelques mois.
La mise en cache est l’optimisation la plus sous-estimée. La mise en cache par correspondance exacte capture les prompts répétés. La mise en cache sémantique capture les prompts qui signifient la même chose. Pour les systèmes à fort trafic, la mise en cache sémantique élimine une grande partie des appels API avant qu’ils ne se produisent.
Les chaînes de repli réduisent le coût moyen par requête : privilégiez les modèles coûteux lorsque le budget le permet, revenez à des modèles moins chers ou locaux au fur et à mesure de la session.
Approfondissement :
- Optimisation des coûts pour les systèmes LLM : Budgétisation des jetons, Modèles de repli, Mise en cache — chiffres matériels réels, tableaux de seuil de rentabilité et modèles Python fonctionnels
Garde-fous (Guardrails)
Les LLM sont imprévisibles par défaut. Les garde-fous contraignent ce qui entre et ce qui sort — sans retirer les capacités du modèle.
Trois couches de garde-fous comptent en pratique :
La validation des entrées stoppe les problèmes avant qu’ils n’atteignent le modèle. La sanitisation des prompts capture les tentatives d’injection. Les limites de longueur empêchent le gaspillage de jetons. Les filtres de contenu bloquent les violations de politique avant que l’inférence ne coûte quelque chose.
Le filtrage des sorties capture les problèmes après la génération. La validation structurelle assure des formes de réponse attendues. Les vérifications de contenu bloquent les sorties nuisibles. La vérification des faits (pour les domaines critiques) valide les affirmations contre une base de connaissances.
Les mécanismes de sécurité protègent le système dans le temps : la limitation du débit (rate limiting) empêche l’abus, les budgets de jetons plafonnent les coûts par requête, la gestion de la fenêtre de contexte empêche le débordement et la fuite de données entre les tours.
Pour les systèmes à forte conformité (RGPD, HIPAA, SOC 2), ajoutez la journalisation d’audit avec des entrées structurées en ajout uniquement (append-only) et des contrôles de résidence des données.
Les garde-fous gèrent la conversation du modèle, mais une fois que les agents appellent des outils et délèguent du travail à d’autres agents, une deuxième couche de sécurité devient nécessaire : qui peut agir, au nom de qui, et avec quelle traçabilité d’audit. Il s’agit de sécurité de protocole plutôt que de filtrage d’E/S du modèle.
Approfondissements :
- Les garde-fous des LLM en pratique : Validation des entrées, Filtrage des sorties, Sécurité — modèles pratiques de garde-fous et notes de conformité
- Sécurité des agents A2A et MCP : Identité, Délégation et Traçabilité d’audit — sécurité du protocole des agents au-delà de la sécurité des prompts : identité, autorisation, passerelles et contrôles de délégation
Conception de systèmes multi-modèles
Lorsqu’un seul modèle ne suffit pas, la question de l’architecture est : comment orchestrer plusieurs modèles sans créer une complexité qui coûte plus cher qu’elle n’économise ?
Cinq modèles couvrent l’espace :
| Modèle | Latence | Coût | Qualité | Utiliser lorsque |
|---|---|---|---|---|
| Modèle unique | Plus basse | Plus bas | Variable | Prototypage, charges de travail uniformes |
| Séquentiel (Pipeline) | Élevée | Moyen | Élevée | Workflows multi-étapes avec spécialisation |
| Parallèle (Fan-Out) | Basse | Élevée | Élevée | Tâches indépendantes, tests A/B |
| Hiérarchique (Planificateur-Exécuteur) | Élevée | Élevée | Plus élevée | Raisonnement complexe avec exécution spécialisée |
| Ensemble | Moyenne | Plus élevé | Plus élevée | Décisions critiques nécessitant un consensus |
La règle générale : commencez par le modèle le plus simple qui gère vos contraintes réelles. La plupart des systèmes de production n’atteignent le parallèle ou le hiérarchique qu’après que le routage basé sur les capacités seul a cessé de suffire.
Approfondissement :
- Conception de systèmes multi-modèles : Quand utiliser quel modèle et pourquoi — les cinq modèles avec du code Python fonctionnel et des tableaux de compromis
Cadre de décision architectural
Utilisez ceci comme un triage rapide pour savoir quoi ajouter et quand :
| Problème | Solution | Quand l’ajouter |
|---|---|---|
| La facture est trop élevée | Routage sensible au coût, mise en cache, inférence locale | Lorsque les coûts API deviennent une ligne budgétaire réelle |
| La latence est trop élevée | Routage sensible à la latence, modèles plus petits | Lorsque les utilisateurs remarquent la lenteur |
| La qualité est incohérente | Routage basé sur les capacités, chaîne de repli | Lorsque les tâches simples obtiennent des modèles coûteux ou les tâches complexes des modèles bon marché |
| Les utilisateurs abusent du système | Validation des entrées, limitation du débit | Lorsque vous ouvrez l’accès au-delà d’une équipe de confiance |
| Les réponses sont insécurisées ou hors politique | Filtrage des sorties, garde-fous de contenu | Lorsque vous servez des utilisateurs généraux |
| Un seul modèle gère tout | Conception multi-modèle | Lorsque les charges de travail divergent suffisamment pour justifier la complexité |
| Les prompts ne fonctionnent pas | Itération de l’ingénierie des prompts | Toujours — les prompts nécessitent un ajustement au fur et à mesure que les tâches évoluent |
Construisez l’architecture du bas vers le haut. L’ingénierie des prompts est toujours dans le périmètre. Ajoutez le routage lorsque les compromis coût/qualité deviennent réels. Ajoutez les garde-fous lorsque vous servez des utilisateurs externes. Ajoutez l’orchestration multi-modèles en dernier.
Comment l’architecture des LLM est liée aux autres sujets
L’architecture des LLM se trouve à l’intersection de plusieurs clusters connexes :
Infrastructure (sous cette couche) :
- Hébergement des LLM en 2026 : Infrastructure locale, auto-hébergée et cloud comparée — environnements d’exécution (Ollama, llama.cpp, vLLM), matériel et décisions de service. Les modèles d’architecture dépendent de l’infrastructure disponible. Le routage sensible au coût n’a de sens que si vous avez des modèles locaux et API en cours d’exécution.
- Performance des LLM en 2026 : Benchmarks, goulots d’étranglement et optimisation — chiffres de latence, limites VRAM, mesures de débit. Ce sont les entrées empiriques pour les décisions de routage et de sélection de modèles.
Couches applicatives (au-dessus de cette couche) :
- Systèmes IA : Assistants auto-hébergés, RAG et infrastructure locale — les systèmes qui consomment les décisions de routage, de garde-fous et d’orchestration. L’architecture multi-modèles est un prérequis pour les assistants IA en production.
- Tutoriel sur la Génération Augmentée par Récupération (RAG) — le RAG est lui-même un modèle architectural : un pipeline de récupération alimentant le contexte dans un LLM. Les modèles de routage, de coût et de garde-fous de ce cluster s’appliquent également à l’intérieur des pipelines RAG.
Couche opérationnelle :
- Observabilité : Surveillance, métriques, guide Prometheus et Grafana — l’architecture LLM de production a besoin d’observabilité. Le suivi des coûts, la surveillance de la latence et les métriques de violation des garde-fous nécessitent tous une instrumentation au niveau de l’architecture, pas seulement au niveau de l’infrastructure.
