WIKI
SUPPORT-IA Support N2/N3 · plateformes IA Azure

09 · Questions d'entretien et fiche J-1

21 min de lecture Mis à jour le 23 octobre 2026
Sur cette page

Version : 1.0 · Date : 2026-10-23 · Parcours Support N2/N3, plateformes IA sur Azure

En une phrase : en entretien de support N2/N3 sur l'IA, on attend trois choses : comprendre le chemin d'une question dans un chatbot RAG, savoir où regarder quand ça casse (et dans quel ordre), et se comporter en professionnel du support pendant un P1 ; ce chapitre donne 50 questions avec des réponses courtes à dire à voix haute, puis la fiche à relire lundi matin.

Comment s'en servir : lire la question, répondre à voix haute en moins d'une minute, puis comparer avec la réponse modèle. Les réponses citent des faits vérifiés sur Microsoft Learn, kubernetes.io, argo-cd.readthedocs.io et langfuse.com (relevé du 23/10/2026) ; les détails sont dans les chapitres 01 à 08.

Le fil rouge à placer dans plusieurs réponses : « je qualifie, je cherche ce qui a changé, je suis la requête saut par saut en corrélant par operation_Id, je lis avant d'agir, et toute action en production est annoncée et validée ».

Partie A · RAG, recherche et données#

Q1. Qu'est-ce qu'un RAG et pourquoi l'utiliser plutôt qu'un fine-tuning ? Retrieval-Augmented Generation : à chaque question, on cherche les passages pertinents dans une base (ici Azure AI Search) et on les injecte dans le prompt pour que le modèle réponde à partir d'eux. Avantages : données à jour sans réentraîner, réponses citables, contrôle d'accès par document, coût bien plus faible qu'un fine-tuning. Le fine-tuning change le comportement ou le style du modèle, pas sa connaissance à jour.

Q2. Quelles sont les trois étapes d'un RAG, et pourquoi c'est utile en support ? Ingestion (extraction, OCR avec Document Intelligence, découpage, embeddings, indexation), recherche (requête hybride, filtres, semantic ranker) et génération (prompt + chunks → modèle). En support, face à une « mauvaise réponse », on cherche l'étage en faute avant de toucher au prompt : le document est-il dans l'index ? remonte-t-il ? le modèle l'a-t-il reçu ? (R2).

Q3. Qu'est-ce qu'un embedding ? Un vecteur numérique qui représente le sens d'un texte ; deux textes proches ont des vecteurs proches. On calcule l'embedding des chunks à l'indexation et celui de la question à la requête, avec le même modèle (par exemple text-embedding-3-small, 1 536 dimensions). Un changement de modèle d'embedding impose de réindexer : sinon on compare des vecteurs incompatibles.

Q4. Pourquoi découper les documents (chunking) et comment choisir la taille ? Le modèle d'embedding a une limite d'entrée et un chunk trop gros dilue le sens ; trop petit, il perd le contexte. Microsoft conseille de partir de 512 tokens (environ 2 000 caractères) avec 25 % de chevauchement. Dans AI Search, le Text Split skill découpe par pages (maximumPageLength, pageOverlapLength) ou par phrases. On valide ensuite sur un jeu de questions de référence.

Q5. Qu'est-ce que la recherche hybride dans Azure AI Search ? Une requête plein texte (BM25) et une requête vectorielle (HNSW ou KNN exhaustif) exécutées en parallèle, puis fusionnées par Reciprocal Rank Fusion (RRF). Elle combine la précision des mots-clés (codes, noms propres) et la proximité de sens. Les scores RRF sont petits par construction : un @search.score de 0,03 peut être un très bon résultat.

Q6. À quoi sert le semantic ranker ? C'est un reclassement de second niveau (L2) : il reprend jusqu'à 50 résultats du classement initial (BM25 ou RRF) et les note avec un modèle de compréhension du langage. Il renvoie @search.rerankerScore de 0 à 4 (4 = répond complètement, 0 = hors sujet), plus des captions et answers extraits mot pour mot. Avec des vecteurs, on met k à 50 pour lui donner assez de candidats.

Q7. Un utilisateur dit que le chatbot ignore un document publié ce matin. Que vérifiez-vous ?

  1. Le document est-il dans l'index (requête directe sur un mot rare) ? 2) Statut de l'indexer (Get Indexer Status : dernière exécution, itemsFailed, erreurs) et planification. 3) Les filtres de sécurité : l'utilisateur a-t-il le droit de voir ce document ? 4) Si le document est indexé et remonte, la génération (trace Langfuse). Correctif typique : corriger l'erreur d'ingestion puis relancer l'indexer, avec accord.

Q8. Quels statuts d'indexer connaissez-vous ? Statut global : running ou error. Par exécution : success, inProgress, transientFailure (l'indexer réessaie, en espaçant jusqu'à une fois par 24 h), persistentFailure (intervention humaine, les exécutions planifiées s'arrêtent jusqu'au reset) et reset. Une exécution peut être success avec des erreurs tant qu'on reste sous maxFailedItems.

Q9. À quoi sert Document Intelligence dans la chaîne, et quelles limites retenir ? Il extrait texte, tableaux et structure des PDF, scans et images (OCR, modèles prebuilt-read et prebuilt-layout) avant le découpage. L'analyse est asynchrone (POST → Operation-Location → GET jusqu'à succeeded ou failed). Limites : 500 MB et 2 000 pages en S0 (4 MB et 2 pages en F0), 15 requêtes d'analyse par seconde par défaut, pas de PDF protégé par mot de passe. En Entra ID il faut un custom subdomain et le rôle Cognitive Services User.

Q10. Comment évaluer la qualité d'un chatbot RAG dans le temps ? Un jeu de questions de référence (dataset) rejoué à chaque changement de prompt, de modèle, de chunking ou d'index, avec des scores : retours utilisateurs, notation manuelle, LLM-as-a-judge (Langfuse les gère tous les trois). On compare avant et après ; une seule question du ticket ne suffit pas à valider.

Partie B · Modèles, tokens, coûts et latence#

Q11. Qu'est-ce qu'un token et pourquoi le support doit-il s'en soucier ? L'unité de texte que le modèle lit et écrit (un morceau de mot). Tout se mesure en tokens : la facture (entrée et sortie, les tokens de raisonnement sont facturés en sortie), la limite de débit (TPM), la fenêtre de contexte et la latence (plus de tokens d'entrée = premier token plus tard ; plus de tokens de sortie = réponse plus longue).

Q12. TPM et RPM : comment fonctionne la limite d'un déploiement Azure OpenAI ? Le quota est attribué par abonnement, région, modèle et type de déploiement ; on en affecte une part à chaque déploiement en TPM, et le RPM en découle (pour les anciens modèles de chat : 1 000 TPM = 6 RPM). Le TPM est contrôlé à la réception sur une estimation qui inclut max_tokens ; le RPM est contrôlé sur des fenêtres de 1 ou 10 secondes, donc une rafale peut déclencher un 429 sous la moyenne.

Q13. Vous voyez des 429. Comment les traitez-vous ? Je lis le message : « rate limit exceeded » = limite du déploiement (plus de TPM, rééquilibrer, demander une hausse, réduire max_tokens, lisser) ; « service temporarily unable / high demand » = capacité du service (backoff, autre région, PTU), une hausse de quota n'y changera rien. J'utilise retry-after-ms et les en-têtes x-ratelimit-*, je vérifie qu'il n'y a qu'un seul niveau de retry. 429 durables sous le quota approuvé en production : ticket Microsoft.

Q14. Quels types de déploiement connaissez-vous ? Global Standard (point de départ recommandé, quota le plus élevé, routage mondial), Data Zone Standard (traitement dans une zone US ou UE), Standard régional, les variantes Provisioned (PTU : capacité réservée, latence plus stable) et Global Batch / Data Zone Batch (asynchrone, délai cible 24 h, 50 % moins cher que Global Standard). Le choix dépend de la résidence des données, du volume et de la stabilité de latence voulue.

Q15. Qu'est-ce que le prompt caching et comment l'exploiter ? Le service garde en cache le calcul d'un préfixe identique de prompt (au moins 1 024 tokens) ; les tokens en cache sont facturés moins cher et le premier token arrive plus vite. On le voit dans usage.prompt_tokens_details.cached_tokens. Pour en profiter : contenu stable (prompt système, outils, instructions) au début, contenu variable (question, chunks) à la fin. Sur les familles GPT-5.6 et suivantes, l'écriture en cache peut être facturée.

Q16. La latence a doublé sans erreur. Comment décomposez-vous ? Je compare avec une période normale (volume, p95), puis je décompose par dépendance dans AppDependencies : application, AI Search, modèle. Côté modèle : Time to Response (TTFT), Time Between Tokens, Time to Last Byte, toujours à côté des tokens (ProcessedPromptTokens, GeneratedTokens). Latence et tokens qui montent ensemble : prompt ou réponse plus longs ; latence seule : 429 et retries, charge, PTU utilization (R3).

Q17. Le coût des tokens a explosé ce mois-ci. Par où commencez-vous ? Par déploiement et par jour : plus de requêtes ou plus de tokens par requête ? Puis entrée ou sortie. Causes classiques : nouveau modèle (raisonnement), plus de chunks, historique de conversation non borné, cache raté (cached_tokens à 0), boucle d'agent ou retries, ingestion lancée en temps réel au lieu de Batch. Langfuse donne le coût par trace, utilisateur et version de prompt.

Q18. Une question légitime est bloquée par le content filter. Que faites-vous ? Je distingue HTTP 400 code content_filter (le prompt, y compris les chunks injectés, est bloqué) et finish_reason: content_filter (la sortie est filtrée). Je lis content_filter_results (catégorie, sévérité). Si c'est légitime, je documente et je demande au propriétaire d'ajuster la configuration de guardrail ; je ne relâche jamais une détection de jailbreak sans analyse sécurité. Les deux cas sont facturés.

Partie C · AKS et Kubernetes pour le support#

Q19. Citez les objets Kubernetes que vous manipulez en support et leur rôle. Pod (un ou plusieurs conteneurs), Deployment (version désirée, rollouts) → ReplicaSet (un par version) → pods, Service (adresse stable vers les pods), Ingress ou Gateway (entrée HTTP), ConfigMap et Secret (configuration), ServiceAccount (identité du pod, base de Workload ID), Namespace (isolation, quotas), HPA (mise à l'échelle), Events (ce qui s'est passé).

Q20. CrashLoopBackOff, ImagePullBackOff, Pending : que signifient-ils et où regardez-vous ? CrashLoopBackOff : le conteneur démarre puis plante → kubectl logs --previous, describe (OOMKilled ?). ImagePullBackOff : l'image ne se télécharge pas → message de l'événement (401 droits, 403 réseau ou DNS, not found). Pending : le pod n'est placé sur aucun node → FailedScheduling (CPU, mémoire, taints, affinité, quota). Toujours commencer par kubectl describe pod et la section Events.

Q21. J'ai poussé une nouvelle image avec le même tag et rien ne change. Pourquoi ? Un rollout ne démarre que si le template de pod change ; même tag = template identique = pas de nouveau ReplicaSet. Et la politique par défaut IfNotPresent peut garder l'ancienne image sur le node. Il faut un tag unique par build (ou un digest), écrit dans le repo GitOps. Kubernetes déconseille :latest en production.

Q22. Un rollout est bloqué. Comment le voyez-vous et que faites-vous ? kubectl rollout status ne se termine pas ; describe deployment montre Progressing=False raison ProgressDeadlineExceeded (après 600 s par défaut) ou ReplicaFailure ... FailedCreate (quota, admission). Je trouve la cause dans les événements du nouveau ReplicaSet. En contournement, retour à la version précédente : par Git avec Argo CD (pas de kubectl à la main en GitOps).

Q23. Différence entre liveness, readiness et startup probe ? Readiness : le pod reçoit-il du trafic ? (en échec, il sort des endpoints du Service, sans redémarrer). Liveness : le conteneur est-il vivant ? (en échec, kubelet le redémarre). Startup : laisse le temps à un démarrage long avant que la liveness s'applique. Piège : une liveness qui teste une dépendance externe redémarre tous les pods quand la dépendance tombe.

Q24. Requests et limits : quel impact en incident ? Les requests servent au placement (un pod trop gourmand reste Pending) ; les limits plafonnent : au-delà de la limite mémoire le conteneur est tué (OOMKilled), au-delà de la limite CPU il est ralenti (throttling : latence sans erreur). Je regarde la consommation réelle dans Grafana ou Container insights avant de proposer un changement.

Q25. Expliquez Workload Identity sur AKS en 30 secondes. Le cluster expose un OIDC issuer. Le pod (label azure.workload.identity/use: "true") utilise un ServiceAccount annoté avec le client ID d'une managed identity. Sur cette identité, une federated identity credential fait confiance à l'issuer du cluster pour le subject system:serviceaccount:<ns>:<sa>. Le webhook injecte AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE ; le SDK échange le jeton du pod contre un jeton Entra ID. Aucun secret stocké.

Q26. Un pod ne monte pas ses secrets Key Vault (Secrets Store CSI). Votre démarche ? kubectl describe pod → événement FailedMount et son message. Selon le message : CSI driver absent sur le node, SecretProviderClass introuvable (même namespace), AADSTS70021 (subject ou issuer de la federated credential), 403 (rôle Key Vault Secrets User manquant ou pas propagé), timeout (DNS privatelink.vaultcore.azure.net, Private Endpoint). Logs des pods secrets-store-provider-azure et secrets-store-csi-driver du même node (R4).

Q27. Que savez-vous de l'avenir de l'Ingress sur AKS ? Le projet communautaire Ingress NGINX est retiré (maintenance arrêtée en mars 2026). Microsoft assure les correctifs de sécurité critiques de l'application routing add-on NGINX jusqu'en novembre 2026 et recommande Gateway API (application routing Gateway API implementation, ou Istio) ou Application Gateway for Containers. Pour le client, c'est un sujet de migration à planifier.

Partie D · GitOps, Azure DevOps et ACR#

Q28. Qu'est-ce que le GitOps et qu'est-ce que ça change pour le support ? L'état voulu du cluster est dans Git ; un agent (Argo CD) compare en continu Git et le cluster et applique les écarts. Pour le support : la vérité est dans Git, les changements sont tracés (qui, quand, quoi), le retour arrière est un commit, et une modification faite à la main est soit écrasée, soit un écart invisible si le self-heal est désactivé.

Q29. Sync status et health status dans Argo CD ? Sync : Synced (le cluster correspond à Git) ou OutOfSync. Health : Healthy, Progressing, Degraded, Suspended, Missing, Unknown. Une application peut être Synced et Degraded : Git est appliqué, mais les pods ne démarrent pas.

Q30. Le développeur a poussé, Argo CD ne déploie pas. Vos hypothèses ? Délai de détection (polling 120 s + jitter 60 s, 3 min au plus) ; auto-sync désactivé (OutOfSync en attente) ; sync en échec sur ce commit (l'auto-sync ne retente pas le même commit) ; mauvaise branche ou mauvais chemin suivi ; tag d'image inchangé dans les manifests ; accès au repo cassé. Commandes : argocd app get --refresh, --show-operation, argocd app diff, argocd app history.

Q31. Comment faire un rollback avec Argo CD ? argocd app rollback <app> <id> existe, mais pas sur une application en auto-sync. En GitOps, le retour arrière normal est un revert du commit dans Git : tracé, revu, et l'auto-sync l'applique. Toujours avec l'accord prévu par le processus de changement.

Q32. Pourquoi ACR Premium dans ce contexte ? Parce que les Private Endpoints (et la geo-replication) sont réservés au tier Premium : avec des plateformes entièrement privées, c'est le seul tier possible. AKS tire avec la kubelet identity (rôle AcrPull, ou Container Registry Repository Reader si le registre est en mode ABAC) ; la Web App tire avec sa managed identity, via le VNet si vnetImagePullEnabled.

Q33. Comment diagnostiquez-vous un ImagePullBackOff depuis un ACR privé ? Le message dit l'étape : 401 = droits (rôle, image d'une autre architecture, nom faux) ; 403 = réseau (lien de la zone privatelink.azurecr.io absent, pare-feu ACR) ; timeout = chemin (NSG, Azure Firewall, UDR) ; not found = tag. Outil intégré : az aks check-acr. Et l'endpoint de données régional (<acr>.<region>.data.azurecr.io) doit aussi se résoudre en privé.

Partie E · Web App for Containers privée#

Q34. Private Endpoint et VNet integration sur une Web App : quelle différence ? Le Private Endpoint gère l'entrant : le site reçoit le trafic sur une IP privée (zone privatelink.azurewebsites.net). La VNet integration gère le sortant : l'application joint ses dépendances privées (AI Search, Azure OpenAI, Key Vault) via un subnet délégué ; avec Route All, tout le trafic sortant passe par le VNet. Il faut les deux pour une application entièrement privée.

Q35. « Container didn't respond to HTTP pings » : causes et correctifs ? Au démarrage, App Service envoie un warmup (/robots933456.txt) et attend une réponse HTTP, n'importe quel code, 240 s par défaut. Causes : port (aligner WEBSITES_PORT), application qui écoute sur 127.0.0.1, démarrage trop long (WEBSITES_CONTAINER_START_TIME_LIMIT jusqu'à 1 800 s), crash au démarrage (variable ou secret manquant), image non tirée. Lecture : az webapp log tail après az webapp log config --docker-container-logging filesystem.

Q36. Comment testez-vous la résolution DNS et la connectivité depuis une Web App Linux privée ? Depuis la console SSH ou Kudu du site : nslookup <service>.openai.azure.com (doit répondre une IP privée) et curl -v https://<service> pour la connectivité TLS. (nameresolver et tcpping sont les outils des applications Windows.) Puis vérifier le lien de la Private DNS zone vers le VNet d'intégration et l'état du Private Endpoint.

Partie F · Observabilité#

Q37. Log stream, Application Insights, Log Analytics workspace : qui fait quoi ? Log stream : la sortie console en direct (stdout/stderr), utile pendant un démarrage ou un incident en cours, sans historique ni requête. Application Insights : la télémétrie applicative (requêtes, dépendances, exceptions, traces distribuées). Log Analytics workspace : le stockage et le moteur KQL où atterrissent la télémétrie Application Insights (les ressources classiques sont retirées, tout est workspace-based), les resource logs Azure et Container insights.

Q38. Qu'est-ce qu'OpenTelemetry et comment s'intègre-t-il à Azure Monitor ? Le standard ouvert (CNCF) d'instrumentation pour traces, métriques et logs. Azure Monitor le prend en charge de deux façons : l'Azure Monitor OpenTelemetry Distro (Microsoft OpenTelemetry Distro, intégration complète avec Application Insights) ou l'ingestion OTLP native (Collector, Azure Monitor Agent, onboarding AKS). La propagation W3C Trace Context (traceparent) donne l'identifiant commun : l'operation_Id.

Q39. Comment retrouvez-vous tout le parcours d'une question ? Par l'operation_Id : union AppRequests, AppDependencies, AppExceptions, AppTraces | where OperationId == "<id>". On voit la requête entrante, chaque appel (AI Search, Azure OpenAI, Key Vault) avec sa durée et son code, et l'exception. Côté LLM, la trace Langfuse donne le prompt réel, les chunks injectés, les tokens et le coût.

Q40. Managed Prometheus et Azure Managed Grafana : comment ça s'articule ? Les pods ama-metrics du cluster scrapent les métriques (kubelet, cAdvisor, kube-state-metrics, applications) et les envoient dans un Azure Monitor workspace. Azure Managed Grafana les lit via une data source Prometheus authentifiée par sa managed identity. Les métriques et logs Azure passent par la data source Azure Monitor.

Q41. Grafana n'affiche plus rien. Quels rôles et quels points vérifiez-vous ? Identité de Grafana activée ; Monitoring Reader (abonnement ou RG) pour la data source Azure Monitor ; Monitoring Data Reader sur l'Azure Monitor workspace pour Prometheus ; Reader ou Log Analytics Reader sur le LAW si « No Log Analytics workspaces found ». Ensuite période et variables du tableau, puis la collecte : pods ama-metrics, /targets, quotas d'ingestion (R5).

Q42. Qu'apporte Langfuse par rapport à Application Insights ? Application Insights voit les appels (durée, code, dépendances) ; Langfuse voit le contenu LLM : traces composées d'observations (spans, generations, events), prompt et réponse, chunks, tokens et coût par génération, sessions multi-tours, scores (retours utilisateurs, LLM-as-a-judge, annotation) et datasets d'évaluation. Indispensable pour R2 (mauvaise réponse) et R14 (coût).

Q43. Quelles alertes mettriez-vous en place en priorité sur un chatbot ? Taux d'échec et latence p95 des requêtes (Application Insights), test de disponibilité sur une vraie question, taux de 429 et utilisation du TPM du modèle, redémarrages de pods et ProgressDeadlineExceeded, Argo CD SyncFailed / Degraded, âge de la dernière indexation réussie, expiration des secrets et certificats, budget Cost Management.

Partie G · Posture de support (comportemental)#

Q44. Comment gérez-vous un P1 ?

  1. Qualifier en 5 minutes (qui, quoi, depuis quand, périmètre) et ouvrir le canal de crise. 2) Communiquer tout de suite : symptôme, impact, prochain point à heure fixe. 3) Ce qui a changé et saut par saut. 4) Contournement dès qu'il existe (rollback, autre déploiement de modèle), validé. 5) Vérifier sur une métrique et avec un utilisateur.
  2. Post-mortem sous quelques jours. Je tiens une chronologie horodatée pendant tout l'incident.

Q45. Quand et comment escaladez-vous ? J'escalade quand l'impact dépasse ce que je peux résoudre dans le délai attendu, quand la cause est hors de mon périmètre (code applicatif, plateforme Microsoft) ou quand une action demande un droit que je n'ai pas. J'escalade avec un dossier : symptôme, horodatage UTC, ressources, operation_Id, requêtes et résultats, hypothèses écartées, ce que je demande précisément. Escalader tôt avec des faits n'est pas un échec.

Q46. Comment communiquez-vous avec les utilisateurs pendant un incident ? Court, factuel, sans jargon : ce qui ne marche pas, qui est touché, le contournement, l'heure du prochain point. Je tiens le rythme annoncé même sans nouveauté (« analyse en cours, prochain point à 10:30 »). À la fin : résolution, cause en une phrase, ce qui est fait pour éviter la récidive. Je ne promets pas d'heure de résolution que je ne maîtrise pas.

Q47. Que mettez-vous dans un post-mortem ? Résumé, chronologie précise (début, détection, contournement, résolution), impact, cause racine technique puis « pourquoi ce n'a pas été détecté » (5 pourquoi), ce qui a bien marché et ce qui a manqué, et des actions avec responsable et date (alerte, test, runbook). Sans recherche de coupable : on corrige le système, pas les personnes.

Q48. On vous demande de « juste redémarrer » en production. Que répondez-vous ? D'abord capturer les preuves (describe, logs --previous, operation_Id), sinon la cause disparaît. Puis j'annonce l'environnement, la commande exacte, l'impact attendu et le retour arrière, et j'attends la validation prévue par le processus. En GitOps, je privilégie une action tracée (sync, revert) plutôt qu'une modification manuelle.

Q49. Vous ne connaissez pas la réponse à une question technique en entretien. Je le dis, puis je montre comment je trouverais : « je ne l'ai pas manipulé, je vérifierais dans la documentation Microsoft Learn et dans les logs, voici par quoi je commencerais ». Un support qui invente est plus dangereux qu'un support qui cherche.

Q50. Deux incidents arrivent en même temps. Comment priorisez-vous ? Par impact et urgence selon la grille du client (P1 avant P2), puis par nombre d'utilisateurs touchés et contournement disponible. Je préviens l'émetteur de l'incident mis en attente et je demande du renfort si deux P1 se chevauchent. Une cause commune est possible (DNS, Azure OpenAI, Entra ID) : je vérifie d'abord si les deux sont liés.

Questions à poser au recruteur#

  • Combien de projets IA en production, un cluster par projet, quels environnements (DEV, REC, PRD) ?
  • Quelle est la grille de priorité, l'astreinte, et qui est le N3 (équipe projet, éditeur, Microsoft) ?
  • Quels droits a le N2/N3 en production (lecture seule, actions sur validation) ?
  • Les runbooks existent-ils, et quelle est la place de Langfuse et de Grafana dans le quotidien ?
  • Quel est le plan pour la fin du support d'Ingress NGINX en novembre 2026 ?

Fiche J-1 (à relire lundi matin)#

Méthode

  • Qualifier : qui, quoi, depuis quand, périmètre, impact → priorité.
  • Ce qui a changé : Argo CD history, pipeline, Activity log / resourcechanges, secrets, quotas, Service Health.
  • Saut par saut : utilisateur → entrée privée → application → AI Search → Azure OpenAI ; premier saut en erreur.
  • operation_Id : union AppRequests, AppDependencies, AppExceptions, AppTraces.
  • Lire avant d'agir ; toute action annoncée (environnement, commande, impact, retour arrière) et validée.
  • Communication à heure fixe ; post-mortem sans coupable, actions datées.

RAG

  • Ingestion, recherche, génération : trouver l'étage avant de toucher au prompt.
  • Hybride = BM25 + vecteurs, fusion RRF (scores petits, normal) ; semantic ranker sur 50 résultats, score 0 à 4, k = 50.
  • Chunking de départ : 512 tokens, 25 % de chevauchement ; même modèle d'embedding à l'indexation et à la requête.
  • Indexer : transientFailure, persistentFailure (reset), maxFailedItems, Get Indexer Status.
  • Document Intelligence : asynchrone, 500 MB, 2 000 pages, 15 TPS, custom subdomain + Cognitive Services User.

Modèles

  • TPM / RPM (1 000 TPM = 6 RPM sur les anciens modèles de chat), max_tokens compte, RPM sur 1 ou 10 s.
  • 429 : lire le message (quota ou capacité), retry-after-ms, x-ratelimit-*, un seul niveau de retry.
  • Latence : Time to Response (TTFT), Time Between Tokens, Time to Last Byte, toujours avec les tokens.
  • Prompt caching : préfixe identique ≥ 1 024 tokens, cached_tokens, stable au début.
  • Global Standard, Data Zone, Provisioned (PTU), Global Batch (− 50 %, 24 h).
  • Content filter : 400 content_filter (prompt) ou finish_reason (sortie), facturés ; guardrails.

AKS et GitOps

  • describe (Events), logs --previous, get events --sort-by=.lastTimestamp, rollout status | history | undo.
  • Rollout seulement si .spec.template change ; tag unique ; ProgressDeadlineExceeded à 600 s.
  • CrashLoopBackOff (logs), ImagePullBackOff (401 droits, 403 réseau), Pending (FailedScheduling), OOMKilled (limit).
  • Workload ID : label pod, annotation SA, federated credential (issuer, subject, audience api://AzureADTokenExchange).
  • CSI Key Vault : FailedMount, SecretProviderClass même namespace, Key Vault Secrets User, privatelink.vaultcore.azure.net.
  • Argo CD : ≤ 3 min, Synced / OutOfSync, Healthy / Degraded, pas de retry du même commit, pas de rollback en auto-sync.
  • ACR Premium : Private Endpoint, AcrPull (ou Repository Reader en ABAC), az aks check-acr.
  • Ingress NGINX retiré ; support Microsoft de l'add-on jusqu'en novembre 2026 ; Gateway API, Application Gateway for Containers.

Web App

  • Private Endpoint = entrant ; VNet integration (+ Route All) = sortant ; vnetImagePullEnabled pour l'ACR privé.
  • HTTP pings : warmup /robots933456.txt, 240 s, WEBSITES_PORT, WEBSITES_CONTAINER_START_TIME_LIMIT (≤ 1 800 s).
  • az webapp log config --docker-container-logging filesystem puis az webapp log tail ; SSH : nslookup, curl -v.

Observabilité

  • Log stream (direct) ; Application Insights (télémétrie) ; LAW (stockage KQL, workspace-based).
  • Tables : AppRequests, AppDependencies, AppServiceHTTPLogs (ScStatus), AppServiceConsoleLogs, KubePodInventory, KubeEvents, ContainerLogV2, AzureDiagnostics (Query.Search, RequestResponse).
  • Grafana : Monitoring Reader, Monitoring Data Reader (Azure Monitor workspace), pods ama-metrics.
  • Langfuse : traces, generations, tokens, coût, sessions, scores, datasets.

Les 3 phrases à placer

  • « Je cherche d'abord ce qui a changé. »
  • « Je suis la requête saut par saut et je corrèle par operation_Id. »
  • « Je lis avant d'agir, et en production j'annonce environnement, commande, impact et retour arrière avant toute action. »

Références#

Relevé du 23/10/2026. Les références détaillées de chaque sujet sont dans les chapitres 01 à 08 ; celles utilisées directement ici :

Sur cette page
Échap

Tape au moins 2 lettres. Plusieurs mots : tous doivent apparaître.