Niveau Débutant — Fondamentaux IA sur Azure
4 modules pour comprendre les concepts IA/ML/GenAI, l’IA responsable et les services Azure AI (Vision, Language, Speech, Document Intelligence).
Module 1 : Concepts IA, Machine Learning, IA générative et IA responsable
1.1 Intelligence artificielle, Machine Learning et Deep Learning
L’intelligence artificielle (IA) désigne tout système simulant des capacités humaines : comprendre le langage, reconnaître des images, prendre des décisions. Le Machine Learning (ML) est un sous-ensemble de l’IA où le système apprend des motifs depuis des données au lieu d’être programmé par règles explicites. Le Deep Learning est un sous-ensemble du ML fondé sur des réseaux de neurones profonds, particulièrement efficace pour la vision, la parole et le langage.
- Apprentissage supervisé — le modèle apprend depuis des exemples étiquetés (ex. classifier un e-mail en « spam » ou « légitime »).
- Apprentissage non supervisé — le modèle découvre des structures sans étiquettes (ex. regrouper des clients similaires).
- Apprentissage par renforcement — le modèle apprend par récompenses et pénalités (ex. optimiser un routage).
- Inférence vs entraînement — l’entraînement ajuste les poids du modèle ; l’inférence applique le modèle entraîné à de nouvelles données. À l’examen AI-102, vous déployez et consommez des modèles déjà entraînés.
Pourquoi c'est important : un client vous demande de classifier 50 000 e-mails par jour. Si vous proposez un LLM géant alors qu'un classifieur supervisé suffit, vous multipliez les coûts par cent et la latence par dix. À l'inverse, si vous proposez un modèle à règles pour résumer des rapports, il échouera dès que la formulation change. L'examen AI-102 vérifie exactement ce réflexe : associer chaque besoin au bon type d'apprentissage et savoir quand le génératif se justifie.
L'analogie qui aide : pensez à un apprenti. L'apprentissage supervisé, c'est l'apprenti à qui on montre 1 000 photos étiquetées « spam » ou « légitime » jusqu'à ce qu'il devine seul. Le non supervisé, c'est le même apprenti rangé dans un entrepôt sans étiquettes : il regroupe ce qui se ressemble. Le LLM génératif, c'est un perroquet très cultivé : il ne comprend pas, il prédit la suite la plus probable. Utile, mais ne lui confiez pas vos clés sans vérification.
1.2 IA générative et grands modèles de langage (LLM)
L’IA générative produit du contenu nouveau (texte, image, audio, code) au lieu de se limiter à prédire une étiquette comme les modèles discriminatifs. Les grands modèles de langage (LLM) comme GPT-4o sont des transformeurs entraînés sur d’immenses corpus, puis alignés par instructions et retours humains. Ils fonctionnent par prédiction du token suivant : chaque appel découpe le texte en tokens et génère la suite la plus probable, influencée par le prompt et les paramètres (temperature, top_p).
Exemple de découpage en tokens (ordre de grandeur) :
"Bonjour, analysez ce rapport financier." → environ 10-12 tokens
1 token ≈ 4 caractères en anglais, ≈ 2-3 en français
Fenêtre de contexte GPT-4o : 128 000 tokens (prompt + réponse)
À retenir — Vocabulaire examen
Token = unité de texte facturée et comptée dans la fenêtre de contexte. Prompt = entrée fournie au modèle. Complétion = texte généré. Hallucination = affirmation inventée mais formulée avec assurance : le RAG et le grounding la combattent.
Démonstration pas à pas : prenez la phrase « Bonjour, analysez ce rapport financier. » : 1. Le modèle la découpe en environ 10 à 12 tokens (comptez large en français, plus verbeux qu'en anglais). 2. Chaque token consomme la fenêtre de 128 000 tokens de GPT-4o, prompt ET réponse cumulés. 3. Le modèle prédit le token suivant, puis le suivant, jusqu'à la fin. 4. Sans grounding, il remplit les trous avec du plausible : c'est ainsi que naît une hallucination. Moralité : un prompt long sans stratégie de découpage, c'est une facture élevée et une réponse moins fiable.
1.3 Les six principes de l’IA responsable Microsoft
- Équité (fairness) — traiter toutes les personnes de façon juste, tester les biais sur les jeux de données et les sorties.
- Fiabilité et sécurité (reliability and safety) — le système doit fonctionner comme prévu, y compris face aux usages adverses.
- Confidentialité et sécurité (privacy and security) — protéger les données personnelles, limiter la collecte, chiffrer et contrôler l’accès.
- Inclusivité (inclusiveness) — concevoir pour tous les utilisateurs, y compris les personnes en situation de handicap.
- Transparence (transparency) — documenter les capacités et limites, expliquer les décisions (citations RAG, Model Cards).
- Responsabilité (accountability) — supervision humaine, traçabilité des décisions, gouvernance et audit.
Pièges classiques : ordonner IA, ML et Deep Learning à l'envers ; croire que le LLM comprend ou raisonne comme un humain ; confondre token et mot (le français consomme plus de tokens que l'anglais) ; oublier que la fenêtre de contexte inclut le prompt plus la réponse ; citer les six principes sans savoir associer Content Safety à la fiabilité, le grounding à la transparence et l'humain dans la boucle à la responsabilité.
À vous de jouer : un recruteur trie des CV avec un modèle entraîné sur des données historiques biaisées. Quel principe d'IA responsable est violé en premier, et quel correctif proposez-vous ?
Voir la réponse
L'équité. Le modèle reproduit les biais du passé et traite injustement certains candidats. Correctif : rééquilibrer le jeu de données, tester les sorties par groupe, documenter les limites et garder une revue humaine avant toute décision. À l'examen, associez biais de données à équité, pas à transparence.
- Ordonner IA > Machine Learning > Deep Learning et citer un cas d’usage de chaque type d’apprentissage.
- Opposer modèle discriminatif (étiquette) et génératif (contenu nouveau) : DALL-E et GPT sont génératifs.
- Citer les six principes d’IA responsable et associer chaque garde-fou Azure (Content Safety, grounding, humain dans la boucle) au bon principe.
- Expliquer token, fenêtre de contexte et hallucination : toute question sur la limitation du prompt y fait référence.
Module 2 : Provisionner et consommer Azure AI Services
2.1 Ressource multi-services vs ressources mono-service
La ressource Azure AI services (multi-services, anciennement Cognitive Services) expose Vision, Language, Speech, Document Intelligence et Translator avec un seul endpoint et une seule paire de clés. Les ressources mono-service (ex. Computer Vision, Language service) isolent facturation, quotas et contrôle d’accès par service. Les deux types fournissent deux clés (key1, key2) pour permettre la rotation sans interruption.
# Créer une ressource multi-services (Azure CLI)
az cognitiveservices account create \
--name ai-horizon5-prod \
--resource-group rg-ai102 \
--kind CognitiveServices \
--sku S0 \
--location westeurope
# Lister les clés (à protéger, jamais en dur dans le code)
az cognitiveservices account keys list \
--name ai-horizon5-prod \
--resource-group rg-ai102
Pourquoi c'est important : une start-up met sa clé Azure AI en dur dans une application mobile. Un mois plus tard, la clé fuite sur un forum, la facture explose et l'audit de sécurité échoue. Tout cela pour une ressource créée en deux minutes sans réflexion sur le type de ressource ni sur l'authentification. Le choix multi-services contre mono-service et la gestion des clés ne sont pas de la théorie : c'est ce qui sépare une maquette d'une production auditable.
L'analogie qui aide : la ressource multi-services, c'est un pass hôtel unique qui ouvre la piscine, la salle de sport et le restaurant avec une seule facture. Les ressources mono-service, c'est un trousseau avec une clé par porte et une facture par service : plus lourd, mais vous pouvez révoquer l'accès à la piscine sans bloquer le restaurant. Key Vault, c'est le coffre de la réception : on n'y laisse jamais les clés sur le comptoir.
2.2 Endpoints, clés, identités managées et Key Vault
- Endpoint + clé d’abonnement — en-tête
Ocp-Apim-Subscription-Key pour les appels REST directs.
- Microsoft Entra ID + identité managée — méthode recommandée en production : aucun secret à gérer, contrôle RBAC (rôle
Cognitive Services User).
- Azure Key Vault — stocke les clés quand l’authentification par clé reste nécessaire ; la rotation régénère key1/key2 dans le portail.
- SDK vs REST — les SDK (Python, C#, Java, JavaScript) simplifient l’authentification et la sérialisation ; l’API REST convient aux appels ponctuels et aux tests curl.
# Appel REST : analyse d'image (clé en variable d'environnement)
curl -s -X POST "https://ai-horizon5-prod.cognitiveservices.azure.com/vision/v3.2/analyze?visualFeatures=Description,Tags" \
-H "Ocp-Apim-Subscription-Key: $AI_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://exemple.fr/photo.jpg"}'
Démonstration pas à pas : suivez un appel réel : 1. Vous créez la ressource avec az cognitiveservices account create --kind CognitiveServices --sku S0 et récupérez l'endpoint affiché dans le portail. 2. Vous stockez la clé dans une variable d'environnement ($AI_KEY), jamais dans le code. 3. Vous appelez l'endpoint avec l'en-tête Ocp-Apim-Subscription-Key. 4. En production, vous remplacez la clé par une identité managée avec le rôle Cognitive Services User : plus aucun secret à gérer, l'accès se révoque en un clic dans Entra ID. Retenez l'ordre : identité managée d'abord, Key Vault ensuite, variable d'environnement en dépannage.
Piège classique à l’examen
Si une clé fuit, la réponse attendue est la régénération des clés, pas la suppression de la ressource. En conception, préférez toujours Managed Identity + Key Vault aux clés codées en dur.
Pièges classiques : laisser une clé en dur dans le code ou dans Git ; supprimer la ressource au lieu de régénérer key1 puis key2 pour une rotation sans interruption ; choisir mono-service quand un seul endpoint suffisait, ou l'inverse et mélanger les facturations ; utiliser REST en production quand le SDK gérait mieux l'authentification et les tentatives ; oublier que les deux clés servent précisément à alterner pendant la rotation.
À vous de jouer : votre clé Azure AI a fuité dans un dépôt public. Quelle est la première action, et que mettez-vous en place pour que cela ne se reproduise pas ?
Voir la réponse
Régénérez immédiatement la clé compromise dans le portail (key1 puis key2 pour garder le service en ligne), puis basculez l'application sur une identité managée avec le rôle Cognitive Services User. Les secrets restants vont dans Key Vault. Ne supprimez pas la ressource : vous perdriez l'endpoint, l'historique et la facturation pour rien.
- Choisir multi-services (une clé, facturation mutualisée) vs mono-service (isolation, quotas dédiés).
- Connaître la commande
az cognitiveservices account create --kind CognitiveServices --sku S0.
- Ordonner les méthodes d’authentification : Managed Identity (recommandé) > Key Vault > clé en variable d’environnement, jamais en dur.
- Savoir quand utiliser le SDK (applications) vs REST (tests, intégrations légères).
Module 3 : Azure AI Vision (image, visage, vidéo)
3.1 Image Analysis 4.0 : captioning, tagging, OCR
Image Analysis décrit les images (captioning simple et dense), étiquette les objets (tagging), détecte les personnes et lit le texte (Read / OCR) y compris dans les documents. La version 4.0 unifie ces capacités dans une API synchrones pour les images et un mode asynchrone pour les gros volumes. Les coordonnées retournées (bounding boxes) permettent de localiser chaque objet détecté.
# SDK Python : légende + étiquettes + OCR (extrait)
from azure.ai.vision.imageanalysis import ImageAnalysisClient
from azure.ai.vision.imageanalysis.models import VisualFeatures
from azure.core.credentials import AzureKeyCredential
client = ImageAnalysisClient(
endpoint="https://ai-horizon5-prod.cognitiveservices.azure.com",
credential=AzureKeyCredential("VOTRE_CLE"))
result = client.analyze_from_url(
image_url="https://exemple.fr/facture-scan.jpg",
visual_features=[VisualFeatures.CAPTION, VisualFeatures.TAGS, VisualFeatures.READ])
print(result.caption.text) # Légende générée
for tag in result.tags.list: # Étiquettes + scores de confiance
print(tag.name, round(tag.confidence, 2))
Pourquoi c'est important : un entrepôt reçoit des milliers de photos de palettes par jour et veut détecter les colis endommagés. Sans Image Analysis, il faut une équipe qui regarde chaque image. Avec le captioning, le tagging et l'OCR, le tri devient automatique et chaque détection renvoie sa position exacte. Mais si le besoin touche aux visages, le projet peut se retrouver bloqué faute d'approbation d'accès restreint. Connaître le bon service Vision dès le départ évite un prototype à jeter.
L'analogie qui aide : Image Analysis, c'est une paire de lunettes qui décrit ce qu'elle voit : « un homme devant un entrepôt » pour le captioning, « homme, casque, palette » pour le tagging, et la lecture à voix haute des étiquettes pour l'OCR. Custom Vision, c'est le même opticien qui vous fabrique des verres sur mesure pour vos propres défauts : vos cartons, vos pièces, vos étiquettes. Face avec identification, c'est une serrure biométrique : on ne l'installe pas sans autorisation écrite.
3.2 Face, Custom Vision et Video
- Face — détecte visages, points de repère et attributs (lunettes, pose) ; la reconnaissance/identification exige une approbation d’accès restreint et un cas d’usage responsable documenté.
- Custom Vision — entraîne vos propres classifieurs et détecteurs d’objets : étiquetage d’images, entraînement, publication d’une itération, puis prédiction via endpoint dédié.
- Video Indexer / Video Retrieval — indexe les vidéos (parole, visages, scènes, émotions) pour la recherche dans les contenus vidéo.
Démonstration pas à pas : analysez la photo d'une facture posée sur un bureau : 1. Vous appelez analyze_from_url avec CAPTION, TAGS, READ. 2. Le service renvoie la légende (« un document sur une table »), les étiquettes (« document, papier, texte » avec un score comme 0.97) et le texte OCR ligne par ligne. 3. Chaque objet détecté arrive avec son rectangle (x, y, largeur, hauteur) pour le localiser. 4. Pour un besoin métier, vous passez à Custom Vision : étiquetez 50 images par classe, entraînez, vérifiez précision et rappel, publiez l'itération, puis interrogez le nouvel endpoint de prédiction.
À retenir — IA responsable et Face
Les attributs sensibles (émotion, âge, genre) ont été retirés ou restreints : toute question sur l’identification faciale attend « accès restreint + validation du cas d’usage ».
Pièges classiques : proposer Face pour identifier des employés sans mentionner l'approbation d'accès restreint ; utiliser Image Analysis 3.2 par habitude alors que la 4.0 unifie captioning, tagging et Read ; entraîner Custom Vision puis oublier de publier l'itération, donc prédire sur l'ancienne version ; ignorer les scores de confiance et les rectangles, puis ne pas savoir localiser l'objet ; demander l'émotion ou l'âge comme avant, alors que ces attributs sont retirés ou restreints.
À vous de jouer : une école veut reconnaître automatiquement les élèves à l'entrée avec Face. Que répondez-vous en tant qu'ingénieur AI-102 ?
Voir la réponse
Non sans dossier d'accès restreint et validation du cas d'usage responsable. L'identification faciale exige une approbation Microsoft et une justification éthique. Proposez d'abord une alternative : badge, QR code ou détection anonymisée de présence, et documentez les risques avant toute demande d'accès.
- Associer chaque besoin Vision au bon service : description/OCR → Image Analysis, visages → Face, modèle métier sur mesure → Custom Vision, indexation vidéo → Video Indexer.
- Savoir que Face identification = accès restreint avec justification d’IA responsable.
- Lire une réponse JSON : caption, tags avec confidence, readResult (lignes OCR), faces avec faceRectangle.
- Décrire le cycle Custom Vision : taguer, entraîner, évaluer (précision/rappel), publier l’itération.
Module 4 : Language, Speech, Document Intelligence et Translator
4.1 Azure AI Language : comprendre et expurger le texte
- Analyse de sentiments et opinion mining — polarité positive/négative/neutre, par phrase et par aspect.
- Détection PII et rédaction — repère e-mails, téléphones, numéros de sécurité sociale et les masque avant archivage.
- Reconnaissance d’entités nommées (NER) et liaison d’entités — personnes, lieux, organisations reliés à une base de connaissances.
- Résumé, détection de langue, questions-réponses personnalisées — résumé extractif/abstractif, routage multilingue, base de connaissances métier.
- CLU (Conversational Language Understanding) — intentions + entités pour les bots, avec évaluation par projet de conversation.
# SDK Python : sentiments + PII (extrait)
from azure.ai.textanalytics import TextAnalyticsClient
from azure.core.credentials import AzureKeyCredential
client = TextAnalyticsClient(endpoint="https://ai-horizon5-prod.cognitiveservices.azure.com",
credential=AzureKeyCredential("VOTRE_CLE"))
avis = ["Le déploiement RAG est limpide, mais la latence du premier appel reste élevée."]
print(client.analyze_sentiment(avis)[0].sentiment) # positive / negative / neutral / mixed
pii = client.recognize_pii_entities(["Contact : marie.dupont@exemple.fr, 06 12 34 56 78"])[0]
print([(e.text, e.category) for e in pii.entities]) # Email, PhoneNumber → à rédiger
Pourquoi c'est important : un service client archive des avis contenant e-mails et numéros de téléphone en clair. Le jour d'un contrôle, c'est une violation de confidentialité. Le même service rate les avis négatifs noyés dans des milliers de messages. L'analyse de sentiments trie le signal, la détection PII expurge avant archivage ou indexation RAG, et le résumé rend les rapports lisibles. Sans ces trois réflexes, aucune solution GenAI en aval n'est conforme.
L'analogie qui aide : Azure AI Language, c'est une secrétaire rigoureuse : elle surligne le ton de chaque lettre (sentiment), caviarde au marqueur noir les coordonnées personnelles (PII), colle des étiquettes « personne, lieu, entreprise » (entités) et résume en une page. Speech fait le même travail à l'oral : la sténotypiste qui transcrit (STT) et la comédienne qui lit à voix haute (TTS). Document Intelligence, c'est le comptable qui recopie les factures sans faute de frappe.
4.2 Speech : transcription, synthèse et traduction vocale
- Speech-to-Text (STT) — transcription temps réel ou par lot, avec diarisation des locuteurs et vocabulaires personnalisés (Custom Speech).
- Text-to-Speech (TTS) — voix neuronales, SSML pour la prosodie, voix personnalisées (Custom Voice, accès restreint).
- Traduction vocale — Speech-to-text + traduction + synthèse dans la langue cible.
# Azure CLI : transcription par lot d'un fichier audio stocké sur Blob
az cognitiveservices account create --name ai-speech-prod --resource-group rg-ai102 \
--kind SpeechServices --sku S0 --location westeurope
# Puis transcription via le portail Speech Studio ou le SDK Speech :
# speechsdk.SpeechConfig(subscription=CLE, region="westeurope")
Démonstration pas à pas : traitez l'avis « Le déploiement RAG est limpide, mais la latence du premier appel reste élevée. » : 1. analyze_sentiment renvoie un sentiment global mitigé et un score par phrase : positif sur la clarté, négatif sur la latence. 2. recognize_pii_entities repère « marie.dupont@exemple.fr » comme Email et « 06 12 34 56 78 » comme PhoneNumber, à masquer avant stockage. 3. Côté audio, Speech-to-Text transcrit la réunion avec diarisation (« Locuteur 1, Locuteur 2 »), puis Text-to-Speech relit le résumé avec une voix neuronale pilotée en SSML. Retenez le sens : STT va de l'audio vers le texte, TTS fait l'inverse.
4.3 Document Intelligence et Translator
Document Intelligence (ex-Form Recognizer) extrait texte, paires clé-valeur, tableaux et cases à cocher. Modèles préconçus : layout (mise en page), invoice (factures), receipt, idDocument, tax. Modèles personnalisés : template (zones fixes), neural (mises en page variées), composed (aiguille vers le bon sous-modèle). Translator traduit documents et textes avec dictionnaires et mémoire de traduction personnalisée.
# SDK Python : facture avec le modèle préconçu (extrait)
from azure.ai.formrecognizer import DocumentAnalysisClient
from azure.core.credentials import AzureKeyCredential
client = DocumentAnalysisClient(endpoint="https://ai-horizon5-prod.cognitiveservices.azure.com",
credential=AzureKeyCredential("VOTRE_CLE"))
poller = client.begin_analyze_document_from_url("prebuilt-invoice", "https://exemple.fr/facture.pdf")
for doc in poller.result().documents:
print(doc.fields["CustomerName"].value, doc.fields["InvoiceTotal"].value)
Pièges classiques : inverser STT et TTS le jour de l'examen ; oublier la diarisation pour une réunion à plusieurs voix ; prendre un modèle template pour des factures aux mises en page variées alors qu'il faut neural, ou oublier composed pour router vers le bon sous-modèle ; indexer des documents sans expurger les PII au préalable ; croire que Custom Voice se crée librement alors qu'elle exige un accès restreint comme Face.
À vous de jouer : vous devez extraire automatiquement le total et le nom client de 5 000 factures PDF aux mises en page différentes. Quel modèle Document Intelligence choisissez-vous, et que faites-vous des e-mails détectés dans les factures ?
Voir la réponse
Le modèle préconçu prebuilt-invoice : il sait déjà où chercher le total et le client, même avec des mises en page variées. Un modèle template échouerait car il attend des zones fixes. Les e-mails repérés par la détection PII sont masqués avant archivage et avant toute indexation RAG, pour rester conforme.
- Associer chaque besoin langue au bon service : expurger des données personnelles → Language PII, intention de bot → CLU, base de questions métier → Custom Question Answering.
- Opposer STT (audio vers texte) et TTS (texte vers audio) et citer la diarisation pour les réunions multi-locuteurs.
- Choisir le modèle Document Intelligence : prebuilt-invoice pour des factures, template pour formulaires fixes, neural pour mises en page variées, composed pour routage multi-modèles.
- Savoir que Custom Voice (voix clonée) exige un accès restreint, comme Face identification.
Prochaine étape
Testez ces notions dans le Terminal Azure IA (commandes az cognitiveservices account, prompt, safety-check), puis passez au niveau Intermédiaire : Azure OpenAI, prompts et RAG.