Six Board-Level Case Studies

Les items les plus longs de l’AIB-C01 ne sont pas des définitions. Ils vous tendent un paragraphe de désordre organisationnel – un sponsor à la conviction figée, des chiffres qui ne tombent pas tout à fait juste, une échéance – et demandent ce qu’un stratège métier ferait réellement. Ces six études de cas entraînent ce raisonnement. Chacune est traitée de bout en bout : la situation, la décision qu’on vous demande de prendre, les preuves, une analyse qui nomme le cadre et montre l’arithmétique, une recommandation séquencée, les réponses plus faibles démontées, une correspondance vers les énoncés de tâches officiels, et trois questions de style examen.

Chaque chiffre ci-dessous est illustratif – inventé pour le cas, cohérent en interne, et vérifiable arithmétiquement. Aucun chiffre ici n’est un prix AWS sauf s’il apparaît dans l’annexe des cadres ; là où une vraie structure de tarification AWS compte, le cas nomme la structure (à la consommation, au siège, à l’engagement), pas un tarif. Ces pages complètent les quatre pages de domaines et les deux examens blancs ; travaillez-les après votre premier diagnostic.

---

Case 1 · L’assistant de centre de contact qui est en réalité un problème de base de connaissances

Situation. Meridian Retail Bank est une banque de taille moyenne d’environ 5 000 employés et quelque 900 agents de centre de contact répartis sur trois sites. Le temps de traitement a grimpé sur deux ans et le score de satisfaction client a glissé de 78 à 71. La Chief Customer Officer est revenue d’une conférence convaincue qu’un assistant de generative AI, aux côtés de chaque agent et répondant aux questions en langage naturel, est le remède. Elle a une démo fournisseur programmée et veut un go/no-go de vous, la responsable transformation, sous deux semaines.

La banque a essayé des choses voisines. Un chatbot scripté sur le site web dévie les requêtes simples de solde et d’horaires mais est désactivé pour tout sujet sensible. Un outil de recherche interne sur la bibliothèque de politiques existe mais les agents le décrivent comme « plus rapide d’appeler un collègue ». Personne n’a mesuré pourquoi les appels durent aussi longtemps.

Vous passez trois jours sur le plateau. Les agents ne manquent ni d’intelligence ni de bonne volonté ; ils manquent de réponses auxquelles ils peuvent se fier. Les politiques produit et conformité vivent dans quatre systèmes : un wiki organisé pour la dernière fois il y a dix-huit mois, un lecteur partagé de PDF, un dossier d’e-mails de « clarifications » de l’équipe conformité, et de la connaissance tribale. Quand un agent tombe sur une question difficile, il devine, met le client en longue attente pendant qu’il cherche, ou escalade. Un audit échantillonné révèle que 31 % des réponses de politique dans le wiki sont périmées ou contredites par une clarification e-mail ultérieure.

La sponsore croit que l’assistant « saura tout simplement » les réponses. Elle n’a pas demandé d’où l’assistant les tirerait.

Ce qu’on vous demande. Recommander s’il faut financer maintenant l’assistant de centre de contact de generative AI, et sinon maintenant, quoi faire à la place et dans quel ordre.

Les preuves dont vous disposez.

Fait	Valeur (illustrative)
Agents de centre de contact	900
Temps de traitement moyen (AHT)	9,4 minutes, contre 8,1 il y a deux ans
Appels par agent par jour	46
Part de l’AHT passée à chercher des réponses de politique (observée)	~22 %
Réponses du wiki trouvées périmées ou contredites	31 %
Sources de politique non consolidées	4 systèmes distincts
Types d’appels réglementés (prêt, plaintes, clients vulnérables)	~18 % du volume
CSAT de référence	71 (était 78)
Date de décision demandée par la sponsore	2 semaines

Analyse. Le bon premier geste est de séparer le symptôme que voit la sponsore du problème qu’a le plateau. Elle voit un service lent et incohérent et recourt à un outil. Le plateau a une base de connaissances non fiable et fragmentée. Un assistant génératif ne crée pas de connaissance ; il récupère et reformule ce qu’il peut atteindre. S’il est ancré dans un corpus faux à 31 %, il répondra faux 31 % du temps, avec fluidité et à l’échelle – et dans les 18 % d’appels réglementés, une réponse fausse et assurée est un événement de conformité, pas seulement une mauvaise expérience.

Appliquez l’échelle de type de solution sur laquelle l’examen s’appuie (tâches 1.2.1 et 1.3.3) : automatisation par règles → IA → IA augmentée par récupération (RAG). Les requêtes déterministes, à fort volume et non ambiguës (solde, horaires, étapes de réinitialisation) appartiennent à l’automatisation par règles – peu coûteuse, auditable, sans dérive. Les requêtes restantes ont besoin que l’agent trouve la politique actuelle : c’est un problème de récupération, et le RAG est le motif qui ancre un modèle dans une source faisant autorité et actuelle plutôt que dans ses données d’entraînement. Mais la réponse du RAG n’est aussi bonne que le corpus qu’il indexe. La gouvernance dès la conception (tâche 3.1.3) dit de corriger le corpus et de décider la règle de supervision humaine avant de pointer un modèle dessus.

L’arithmétique dit à la sponsore pourquoi le séquençage compte. Temps perdu à chercher par agent par jour : 46 appels × 9,4 min × 22 % ≈ 95 minutes. Sur 900 agents, cela fait environ 1 425 heures par jour. Même diviser par deux le temps de recherche vaut ~712 heures par jour – un gros gain. Mais le gain n’est réel que si la source de vérité est fiable ; ancrer un modèle dans un corpus faux à 31 % convertit un problème de recherche en un problème de faux-avec-assurance-à-l’échelle, ce qui est pire dans les 18 % réglementés.

Établissez une référence avant la mise en œuvre (tâche 2.2.2) : AHT par type d’appel, temps de recherche, résolution au premier contact, et exactitude des réponses échantillonnée face à un jeu de politiques corrigé. Sans elle, personne ne pourra plus tard prouver que l’assistant a aidé, et « ça paraît plus rapide » ne survivra pas à une revue du conseil.

Recommandation, séquencée.

1. Recadrer la décision pour la sponsore : l’assistant est la phase trois, pas la phase un. Obtenir l’accord que l’objectif est des réponses fiables, pas un outil spécifique.
2. Consolider et corriger la base de connaissances. Une source faisant autorité unique ; retirer les quatre sources fragmentées ; assigner un propriétaire dans la conformité pour l’actualité. C’est l’étape au plus fort effet de levier et au plus faible risque, et elle aide même les humains.
3. Automatiser la queue déterministe avec des flux par règles pour les requêtes non ambiguës et à fort volume.
4. Tout référencer (AHT par type, temps de recherche, FCR, exactitude) avant qu’un modèle ne touche un appel.
5. Ensuite piloter un assistant ancré par RAG sur les types d’appels non réglementés, avec une supervision humaine obligatoire sur les 18 % réglementés et une règle d’escalade pour les réponses à faible confiance.
6. Mesurer face à la référence et décider scale/pause/terminate sur preuve.

À quoi ressemble une réponse plus faible, et pourquoi.

• « Approuver l’assistant maintenant ; la démo était impressionnante. » La fluidité dans une démo n’est pas l’ancrage dans votre corpus. Cela finance un outil pour un problème que vous n’avez pas défini et saute la référence, donc vous ne pourriez jamais prouver la valeur ni attraper le risque des réponses réglementées.
• « Acheter l’assistant mais seulement pour les appels réglementés, puisque ce sont les plus difficiles. » Exactement à l’envers : les appels réglementés portent la plus lourde charge de supervision et le coût le plus élevé d’une réponse fausse. Commencez là où une erreur est peu coûteuse.
• « Sauter l’IA entièrement ; dire juste aux agents de chercher davantage. » Ignore que le corpus lui-même est faux ; l’effort ne peut compenser une source de vérité périmée.
• « Fine-tuner un modèle sur les politiques. » Le fine-tuning ancre les politiques d’aujourd’hui dans les poids ; les politiques changent, et le modèle dériverait, deviendrait obsolète et serait coûteux à rafraîchir. La récupération face à un corpus maintenu est l’adéquation.

Quels domaines et tâches cela exerce. D1 1.2.1 (règles vs IA), 1.3.3 (RAG vs fine-tuning) ; D2 2.1.4 (quand l’IA n’est pas encore la réponse), 2.2.2 (références) ; D3 3.1.3 (gouvernance dès la conception), 3.1.4 (supervision humaine pour les appels réglementés).

Trois questions de style examen sur ce cas.

---

Case 2 · Trois initiatives, un budget, un conseil la semaine prochaine

Situation. Kestrel Industrial est un fabricant d’environ 12 000 employés aux marges serrées et au conseil prudent. Trois initiatives d’IA ont émergé le même trimestre, chacune avec un champion interne, et il y a du budget pour une seule cette année. Le directeur financier veut une recommandation unique au conseil de la semaine prochaine, défendable sur les chiffres, pas sur l’enthousiasme.

L’initiative A est la maintenance prédictive sur les principales lignes de production : prévoir les pannes, planifier les arrêts, éviter les arrêts non planifiés. L’initiative B est un sales-copilot qui rédige des propositions et répond aux questions produit pour l’équipe commerciale terrain. L’initiative C est un outil d’extraction documentaire qui extrait des champs de factures et contrats fournisseurs pour réduire la saisie manuelle.

Chaque champion a un dossier métier de qualité variable. L’équipe maintenance a de vraies données de coût d’arrêt. Le champion commercial a un pilote enthousiaste mais des chiffres mous. Le champion finance a une économie propre, petite et certaine. Le conseil a lu que les concurrents « investissent lourdement dans l’IA » et ne veut pas prendre de retard, mais est allergique à devoir passer par pertes et profits un programme échoué.

Le sponsor – le COO – favorise en privé le sales-copilot parce qu’il est le plus visible. Votre travail est de faire la recommandation que les preuves soutiennent, et de la cadrer pour que le conseil puisse agir.

Ce qu’on vous demande. Recommander quelle initiative unique financer cette année, et décrire comment vous traiteriez les deux autres.

Les preuves dont vous disposez.

Initiative	Bénéfice annuel (illustratif)	Coût one-off + annuel	Faisabilité	Préparation des données	Adéquation stratégique
A · Maintenance prédictive	4,0 M$ d’arrêts évités	0,6 M$ build + 0,4 M$/an run	Moyenne (données capteurs existent)	Élevée	Élevée (opérations cœur)
B · Sales-copilot	1,2 M$ d’uplift revendiqué (mou)	0,3 M$ + 0,5 M$/an	Élevée (SaaS, rapide)	Moyenne	Moyenne
C · Extraction de factures	0,5 M$ de main-d’œuvre économisée	0,15 M$ + 0,1 M$/an	Élevée	Élevée	Faible-moyenne

Analyse. Notez chaque initiative sur les quatre critères que l’examen nomme pour la priorisation (tâche 2.1.3) : valeur métier, faisabilité, pérennité, alignement stratégique. L’enthousiasme et la visibilité ne sont pas sur la liste ; la préférence du COO est un biais à gérer, pas un critère.

Faites d’abord l’arithmétique du ROI, car le conseil est piloté par les chiffres. ROI de la première année = (bénéfice − coût de la première année) ÷ coût de la première année, où le coût de la première année = one-off + un an de run.

• A : coût de la première année 0,6 M$ + 0,4 M$ = 1,0 M$ ; net = 4,0 M$ − 1,0 M$ = 3,0 M$ ; ROI ≈ 300 %. Le ROI courant est bien plus élevé une fois le build amorti : (4,0 M$ − 0,4 M$) ÷ 0,4 M$ = 900 %.
• B : coût de la première année 0,3 M$ + 0,5 M$ = 0,8 M$ ; net = 1,2 M$ − 0,8 M$ = 0,4 M$ ; ROI ≈ 50 % – mais le bénéfice est mou, donc un scénario réaliste défavorable (disons la moitié de la revendication, 0,6 M$) le rend négatif : 0,6 M$ − 0,8 M$ = −0,2 M$.
• C : coût de la première année 0,15 M$ + 0,1 M$ = 0,25 M$ ; net = 0,5 M$ − 0,25 M$ = 0,25 M$ ; ROI ≈ 100 % ; petit, certain, faible poids stratégique.

A est le leader clair sur la valeur et l’alignement stratégique (elle défend les opérations cœur, la source de la marge de l’entreprise) avec une préparation des données élevée. Son seul point faible est la faisabilité, qui est moyenne – donc le risque à gérer est la livraison, pas de savoir si le gain est réel.

Sur le niveau d’investissement face à la maturité du secteur (tâche 2.3.4) : dans un secteur manufacturier mature et à faibles marges, le geste défendable est d’investir là où l’IA protège le cœur, pas de courir après le cas d’usage le plus visible. « Les concurrents investissent lourdement » est une raison d’investir délibérément, pas une raison de choisir l’option la plus brillante.

Les deux autres ne sont pas simplement rejetées. Le langage de l’examen est scale, pause ou terminate (tâche 2.1.3). C est peu coûteuse, certaine et à faible risque : financez-la sur le budget d’exploitation comme gain rapide plutôt que dans le créneau stratégique, ou suspendez-la au prochain cycle. B repose sur des chiffres mous : suspendez-la et renvoyez le champion établir une référence propre et un pilote mesuré avant qu’elle ne concoure de nouveau pour de l’argent – ne terminez pas une idée plausible faute de mesure.

Recommandation, séquencée.

1. Financer A (maintenance prédictive) comme initiative stratégique : valeur la plus élevée, adéquation stratégique la plus forte, préparation des données élevée, ROI ~300 % la première année.
2. Gérer le risque de faisabilité d’A : étaler le build, conditionner la dépense sur une preuve face aux données réelles de ligne, et fixer une revue scale/pause/terminate à la frontière du pilote.
3. Approuver C comme gain rapide à faible coût sur le budget d’exploitation si la trésorerie le permet – elle est presque gratuite et s’autofinance – sinon la mettre en file.
4. Suspendre B : la renvoyer au champion avec l’exigence d’établir une référence et un pilote mesuré ; réévaluer au prochain cycle sur des chiffres durs.
5. Présenter les trois au conseil sur une seule page avec les scores à quatre critères et les calculs de ROI, pour que la décision soit lisible et que la préférence du COO soit traitée avec transparence.

À quoi ressemble une réponse plus faible, et pourquoi.

• « Financer le sales-copilot ; c’est ce que veut le COO et c’est visible. » Substitue la préférence du sponsor et la visibilité aux quatre critères, et fonde le dossier sur des chiffres mous qui deviennent négatifs dans un scénario défavorable réaliste.
• « Financer les trois à périmètre réduit. » Étale un budget unique sur trois efforts à moitié dotés, dont aucun n’atteint l’échelle nécessaire pour prouver la valeur ; viole la logique du commencer-avec-un-focus.
• « Terminer B et C ; seule A compte. » Élague trop : C est presque gratuite et certaine, et B est une idée plausible qui manque seulement de mesure. Suspendez, ne tuez pas.
• « Choisir C parce qu’elle est la plus sûre et la moins chère. » Optimise la certitude au détriment de la valeur et de l’alignement stratégique ; le plus petit gain, le moins stratégique, ne devrait pas consommer le créneau stratégique.

Quels domaines et tâches cela exerce. D2 2.1.2 (build-buy-partner implicite dans chaque), 2.1.3 (prioriser ; scale/pause/terminate), 2.2.3 (ROI), 2.3.4 (niveau d’investissement vs maturité du secteur) ; D4 4.4.2 (commencer par des gains à court terme) pour le traitement de C.

Trois questions de style examen sur ce cas.

---

Case 3 · Le modèle de tri exact que le conseil clinique n’approuvera pas

Situation. Caldera Health gère des cliniques de soins urgents et une ligne de tri téléphonique menée par des infirmiers. Un partenaire data-science a construit un modèle de tri qui recommande une orientation – auto-soins, prendre rendez-vous chez un médecin généraliste, ou aller aux urgences – à partir des symptômes décrits par le patient. Sur un jeu de test réservé, il est exact à 91 %, mieux que les 84 % mesurés du protocole actuel. Le sponsor du programme, le Chief Operating Officer, y voit un moyen de réduire le temps de tri et d’absorber une demande croissante, et veut déployer.

Le conseil de gouvernance clinique refuse de l’approuver. Son objection n’est pas le chiffre d’exactitude. C’est que le modèle est une boîte noire : quand il recommande « auto-soins » pour un patient qu’un infirmier aurait escaladé, aucun clinicien ne peut voir pourquoi, et les 9 % d’erreurs ne sont pas réparties uniformément – une revue échantillonnée suggère que le modèle sous-trie certaines présentations plus que d’autres. Dans un contexte critique pour la sûreté et réglementé, une recommandation « auto-soins » erronée est l’erreur qui blesse.

Le sponsor argue que 91 % bat 84 % et que le conseil est trop averse au risque. Le partenaire data-science propose un modèle plus exact mais encore moins interprétable. Vous êtes le responsable de stratégie IA à qui l’on demande de dénouer l’impasse.

Ce qu’on vous demande. Recommander comment procéder pour que le gain d’exactitude ne soit pas perdu et que les préoccupations du conseil clinique soient véritablement satisfaites.

Les preuves dont vous disposez.

Fait	Valeur (illustrative)
Exactitude du modèle (jeu réservé)	91 %
Exactitude du protocole actuel	84 %
Distribution des erreurs	Inégale ; sous-tri concentré sur certaines présentations
Explicabilité	Faible – pas de justification par décision
Contexte	Critique pour la sûreté, réglementé (clinique)
Erreur au plus fort préjudice	Faux « auto-soins » pour un patient nécessitant une escalade
Alternative proposée	Plus exacte, moins interprétable

Analyse. Le conseil a raison, et l’examen attend que vous en voyiez la raison. Dans un domaine critique pour la sûreté, la question pertinente n’est pas « l’exactitude agrégée est-elle plus élevée ? » mais « quelle est la distribution du coût des erreurs, et un humain peut-il superviser la décision ? » (tâches 3.1.1, 3.1.2, 3.1.4). L’exactitude agrégée cache l’erreur qui compte : un sous-tri dans la classe au plus fort préjudice. Un modèle exact à 91 % au global mais qui concentre ses erreurs dans « renvoyé chez lui un patient qui avait besoin de soins » n’est pas plus sûr qu’un protocole à 84 % dont les erreurs sont plus bénignes.

Nommez le compromis explicitement (tâche 3.1.2) : explicabilité versus performance brute. L’alternative plus exacte et moins interprétable va dans le mauvais sens. Dans un contexte clinique réglementé, un clinicien doit pouvoir comprendre et, au besoin, outrepasser une recommandation ; l’explicabilité est une exigence, pas un agrément, car c’est elle qui rend la supervision humaine réelle plutôt que nominale.

Appliquez une lentille de classification des risques (tâche 3.2.4) : un tri clinique qui peut renvoyer un patient chez lui est à haut risque selon tout niveau. Les cas d’usage à haut risque portent des obligations – supervision humaine, explicabilité, monitoring, validation documentée – quelle que soit la belle apparence de l’exactitude. La gouvernance dès la conception (tâche 3.1.3) signifie que c’étaient des exigences à intégrer dès le départ, pas des points à débattre à la fin.

Le recadrage qui débloque l’impasse : le modèle n’a pas à remplacer le jugement de l’infirmier pour ajouter de la valeur. Déployé comme aide à la décision avec supervision humaine – le modèle suggère, l’infirmier décide, avec une règle d’escalade voulant que toute suggestion « auto-soins » outrepassant l’instinct d’un infirmier soit revue – vous captez le gain d’exactitude sur la majorité bénigne pendant qu’un clinicien couvre la queue nuisible. Ajoutez l’explicabilité et le monitoring dont le conseil a besoin, et son objection est satisfaite sur le fond.

Recommandation, séquencée.

1. Rejeter le remplacement boîte noire ; rejeter l’alternative plus-exacte-moins-interprétable pour ce cas d’usage.
2. Reclasser le cas d’usage comme à haut risque et attacher les obligations : supervision humaine, explicabilité, monitoring des biais/erreurs par type de présentation, validation clinique documentée.
3. Déployer comme aide à la décision, pas décideur : le modèle recommande, un infirmier décide, avec une règle d’escalade dure sur toute classe sujette à erreur ou à fort préjudice.
4. Ajouter des explications par décision (ou un modèle qui en fournit) pour que la supervision soit réelle ; mesurer la distribution des erreurs, pas seulement l’agrégat.
5. Superviser en production la dérive d’erreur, surtout dans les classes de sous-tri, et donner au conseil une revue permanente.
6. Emmener le sponsor en montrant que ce chemin garde l’essentiel du gain d’exactitude tout en rendant le risque défendable – un déploiement que le conseil approuve bat un modèle supérieur qu’il bloque.

À quoi ressemble une réponse plus faible, et pourquoi.

• « Déployez-le ; 91 % bat 84 %. » Compare des agrégats et ignore que les erreurs se concentrent dans la classe au plus fort préjudice. Une exactitude moyenne plus élevée n’est pas une sûreté plus élevée.
• « Adopter le modèle plus exact et moins interprétable. » Optimise le mauvais axe ; moins d’interprétabilité affaiblit la supervision humaine dans exactement le contexte qui en a le plus besoin.
• « Garder le protocole manuel ; l’IA est trop risquée pour le travail clinique. » Écarte un gain réel dont la majorité des patients bénéficierait ; la réponse est la supervision, pas l’abstention.
• « Laisser le conseil l’approuver avec un avertissement. » Un avertissement n’est pas une supervision ; il transfère la responsabilité sans ajouter de garantie ni d’explicabilité.

Quels domaines et tâches cela exerce. D3 3.1.1 (dimensions d’IA responsable : explicabilité, sûreté), 3.1.2 (objectif métier vs compromis d’IA responsable), 3.1.3 (gouvernance dès la conception), 3.1.4 (supervision humaine et escalade), 3.2.4 (classification des risques) ; D3 3.3.2 (erreur/biais inégal tout au long d’un cycle de vie) et 3.3.4 (fiabilité).

Trois questions de style examen sur ce cas.

---

Case 4 · Du shadow AI partout et une clause de confidentialité

Situation. Aldergate Advisory est un cabinet de services professionnels d’environ 800 consultants. Il n’y a aucune politique d’IA. Une enquête interne discrète révèle que 62 % des consultants utilisent déjà des outils d’IA grand public quotidiennement – résumer des documents clients, rédiger des livrables, générer du code – en collant ce sur quoi ils travaillent dans des outils de chat publics gratuits. Les anecdotes de productivité sont élogieuses.

Le problème a émergé quand un associé a réalisé qu’un consultant avait collé le document de stratégie confidentiel d’un client dans un outil gratuit dont les conditions permettent au fournisseur d’utiliser les entrées pour améliorer ses modèles. Le contrat d’engagement de ce client contient une clause de confidentialité explicite et une interdiction de divulguer son matériel à des tiers. Le cabinet est peut-être déjà en infraction.

L’instinct des dirigeants se divise en deux. L’associé risque veut interdire tous les outils d’IA immédiatement. Le responsable du conseil veut ne rien faire parce que les gains de productivité sont réels et qu’une interdiction serait de toute façon ignorée. L’associé gérant vous demande, en tant que conseiller en gouvernance IA, un chemin qui ne perde ni la productivité ni ne courtise la prochaine infraction.

Ce qu’on vous demande. Recommander une réponse de gouvernance qui gère le risque de confidentialité et de PI sans pousser le comportement davantage dans la clandestinité.

Les preuves dont vous disposez.

Fait	Valeur (illustrative)
Consultants	800
Utilisant déjà l’IA quotidiennement (enquête)	62 % (~496 personnes)
Politique d’IA en place	Aucune
Outil utilisé	Outil public gratuit ; les conditions permettent l’entraînement sur les entrées
Événement déclencheur	Document client confidentiel collé dans un outil public
Position contractuelle	Clause de confidentialité ; divulgation à des tiers interdite
Options des dirigeants sur la table	Tout interdire / ne rien faire

Analyse. Les deux instincts sont mauvais pour la même raison : ils ignorent comment se comporte le shadow AI. Une interdiction générale n’arrête pas l’usage ; elle arrête l’usage visible, poussant 496 personnes sur des appareils personnels où vous n’avez aucun contrôle et aucun journal – l’opposé de la gouvernance (tâche 1.2.4). Ne rien faire accepte une infraction contractuelle en cours. La réponse de l’examen au shadow AI n’est ni l’interdiction ni la permissivité ; c’est la classification transparente – une liste publiée d’outils approuvés, bloqués et en évaluation – associée à une règle d’usage acceptable claire sur quelles données peuvent entrer dans quelle classe d’outil.

La distinction porteuse n’est pas « IA bonne/mauvaise » mais la classification des données rencontrant la classification des outils. Le matériel confidentiel client ne doit jamais entrer dans un outil dont les conditions permettent l’entraînement sur les entrées ; c’est le risque de PI et de confidentialité (tâche 3.3.3) qui a causé l’incident. Le remède est de fournir une alternative approuvée et gouvernée – un outil aux conditions qui n’entraînent pas sur les entrées et avec des contrôles d’accès – pour que la voie sanctionnée soit aussi la voie facile. Une gouvernance qui ne dit que « non » pousse au shadow AI ; une gouvernance qui dit « oui, ici, en sécurité » y met fin.

La structure suit (tâche 3.2.1) : un petit groupe propriétaire transverse – risque, juridique, un responsable technologie, et une voix de consultant respectée – qui maintient la liste des outils, fixe les règles de données, et exécute une voie d’exception rapide pour qu’un « non » soit rare et un « pas encore » rapide. Et parce que le comportement est déjà universel, le correctif durable est l’habilitation (tâche 4.3.5) : dire aux gens clairement ce qu’ils peuvent et ne peuvent pas faire, pourquoi le contrat client compte, et les former – plutôt que de supposer qu’un PDF de politique changera les habitudes.

Le problème contractuel immédiat est distinct et urgent : le juridique doit évaluer l’infraction possible, si une notification du client est requise, et le confinement, en parallèle de la construction de la gouvernance.

Recommandation, séquencée.

1. Contenir l’incident maintenant : le juridique évalue l’infraction et les obligations de notification pour le client concerné ; émettre une règle intérimaire immédiate voulant qu’aucun matériel confidentiel client n’entre dans un outil public.
2. Publier une classification des outils – approuvés / bloqués / en évaluation – et monter un outil approuvé et gouverné dont les conditions n’entraînent pas sur les entrées.
3. Écrire une courte règle d’usage acceptable indexée sur la classification des données : quelle classe de données peut entrer dans quelle classe d’outil ; les données confidentielles client uniquement dans l’outil approuvé et gouverné.
4. Former le groupe propriétaire transverse avec une voie d’exception rapide pour que la route sanctionnée soit le chemin de moindre résistance.
5. Habiliter la main-d’œuvre : communiquer le pourquoi (le contrat client), former sur les règles, et rendre l’outil approuvé véritablement bon pour que l’usage clandestin n’ait aucune raison de persister.
6. Superviser l’adoption de l’outil approuvé comme le signal que l’usage clandestin recule.

À quoi ressemble une réponse plus faible, et pourquoi.

• « Interdire tous les outils d’IA immédiatement. » Met fin à l’usage visible, pas à l’usage ; 496 personnes passent sur des appareils personnels et vous perdez tous les journaux et le contrôle – de la gouvernance de nom seulement.
• « Ne rien faire ; la productivité en vaut la peine. » Accepte une infraction contractuelle en cours et garantit une récidive avec un client plus important.
• « Écrire un PDF de politique et l’envoyer par e-mail. » Un document n’est pas un modèle opérationnel ; sans alternative approuvée ni habilitation, les habitudes ne changent pas.
• « Fine-tuner un modèle privé pour que les données restent en interne. » Sur-ingénierié pour le vrai problème (les gens ont besoin d’un outil quotidien sûr maintenant) et ne traite ni l’infraction immédiate ni le comportement de données-dans-des-outils-publics.

Quels domaines et tâches cela exerce. D1 1.2.4 (classification du shadow AI : approuvés/bloqués/en évaluation) ; D3 3.2.1 (structure de gouvernance avec redevabilité transverse), 3.2.3 (mesures d’accès/sécurité des données au niveau stratégique), 3.3.3 (risque de PI et de confidentialité) ; D4 4.3.5 (habilitation de la main-d’œuvre), 4.3.3 (communication transparente).

Trois questions de style examen sur ce cas.

---

Case 5 · Le pilote réussi qui ne peut pas passer à l’échelle

Situation. Trellis Logistics a mené un pilote de six mois que tout le monde qualifie de succès. Un outil de traitement documentaire génératif lit la paperasse des transporteurs, extrait les données d’expédition et signale les exceptions ; dans un hub régional, il a réduit la saisie manuelle et accéléré le traitement des exceptions. Le responsable régional est ravi et le CEO veut le déployer dans les quatorze hubs d’ici la fin de l’année.

Quand vous regardez sous le pilote, le tableau d’état de préparation est mince. Le pilote a tourné sur des données exportées à la main du système d’un hub par un analyste qui a depuis changé d’équipe ; il n’y a pas de propriétaire. Chaque hub stocke sa paperasse différemment, dans des silos qui ne communiquent pas. Le coût du pilote était faible parce que le volume était faible, et l’outil est facturé sur une base à la consommation – par document traité – donc le coût croît linéairement avec l’augmentation de volume par quatorze, sans remise d’engagement en place. Personne n’a défini qui possède l’outil, les données ou les exceptions une fois à l’échelle de l’entreprise.

Le CEO lit le succès du pilote comme la preuve que le déploiement fonctionnera. L’examen veut que vous voyiez l’écart entre un pilote qui a prouvé la faisabilité à un endroit et un déploiement d’entreprise qui a besoin d’un état de préparation partout.

Ce qu’on vous demande. Recommander s’il faut déployer dans les quatorze hubs maintenant, et ce qui doit être vrai avant de mettre à l’échelle.

Les preuves dont vous disposez.

Fait	Valeur (illustrative)
Périmètre du pilote	1 hub sur 14, 6 mois
Source de données dans le pilote	Exportée à la main par un analyste (désormais parti)
Données à travers les hubs	Silotées, formats incohérents
Propriétaire de l’outil/données/exceptions	Aucun défini
Modèle de tarification	À la consommation (par document), sans remise d’engagement
Coût mensuel du pilote	8 k$ au volume du pilote
Augmentation de volume au déploiement complet	~14×
Cible du CEO	Les 14 hubs d’ici la fin de l’année

Analyse. Utilisez les phases du CAF comme modèle mental (tâches 4.4.1, 4.4.5) : le pilote est un artefact de la phase Launch – il a démontré une valeur incrémentale en production à un endroit. La mise à l’échelle est la phase Scale, et l’examen est explicite que la transition de l’expérimental vers la qualité production requiert des fondations de gouvernance et d’exploitation que le pilote a sautées. Évaluez l’état de préparation selon les dimensions que le guide nomme (tâche 4.1.1) et les perspectives du CAF (tâches 4.2.x) : le pilote est fort sur la valeur Product mais faible sur Platform (silos de données), Operations (pas de propriétaire) et Governance (pas de redevabilité pour les exceptions).

Les deux écarts durs sont les données et la propriété (tâches 4.2.1, 4.2.2). Quatorze silos aux formats incohérents signifient que la chose qui a rendu le pilote facile – un export à la main propre unique – n’existe pas à l’échelle. Et un export à la main par une personne partie n’est pas une stratégie de données ; le déploiement d’entreprise a besoin d’une propriété des données définie et d’un cadre de partage, pas d’exploits héroïques.

La structure de coût est le piège que le CEO manquera (tâches 2.2.5, 2.1.5). En tarification à la consommation, le coût mensuel croît environ avec le volume : 8 k$ × 14 ≈ 112 k$/mois, soit ~1,34 M$/an, sans plancher ni remise. C’est là que les structures de tarification d’AWS comptent au niveau stratégique : un arrangement à l’engagement (s’engager sur un volume contre une remise) peut réduire matériellement le coût d’un usage prévisible, fort et régulier – mais s’engager avant de connaître le vrai volume en régime permanent risque de payer une capacité que vous n’utilisez pas. Le raisonnement stratégique est : prouver le volume en régime permanent, puis décider si un engagement bat la consommation. Mettre à l’échelle d’abord et optimiser le coût jamais est la façon dont un « pilote réussi » devient une surprise budgétaire.

Recommandation, séquencée.

1. Ne pas déployer dans les quatorze hubs maintenant. Le pilote a prouvé la faisabilité à un endroit, pas l’état de préparation partout.
2. Corriger d’abord les fondations : assigner un propriétaire pour l’outil, les données et le processus d’exception ; définir une propriété des données et un cadre de partage ; traiter le silo et l’incohérence de format pour que l’outil ait une entrée fiable partout.
3. Modéliser le coût à l’échelle honnêtement : ~112 k$/mois en tarification à la consommation, et décider la stratégie de tarification seulement après avoir observé le vrai volume multi-hubs – consommation tant que le volume est incertain, un engagement une fois le régime permanent connu.
4. Mettre à l’échelle par vagues, en commençant par des gains à court terme (tâche 4.4.2) : un deuxième et un troisième hub ensuite, chacun prouvant que les fondations tiennent, avant un déploiement à l’échelle de l’entreprise.
5. Fixer des métriques de succès et un mécanisme de feedback (tâche 4.4.4) pour que chaque vague soit un point de contrôle, pas un saut.
6. Emmener le CEO : cadrer cela comme protégeant le gain du pilote, pas le ralentissant – un déploiement non gouverné de quatorze hubs est le moyen le plus rapide vers un échec public.

À quoi ressemble une réponse plus faible, et pourquoi.

• « Déployer dans les quatorze hubs maintenant ; le pilote a réussi. » Confond faisabilité-à-un-endroit et état-de-préparation-partout ; les silos de données, le propriétaire manquant et le coût linéaire ne sont pas traités.
• « Signer un gros contrat d’engagement pour réduire le coût par document avant le déploiement. » S’engage sur un volume que vous n’avez pas vérifié ; si le volume réel est plus faible, vous payez une capacité inutilisée – optimiser le coût avant de prouver l’usage.
• « Refaire simplement le même export à la main dans chaque hub. » Dépend d’exploits héroïques et d’une personne partie ; pas une stratégie de données et pas reproductible sur quatorze sites.
• « Nommer un propriétaire et déployer simultanément. » Nomme un propriétaire mais ignore toujours les problèmes de silo de données et de coût à l’échelle ; la propriété seule ne rend pas les données d’entrée utilisables partout.

Quels domaines et tâches cela exerce. D4 4.1.1 (dimensions d’état de préparation), 4.2.1 (silos de données), 4.2.2 (propriété et partage des données), 4.4.1/4.4.5 (mise à l’échelle par phases ; expérimental vers qualité production), 4.4.2 (gains à court terme), 4.4.4 (feedback et métriques) ; D2 2.1.5 (considérations de transition), 2.2.5 (planification des coûts et structure de tarification).

Trois questions de style examen sur ce cas.

---

Case 6 · Adoption bloquée à 11 % et la technologie fonctionne

Situation. Fenwick Insurance est à dix-huit mois dans une transformation par l’IA. Elle a acheté des licences d’entreprise pour un assistant génératif destiné à 3 000 travailleurs du savoir, organisé un événement de lancement et publié un portail de formation. La technologie fonctionne bien ; une preuve de concept dans les sinistres a montré de réelles économies de temps, et l’outil est stable et bien noté par ceux qui l’utilisent.

Le problème est que presque personne ne l’utilise. La télémétrie montre que 11 % des utilisateurs sous licence sont actifs sur un mois donné, et l’usage actif est concentré dans deux équipes enthousiastes. Le reste l’a essayé une fois ou ne s’est jamais connecté. Le directeur financier demande pourquoi le cabinet paie 3 000 sièges pour obtenir 330 utilisateurs. L’instinct du sponsor de la transformation est d’acheter plus de formation et d’envoyer un autre e-mail à tout le personnel.

Vous menez des entretiens à travers le métier. Le motif n’est pas un problème de technologie. Les managers ne l’utilisent pas eux-mêmes et ne le demandent pas à leurs équipes ; certains s’inquiètent en silence que cela fasse paraître leur expertise remplaçable. Le personnel de première ligne ne sait pas si l’utiliser est encouragé ou un raccourci qui leur sera reproché, et plusieurs craignent que ce soit un prélude à des coupes d’emplois – une crainte que personne n’a adressée. Les deux équipes à forte adoption ont toutes deux un manager qui incarne le comportement et quelques champions informels.

Ce qu’on vous demande. Recommander comment faire bouger l’adoption, étant donné que la technologie n’est pas la contrainte.

Les preuves dont vous disposez.

Fait	Valeur (illustrative)
Sièges sous licence	3 000
Utilisateurs actifs mensuels	11 % (~330)
Où l’adoption est forte	2 équipes avec un manager qui incarne + des champions
Qualité de la technologie	Bonne ; stable ; la POC a montré de réelles économies
Formation fournie	Portail + événement de lancement
Comportement des managers	Majoritairement ne l’utilisent pas, ne le demandent pas aux équipes
Crainte non adressée	Sécurité de l’emploi / impact sur les rôles
Tarification des sièges	Au siège (payer par licence quel que soit l’usage)

Analyse. Le matériel de conduite du changement de l’examen (tâche 4.3) est conçu exactement pour cela : la technologie fonctionne, la valeur est prouvée, et l’adoption stagne quand même parce que le système humain n’a pas été mené. Plus de formation et un autre e-mail traitent un problème de leadership et de culture comme un problème d’information – et les preuves disent que l’information n’est pas l’écart, car les deux équipes qui ont réussi n’ont pas reçu plus de formation ; elles avaient un manager qui incarnait le comportement et des champions qui l’ont normalisé.

Diagnostiquez les barrières par leur nom (tâche 4.3.4) : le comportement des managers (des leaders qui ne l’utilisent pas signalent que c’est optionnel), la crainte sur l’impact sur les rôles (une anxiété non adressée sur la sécurité de l’emploi supprime l’usage), et l’absence de champions hors des deux équipes. La structure de coût au siège aiguise l’urgence – le cabinet paie 3 000 sièges qu’ils soient utilisés ou non, donc à, illustrativement, 100 $/siège/mois la facture de licence annuelle est 3 000 × 100 $ × 12 = 3,6 M$/an, dont ~89 % (≈3,2 M$) est oisif à 11 % d’adoption – mais le coût est le symptôme, pas le levier.

Les leviers sont comportementaux. Sponsorship exécutif et modélisation par les managers (tâche 4.3.1) : faire que les managers l’utilisent et l’attendent de leurs équipes, car les équipes qui réussissent montrent que c’est la différence. Champions (tâche 4.3.1) : recruter et habiliter les enthousiastes informels en réseau, pas en coup ponctuel. Communication transparente sur l’impact sur les rôles (tâche 4.3.3) : adresser la crainte de la sécurité de l’emploi directement et honnêtement – à quoi sert l’outil, comment les rôles évoluent vers la supervision et un travail à plus forte valeur (tâche 4.3.6), et ce qui n’arrivera pas – car une crainte tue est un frein plus fort que n’importe quelle fonctionnalité manquante. Et mesurer des indicateurs avancés (tâches 2.2.4, 4.4.4) : usage actif hebdomadaire par équipe, usage des managers, activité des champions – des signaux qui prédisent l’adoption – plutôt que d’attendre un chiffre de productivité retardé.

Recommandation, séquencée.

1. Stopper la dépense réflexe sur plus de formation générique et des e-mails de masse ; ils adressent un écart qui n’est pas la contrainte.
2. Enrôler les managers comme levier principal : faire de l’usage une attente de leadership visible, et faire que les managers l’incarnent dans leur propre travail – répliquer ce qu’ont fait les deux équipes qui réussissent.
3. Construire un réseau de champions à partir des enthousiastes existants, doté et reconnu, essaimé dans chaque équipe.
4. Adresser la crainte de l’impact sur les rôles de front avec une communication honnête et transparente sur la façon dont les rôles évoluent vers la supervision et un travail à plus forte valeur, et sur l’impact sur l’emploi qui arrivera et n’arrivera pas.
5. Suivre des indicateurs avancés (usage actif hebdomadaire, usage des managers, activité des champions) par équipe et agir sur les retardataires.
6. Seulement ensuite revoir le nombre de sièges – dimensionner les licences à l’usage réel et croissant une fois les leviers comportementaux à l’œuvre, plutôt que de couper des sièges et tuer l’élan.

À quoi ressemble une réponse plus faible, et pourquoi.

• « Acheter plus de formation et envoyer un autre e-mail à tout le personnel. » Traite un problème de leadership et de culture comme un écart d’information ; les équipes qui réussissent prouvent que l’information n’a jamais été la contrainte.
• « Réduire les licences à 330 pour arrêter de gaspiller de l’argent. » Optimise le symptôme et abandonne la transformation ; économise du coût en renonçant à 90 % de la valeur visée.
• « Imposer l’usage et le suivre de façon punitive. » Un mandat sans adresser la crainte de la sécurité de l’emploi approfondit la résistance et produit du jeu, pas une adoption véritable.
• « Attendre la métrique de productivité retardée avant d’agir. » Les indicateurs avancés existent précisément pour ne pas attendre ; le temps que le chiffre retardé bouge, la dépense de licence est depuis longtemps gaspillée.

Quels domaines et tâches cela exerce. D4 4.3.1 (sponsorship, modélisation par les managers, champions), 4.3.3 (communication sur l’impact sur les rôles), 4.3.4 (barrières culturelles, intervention du leadership), 4.3.6 (faire évoluer les rôles vers la supervision) ; D2 2.2.4 (indicateurs avancés), 2.2.1 (bénéfices intangibles comme la productivité et la satisfaction) ; D4 4.4.4 (feedback et métriques de succès).

Trois questions de style examen sur ce cas.

---

Comment utiliser ces études de cas

Travaillez chaque cas avant de lire son analyse : écrivez votre recommandation, puis comparez. La compétence que récompense l’examen n’est pas de rappeler une définition – c’est de tenir plusieurs critères à la fois, de résister à la conviction figée du sponsor, de faire l’arithmétique, et de séquencer le correctif pour que les fondations viennent avant la mise à l’échelle et la gouvernance avant le lancement. Quand vous savez reconstruire la trace de raisonnement, pas seulement reconnaître la réponse, vous êtes prêt pour les items longs. Retournez à la page de domaine pertinente pour la profondeur : D1, D2, D3, D4, puis passez les examens blancs.