Ne découvrez pas l'examen
le jour J

Réponse : Automatiser autant que possible. / Éliminer les points uniques de défaillance.
Explication : L’automatisation et l’élimination des SPOF sont des pratiques clés pour la robustesse et l’efficacité de l’architecture cloud.

Réponse : AWS Organizations. Explication : AWS Organizations aide à gérer et gouverner de manière centralisée plusieurs comptes AWS sans frais supplémentaires. Les fonctionnalités incluent la facturation consolidée, les stratégies de contrôle des services (SCP) et les unités organisationnelles pour le regroupement des comptes.

Réponse : Amazon EBS.
Explication : Amazon RDS s’appuie sur Amazon EBS pour stocker les données des bases relationnelles, afin d’assurer durabilité et performance.

Réponse : Networking as a Service (NaaS).
Explication : NaaS n’est pas un modèle officiellement reconnu par AWS. Les trois principaux modèles sont IaaS, PaaS et SaaS.

Réponse : B) Télécharger les rapports à partir d'AWS Artifact. AWS Artifact est la ressource centrale pour la documentation de conformité AWS, incluant les rapports SOC, les documents de conformité PCI DSS, les certifications ISO et autres rapports d'audit qui peuvent être téléchargés à la demande sans intervention manuelle.

Réponse : A) Amazon Simple Notification Service (Amazon SNS). Amazon SNS est un service de messagerie pub/sub entièrement géré qui permet d'envoyer des messages (SMS, e-mail, notifications HTTP/S) à de nombreux abonnés simultanément. SNS est idéal pour les notifications d'applications distribuées et offre une architecture découplée et scalable.

Réponse : AWS Service Catalog. AWS Service Catalog permet aux organisations de créer et de gérer des catalogues de services IT approuvés en tant que modèles d'infrastructure as code. Il permet de gouverner les ressources qui peuvent être déployées tout en donnant aux équipes l'accès en libre-service aux configurations approuvées.

Réponse : Automatiser autant que possible et supprimer les points de défaillance unique.
Explication : Automatiser et éliminer les SPOF sont des principes clés d’architecture sur AWS.

Réponse : Bâtir des architectures multi-régions / Utiliser des architectures serverless.
Explication : Bâtir des architectures multi-régions permet d’optimiser la latence et la disponibilité ; le serverless offre une adaptation dynamique à la charge pour la performance.

Réponse : AWS Identity and Access Management.
Explication : IAM permet d’attribuer des rôles, des permissions et de gérer l’accès à tous les services AWS.

Un modèle d’embeddings multi-modaux projette texte et images dans le même espace vectoriel pour des recherches par similarité.

Les bases de données vectorielles (ex. : Amazon OpenSearch Service, Aurora pgvector, Pinecone) stockent les embeddings — représentations numériques de textes sous forme de vecteurs. Dans un pipeline RAG, les documents sont d'abord transformés en embeddings puis stockés. Lors d'une requête, la question de l'utilisateur est aussi transformée en embedding, et une recherche de similarité cosinus identifie les documents les plus pertinents à passer au LLM. Elles ne stockent pas les images directement ni les poids du modèle.

L'IA générative transforme de nombreux processus métier. La génération de résumés automatiques de documents longs (contrats, rapports) réduit le temps d'analyse. Les chatbots intelligents pour le service client répondent de manière contextuelle. La génération de code accélère le développement logiciel. La maintenance prédictive classique ou la détection de fraude reposent généralement sur du ML supervisé, pas sur de la GenAI.

Amazon Q Developer : service IA générant du code avec traçabilité complète des références source et détection automatique des dépendances open source, essentiels pour conformité et sécurité. Contrairement à AWS Chatbot (notifications uniquement), Lambda (exécution sans génération) et CodeCommit (simple dépôt git), Q Developer intègre gestion des licences et gouvernance du code généré.

Pipeline speech-to-insight : Transcribe convertit audio en texte scalablement. Comprehend détecte sentiments/entités rapidement. GenAI via Bedrock interprète intentions complexes, compliance et contexte métier. Architecture en chaîne pour efficacité optimale.

Transfer learning : réutilise des poids pré-entraînés d'un modèle sur données larges, puis affine (fine-tuning) sur votre domaine spécifique. Cela accélère convergence et réduit données nécessaires, contrairement à augmenter les époques (surentraînement) ou l'apprentissage non supervisé (sans labels).

Prompt engineering : technique d'optimisation du style et ton sans coûts additionnels. Les instructions précises (ex.: "réponds avec ton professionnel, 2 phrases max") contrôlent directement la génération. Contrairement au fine-tuning (coûteux) ou à la température (qui ajoute aléatoire), le prompt affinage itératif adapte le comportement du modèle existant efficacement.

Amazon Bedrock avec agents : plateforme entièrement gérée pour orchestrer des modèles de fondation (FM). Les agents IA routent dynamiquement les requêtes, s'intègrent à Lex pour le NLU, et gèrent la scalabilité massive requise pour 10 000 requêtes simultanées.

Amazon Textract : service spécialisé dans l'extraction de texte et de structures (tableaux, formulaires) à partir de documents scannés ou d'images PDF. Essentiel pour le pré-traitement avant RAG, car il convertit les PDFs non-textuels en données exploitables. À différencier : Transcribe traite l'audio, Lex gère les chatbots conversationnels, Personalize optimise les recommandations.

Amazon Textract : service spécialisé dans l'extraction de texte, champs et tableaux à partir de documents scannés ou images PDF. Il utilise la vision par ordinateur pour reconnaître et structurer les données, contrairement à Transcribe (audio→texte), Comprehend (analyse textuelle) et AWS Glue (intégration données). Textract détecte automatiquement les formulaires et tables, idéal pour numériser des documents papier.

Pilier Inspection : Examen régulier des artefacts Scrum et de la progression vers les Objectifs de Sprint afin d'identifier rapidement les écarts. Cela permet une adaptation en temps opportun avant que les problèmes ne s'aggravent. Contrairement aux audits de code ou aux évaluations de performance (centrées sur l'individu), l'inspection met l'accent sur une mesure transparente et empirique du travail et des résultats de l'équipe.

Continuité des Sprints : Les Sprints sont des événements consécutifs limités dans le temps, sans interruption entre eux. Dès qu'un Sprint se termine, le suivant commence immédiatement, assurant ainsi des cycles de livraison continus. Cela élimine les périodes d'inactivité et maintient la dynamique de l'équipe, sans pause pour la planification ou les transitions.

Le Scrum Master comme bouclier : Le Scrum Master supprime activement les obstacles et protège les Développeurs des interruptions externes, leur permettant de maintenir leur concentration et leur flux de travail durant le Sprint. Ce rôle protecteur est essentiel pour assurer un rythme soutenable et l'atteinte du Sprint Goal, distinguant ainsi le servant-leadership d'une simple facilitation passive.

Réponse : Les managers ne sont pas requis lors du Daily Scrum.
Explication : Le Daily Scrum est un événement de la Development Team destiné à la coordination de l'équipe. La présence du management externe n'est pas requise et peut même nuire à la communication ouverte si les membres de l'équipe se sentent observés ou évalués.

La cross-fonctionnalité dans Scrum : L'équipe possède collectivement toutes les compétences nécessaires pour livrer un Increment complet à chaque Sprint, éliminant ainsi les dépendances externes. Cela diffère de l'expertise individuelle multi-domaines ou du travail simultané sur plusieurs projets — il s'agit de la composition de l'équipe, et non des capacités individuelles ou de la répartition de la charge de travail.

L'empirisme affirme que la connaissance vient de l'expérience et que les décisions sont basées sur ce qui est connu. Dans Scrum, l'équipe prend des décisions fondées sur l'observation et l'expérimentation, et non sur des plans prédéfinis ou des hypothèses. Cela contraste avec une approche de processus défini, où l'ensemble du processus peut être planifié et reproduit avec précision. La Transparence, l'Inspection et l'Adaptation sont les trois piliers qui mettent en œuvre le contrôle empirique des processus dans Scrum.

Réponse : Minimiser les dépendances entre les équipes.
Explication : Lorsque plusieurs équipes travaillent à partir du même Product Backlog, la principale préoccupation en matière de coordination est de minimiser les dépendances inter-équipes qui créent des goulots d'étranglement, bloquent le travail et génèrent des difficultés d'intégration.

Taille de l'équipe et complexité des communications : Les Scrum Teams dépassent leur niveau d'efficacité optimal au-delà de 10 membres en raison de la croissance exponentielle du nombre de canaux de communication. Avec n personnes, le nombre de paires de communication possibles est égal à n(n-1)/2, ce qui génère une charge de coordination qui nuit à l'agilité. Les opinions, les réunions et les éléments du Backlog augmentent avec la taille de l'équipe, mais ne sont pas directement à l'origine de cette perte d'efficacité ; la complexité des communications constitue la contrainte fondamentale.

Concept clé : La propriété du Sprint Backlog et l'autorité de modification. Le Sprint Backlog appartient et est géré exclusivement par les Développeurs pendant un Sprint. Bien que les parties prenantes soient des contributeurs essentiels à la valeur du produit et puissent fournir des retours sur le travail en cours, elles n'ont pas d'autorité directe pour modifier le Sprint Backlog. Les parties prenantes influencent le backlog indirectement via le Product Owner, qui priorise les éléments du Product Backlog. Les Développeurs peuvent ajuster les éléments du Sprint Backlog pendant le Sprint (en ajoutant, supprimant ou modifiant des tâches), mais seuls eux prennent ces décisions pour atteindre l'Objectif du Sprint. Cette séparation garantit la transparence, la responsabilité et empêche le glissement de périmètre ou les priorités conflictuelles de perturber l'exécution du Sprint. Les contributions des parties prenantes sont valorisées, mais canalisées à travers des structures de gouvernance appropriées, et non par une manipulation directe du backlog.

Pourquoi cette réponse est correcte : Le Product Backlog est un artefact vivant qui existe pour soutenir le développement continu d'un produit. Selon le Guide Scrum, lorsqu'un produit n'est plus en cours de développement, il n'est plus nécessaire de maintenir un Product Backlog, puisqu'il n'y a plus d'Increments futurs à planifier.

Pourquoi les autres réponses sont incorrectes : Le Scrum Master n'a aucune responsabilité particulière d'archivage du Product Backlog ; le PMO (Project Management Office) n'est pas un concept Scrum et n'a aucun rôle défini dans la gestion des Product Backlogs ; et les éléments du Product Backlog ne sont pas automatiquement transférés vers d'autres produits, car ils sont spécifiques au produit auquel ils se rapportent.

Pourquoi cette réponse est correcte : Le Guide Scrum 2020 stipule explicitement que le Product Owner est responsable de l'ordonnancement du Product Backlog en fonction de facteurs tels que la valeur, le risque, la priorité et les dépendances. Cela garantit que le backlog reflète les objectifs métier et maximise la livraison de valeur.

Pourquoi les autres réponses sont incorrectes : La complexité technique, l'ordre alphabétique et l'ordonnancement par les développeurs ne sont pas alignés avec les principes de Scrum. C'est le Product Owner — et non les Developers — qui est responsable des décisions d'ordonnancement du backlog, et cet ordonnancement doit être guidé par la valeur métier et les priorités stratégiques, et non par des considérations techniques ou administratives.

Le Product Backlog est émergent car il évolue continuellement à mesure que la compréhension du produit et du marché s'améliore — ce n'est pas un document figé créé à l'avance. Il est ordonné par le Product Owner en fonction de la valeur et des priorités, et contient tout ce qui est connu comme nécessaire — et non une spécification complète, ce qui contredirait la nature empirique de Scrum. Les autres options le décrivent à tort comme fixe, entièrement détaillé ou comme un outil d'attribution de tâches, aucune de ces descriptions n'étant conforme à la définition du Product Backlog dans le Scrum Guide en tant qu'artefact dynamique et priorisé.

Pourquoi cette réponse est correcte : Selon le Guide Scrum, la Definition of Done est une description formelle qui établit ce que signifie pour un Increment d'être complet, garantissant qu'il répond aux standards de qualité requis pour le produit. Il s'agit d'une compréhension partagée créée par la Scrum Team qui s'applique à chaque Increment.

Pourquoi les autres réponses sont incorrectes : La Definition of Done n'est pas statique — elle évolue à mesure que l'organisation mûrit et que les standards changent. Ce n'est pas une liste de contrôle personnelle du Product Owner, mais un engagement de l'équipe, et elle s'applique à chaque Increment livré au cours du Sprint, et non uniquement à la release finale.

Le Daily Scrum est un événement de 15 minutes réservé aux Développeurs pour synchroniser leur travail et planifier leurs prochaines 24 heures. Le Product Owner n'a aucun rôle ni responsabilité requis lors de cette cérémonie, bien qu'il puisse y assister en tant qu'observateur s'il y est invité. C'est le Scrum Master qui facilite l'événement, et non le Product Owner, et les mises à jour de statut sont échangées entre les Développeurs, et non rapportées au Product Owner. Les mises à jour du Sprint Backlog et les approbations d'éléments se font en dehors du Daily Scrum, dans le cadre d'une collaboration continue.

Réponse : Faux.
Explication : Chaque Increment doit satisfaire à la Definition of Done et être potentiellement livrable, mais c'est le Product Owner qui décide de le livrer effectivement ou non. La mise en production est une décision métier, et non une obligation du Sprint.

Réponse : Utilisable, conforme au DoD, peut être présenté aux parties prenantes.
Explication : Un Increment peut être partiel, mais il doit être utilisable et satisfaire au DoD. Il n'est pas nécessaire qu'il inclue toutes les fonctionnalités initialement prévues.

Réponse : L'objectif du Sprint devient obsolète, changement majeur de stratégie.
Explication : Un Sprint est annulé uniquement lorsque l'objectif du Sprint n'a plus de valeur — par exemple en raison d'un changement stratégique majeur.

Réponse : L'équipe de développement.
Explication : Le Daily Scrum est organisé par et pour l'équipe de développement. Le Product Owner et le Scrum Master ne sont pas tenus d'y assister, bien qu'ils puissent se joindre à la réunion lorsque cela s'avère utile.

Suivi des performances du projet selon le PMBOK 7e édition : La mesure et le suivi constituent un domaine d'activité fondamental qui repose sur l'observation régulière des écarts entre le plan de base (scope, calendrier, coûts) et l'exécution réelle du projet. Ces écarts permettent au chef de projet d'identifier rapidement les dérives et de déclencher des actions correctives avant que les impacts ne deviennent critiques. Les indicateurs de performance clés (KPI) complètent cette analyse en fournissant des métriques quantifiables telles que l'indice de performance des coûts (IPC), l'indice de performance des délais (IPD), le taux de complétion ou la qualité des livrables. Cette combinaison permet une évaluation objective de la performance. La progression vers les bénéfices attendus, bien que importante, relève davantage du domaine de la Gestion de la valeur et de la livraison (Value Delivery Domain) en fin de projet. Le nombre de pages de rapports et la fréquence des réunions sont des métriques de processus, non de performance projet. Enfin, la satisfaction du sponsor sans ajustement du budget initial ignorerait les réalités du terrain et contredirait le principe d'amélioration continue du PMBOK.

Réponse : Organiser une rétrospective pour identifier les causes de la démotivation et trouver des solutions avec l’équipe.

Accountable : personne responsable ultime du résultat et de la reddition de comptes. Elle rend des comptes à la direction et assume les conséquences des décisions. Distinct d'un "Responsible" (R) qui exécute le travail, et d'un "Approver" qui valide seulement.

Concept clé : L'adaptation (Tailoring) des processus : selon le PMBOK 7e édition, l'adaptation est le processus de sélection, d'interprétation et de personnalisation des pratiques de gestion de projet en fonction des caractéristiques spécifiques du projet, de l'organisation et de l'environnement. C'est un principe fondamental qui reconnaît qu'aucun projet n'est identique et qu'une approche unique ne convient pas à tous les contextes. Pourquoi cette réponse est correcte : L'adaptation permet d'ajuster les pratiques les plus pertinentes pour maximiser la valeur du projet en tenant compte de facteurs tels que la taille du projet, le secteur d'activité, le niveau de complexité, les contraintes organisationnelles et les préférences des parties prenantes. Elle favorise l'équilibre entre la structure nécessaire et la flexibilité requise. Une équipe agile n'aura pas besoin des mêmes processus qu'un projet traditionnel en cascade ; une petite startup ne déploiera pas les mêmes pratiques de gouvernance qu'une grande entreprise. L'adaptation reconnaît la diversité des contextes et optimise l'efficacité opérationnelle. Distinction des autres options : La deuxième option confond adaptation et standardisation bureaucratique—l'

Conformité réglementaire et légale : obligation légale non négociable qui prime sur coût, délais et qualité fonctionnelle. Non-respect = sanctions pénales, responsabilité civile, perte de licences. PMBOK 7 classe ces contraintes externes en risques organisationnels majeurs. Communication n'est qu'un moyen, non une fin.

SPI (Schedule Performance Index) : rapport entre le travail réalisé et le travail prévu (SPI = EV/PV). Un SPI de 0,8 signifie que seuls 80% du travail prévu ont été complétés au moment prévu. Le projet avance donc à 80% de la cadence attendue, indiquant un retard sur le calendrier. Contrairement à une avance (SPI > 1), cette sous-performance confirme un glissement de délai.

Réponse : Faciliter une discussion ouverte pour trouver une solution collaborative. Le rôle du chef de projet est de médiateur.

Le domaine Mesure et Performance du PMBOK 7 : Ce domaine de performance représente l'ensemble des processus permettant de collecter, mesurer et analyser les données de projet pour évaluer l'avancement et les performances. Le suivi de l'avancement par rapport au plan en est l'élément fondamental car il constitue l'activité centrale : comparer continuellement ce qui a été réalisé contre ce qui était planifié (délais, coûts, scope, qualité). Cette comparaison systématique permet au chef de projet d'identifier rapidement les écarts et de déclencher des actions correctives. Les autres options, bien que liées à la gestion de projet, ne correspondent pas à ce domaine spécifique : l'analyse des écarts (option 2) est une technique, non un élément du domaine lui-même ; la communication (option 3) relève du domaine Parties prenantes ; la création de nouveaux livrables (option 4) appartient au domaine Planification ; et la définition du périmètre initial (option 5) relève du domaine Planification également. Le suivi constitue ainsi le cœur du domaine Mesure, car sans cette activité continue de comparaison réel/prévu, aucune mesure de performance réelle n'est possible et aucun contrôle du projet ne peut être exercé efficacement.

Concept clé : La Valeur en Management de Projet : Dans le PMBOK 7e édition, la valeur représente bien plus qu'un simple calcul financier. Il s'agit de l'utilité, l'importance ou le bénéfice généré par le projet pour les parties prenantes et l'organisation. Cette définition holistique reconnaît que la valeur peut être tangible (économique, financière) ou intangible (amélioration de la satisfaction client, renforcement de la marque, capacités organisationnelles accrues, innovation). Le PMBOK 7 met l'accent sur la création de valeur comme objectif central du management de projet, aligné avec la stratégie organisationnelle. La valeur est créée à travers les livrables, les résultats et l'impact du projet sur l'organisation et ses stakeholders. Contrairement à l'ancienne approche focalisée sur les contraintes triple (délai, coût, qualité), le PMBOK 7 place la création de valeur au cœur du succès du projet. Les autres options sont réductrices : la NPV est un outil de calcul parmi d'autres pour évaluer la valeur financière, le ratio budget/livrables mesure l'efficacité opérationnelle uniquement, et la conformité technique ne garantit pas la création de

Transfert du risque : confier la responsabilité d'un risque à un tiers (prestataire, assureur) via contrat. L'externalisation transfère le risque au fournisseur, contrairement à l'atténuation (réduire l'impact) ou l'acceptation (tolérer le risque).

Cette question correspond à l\'objectif d\'apprentissage FL-6.2.1 (K1) - Rappeler les avantages et les risques de l\'automatisation des tests.

● a) Faux → L\'automatisation n\'améliore pas nécessairement la qualité de conception des cas de test, qui dépend davantage des compétences des testeurs.
● b) Correct → Le principal avantage de l\'automatisation des tests de régression est qu\'elle permet d\'exécuter rapidement un grand nombre de tests qui doivent être
répétés fréquemment.
● c) Faux → L\'automatisation des tests ne garantit pas l\'absence de défauts, elle permet seulement de détecter ceux pour lesquels des tests ont été écrits.
● d) Faux → L\'automatisation ne remplace pas complètement les tests manuels, qui restent nécessaires pour certains aspects comme les tests exploratoires

Cette question correspond à l’objectif d’apprentissage FL-4.5.2 (K2) – Classer les différentes options pour la rédaction des critères d’acceptation.
● a) Faux → Bien que la forme Given/When/Then soit très répandue et efficace, il n’existe pas d’obligation stricte dans les projets de test d’acceptation de toujours utiliser ce format.
● b) Correct → format dépend du contexte du projet, du public cible, et de la maturité de l’équipe. Selon la complexité du projet et les habitudes de l’organisation, on peut utiliser plusieurs formats.
● c) Faux → Les critères d’acceptation doivent généralement être élaborés en collaboration avec les parties prenantes clés : Product Owner, utilisateurs métiers, testeurs et développeurs. Se limiter à l’équipe de développement peut conduire à des critères trop techniques ou peu alignés sur les attentes métiers.
● d) Faux → Les critères d’acceptation peuvent effectivement comporter des exigences de performance, mais ils ne se limitent pas à cet aspect. Ils doivent également couvrir la fonctionnalité, la facilité d’utilisation, la sécurité, la fiabilité, etc.

Cette question correspond à l’objectif d’apprentissage FL-3.2.1 (K1) – Identifier les
avantages d’un feedback précoce et fréquent de la part des parties prenantes.

● a) Faux → L’automatisation des tests est indépendante du moment où le feedback est reçu.
● b) Correct → Obtenir des retours rapides des parties prenantes permet d’identifier plus tôt les erreurs, les imprécisions ou les malentendus liés aux exigences ou aux spécifications → cela réduit le coût de correction.
● c) Faux → Le feedback n’a pas pour but de réduire le besoin d’exploration, mais d’améliorer la compréhension dès le début.
● d) Faux → Le retour d’information ne supprime pas les changements, mais facilite leur gestion en les identifiant plus tôt.

Cette question correspond à l\'objectif d\'apprentissage FL-4.1.1 (K2) - Distinguer les techniques de test boîte noire, boîte blanche et basées sur l\'expérience.

● a) Faux → Cette description correspond aux techniques de test boîte blanche, qui examinent la structure interne du code pour concevoir des tests couvrant différents
chemins d\'exécution. Les tests boîte noire ne s\'intéressent pas au code source.
● b) Faux → Cette description correspond aux techniques de test basées sur l\'expérience, qui s\'appuient sur les connaissances et l\'expérience des testeurs pour
identifier les défauts potentiels. Les tests boîte noire sont basés sur des spécifications documentées plutôt que sur l\'expérience seule.
● c) Faux → Cette description correspond également aux techniques de test boîte blanche, qui analysent la structure interne et mesurent la couverture (instructions, branches, chemins). Les tests boîte noire ne s\'intéressent pas à la structure interne.
● d) Correct → Cette description caractérise précisément les techniques de test boîte noire. Ces techniques considèrent le système comme une \"boîte noire\" dont le fonctionnement interne est inconnu ou ignoré. Les cas de test sont dérivés des spécifications, des exigences et des comportements attendus, sans connaissance de l\'implémentation.

Cette question correspond à l’objectif d’apprentissage FL-1.4.3 (K2) – Différencier les composants du testware qui soutiennent les activités de test.
La bonne réponse est a) 1B, 2B, 3C, 4D

● 1A (Faux) → Le cahier des charges appartient à la documentation des exigences, car il définit les attentes des utilisateurs.
● 2B (Correct) → Les spécifications détaillées sont une partie de la documentation
des exigences, car elles précisent les aspects fonctionnels et non fonctionnels.
● 3C (Correct) → Le plan de test appartient à la documentation de test, car il définit la stratégie et l’organisation des tests.
● 4D (Correct) → Le rapport de test fait partie de la documentation des résultats, car il synthétise les observations et les anomalies détectées.

Cette question correspond à l’objectif d’apprentissage FL-3.2.5 (K1) – Rappeler les facteurs qui contribuent à la réussite d\'une revue.

● a) Correct → Impliquer activement les parties prenantes assure une meilleure
qualité des revues et des retours pertinents.
● b) Faux → Encourager la discussion permet d’identifier plus efficacement les problèmes.
● c) Faux → Un modérateur aide à structurer la revue et à maintenir son efficacité.
● d) Faux → Les revues formelles sont aussi importantes que les revues informelles.

Cette question correspond à l’objectif d’apprentissage FL-2.1.2 (K1) – Rappeler les bonnes
pratiques de test applicables à tous les cycles de vie.
● a) Faux → Cela correspond à une approche tardive (type Waterfall rigide), et va àl’encontre des bonnes pratiques modernes.
● b) Faux → Les testeurs doivent être impliqués dès les phases d’analyse et de conception.
● c) Correct → Tester dès que possible (shift-left) est une bonne pratique universelle qui réduit les coûts de détection de défauts.
● d) Faux → Collaboration entre test et développement est essentielle, peu importe le cycle.

Cette question correspond à l\'objectif d\'apprentissage FL-5.1.7 (K2) - Résumer les quadrants du test et leurs relations avec les niveaux et les types de tests.

La bonne réponse est b) :

1. Test d\'accessibilité - Orienté métier, critique du produit (C)
2. Test unitaire - Orienté technologie, support à l\'équipe de développement (A)
3. Test d\'acceptation utilisateur - Orienté métier, critique du produit (C)
4. Test de performance - Orienté technologie, critique du produit (D)
● a) Faux → Le test d\'acceptation utilisateur est en C (orienté métier, critique du produit), pas en B.
● b) Correct → Toutes les correspondances sont correctes.
● c) Faux →- Le test d\'accessibilité est en C, pas en D, et le test de performance est en D, pas en B.
● d) Faux → Le test d\'accessibilité est en C, pas en D, et le test unitaire est en A, pas en B.

Cette question correspond à l’objectif d’apprentissage FL-1.3.1 (K2) – Expliquer les sept principes du test.

● a) Faux → Les tests de régression restent nécessaires tout au long du cycle de vie du logiciel.
● b) Correct → Plus un défaut est détecté tôt, moins il est coûteux à corriger, car il est identifié avant qu’il ne se propage.
● c) Faux → Tester tôt ne garantit pas un produit exempt de défauts.
● d) Faux → Tester tôt ne signifie pas réduire le nombre total de tests nécessaires.

Cette question correspond à l’objectif FL-5.5.1 (K3) – Préparer un rapport de défaut.
● a) Faux → Utile, mais pas bloquant pour comprendre l’erreur.
● b) Correct → Sans résultat attendu, il est impossible de savoir ce qui aurait dû se produire → c’est l’élément clé manquant
● c) Faux → Peu utile dans la reproduction du défaut.
● d) Faux → Intéressant dans certains cas (web), mais pas toujours essentiel

Attaque de l'homme du milieu (MITM) : Un attaquant intercepte la communication entre deux parties afin d'espionner ou d'altérer les données en transit. Cela diffère du hameçonnage (ingénierie sociale), des rançongiciels (chiffrement/extorsion) et du DoS (interruption de service). L'attaque MITM cible spécifiquement la confidentialité des données lors de leur transmission.

La classification des données de santé : la loi HIPAA exige que les informations médicales des patients soient classifiées comme « Sensibles » en raison de leur statut d'informations de santé protégées (PHI), imposant ainsi le chiffrement et des contrôles d'accès. Contrairement à la catégorie « Publique » (sans restriction), « Privée » (personnelle mais non réglementée) ou « Critique » (axée sur la disponibilité des systèmes), la catégorie « Sensible » désigne spécifiquement les données réglementées nécessitant une protection renforcée et des obligations de notification en cas de violation.

Dispersion géographique : distribution des données de sauvegarde sur plusieurs sites physiquement séparés. Les catastrophes naturelles (séismes, inondations, ouragans) affectent généralement des zones localisées ; la dispersion des sites garantit qu'un seul événement ne peut pas détruire toutes les sauvegardes. La diversité des plateformes traite les variations matérielles, les sites de secours actifs permettent un basculement rapide mais n'empêchent pas la perte de données en cas de co-localisation, et l'équilibrage de charge distribue le trafic — aucune de ces options ne protège spécifiquement contre les catastrophes géographiquement localisées.

Une politique de sécurité est un document formel de haut niveau qui définit les objectifs, les attentes et les règles de sécurité d'une organisation. Elle précise ce qui doit être fait (et non comment le faire). Exemples : Politique d'utilisation acceptable, Politique de mots de passe, Politique de classification des données. Les politiques constituent le fondement d'un programme de sécurité de l'information — elles pilotent les procédures, les normes et les directives. Sans politiques, il n'existe aucune référence de base pour mesurer la conformité, rendant impossible l'application des règles et les audits. Les politiques requièrent l'approbation de la direction générale et doivent être communiquées à l'ensemble des employés.

Réponse correcte : Le principe du moindre privilège (Least Privilege) signifie accorder aux utilisateurs uniquement les permissions minimales nécessaires pour accomplir leurs fonctions professionnelles, réduisant ainsi la surface d'attaque et limitant les dégâts en cas de compromission de compte.

Pourquoi les autres réponses sont incorrectes : Accorder tous les droits d'accès d'abord puis les retirer est inefficace et dangereux. Partager des comptes privilégiés entre plusieurs administrateurs viole la responsabilité individuelle et la traçabilité. Utiliser des comptes administrateur pour les activités quotidiennes expose l'organisation à des risques de sécurité majeurs en cas de malveillance ou d'erreur.

Le RTO (Recovery Time Objective) est le délai maximal acceptable pour restaurer une fonction métier ou un système informatique après une interruption. Si le RTO d'une organisation pour une base de données critique est de 4 heures, le plan de reprise après sinistre doit restaurer ce système dans les 4 heures suivant la défaillance. Le RPO (Recovery Point Objective) est la quantité maximale acceptable de perte de données (quelle est l'ancienneté maximale tolérée de la sauvegarde la plus récente). Le RTO oriente les décisions d'infrastructure (serveur de secours à chaud vs. sauvegarde à froid). Un RTO élevé = des solutions moins coûteuses sont acceptables. Un RTO faible = nécessite un basculement à chaud ou une architecture active-active.

Le jailbreaking : le processus de modification du système d'exploitation d'un appareil mobile afin de supprimer les restrictions du fabricant et d'obtenir un accès non autorisé aux fonctions système. Les organisations l'interdisent car il contourne les contrôles de sécurité, permet l'installation de logiciels malveillants et annule la protection de l'appareil. Contrairement au sideloading (installation d'applications en dehors des boutiques officielles), le jailbreaking compromet fondamentalement l'architecture de sécurité du système d'exploitation lui-même.

Sauvegarde et récupération : une sauvegarde est une copie de données stockée séparément de l'original, permettant la restauration après une suppression accidentelle ou une perte de données. Il s'agit du mécanisme principal de récupération des données. Les journaux antivirus détectent les logiciels malveillants mais ne peuvent pas restaurer les fichiers ; le chiffrement protège les données mais ne les récupère pas ; les permissions contrôlent les accès mais ne restaurent pas le contenu supprimé.

Réponse : Non-répudiation.
Explication : La non-répudiation garantit qu'un expéditeur ne peut pas nier avoir envoyé un message. Les signatures numériques assurent la non-répudiation — elles lient cryptographiquement un message à la clé privée de son expéditeur, prouvant ainsi la paternité du message et empêchant tout déni ultérieur.

Un WAF opère au niveau de la couche 7 (couche applicative) et inspecte le trafic HTTP/HTTPS afin de détecter et bloquer les attaques spécifiques au web : injection SQL, XSS (Cross-Site Scripting), CSRF, traversée de répertoires et inclusion de fichiers. Contrairement à un pare-feu traditionnel qui filtre par adresse IP/port, un WAF comprend les protocoles web et peut analyser les paramètres de requêtes, les en-têtes et les corps de messages. Il peut être déployé en mode détection (journalisation uniquement) ou en mode prévention (blocage). Exemples de WAF courants : AWS WAF, ModSecurity, Cloudflare WAF.

Index dans une base relationnelle : structure de données qui organise les valeurs d'une ou plusieurs colonnes pour accélérer la localisation des enregistrements. Sans index, le moteur doit scanner chaque ligne (table scan). Avec un index, il utilise une structure optimisée (arbres B) pour retrouver les données en quelques accès disque seulement, d'où une amélioration drastique de performance. À ne pas confondre avec la suppression de redondance (normalization), l'unicité (contrainte unique) ou la sécurité (transactions ACID).

OLTP vs OLAP : OLTP (Online Transaction Processing) traite des transactions courtes et fréquentes (ventes, paiements) optimisées pour la vitesse. OLAP (Online Analytical Processing) analyse de grands volumes historiques pour le reporting et la décision. OLTP = écriture rapide, OLAP = lecture massive. Contrairement aux idées fausses, OLAP supporte SQL et n'est pas limité à l'IoT.

Azure SQL Database : service PaaS qui offre une base de données relationnelle SQL entièrement managée. Microsoft gère les mises à jour, sauvegardes et haute disponibilité, vous concentrant sur les données. À distinguer de Cosmos DB (NoSQL documentaire), Blob Storage (stockage objet) et Files (partages réseau).

Réponses : Une latence faible est attendue et les données sont traitées au fur et à mesure de leur création. Explication : Le traitement en temps réel traite les données immédiatement au moment où les événements se produisent avec un délai minimal. Contrairement au traitement par lots qui accumule d'abord les données, le traitement en temps réel nécessite une faible latence et l'ingestion et le traitement continus des données.

La clause WHERE : filtre les lignes d'une table selon des conditions spécifiques AVANT le regroupement. Elle s'applique aux enregistrements individuels. À ne pas confondre avec HAVING (filtre après regroupement), ORDER BY (tri des résultats) ou GROUP BY (agrégation de données).

Un index est une structure de données auxiliaire qui accélère les opérations de lecture (SELECT, WHERE) en permettant au moteur SQL de localiser rapidement les lignes sans scanner toute la table. Les index clustered et non-clustered optimisent différents types de requêtes. Inconvénient : les index ralentissent les opérations d'écriture (INSERT, UPDATE, DELETE) car ils doivent être mis à jour à chaque modification. Ils consomment aussi de l'espace disque. Un équilibre entre index de lecture et performance d'écriture est nécessaire.

Power BI : plateforme Microsoft dédiée à la business intelligence, permettant de transformer des données brutes en visualisations interactives et tableaux de bord partageables. Contrairement à Excel (outil bureautique) ou Azure Monitor (surveillance d'infrastructure), Power BI excelle dans l'analyse métier et la décision data-driven en temps réel.

Réponse : Azure SQL Database. Explication : Azure SQL Database est un service de base de données relationnelle PaaS complètement géré, optimisé pour les charges de travail OLTP dans les applications SaaS. Il fournit la mise à l'échelle automatique, la haute disponibilité intégrée et la sécurité sans nécessiter de gestion d'infrastructure.

Réponse : CREATE. Explication : Les instructions DDL (Data Definition Language) définissent et modifient la structure de la base de données : CREATE (créer des objets), ALTER (modifier des objets), DROP (supprimer des objets), TRUNCATE (vider des tables). CREATE est un exemple classique de DDL — il crée des objets de base de données comme les tables, les vues et les index.

Réponse : Il y a un délai notable entre l'ingestion des données et l'obtention des résultats. Explication : Le traitement par lots collecte les données sur une période et les traite en groupe selon des intervalles planifiés. Cela introduit intrinsèquement une latence — les résultats ne sont disponibles qu'après l'exécution du lot, ce qui le rend inadapté aux exigences en temps réel.

Réponse : Vrai
Le Journal Universel (ACDOCA) est la pierre angulaire de S/4HANA Finance. Il centralise FI, CO et AA dans une seule table, éliminant la réconciliation entre les anciens tableaux BSEG, COEP et ANEK. Cela garantit la cohérence des données en temps réel.

Réponse : Ils reçoivent automatiquement les écritures miroir des sous-comptes BP ; Les écritures directes sont interdites ; La modification du compte de réconciliation en production doit suivre une procédure contrôlée.
Explication : Les comptes de réconciliation assurent l’intégrité entre sous-comptes et GL ; tout changement requiert précautions (soldes/postes).

Dans S/4HANA, l'intégration FI-AA est totale : chaque transaction d'actif (acquisition, cession, amortissement) génère simultanément un document d'immobilisation (dans le sous-module AA) ET un document comptable FI avec les écritures sur les comptes de bilan. Il n'y a plus de réconciliation périodique nécessaire comme en ECC — les deux modules sont synchronisés en temps réel. Le document d'immobilisation contient les données spécifiques (zone d'évaluation, clé d'amortissement) ; le document FI contient les imputations comptables.

Réponse : Assignez un ordre interne réel dans les données de base d'immobilisation et réglez périodiquement à deux centres de coûts. Explication : Pour répartir les coûts d'amortissement à plusieurs centres de coûts, utilisez un ordre interne comme collecteur intermédiaire dans les données de base d'immobilisation. L'ordre interne est ensuite réglé périodiquement à l'aide de règles de distribution pour allouer les coûts à chaque centre de coûts.

Réponse : Core Data Services
Explication : Les vues CDS définissent sémantique, associations et annotations (UI/analytique) consommées par Fiori et l’analytique embarquée.

Réponse : ACDOCA
En SAP S/4HANA, la table ACDOCA (Universal Journal Entry Line Items) est la table centrale qui stocke toutes les écritures comptables FI, CO et AA dans un enregistrement unique. Elle élimine les redondances entre les anciens modules séparés (FI : BSEG, CO : COEP, AA : ANEK).

Réponse : Les comptes sont gérés dans BAM et assignés aux sociétés
Le Bank Account Management (BAM) dans S/4HANA centralise la gestion des comptes bancaires de l'entreprise. Les comptes sont créés dans BAM et assignés aux codes société pour être utilisés dans le programme de paiement F110 et le rapprochement bancaire.

Réponse : Tolérances + reason codes + comptes d'écart configurés
La gestion des écarts de paiement AR nécessite : (1) la configuration des groupes de tolérance, (2) l'affectation de reason codes aux écarts (ex. escompte non déduit, litige), et (3) la définition des comptes G/L cibles pour comptabiliser automatiquement les différences. Transaction : OBA3, OB57.

Réponse : Modèles de listes de tâches ; Dépendances et jalons ; Assignation d’organisations et de rôles ; Suivi d’exécution et journalisation.
Explication : Le FCC industrialise la planification et l’exécution de la clôture avec traçabilité.

Réponse : Un acompte (down payment).
Explication : Les transactions spéciales incluent acomptes, garanties, lettres de crédit, etc., traitées via des indicateurs spécifiques.

Concept clé : Test d'attaques adversariales. Les exemples adversariaux sont des entrées soigneusement conçues qui trompent les modèles AI malgré des perturbations imperceptibles pour l'humain. Les testeurs de sécurité doivent valider la robustesse en tentant de générer des entrées adversariales et en vérifiant la résilience du système face à de telles manipulations.

Concept clé : Détection des biais dans les données d'entraînement. L'analyse de parité démographique évalue si les résultats du modèle sont équitables entre les groupes démographiques. L'échantillonnage stratifié garantit la représentation de tous les attributs protégés, permettant aux testeurs d'identifier les problèmes d'équité avant le déploiement.

Concept clé : Surveillance humaine dans l'éthique de l'AI. Les systèmes human-in-the-loop maintiennent la responsabilité et permettent l'intervention lorsque les décisions de l'AI pourraient causer du tort. Les tests doivent vérifier que les mécanismes de surveillance fonctionnent correctement et que les humains peuvent examiner et contester de manière significative les décisions avant qu'elles n'affectent les parties prenantes.

Réponse : Le système de valeur des services.
Explication : Le système de valeur des services (SVS) est le concept ITIL 4 qui décrit comment tous les composants et activités, y compris la gouvernance, fonctionnent ensemble pour créer de la valeur.

Réponse : Tout changement d\'état significatif pour la gestion d\'un service ou de tout autre élément de configuration.
Explication : Un événement est tout changement d\'état significatif pour la gestion d\'un service ou d\'un élément de configuration. Les événements peuvent déclencher des incidents, des problèmes ou des demandes.

Réponse : S\'assurer que les fournisseurs de l\'organisation et leurs performances sont gérés de manière appropriée afin de supporter l\'approvisionnement continu de produits et services de qualité.
Explication : La gestion des fournisseurs assure que les relations avec les fournisseurs externes sont correctement gérées pour garantir un approvisionnement continu en produits et services de qualité.

Réponse : Le centre de services.
Explication : Le centre de services est le point d\'entrée unique pour les utilisateurs. Il inclut la classification et la propriété de toutes les questions et demandes, qu\'il redirige vers les équipes appropriées.

Réponse : Il devrait y avoir au moins une petite équipe qui se consacre à la conduite des efforts d\'\"amélioration continue\".
Explication : ITIL 4 recommande qu\'une équipe dédiée, même réduite, pilote les efforts d\'amélioration continue pour maintenir le focus et la cohérence, sans que cela n\'empêche toute l\'organisation d\'y contribuer.

Réponse : Offre de service.
Explication : Une offre de service est un ensemble de produits et services proposé à un consommateur. Le package (ordinateur + logiciels + licences + support) constitue une offre de service complète et packagée.

Réponse : L\'amélioration continue.
Explication : L\'amélioration continue est la responsabilité de chacun dans l\'organisation, pas seulement d\'une équipe dédiée. Chaque employé doit contribuer à l\'identification et à la mise en oeuvre des améliorations.

Réponse : Progresser par itérations avec des retours.
Explication : Le principe \'Progresser par itérations avec des retours\' recommande de diviser le travail en petites étapes gérables avec des boucles de feedback fréquentes pour s\'adapter et corriger rapidement.

Réponse : Les coûts supprimés par le service et les coûts imposés par le service.
Explication : Le consommateur d\'un service doit évaluer les coûts supprimés (ce qu\'il n\'a plus à gérer) et les coûts imposés (ce qu\'il doit payer), pour déterminer si la valeur nette est positive.

Réponse : Pour planifier les changements et éviter les conflits.
Explication : Le calendrier des changements sert principalement à planifier les changements et à prévenir les conflits entre eux, en offrant une vue consolidée de tous les changements prévus.

• Reminder (Rappel) permet d’envoyer une notification à une heure précise, même si l’application n’est pas ouverte.

• C’est la fonctionnalité qui déclenche une alerte automatique à 8h chaque matin.

  🎯 À retenir pour l’examen MS-900 :

  • Reminder = notification à une heure précise

  • Recurrence = répétition de la tâche

  • Les deux peuvent être combinés, mais pour recevoir une alerte à 8h, il faut activer le rappel.

L’application mobile OneDrive permet :

• D’accéder aux fichiers sur tablette et smartphone

• De rendre certains fichiers ou dossiers disponibles hors ligne

• De minimiser le stockage local, car seuls les fichiers sélectionnés sont téléchargés pour un accès hors ligne, le reste reste dans le cloud.

  🎯 À retenir pour l’examen MS-900 :

  • OneDrive mobile app + disponibilité hors ligne = accès aux fichiers sur appareils mobiles même sans connexion, avec stockage local limité.

  • Les autres solutions (navigateur, WebDAV, laptop) ne répondent pas au besoin mobile hors ligne.

• Monthly Enterprise Channel (canal mensuel pour entreprises) :

  • Fournit les mises à jour de fonctionnalités mensuelles dès qu’elles sont disponibles pour le grand public.

  • Convient aux organisations qui veulent un équilibre entre rapidité et stabilité.

• Ce canal est idéal pour déployer rapidement de nouvelles fonctionnalités aux groupes pilotes ou à certaines machines, sans attendre les canaux plus longs comme le Semi-Annual Channel.

  🎯 À retenir pour l’examen MS-900 :

  • Monthly Enterprise Channel = mises à jour mensuelles officielles pour entreprises, avec déploiement rapide

  • Semi-Annual Channel = déploiement lent, deux fois par an

  • Insider / Default Channel = pas adapté pour un déploiement contrôlé en entreprise

• La section Token Usage :

  • Montre le nombre total de tokens AI utilisés par votre organisation sur une période donnée.

  • Permet de suivre l’utilisation et estimer les coûts liés à l’usage de Copilot.

• Les autres sections ne fournissent pas cette information :

  • User Engagement → suit l’activité des utilisateurs avec Copilot.

  • Prompt Library → contient les prompts enregistrés et réutilisables.

  • Security Insights → fournit des informations de sécurité et de conformité.

    🎯 À retenir pour l’examen MS-900 :

    • Token Usage = suivi de la consommation de tokens et des coûts Copilot

    • Les autres sections se concentrent sur activité utilisateur, sécurité ou prompts.

• Rédiger avec Copilot permet de :

  • Analyser le message précédent

  • Générer automatiquement un email de réponse ou de refus poli

  • Accélérer la rédaction tout en restant professionnel

• Les autres options n’impliquent pas Copilot :

  • Réponse rapide → simplement un raccourci pour répondre rapidement

  • Focused Inbox → organise les emails, ne rédige rien

  • Schedule Send → planifie l’envoi, ne crée pas de contenu

    🎯 À retenir pour l’examen MS-900 :

    • Copilot dans Outlook = générer des brouillons intelligents basés sur le contexte du message

    • Tout ce qui est filtre, calendrier ou planification n’utilise pas Copilot.

Dans Microsoft Lists, la mise en forme de colonne (Column formatting) permet d’appliquer un style visuel conditionnel à une colonne spécifique.

👉 Elle permet notamment :

• De modifier la couleur d’arrière-plan

• De changer la couleur du texte

• D’ajouter des icônes

• D’appliquer des règles conditionnelles (ex : si la valeur < seuil → fond rouge)

Cette fonctionnalité utilise du JSON en arrière-plan, mais du point de vue fonctionnel, la capacité recherchée est bien la mise en forme de colonne.

• Dans un environnement hybride, vous continuez à utiliser votre infrastructure locale (CapEx) pour certains services ou serveurs AD.

• En parallèle, vous payez des abonnements cloud Azure AD Premium et éventuellement des services de synchronisation de données, ce qui constitue des dépenses d’exploitation (OpEx).

• Les autres options sont incorrectes :

  • A : Faux, le CapEx sur site reste nécessaire.

  • B : Faux, ce n’est pas un double paiement intégral.

  • C : Faux, l’utilisation d’Azure AD introduit bien des coûts OpEx.

• La Timeline view (vue Chronologie) permet :

  • D’afficher les tâches ou phases sur une ligne de temps

  • De visualiser clairement les dates de début et de fin

  • D’avoir une vue simple et synthétique adaptée à un partage dans Teams

Elle est idéale pour donner une vue globale rapide du projet.

❌ Pourquoi les autres réponses sont incorrectes :

• A. Gantt Chart view → Plus détaillée et orientée gestion avancée (dépendances, planification complexe). Moins “simple” pour un aperçu rapide.

• B. Project Roadmap → Sert à consolider plusieurs projets, pas juste à afficher un planning simple d’un projet.

• D. Calendar view → Affiche les tâches par date dans un calendrier, mais ne donne pas une vision linéaire claire des phases.

🎯 À retenir pour l’examen MS-900 :

• Timeline view = vue simple et visuelle des dates de début et fin

• Gantt = gestion avancée

• Calendar = vue mensuelle/journalière
  Roadmap = consolidation multi-projets
  
  

• Avec le group-based licensing, les licences sont attribuées automatiquement via l’appartenance au groupe.

• Dès que l’utilisateur est retiré du groupe :

  • Les licences liées sont révoquées automatiquement

  • L’utilisateur perd l’accès aux services correspondant à ces licences

• Les autres options sont incorrectes :

  • A : Faux, la licence ne reste pas après suppression du groupe.

  • C : Faux, l’utilisateur peut se connecter à Microsoft 365 si d’autres licences sont présentes.

  • D : Faux, l’utilisateur n’est pas transformé en boîte aux lettres partagée automatiquement.

Dans Exchange Online, Microsoft assure automatiquement :

• La haute disponibilité (High Availability) grâce à la réplication native des bases de données de boîtes aux lettres entre plusieurs serveurs et centres de données.

• La reprise après sinistre (Disaster Recovery) grâce à l’architecture distribuée et redondante de Microsoft 365.

Pour répondre aux exigences réglementaires de conservation :

• Litigation Hold permet de conserver les e-mails d’une boîte aux lettres, même s’ils sont supprimés par l’utilisateur.

• Cela garantit l’intégrité et la disponibilité des données à des fins légales ou réglementaires.

👉 Ensemble, ces fonctionnalités assurent la disponibilité continue et la conservation réglementaire des données.

• Objectif d’un tabletop exercise :

  • Identifier lacunes dans les procédures, rôles et responsabilités

  • Former les parties prenantes à la coordination et aux étapes critiques

• Observation : les chemins d’escalade ne sont pas clairs

  • Correctif immédiat = mettre à jour la documentation BCDR

  • Validation = planifier un nouvel exercice pour s’assurer que tous comprennent les procédures

• Cette approche :

  • Est non intrusive, sécurisée et pédagogique

  • Permet de corriger les processus sans risquer les systèmes en production

Pour respecter PCI DSS (chiffrement des données au repos et en transit) :

• Azure Policy permet de :

  • Définir des règles obligatoires pour le chiffrement au repos (ex. Storage Service Encryption, SQL TDE)

  • Définir des règles pour le chiffrement en transit (ex. TLS obligatoire pour les services)

  • Appliquer ces règles à toutes les ressources Azure via des initiatives intégrées ou personnalisées

  • Auditer la conformité et générer des rapports

• Initiatives intégrées : Microsoft propose des initiatives prêtes à l’emploi pour le chiffrement et la sécurité des données, alignées avec PCI DSS, NIST et autres standards.

• Microsoft recommande pour les workloads AKS exposés aux APIs :

  • Multi-layer defense : défense en profondeur (defense-in-depth)

  • Azure Firewall pour contrôler le trafic réseau entrant/sortant

  • DDoS Protection Standard pour se protéger contre les attaques volumétriques sur le réseau

  • Application Gateway WAF pour inspecter et protéger les APIs contre :

    • SQL injection

    • Cross-site scripting

    • Autres attaques applicatives

• Cette approche est la baseline de sécurité recommandée pour AKS exposé à Internet.

• MCAS / Defender for Cloud Apps :

  • Fournit visibilité complète sur les applications SaaS connectées à Entra ID

  • Identifie les applications non approuvées ou risquées

  • Permet de :

    • Appliquer des politiques d’accès

    • Restreindre ou contrôler l’usage des applications

    • Surveiller les activités et détecter les risques liés aux utilisateurs et aux sessions

• C’est la solution Microsoft recommandée pour le Shadow IT et la gouvernance SaaS.

• Business Impact Analysis (BIA) classe les risques en fonction de :

  • L’impact financier, réglementaire et opérationnel

  • La criticité des actifs pour le fonctionnement de l’organisation

• Dans cet exemple :

  • La divulgation des EHR entraîne des amendes HIPAA jusqu’à 2M$ → impact financier élevé et conformité critique

  • Une simple interruption n’a pas le même impact → faible perte opérationnelle

• Donc, pour la menace de divulgation, l’impact est élevé (High Business Impact)

L’exigence clé est :
✔ Reporting cohérent
✔ Multi-cloud (Azure, AWS, GCP)
✔ Outil déjà en place : Microsoft Sentinel

Microsoft Sentinel est un SIEM/SOAR cloud-native capable d’ingérer des logs provenant de multiples environnements (Azure, AWS, GCP, on-premises).

En configurant :

• L’ingestion des journaux d’audit de sauvegarde (backup audit logs)

• Azure Monitor comme couche de collecte

• Des workbooks / dashboards unifiés dans Sentinel

👉 L’entreprise obtient une vision centralisée et normalisée de la conformité des sauvegardes sur tous les clouds, sans migration complexe.

Cela correspond parfaitement à une approche Zero Trust et multi-cloud moderne, attendue au niveau SC-100.

• Microsoft Entra Internet Access (EIA) : solution SSE qui fournit :

  • Filtrage d’accès Internet

  • Protection contre les applications non approuvées

  • Application des politiques d’usage acceptable

• Intégration avec Microsoft Defender for Cloud Apps :

  • Permet de détecter et contrôler l’usage des applications SaaS

  • Active les politiques Conditional Access pour :

    • Bloquer les connexions à des applications non sanctionnées

    • Appliquer des restrictions ou des alertes pour les applications approuvées

  • Assure visibilité, contrôle et gouvernance centralisée

• C’est la meilleure pratique Microsoft SSE pour sécuriser l’accès SaaS et Internet.

• Microsoft Sentinel Playbooks (basés sur Logic Apps) permettent de :

  • Automatiser la réponse aux incidents (SOAR – Security Orchestration, Automation, and Response)

  • Déclencher des workflows de restauration depuis les backups dès qu’un incident est détecté

  • Réagir rapidement et de manière cohérente face à un ransomware

• Cela offre un processus automatique de containment et de récupération, exactement ce que demande le SOC.

Les comptes break-glass sont des comptes d’accès d’urgence utilisés uniquement lorsque :

• L’authentification normale est indisponible

• Les mécanismes MFA ou Conditional Access sont défaillants

• L’environnement est compromis (ex. attaque ransomware)

Les bonnes pratiques Microsoft recommandent :

• 🔐 Identifiants stockés dans un coffre-fort sécurisé hors ligne

• 🔄 Validation régulière (tests d’accès contrôlés)

• 🚨 Surveillance renforcée

• 🔒 Utilisation uniquement en cas d’urgence

Pourquoi hors ligne ?

En cas de ransomware ou compromission massive :

• Les systèmes en ligne (y compris SIEM) peuvent être impactés.

• Le coffre-fort hors ligne réduit le risque de compromission.

Azure Key Vault est un composant critique pour la sécurité :

• Il stocke des clés cryptographiques, certificats et secrets essentiels pour le chiffrement des données et la sécurité des transactions.

• Le vecteur de menace le plus critique est l’accès non autorisé :

  • Si un attaquant obtient l’accès à Key Vault, il peut récupérer les clés et décrypter les données sensibles ou signer des transactions frauduleuses.

• La protection contre ce vecteur repose sur :

  • Des politiques d’accès strictes (RBAC ou policies Key Vault)

  • L’activation de Azure AD Conditional Access

  • L’utilisation du principle du moindre privilège

Un Deployment Kubernetes par microservice permet de gérer indépendamment le cycle de vie, les réplicas et l'autoscaling de chaque microservice. Les Deployments sont le standard Kubernetes pour les applications sans état qui nécessitent un scaling individuel.

Le rôle roles/logging.privateLogViewer inclut l'accès aux journaux d'audit d'administration ET aux journaux d'accès aux données. Diriger l'auditeur vers les journaux de modifications IAM compète la vue complète. Pas besoin d'export — l'accès direct suffit.

La section IAM dans la console GCP affiche tous les membres (utilisateurs, groupes, comptes de service) et leurs rôles attribués dans le projet. gcloud iam roles list affiche les rôles disponibles, pas les attributions. gcloud iam service-accounts list ne montre que les comptes de service.

Les journaux d'audit d'accès aux données enregistrent qui a lu, modifié ou supprimé des données. En filtrant par email de l'utilisateur comme principal, on peut voir tous ses accès aux données sensibles. Les journaux d'activité Admin n'enregistrent pas les lectures de données.

Dans GCP, les règles de pare-feu s'appliquent par ordre de priorité (lower = higher priority). Une règle deny-all basse priorité (65534) bloque tout par défaut, et une règle allow haute priorité (1000) ouvre uniquement les ports nécessaires — principe du moindre accès.

Le calculateur de prix GCP est l'outil officiel pour estimer les coûts mensuels sans provisionner réellement les ressources. Examiner les pages de tarification garantit d'utiliser les prix actuels et exacts pour chaque produit.

Un job d'export Cloud SQL (planifié le premier du mois) écrit un fichier SQL/CSV dans Cloud Storage Archive — la classe la moins chère pour des données conservées 3 ans avec accès très rare. Les sauvegardes automatiques Cloud SQL ne peuvent pas être conservées 3 ans.

Les bonnes pratiques Google recommandent d'utiliser des groupes plutôt que des comptes individuels et des rôles prédéfinis plutôt que des rôles personnalisés quand ils répondent au besoin. logging.viewer + bigQuery.dataViewer couvrent exactement les besoins d'audit.

Une métrique personnalisée basée sur les journaux compte les occurrences de l'erreur spécifique. Couplée à une politique d'alerte, elle déclenche une notification automatique si l'erreur réapparaît. C'est la solution proactive recommandée.

La combinaison Service NodePort + Ingress est la méthode recommandée pour exposer une application GKE en HTTPS via un Cloud Load Balancer. L'Ingress gère le certificat SSL/TLS et l'IP publique. ClusterIP n'est accessible qu'en interne au cluster.

La bonne réponse (option 2) identifie que le manque de transparence du Scrum Master et du Product Owner, combiné au désengagement des parties prenantes lors des Sprint Reviews, a conduit à des attentes mal alignées. Le pilier de transparence de Scrum exige une inspection régulière par les parties prenantes lors des Sprint Reviews. Les autres options attribuent incorrectement les responsabilités ou se concentrent sur des facteurs non pertinents tels que la vélocité ou les diagrammes de Gantt.

Réponse correcte : Faux. Le Guide Scrum exige un Incrément unique et intégré à la fin de chaque Sprint, même dans les environnements à grande échelle. Des branches séparées par équipe nuisent à cette transparence et créent un risque d'intégration. Chaque équipe doit œuvrer à la réalisation d'un seul Incrément livrable qui démontre une progression continue vers l'objectif du produit.

Correct : Option 2 - L'ajout d'une deuxième équipe entraîne généralement une baisse initiale de la vélocité de l'équipe d'origine, en raison de la surcharge de communication accrue, du changement de contexte et de la complexité de coordination liée à l'intégration avec la nouvelle équipe. La vélocité mesure la capacité de l'équipe, qui est souvent mise à rude épreuve par les effets du passage à l'échelle avant que des améliorations ne se manifestent.

L'option B est correcte. Le Scrum Master doit accompagner le Product Owner en lui expliquant que l'empirisme et l'émergence sont au cœur de Scrum ; la complexité rend toute prévision parfaite impossible. Les nouveaux apprentissages réalisés durant le Sprint affectent naturellement le Sprint Backlog. L'option A démotive l'équipe par une pression irréaliste, l'option C est défensive et ignore les préoccupations des parties prenantes, et l'option D enfreint le principe selon lequel l'ajout de personnes en cours de Sprint réduit la productivité et ne résout pas les problèmes de fond.

Pour aider une nouvelle Scrum Team à démarrer efficacement, le Scrum Master doit se concentrer sur la présentation de l'équipe, la connaissance du produit et l'établissement de la Definition of Done. L'option 1 est incorrecte car la compatibilité des personnalités et les systèmes de récompenses ne relèvent pas des responsabilités du Scrum Master ; l'équipe s'auto-organise en fonction des compétences et de l'engagement envers les valeurs Scrum.

Cette affirmation est Vraie. La dette technique s'accumule avec le temps — les raccourcis accumulés et les mauvais choix de conception rendent les évolutions futures de plus en plus difficiles et coûteuses. Cela ralentit la vélocité et va à l'encontre d'un rythme soutenable, l'un des principes fondamentaux de Scrum.

Correct : Options 2, 3 et 5 - La Definition of Done guide la prévision, fournit une orientation en temps réel pendant le développement, et crée de la transparence lors de la Sprint Review concernant ce que « terminé » signifie réellement. L'option 1 la traite comme un outil de suivi de l'avancement (usage incorrect) ; l'option 4 contredit l'objectif de compléter le travail à chaque Sprint ; l'option 6 confond la Definition of Done avec la durée du Sprint.

Réponses correctes : Options 2 et 4. L'option 2 explique correctement que les time-boxes permettent à ceux qui sont au plus près des problèmes de prendre les meilleures décisions dans les contraintes imposées — un principe fondamental de l'auto-organisation. L'option 4 montre correctement que les time-boxes alignent la concentration et la compréhension partagée au sein de l'équipe. L'option 1 confond engagement et contrainte, et l'option 3 représente de manière erronée le rôle du time-boxing dans la planification prévisionnelle.

Réponses correctes : Options 2 et 4. L'option 2 identifie correctement l'auto-organisation : la créativité et l'exploration s'épanouissent lorsque les équipes s'approprient les décisions. L'option 4 illustre correctement l'auto-organisation : les équipes résolvent leurs conflits internes sans intervention externe, maintenant ainsi leur dynamique. L'option 1 reflète un management de type commande-et-contrôle, et non l'auto-organisation. L'option 3 est incomplète — savoir quoi faire est nécessaire mais pas suffisant pour une véritable auto-organisation.

Lorsque plusieurs Scrum Teams travaillent à partir d'un Product Backlog partagé, la coordination s'effectue par auto-organisation et concertation, et non par une assignation descendante. Les équipes doivent sélectionner le travail en collaboration avec le Product Owner et entre elles, en respectant les capacités et les dépendances. Les autres options vont à l'encontre de l'accent mis par Scrum sur l'auto-organisation des équipes et l'autorité du Product Owner sur l'ordre du backlog.

Réponse : Portabilité.
Explication : C est correct car la portabilité est un attribut non-fonctionnel de faible priorité pour un système de surveillance médicale critique pour la sécurité, normalement lié à des piles matériel/système d\'exploitation certifiées. La disponibilité, la sécurité et la fiabilité ont un impact direct sur le risque patient et les preuves réglementaires.

Réponse : Les critères d\'entrée et de sortie sont un moyen principal d\'obtenir des ressources adéquates..
Explication : C est correct car les critères d\'entrée et de sortie sont des portes de qualité objectives pour les transitions de niveau et la prise de décision, non des mécanismes destinés à sécuriser les ressources. Ils spécifient des conditions mesurables soutenant les décisions arrêt/go et protègent les activités en aval.

Réponse : Créer une estimation basée sur la technique d\'analyse de points de fonction et l\'analyse de points de test.
Explication : La réponse A est correcte car l\'analyse de points de fonction combinée à l\'analyse de points de test produit une estimation précoce basée sur la taille, spécifique aux tests, indépendante de la disponibilité du code source. L\'APF fournit une métrique de taille fonctionnelle, l\'APT traduit cette taille en effort de test en appliquant les facteurs de testabilité et de qualité.

Réponse : La qualité de l\'estimation du développement peut être médiocre. / Utiliser le même pourcentage chaque fois ne tient pas compte du niveau de risque de l\'application à tester. / La maturité de l\'organisation, par exemple la qualité de la base de test, la qualité des tests de développement, la gestion de configuration, la disponibilité des outils de test, influencent également l\'effort requis pour le test..
Explication : Les réponses A, D et E désignent des sources distinctes de variance qu\'un simple pourcentage du développement ne peut pas capturer. A: les estimations de développement peuvent être inexactes, propageant l\'erreur d\'estimation. D: un pourcentage fixe ignore le risque spécifique, la criticité métier et les profils d\'impact des défauts. E: la maturité organisationnelle (qualité de la base de test, tests unitaires du développement, gestion de configuration, outils disponibles) influence directement l\'effort de test.

Réponse : Pourcentage de couverture des exigences.
Explication : B est correct car le pourcentage de couverture des exigences quantifie directement l\'adéquation des tests par rapport à l\'objectif déclaré de valider que le système satisfait ses exigences. L\'efficacité du test dans un contexte piloté par les exigences repose sur la mesure objective de la complétude de la couverture des exigences et de la détection des non-conformités.

Réponse : Une approche des tests de régression.
Explication : Le plan directeur de test est un document stratégique de haut niveau qui définit l\'approche globale, la portée, les objectifs et les risques. L\'approche des tests de régression est une décision stratégique appropriée à couvrir en détail, contrairement aux détails tactiques comme les valeurs limites ou l\'organisation des cas de test.

Réponse : Les préoccupations concernant l\'interface utilisateur augmentent la probabilité d\'un risque dans ce domaine et augmentent la quantité d\'effort de test nécessaire pour l\'interface utilisateur, limitant ainsi l\'effort de test disponible pour d\'autres parties de l\'outil de gestion de test..
Explication : L\'option B est correcte car elle modifie explicitement à la fois la probabilité évaluée et l\'impact basé sur les ressources (couverture de test), ce qui altère l\'exposition au risque produit et force une réévaluation des priorités. Le risque augmente (probabilité × conséquence) avec la réallocation des ressources.

Réponse : Organiser une réunion avec la direction générale pour qu\'elle aborde l\'importance d\'une bonne qualité de test pour ce projet.
Explication : D est correct car l\'appui visible de la direction générale élève la priorité organisationnelle des tests, fournit une reconnaissance et supprime les obstacles systémiques. Cela augmente la signification de la tâche et aligne l\'effort individuel avec les objectifs organisationnels, motivant durablement l\'équipe.

Réponse : Exécution des tests.
Explication : L\'exécution des tests représente la portion la plus importante et la moins prévisible de la variabilité (taux de découverte de défauts, disponibilité de l\'environnement, productivité humaine, boucles de rework). C\'est donc la partie la plus difficile à estimer.

Réponse : Gestion et pilotage de projet.
Explication : B est correct car la gestion et le pilotage de projet sont des préoccupations transversales à tous les cycles de vie, non spécifiques au test en RAD. Les attributs distinctifs du RAD—prototypage itératif, exigences évolutives, délais serrés—créent des problèmes centrés sur le test : exigences instables, régressions fréquentes, cycles de test compressés.

A. Définir la température à 0 pour éliminer la variabilité des sorties et garantir un formatage cohérent — Incorrect. Cela réduit l'aléatoire mais ne corrige pas les erreurs d'extraction systématiques comme la mauvaise interprétation des plages (« 2 à 3 »). B. Envoyer une requête de suivi incluant l'erreur de validation, en demandant au modèle de corriger sa sortie — Correct. Fournir un retour de validation précis permet au modèle de corriger le problème exact (par exemple, convertir « 2 à 3 » en un nombre flottant valide), rendant la récupération très efficace. C. Pré-traiter les documents sources pour standardiser les formats problématiques avant de les envoyer à l'extraction — Incorrect. Utile dans certains cas, mais pas évolutif ni suffisant pour gérer la diversité des variations du monde réel. D. Mettre en place un pipeline secondaire utilisant un modèle de niveau supérieur pour retraiter les documents qui échouent à la validation — Incorrect. Plus coûteux et inutile — la correction ciblée est plus efficace et plus performante.

A. Des descriptions de paramètres claires expliquant le format attendu, par exemple « user_id : UUID de l'utilisateur à mettre à jour (obligatoire) » — Correct. Des descriptions claires et lisibles sont le facteur le plus important pour aider Claude à comprendre quelles valeurs fournir et comment les paramètres doivent être structurés. B. Des noms de paramètres verbeux encodant des indications de format, comme user_id_string_uuid_format — Incorrect. Des noms excessivement verbeux réduisent la lisibilité et sont moins efficaces que des descriptions appropriées. C. Des contraintes de type JSON Schema strictes marquant user_id comme obligatoire et définissant fields_to_update comme type objet — Incorrect. Les contraintes de schéma facilitent la validation, mais n'expliquent pas suffisamment les attentes sémantiques comme le format UUID requis. D. Des réponses d'erreur détaillées expliquant pourquoi des valeurs de paramètres invalides ont été rejetées — Incorrect. Utiles après un échec, mais pas le facteur le plus critique pour prévenir les erreurs en amont.

A. La fenêtre de contexte du modèle a été dépassée par la longueur de la conversation — Incorrect. Cela ne se produirait que lors de conversations très longues, alors que le problème apparaît dès les premiers échanges. B. L'API Claude nécessite un paramètre session_id que vous n'avez pas configuré — Incorrect. Il n'existe pas de session_id obligatoire ; le contexte doit être géré explicitement par l'application. C. Claude nécessite une connexion à une base de données vectorielle pour maintenir la mémoire de la conversation — Incorrect. Une base de données vectorielle est optionnelle pour la récupération d'informations, elle n'est pas requise pour la mémoire conversationnelle de base. D. Votre application n'inclut pas les messages précédents dans le tableau messages — Correct. Claude ne conserve aucune mémoire entre les appels ; si les messages précédents ne sont pas inclus, il ne peut pas se souvenir des préférences exprimées antérieurement par l'utilisateur.

A. Enregistrer l'erreur côté serveur et retourner un résultat vide pour ne pas perturber le modèle — Incorrect. Cela masque les informations critiques sur l'échec, rendant impossible pour l'agent de distinguer « aucune donnée » d'une « défaillance système ». B. Lever une exception depuis le gestionnaire d'outil afin que le framework agent puisse la capturer et la journaliser — Incorrect. Les exceptions sont utiles en interne, mais l'agent a toujours besoin d'une réponse structurée de l'outil ; les exceptions brutes ne propagent pas de manière fiable un contexte utile au modèle. C. Retourner le message d'erreur dans le contenu du résultat de l'outil avec le flag isError défini à true — Correct. Il s'agit du modèle MCP approprié : l'outil signale explicitement l'échec en utilisant isError: true, tout en fournissant un message d'erreur lisible afin que l'agent puisse décider de réessayer, d'escalader ou d'informer l'utilisateur. D. Retourner une réponse de succès avec un champ « status » indiquant le type d'erreur — Incorrect. Cela est trompeur car cela traite les échecs comme des réponses réussies, ce qui perturbe le raisonnement en aval et l'orchestration des outils.

A. Retourner une liste de vols vide comme si la recherche avait réussi mais n'avait trouvé aucun vol correspondant. Incorrect. Cela masque l'échec et induit le système en erreur en lui faisant croire qu'aucun vol n'existe, ce qui peut conduire à des conclusions incorrectes. B. Enregistrer l'erreur en interne et retourner une réponse vide, laissant le modèle continuer sans les données de vols. Incorrect. Cela supprime également le signal d'échec, empêchant l'agent de prendre des mesures correctives. C. Retourner un message d'erreur dans le résultat de l'outil expliquant que le service est temporairement indisponible. Incorrect. Bien que transparent, cela ne tente pas à lui seul une récupération et peut dégrader inutilement l'expérience utilisateur. D. Réessayer automatiquement la requête jusqu'à cinq fois avec un backoff exponentiel avant de retourner les résultats à l'agent. Correct. Il s'agit de l'approche la plus efficace : elle gère les pannes transitoires de manière élégante, améliore la fiabilité et ne remonte les erreurs que si les tentatives échouent.

A. Des URLs sur lesquelles les utilisateurs peuvent cliquer pour ouvrir le document dans leur navigateur. Incorrect. Les URLs sont utiles pour les utilisateurs, mais ne sont pas idéales pour les agents effectuant des workflows en plusieurs étapes nécessitant un référencement fiable et des opérations supplémentaires. B. Des données structurées contenant les identifiants de documents et les métadonnées pour chaque résultat. Correct. Cela permet à l'agent de référencer de manière programmatique des documents spécifiques (via des identifiants) à travers plusieurs étapes, rendant les workflows tels que les requêtes de suivi ou la récupération de documents précis et fiables. C. Un tableau JSON de titres de documents extraits des résultats de recherche. Incorrect. Les titres seuls sont ambigus et ne constituent pas des identifiants stables, ce qui rend difficile pour les agents d'agir de manière fiable sur des documents spécifiques. D. Des descriptions plus détaillées et lisibles par l'humain, incluant la taille et les auteurs. Incorrect. Utile pour les utilisateurs, mais toujours non structuré et non adapté à des opérations précises d'agents en plusieurs étapes.

A. Mettre en œuvre une déduplication sémantique pour identifier et supprimer les informations redondantes dans les résultats RAG accumulés et les tours de conversation — Incorrect. Cela réduit la redondance, mais ne résout pas le problème central de l'accumulation non bornée du contexte RAG. B. Mettre en œuvre une fenêtre glissante pour les résultats RAG des 2 à 3 dernières requêtes tout en préservant l'historique de la conversation — Correct. Cela répond directement au problème de saturation du contexte en limitant la croissance du RAG tout en maintenant la continuité de la conversation. C. Réaffecter le budget de contexte en faveur des résultats RAG tout en réduisant l'allocation de l'historique de conversation — Incorrect. Cela détériore la cohérence en sacrifiant le contexte conversationnel. D. Compresser tous les résultats RAG en un document de synthèse consolidé qui se met à jour de manière incrémentielle après chaque récupération — Incorrect. Cela peut entraîner une perte d'informations et une dérive du résumé, en particulier sur de nombreux tours de conversation.

A. Fournir au sous-agent des définitions d'outils lui permettant de demander des résultats à d'autres sous-agents via des callbacks. Incorrect. Cette approche introduit un couplage et une complexité inutiles. Les sous-agents ne devraient pas avoir besoin de récupérer activement des données auprès des autres. B. Inclure directement les résultats complets des deux sous-agents dans le prompt du sous-agent de synthèse. Incorrect. Bien que simple, cette approche ne passe pas bien à l'échelle pour des résultats volumineux et peut dépasser les limites de contexte, réduisant ainsi l'efficacité. C. Transmettre des identifiants de référence et configurer le sous-agent avec un accès en lecture à un espace mémoire partagé où les autres sous-agents ont déposé leurs résultats. Correct. Il s'agit de l'approche la plus évolutive et prête pour la production. Elle préserve la fidélité des informations tout en évitant la surcharge du contexte, permettant à l'agent de synthèse de récupérer exactement ce dont il a besoin. D. Instancier le sous-agent avec seulement une brève description de tâche, en s'appuyant sur un héritage automatique du contexte depuis le coordinateur. Incorrect. Il n'existe pas d'héritage automatique du contexte — sans accès explicite aux données, l'agent de synthèse ne peut pas fonctionner correctement.

A. L'agent coordinateur reçoit la sortie de l'agent de recherche web et inclut les résultats pertinents dans le prompt lors de l'invocation de l'agent d'analyse de documents. Correct. Cela suit le modèle d'orchestration standard où le coordinateur gère tous les flux de données, en transmettant explicitement les sorties entre les sous-agents. B. Les agents communiquent via une file de messages orientée événements, l'agent d'analyse de documents s'abonnant aux événements de fin de recherche web. Incorrect. Cela introduit une complexité d'infrastructure inutile et ne correspond pas au modèle d'orchestration d'agents habituel. C. L'agent de recherche web invoque directement l'agent d'analyse de documents, en utilisant les sources découvertes comme paramètres. Incorrect. Les sous-agents ne doivent pas s'invoquer directement entre eux ; cela rompt le contrôle centralisé et la traçabilité. D. Les deux agents accèdent à un espace mémoire partagé où l'agent de recherche web écrit les résultats et l'agent d'analyse de documents les lit. Incorrect. Bien que cela soit possible dans des systèmes avancés, ce n'est pas l'approche standard ou la plus simple ; cela ajoute de la complexité sans nécessité évidente dans les pipelines classiques.

B. Les détails de la commande sont ajoutés à la conversation et le modèle raisonne sur l'action à entreprendre. Correct. Dans une boucle agentique, les résultats des outils (comme « acheté il y a 45 jours ») sont réinjectés dans le contexte du modèle, et celui-ci réévalue la situation de manière dynamique. Il décide ensuite s'il convient de procéder avec process_refund, d'escalader vers un humain, ou d'entreprendre une autre action en fonction de la politique et des informations mises à jour. Pourquoi les autres réponses sont incorrectes : A. Séquence d'outils fixe planifiée dès le départ — Incorrect. Les systèmes agentiques ne sont pas des flux de travail statiques ; ils s'adaptent après chaque observation. C. Arbre de décision préconfiguré — Incorrect. Il s'agit d'une automatisation basée sur des règles, et non d'un raisonnement piloté par un LLM. D. La couche d'orchestration achemine automatiquement le prochain appel d'outil — Incorrect. Cela supprime le rôle de raisonnement du modèle et le transforme en un routage déterministe.