Le déploiement de Microsoft Foundry au sein de mon organisation

Un plan de déploiement structuré vous permet d’éviter les lacunes de sécurité, les dépassements de coûts et l’extension de l’accès lorsque vous adoptez Microsoft Foundry à grande échelle. Utilisez ce guide pour définir des limites de charge de travail, choisir une topologie de ressources et établir une gouvernance pour les équipes en libre-service.

Conditions préalables

Avant de commencer la planification, vérifiez que vous disposez des points suivants :

• Une compréhension de l’abonnement Azure de base de votre organisation et de l’organisation des groupes de ressources.
• Entrées sur les exigences de sécurité de votre organisation pour la mise en réseau, le chiffrement et l’isolation des données.
• Plan de région initial basé sur la disponibilité des modèles et des fonctionnalités. Pour plus d’informations, consultez la disponibilité des fonctionnalités dans les régions cloud.
• Accord sur les exigences de sécurité pour la mise en réseau, le chiffrement et l’isolation des données dans votre organisation.
• Inventaire des fonctionnalités et API Foundry que vos équipes prévoient d’utiliser.

Définir des limites d’isolation

Commencez par les conseils de prise de décision du Cloud Adoption Framework pour le partage de plateforme d’IA, puis appliquez ces décisions à Foundry :

• Définir des limites de partage de plateforme IA

Bien que chaque situation soit unique, pour l’organisation commune, nous recommandons la séquence suivante :

1. Définissez des limites de partage non modifiables entre les unités commerciales, les domaines de données, la propriété du produit et les niveaux d’environnement.
2. Définissez une stratégie prod qui est par défaut isolée, sauf si une exception documentée autorise la colocalisation.
3. Définissez une stratégie d’exploration qui colocalise par défaut pour une expérimentation plus rapide, sauf si la conformité ou la validation nécessite une isolation.
4. Attribuez un responsable à chaque périmètre, notamment pour la sécurité, les coûts et la réponse aux incidents.

Identifier les exigences de capacité et d’accès

Déterminez les fonctionnalités et API Foundry requises par chaque charge de travail avant de finaliser votre topologie.

Pour les cas d’usage colocalisés qui partagent une ressource Foundry, utilisez des projets Foundry comme espaces de travail isolés pour chaque cas d’usage. Par exemple, les équipes qui expérimentent une idée peuvent créer un projet pour organiser des ressources cohérentes sans répéter la configuration de l’infrastructure pour la sécurité, les déploiements de modèles et l’accès aux outils.

Les API Foundry centrées sur les agents les plus récentes prennent en charge l’autorisation d’étendue du projet. Certaines API Foundry Tools traditionnelles (anciennement Azure AI Services), telles que la transcription vocale, nécessitent toujours un accès à la portée de la ressource parente. Définissez les limites du plan et le RBAC afin que toutes les fonctionnalités requises soient accessibles dans le périmètre de gestion des accès visé.

Choisir la topologie de ressource Foundry

Après avoir défini des limites et des besoins en fonctionnalités, choisissez la topologie par environnement.

Planifier votre base de référence de sécurité

Utilisez ce tableau de référence comme liste de contrôle pour les décisions de conception de sécurité.

Planifier le modèle, la région et la stratégie de capacité

Pour chaque charge de travail, définissez :

• Modèles familles et types de déploiement requis par le cas d’usage.
• Exigences en matière de traitement des données (par exemple, contraintes globales ou régionales).
• Cibles de débit et de latence pour les scénarios interactifs et par lots.
• Exigences en matière de quota et de capacité approvisionnée pour les charges d’état stable et de pointe.

Utilisez ces références :

• Modèles vendus directement par Azure
• Modèles de partenaires
• Quota dans Foundry
• Quotas et limites pour les modèles Foundry

Planifier la connectivité et l’intégration des données

Pour chaque charge de travail, identifiez les dépendances externes et les modèles de connexion :

• Sources de données et magasins de données.
• API internes et systèmes métier.
• Outils SaaS non Azure requis par les agents ou les flux d’orchestration.
• Exigences de mise en réseau, notamment les points de terminaison privés, la résolution DNS, les contrôles de sortie et si un réseau virtuel BYO ou un réseau managé est requis.

Utilisez Ajouter des connexions dans Foundry pour normaliser la configuration des connexions.

Les connexions peuvent être créées à la fois au niveau de la ressource Foundry parente et au niveau du projet enfant, selon le niveau d’isolation souhaité. Les connexions configurées au niveau parent sont disponibles pour tous les projets.

Planifier l’automatisation et les opérations

Définissez la façon dont les équipes créent et gèrent les ressources de manière cohérente entre les environnements.

• Utilisez l’infrastructure comme code pour approvisionner les ressources principales et les paramètres de stratégie par défaut.
• Normaliser les pipelines de déploiement pour les projets, les connexions, les déploiements de modèles et les modifications de configuration.
• Définissez les procédures de restauration et de réponse aux incidents pour les modifications de modèle et de stratégie.

Pour les modèles d’automatisation et les implémentations de démarrage, utilisez :

• Quickstart : Déployer une ressource Microsoft Foundry à l’aide d’un fichier Bicep
• Terraform sur Azure
• Exemples de configurations de sécurité

Les exemples de modèles incluent des modèles de bout en bout pour des scénarios de sécurité courants, tels que la mise en réseau privée, les clés gérées par le client et le contrôle d’accès en fonction du rôle.

Définir des garde-fous en libre-service

Autorisez le libre-service uniquement dans des limites clairement définies :

• Définissez les rôles qui peuvent créer des projets, déployer des modèles et connecter des outils externes.
• Appliquez des contrôles de stratégie pour le déploiement de modèles et le comportement d’exécution, y compris les fournisseurs de modèles et les connexions d’outils autorisées.
• Définissez les contrôles de coûts et les alertes budgétaires pour les environnements partagés et isolés.
• Appliquer la journalisation de traces au sein de l’observabilité centralisée dans Microsoft Foundry, Microsoft Copilot Studio et Microsoft 365.

Utilisez ces références :

• Stratégie de déploiement des modèles dans Foundry
• Gérer les coûts dans Foundry
• Intégration de l’agent 365

Attribuer la propriété et la gouvernance

Traitez cette étape comme la transition de l’infrastructure provisionnée à l’utilisation des développeurs opérationnels.

La plupart des organisations gèrent déjà l’accès via des groupes de Microsoft Entra ID précréés. Associez ces groupes aux rôles Foundry au niveau de portée requis, puis validez les modes d’accès pour la gestion et le développement.

Foundry sépare l’accès selon :

• Actions RBAC du plan de contrôle pour la gestion des ressources.
• Actions RBAC du plan de données pour les charges de travail de développement.

Pour obtenir des conseils de mappage de rôles et des combinaisons de rôles requises, consultez le contrôle d’accès en fonction du rôle dans Foundry.

Après avoir intégré vos groupes d’utilisateurs, envisagez d’établir ou de développer des tableaux de bord de gouvernance pour suivre l’utilisation de Foundry, la fiabilité, la traçabilité et la conformité :

• Surveillance des flottes dans Foundry
• Intégration de l’agent 365
• Microsoft Defender pour le Cloud
• Azure Policy

Exemple de déploiement de plateforme

L’organisation informatique de Contoso doit prendre en charge plusieurs équipes tout en équilibrant deux priorités :

• Innovation rapide, où les développeurs peuvent tester rigoureusement les dernières technologies IA à l’aide de données hors production.
• Environnements de développement/test et de production entièrement isolés pour les cas d’usage prouvés qui reçoivent du financement pour l’opérationnalisation.

Le diagramme montre comment Contoso colocalise une instance découverte partagée pour l’innovation, disponible pour toutes les équipes, avec une capacité limitée et des données et outils pré-connectés. L’exemple de backlog reflète les fonctions d’entreprise courantes telles que le support client, le support technique des employés, les opérations financières, l’approvisionnement et les ventes. Historiquement, seuls quelques cas d’usage progressent vers une faisabilité éprouvée ou un financement sécurisé pour un déploiement de développement/test. Parmi ceux-ci, un sous-ensemble encore plus restreint passe en production. L’exemple montre également deux cas d’usage commerciaux connexes qui restent colocalisés pendant les phases d’exploration et de développement/test, car ils partagent les mêmes données CRM, les mêmes personas utilisateurs et les mêmes systèmes connectés. À mesure que les cas d’usage arrivent à maturité, les équipes se voient attribuer des environnements avec une isolation progressivement plus forte, ce qui aboutit à une séparation complète de niveau production si nécessaire.

Pour en savoir plus

• Sécuriser l’environnement Foundry

  • Authentification et RBAC : contrôle d’accès en fonction du rôle dans Foundry
  • Mise en réseau : utiliser un réseau virtuel avec Foundry
  • Clés gérées par le client (CMK) : clés gérées par le client dans Foundry
  • Exemple d’infrastructure : référentiel de modèles avec des exemples de modèles d’infrastructure
  • Récupérer ou vider les ressources Foundry supprimées

• Établir une connectivité avec d’autres services Azure

  • Vue d’ensemble des connexions : Ajouter une nouvelle connexion dans Foundry

Étape suivante