Qu'est-ce qu'un architecte de plateforme d'IA ? Modèles, données, environnement d'exécution, sécurité et opérations
Un architecte de plateforme d'IA conçoit la fondation d'IA réutilisable grâce à laquelle plusieurs applications, équipes ou contextes de locataires accèdent aux modèles, aux données et à la récupération, aux environnements d'exécution d'agents et d'outils, à l'identité et aux autorisations, à l'évaluation, à l'observabilité, aux quotas, aux secrets et aux capacités de déploiement. Le rôle est plus large que l'infrastructure mais plus étroit que la possession de chaque produit activé par l'IA : sa responsabilité centrale est de décider ce qui doit être partagé, comment les capacités partagées sont gouvernées et isolées, et ce qui doit rester spécifique à la solution.
Que conçoit réellement un architecte de plateforme d'IA ?
L'objet du travail est la plateforme : un ensemble de capacités partagées qui réduit le travail d'intégration répété tout en préservant des frontières explicites en matière de sécurité, de données et d'exploitation. Une plateforme peut exposer l'accès aux modèles, des adaptateurs de fournisseurs, des primitives de récupération, l'exécution d'agents, des courtiers d'outils, l'application des politiques, l'évaluation, la télémétrie et des services de déploiement à de nombreuses solutions consommatrices.
La plateforme n'a pas de valeur simplement parce que les composants sont centralisés. Elle a de la valeur lorsque les consommateurs reçoivent des capacités stables avec des contrats clairs, une propriété, une isolation, une observabilité et des règles de cycle de vie. La question architecturale clé n'est donc pas « Quel modèle tout le monde devrait-il utiliser ? » mais « Quelles responsabilités peuvent être normalisées et réutilisées en toute sécurité sans effacer les exigences de chaque solution ? ».
L'architecture de solution et l'architecture de plateforme résolvent des problèmes de portée différents
| Architecte de solution d'IA | Architecte de plateforme d'IA | |
|---|---|---|
| Portée principale | One concrete AI-enabled product, workflow or application. | Reusable AI capabilities consumed by multiple solutions, teams or tenant contexts. |
| Question principale | How should this solution meet its business, data, security, quality and operational requirements? | Which shared capabilities and controls should solutions consume, and where must solution-specific ownership remain? |
| Autorité sur les données | Defines which domain data is authoritative and how the solution may use it. | Provides storage, retrieval, provenance or access primitives without automatically becoming the authority for every domain. |
| Évaluation | Defines task-specific quality and acceptance criteria. | Provides reusable evaluation, telemetry and release mechanisms; it cannot define every domain's success threshold. |
| Cycle de vie | Owns the lifecycle of the specific workload. | Owns shared capability versions, compatibility, onboarding, quotas, policy and operational contracts. |
L'exemple le plus simple
Imaginez qu'une organisation dispose de cinq produits activés par l'IA : un assistant documentaire interne, un copilote d'assistance client, un agent d'ingénierie logicielle, un flux de travail de révision de contrats et un assistant de recherche de produits. Chaque produit pourrait intégrer indépendamment des API de modèles, conserver des identifiants, implémenter des nouvelles tentatives, collecter des métriques de jetons, créer du code de récupération et établir ses propres autorisations d'outils.
Cette duplication est coûteuse et dangereuse lorsque chaque équipe invente un modèle de sécurité et d'exploitation différent. Une plateforme partagée peut plutôt offrir des connexions de fournisseurs approuvées, la découverte de modèles, des quotas, des identifiants, un accès tenant compte des locataires, une télémétrie commune, des services de récupération réutilisables et un contrat d'environnement d'exécution d'agents/d'outils.
Mais la plateforme doit s'arrêter à la bonne frontière. La solution de révision de contrats peut exiger une autorité sur les documents juridiques et des règles de citation que l'agent logiciel n'a pas. L'assistant de recherche de produits peut avoir besoin de règles de fraîcheur et d'autorisation spécifiques au commerce. Une infrastructure réutilisable ne rend pas toute la vérité métier réutilisable.
Un chemin de requête d'IA partagé
Où l'exemple simple s'arrête
La centralisation n'est pas automatiquement de l'architecture. Un point de terminaison unique devant plusieurs API de modèles est utile, mais il ne crée pas à lui seul une plateforme d'IA. Une plateforme de production a également besoin de frontières d'identité, de contrats de capacités, de gestion de la santé et du cycle de vie des fournisseurs, de quotas, de propriété des secrets, d'observabilité, de règles de compatibilité, de contrôles de sécurité, de discipline de publication et d'une responsabilité opérationnelle claire.
L'échec opposé est également courant : mettre chaque invite, index vectoriel, règle métier, agent et flux de travail applicatif dans un seul « backend d'IA ». Cela crée un monolithe dont le statut partagé est accidentel plutôt qu'architectural. Une plateforme doit normaliser les capacités transversales, pas absorber la propriété métier simplement parce que l'IA est impliquée.
La décision de plateforme la plus importante : partagé ou spécifique à la solution
| Domaine de capacité | Bon candidat pour une propriété de plateforme partagée | Reste généralement spécifique à la solution |
|---|---|---|
| Accès aux modèles | Connexions fournisseurs approuvées, adaptateurs, identifiants, santé, primitives de routage, quotas | Acceptation des modèles spécifique à la tâche, comportement des invites, seuil de qualité |
| Récupération | Primitives d'ingestion, extraction, indexation, API de recherche, contrats de provenance, hooks d'autorisation | Corpus faisant autorité, règles de fraîcheur, métadonnées de domaine, suffisance des preuves |
| Agents et outils | Cycle de vie d'exécution, registre/courtier d'outils, application des permissions, traçage, annulation | Flux de travail métier, sémantique des actions autorisées, politique d'escalade, succès de la tâche |
| Sécurité | Intégration d'identité, stockage des secrets, application des politiques, contrats d'audit, mécanismes d'isolation des locataires | Classification des données, règles d'autorisation métier, acceptation des risques spécifiques au domaine |
| Évaluation | Harnais, mécanismes de jeu de données/version, télémétrie, flux de travail d'expérimentation/publication | Vérité terrain, jeu de test de domaine, seuil d'acceptation, résultat utilisateur |
| Opérations | Modèle de déploiement, santé, métriques, intégration des incidents, contrôles de capacité | SLO de solution lorsqu'ils diffèrent, impact sur la continuité d'activité, runbooks spécifiques à la charge de travail |
Carte des responsabilités d'architecture
1. Accès aux modèles et aux fournisseurs
Un architecte de plateforme définit comment les consommateurs découvrent et invoquent les modèles sans forcer chaque application à coder en dur un fournisseur. Cela inclut les adaptateurs de fournisseurs, les identifiants de modèles, les métadonnées de capacités, l'authentification, les contrôles de santé, la configuration des points de terminaison, la normalisation des requêtes et le comportement de compatibilité.
L'abstraction des fournisseurs doit rester honnête. Différents fournisseurs exposent différentes limites de contexte, sémantiques d'outils, comportements de sortie structurée, capacités multimodales, contrôles de sécurité, mise en cache, tarification et modes de défaillance. Une bonne abstraction crée un contrat de plateforme stable tout en préservant l'accès aux capacités qui ne peuvent pas être aplaties de manière significative.
2. Passerelle, routage, quotas et contrôles de coûts
Une passerelle IA partagée peut centraliser l'authentification, le routage, la limitation de débit, les tentatives, les limites de jetons, l'attribution d'utilisation et l'application des politiques. Les directives actuelles de Microsoft sur AI Gateway traitent explicitement les limites de jetons par minute, les quotas et le confinement multi-projets comme des préoccupations de plateforme ; AWS expose de même les quotas de compte et de modèle et des contrôles centralisés.
La passerelle est donc plus qu'un proxy inverse lorsqu'elle porte des politiques et des sémantiques opérationnelles spécifiques à l'IA. Mais elle ne doit pas prendre silencieusement des décisions métier. Une politique de routage peut préférer un modèle local sain, un fournisseur moins coûteux ou un point de terminaison conforme régionalement ; si cette route est acceptable pour une tâche particulière reste un contrat entre la plateforme et la solution.
Le routage nécessite également des sémantiques de défaillance. Si le modèle préféré est indisponible, la plateforme doit savoir si le repli est autorisé, si une route cloud nécessite un consentement explicite, si un modèle de moindre capacité est valide et comment la décision est exposée à l'observabilité.
3. Services partagés de données, de récupération et d'ancrage
Les services de récupération sont de bons candidats pour la plateforme car l'analyse, le découpage, l'indexation, la recherche lexicale, la recherche sémantique, le filtrage des métadonnées, la provenance et les mécanismes de citation sont réutilisables. Cependant, la plateforme ne doit pas confondre un moteur de récupération partagé avec une source de vérité partagée.
Une solution reste propriétaire de questions telles que : Quel corpus fait autorité ? Quelle version est valide ? Cet utilisateur peut-il voir ce document ? Quelle fraîcheur les données doivent-elles avoir ? Qu'est-ce qui compte comme preuve suffisante ? Une réponse peut-elle être générée lorsque la récupération échoue ? Ce sont des exigences de domaine et de solution même lorsque la plateforme fournit la machinerie de récupération.
Cette frontière est particulièrement importante dans les systèmes multi-locataires. Un index ou un service vectoriel techniquement partagé ne justifie pas une visibilité entre locataires. Le contexte d'autorisation doit être préservé tout au long de la récupération, et non ajouté seulement après que les résultats de recherche ont déjà franchi la frontière.
4. Exécution des agents et des outils
Les systèmes agentiques ajoutent des préoccupations d'exécution réutilisables : cycle de vie des fils/sessions, boucles de planification, enregistrement d'outils, invocation d'outils, annulation, délais d'attente, approbations humaines, interfaces de mémoire/état, protocoles d'agents distants et corrélation des traces. Une plateforme peut fournir ces mécanismes pour que chaque produit ne les reconstruise pas.
La plateforme doit également garder la permission des outils séparée de la capacité du modèle. Un modèle capable de générer une commande shell ne signifie pas que l'exécution doit autoriser l'exécution shell. La frontière de permission appartient à l'architecture de l'application/d'exécution et doit être applicable indépendamment du modèle.
Les recommandations actuelles d'AWS sur l'IA agentique mettent l'accent sur des agents à périmètre délimité, une autorité explicite, une traçabilité de bout en bout, des artefacts comportementaux versionnés et une supervision humaine proportionnée aux conséquences. Ce sont des préoccupations qui permettent la plateforme, mais la solution consommatrice définit encore quelles actions sont légitimes pour son domaine.
5. Identité, isolation des locataires et autorisation
Les plateformes d'IA se trouvent souvent devant des modèles à forte valeur, des données propriétaires et des outils capables d'actions. L'authentification n'est donc que le début. L'architecture doit transporter le contexte de l'utilisateur, du service, de l'application et du locataire à travers chaque opération privilégiée qui en a besoin.
Le RBAC et l'isolation des locataires résolvent des problèmes différents. Le RBAC répond à ce qu'une identité peut faire ; l'isolation des locataires répond sur les ressources de quel locataire cette identité peut agir. Une plateforme qui vérifie les rôles mais perd le contexte du locataire peut encore exposer les mauvaises données.
Les recommandations actuelles de Microsoft sur les charges de travail d'IA préconisent explicitement la segmentation des identités et un accès au contenu tenant compte de l'autorisation. Les recommandations d'AWS sur les plateformes d'IA générative multi-locataires traitent de même l'isolation logique, les contrôles centralisés et l'auditabilité comme des préoccupations de plateforme.
6. Secrets, identifiants et frontières de confiance
Une plateforme doit définir qui possède les clés des fournisseurs, les jetons porteurs distants, le matériel de signature et les identifiants des outils, où ils sont stockés, quel processus peut y accéder, comment ils sont renouvelés et s'ils peuvent un jour atteindre un navigateur ou un moteur de rendu non fiable.
Il s'agit d'une frontière architecturale, pas d'un détail d'implémentation. Si chaque application consommatrice copie les identifiants du fournisseur dans sa propre configuration, l'organisation a dupliqué à la fois la charge opérationnelle et le rayon d'impact. La centralisation ne peut réduire ce risque que si la plateforme elle-même dispose de chemins d'accès plus étroits et auditables.
7. Évaluation, observabilité et auditabilité
Une plateforme réutilisable peut fournir des harnais d'évaluation, des identifiants de trace, des métadonnées de modèle/fournisseur, des métriques de jetons et de coûts, la latence, les taux d'erreur, la liaison version de prompt/modèle, les traces d'agents/outils et une journalisation contrôlée. AWS et Microsoft considèrent tous deux l'observabilité et l'évaluation comme des préoccupations de production essentielles pour les charges de travail d'IA.
L'évaluation de la plateforme et l'évaluation de la solution doivent rester distinctes. Une plateforme peut vérifier qu'un point de terminaison est sain, qu'une version de modèle passe une suite de régression générale et que les traces sont complètes. Elle ne peut pas décider qu'une réponse juridique, un flux de travail médical ou une recommandation de produit est acceptable sans vérité terrain et critères d'acceptation spécifiques au domaine.
La journalisation crée également une frontière de confidentialité. Les journaux de prompts et de réponses peuvent contenir des données sensibles ou propriétaires. L'architecte de plateforme doit donc décider ce qui est journalisé, masqué, échantillonné, conservé et accessible plutôt que de supposer que plus de télémétrie est toujours plus sûr.
8. Exécution, déploiement et localité
Un architecte de plateforme décide comment les capacités d'IA partagées sont déployées et atteintes : services cloud gérés, points de terminaison auto-hébergés, inférence locale, routage hybride, services conteneurisés, environnements d'exécution de bureau, réseaux privés ou environnements isolés. La distinction importante est entre l'endroit où le processus de contrôle/exécution s'exécute et l'endroit où l'inférence et le traitement des données se produisent réellement.
Un client local peut encore appeler un modèle cloud. Un plan de contrôle cloud peut router vers un modèle sur site. Un agent distant peut exécuter des outils à l'intérieur du réseau d'un client. Les diagrammes d'architecture doivent donc montrer les frontières de confiance et de flux de données plutôt que d'utiliser « local » et « cloud » comme des étiquettes vagues.
9. Cycle de vie de la plateforme, compatibilité et intégration
Une capacité réutilisable ne devient une plateforme que lorsque les consommateurs peuvent en dépendre dans le temps. Cela nécessite des contrats versionnés, des règles de migration, une politique de compatibilité, la dépréciation, des tests de version, la restauration, la responsabilité des incidents, la planification de la capacité, la documentation et un chemin pour intégrer de nouvelles équipes ou applications.
Les écosystèmes d'IA en évolution rapide rendent cela particulièrement important. Les noms de modèles, les SDK, les versions de protocole, les API des fournisseurs et les capacités de sécurité changent indépendamment. Une plateforme doit absorber une partie de cette volatilité sans masquer les changements qui affectent matériellement le comportement d'une solution.
Un modèle pratique de plan de contrôle / plan d'exécution / plan de solution
| Plan | Responsabilités typiques | Ne devrait pas posséder silencieusement |
|---|---|---|
| Plan de contrôle de la plateforme | Registre des fournisseurs, politique de modèles, quotas, configuration des locataires, identités, secrets, règles de routage, versions des capacités, configuration de déploiement | Logique métier applicative ou vérité du domaine |
| Plan d'exécution/données de la plateforme | Requêtes d'inférence, opérations de récupération, exécution d'agents/outils, extraction, indexation, émission de télémétrie, application des politiques | Accès inter-locataires simplement parce que l'infrastructure est partagée |
| Plan de solution | Flux de travail utilisateur, invites/instructions, sélection du corpus faisant autorité, autorisation de domaine, règles métier, évaluation et acceptation des tâches | Intégration de fournisseur de bas niveau que la plateforme possède explicitement |
Cette séparation aide à diagnostiquer la dérive de la plateforme. Si une application doit connaître chaque identifiant et point de terminaison spécifique à un fournisseur, le contrat de la plateforme est trop mince. Si la plateforme décide quel enregistrement client fait légalement autorité ou si une réponse de domaine est acceptable, la plateforme a empiété sur la propriété de la solution.
Que devrait produire un architecte de plateforme IA ?
| Artefact d'architecture | Objectif |
|---|---|
| Carte des capacités de la plateforme | Définit ce que la plateforme fournit, qui la consomme et quelles capacités restent hors périmètre. |
| Contrat fournisseur/modèle | Définit les fournisseurs, les modèles, les capacités, les frontières d'abstraction, les métadonnées de routage et la sémantique de repli. |
| Modèle d'identité et de multi-location | Définit l'identité utilisateur/service/application, le contexte de locataire, les points d'ancrage RBAC/ABAC et l'isolation des ressources. |
| Politique de passerelle et de quotas | Définit les limites de débit, les budgets de jetons/coûts, les contrôles de routage, les tentatives et le comportement de capacité. |
| Contrat de récupération/données | Définit l'ingestion, la provenance, la recherche, les métadonnées, la propagation de l'autorisation et où l'autorité de domaine reste. |
| Contrat agent/outil | Définit le cycle de vie d'exécution, l'enregistrement des outils, les permissions, les approbations, l'annulation et le comportement de trace. |
| Modèle de secrets et de frontières de confiance | Définit la propriété des identifiants, le stockage, les frontières de processus, la rotation et les chemins de données sensibles. |
| Contrat d'évaluation et de télémétrie | Définit les métriques communes, les traces, les liens de jeux de données/versions, la politique de journalisation et les points d'extension de solution. |
| Politique de cycle de vie et de compatibilité | Définit les versions, les migrations, la dépréciation, les versions, le retour arrière, la propriété des incidents et l'intégration. |
Le travail est surtout une question de compromis, pas de centralisation maximale
Compromis courants de plateforme
| Pression A | Pression B | |
|---|---|---|
| Abstraction du fournisseur | Stable portable platform API | Access to provider-specific capabilities and fast innovation |
| Réutilisation | Shared services reduce duplication | Isolation and domain autonomy prevent unsafe coupling |
| Gouvernance | Central policy and auditability | Team speed and local experimentation |
| Observabilité | Rich traces for debugging and evaluation | Privacy, data minimization and logging cost |
| Disponibilité | Fallback and multi-provider resilience | Predictable quality, compliance and data-location guarantees |
| Périmètre de la plateforme | More reusable capabilities | Smaller blast radius and less platform lock-in |
En quoi cela diffère-t-il des rôles adjacents ?
| Rôle | Périmètre architectural principal |
|---|---|
| Architecte de solution IA | Une solution concrète activée par l'IA et ses exigences de bout en bout, frontières, compromis et acceptation en production. |
| Architecte de plateforme IA | Capacités IA réutilisables et contrats opérationnels/de sécurité consommés à travers plusieurs solutions ou équipes. |
| Architecte d'entreprise | Portefeuille métier/technologique à l'échelle de l'organisation, alignement des capacités et de la gouvernance à un niveau plus large. |
| Architecte ou spécialiste MLOps / LLMOps | Cycle de vie des modèles et de l'IA, déploiement, expériences, observabilité, publication et pratiques opérationnelles ; peut fortement chevaucher mais ne possède pas automatiquement toute la plateforme applicative partagée. |
| Ingénieur de plateforme / SRE | Implémente et exploite l'infrastructure de la plateforme, la fiabilité, l'automatisation et l'expérience développeur ; la responsabilité architecturale peut être partagée avec l'architecte de plateforme. |
| Ingénieur IA / logiciel | Implémente les modèles, intégrations, services, agents, récupération et fonctionnalités produit dans l'architecture convenue. |
Ces frontières sont organisationnelles, pas universelles. Dans une petite équipe, une personne peut assumer plusieurs responsabilités. Dans une entreprise réglementée, elles peuvent être réparties entre les groupes architecture, sécurité, plateforme, données et opérations. La distinction utile est le périmètre de responsabilité architecturale, pas le titre de poste imprimé sur un organigramme.
Preuves de mise en œuvre : comment ces frontières de plateforme apparaissent dans mon propre travail
Aaasaasa AI Client : séparation des fournisseurs, de l'exécution et des permissions
Aaasaasa AI Client est un espace de travail IA de bureau local-first construit avec Nuxt 4, Electron et TypeScript. Son AI Hub sépare délibérément agent/client, fournisseur, modèle, emplacement de connexion/exécution, permissions et client web au lieu de les traiter comme une seule valeur de configuration.
L'implémentation inclut des adaptateurs de fournisseurs directs, l'intégration du runtime d'agent Codex, des chemins locaux Ollama/LM Studio, des services compatibles OpenAI, des permissions d'espace de travail centralisées, le stockage des identifiants dans le processus principal, DuckDB, le support Qdrant/vectoriel, l'extraction PDF/lisibilité et l'accès authentifié aux répertoires basé sur MCP.
Deux leçons de plateforme sont particulièrement pertinentes. Premièrement, un runtime local n'est pas la même chose qu'une inférence locale : un processus Codex local peut toujours utiliser un modèle cloud. Deuxièmement, le routage automatique ne bascule pas silencieusement d'une inférence locale à une inférence cloud payante. Cela rend la politique de routage et la localité d'exécution explicites plutôt qu'inférées à partir des libellés de l'interface.
| Frontière mise en œuvre | Signification pour l'architecture de plateforme |
|---|---|
| Agent vs fournisseur vs modèle | Des responsabilités différentes peuvent évoluer indépendamment au lieu d'être cachées derrière un seul sélecteur « IA ». |
| Permissions séparées du modèle | L'autorité sur le système de fichiers/les outils appartient à la politique d'exécution, pas à la capacité du modèle. |
| Secrets dans le processus principal | La propriété des identifiants suit la frontière du processus privilégié plutôt que le moteur de rendu/l'interface. |
| Santé du fournisseur et découverte de modèles | Le routage et la disponibilité sont des préoccupations d'exécution/de plateforme. |
| Pas de repli cloud silencieux | Les sémantiques de coût, de localité et de transfert de données restent des décisions politiques explicites. |
Aaasaasa AI CMS : l'autorisation limitée au locataire comme frontière de plateforme
La base de code d'Aaasaasa AI CMS fournit un exemple d'implémentation distinct : le RBAC limité au locataire est représenté par des rôles, des permissions et des attributions de rôles utilisateur liés à un identifiant de locataire. Les permissions système sont regroupées par capacité, et la recherche et les mises à jour des rôles restent limitées au locataire.
Cela ne constitue pas en soi la preuve d'une plateforme d'IA complète, mais c'est directement pertinent pour l'une des frontières de plateforme partagée les plus difficiles : un service réutilisable doit préserver qui peut faire quoi et pour quel locataire. L'ajout d'inférence ou de récupération d'IA au-dessus d'une plateforme applicative ne supprime pas cette exigence.
L'implication architecturale est que les passerelles de modèles, les services de récupération et les agents devraient consommer le contexte d'identité/locataire établi plutôt que d'inventer un univers d'autorisation parallèle réservé à l'IA.
Source of Truth Research Engine : mécanismes de récupération partagés sans vérité partagée
Le Source of Truth Research Engine fournit un troisième exemple d'implémentation. Différents modes de recherche partagent un noyau de preuves commun : Sources, Artefacts, provenance, Affirmations, Relations, Contradictions, un Modèle de Référence et une piste d'audit. Le système fournit également une récupération lexicale locale, une récupération sémantique optionnelle, l'extraction, des instantanés et une provenance basée sur SHA-256.
Le projet traite explicitement la recherche et la similarité sémantique comme des signaux de découverte plutôt que comme des preuves. Un résultat doit être retracé jusqu'à une source et un localisateur concrets avant de pouvoir étayer une affirmation. C'est précisément la distinction dont une plateforme d'IA a besoin : la machinerie de récupération réutilisable peut être partagée tandis que l'autorité des preuves reste régie par la méthodologie et le domaine consommateurs.
Le moteur démontre également pourquoi une plateforme partagée unique n'exige pas une interprétation partagée unique. Les modes historique, scientifique/technique, d'intelligence de marché et de surveillance peuvent réutiliser l'infrastructure de preuves de base tout en conservant une méthodologie spécifique au mode.
Comment les orientations architecturales actuelles soutiennent ce périmètre de plateforme
ISO/IEC/IEEE 42010:2022 fournit une discipline générale pour les descriptions d'architecture à travers les logiciels, les systèmes, les entreprises et les entités connexes. Il ne définit pas un Architecte de Plateforme d'IA, mais il renforce la nécessité d'exprimer les préoccupations, les relations et les points de vue architecturaux plutôt que de réduire l'architecture à une liste de technologies.
NIST AI RMF 1.0 et le Profil d'IA Générative encadrent la gestion des risques d'IA sur l'ensemble du cycle de vie plutôt qu'au seul moment de la sélection du modèle. La gouvernance, la cartographie, la mesure et la gestion sont donc compatibles avec une architecture de plateforme qui porte des contrôles et des preuves partagés à travers de nombreuses charges de travail consommatrices.
Les orientations actuelles de Microsoft sur les charges de travail d'IA traitent la conception d'applications, les données, la sécurité, les opérations, les tests/évaluation et GenAIOps comme des domaines architecturaux connectés. Ses orientations actuelles sur la passerelle d'IA montrent également des préoccupations pratiques de plateforme telles que l'accès centralisé aux modèles, les limites de jetons spécifiques au projet, les quotas et le confinement multi-équipes.
Le Lens d'IA Générative actuel d'AWS et le scénario de plateforme multi-locataires séparent de même les contrôles de plateforme fondamentaux de la propriété des applications consommatrices. AWS note explicitement qu'une plateforme centrale peut appliquer des garde-fous partagés et une auditabilité tandis que la qualité des données et l'observabilité spécifique à la charge de travail restent des responsabilités des applications consommatrices ou des producteurs de données.
Les produits des fournisseurs diffèrent, mais le modèle inter-sources est stable : les plateformes d'IA en production doivent coordonner l'identité, l'accès aux données, les modèles, la politique, l'évaluation, l'observabilité, la capacité, le coût et le cycle de vie. Un cluster de GPU ou un point de terminaison de modèle ne couvre qu'une partie de cette responsabilité.
Idées fausses courantes
| Idée fausse | Pourquoi c'est faux |
|---|---|
| « Une plateforme d'IA, c'est le cluster de GPU. » | Le calcul est un substrat. Une plateforme a aussi besoin de contrats pour l'identité, l'accès aux modèles, les données, la politique, l'évaluation, l'observabilité et le cycle de vie. |
| « Une passerelle d'IA n'est qu'un proxy inverse. » | Elle peut aussi porter le routage de modèles, les quotas de jetons, l'attribution des coûts, l'application des politiques, l'identité et la télémétrie spécifique à l'IA. |
| « Partagé signifie partagé globalement. » | Un service peut être physiquement partagé tout en étant logiquement segmenté par locataire, application, région, classification ou niveau de risque. |
| « Une base de données vectorielle centrale unique devient la vérité de l'entreprise. » | Un magasin vectoriel ou un service de récupération est une infrastructure. L'autorité du domaine, la fraîcheur, la provenance et l'accès restent des préoccupations distinctes. |
| « L'évaluation de la plateforme remplace l'évaluation de la solution. » | La régression générale et la télémétrie ne peuvent pas définir si une réponse ou une action spécifique à un domaine est acceptable. |
| « L'abstraction du fournisseur devrait masquer toutes les différences. » | Certaines différences sont des capacités matérielles, des sémantiques de sécurité ou des modes de défaillance et doivent rester visibles. |
| « Le RBAC résout le multi-locataires. » | Le RBAC contrôle les actions ; l'isolation des locataires contrôle les frontières des ressources. Les deux peuvent être nécessaires. |
| « Architecte de Plateforme d'IA n'est qu'un autre nom pour MLOps. » | MLOps/LLMOps est une discipline majeure qui se chevauche, mais les frontières partagées d'application/exécution, d'identité, de passerelle, de récupération et d'outils peuvent s'étendre au-delà des opérations du cycle de vie des modèles. |
Modes de défaillance qu'un Architecte de Plateforme d'IA devrait prévenir
| Mode de défaillance | Conséquence architecturale |
|---|---|
| Chaque équipe stocke ses propres clés de fournisseur | Gestion dupliquée des secrets, rotation incohérente et rayon d'impact plus large. |
| L'abstraction du fournisseur masque les capacités requises | Les consommateurs ne peuvent pas utiliser les fonctionnalités dont ils ont besoin ou reçoivent silencieusement un comportement différent des hypothèses. |
| La récupération partagée ignore le contexte du locataire/utilisateur | Une fuite de données entre frontières peut se produire avant que l'application ait la possibilité de filtrer les résultats. |
| Le repli change silencieusement de fournisseur ou de localité | Le coût, la conformité, la localisation des données et la qualité de sortie peuvent changer sans que l'appelant le sache. |
| Les outils d'agent sont accordés par le choix du modèle | Un modèle performant devient sur-privilégié car l'autorité d'exécution n'est pas appliquée indépendamment. |
| Tous les prompts/réponses sont journalisés par défaut | L'observabilité peut créer un nouveau dépôt de données sensibles et un problème de conformité. |
| La plateforme possède un score de qualité générique unique | Les défaillances du domaine restent cachées derrière les métriques de santé de la plateforme. |
| Aucun contrat de version pour les capacités de la plateforme | Les changements de modèle/fournisseur/environnement d'exécution cassent les consommateurs de manière imprévisible. |
| Tout ce qui est lié à l'IA est centralisé | La plateforme devient un goulot d'étranglement et un monolithe au lieu d'une couche de capacités réutilisables. |
Une séquence de décision pratique pour l'architecture de plateforme
Du besoin de plateforme à une capacité partagée exploitable
Cas limites et limites du rôle
Une petite organisation avec une seule application d'IA peut ne pas avoir besoin d'une plateforme d'IA distincte ni d'un architecte de plateforme. Une plateformisation prématurée peut créer plus d'abstraction que de valeur. L'architecture correcte peut être une solution bien conçue avec quelques modules réutilisables.
Un déploiement en air gap ou souverain change considérablement le modèle de fournisseur, de mise à jour et d'observabilité. L'hébergement de modèles, la distribution d'artefacts, l'intégration d'identité et l'export de télémétrie peuvent tous nécessiter des équivalents locaux.
Les charges de travail hautement réglementées ou à fort impact peuvent nécessiter une isolation physique ou organisationnelle plus forte au lieu d'une plateforme logiquement partagée. La réutilisation n'est jamais une raison suffisante pour affaiblir une frontière de sécurité requise.
Les services d'IA cloud gérés peuvent supprimer la charge de mise en œuvre mais ne suppriment pas la responsabilité architecturale. L'organisation décide toujours de l'identité, de l'accès aux données, de la journalisation, de la rétention, des quotas, de l'éligibilité des modèles, du repli, de l'évaluation et de l'acceptation des solutions.
La frontière de la plateforme peut également différer selon la modalité. L'inférence textuelle, la génération multimodale, la parole, l'utilisation d'ordinateur et les agents autonomes peuvent avoir des exigences différentes en matière de latence, de données, de permissions et d'observabilité, même lorsqu'ils partagent l'infrastructure de fournisseur et d'identité.
Qu'est-ce qui changerait cette réponse ?
La définition principale changerait si la portée organisationnelle change. Si l'architecte est responsable d'une seule charge de travail, le rôle se rapproche de celui d'Architecte de Solutions d'IA. Si la responsabilité s'étend à la stratégie de capacités à l'échelle de l'organisation, aux investissements, aux normes et aux portefeuilles cibles, elle se rapproche de l'Architecture d'IA d'Entreprise.
Les conseils de mise en œuvre changent chaque fois que les fournisseurs, les produits de passerelle, les protocoles d'agent, les obligations réglementaires, les capacités des modèles ou les contraintes de déploiement changent. C'est pourquoi l'architecture de plateforme doit exprimer des responsabilités et des contrats stables indépendamment des mécanismes actuels des fournisseurs.
Liste de contrôle de l'Architecte de Plateforme d'IA
| Question | Réponse attendue |
|---|---|
| Qui sont les consommateurs réels de la plateforme ? | Des solutions, équipes ou contextes de locataires nommés avec des besoins distincts mais qui se chevauchent. |
| Qu'est-ce qui est réellement partagé ? | Une liste explicite de capacités, pas un vague « backend IA ». |
| Qu'est-ce qui doit rester spécifique à la solution ? | L'autorité métier, le flux de travail métier, l'acceptation des tâches et autres préoccupations propres à la charge de travail. |
| Comment les modèles/fournisseurs sont-ils représentés ? | Des contrats de fournisseur/modèle versionnés avec des capacités et une sémantique de repli explicite. |
| Comment l'identité est-elle propagée ? | Le contexte utilisateur/service/application/locataire survit à chaque chemin de requête privilégié. |
| Comment l'isolation des locataires est-elle appliquée ? | La portée des ressources est distincte des vérifications de permissions de rôle. |
| Comment les secrets sont-ils gérés ? | Stockage privilégié, rotation, exposition limitée et propriété auditable. |
| Comment la récupération préserve-t-elle l'autorité ? | Des mécanismes partagés avec autorisation, provenance et règles de preuve propres au domaine. |
| Comment les outils et agents sont-ils contraints ? | Permissions d'exécution, contrats d'outils bornés, approbations, annulation et traçabilité. |
| Comment le coût et la capacité sont-ils contrôlés ? | Quotas, contrôles de jetons/débit, attribution d'utilisation et comportement en cas de surcharge. |
| Comment la qualité est-elle mesurée ? | Régression/évaluation de la plateforme plus vérité terrain et acceptation spécifiques à la solution. |
| Comment les changements sont-ils déployés ? | Versionnage, compatibilité, migration, dépréciation, retour arrière et propriété des incidents. |
Conclusion
Un Architecte de Plateforme d'IA est responsable de l'architecture réutilisable entre les capacités d'IA et les solutions qui les consomment. Le rôle définit comment les modèles, fournisseurs, récupération, agents, outils, identité, locataires, secrets, évaluation, observabilité, quotas et opérations d'exécution deviennent des services de plateforme fiables plutôt que des intégrations ponctuelles répétées.
La partie difficile n'est pas de maximiser la réutilisation. C'est de choisir la bonne frontière. Une plateforme solide standardise les mécanismes, la politique et les opérations là où plusieurs consommateurs en bénéficient réellement, tout en préservant l'autorité sur les données, la logique métier, les exigences de sécurité et les critères d'acceptation propres à chaque solution.
Cette distinction explique aussi la relation avec l'Architecture de Solutions d'IA : l'architecte de solutions fait en sorte qu'un système doté d'IA corresponde à son objectif ; l'architecte de plateforme fait en sorte que les capacités d'IA partagées soient sûres, réutilisables, exploitables et évolutives à travers de nombreux systèmes de ce type.
Connaissances canoniques associées
Cet article se situe après les fondations canoniques sur les composants d'IA générative, ADR versus NFR, et l'architecture de solutions d'IA. Ces concepts sont des prérequis car une plateforme existe pour fournir des capacités système réutilisables et pour encoder les décisions architecturales en fonction d'exigences explicites de qualité et d'exploitation.
La génération augmentée par récupération est un exemple de capacité qui peut être offerte via une plateforme, mais la plateforme ne doit pas fusionner l'infrastructure de récupération, la connaissance métier et la validité des réponses en un seul concept.
Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnementIntroduction canonique à la génération augmentée par récupération et à la frontière entre la génération par le modèle et la récupération de connaissances externes.
Les protocoles d'agents, l'isolation des locataires, la gouvernance de l'IA, le routage des modèles, l'ingénierie du contexte et MLOps/LLMOps sont des nœuds de connaissance en aval ou adjacents. Ils deviennent plus faciles à appréhender une fois la frontière de la plateforme explicite.
Questions fréquemment posées
FAQ de l'architecte de plateforme d'IA
Un architecte de plateforme d'IA est-il identique à un architecte de solutions d'IA ?
Une plateforme d'IA doit-elle héberger ses propres modèles ?
Une passerelle d'IA suffit-elle pour constituer une plateforme d'IA ?
La récupération doit-elle être centralisée ?
L'évaluation de la plateforme remplace-t-elle l'évaluation de l'application ?
La multi-location est-elle simplement du RBAC ?
Glossaire
Termes clés de l'architecture de plateforme d'IA
- Plateforme d'IA
- Un ensemble réutilisable de capacités techniques et opérationnelles liées à l'IA, consommées par plusieurs applications, équipes ou contextes de locataires.
- Passerelle d'IA
- Une couche de passerelle pour les points de terminaison d'IA qui peut ajouter l'authentification, le routage, les quotas, la politique, les tentatives, l'attribution des coûts et la télémétrie spécifique à l'IA au-delà du simple proxy.
- Adaptateur de fournisseur
- Un composant qui mappe un contrat de plateforme vers l'API, les capacités, l'état de santé et la sémantique de défaillance d'un fournisseur de modèles.
- Isolation des locataires
- La frontière qui empêche un contexte de locataire d'accéder aux ressources d'un autre locataire, indépendamment des permissions de rôle.
- Contrat de capacité
- Une interface versionnée et un accord comportemental décrivant ce qu'un service de plateforme partagé fournit et ce que le consommateur doit fournir ou posséder.
- Service d'ancrage / de récupération
- Mécanismes partagés pour trouver et fournir des informations externes à une charge de travail d'IA ; cela ne définit pas automatiquement quelles informations font autorité pour un domaine.
- Harnais d'évaluation
- Infrastructure réutilisable pour exécuter des tests, des jeux de données, des versions de modèles/prompts et des métriques ; l'acceptation métier reste spécifique à la solution.
- Plan de contrôle
- La couche de configuration et de gouvernance qui gère les capacités de la plateforme, les identités, les politiques, les quotas, les versions et l'état de déploiement.
Sources primaires et orientations architecturales actuelles
Les sources ci-dessous étayent les affirmations générales sur l'architecture et la plateforme de production. Les sections Aaasaasa AI Client, Aaasaasa AI CMS et Source of Truth Research Engine constituent explicitement des preuves de mise en œuvre originales. Les références externes à l'état actuel ont été vérifiées le 8 octobre 2026.
ISO/IEC/IEEE 42010:2022 — Description de l'architectureNorme internationale publiée actuelle pour les concepts et relations de description d'architecture.
Cadre de gestion des risques d'IA du NISTRessources et statut actuel de l'AI RMF du NIST ; l'AI RMF 1.0 est en cours de révision en octobre 2026.
NIST AI 600-1 — Profil d'IA générativeProfil d'IA générative pour appliquer les considérations de gestion des risques d'IA tout au long du cycle de vie de l'IA.
Microsoft Azure Well-Architected — Charges de travail d'IAOrientations architecturales actuelles couvrant l'application d'IA, les données, les opérations, l'évaluation, l'IA responsable et les préoccupations du cycle de vie.
Microsoft — Principes de conception pour les charges de travail d'IAOrientations actuelles sur la segmentation des identités, les frontières de sécurité, la télémétrie, les performances, les données et les compromis de plateforme.
Microsoft Foundry — Architecture de passerelle d'IAOrientations actuelles sur la passerelle d'IA pour l'accès partagé aux projets, la maîtrise des jetons, les quotas et la gouvernance.
Centre d'architecture Azure — Accéder aux modèles via une passerelleOrientations architecturales pour l'accès centralisé aux modèles, le routage, la limitation, le basculement et les responsabilités client/plateforme.
AWS Well-Architected — Lens IA générativesConseils d'architecture de production actuels pour les charges de travail d'IA génératives couvrant la sécurité, la fiabilité, les opérations, les performances et les coûts.
AWS — Scénario de plateforme d'IA générative multi-locatairesExemple actuel séparant les contrôles de plateforme centrale et l'auditabilité de la qualité des données des applications consommatrices et des responsabilités propres à chaque charge de travail.
AWS Well-Architected — Principes de conception de l'IA agentiqueConseils actuels sur l'autorité limitée des agents, la traçabilité, le comportement versionné, les contrats explicites et la supervision humaine.
AWS CloudWatch — Observabilité de l'IA générativeCapacités d'observabilité actuelles et métriques de production pour les modèles, les agents, les bases de connaissances, les outils et l'analyse des coûts/latence/erreurs.
Related Articles
MCP expliqué : ce qu'il connecte, ce qu'il ne fait pas et où il s'intègre
Le protocole de contexte de modèle connecte les applications d’IA à des outils, des ressources et des invites externes par le biais d’une frontière standard client-serveur. Découvrez ce que fait le MCP, ce qu’il ne fait pas et où il s’intègre dans l’architecture des agents.
Enterprise-Grade Multi-Tenant Architecture for an International Platform
Loving Rocks is an enterprise-grade wedding platform designed with a true multi-tenant architecture, isolated databases per tenant, and built-in internationalization for global scalability, security, and long-term operational stability.
La frontière de validité des réponses : la couche manquante entre la pertinence et les réponses fiables de l'IA
Une source peut être pertinente, faisant autorité et pourtant être erronée pour la question posée. La couche manquante est l'applicabilité : les conditions dans lesquelles une réponse est valable, et les changements qui obligent à la reconsidérer. Cet article présente la Frontière de Validité de la Réponse comme un modèle de conception de source pour les humains, la recherche par IA et les systèmes RAG.
Que devrait mémoriser, oublier, recalculer ou récupérer à nouveau un agent IA ?
Les agents à exécution longue ne devraient pas tout retenir. Cet article propose un modèle de cycle de vie pratique pour décider de ce qui a sa place dans la mémoire durable, de ce qui devrait être récupéré à nouveau, de ce qu'il est plus sûr de recalculer et de ce qui devrait expirer ou être remplacé.
La mémoire des agents IA n'est pas le RAG : comment séparer la mémoire, la récupération, l'état et le contexte
La mémoire des agents, le RAG, l'état et le contexte sont souvent utilisés comme s'ils étaient interchangeables. Ils ne le sont pas. Ce modèle d'architecture pratique sépare les quatre couches, montre où chacune se situe et explique ce qui dysfonctionne lorsque les systèmes les fusionnent en une seule.
Qu'est-ce qu'un architecte de solutions IA ? Limites du système, responsabilités et compromis
Un architecte de solutions d'IA transforme les exigences métier en un système d'IA prêt pour la production, couvrant les données, les modèles, les outils, la sécurité, l'exécution, l'évaluation et les opérations.
D'où un LLM tire-t-il ses données ? Sources de données RAG en Python
Un LLM ne connaît pas magiquement vos fichiers, bases de données ou API. Cette suite pratique de la série sur le RAG montre, avec du Python simple, comment des données externes deviennent des preuves récupérables : des fichiers texte et du SQL à la recherche en texte intégral, aux embeddings, à l'assemblage du contexte et à l'appel final au LLM.
IA souveraine : contrôle des modèles, des données, des infrastructures et des dépendances
L'IA souveraine concerne le contrôle effectif sur les modèles, les données, l'infrastructure, les logiciels, les opérations et les dépendances stratégiques — et non simplement l'endroit où un modèle d'IA est hébergé.
Bases de données vectorielles, plongements et reclassement : trois parties distinctes de la recherche
Les embeddings représentent le sens, les bases de données vectorielles récupèrent des candidats, et les rerankers affinent les résultats. Découvrez comment ces trois couches de récupération diffèrent et fonctionnent ensemble dans le RAG.
L'IA agentique expliquée : quand un système d'IA peut planifier, utiliser des outils et agir
L'IA agentique utilise des modèles au sein de boucles d'exécution multi-étapes où ils peuvent choisir des outils, observer les résultats, mettre à jour l'état et adapter leur action suivante dans des limites explicites d'exécution et de permissions.
MCP vs A2A vs UCP vs AP2 vs A2UI : La pile de protocoles d'agent expliquée
MCP, A2A, UCP, AP2 et A2UI sont souvent présentés comme des standards d'agents concurrents. Ils résolvent principalement des problèmes d'interopérabilité différents. Ce guide associe chaque protocole à la frontière qu'il standardise réellement—et montre comment ils peuvent fonctionner ensemble dans un seul système de production.
Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement
Le RAG semble compliqué, mais l'idée est simple : avant qu'une IA ne réponde, elle recherche d'abord des informations utiles dans une source de connaissances et transmet ces informations au modèle de langage. Ce guide explique le RAG, les LLM, l'état, la mémoire et les outils à l'aide d'un modèle mental simple.