L'IA générative expliquée : modèles, recherche, outils et applications ne sont pas la même chose

L'IA générative n'est pas un seul composant. Un système d'IA générative en production combine généralement un modèle génératif avec du code applicatif qui fournit des instructions et du contexte, récupère des connaissances externes lorsque nécessaire, expose des outils pour lire ou modifier des systèmes externes, gère l'état d'exécution et les permissions, et transforme le résultat en un produit utilisable. Traiter le modèle, la récupération, les outils, le contexte, le runtime et l'application comme une seule et même chose masque les frontières qui déterminent la fraîcheur, la sécurité, la fiabilité, le coût et le contrôle.

Que signifie réellement « IA générative » ?

Au niveau du modèle, l'IA générative désigne les modèles d'IA qui génèrent du contenu synthétique dérivé tel que du texte, des images, de l'audio, de la vidéo, du code ou d'autres sorties numériques. NIST AI 600-1 utilise cette signification orientée modèle et traite séparément des risques aux niveaux du modèle, du système, de l'application et du cas d'usage.

Cette distinction est importante car un modèle d'IA n'est pas la même chose que le système d'IA complet. Le glossaire actuel du NIST définit un modèle d'IA comme un composant qui produit des sorties à partir d'entrées en utilisant des techniques computationnelles, statistiques ou d'apprentissage automatique, tandis qu'un système d'IA peut inclure des logiciels, du matériel, des applications, des outils ou des utilitaires qui fonctionnent à l'aide de l'IA.

Le modèle utile le plus simple d'un système d'IA générative

Pour un premier modèle mental, imaginez un assistant d'entreprise répondant : « Ce client peut-il obtenir un remboursement aujourd'hui ? » Une réponse utile peut nécessiter plusieurs responsabilités différentes. Le modèle de langage peut interpréter la question et rédiger l'explication, mais l'état actuel de la commande peut provenir d'un outil de base de données, la politique de remboursement peut provenir de la récupération de documents, les permissions peuvent être appliquées par l'application, et l'action finale peut nécessiter un appel API contrôlé.

Les systèmes réels ne suivent pas toujours exactement cette séquence. La récupération peut avoir lieu avant le premier appel au modèle, les outils peuvent être sélectionnés pendant une boucle d'agent, la logique applicative déterministe peut contourner entièrement le modèle, et la validation peut se produire à plusieurs étapes. L'objectif est de séparer les responsabilités, non d'imposer un flux de travail universel.

Les six frontières qui comptent

1. Le modèle : la génération est sa responsabilité principale

Un modèle génératif associe des entrées fournies à des sorties générées. Pour un modèle de langage, cela peut inclure du texte en langage naturel, du JSON structuré, du code, des classifications, des résumés, des plans ou des arguments d'appel d'outils. Les modèles génératifs multimodaux peuvent fonctionner avec des types d'entrée et de sortie supplémentaires.

Le modèle peut contenir des connaissances apprises substantielles dans ses paramètres, mais les connaissances paramétrées ne sont pas une base de données en direct. Le modèle ne connaît pas automatiquement un document créé il y a cinq minutes, le niveau de stock actuel, un dossier client privé ou l'état d'une application, sauf si cette information est fournie via le chemin d'entrée actuel.

C'est pourquoi changer le modèle ne résout pas automatiquement des connaissances obsolètes, des permissions manquantes, une récupération défaillante, une propriété d'état incorrecte ou une exécution d'outil dangereuse. Ces défaillances appartiennent souvent à d'autres couches.

2. Récupération : trouver des preuves externes est une opération distincte

La récupération sélectionne des informations à partir d'une source externe avant ou pendant la génération. Les travaux de 2020 sur la génération augmentée par récupération de Lewis et al. ont rendu cette séparation explicite en combinant un modèle génératif paramétrique avec une mémoire non paramétrique récupérée. Les systèmes de production modernes utilisent de nombreuses variantes de récupération, mais l'idée architecturale reste la même : des preuves utiles peuvent être récupérées au moment de l'inférence au lieu de s'appuyer uniquement sur ce que le modèle a appris pendant l'entraînement.

La récupération peut utiliser la recherche lexicale, les embeddings, la recherche vectorielle, la recherche hybride, SQL, les graphes de connaissances, les filtres de métadonnées, les API ou d'autres mécanismes de sélection. Une base de données vectorielle est donc un composant de récupération possible, et non la définition du RAG.

3. Outils : l'accès et l'action ne sont pas des connaissances du modèle

Un outil est une interface par laquelle un environnement d'exécution d'IA peut demander des fonctionnalités extérieures au modèle. Un outil peut interroger une base de données, rechercher sur le web, lire un fichier, calculer une valeur, appeler un service interne, créer un ticket, envoyer un message, modifier un enregistrement ou déclencher une autre opération contrôlée.

La documentation actuelle d'OpenAI sur l'appel de fonctions rend cette frontière explicite : l'appel de fonctions permet aux modèles d'interagir avec des systèmes externes et d'accéder à des données ou à des actions fournies par l'application. Le modèle peut proposer ou sélectionner un appel, mais c'est le système externe qui effectue l'opération réelle.

L'utilisation d'outils crée donc deux questions distinctes : le modèle peut-il demander cette capacité ? et l'application va-t-elle l'autoriser et l'exécuter ? Un système de production ne doit pas confondre l'intention du modèle avec la permission de provoquer un effet de bord.

4. Contexte : ce que le modèle peut voir à l'instant présent

Le contexte est l'information disponible pour le modèle à une étape d'inférence donnée. Les recommandations d'Anthropic sur l'ingénierie du contexte décrivent le contexte comme l'ensemble des tokens inclus lors de l'échantillonnage à partir d'un LLM. En pratique, cet ensemble peut contenir des instructions système, des messages utilisateur, l'historique de conversation, des preuves récupérées, des définitions d'outils, des résultats d'outils, des résumés de mémoire et un état applicatif sélectionné.

Le contexte n'est donc ni la base de connaissances complète ni la mémoire à long terme. Une entreprise peut stocker dix millions de documents alors que seule une poignée de passages entre dans un appel au modèle. Un environnement d'exécution peut conserver un an d'historique de conversation tout en n'exposant que les éléments nécessaires à la tâche en cours.

La fenêtre de contexte crée également une contrainte d'ingénierie. Ajouter plus de texte ne garantit pas une meilleure réponse ; des informations non pertinentes, obsolètes, contradictoires ou de faible autorité peuvent diluer les preuves qui comptent réellement.

5. Environnement d'exécution et orchestration : coordonner la boucle

La couche d'exécution ou d'orchestration coordonne la manière dont le modèle participe à une tâche. Selon l'architecture, elle peut gérer les sessions, les requêtes au modèle, la découverte d'outils, les boucles d'appels d'outils, les nouvelles tentatives, les transferts, les événements en streaming, les délais d'attente, les points de contrôle, la compaction ou les environnements d'exécution.

Certains environnements d'exécution sont de simples codes applicatifs autour d'une API de modèle. D'autres sont de véritables harnais d'agents. Un environnement d'exécution fourni par un prestataire peut prendre en charge une partie de la boucle tandis que l'application reste responsable de la vérité métier, de l'autorisation, des effets de bord métier et du cycle de vie du produit.

Cette frontière est importante car l'endroit où s'exécute l'environnement d'exécution et celui où s'exécute l'inférence sont des décisions distinctes. Un client ou un processus d'agent s'exécutant localement peut tout de même appeler un modèle distant, tandis qu'une application distante peut appeler un modèle hébergé sur une infrastructure sous le contrôle de l'organisation.

6. L'application : là où l'IA devient un produit

L'application est la frontière du produit autour des composants d'IA. Elle est responsable de l'expérience utilisateur, du modèle de domaine, de l'état actuel, de l'identité, de la portée du locataire, des autorisations, de la persistance, des intégrations de services, de la validation, de l'observabilité, de la facturation ou de la logique de quota le cas échéant, et des règles qui déterminent ce que l'IA est autorisée à voir ou à faire.

C'est la couche qui transforme « un modèle peut produire une sortie utile » en « un système peut fournir une capacité fiable ». Le même modèle peut participer à un assistant de recherche privé, à un flux de travail de support, à un agent de code ou à une application commerciale, car l'application environnante modifie les données, les outils, les politiques, l'état et le contrat d'exécution.

Comment les parties fonctionnent ensemble dans une requête réelle

Prenons un assistant de support à qui l'on demande : « Rembourse la commande 4711 si elle est encore éligible, et explique pourquoi. » La requête combine connaissances, état actuel, autorisation, raisonnement et un effet secondaire.

Si l'assistant ne dispose que du modèle de langage, il peut discuter des remboursements mais ne peut pas savoir de manière fiable si la commande 4711 est actuellement éligible ni effectuer la transaction. S'il ne dispose que de la récupération, il peut trouver la politique mais manque encore de l'état en direct de la commande. S'il dispose d'outils sans autorisation d'application, il peut devenir capable mais dangereux. La fiabilité vient de la composition des couches avec une propriété explicite.

Différents produits d'IA utilisent différentes combinaisons

Ce sont des modèles d'architecture, et non des classements de maturité. Une fonctionnalité modèle uniquement peut être la conception correcte lorsque la tâche ne nécessite aucun fait ni action externe. L'ajout de récupération, d'outils, de mémoire ou d'une boucle d'agent n'est justifié que lorsque la tâche exige ces capacités.

Preuves de mise en œuvre : Aaasaasa AI Client

Aaasaasa AI Client est un espace de travail d'IA de bureau local-first construit avec Nuxt 4, Electron et TypeScript. Son AI Hub sépare délibérément l'agent/client, le fournisseur, le modèle, l'emplacement d'exécution, les autorisations et le client web au lieu de les traiter comme un seul paramètre « IA ».

Cette séparation crée un comportement concret. Direct Chat peut parler aux modèles sans outils de système de fichiers ou de shell. Un agent Codex peut utiliser un espace de travail et un profil d'autorisation sélectionnés. Ollama peut fournir une inférence locale directe, tandis que LM Studio et les points de terminaison compatibles OpenAI configurables représentent d'autres chemins de fournisseur. Un processus Codex exécuté localement peut toujours utiliser un modèle cloud, de sorte que l'interface utilisateur et l'architecture n'assimilent pas l'exécution locale à l'inférence locale.

La mise en œuvre contient également la prise en charge de Qdrant/vecteurs, des capacités d'extraction de documents et un courtier MCP de répertoire authentifié. Ces composants illustrent une autre frontière : l'infrastructure de récupération et l'accès aux outils peuvent vivre dans le même produit sans devenir des propriétés du modèle lui-même.

Erreurs de catégorie courantes

Modes de défaillance lorsque les frontières s'effondrent

Les erreurs de frontière ne sont pas de simples problèmes de terminologie. Elles créent des défaillances de production distinctes qui nécessitent des correctifs différents.

Qu'est-ce qui est stable et qu'est-ce qui dépend de la version ?

Les distinctions architecturales de cet article sont volontairement neutres vis-à-vis des fournisseurs. Les exemples actuels ci-dessous sont des faits d'implémentation qui doivent être revérifiés lorsque les API évoluent.

Un article de référence devrait donc préserver les deux niveaux : des concepts stables pour l'architecture, et des preuves datées pour les implémentations actuelles. Mélanger les deux fait vieillir un article inutilement vite.

Le test des frontières des composants IA

Lors de l'évaluation d'une fonctionnalité IA, posez les questions suivantes dans l'ordre. Les réponses révèlent quels composants le système possède réellement et quelles responsabilités sont encore implicites.

Ce que l'IA générative n'est pas

L'IA générative n'est pas synonyme de LLM, même si les LLM sont une classe majeure de modèle génératif. Elle n'est pas non plus synonyme de RAG, d'une base de données vectorielle, d'un agent, d'un protocole d'outil, d'une interface de chatbot ou d'une application.

Ces concepts peuvent être connectés, mais chacun répond à une question architecturale différente. Un LLM demande comment la sortie linguistique est produite. La récupération demande d'où viennent les preuves externes. Les outils demandent comment les capacités externes sont exposées. Le contexte demande ce que le modèle peut voir. Le runtime demande comment l'exécution est coordonnée. L'application demande comment la capacité devient un produit contrôlé.

Où aller ensuite dans le graphe de connaissances

Une fois ces frontières claires, les sujets plus profonds deviennent plus faciles à situer. Le RAG appartient à la récupération et à la construction du contexte. Le déclencheur de récupération décide quand des preuves externes sont nécessaires. La mémoire d'agent concerne ce qui persiste dans le temps. L'appel d'outil et MCP appartiennent à l'accès aux capacités. Les harnais d'agent appartiennent à l'orchestration du runtime. RBAC, l'isolation des locataires et l'autorisation de domaine appartiennent à la frontière de sécurité de l'application et de la plateforme.

Limites

Le modèle à six couches est une carte des responsabilités, et non une exigence que chaque produit déploie six services distincts. Une petite application peut implémenter la construction de contexte, la récupération et l'orchestration au sein d'un seul processus. Une plateforme managée peut regrouper plusieurs responsabilités derrière une seule API. Le déploiement physique peut être combiné tandis que la propriété sémantique reste distincte.

La terminologie varie également selon les fournisseurs et la recherche. « Agent », « runtime », « mémoire », « outil », « connecteur » et « contexte » peuvent être définis différemment. Les définitions ici sont choisies pour rendre explicites la propriété opérationnelle et le diagnostic des défaillances, plutôt que pour affirmer que chaque framework utilise un vocabulaire identique.

La section Aaasaasa AI Client documente un modèle d'implémentation. Elle démontre que des frontières explicites sont pratiques, mais elle ne prouve pas que la même disposition des composants soit optimale pour chaque produit d'IA.

Qu'est-ce qui changerait cette réponse ?

La carte des responsabilités devrait être révisée si les architectures de modèles elles-mêmes commençaient à posséder un état externe faisant autorité, des permissions, des effets secondaires transactionnels durables et un accès vérifiable aux sources comme des propriétés intrinsèques plutôt que des capacités fournies par un système environnant. Les architectures de production actuelles ne font pas de cela une hypothèse générale sûre.

Les exemples d'implémentation individuels changeront bien plus tôt. Les outils de récupération hébergés, les API d'agents, les intégrations MCP, les fonctionnalités de gestion de contexte et les capacités des fournisseurs évoluent rapidement. Ces détails devraient être mis à jour sans effondrer les distinctions sous-jacentes entre génération, preuve, accès aux capacités, contexte, exécution et contrôle applicatif.

Conclusion

L'IA générative devient plus facile à concevoir une fois que « l'IA » cesse d'être traitée comme une seule boîte noire. Le modèle est le composant génératif, pas le produit complet. La récupération fournit des preuves externes. Les outils exposent des capacités. Le contexte transporte les informations sélectionnées vers l'inférence en cours. Le runtime coordonne l'exécution. L'application possède la frontière faisant autorité du produit.

Cette séparation est utile au-delà de l'explication. Elle indique aux ingénieurs d'où proviennent les faits obsolètes, où se situe l'autorisation, pourquoi un runtime local peut encore utiliser l'inférence cloud, pourquoi le RAG n'équivaut pas à une base de données vectorielle, pourquoi les appels d'outils nécessitent une validation, et pourquoi changer le modèle ne peut pas réparer toutes les défaillances du système.

La question architecturale durable n'est donc pas « Quel modèle d'IA utilisons-nous ? » Elle est : Quelle responsabilité chaque composant possède-t-il, quelles preuves traversent chaque frontière, et quelle couche est autorisée à modifier l'état réel ?

FAQ

Glossaire

Sources primaires et preuves d'implémentation

Les définitions stables ci-dessous sont ancrées dans des normes et des recherches ; les exemples de mise en œuvre à évolution rapide s'appuient sur la documentation d'ingénierie officielle actuelle. Aaasaasa AI Client constitue une preuve de mise en œuvre originale et a été vérifié par rapport à l'état de sa base de code et de sa documentation daté du 26 juillet 2026.