L'équipe doit développer en Python la composante vocale de l'agent, capable d'écouter une commande orale d'un client et de lui répondre par synthèse vocale. Décrivez les classes et méthodes du SDK Azure Speech à utiliser pour (a) configurer la connexion au service, (b) effectuer la reconnaissance vocale ponctuelle d'une commande courte, et (c) sauvegarder la réponse synthétisée dans un fichier audio local nommé 'reponse.wav' avant diffusion téléphonique.

Pour (a) configurer la connexion, l'équipe doit instancier la classe SpeechConfig en lui passant la clé d'abonnement (subscription) et la région Azure (region). SpeechConfig est le point d'entrée central qui authentifie et oriente toutes les requêtes vers le bon endpoint du service Azure Speech. Pour (b) la reconnaissance vocale ponctuelle, un objet SpeechRecognizer est créé en lui passant le speech_config. La méthode à appeler est recognize_once() (ou recognize_once_async() pour une approche non bloquante). Cette méthode est conçue pour capturer un énoncé court (jusqu'à 15 secondes ou jusqu'au premier silence détecté), ce qui correspond parfaitement à des commandes clients brèves comme 'Je veux modifier ma réservation'. Pour (c) la synthèse vocale vers un fichier, l'équipe doit créer un objet AudioOutputConfig en spécifiant filename='reponse.wav'. Cet objet est ensuite passé au constructeur de SpeechSynthesizer via le paramètre audio_config. Lors de l'appel à speak_text() ou speak_ssml(), l'audio généré est directement écrit dans le fichier local spécifié, prêt à être injecté dans le flux téléphonique. Cette approche est distincte de la diffusion en temps réel vers le haut-parleur par défaut.

Le chef de projet propose de configurer l'agent IA pour qu'il adopte le rôle d'un assistant nommé 'AirBot', courtois, spécialisé uniquement dans les demandes liées aux vols AirConnect, et incapable de répondre à des sujets hors périmètre. Quel mécanisme de Microsoft Foundry doit être utilisé pour imposer ce comportement, et pourquoi les prompts système ne peuvent-ils pas être utilisés pour contrôler les autorisations d'accès à l'agent ?

Pour définir le rôle, la persona et les contraintes comportementales d'AirBot, l'équipe doit configurer les instructions système (system prompt) de l'agent dans Microsoft Foundry. Ces instructions constituent le guide fondateur de l'agent : elles précisent son nom, son ton (courtois), son domaine de compétence exclusif (vols AirConnect), et ses limites opérationnelles (refus de toute question hors périmètre). Par exemple : 'Tu es AirBot, assistant virtuel d'AirConnect. Tu réponds uniquement aux questions relatives aux vols, réservations et bagages AirConnect. Pour toute autre demande, tu informes poliment l'utilisateur que tu ne peux pas aider sur ce sujet.' En revanche, les prompts système ne peuvent absolument pas être utilisés pour gérer les autorisations d'accès. L'autorisation est un mécanisme de sécurité relevant de la gestion des identités et des accès (IAM), implémenté via le code applicatif, les passerelles API, les tokens OAuth ou Azure Active Directory. Un prompt système n'est qu'un texte fourni en entrée à un modèle de langage : il ne dispose d'aucune capacité cryptographique, ne peut pas vérifier l'identité d'un appelant, ni bloquer réellement l'accès à des ressources. Un utilisateur malveillant pourrait tenter de le contourner par injection de prompt. La sécurité des accès doit donc être gérée en dehors du modèle, au niveau de l'infrastructure.

Un client soumet un fichier PDF numérisé contenant son billet d'avion afin de demander un remboursement. L'application doit extraire automatiquement des champs structurés : numéro de billet, date de vol, montant payé et nom du passager. Décrivez la solution technique à mettre en œuvre avec Azure Content Understanding dans Foundry Tools, en précisant : le type d'analyseur à utiliser, le rôle du schéma, et la séquence de code Python pour soumettre le document et récupérer les résultats.

Pour traiter un billet d'avion au format PDF numérisé, l'équipe doit utiliser l'analyseur de document (document analyzer) d'Azure Content Understanding. Cet analyseur combine la reconnaissance optique de caractères (OCR) pour lire le texte imprimé sur le PDF numérisé, et des modèles de langage avancés pour comprendre la structure sémantique du document commercial. Le schéma joue un rôle central : c'est la structure de métadonnées dans laquelle l'équipe déclare les champs à extraire (numéro de billet, date de vol, montant payé, nom du passager), leurs types de données (string, date, float, string) et éventuellement des contraintes de validation. Sans schéma défini, l'analyseur ne sait pas quelles informations cibler dans le document. Côté code Python, la séquence est la suivante : 1. Instancier le client Azure Content Understanding avec les credentials du projet Foundry. 2. Appeler client.begin_analyze(analyzer_id='invoice', input_url=url_du_pdf) — ou passer les données binaires directement. Cette méthode est asynchrone : elle retourne immédiatement un objet LROPoller (Long-Running Operation Poller) avec un statut InProgress, sans bloquer. 3. Appeler poller.result() pour bloquer l'exécution jusqu'à la fin du traitement et récupérer l'objet de résultats structurés contenant les valeurs extraites pour chaque champ du schéma. Cette approche asynchrone est nécessaire car l'analyse de PDF volumineux peut prendre plusieurs secondes, et le modèle de poller évite de saturer l'API avec des requêtes répétées.

Pour analyser les 9 500 e-mails hebdomadaires, l'équipe doit identifier automatiquement les mentions de noms de clients, de références de magasins et d'organisations tierces (transporteurs, fournisseurs). Quelle technique d'analyse de texte spécifique doit être utilisée, et en quoi est-elle différente des autres approches comme l'analyse de sentiments ou le résumé automatique ?

La technique à utiliser est la Reconnaissance d'Entités Nommées, ou NER (Named Entity Recognition). La NER est spécifiquement conçue pour identifier et catégoriser des entités nommées dans un texte non structuré selon des classes prédéfinies : personnes (noms de clients), organisations (transporteurs, fournisseurs), lieux (références de magasins), et d'autres catégories selon le modèle utilisé. C'est exactement ce dont RetailMax a besoin pour structurer le contenu de ses e-mails. La NER se distingue clairement des autres approches : - L'analyse de sentiments évalue la polarité émotionnelle d'un texte (positif, négatif, neutre, mixte) : elle dirait si un e-mail exprime de la frustration, mais ne localisera pas le nom du magasin concerné. - Le résumé automatique condense un texte long en version courte en préservant le sens global : utile pour un rapport, mais sans extraction de champs structurés. - La classification texte prédit une catégorie parmi des labels prédéfinis : elle nécessite des exemples étiquetés et ne fait pas d'extraction d'entités. La NER produit une sortie structurée (entité, type, position dans le texte) directement exploitable pour alimenter une base de données CRM ou déclencher des workflows automatisés, ce qui correspond à l'objectif de RetailMax.

Les 3 200 messages vocaux hebdomadaires sont stockés sous forme de fichiers WAV dans Azure Blob Storage. L'équipe doit générer des transcriptions textuelles de l'ensemble de ces fichiers de manière économique et efficace. Quelle fonctionnalité d'Azure Speech doit être utilisée, et quel type d'analyseur Azure Content Understanding est adapté si l'on souhaite en plus extraire des informations structurées (motif d'appel, numéro de commande mentionné) à partir de ces enregistrements ?

Pour transcrire en masse les 3 200 fichiers WAV hebdomadaires stockés dans Azure Blob Storage, la fonctionnalité adaptée est la transcription par lots (batch transcription) du service Azure Speech. Contrairement à la reconnaissance vocale en temps réel (SpeechRecognizer.recognize_once()) qui traite un flux audio en direct, la transcription par lots est conçue spécifiquement pour traiter de grands volumes de fichiers audio pré-enregistrés de manière asynchrone et efficace. Elle peut traiter plusieurs fichiers en parallèle, ce qui est crucial pour absorber 3 200 fichiers par semaine sans latence excessive. Pour aller plus loin et extraire des informations structurées (motif d'appel, numéro de commande mentionné dans la conversation), l'équipe doit utiliser l'analyseur audio d'Azure Content Understanding dans Foundry Tools. L'analyseur audio est spécifiquement conçu pour traiter des fichiers audio au format WAV ou MP3 : il assure d'abord la transcription via la fonctionnalité de transcription intégrée, puis applique un schéma défini pour identifier et extraire des entités spécifiques (numéro de commande, type de problème signalé, sentiment général). Il ne faut pas confondre avec l'analyseur de document (prévu pour PDF/images) ou l'analyseur vidéo (prévu pour des flux vidéo avec composante visuelle). L'analyseur audio est le seul type nativement adapté aux entrées acoustiques de type messagerie vocale.

Le management souhaite regrouper automatiquement les tickets de support par thème émergent sans définir de catégories à l'avance, et l'équipe RGPD impose de chiffrer toutes les données clients et de restreindre l'accès aux personnels autorisés. (a) Quelle approche de machine learning est appropriée pour le regroupement thématique, et pourquoi la classification supervisée est-elle inadaptée ici ? (b) À quel principe d'IA responsable de Microsoft correspond l'exigence RGPD de chiffrement et de contrôle d'accès ?

(a) L'approche appropriée pour regrouper les tickets sans catégories prédéfinies est le clustering, une technique d'apprentissage non supervisé. Le clustering analyse les similarités entre les tickets (termes récurrents, patterns sémantiques) et les regroupe automatiquement en clusters thématiques cohérents — par exemple : 'problèmes de livraison', 'remboursements', 'qualité produit' — sans que l'équipe n'ait eu à étiqueter d'exemples au préalable. C'est précisément ce qu'il faut pour découvrir des thèmes émergents inconnus. La classification supervisée est inadaptée pour plusieurs raisons : elle nécessite un jeu de données d'entraînement avec des étiquettes prédéfinies (ce que RetailMax ne possède pas pour les nouveaux thèmes), elle ne peut prédire que des catégories connues à l'avance, et elle serait incapable de détecter un thème nouveau jamais vu lors de l'entraînement. Le clustering, au contraire, s'adapte naturellement à l'évolution des motifs de contact. (b) L'exigence de chiffrement des données sensibles clients et de restriction d'accès aux personnels autorisés correspond au principe de Confidentialité et Sécurité (Privacy and Security) de l'IA responsable Microsoft. Ce principe impose que les systèmes IA respectent les lois sur la protection des données (dont le RGPD), en mettant en œuvre le chiffrement des données au repos et en transit, et en configurant le contrôle d'accès basé sur les rôles (RBAC) pour restreindre l'accès aux données personnelles. Il ne s'agit pas du principe d'Équité (qui traite des biais), ni de Transparence (qui concerne la compréhensibilité pour l'utilisateur).

L'équipe doit configurer un agent IA dans Microsoft Foundry pour qu'il génère des descriptions produits dans un style éditorial précis : ton enthousiaste mais sobre, vocabulaire mode, longueur limitée à 120 mots, sans mentionner les prix ni les concurrents. Par ailleurs, pour contrôler les coûts d'API et respecter la contrainte de longueur, quel paramètre de déploiement doit être configuré ? Expliquez le rôle de chacun des deux mécanismes.

Pour imposer le style éditorial précis à l'agent, l'équipe doit configurer les instructions système (system prompt) dans Microsoft Foundry. Ces instructions constituent le guide comportemental fondateur de l'agent : elles définissent son rôle ('Tu es un rédacteur mode expert pour FashionHub'), son ton ('enthousiaste mais sobre'), son vocabulaire, ses contraintes de contenu ('Ne mentionne jamais les prix ni les noms de concurrents') et ses limites de format ('Rédige en 120 mots maximum'). À chaque requête, ces instructions précèdent le prompt utilisateur et cadrent systématiquement le comportement du modèle. Pour contrôler la longueur des réponses et maîtriser les coûts d'API, le paramètre à configurer est Max Completion Tokens. Ce paramètre plafonne le nombre maximum de tokens (mots ou sous-mots) que le modèle peut générer dans une réponse. En le fixant à une valeur cohérente avec 120 mots (environ 150-160 tokens selon la langue), l'équipe s'assure que les descriptions ne dépassent pas la cible. Ce mécanisme agit directement sur les coûts car la facturation Azure OpenAI est proportionnelle au nombre de tokens générés : moins de tokens produits signifie moins de coûts par requête, ce qui est crucial pour traiter 85 000 fiches produits. Les deux mécanismes sont complémentaires : les instructions système définissent le 'quoi écrire', tandis que Max Completion Tokens définit le 'combien écrire au maximum'.

FashionHub souhaite que son modèle déployé dans Foundry analyse des photos produits fournies par les marques (ex. : identifier la couleur dominante, le type de vêtement, les détails notables) et les intègre dans la génération de fiches produits. Décrivez comment structurer en Python une requête multimodale combinant une question textuelle et une image JPEG locale, en précisant les valeurs des champs 'type' et le format à utiliser pour transmettre l'image en données binaires.

Pour envoyer une requête multimodale combinant texte et image JPEG locale à un modèle avec capacité vision dans Foundry, l'équipe doit utiliser l'API Responses d'OpenAI avec une structure de message contenant deux blocs de contenu dans le tableau 'content'. Le premier bloc, pour la question textuelle, doit avoir le champ 'type' valorisé à 'input_text', accompagné du champ 'text' contenant la question (ex. : 'Décris les caractéristiques visuelles de ce vêtement : couleur, matière apparente, style.'). Le second bloc, pour l'image, doit avoir le champ 'type' valorisé à 'input_image', accompagné du champ 'image_url'. Puisque l'image est locale et doit être transmise en données binaires (et non via une URL publique), la valeur de 'image_url.url' doit être construite au format Data URI base64 : 'data:image/jpeg;base64,' suivi des données binaires de l'image encodées en base64. L'encodage base64 permet d'intégrer les données binaires directement dans la charge utile JSON de la requête, via un protocole texte RESTful, sans nécessiter d'héberger l'image sur un serveur public accessible. Les deux blocs sont inclus dans un seul message utilisateur (role: 'user'), ce qui minimise la latence en réduisant le nombre d'allers-retours API. Il est important de ne pas confondre 'input_image' (type de bloc multimodal) avec 'input_url' qui n'est pas un type de bloc valide dans cette API.

Avant de choisir le modèle LLM à déployer en production, l'équipe veut comparer les coûts opérationnels de plusieurs modèles disponibles dans Foundry. Quel outil du portail Microsoft Foundry doit être utilisé pour cette comparaison ? Par ailleurs, pour réduire le risque que le modèle génère des descriptions produits inventées non conformes aux spécifications réelles (hallucinations), quelle approche générale doit être adoptée, et quel pattern d'architecture IA la met en œuvre ?

Pour comparer les coûts opérationnels des différents LLMs disponibles avant déploiement, l'équipe doit utiliser le Classement des modèles (Model Leaderboard) dans le portail Microsoft Foundry. Cet outil fournit une analyse comparative côte à côte des modèles disponibles dans le catalogue, incluant leurs métriques de performance (qualité, vitesse d'inférence) et leurs coûts opérationnels (prix par million de tokens en entrée/sortie). Il permet d'identifier rapidement le modèle offrant le meilleur équilibre coût/performance pour le cas d'usage spécifique de FashionHub, sans avoir à déployer et tester chaque modèle individuellement. Pour réduire les hallucinations et garantir que les descriptions générées restent conformes aux spécifications réelles des produits, l'approche à adopter est l'ancrage du modèle avec des données pertinentes (grounding). Cette approche consiste à fournir au modèle, dans chaque requête, les données factuelles réelles du produit en question (matière, dimensions, couleurs disponibles, détails techniques issus de la fiche fournisseur) comme contexte de référence. Le modèle génère alors sa description en s'appuyant sur ces données plutôt qu'en les inventant. Le pattern d'architecture qui met en œuvre cette approche est la Génération Augmentée par Récupération, ou RAG (Retrieval-Augmented Generation). Dans ce pattern, un système de recherche récupère dynamiquement les données produits pertinentes depuis une base de connaissances, et les injecte dans le prompt avant génération, ancrant ainsi la sortie du modèle dans des faits vérifiables.

L'audit révèle que le modèle de scoring crédit produit des taux de refus significativement différents selon l'origine géographique des demandeurs, sans que cette variable ne soit explicitement incluse dans les features. (a) À quel principe d'IA responsable de Microsoft ce problème est-il directement lié, et en quoi ce principe diffère-t-il de l'idée reçue selon laquelle 'l'équité signifie que tous les utilisateurs reçoivent la même réponse' ? (b) Quelle action corrective illustre concrètement ce principe ?

(a) Ce problème est directement lié au principe d'Équité (Fairness) de l'IA responsable Microsoft. Ce principe exige que les systèmes IA traitent tous les groupes de personnes de manière équitable, sans discriminer sur la base de caractéristiques démographiques telles que l'origine, le genre, l'âge ou l'ethnie — même lorsque ces variables ne sont pas explicitement présentes dans le modèle (biais indirect via des variables proxy comme le code postal). Il est crucial de distinguer équité et uniformité : l'équité ne signifie pas que tous les utilisateurs reçoivent toujours la même décision ou le même score. Un client présentant un excellent historique de remboursement doit légitimement obtenir une décision différente d'un client avec des incidents de paiement répétés — cette différence est fondée sur des caractéristiques valides et pertinentes pour l'évaluation du risque. L'équité signifie que deux individus aux profils financiers objectivement identiques ne doivent pas recevoir des décisions différentes en raison de leur appartenance à un groupe démographique. L'objectif est l'absence de discrimination, pas l'uniformité des sorties. (b) L'action corrective illustrant ce principe est l'évaluation systématique des sorties du modèle en les segmentant par groupes démographiques (analyse des taux de refus par origine géographique, par tranche d'âge, par genre) afin d'identifier et d'éliminer proactivement les biais algorithmiques. Cette démarche peut inclure la révision des features d'entraînement, le rééquilibrage du jeu de données, ou l'ajout de contraintes d'équité dans la fonction objectif du modèle.

Le comité de conformité constate que lorsqu'un client se voit refuser un prêt immobilier par le système IA, il ne reçoit aucune explication sur les critères ayant conduit à cette décision. Par ailleurs, certains clients ne savent pas qu'ils interagissent avec un chatbot IA et non un conseiller humain. (a) À quel principe d'IA responsable de Microsoft ces deux lacunes sont-elles liées ? (b) Quelles mesures concrètes doivent être mises en place pour y remédier ?

(a) Ces deux lacunes sont liées au principe de Transparence de l'IA responsable Microsoft. Ce principe vise à rendre les systèmes IA compréhensibles et clairs pour les personnes qui interagissent avec eux. Il exige : de fournir des explications sur la manière dont les modèles prennent leurs décisions, de clarifier les données utilisées pour l'entraînement, de communiquer les limites opérationnelles du système, et — point essentiel — d'informer les utilisateurs lorsqu'ils interagissent avec un système IA plutôt qu'avec un être humain. Ne pas informer le client qu'il parle à un chatbot constitue une violation directe de ce principe. (b) Les mesures concrètes à mettre en place sont : Premièrement, pour les refus de crédit : implémenter un mécanisme d'explicabilité (par exemple des scores de contribution des features) permettant de générer une lettre de refus compréhensible mentionnant les principaux facteurs ayant influencé la décision (ex. : 'taux d'endettement supérieur au seuil, durée d'emploi insuffisante'), sans révéler les paramètres internes du modèle. Deuxièmement, pour le chatbot : afficher dès la première interaction un message clair indiquant que le client dialogue avec un assistant IA ('Bonjour, je suis l'assistant virtuel de BanqueNord, un système d'intelligence artificielle'), en précisant ses capacités et ses limites (ex. : 'Pour des conseils personnalisés complexes, je peux vous mettre en relation avec un conseiller humain'). Troisièmement, publier une documentation accessible expliquant globalement le fonctionnement, les données utilisées et les limites des systèmes IA de BanqueNord.

Le responsable informatique propose de cesser toute surveillance des trois systèmes IA après leur mise en production, arguant que 'le modèle a été validé avant déploiement, donc il est fiable'. L'équipe d'audit souhaite également mettre en place une règle selon laquelle toutes les décisions de refus de crédit supérieures à 150 000 € doivent être revues par un analyste humain avant notification au client. À quel(s) principe(s) d'IA responsable de Microsoft ces deux sujets correspondent-ils respectivement, et quels arguments l'audit doit-il avancer ?

Premier sujet — La surveillance continue après déploiement : La proposition de cesser toute surveillance est contraire au principe de Fiabilité et Sécurité (Reliability and Safety) de l'IA responsable Microsoft. Ce principe exige que les systèmes IA fonctionnent de manière cohérente et prévisible, non seulement dans des conditions standard, mais aussi dans des scénarios limites ou inattendus. L'argument central de l'audit est que la validation pré-déploiement est nécessaire mais insuffisante. Au fil du temps, les modèles souffrent de dérive des données (data drift) : les comportements financiers des emprunteurs évoluent, les conditions économiques changent, les patterns de fraude se transforment. Un modèle validé en 2023 peut produire des résultats dégradés ou biaisés en 2025 sans surveillance active. Une surveillance continue est indispensable pour détecter les baisses de performance, les nouveaux biais émergents, et les comportements inattendus avant qu'ils ne causent des préjudices réels aux clients ou des risques réglementaires à BanqueNord. Le déploiement en production marque le début d'un cycle de maintenance, pas sa fin. Second sujet — La revue humaine des décisions à fort impact : La règle proposée illustre le principe de Responsabilité (Accountability) de l'IA responsable Microsoft. Ce principe établit que les personnes et organisations qui conçoivent, déploient et exploitent des systèmes IA doivent demeurer en dernier ressort responsables de leurs décisions. La mise en place d'une supervision 'human-in-the-loop' — où un analyste humain revoit et valide les décisions IA à fort impact financier avant notification — est précisément la concrétisation opérationnelle de ce principe. Elle garantit qu'aucune décision automatisée irréversible et significative n'est prise sans engagement humain, préservant ainsi la responsabilité légale et éthique de l'établissement.

Le GHM reçoit deux catégories principales de documents à automatiser : (a) des formulaires de prise en charge assurance au format PDF numérisé, depuis lesquels il faut extraire des champs précis (numéro de sécurité sociale, code acte médical, montant remboursé), et (b) des comptes-rendus médicaux dictés par les médecins, stockés sous forme de fichiers MP3. Pour chaque catégorie, identifiez le type d'analyseur Azure Content Understanding adapté et justifiez votre choix.

(a) Pour les formulaires de prise en charge assurance au format PDF numérisé, l'analyseur adapté est l'analyseur de document (document analyzer). Ces formulaires sont des documents structurés ou semi-structurés contenant du texte imprimé ou manuscrit sur support papier numérisé. L'analyseur de document combine la Reconnaissance Optique de Caractères (OCR) pour extraire le texte des images numérisées, et des modèles de langage avancés pour comprendre la structure sémantique du formulaire. En définissant un schéma précis déclarant les champs attendus (numéro de sécurité sociale de type string avec format spécifique, code acte de type string, montant de type float), l'analyseur extrait directement les valeurs structurées sans nécessiter de saisie manuelle. L'analyseur audio ou vidéo serait totalement inadapté à ce type d'entrée documentaire. (b) Pour les comptes-rendus médicaux dictés au format MP3, l'analyseur adapté est l'analyseur audio (audio analyzer). Les fichiers MP3 sont des enregistrements acoustiques de voix parlée. L'analyseur audio est le seul framework nativement conçu pour traiter des formats audio : il effectue d'abord la transcription (conversion de la parole en texte via la fonctionnalité de transcription d'Azure Content Understanding), puis peut extraire des entités structurées selon un schéma (type d'acte médical, médicaments prescrits, diagnostic). L'analyseur de document ne peut pas traiter des entrées audio ; il est réservé aux supports visuels textuels. Azure Content Understanding est donc une solution multimodale capable de traiter ces deux modalités d'entrée distinctes au sein d'une même plateforme Foundry.

Un développeur du GHM doit implémenter en Python la soumission asynchrone d'un formulaire PDF à Azure Content Understanding et la récupération des résultats. Expliquez pourquoi l'analyse est asynchrone, décrivez la séquence de code à implémenter, et précisez le rôle de l'objet retourné par begin_analyze().

L'analyse est asynchrone car le traitement d'un document (OCR, inférence du modèle de langage, extraction structurée) peut prendre plusieurs secondes à plusieurs dizaines de secondes selon la taille et la complexité du PDF. Un appel synchrone bloquerait le thread de l'application pendant toute cette durée, ce qui est inacceptable dans un contexte de traitement en volume (22 000 documents par mois). Le modèle asynchrone permet à l'application de continuer à fonctionner et de vérifier périodiquement l'état du traitement. La séquence d'implémentation Python est la suivante : 1. Instancier le client Azure Content Understanding avec les credentials Foundry (endpoint et clé API récupérés idéalement depuis Azure Key Vault, jamais en dur dans le code). 2. Appeler poller = client.begin_analyze(analyzer_id='formulaire-assurance', input_url=url_du_pdf). Cette méthode déclenche l'opération de traitement sur le service cloud et retourne immédiatement sans attendre la fin de l'analyse. 3. L'objet retourné est un LROPoller (Long-Running Operation Poller). Il encapsule un token de suivi et permet d'interroger l'état de l'opération. Son statut initial est 'InProgress'. 4. Appeler result = poller.result() pour bloquer l'exécution jusqu'à la fin du traitement. Cette méthode interroge en interne l'endpoint de statut jusqu'à obtenir une réponse terminale ('Succeeded' ou 'Failed'), puis retourne l'objet de résultats contenant les champs extraits selon le schéma défini. 5. Accéder aux valeurs extraites depuis l'objet result (ex. : result.fields['numero_securite_sociale'].value). Cette approche avec begin_analyze() + poller.result() est préférable à une boucle de polling manuel car elle abstrait la logique de retry et de gestion des délais.

L'équipe projet doit sécuriser les clés API et secrets utilisés par l'application, et concevoir l'interface de reconnaissance vocale en temps réel pour les agents, en tenant compte des agents présentant des difficultés de lecture (dyslexie, troubles visuels). (a) Quelle pratique de sécurité doit être appliquée pour protéger les secrets, et quel outil Azure est recommandé ? (b) À quel principe d'IA responsable de Microsoft correspond la prise en compte des agents avec difficultés de lecture, et comment ce principe se manifeste-t-il concrètement dans la conception de l'interface ?

(a) La pratique de sécurité à appliquer est de ne jamais stocker les clés API, chaînes de connexion ou tokens d'authentification en clair dans le code source, les fichiers de configuration versionnés ou les variables d'environnement non protégées. L'outil Azure recommandé est Azure Key Vault, un service de gestion sécurisée des secrets. Les clés API du service Azure Speech, les credentials Azure Content Understanding et les tokens Azure OpenAI doivent être stockés dans Key Vault et accessibles par l'application via des mécanismes contrôlés (identité managée, RBAC). Cette pratique protège les secrets contre les fuites accidentelles (commit Git public, logs d'application) et permet de renouveler les clés sans modifier le code applicatif. Elle s'inscrit également dans le principe d'IA responsable de Confidentialité et Sécurité, qui exige la protection des données sensibles et la restriction d'accès aux personnels autorisés — exigence critique dans un contexte HDS. (b) La prise en compte des agents présentant des difficultés de lecture (dyslexie, troubles visuels) correspond au principe d'Inclusivité de l'IA responsable Microsoft. Ce principe vise à garantir que les systèmes IA sont accessibles et efficaces pour tous les utilisateurs, quelles que soient leurs capacités. Il ne s'agit pas d'un principe de sécurité ni d'équité (qui traite des biais démographiques), mais bien d'accessibilité universelle. Concrètement, ce principe se manifeste dans la conception de l'interface de la manière suivante : l'interface de reconnaissance vocale en temps réel est elle-même un vecteur d'inclusivité en permettant aux agents de requêter oralement le système sans dépendre de la lecture. En complément, l'interface doit proposer une synthèse vocale (text-to-speech) pour lire les résultats à voix haute, des polices de grande taille et à fort contraste, un mode de navigation entièrement à la voix pour les agents avec troubles visuels sévères, et une compatibilité avec les lecteurs d'écran. Ces adaptations permettent à tous les agents d'utiliser le système avec la même efficacité, indépendamment de leurs capacités individuelles.