# D6 · Stakeholder Communication & Lifecycle Management Découverte structurée et recueil des exigences, communication des décisions d’architecture à des publics techniques et non techniques, boucles de rétroaction et alignement des SLA, documentation C4, phases du cycle de vie avec critères de sortie, gestion du changement, et dépréciation de modèle comme événement du cycle de vie. import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components'; Ce domaine pèse **14 % – environ 9 des 63 items**. C’est là que les candidats de niveau Foundations perdent des points, car il teste la moitié *non-code* du travail d’architecte : recueillir les vraies exigences, communiquer les arbitrages à différents publics, documenter le système, et l’accompagner sur tout son cycle de vie — y compris traiter les **dépréciations et migrations de modèle comme des événements planifiés du cycle de vie**. Les bonnes réponses favorisent une communication **structurée, adaptée au public, étayée par des preuves** et des **gates de phase avec critères de sortie** plutôt que l’héroïsme ad hoc. ## Objectifs d’apprentissage À la fin de cette page, vous devriez savoir : 1. Mener une **découverte structurée** : frameworks d’entretien, métriques de réussite, capture des contraintes. 2. Communiquer les **décisions d’architecture et les arbitrages** à des publics techniques et non techniques à l’aide d’ADR, de matrices de décision, de modèles de coût et de registres des risques. 3. Concevoir des **boucles de rétroaction** et s’aligner sur les **attentes/SLA**. 4. Produire la **documentation d’architecture** : vues C4, diagrammes de flux de données, runbooks. 5. Gérer le **cycle de vie** (découverte → conception → build → passation → supervision → itération) avec des livrables et des **critères de sortie** par phase. 6. Piloter la **gestion du changement et l’adoption**. 7. Gérer les **dépréciations et migrations de modèle** comme un événement du cycle de vie ; fixer une cadence de **revue post-lancement**. --- ## 6.1 Structured discovery and requirements gathering La découverte (introduite en D1) est aussi une discipline de *communication* : extraire les exigences de personnes qui décrivent des symptômes, non des spécifications, et les convertir en critères mesurables et convenus. | Framework | Usage | Sortie | | --- | --- | --- | | Carte des parties prenantes | Identifier qui décide, qui est affecté, qui l’opère | RACI | | Entretien structuré | Recueillir objectifs, points de douleur, contraintes, définition de la réussite | Liste d’exigences | | Jobs-to-be-done | Cadrer la tâche que le système doit accomplir | Énoncé du problème | | Capture des contraintes | Budget, échéance, résidence, IAM, compétences, volume | Registre des contraintes | | Atelier de métriques de réussite | Transformer « mieux » en chiffres, par segment | Critères d’acceptation mesurables | :::tip[Signal d’examen] Quand un énoncé montre une demande vague et des parties prenantes en désaccord, la bonne réponse est généralement de **mener une découverte structurée et de convenir de critères de réussite mesurables** avant de concevoir ou de construire — non de commencer à coder ou de choisir un modèle. ::: --- ## 6.2 Communicating decisions to different audiences La même décision doit être cadrée différemment pour différents lecteurs. C’est une compétence centrale que l’examen teste. | Public | Ce dont il a besoin | Vecteur | | --- | --- | --- | | Dirigeants / sponsors | Décision, options, coût, risque, valeur métier ; une page | Matrice de décision + modèle de coût + brief d’une page | | Pairs techniques | Les arbitrages, alternatives rejetées, conséquences | **ADR** | | Risque / conformité | Menaces, contrôles, risque résiduel | **Registre des risques** | | Opérateurs | Comment l’exploiter, superviser, récupérer | **Runbook** | | Utilisateurs finaux / adoptants | Ce qui change, pourquoi, comment l’utiliser | Matériel d’activation | | Artefact de communication | Ce qu’il capture | | --- | --- | | ADR | Une décision : contexte, options, choix, conséquences (D1) | | Matrice de décision | Options notées contre des critères pondérés | | Modèle de coût | Économie unitaire sous un volume réaliste (routage, caching, batch) | | Registre des risques | Risques avec vraisemblance, impact, propriétaire, atténuation | :::caution[Mauvaise altitude] Remettre aux dirigeants un ADR technique profond, ou remettre aux ingénieurs une diapositive centrée seulement sur la valeur, sont deux échecs. Accordez l’artefact au public. Les distracteurs qui donnent à chaque public le même document sont faux. ::: --- ## 6.3 Feedback loops and SLA alignment Fixez les attentes explicitement et mesurablement, puis gardez une boucle ouverte. - Convenez des **SLA** en chiffres (latence p95, disponibilité, justesse par segment, coût par tâche) — les mêmes critères qui pilotent les évals (D4). - Distinguez **SLA** (engagement externe), **SLO** (objectif interne), **SLI** (l’indicateur mesuré). - Établissez un **canal de rétroaction** (thumbs utilisateur, échantillonnage QA, métriques online) qui alimente la boucle d’amélioration, et reportez contre les chiffres convenus à une cadence. - Gérez d’emblée les attentes sur les **limites de l’IA** (c’est un collaborateur faillible ; il y a des points de contrôle humains) pour éviter de surpromettre. --- ## 6.4 Architecture documentation (C4 and runbooks) La documentation est un livrable, non une réflexion après coup. Le **modèle C4** donne un langage partagé à quatre niveaux de zoom. | Niveau C4 | Montre | Public | | --- | --- | --- | | 1 · Contexte | Le système dans son environnement, utilisateurs, systèmes externes | Tout le monde | | 2 · Conteneur | Apps, socles de données, services modèle/RAG, serveurs MCP | Technique | | 3 · Composant | Composants internes d’un conteneur | Ingénieurs | | 4 · Code | Détail classe/fonction (rarement nécessaire) | Ingénieurs | ```text C4 L1 (Context) C4 L2 (Container) ┌──────────┐ ┌───────────────┐ ┌───────────────────────────────┐ │ user │──▶│ Support │ │ [web app] ─▶ [orchestrator] ─▶│ └──────────┘ │ Assistant │ │ ─▶ [RAG service] │ ┌──────────┐ │ (this system) │ │ ─▶ [Claude/Bedrock]│ │ CRM (ext)│◀─▶│ │ │ ─▶ [MCP tools] │ └──────────┘ └───────────────┘ └───────────────────────────────┘ ``` Un **runbook** documente comment exploiter et récupérer : dashboards, alertes, étapes d’astreinte, procédure de rollback, contacts d’incident, carte des dépendances. Un **diagramme de flux de données** montre comment les données (y compris PII/PHI) se déplacent — essentiel pour la DPIA (D5). --- ## 6.5 Lifecycle phases with exit criteria Un architecte possède le système sur toute sa vie, non seulement la conception. Chaque phase a des livrables et un **critère de sortie** (un gate à passer pour continuer). | Phase | Livrables clés | Critère de sortie | | --- | --- | --- | | Découverte | Énoncé du problème, contraintes, critères de réussite mesurables | Les parties prenantes valident les critères | | Conception | Architecture de référence, ADR, matrice de décision, modèle de coût, registre des risques | Revue de conception passée ; DPIA/BAA si nécessaire | | Build | Implémentation, évals, garde-fous, observabilité | Suite de régression offline au vert par segment | | Passation | Runbook, docs C4, formation, transfert de propriété | Les opérateurs peuvent l’exploiter et le récupérer | | Supervision | Dashboards, métriques online, alertes | SLA respectés en production ; canary sain | | Itération | Backlog issu de la boucle de rétroaction ; améliorations prompt/modèle/récupération | Les améliorations passent régression + canary | ```text Discovery ─▶ Design ─▶ Build ─▶ Handoff ─▶ Monitoring ─▶ Iteration ─┐ ▲ │ └───────────────── feedback loop (D1/D4) ───────────────────────┘ ``` :::tip[Signal d’examen] « Ils veulent passer directement au build » ou « déployer sans runbook / sans critères convenus » → la bonne réponse insère le **gate de phase** manquant (critères convenus avant la conception ; runbook avant la passation ; canary avant le déploiement complet). ::: --- ## 6.6 Change management and adoption Un système techniquement excellent que personne n’adopte a échoué. L’adoption est une préoccupation d’architecture. | Levier | Objectif | | --- | --- | | Plan de communication des parties prenantes | Tenir sponsors et utilisateurs informés | | Formation et activation | Les utilisateurs connaissent ce que fait le système et ses limites | | Déploiement par phases | Réduire le risque et bâtir la confiance (reflète le canary) | | Capture de la rétroaction | Faire remonter les problèmes tôt ; montrer la réactivité | | Reporting des métriques de réussite | Démontrer la valeur contre les critères convenus | --- ## 6.7 Model deprecation and migration as a lifecycle event Les modèles sont versionnés et **dépréciés/retirés** (p. ex. Opus 4.1 retiré le 2026-08-05). La migration est un **événement planifié du cycle de vie**, non un exercice d’incendie. 1. **Inventaire** : quels services épinglent quels IDs de modèle, prompts et référentiels d’éval (depuis l’inventaire de modèles en D5). 2. **Évaluer** : lire l’avis de dépréciation ; identifier les changements incompatibles (p. ex. `budget_tokens` supprimé, comportement de l’usage forcé d’outils, règles des thinking blocks — D2). 3. **Re-valider** : exécuter la **suite de régression** sur le modèle cible par segment ; ajuster les prompts au besoin (les prompts sont validés par modèle, D2/D4). 4. **Migrer en canary** : déployer le nouveau modèle via canary avec rollback ; monter en charge quand c’est sain. 5. **Communiquer** : annoncer aux parties prenantes le calendrier, les différences attendues, et tout impact SLA. :::caution[La dépréciation n’est pas « échanger l’ID et espérer »] Ré-épingler silencieusement vers un nouveau modèle sans relancer les évals peut régresser un segment ou heurter un changement incompatible. Traitez-la comme une migration gouvernée avec re-validation et canary. Et ne laissez jamais un repli piloté par la disponibilité rétrograder silencieusement une session de thinking Fable 5.1 (D1/D2). ::: --- ## 6.8 Post-launch review cadence Fixez une revue récurrente (p. ex. hebdomadaire au début, puis mensuelle) qui examine : le respect des SLA par segment, la tendance de coût, les constats d’incident/red-team, la dérive, et le backlog d’itération. C’est la forme opérationnelle de la boucle de rétroaction et l’endroit où les calendriers de dépréciation et les décisions de ré-architecture émergent. --- ## 6.9 A discovery interview guide (reusable artefact) La découverte est répétable. Ce guide convertit une demande vague en une spécification validée. ```text DISCOVERY GUIDE — Claude solution 1. Problem & value - What decision/task are we automating? What breaks today? - Which value pillar dominates: efficiency, cost, or an SLA? 2. Success criteria (make it numeric, per segment) - "Good enough" as numbers: accuracy, p95 latency, deflection, cost/task - Which segments must not regress? (tiers, languages, doc types) 3. Volume & shape - Requests/sec avg & peak; sync vs async; payload sizes 4. Data & compliance - Sensitivity class; residency; retention; sources; freshness - Regulations: GDPR / HIPAA / FedRAMP / EU AI Act? 5. Constraints - Budget ceiling; deadline; existing cloud/IAM; team skills 6. Risk & reversibility - Blast radius of a wrong answer; which actions are irreversible? 7. Integration & identity - Systems to read/write; identity model; MCP vs API 8. Sign-off - Stakeholders agree criteria & constraints → DESIGN gate passed ``` | Anti-patron d’entretien | Meilleur geste | | --- | --- | | Accepter « améliorer le support » et démarrer | Pousser vers des critères numériques, par segment | | N’interroger que la partie prenante la plus bruyante | Cartographier décideur / affecté / opérateur (RACI) | | Capturer les objectifs mais pas les contraintes | Capturer budget, échéance, résidence, IAM d’emblée | --- ## 6.10 A weighted decision matrix (worked example) Pour le sponsor, une matrice de décision note les options contre des critères pondérés et produit un choix défendable. **Décision : patron pour un assistant de triage de sinistres.** Critères pondérés en faveur du métier (coût et fiabilité dominent ici). | Critère (poids) | Workflow | Agentique | Multi-agents | | --- | --- | --- | --- | | Respecte le SLA p95 (0,25) | 5 | 3 | 2 | | Coût unitaire (0,25) | 5 | 3 | 2 | | Fiabilité/débogabilité (0,20) | 5 | 3 | 2 | | Flexibilité pour le périmètre futur (0,15) | 3 | 5 | 5 | | Effort de build/exploitation (0,15) | 4 | 3 | 2 | | **Total pondéré** | **4,60** | **3,30** | **2,45** | ```text Workflow = 0.25·5 + 0.25·5 + 0.20·5 + 0.15·3 + 0.15·4 = 1.25+1.25+1.00+0.45+0.60 = 4.60 ``` Le workflow l’emporte de façon décisive car les critères pondérés favorisent le SLA, le coût et la fiabilité — exactement la justification de l’ADR, exprimée pour un public non technique. Changez les poids (p. ex. la flexibilité devient dominante pour un outil de recherche ouvert) et la matrice peut favoriser l’agentique — ce qui est tout l’intérêt : le choix est **traçable jusqu’à des priorités métier pondérées**. :::tip[Signal d’examen] Quand un énoncé demande comment justifier une conception auprès d’un sponsor, la réponse est une **matrice de décision / un modèle de coût / un brief d’une page**, tandis que les ingénieurs reçoivent l’**ADR**. Donner le même artefact aux deux publics est le piège de la mauvaise altitude. ::: --- ## 6.11 A runbook template (handoff artefact) Le critère de sortie du gate de passation est « les opérateurs peuvent l’exploiter et le récupérer ». Cela requiert un runbook : ```text RUNBOOK — 1. Overview: purpose, owners, on-call rotation, C4 context link 2. Dependencies: models (IDs/versions), MCP servers, vector store, downstream APIs 3. Dashboards: p95 latency, cost/task, error rate, per-segment accuracy, cache hit 4. Alerts & thresholds: 429/5xx spike, cost anomaly, faithfulness drop, injection detector 5. Common incidents → actions: - 529/overload → confirm backoff + fallback; check provider status - stale answers → inspect retrieval; trigger re-index (freshness pipeline) - injection detected → disable tool via hook; roll back prompt/model version - cost spike → check loop/iteration backstop; verify cache prefix stable 6. Rollback: how to flip prompt/model version; prior version is kept hot 7. Escalation: who to page; compliance contact (GDPR breach → 72 h) 8. Change log: prompt/model versions, dates, eval scores ``` Un **diagramme de flux de données** l’accompagne (chemins des PII/PHI pour la DPIA, D5). Sans dashboards, alertes et chemin de rollback, le gate de passation échoue. --- ## 6.12 Scénario détaillé : sauver un déploiement bloqué et mal communiqué **Scénario.** Une équipe d’ingénierie a construit un assistant de support solide mais il est bloqué : on a montré au VP sponsor un ADR technique de 40 pages et il n’est pas convaincu ; les ops refusent la passation car il n’y a pas de runbook ; l’équipe veut déployer à 100 % la semaine prochaine ; et aucun critère de réussite numérique n’a jamais été convenu. L’adoption dans l’équipe pilote est faible. **Trace de raisonnement d’expert.** 1. **Corriger l’altitude de communication.** Le VP a besoin d’une **matrice de décision d’une page + modèle de coût + valeur métier**, non de l’ADR. Les ingénieurs gardent l’ADR. Même décision, artefacts différents. 2. **Fermer rétroactivement le gate de découverte.** Menez un atelier de métriques de réussite ; convenez de critères **numériques, par segment** (p95, déflexion, coût/ticket) et obtenez la validation. 3. **Produire le runbook.** Dashboards, alertes, rollback, dépendances, astreinte — le critère de sortie de passation — plus les docs C4 et de flux de données. 4. **Remplacer le big-bang par le canary.** Rejetez le 100 %-la-semaine-prochaine ; **canary → montée en charge** avec rollback et métriques online. 5. **Traiter l’adoption.** Activation/formation sur les capacités *et les limites*, déploiement par phases, capture de la rétroaction, reporting de valeur contre les métriques convenues. 6. **Fixer une cadence de revue post-lancement** pour surveiller les SLA par segment, le coût, les incidents et le calendrier de dépréciation. **Pourquoi les alternatives tentantes sont fausses :** « renvoyer l’ADR au VP » répète l’erreur de mauvaise altitude ; « déployer à 100 % pour forcer l’adoption » est un fort rayon d’impact et engendre la résistance ; « sauter le runbook pour tenir la date » échoue au gate de passation ; « une seule métrique agrégée » masque la défaillance par segment et ne peut pas être reportée de façon crédible. --- ## 6.13 Common misconceptions | Idée reçue | Réalité | Pourquoi c’est important à l’examen | | --- | --- | --- | | « Tout le monde devrait recevoir le document technique complet. » | Accordez l’artefact à l’altitude du public. | Le même-doc-pour-tous est le piège de la mauvaise altitude. | | « On peut définir la réussite plus tard. » | Des critères mesurables, par segment, doivent être convenus à la découverte. | Construire avant les critères est sans ancrage. | | « ‘Plus rapide’ est un objectif. » | Les SLA doivent être des chiffres (p95, déflexion, coût/tâche). | Les promesses vagues ne peuvent être ni vérifiées ni reportées. | | « Un changement de modèle n’est qu’un changement d’ID. » | La dépréciation est une migration gouvernée : évaluer, re-valider, canary, communiquer. | Les échanges à l’aveugle heurtent des changements incompatibles/régressions. | | « L’adoption suit automatiquement une bonne technique. » | L’adoption nécessite activation, déploiement par phases, reporting de valeur. | Les énoncés à faible adoption testent la gestion du changement. | | « SLA, SLO, SLI sont synonymes. » | SLI (métrique) → SLO (interne) → SLA (engagement externe). | Les items de définition testent ceci précisément. | | « La conformité peut attendre le lancement. » | La DPIA/le BAA appartiennent au design-gate. | La conformité-tardive est une mauvaise réponse. | --- ## Pièges de l’examen dans ce domaine | Piège | Pourquoi c’est faux | | --- | --- | | Sauter au build avant de convenir de critères de réussite mesurables | Saute le gate de sortie de découverte ; sans ancrage | | Donner à chaque public le même document | Mauvaise altitude ; les dirigeants ont besoin de valeur/coût, les ingénieurs d’ADR | | Fixer « mieux » comme objectif au lieu de chiffres | Non mesurable ; ne peut être vérifié ni reporté | | Déployer sans runbook | Les opérateurs ne peuvent pas exploiter ou récupérer le système | | Déploiement complet sans canary ni adoption par phases | Fort rayon d’impact ; aucune construction de confiance | | Traiter une dépréciation de modèle comme un échange à même ID | Les changements incompatibles / régressions de segment passent inaperçus | | Surpromettre la capacité de l’IA aux sponsors | Attentes désalignées ; érode la confiance | | Aucune boucle de rétroaction / aucune revue post-lancement | Le système stagne ; dérive et régressions passent inaperçues | | Confondre SLA, SLO, SLI | Engagements et objectifs internes sont amalgamés | | Sauter la DPIA/le BAA au design-gate | Conformité découverte trop tard (lié à D5) | | Justifier une conception à un sponsor avec un ADR brut ou des logs d’éval | Les sponsors ont besoin d’une matrice de décision / d’un modèle de coût / d’un brief d’une page | | Passer la main sans runbook, dashboards, ou rollback | Échoue au critère de sortie de passation ; les opérateurs ne peuvent pas le récupérer | | Déployer à 100 % pour « forcer » l’adoption | Fort rayon d’impact ; l’adoption nécessite activation + déploiement par phases | | Noter les options sans pondérer les critères aux priorités métier | Une matrice de décision doit refléter des priorités pondérées pour être défendable | | Omettre le diagramme de flux de données de la documentation | La DPIA et la revue PII/PHI en dépendent | --- ## Questions d’entraînement A. Commencer à construire l’interprétation la plus probable. B. Mener une découverte structurée pour aligner les parties prenantes sur des critères de réussite mesurables, par segment, et des contraintes, et obtenir la validation avant la conception. C. Choisir Opus 5 et commencer. D. Escalader vers le fournisseur. **Réponse : B.** Avec un désaccord et aucune métrique, le gate de découverte n’est pas passé ; une découverte structurée et des critères convenus doivent précéder la conception/le build. Construire sur une supposition (A), choisir un modèle (C), ou escalader vers le fournisseur (D) sautent tous l’étape d’ancrage. A. Envoyer aux deux publics l’ADR technique complet. B. Donner au sponsor une matrice de décision d’une page avec modèle de coût, risque et valeur métier ; donner aux ingénieurs l’ADR avec les alternatives rejetées et les conséquences. C. Donner aux deux une diapositive centrée seulement sur la valeur. D. Donner aux deux les logs d’éval bruts. **Réponse : B.** La communication doit correspondre à l’altitude du public : valeur/coût/risque pour le sponsor, arbitrages et conséquences pour les ingénieurs. Un seul document pour les deux (A, C) ou des logs bruts (D) sont inadaptés à au moins un public. A. Promettre que ce sera « beaucoup plus rapide ». B. Convenir de cibles numériques — p. ex. latence p95 sous 6 s, ≥ 60 % de déflexion, coût sous 0,05 $/ticket — par segment, et reporter contre elles à une cadence. C. Suivre seulement la latence moyenne. D. Le laisser indéfini et ajuster plus tard. **Réponse : B.** Les SLA doivent être mesurables et par segment, reflétant les critères d’éval, avec un reporting régulier. Les promesses vagues (A) ne peuvent être vérifiées ; la moyenne seule (C) masque la queue ; indéfini (D) invite les litiges. A. Le niveau 4 (Code). B. Le niveau 1 (Contexte) — le système, ses utilisateurs, et les systèmes externes. C. Le niveau 3 (Composant). D. Des diagrammes de séquence bruts de chaque appel d’API. **Réponse : B.** Le niveau Contexte montre le système dans son environnement pour un large public. Le Code (A) et le Composant (C) sont pour les ingénieurs ; des diagrammes de séquence exhaustifs (D) submergent les lecteurs non techniques. A. Lire l’avis de dépréciation, identifier les changements incompatibles, et relancer la suite de régression par segment sur le modèle cible, en ajustant les prompts au besoin. B. Faire du nouveau modèle un canary avec rollback, puis monter en charge, et communiquer le calendrier/les différences aux parties prenantes. C. Échanger l’ID de modèle en production et espérer que tout aille bien. D. Continuer à appeler le modèle retiré. E. Désactiver les évals pendant la migration pour aller plus vite. **Réponse : A et B.** La dépréciation est un événement gouverné du cycle de vie : évaluer les changements incompatibles, re-valider par segment, canary avec rollback, et communiquer. Un échange d’ID à l’aveugle (C) risque des régressions/changements incompatibles ; appeler un modèle retiré (D) échoue ; désactiver les évals (E) retire le filet de sécurité. A. Un deck marketing. B. Un runbook couvrant dashboards, alertes, étapes d’astreinte, rollback, et dépendances, plus les docs C4, pour que les opérateurs puissent l’exploiter et le récupérer. C. Rien ; les opérateurs se débrouilleront. D. Uniquement le code source. **Réponse : B.** Le critère de sortie de la passation est que les opérateurs puissent exploiter et récupérer le système, ce qui requiert un runbook et des docs d’architecture. Un deck (A), rien (C), ou le code seul (D) ne permettent pas une exploitation sûre. A. Ce sont des synonymes. B. Le SLI est l’indicateur mesuré, le SLO est l’objectif interne, le SLA est l’engagement externe (souvent avec des conséquences). C. Le SLA est interne ; le SLO est externe. D. Le SLI est un contrat juridique. **Réponse : B.** SLI (indicateur) → SLO (objectif interne) → SLA (engagement externe). Ce ne sont pas des synonymes (A), les rôles interne/externe ne sont pas inversés (C), et le SLI est une métrique, non un contrat (D). A. Formation/activation et communication claire de ce que fait le système et de ses limites. B. Un déploiement par phases avec capture de la rétroaction et reporting des métriques de réussite pour bâtir la confiance. C. Forcer toutes les équipes à l’utiliser immédiatement sans support. D. Retirer les points de contrôle de supervision humaine pour le rendre plus rapide. E. Cacher les limites aux utilisateurs. **Réponse : A et B.** L’adoption est pilotée par l’activation, le déploiement par phases, la rétroaction et la valeur démontrée. Forcer l’usage sans support (C) engendre la résistance ; retirer les points de contrôle de sûreté (D) est non sûr ; cacher les limites (E) érode la confiance quand elles apparaissent. A. Après le lancement si un régulateur le demande. B. Au design-gate, pour que résidence, rétention et traitement des PHI/PII façonnent l’architecture avant le build. C. Jamais, si le système est interne. D. Uniquement pendant la réponse aux incidents. **Réponse : B.** Les obligations de conformité doivent façonner la conception, donc la DPIA/le BAA appartiennent au critère de sortie de conception. Après le lancement (A) ou pendant un incident (D) est trop tard ; « interne » (C) n’exempte pas les données réglementées. A. Clore le projet définitivement. B. Revoir le respect des SLA par segment, la tendance de coût, les incidents/constats de red-team, la dérive, et le backlog d’itération — opérationnalisant la boucle de rétroaction et faisant remonter les besoins de dépréciation/ré-architecture. C. Remplacer les dashboards de supervision. D. Éviter la documentation. **Réponse : B.** La cadence est la boucle de rétroaction opérationnelle où la santé du système et les besoins futurs sont revus. Elle ne termine pas le projet (A), ne remplace pas les dashboards (C), et n’excuse pas la documentation (D). A. Un ADR. B. Un registre des risques listant les risques avec vraisemblance, impact, propriétaire et atténuation. C. Un modèle de coût. D. Un diagramme de code C4. **Réponse : B.** Un registre des risques est le vecteur pour communiquer les risques et le risque résiduel à la conformité. Un ADR (A) est un enregistrement de décision technique ; un modèle de coût (C) est de l’économie ; un diagramme de code (D) est pour les ingénieurs. A. Des critères de réussite convenus et mesurables (gate de découverte/conception) avant de continuer. B. Un runbook et un déploiement canary/par phases avec rollback avant le déploiement complet. C. Un déploiement complet immédiat pour rassembler les données plus vite. D. Sauter la supervision pour réduire la charge. E. Laisser chaque ingénieur définir ses propres métriques. **Réponse : A et B.** Les gates de phase manquants sont les critères convenus et un runbook plus canary avec rollback. Le déploiement complet immédiat (C) est un fort rayon d’impact ; sauter la supervision (D) aveugle les opérations ; les métriques par ingénieur (E) détruisent une définition partagée de la réussite. A. Renvoyer l’ADR avec un e-mail de résumé. B. Présenter une matrice de décision d’une page avec critères pondérés, un modèle de coût, et la valeur/le risque métier cadrés pour un dirigeant. C. Envoyer les logs d’évaluation bruts. D. Donner le runbook au VP. **Réponse : B.** Les sponsors ont besoin d’une matrice de décision/d’un modèle de coût/d’un brief d’une page à leur altitude, non d’un ADR d’ingénierie. Renvoyer l’ADR (A) répète l’erreur ; les logs d’éval bruts (C) et le runbook opérateur (D) sont les mauvais artefacts pour un sponsor. A. L’Agentique, car il est plus flexible. B. Le Workflow (pondéré 4,60 vs 3,30), car le métier a pondéré le SLA, le coût et la fiabilité au plus haut. C. Ils sont à égalité. D. La matrice ne peut pas décider. **Réponse : B.** Workflow = 0,25·5+0,25·5+0,20·5+0,15·3+0,15·4 = 4,60 ; Agentique = 0,25·3+0,25·3+0,20·3+0,15·5+0,15·3 = 3,30. Les poids favorisent SLA/coût/fiabilité, donc le workflow l’emporte. La flexibilité (A) n’est que 0,15 ; ce n’est pas une égalité (C) ; la matrice décide de façon transparente (D). A. Un deck de diapositives et une promesse de support. B. Un runbook (dashboards, alertes, astreinte, rollback, dépendances) plus les docs C4 et de flux de données, pour que les opérateurs puissent exploiter et récupérer le système. C. Le dépôt de code source uniquement. D. Un modèle de coût. **Réponse : B.** Le critère de sortie de la passation est l’exploitabilité et la récupérabilité, que le runbook plus les docs d’architecture/de flux de données fournissent. Un deck (A), le code seul (C), ou un modèle de coût (D) ne permettent pas aux opérateurs de l’exploiter et de le récupérer. A. Convenir de critères de réussite mesurables, par segment (gate de découverte/conception). B. Produire un runbook et utiliser un déploiement canary/par phases avec rollback avant le déploiement complet. C. Déployer immédiatement pour rassembler les données de production plus vite. D. Sauter la supervision pour réduire la charge. E. Laisser chaque ingénieur définir des métriques personnelles. **Réponse : A et B.** Les gates manquants sont les critères convenus et un runbook plus canary avec rollback. Le déploiement complet immédiat (C) est un fort rayon d’impact ; sauter la supervision (D) aveugle les ops ; les métriques par ingénieur (E) détruisent une définition partagée de la réussite. A. Choisir Opus 5 et commencer à construire. B. Mener l’étape de métrique de réussite pour transformer « plus rapide » en critères numériques, par segment et capturer les contraintes, puis obtenir la validation. C. Supposer une cible d’amélioration de 50 %. D. Escalader vers le fournisseur. **Réponse : B.** Le guide de découverte convertit les demandes vagues en critères numériques, par segment avec contraintes et validation avant la conception. Construire (A), supposer une cible (C), ou escalader (D) sautent l’étape d’ancrage. A. Une activation/formation qui couvre les capacités et les limites, et comment revoir la sortie de l’IA. B. Un déploiement par phases avec capture de la rétroaction et reporting de valeur contre les métriques convenues. C. Imposer l’usage à l’échelle de l’organisation immédiatement sans support. D. Retirer les points de contrôle de supervision humaine pour paraître plus rapide. E. Cacher les limites connues aux utilisateurs. **Réponse : A et B.** L’adoption est pilotée par l’activation et le déploiement par phases avec rétroaction et valeur démontrée. L’usage forcé (C), le retrait des points de contrôle de sûreté (D), et cacher les limites (E) se retournent contre soi. ## À retenir - Commencez par une **découverte structurée** ; convertissez les demandes vagues en critères de réussite **mesurables, par segment, validés**. - Communiquez à la **bonne altitude** : matrice de décision/modèle de coût pour les sponsors, **ADR** pour les ingénieurs, **registres des risques** pour la conformité, **runbooks** pour les opérateurs. - Convenez des SLA en **chiffres** ; distinguez SLI → SLO → SLA ; gardez une **boucle de rétroaction** et reportez à une cadence. - Documentez avec des vues **C4**, des diagrammes de flux de données et des runbooks — des livrables, non des réflexions après coup. - Gérez le **cycle de vie avec des critères de sortie** par phase ; ne sautez pas le gate (critères avant la conception, runbook avant la passation, canary avant le déploiement complet). - Traitez la **dépréciation/migration de modèle** comme un événement gouverné du cycle de vie : évaluer les changements incompatibles, re-valider par segment, canary, communiquer. - Pilotez l’**adoption** avec activation, déploiement par phases et reporting de valeur ; menez une cadence de **revue post-lancement**. - Utilisez un **guide d’entretien de découverte** réutilisable pour imposer des critères numériques, par segment et la capture des contraintes avant le design-gate. - Justifiez les conceptions aux sponsors avec une **matrice de décision pondérée** (score × poids) qui trace le choix jusqu’aux priorités métier ; les ingénieurs reçoivent l’ADR. - Le **gate de passation** requiert un runbook (dashboards, alertes, rollback, dépendances) plus les docs C4 et de flux de données — non un deck ni le code seul.