Frameworks AWS pour les décisions IA

Voici la référence unique pour les frameworks sur lesquels s’appuie l’examen AWS Certified AI Business Strategist (AIB-C01). Elle les présente au niveau métier que l’examen évalue — pas de parcours console, pas d’API, pas d’architecture. Tout ce qui suit est vérifié par rapport aux publications d’AWS au 15 septembre 2026 ; l’examen vous demande d’appliquer ces frameworks à des décisions, pas de citer des numéros d’article ou des décomptes de capacités. Là où la formulation du guide d’examen diffère de la formulation canonique d’AWS, les deux sont indiquées.

AWS Cloud Adoption Framework (AWS CAF)

L’AWS CAF (cadre d’adoption du cloud) est le framework que l’AIB-C01 utilise pour structurer une transformation : qui détient quoi, dans quel ordre, et comment savoir qu’une phase est terminée. Trois éléments mobiles : six perspectives (les prismes), quatre domaines de transformation (la chaîne de valeur) et quatre phases (la séquence).

Les six perspectives

Chaque perspective est un ensemble de capacités détenu par un groupe de parties prenantes. Business, People et Governance sont des perspectives de capacités métier ; Platform, Security et Operations sont des perspectives de capacités techniques. CAF 3.0 détaille 47 capacités au total ; le stratège a besoin des perspectives et des questions auxquelles elles répondent, pas de la liste des capacités.

Perspective	Ce qu’elle détient	La question à laquelle elle répond
Business	Résultats métier, réalisation de la valeur, décisions de portefeuille et d’investissement	Cette initiative IA fait-elle progresser un résultat métier qui nous importe, et pouvons-nous le prouver ?
People	Culture, structure organisationnelle, rôles, compétences, conduite du changement	Avons-nous le leadership, les compétences et la culture pour l’adopter, et qui la porte ?
Governance	Gestion de portefeuille, risque, conformité, réalisation des bénéfices	Qui est responsable, quels sont les risques, et comment gérons-nous le portefeuille ?
Platform	Architecture, ingénierie, le parc technologique	Notre socle technologique peut-il soutenir cela, et le construisons-nous ou l’achetons-nous ?
Security	Identité, contrôles, détection des menaces, assurance de conformité	Les données sont-elles protégées, les contrôles sont-ils en place, et sommes-nous conformes ?
Operations	Exécuter, observer et soutenir les charges de travail en production	Pouvons-nous l’exploiter de façon fiable en production et détecter sa dégradation ?

Signal d’examen

Les énoncés qui disent « qui devrait être responsable », « quelles parties prenantes », « quel écart de capacité » ou « évaluer la maturité sur » sont des questions de perspective CAF. Une réponse de stratège nomme la perspective et son propriétaire, pas un correctif technique.

Les quatre domaines de transformation — une chaîne de valeur

Le CAF présente la transformation comme une valeur qui circule le long d’une chaîne. Chaque étape alimente la suivante ; un maillon rompu en amont plafonne la valeur réalisable en aval.

La lecture du stratège : acheter la plateforme (Technology) sans redéfinir le workflow (Process) ni les rôles qui l’entourent (Organization) est la raison la plus fréquente pour laquelle un pilote ne devient jamais un résultat au niveau Product.

Les quatre phases — critères d’entrée et de sortie

Phase	Objet	Critères d’entrée	Critères de sortie
Envision	Identifier et prioriser les opportunités de transformation au regard des objectifs métier	Le leadership veut avancer ; les objectifs métier sont énoncés	Un ensemble priorisé d’opportunités liées à des résultats métier précis
Align	Identifier les écarts de capacité sur les six perspectives, les dépendances transverses et les préoccupations des parties prenantes	Des opportunités priorisées existent	Une cartographie des écarts et dépendances, des parties prenantes nommées, un plan d’action pour combler les écarts
Launch	Livrer des pilotes en production et démontrer une valeur incrémentale	Écarts compris, périmètre du pilote convenu, référence mesurée	Des pilotes en production avec une valeur incrémentale mesurée par rapport à la référence
Scale	Étendre les pilotes en production et la valeur métier à l’échelle visée	Un pilote a démontré sa valeur et est solide en exploitation	Valeur réalisée à l’échelle visée, avec une gouvernance et des opérations qui tiennent

Envision → Align, et non Envision → Experiment

La deuxième phase propre à l’AWS CAF est Align. Le guide d’examen AIB-C01 (tâche 4.4.1) donne une formulation exemple : « envision, experiment, launch, scale ». Traitez-la comme une reformulation approximative de la même idée itérative, et non comme un framework différent. Si un énoncé cite les quatre mots du guide, il teste toujours la séquence CAF : envisager l’opportunité, combler les écarts, prouver la valeur dans un pilote en production, puis passer à l’échelle.

AWS CAF pour l’IA, le ML et l’IA générative

AWS publie un livre blanc dédié : CAF for AI, ML and Generative AI. Il utilise les mêmes six perspectives et les mêmes quatre phases ; il n’invente pas un framework parallèle. Sa contribution est de nommer les écarts de capacité propres à l’IA à rechercher dans chaque perspective — par exemple la préparation des données et la gouvernance des modèles sous Governance, et la culture IA et l’identification des champions sous People. Pour l’examen, à retenir : la variante IA est le CAF appliqué à l’IA, donc une question sur « le framework AWS pour adopter l’IA » se répond avec les perspectives et les phases du CAF.

Évaluation d’écarts CAF, cas pratique — Meridian Logistics

Meridian Logistics veut déployer un assistant d’extraction documentaire qui lit les factures de fret. Le leadership est enthousiaste (Envision faite). Exécuter Align sur les six perspectives révèle l’état réel :

Perspective	Constat	Sévérité de l’écart
Business	Résultat nommé (réduire de 40 % le coût de traitement des factures) et référence existante	Faible
People	Aucun champion IA ; l’équipe finance craint la perte de son rôle ; aucun programme de culture IA	Élevée
Governance	Aucun propriétaire responsable ; aucune classification des risques ; aucun plan de supervision	Élevée
Platform	Utiliserait une plateforme managée ; aucun développement nécessaire	Faible
Security	Les données de factures incluent les coordonnées bancaires des fournisseurs ; aucune revue du contrôle d’accès	Moyenne
Operations	Aucun plan pour détecter la dérive de la précision d’extraction en production	Moyenne

Conclusion du stratège : la technologie est la partie facile. Meridian n’est pas prête à Launch — les deux écarts Élevés (People et Governance) doivent d’abord se combler. La recommandation : nommer un propriétaire responsable et un champion IA, animer une session de culture IA avec l’équipe finance en présentant l’assistant comme un glissement vers un travail de supervision, et définir un seuil de suivi de la précision — puis piloter. Acheter la plateforme maintenant produirait un pilote au point mort et une équipe inquiète. C’est le schéma préféré de l’examen : la bonne réponse comble les écarts People/Governance avant de toucher à la Technology.

L’IA responsable selon AWS — les huit dimensions

AWS publie huit dimensions fondamentales de l’IA responsable. Chacune porte une question métier que vous devez savoir poser, et un exemple de défaillance qui montre ce qui déraille lorsqu’on la néglige.

Dimension	Question métier	Exemple de défaillance
Fairness (équité)	Le système traite-t-il équitablement des personnes et des groupes comparables ?	Un filtre de recrutement déclasse une catégorie démographique parce que les données d’entraînement reflétaient un biais passé
Explainability (explicabilité)	Pouvons-nous expliquer pourquoi le système a produit une sortie, aux personnes concernées ?	Un refus de prêt que personne — y compris le personnel — ne peut justifier au client
Privacy and security (confidentialité et sécurité)	Les données personnelles et sensibles sont-elles protégées tout au long de leur cycle de vie ?	Des dossiers clients fuient dans les prompts et réapparaissent dans la sortie d’un autre utilisateur
Safety (sûreté)	Le système évite-t-il les comportements et sorties nuisibles ?	Un bot de support recommande une action qui endommage le compte du client
Controllability (contrôlabilité)	Les humains peuvent-ils superviser, orienter et intervenir dans le système ?	Un agent de tarification automatisé tourne sans contrôle et ne peut être suspendu pendant un incident
Veracity and robustness (véracité et robustesse)	Les sorties sont-elles exactes, et le système tient-il face aux conditions réelles et adverses ?	Une hallucination assurée est publiée comme un fait ; le modèle casse sur des entrées jamais vues
Governance (gouvernance)	Des politiques, une responsabilité et une supervision sont-elles en place sur tout le cycle de vie ?	Personne ne détient le modèle ; les incidents n’ont pas de voie d’escalade
Transparency (transparence)	Les parties prenantes sont-elles informées de comment et où l’IA est utilisée, et de ses limites ?	On ne dit pas aux clients qu’ils parlent à une IA, ni ce qu’elle ne sait pas faire

Le guide d’examen nomme un sous-ensemble de six

La liste propre au guide d’examen AIB-C01 est fairness, explainability, privacy, safety, transparency, robustness — un sous-ensemble des huit d’AWS. Apprenez les huit (l’examen peut référencer controllability, veracity et governance par le concept), et reconnaissez les six du guide comme celles les plus susceptibles d’être nommées explicitement. Le principe qu’elles partagent : l’IA responsable est une donnée d’entrée de conception, pas une revue à la fin — la tâche 3.1.3 appelle cela la governance by design (gouvernance dès la conception).

AWS Well-Architected Responsible AI Lens

Le Well-Architected Framework Responsible AI Lens est la collection de bonnes pratiques d’AWS pour construire et exploiter l’IA de façon responsable, organisée autour de la conception, du développement et de l’exploitation. Son rôle dans la boîte à outils du stratège est d’être le comment qui se place sous le quoi des huit dimensions : les dimensions vous disent que l’équité et la transparence comptent ; le Lens est là où vivent les pratiques concrètes. Dans un scénario d’examen, recourir au Responsible AI Lens est le bon réflexe quand la question est « comment opérationnaliser l’IA responsable sur tout le cycle de vie » plutôt que « quel principe s’applique ici ». Vous n’avez pas à réciter ses pratiques — vous devez savoir qu’il existe et où il s’insère.

Modèle de responsabilité partagée AWS pour les charges IA

Le partage classique oppose la sécurité du cloud (AWS) à la sécurité dans le cloud (client). Pour les charges IA la ligne se déplace selon le degré de gestion du service, mais une colonne ne bouge jamais : la responsabilité du client quant à l’usage du système et à l’adéquation de sa sortie à l’objectif.

AWS est responsable de…	Le client est responsable de…	Ce qui reste vôtre quoi qu’il arrive
La sécurité du cloud : infrastructure physique, matériel, l’exploitation du service managé	La sécurité dans le cloud : ses données, le contrôle d’accès, la configuration du service	L’adéquation du cas d’usage — décider que l’IA doit être utilisée ici
L’exploitation et le patching de la plateforme IA managée	Quelles données entrent, ainsi que leur qualité et leur classification	La supervision humaine des décisions à enjeu
La disponibilité des modèles et de l’infrastructure sous-jacents	La conformité du processus métier qui utilise la sortie	L’adéquation à l’objectif — savoir si la sortie est assez bonne pour agir

Signal d’examen

Des énoncés comme « le fournisseur gère le modèle, alors qui est responsable d’une sortie biaisée ? » testent ce modèle. La réponse est presque toujours le client — un service managé déplace la ligne opérationnelle mais n’enlève jamais la responsabilité du cas d’usage, des données que vous lui donnez et de la pertinence même du recours à l’IA.

Lecture pratique : une banque utilise un service de foundation model entièrement managé pour rédiger des explications de décisions de crédit. AWS exploite la plateforme et sécurise l’infrastructure. La banque reste responsable des données qu’elle fournit, du maintien d’un humain dans la boucle sur la décision de crédit elle-même, et de savoir si une explication rédigée par l’IA est apte à être envoyée à un régulateur. « C’est un service managé » n’est pas une défense pour une décision inéquitable ou inexpliquée.

AI Service Cards

Les AI Service Cards sont l’artefact de transparence d’AWS pour ses services et modèles IA. Chaque fiche documente trois choses :

Cas d’usage prévus et limites — à quoi le service sert et à quoi il ne devrait pas servir.
Choix de conception d’IA responsable — les décisions prises par AWS pour adresser les dimensions de l’IA responsable.
Bonnes pratiques de performance et d’optimisation — comment obtenir des résultats bons et responsables.

Pour le stratège, la Service Card est le document vers lequel pointer une conversation de gouvernance ou d’achat quand quelqu’un demande « ce service est-il approprié et sûr pour notre cas d’usage ? » Elle soutient la dimension transparency et alimente les décisions build-buy-partner et d’adéquation du cas d’usage.

Normes externes à connaître au niveau métier

L’examen attend que vous reconnaissiez ces normes et sachiez ce que chacune vous oblige à faire — pas que vous citiez des clauses.

ISO/IEC 42001 — système de management de l’IA. La norme certifiable de système de management pour l’IA, dans la même famille qu’ISO 9001 (qualité) ou ISO 27001 (sécurité de l’information). Elle définit comment une organisation gouverne l’IA sur tout son cycle de vie : politiques, rôles, traitement du risque, amélioration continue. AWS a déclaré la prendre en charge.

Ce qu’elle vous oblige à faire : mettre en place et maintenir un système de management de l’IA auditable — politiques documentées, propriétaires responsables, processus de risque — qu’un organisme de certification pourrait évaluer. Elle porte sur la façon dont vous pilotez le programme IA, pas sur un modèle particulier.

La classification des risques comme modèle mental

Quel framework mobiliser, et quand

La décision devant vous	Mobiliser	Pourquoi
Structurer un programme d’adoption de l’IA de bout en bout	AWS CAF (perspectives, domaines, phases)	Il séquence le travail et attribue la responsabilité
Évaluer la maturité et les écarts de capacité	La phase CAF Align sur les six perspectives	Les écarts se trouvent par perspective
Décider comment construire de façon responsable sur tout le cycle de vie	Well-Architected Responsible AI Lens	Il porte les bonnes pratiques opérationnelles
Décider si un usage est responsable	Les huit dimensions de l’IA responsable	Ce sont les principes à appliquer
Classer et prioriser le risque IA	Les niveaux de l’EU AI Act ou le NIST AI RMF	Obligations par niveau ; fonctions de risque sur le cycle de vie
Mettre en place un programme de gouvernance auditable	ISO/IEC 42001	La norme certifiable de système de management
Établir une terminologie IA partagée	ISO/IEC 23053	Le cadre et le vocabulaire des systèmes ML
Juger qui est responsable d’un service IA managé	Modèle de responsabilité partagée	Il trace la ligne de responsabilité
Décider si un service convient à un cas d’usage	AI Service Cards	Usage prévu, limites, choix de conception

Points clés

AWS CAF = six perspectives (Business, People, Governance, Platform, Security, Operations) × quatre domaines de transformation (Technology → Process → Organization → Product) × quatre phases (Envision → Align → Launch → Scale). La valeur ne peut sauter une étape de transformation, et chaque phase a des critères d’entrée et de sortie.
Le « envision, experiment, launch, scale » du guide est une formulation approximative des phases CAF, dont la vraie deuxième phase est Align.
AWS publie huit dimensions de l’IA responsable ; le guide d’examen en nomme un sous-ensemble de six — apprenez les huit et traitez l’IA responsable comme une governance by design.
Le Well-Architected Responsible AI Lens est le comment (bonnes pratiques du cycle de vie) sous le quoi (les dimensions).
Le modèle de responsabilité partagée déplace la ligne opérationnelle pour les services managés mais n’enlève jamais la responsabilité du client quant à l’adéquation du cas d’usage, la supervision humaine et l’adéquation à l’objectif.
Les AI Service Cards documentent l’usage prévu, les limites et les choix de conception d’IA responsable — votre référence de transparence et d’achat.
Reconnaissez ISO/IEC 42001 (système de management de l’IA certifiable), ISO/IEC 23053 (cadre et vocabulaire ML), NIST AI RMF (Govern-Map-Measure-Manage) et les niveaux de risque de l’EU AI Act, et sachez ce que chacun vous oblige à faire.