Préparer votre environnement Microsoft à l’IA d’entreprise

Le premier projet d’IA d’entreprise d’une organisation est généralement décrit, après coup, comme ayant « rencontré des problèmes inattendus ». Ces problèmes n’avaient rien d’inattendu pour quiconque avait examiné le tenant. C’étaient les dettes existantes du parc — identité, données, réseau, gouvernance — et le projet d’IA était simplement la première charge de travail incapable de les contourner.

Un assistant de connaissances qui ne doit répondre qu’à partir des documents que le demandeur a le droit de lire constitue un test très direct de la fidélité de votre modèle de permissions à la réalité. Il s’avère que beaucoup ne la reflètent pas.

Voici la préparation qui fait la différence, dans l’ordre où elle tend à compter.

Identité : celle du demandeur doit voyager

Tout le reste en dépend. Une application d’IA sur des données Microsoft doit savoir qui pose la question, et cette identité doit circuler jusqu’à la recherche — pour que ce qui remonte soit ce que cette personne, et elle seule, est autorisée à lire.

Concrètement, l’application authentifie ses utilisateurs via Entra ID et agit en leur nom auprès des sources de données, plutôt qu’avec une identité puissante qui lui serait propre. Des permissions déléguées, non applicatives, partout où la source le permet. Le raccourci commode — un principal de service capable de tout lire, l’application décidant ensuite de ce qu’elle affiche — déplace tout le modèle de contrôle d’accès dans votre code, où il sera faux.

L’identité propre de l’application doit être une identité managée : aucun secret client à stocker, renouveler ou perdre. Et l’application d’IA est elle-même une cible de connexion : elle relève des accès conditionnels comme n’importe quelle autre, sans exemption au motif de sa nouveauté.

Données : votre modèle de partage est votre modèle de recherche

Les systèmes à génération augmentée héritent des permissions du contenu qu’ils indexent. Si le partage sous-jacent est erroné, l’assistant reproduit fidèlement l’erreur, à la vitesse d’une conversation, à quiconque pose la bonne question.

Deux problèmes apparaissent immédiatement. Le sur-partage — des sites SharePoint où « Tout le monde sauf les utilisateurs externes » était le choix facile il y a des années, si bien que des documents techniquement ouverts à toute l’entreprise mais pratiquement introuvables deviennent instantanément trouvables. Et les permissions obsolètes — des groupes qui reflètent d’anciens postes.

Avant d’indexer quoi que ce soit, sachez ce qui est sur-partagé et décidez de ce qu’il faut corriger. Les étiquettes de confidentialité Purview offrent un second levier : étiquetez ce qui est confidentiel, puis décidez par étiquette ce que l’IA a le droit d’indexer. Certains contenus ne doivent jamais être accessibles à un assistant généraliste, quel que soit le demandeur, et l’étiquette est l’endroit honnête pour le consigner.

La résidence des données relève du même chapitre. Sachez dans quelles régions vos données peuvent être traitées avant de choisir où s’exécute le modèle, pas après.

Réseau : la même landing zone, pas une zone à part

Les charges de travail d’IA ont tendance à être déployées hors des schémas habituels de la plateforme — parce qu’il s’agissait d’un pilote, d’une autre équipe, ou d’une urgence.

Résistez. Azure OpenAI, AI Search et le stockage qui les alimente relèvent du même modèle de landing zone que tout le reste : points de terminaison privés, aucun accès réseau public, trafic via le hub, résolution DNS privée. Un point de terminaison de modèle doté d’une adresse publique et d’une clé est exactement le type de ressource que la revue de sécurité finit par trouver.

La difficulté pratique tient à la disponibilité régionale. Les déploiements de modèles et les quotas sont définis par région et évoluent, et la région que privilégie votre landing zone n’offre pas nécessairement le modèle voulu dans la capacité requise. Découvrez-le pendant la conception, pas la semaine prévue pour la mise en production.

Gouvernance : décider qui peut construire quoi

Sans décision de gouvernance, l’adoption de l’IA dans un parc Microsoft emprunte le chemin qui compte le moins de contrôles — généralement une souscription personnelle, l’inscription d’application d’un développeur et un outil SaaS passé en note de frais.

Trois décisions préviennent l’essentiel :

• Une politique d’IA responsable assez courte pour être lue. Quels cas d’usage sont permis, quelles données peuvent être utilisées, ce qui exige une revue. Deux pages que les ingénieurs consultent réellement valent mieux que quarante approuvées par le juridique.
• Un responsable nommé par assistant. Chaque application d’IA déployée a une personne redevable de son comportement, de ses permissions et de son coût — la même discipline que pour toute application manipulant des données de l’entreprise.
• Un chemin pour dire oui rapidement. Si la voie approuvée prend six semaines, la voie non approuvée l’emporte. Une gouvernance qui fonctionne est surtout une voie rapide dotée de garde-fous.

Ajoutez-y une réalité opérationnelle : les versions de modèles sont retirées selon un calendrier. Un assistant construit sur une version précise est une dépendance qui expirera, et le parc a besoin d’un processus de cycle de vie qui met à niveau et réévalue avant cette échéance, pas après.

Les contrôles de sécurité propres à l’IA

Les contrôles ci-dessus sont ceux de la plateforme, appliqués avec constance. Quelques-uns sont réellement nouveaux.

Le filtrage de contenu sur les points de terminaison de modèles, configuré délibérément plutôt que laissé à des valeurs par défaut jamais lues. La journalisation des prompts et des réponses à des fins d’investigation, conçue avec l’équipe en charge de la protection des données, car ces journaux contiennent ce que vos collaborateurs ont demandé. Et l’injection de prompt indirecte — un contenu de votre index qui se lit comme une instruction — bornée dans un système de simple recherche, et nettement moins bornée dès que l’assistant dispose d’outils. L’article sur le RAG et les agents explique pourquoi cela change l’identité sous laquelle un outil s’exécute.

Coûts : instrumenter la requête, pas la ressource

L’unité de dépense de l’IA est la requête, et l’étiquetage au niveau des ressources sur lequel repose votre pratique FinOps ne voit pas à l’intérieur. Dès le premier déploiement, journalisez par requête : quel cas d’usage, quel modèle, combien de tokens en entrée et en sortie, combien d’appels. C’est la différence entre pouvoir énoncer un coût par conversation et n’avoir qu’un total mensuel sur lequel personne ne peut agir. L’article sur le FinOps de l’IA explique pourquoi l’urgence vient avec l’adoption, et non avant.

Évaluation : savoir ce que « fonctionner » veut dire avant de commencer

Un assistant qui répond de façon plausible n’est pas un assistant qui répond juste, et l’écart entre les deux est invisible sans mesure.

Avant toute mise à disposition, constituez un ensemble de questions réelles aux réponses connues, avec les sources dont elles doivent provenir. Confrontez-y chaque modification. Mesurez la recherche séparément de la génération : lorsque la qualité baisse, la cause est le plus souvent que le bon passage n’a jamais été trouvé — et retoucher le prompt n’y changera rien.

C’est aussi ce qui permet de réduire les coûts en confiance : la configuration la moins chère est acceptable si le jeu d’évaluation le confirme, et un pari dans le cas contraire.

Les personnes : le modèle d’exploitation fait partie de l’environnement

Quelqu’un doit répondre de la qualité de la recherche quand l’index dérive. Quelqu’un doit répondre à la finance sur le coût par conversation. Quelqu’un doit décider si la nouvelle version du modèle se comporte correctement avant le retrait de l’ancienne.

Aucun de ces rôles n’existe dans la plupart des organisations. Ce ne sont pas non plus des postes à temps plein, du moins au départ. Mais ils doivent porter des noms avant le lancement, car le moment où l’on en a besoin est précisément celui où personne n’a le temps de chercher à qui cela incombait.

Une liste de préparation

À peu près dans l’ordre où les traiter :

1. Les utilisateurs se connectent via Entra ID et l’application agit en leur nom ; l’application elle-même utilise une identité managée
2. Le sur-partage dans SharePoint et M365 est identifié et corrigé ; les étiquettes de confidentialité sont appliquées à ce qui ne doit jamais être indexé
3. Les ressources d’IA sont déployées dans la landing zone, avec points de terminaison privés et sans accès public ; la disponibilité régionale des modèles est confirmée
4. Une politique d’IA responsable courte, un responsable nommé par assistant et un chemin d’approbation rapide
5. Le filtrage de contenu est configuré et la journalisation des prompts et réponses validée avec la protection des données
6. Une télémétrie par requête — cas d’usage, modèle, tokens, appels — dès le premier jour
7. Un jeu d’évaluation aux réponses connues, exécuté à chaque modification
8. Des responsables nommés pour la qualité de la recherche, les coûts et le cycle de vie des modèles

L’environnement est le projet

Rien de tout cela n’est spectaculaire, et presque rien ne concerne un modèle. C’est justement le propos. Les organisations dont les programmes d’IA atteignent la production ne sont pas celles qui ont les meilleurs prompts. Ce sont celles dont le modèle d’identité était honnête, dont les données étaient partagées comme prévu, dont les schémas de plateforme ont tenu pour la nouvelle charge de travail, et dont la gouvernance a su dire oui rapidement aux bonnes choses.

Préparez l’environnement et le travail d’IA devient un projet applicatif. Sautez cette étape et il devient un audit imprévu de tout ce qui se trouve en dessous — mené en public, avec une échéance.