# D1 · AI Fundamentals and Literacy Le vocabulaire métier de l’IA, du ML et de la GenAI, les types et la qualité des données, l’entraînement sur données historiques, les standards mondiaux, l’automatisation par règles face à l’IA, les agents, la supervision, le shadow AI, le prompting, les tokens et l’adaptation des modèles. import { Accordions, AccordionItem } from '@prosefly/astro-components'; Ce domaine pèse **24 %** du blueprint — soit environ **20 des 85 items** de notre examen blanc. Ce n’est pas un examen technique : il vérifie qu’un dirigeant métier possède assez de *littératie* (culture de base) pour tenir une conversation franche avec une équipe technique, choisir le bon type de solution, et savoir ce qu’il faut demander et ce dont il faut se méfier. On ne vous demandera pas de dériver un algorithme ; on vous demandera quel vocabulaire s’applique, quand l’IA est le mauvais outil, ce que l’autonomie d’un agent vous coûte en supervision, et pourquoi un modèle qui fonctionnait en janvier se dégrade silencieusement d’ici juin. Tout le domaine récompense une seule habitude : comprendre l’IA assez bien pour prendre une décision, sans prétendre être ingénieur. ## Ce qu’il faut savoir L’IA est le concept englobant ; le machine learning (apprentissage automatique) est de l’IA qui apprend des motifs à partir de données ; la generative AI est du ML qui produit du contenu nouveau. Un modèle est entraîné sur des données historiques, puis utilisé en inférence pour faire des prédictions — il hérite donc de tout ce que les données d’entraînement ont encodé, y compris le biais d’hier. Le type de données (structurées ou non structurées) et la qualité des données déterminent les résultats davantage que le choix du modèle. L’automatisation par règles bat l’IA chaque fois que la logique est déterministe et auditable ; l’IA gagne sa place là où les motifs sont trop variés pour être énumérés. Parce que le monde bouge et que les modèles non, toute solution d’IA a besoin d’une supervision continue de la dérive (drift), et toute organisation a besoin d’une liste de classification transparente des outils pour maîtriser le shadow AI. ## Objectifs d’apprentissage À la fin de cette page, vous devriez pouvoir : 1. **Employer** correctement le vocabulaire métier fondamental de l’IA — algorithme, modèle, entraînement, inférence, prédiction — et situer l’IA, le ML et la GenAI dans leur relation imbriquée. 2. **Distinguer** les données structurées des données non structurées et expliquer pourquoi le type et la qualité des données déterminent les résultats de l’IA. 3. **Expliquer** ce qu’implique pour une entreprise l’entraînement sur données historiques : représentativité, fraîcheur, boucles de rétroaction et biais hérité. 4. **Décrire** au niveau métier à quoi *servent* ISO/IEC 23053 et ISO/IEC 42001. 5. **Décider** quand l’automatisation par règles est le bon outil et quand l’IA est le mauvais. 6. **Distinguer** les agents d’IA des autres solutions d’IA et raisonner sur les conséquences de l’autonomie en matière de gouvernance. 7. **Spécifier** la supervision continue qu’un responsable métier doit exiger : dérive du modèle, dérive des données et dégradation des performances. 8. **Établir** une classification transparente des outils d’IA (approuvés / bloqués / en évaluation) pour atténuer le risque de shadow AI. 9. **Appliquer** les principes de base de l’ingénierie de prompt et expliquer les limites de tokens et de fenêtre de contexte comme des contraintes métier. 10. **Choisir** entre prompting, RAG et fine-tuning sur le coût, l’effort, la fraîcheur et le contrôle. ## Énoncés de tâches couverts | Tâche / compétence officielle | Où cette page l’enseigne | | --- | --- | | 1.1.1 Concepts fondamentaux de l’IA en contexte métier | 1.1 | | 1.1.2 Distinguer IA, ML et GenAI | 1.1 | | 1.1.3 Données structurées vs non structurées | 1.2 | | 1.1.4 Pourquoi la qualité des données compte | 1.2 | | 1.1.5 Entraîner un modèle sur des données historiques | 1.3 | | 1.1.6 Cadres mondiaux et vocabulaire unifié (ISO/IEC 23053, ISO/IEC 42001) | 1.4 | | 1.2.1 Automatisation par règles vs IA | 1.5, Cadre de décision | | 1.2.2 Agents d’IA vs autres solutions d’IA ; capacités des agents | 1.6 | | 1.2.3 Supervision continue ; dérive du modèle et évolution des performances | 1.7 | | 1.2.4 Classification transparente des outils ; risque de shadow AI | 1.8 | | 1.3.1 Principes de base de l’ingénierie de prompt | 1.9 | | 1.3.2 Limites de tokens et contraintes de fenêtre de contexte | 1.10 | | 1.3.3 Adaptation des modèles (RAG, fine-tuning) | 1.11 | --- ## 1.1 AI, ML, GenAI and the words that trip leaders up L’examen attend que vous employiez cinq mots avec précision et que vous placiez trois domaines dans leur ordre imbriqué. Se tromper de vocabulaire est le moyen le plus rapide de perdre la confiance d’une équipe technique — et de cocher une mauvaise réponse. | Terme | Sens en langage clair | Analogie métier | | --- | --- | --- | | **Algorithme** | La méthode ou la recette pour apprendre ou décider | Le programme d’entraînement, pas l’athlète | | **Modèle** | L’artefact entraîné qui fait des prédictions | L’athlète après l’entraînement | | **Entraînement** | Ajuster le modèle aux données historiques | Les mois de pratique | | **Inférence** | Utiliser le modèle entraîné sur une nouvelle entrée | Le jour de la course | | **Prédiction** | La sortie du modèle pour une entrée donnée | Le résultat d’une course | Les trois domaines sont imbriqués, non concurrents : ```text ┌──────────────────────────────────────────────┐ │ ARTIFICIAL INTELLIGENCE │ │ systems that perform tasks needing │ │ human-like judgement │ │ ┌──────────────────────────────────────┐ │ │ │ MACHINE LEARNING │ │ │ │ learns patterns from data instead │ │ │ │ of being explicitly programmed │ │ │ │ ┌──────────────────────────────┐ │ │ │ │ │ GENERATIVE AI │ │ │ │ │ │ ML that generates new content │ │ │ │ │ │ (text, image, audio, code) │ │ │ │ │ └──────────────────────────────┘ │ │ │ └──────────────────────────────────────┘ │ └──────────────────────────────────────────────┘ ``` Un moteur de recommandation est du ML mais pas de la GenAI. Un moteur de règles qui signale les transactions dépassant un seuil n’est ni du ML ni de la GenAI — c’est de l’automatisation déterministe. La GenAI est un sous-ensemble du ML, lui-même sous-ensemble de l’IA ; l’examen pénalise le réflexe de tout appeler « IA ». :::tip[Signal d’examen] Les énoncés qui disent **« le système apprend à partir d’exemples »** pointent vers le ML ; **« génère un brouillon / un résumé / une image / du contenu nouveau »** pointe vers la GenAI ; **« applique un ensemble fixe de règles »** pointe vers l’automatisation par règles, qui n’est pas de l’IA du tout. Des mots comme *train, infer, predict* sont employés avec précision — lisez-les au pied de la lettre. ::: ## 1.2 Structured vs unstructured data, and why quality drives outcomes Le type de données détermine quelle solution est seulement possible, et la qualité des données plafonne la qualité du résultat quel que soit le modèle. | | Données structurées | Données non structurées | | --- | --- | --- | | Forme | Lignes et colonnes, champs fixes | Texte libre, images, audio, vidéo, documents | | Exemples | Transactions, fiches CRM, relevés de capteurs | E-mails, contrats, enregistrements d’appels, photos | | Adéquation classique | ML classique, tableaux de bord BI | GenAI, vision par ordinateur, extraction documentaire | | Note métier | Faciles à interroger et à auditer | Les 80 % des données d’entreprise jadis difficiles à exploiter | Le point pour les dirigeants : **la GenAI a rendu les données non structurées commercialement exploitables** — les contrats, tickets et transcriptions d’appels qui restaient jadis non lus. Mais toute forme d’IA est bornée par la qualité des données. Une check-list métier utile pour la qualité est **complètes, correctes, actuelles, cohérentes, représentatives** : ```text DATA QUALITY → OUTCOME CEILING ───────────────────────────────── Incomplete → gaps the model fills with guesses Incorrect → confident wrong answers Stale → right answer to last year's question Inconsistent → the same entity treated three ways Unrepresentative → works for the majority, fails a segment ``` **Exemple travaillé.** Une équipe support veut trier automatiquement les tickets. Le modèle atteint 91 % d’exactitude sur la langue majoritaire mais 62 % sur un segment de clients qui écrit dans une seconde langue sous-représentée dans les données d’entraînement. L’exactitude affichée de 88 % masque un échec sur un segment qui est aussi celui qui génère le plus de plaintes. Le correctif est une décision sur les données (représenter le segment), pas un changement de modèle — la qualité et la représentativité, pas l’ingéniosité, fixent le plafond. ## 1.3 Training on historical data — and what it implies Un modèle entraîné sur des données historiques est, par construction, **une opinion compressée sur le passé**. Trois conséquences en découlent, et chacune est un risque métier, pas une note technique en bas de page. - **Représentativité.** Le modèle n’est équitable qu’à hauteur de l’équilibre des données. Si un jeu de données de recrutement surreprésente un profil, le modèle apprend ce profil comme « bon ». - **Fraîcheur.** Le monde bouge ; l’instantané d’entraînement, non. Un modèle de demande entraîné avant un basculement du marché continue de répondre à la question de l’an dernier. - **Boucles de rétroaction.** Quand les propres sorties d’un modèle deviennent les données d’entraînement de demain, de petits biais se composent. On recommande les mêmes produits, on collecte des clics sur ces produits, on les recommande encore plus fort. La ligne la plus examinée : **les données d’hier encodent le biais d’hier.** Un modèle n’invente pas la discrimination ; il reproduit fidèlement tout ce que contenaient les données historiques, puis l’applique à grande échelle et à grande vitesse. C’est pourquoi un responsable métier demande *sur quelle période cela a été entraîné, qui figure dans les données, qui en est absent, et comment les propres sorties du modèle vont s’y réinjecter* avant de faire confiance à une prédiction. ```text HISTORICAL DATA ──train──► MODEL ──inference──► DECISIONS ▲ │ └────────── outputs become new data ─────────┘ (feedback loop: bias can compound) ``` :::tip[Signal d’examen] Les énoncés sur **« le modèle a été entraîné sur des données antérieures / d’une seule région / d’un seul type de client »**, ou **« la performance était correcte au lancement mais s’est dégradée »**, testent la représentativité, la fraîcheur ou la dérive. La bonne réponse interroge les données, pas l’algorithme. ::: ## 1.4 Global frameworks and a unified vocabulary L’examen demande d’être *conscient* de deux standards ISO/IEC au niveau métier — à quoi sert chacun, pas leurs numéros d’articles. | Standard | À quoi il sert, en termes métier | | --- | --- | | **ISO/IEC 42001** | Un standard de **système de management de l’IA** — le standard certifiable et auditable du « comment nous exploitons l’IA de façon responsable en tant qu’organisation », comparable dans l’esprit à un système de management de la qualité ou de la sécurité de l’information. AWS a déclaré le prendre en charge. | | **ISO/IEC 23053** | Un **cadre pour les systèmes d’IA qui utilisent le machine learning** — un modèle de référence et un vocabulaire partagés pour décrire la structure des systèmes de ML. | Pourquoi un stratège s’en soucie : un vocabulaire commun permet au juridique, au risque, à l’ingénierie et au métier de débattre de la même chose, et un standard de système de management reconnu transforme « faites-nous confiance, nous sommes responsables » en quelque chose qu’un client ou un régulateur peut auditer. Vous rencontrerez aussi le **NIST AI Risk Management Framework** (NIST AI RMF : Govern, Map, Measure, Manage) et une réglementation à niveaux de risque comme l’**EU AI Act** au Domaine 3 — les fondamentaux ici sont que des standards existent, qu’ils donnent à tous les mêmes mots, et que l’un d’eux (42001) est un système de management certifiable. ## 1.5 Rule-based automation versus AI La compétence de littératie la plus précieuse de cet examen est de savoir quand *ne pas* recourir à l’IA. L’automatisation par règles est déterministe, transparente, peu coûteuse à auditer et correcte à chaque fois que la règle est correcte. L’IA est probabiliste, puissante sur les motifs désordonnés, et fausse une partie du temps par conception. | Dimension | Automatisation par règles | IA / ML | | --- | --- | --- | | Logique | Règles explicites écrites par un humain | Motifs appris à partir des données | | Déterminisme | Même entrée → même sortie, toujours | Probabiliste ; peut varier | | Auditabilité | Entièrement explicable en lisant la règle | Nécessite des outils d’explicabilité | | Idéal quand | La logique est stable, connue, réglementée | Les motifs sont trop variés pour être énumérés | | Échoue quand | Les règles explosent de façon combinatoire | Les données sont pauvres, éparses ou non représentatives | | Coût d’erreur | Prévisible | Parfois silencieux et sûr de lui | **Exemples honnêtes où l’IA est le mauvais outil :** - Calculer une taxe ou un intérêt — une formule, déterministe, qui doit être exacte et auditable. Utilisez une règle. - Faire respecter un seuil de conformité (« bloquer tout virement au-dessus de la limite ») — une règle, pas un modèle. - Router un formulaire selon la valeur d’une case à cocher — une règle. - Toute décision qui doit être identique et défendable à chaque fois — une règle, car « généralement juste » ne suffit pas. L’IA gagne sa place là où l’entrée est non structurée ou les motifs trop variés pour être écrits : résumer un appel, extraire des champs d’une facture désordonnée, signaler des anomalies que personne n’avait listées à l’avance, rédiger une première version. Quand un énoncé décrit un problème **déterministe, bien spécifié, à fort enjeu qui doit être exact**, la réponse sophistiquée est une règle. ## 1.6 AI agents versus other AI solutions Un **agent** est une solution d’IA qui peut entreprendre des actions vers un objectif, pas seulement produire une réponse. Les capacités qui le définissent sont l’**autonomie** (il décide de l’étape suivante), l’**usage d’outils** (il appelle des systèmes, des API ou des fonctions), la **communication d’agent à agent** (les agents se coordonnent) et l’**orchestration** (un contrôleur séquence les étapes). Un assistant GenAI simple répond ; un agent *fait*. ```text ASSISTANT AGENT ───────── ───── You → prompt → answer Goal → plan → act (tool) → observe You act on the answer → decide next step → repeat → until goal met or stopped Human in every loop Human sets the goal and the guardrails ``` Le point pour les dirigeants : **autonomie et gouvernance avancent ensemble**. Plus un agent décide et agit de lui-même — dépenser de l’argent, envoyer des messages, modifier des enregistrements — plus il peut accomplir et plus une seule mauvaise étape peut faire de dégâts. L’autonomie est donc un curseur de gouvernance, pas une amélioration gratuite : | Niveau d’autonomie | Valeur | Conséquence sur la gouvernance | | --- | --- | --- | | Suggère, l’humain exécute | Modeste | Faible ; l’humain est le point de contrôle | | Agit en bac à sable, l’humain approuve | Plus élevée | Point d’approbation, réversible | | Agit sur des systèmes réels dans des limites | Élevée | Nécessite garde-fous durs, journalisation, escalade | | Entièrement autonome, enchaîne les actions | La plus élevée | Rayon d’impact maximal ; nécessite un kill-switch et un audit | :::tip[Signal d’examen] Les énoncés avec **« autonomously », « takes actions », « calls tools / systems », « chains steps », « coordinates with other agents »** sont des items d’agent. Quand ils ajoutent **« spends / sends / changes / deletes »**, la bonne réponse associe la capacité à une supervision : points d’approbation, limites, journalisation et voie d’escalade — jamais « laissez-le tourner parce que c’est plus rapide ». ::: ## 1.7 Why AI needs ongoing monitoring Un modèle entraîné est un instantané ; le monde continue de bouger. Cet écart explique pourquoi la bonne réponse à « on l’a déployé, on a fini ? » est toujours « non ». Trois dégradations liées comptent, et un responsable métier doit pouvoir nommer ce qu’il demande. | Phénomène | Ce qui change | Symptôme métier | | --- | --- | --- | | **Dérive des données (data drift)** | La distribution des *entrées* se déplace (nouveaux clients, nouvelles formulations, nouveaux produits) | Le modèle voit des entrées différentes de ses données d’entraînement | | **Dérive de concept / du modèle (concept / model drift)** | La *relation* entre l’entrée et la bonne réponse se déplace | La bonne réponse d’hier est la mauvaise d’aujourd’hui | | **Dégradation des performances** | L’exactitude, la précision ou le KPI métier s’érode avec le temps | Des métriques correctes au lancement glissent | Ce qu’un responsable métier doit exiger, en clair : *une référence capturée au lancement ; une supervision continue face à elle ; des seuils d’alerte qui préviennent un humain ; une cadence définie de revue et de réentraînement ; et un propriétaire redevable d’agir sur l’alerte.* Sur AWS, des outils comme SageMaker Model Monitor existent pour détecter et alerter sur les prédictions inexactes de modèles déployés — mais l’examen demande seulement de savoir que **la supervision n’est pas optionnelle et que quelqu’un doit en être propriétaire.** « Régler et oublier » est toujours la mauvaise réponse. ## 1.8 Shadow AI and transparent tool classification Le **shadow AI** désigne des employés qui utilisent des outils d’IA que l’organisation n’a pas validés — coller des données confidentielles dans un chatbot personnel pour travailler plus vite. C’est rarement malveillant ; c’est généralement le symptôme d’une voie gouvernée trop lente ou inexistante. L’atténuation attendue par l’examen est la **classification transparente** : une liste vivante et publiée d’outils dans trois états. | État | Signification | Exemple de critère | | --- | --- | --- | | **Approuvé** | Validé pour des classes de données et des cas d’usage déclarés | A passé la revue données, sécurité et conditions | | **Bloqué** | Non autorisé ; une alternative sûre est nommée | Échoue aux conditions de non-entraînement ou aux besoins de résidence | | **En évaluation** | En cours d’évaluation ; ne pas utiliser avec des données réelles pour l’instant | Essai en cours ; date de décision fixée | Deux choses font *fonctionner* la classification plutôt que jouer la prudence : elle est **transparente** (chacun voit la liste et pourquoi un outil s’y trouve) et elle s’accompagne d’un **défaut approuvé rapide**, de sorte que la voie gouvernée est plus facile que la voie non gouvernée. Une interdiction générale sans alternative approuvée n’arrête pas le shadow AI ; elle le garantit. C’est la version au niveau des fondamentaux d’un thème que le Domaine 3 développe en un modèle opérationnel de gouvernance complet. ## 1.9 Prompt-engineering principles at a business level Vous ne serez pas testé sur des astuces de prompt malignes, mais sur le *principe* que la qualité de la sortie d’un modèle dépend largement de l’instruction reçue. La check-list au niveau métier : - **Rôle** — dites au modèle qui être (« vous êtes analyste sinistres »). - **Tâche** — énoncez précisément la seule mission. - **Contexte** — fournissez les faits dont le modèle a besoin au lieu d’espérer qu’il devine. - **Contraintes** — longueur, ton, ce qu’il faut éviter, ce qui doit figurer. - **Format** — la forme exacte de la sortie (tableau, puces, une page). - **Exemples** — un ou deux exemples travaillés orientent le format et la qualité plus qu’un paragraphe de description. - **Critère de réussite** — comment vous jugerez la réponse. À retenir pour les dirigeants : **vague en entrée, vague en sortie.** Quand une équipe se plaint que « l’IA donne des réponses génériques », la première question est ce qu’on lui a demandé, pas s’il faut acheter un modèle plus gros. La clarté du prompt est le levier de qualité le moins coûteux qui soit. ## 1.10 Tokens and context windows as business constraints Un **token** est un fragment de texte (grossièrement un mot court ou un morceau de mot) que le modèle lit et écrit ; vous êtes généralement facturé **au token** et le modèle ne peut « voir » qu’une quantité bornée de texte à la fois — sa **fenêtre de contexte**. ```text CONTEXT WINDOW = how much the model can hold in view at once ┌───────────────────────────────────────────────────────┐ │ system + instructions │ your documents │ conversation │ ← output └───────────────────────────────────────────────────────┘ if the total exceeds the window, the oldest text falls out ``` Deux contraintes métier en découlent. D’abord, **le coût croît avec les tokens** : un flux qui fourre un manuel de 200 pages entier dans chaque requête est coûteux et souvent plus lent, et le RAG (1.11) existe en partie pour l’éviter. Ensuite, **la fenêtre est finie** : passé une limite, le modèle oublie le contexte antérieur, tronque le document, ou perd le fil d’une longue conversation — ce qui apparaît comme un problème de qualité qui est en réalité un problème de limite de contexte. Quand un énoncé dit que le modèle « oublie les instructions précédentes » ou « rate des détails dans un très long document », le discriminant est la fenêtre de contexte, pas l’intelligence du modèle. :::tip[Signal d’examen] **« Long document », « oublie ce qu’on a dit avant », « le coût par requête est plus élevé que prévu », « tronqué »** pointent vers les contraintes de tokens et de fenêtre de contexte. Le correctif est généralement d’envoyer moins mais un contexte plus pertinent (RAG, résumé, chunking) — pas d’acheter un modèle plus intelligent. ::: ## 1.11 Model adaptation: prompt → RAG → fine-tuning Il existe une échelle de façons d’adapter un modèle généraliste à un besoin métier précis. Ne la gravissez qu’aussi haut qu’il le faut, car chaque échelon coûte plus d’effort et de contrôle. | Technique | Ce qu’elle fait | Coût / effort | Fraîcheur des données | Contrôle | À utiliser quand | | --- | --- | --- | --- | --- | --- | | **Ingénierie de prompt** | De meilleures instructions et un meilleur contexte dans la requête | Le plus faible | Aussi frais que ce que vous collez | Faible | Le modèle de base y arrive avec des indications | | **RAG** | Récupère les données pertinentes de l’entreprise au moment de la requête et les injecte | Moyen | Toujours à jour — mettez à jour la source, pas le modèle | Moyen | Les réponses doivent refléter votre connaissance propriétaire changeante | | **Fine-tuning** | Réentraîne les poids du modèle sur vos exemples | Le plus élevé | Figée au moment de l’entraînement ; réentraînez pour rafraîchir | Élevé | Vous avez besoin d’un style/comportement constant que les instructions ne permettent pas, et les données sont stables | Le **Retrieval-Augmented Generation (RAG, génération augmentée par récupération)** est le cheval de trait de la connaissance métier : il garde les faits dans une source que vous contrôlez, de sorte que mettre à jour un document de politique met à jour les réponses sans réentraînement. Sur AWS, c’est ce que fournissent les Knowledge Bases managées au niveau stratégique — du RAG sans l’infrastructure. Le **fine-tuning** change le modèle lui-même ; il est puissant pour un ton constant ou un comportement spécialisé mais coûteux, lent à rafraîchir, et le mauvais outil quand les faits sous-jacents changent chaque semaine. ```text Need better answers from a general model? │ ├─ Better instructions / context enough? → PROMPT ENGINEERING (start here) │ ├─ Answers must reflect changing, proprietary facts? → RAG │ └─ Need consistent specialised behaviour, stable data, and prompting/RAG are not enough? → FINE-TUNING (last, most costly) ``` L’instinct préféré de l’examen : **commencer à l’échelon le moins cher et ne grimper que forcé.** Aller droit au fine-tuning quand un prompt ou du RAG suffirait est le distracteur classique de sur-ingénierie. --- ## Cadre de décision ### Le sélecteur capacité-vers-solution Quand un problème métier atterrit sur votre bureau, ce sélecteur l’oriente vers le *type* de solution avant que quiconque ne parle d’un produit précis. Notez le problème sur quatre axes, puis lisez la recommandation. | Axe | Question | Penche déterministe ↔ penche IA | | --- | --- | --- | | **Déterminisme** | La bonne réponse est-elle fixe et spécifiable sous forme de règles ? | Oui → règles · Non → IA | | **Disponibilité des données** | Avons-nous des données de qualité et représentatives sur le motif ? | Non → règles/reporter · Oui → ML/GenAI | | **Tolérance à l’erreur** | Le processus peut-il absorber une réponse fausse occasionnelle ? | Non → règles ou forte supervision · Oui → IA | | **Besoin d’auditabilité** | Chaque décision doit-elle être expliquée et identique ? | Oui → règles (ou ML explicable + revue) · Non → GenAI/agentique OK | **Comment le lire :** | Profil | Classe de solution recommandée | | --- | --- | | Déterministe, doit être exact, entièrement auditable | **Automatisation par règles** | | Motifs dans des données structurées, prédiction/classification, une certaine tolérance à l’erreur | **ML classique** | | Entrée non structurée, générer/résumer/extraire, un humain vérifie la sortie | **Generative AI** | | Objectif multi-étapes, doit agir sur des systèmes, erreurs tolérables et réversibles, garde-fous en place | **Agentic AI** (avec supervision proportionnée à l’autonomie) | **Application travaillée.** Un prêteur veut (a) décider de l’éligibilité d’un prêt selon une règle réglementaire fixe, (b) prédire le risque de défaut, et (c) rédiger la lettre de décision au client. - (a) L’éligibilité est déterministe, à fort enjeu, doit être identique et auditable → **automatisation par règles**. Utiliser un modèle ici serait à la fois plus risqué et plus difficile à défendre. - (b) Le risque de défaut est un motif dans des données historiques structurées avec une tolérance à l’erreur gérée par la politique → **ML classique**, avec explicabilité (p. ex. SageMaker Clarify au niveau stratégique) et revue humaine des cas limites car le domaine est réglementé. - (c) La lettre est une génération non structurée à partir d’un modèle de document et des faits → **GenAI**, avec un point de revue humaine avant tout envoi au client. Un problème métier, trois classes de solution différentes. La valeur du cadre est de refuser le réflexe de faire des trois « un projet d’IA ». ## Erreurs fréquentes | Erreur | Pourquoi elle survient | Que faire à la place | | --- | --- | --- | | Appeler « IA » toute automatisation | Le mot est à la mode et vague | Réservez IA/ML aux systèmes à motifs appris ; appelez la logique déterministe par son nom | | Recourir à l’IA sur un problème déterministe | L’IA paraît moderne et impressionnante | Si la réponse est une règle fixe, utilisez une règle — elle est exacte, peu coûteuse et auditable | | Faire confiance à un modèle parce que sa sortie est fluide | L’assurance se lit comme de la compétence | La fluidité n’est pas l’exactitude ; un modèle peut avoir tort avec assurance | | Ignorer la qualité des données et blâmer le modèle | Le modèle est la partie visible | Corrigez d’abord représentativité, fraîcheur et exactitude ; la qualité plafonne le résultat | | Supposer qu’un modèle lancé reste exact | « On l’a déployé, on a fini » | Exigez des références, une supervision de la dérive, une cadence de revue et un propriétaire | | Traiter l’autonomie d’un agent comme une amélioration gratuite | Plus d’autonomie ressemble à plus de valeur | Proportionnez la supervision à l’autonomie ; plus de pouvoir d’action signifie plus de garde-fous | | Interdire purement les outils d’IA pour arrêter le shadow AI | Une interdiction paraît sûre et simple | Publiez approuvés/bloqués/en évaluation et fournissez un défaut approuvé rapide | | Sauter directement au fine-tuning | Il sonne comme la « vraie » solution | Commencez par le prompting, puis le RAG ; fine-tunez seulement forcé | | Fourrer des documents entiers dans chaque prompt | « Donnons-lui tout pour être sûr » | Envoyez le contexte pertinent (RAG, résumés) ; les tokens coûtent et les fenêtres sont finies | | Croire que le biais vient de l’algorithme | Le calcul semble neutre | Le biais entre généralement par les données historiques ; interrogez qui est présent et absent | | Confondre RAG et fine-tuning | Les deux « personnalisent le modèle » vaguement | Le RAG injecte des données actuelles à la requête ; le fine-tuning réentraîne les poids sur des données stables | | Attendre que le modèle devine le contexte manquant | Il répond si couramment quand même | Fournissez rôle, tâche, contexte, contraintes et format ; vague en entrée, vague en sortie | ## Étude de cas guidée **Scénario.** La directrice des opérations d’un distributeur vous demande d’« ajouter de l’IA » à trois problèmes d’un coup. D’abord, une **vérification d’éligibilité au retour** : la politique est un ensemble fixe de règles (sous 30 jours, non porté, reçu présent). Ensuite, une **prévision de la demande** pour du stock saisonnier, où existent deux ans d’historique de ventes propre. Enfin, un **auto-répondeur** qui lira la plainte en texte libre d’un client et *enverra* seul un e-mail de résolution — remboursement, remplacement ou excuse — pour réduire le délai de réponse. Un fournisseur a proposé une seule « plateforme d’IA » pour les trois, et un modèle fine-tuné « entraîné sur vos données » pour l’auto-répondeur. La directrice veut une recommandation d’ici vendredi et est impressionnée par l’argumentaire du fine-tuning. **Trace de raisonnement d’expert.** 1. **Refuser le cadrage taille unique.** Ce sont trois problèmes différents sur le sélecteur capacité-vers-solution, et les regrouper en un seul « projet d’IA » est la première erreur. Je note chacun séparément. 2. **L’éligibilité au retour est déterministe et auditable** — la réponse est fixée par la politique et doit être identique à chaque fois et défendable face à un client ou un régulateur. C’est de l’**automatisation par règles**, pas de l’IA. Utiliser un modèle probabiliste ici introduirait de la variabilité dans une règle qui n’a aucune raison de varier, et rendrait les litiges plus difficiles à défendre. La réponse sophistiquée dit « celui-ci n’est pas un problème d’IA ». 3. **La prévision de la demande est un motif dans des données historiques structurées** avec une tolérance à l’erreur gérée par le stock de sécurité. C’est du **ML classique**. Mais je signale immédiatement la fraîcheur et la représentativité : deux ans d’historique antérieurs à un basculement du marché prédiront la demande de l’an dernier, donc je demande sur quelle période portent les données et j’exige une supervision de la dérive, car une prévision exacte au lancement se dégrade à mesure que les conditions évoluent. 4. **L’auto-répondeur est le dangereux.** C’est de la GenAI (entrée non structurée, sortie générée) *plus de l’autonomie* (il envoie, et les remboursements sont de l’argent qui quitte l’entreprise). Autonomie et gouvernance avancent ensemble : un agent qui dépense de l’argent seul a un grand rayon d’impact. La recommandation est donc la GenAI pour *rédiger*, avec un point d’approbation humaine avant tout envoi ou remboursement — au moins jusqu’à ce qu’une performance supervisée justifie de relever l’autonomie sur des cas à faible valeur et réversibles. 5. **Contester l’argumentaire du fine-tuning.** Les faits de l’auto-répondeur — ce client, cette commande, la politique actuelle — changent constamment, et le fine-tuning fige la connaissance au moment de l’entraînement. La bonne adaptation est le **RAG sur les données actuelles de commande et de politique**, pas le fine-tuning, car mettre à jour un document de politique doit mettre à jour les réponses sans réentraînement. Le fine-tuning ici serait l’échelon le plus coûteux de l’échelle pour résoudre un problème que l’échelon moins cher résout mieux. 6. **Nommer la supervision et la propriété.** Chaque composant d’IA reçoit une référence, une supervision de la dérive et un propriétaire nommé ; la vérification déterministe des retours n’a pas besoin de supervision de la dérive car elle n’apprend pas. **Recommandation correcte à l’examen :** automatisation par règles pour l’éligibilité au retour ; ML classique avec supervision de la dérive pour la prévision ; GenAI avec RAG et point d’approbation humaine pour l’auto-répondeur, en ne relevant l’autonomie que pour des cas à faible valeur réversibles une fois supervisés. **Rejeter** le paquet plateforme unique, **rejeter** le fine-tuning pour l’auto-répondeur, et **rejeter** toute autonomie complète qui laisserait le système rembourser de l’argent sans supervision dès le premier jour. --- ## Pièges de l’examen dans ce domaine | Piège | Pourquoi il est tentant | Le discriminant | | --- | --- | --- | | « C’est de l’automatisation, donc de l’IA » | Les termes se brouillent dans le marketing | L’IA/ML *apprend* des motifs ; une règle fixe est de l’automatisation déterministe | | « Utilisons l’IA parce que c’est plus avancé » | Le moderne bat le démodé | Si la logique est déterministe et doit être exacte, une règle est la meilleure réponse | | « Le modèle est fluide, donc il a raison » | L’assurance signale la compétence | La fluidité est une propriété du langage, pas un signal de vérité | | « Déployé et exact au lancement, donc on a fini » | Le lancement ressemble à la ligne d’arrivée | La dérive et la dégradation sont garanties ; supervision et propriétaire sont requis | | « Fine-tunons-le sur nos données » pour des faits changeants | Cela sonne comme l’option sérieuse | Le fine-tuning fige la connaissance ; le RAG la garde à jour à la requête | | « Donnons-lui l’autonomie complète pour aller vite » | La vitesse est attirante | L’autonomie élargit le rayon d’impact ; la supervision doit croître avec elle | | « Interdisons tous les outils d’IA pour être sûrs » | Une interdiction paraît décisive | Les interdictions poussent au shadow AI ; classez les outils et offrez un défaut approuvé rapide | | « Le biais est un problème technique/d’algorithme » | Le calcul semble neutre | Le biais entre surtout par les données historiques ; interrogez les données, pas seulement le modèle | | « Achetons un modèle plus gros pour corriger les réponses génériques » | Plus gros sonne mieux | Des prompts vagues et un contexte maigre causent des sorties génériques ; corrigez d’abord l’instruction | | « Une plateforme d’IA pour chaque problème » | Simplicité et fournisseur unique | Des problèmes différents nécessitent des classes de solution différentes ; orientez chacun sur le sélecteur | --- ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Tentez avant de révéler. A. Generative AI, parce qu’il produit une sortie. B. Machine learning, parce qu’il apprend des motifs à partir de données plutôt que de suivre des règles fixes. C. Automatisation par règles, parce qu’il signale des transactions. D. Un agent d’IA, parce qu’il entreprend une action. **Réponse : B.** Apprendre des motifs à partir de données est la définition du machine learning ; ce n’est pas génératif car il classe au lieu de créer du contenu (A), ce n’est pas un système à règles fixes (C), et signaler n’est pas une action multi-étapes autonome (D). A. Generative AI pour interpréter chaque demande. B. Un modèle fine-tuné entraîné sur les retours passés. C. Automatisation par règles, parce que la logique est déterministe et doit être identique et auditable. D. Un agent autonome qui décide au cas par cas. **Réponse : C.** La politique est une règle fixe et déterministe qui doit être exacte et défendable, donc un moteur de règles est supérieur. La GenAI (A) et un modèle fine-tuné (B) ajoutent variabilité et coût inutiles, et un agent autonome (D) est de la sur-ingénierie pour une décision de case à cocher. A. L’algorithme est défectueux ; changez de modèle. B. Données d’entraînement non représentatives ; améliorez la représentation de ce segment dans les données. C. La fenêtre de contexte est trop petite ; raccourcissez les prompts. D. Rien ; 88 % au global est acceptable. **Réponse : B.** Un échec sur un segment dû à la sous-représentation est un problème de qualité/représentativité des données, corrigé en représentant le segment, pas par un changement de modèle (A) ni de contexte (C). Accepter le chiffre affiché (D) ignore que le segment défaillant peut être celui à plus fort enjeu. A. Le modèle est devenu moins intelligent. B. Dérive : la distribution des entrées ou la relation entrée-vers-résultat s’est déplacée depuis l’entraînement. C. La fenêtre de contexte a rétréci. D. Les prompts se sont dégradés. **Réponse : B.** Une dégradation progressive après lancement sans changement de code est la signature d’une dérive de données ou de concept à mesure que le monde s’éloigne de l’instantané d’entraînement. Les modèles ne perdent pas en intelligence (A), les fenêtres de contexte ne rétrécissent pas seules (C), et un modèle prédictif n’est pas piloté par prompt (D). A. Inférence — utiliser un modèle entraîné sur une nouvelle entrée pour produire une prédiction. B. Entraînement — ajuster le modèle aux données historiques. C. Algorithme — l’artefact entraîné qui fait des prédictions. D. Prédiction — la recette utilisée pour apprendre. E. Modèle — la méthode d’apprentissage. **Réponse : A et B.** L’inférence est l’application du modèle entraîné à une nouvelle entrée, et l’entraînement est l’ajustement du modèle aux données historiques. C, D et E inversent les définitions : le *modèle* est l’artefact entraîné et l’*algorithme* est la méthode d’apprentissage, tandis qu’une prédiction est une sortie, pas une recette. A. Le fine-tuning, parce qu’il ancre la connaissance dans le modèle. B. Le RAG, parce qu’il récupère la politique actuelle au moment de la requête, si bien que les mises à jour n’exigent aucun réentraînement. C. L’ingénierie de prompt seule, en ignorant les documents. D. Une fenêtre de contexte plus grande, sans récupération. **Réponse : B.** Le RAG garde les faits changeants dans une source que vous contrôlez et récupère toujours la version actuelle, tandis que le fine-tuning (A) fige la connaissance à l’entraînement et exige un réentraînement pour rafraîchir. Le prompting seul (C) n’a aucun accès aux documents, et une fenêtre plus grande (D) ne résout pas la récupération des bons passages. A. Interdire tous les outils d’IA à l’échelle de l’entreprise. B. Publier une classification approuvés/bloqués/en évaluation et fournir un outil par défaut approuvé et rapide. C. L’ignorer ; les outils sont pratiques. D. Surveiller les employés en secret. **Réponse : B.** Une classification transparente plus une voie approuvée rapide supprime la raison pour laquelle les gens contournent. Une interdiction générale (A) enfouit le shadow AI au lieu de l’arrêter, l’ignorer (C) laisse le risque sur les données, et une surveillance secrète (D) touche la confiance, pas la voie gouvernée manquante. A. Un point d’approbation humaine pour les remboursements au-dessus d’une valeur définie. B. La journalisation de chaque action avec une voie d’escalade. C. Supprimer toutes les contraintes pour qu’il réponde le plus vite. D. Choisir le modèle le plus récent quelle que soit l’adéquation. E. Désactiver la supervision pour réduire le coût. **Réponse : A et B.** Une autonomie qui dépense de l’argent nécessite un point d’approbation pour les cas à plus forte valeur et une journalisation complète avec escalade, car le rayon d’impact est de l’argent qui quitte l’entreprise. Supprimer les contraintes (C), courir après le modèle le plus récent (D) et désactiver la supervision (E) accroissent tous le risque au lieu de le contrôler. A. Acheter le modèle plus gros immédiatement. B. Améliorer le prompt avec rôle, tâche, contexte, contraintes et format avant de dépenser pour un modèle plus gros. C. Fine-tuner le modèle sur les données de l’entreprise. D. Réduire la fenêtre de contexte. **Réponse : B.** Une sortie générique reflète généralement un prompt vague et un contexte maigre, donc améliorer l’instruction est le levier le moins cher et le plus rapide. Acheter un modèle plus gros (A) ou fine-tuner (C) est une dépense prématurée, et réduire la fenêtre de contexte (D) supprimerait de l’information utile. A. Un cadre de tarification pour les services d’IA. B. Un standard de système de management de l’IA — une manière certifiable et auditable d’exploiter l’IA de façon responsable en tant qu’organisation. C. Un algorithme de machine learning spécifique. D. Une loi fédérale américaine. **Réponse : B.** ISO/IEC 42001 est un standard de système de management pour gouverner l’IA de façon responsable, contre lequel on peut se certifier, d’où son importance pour un stratège. Ce n’est pas un modèle de tarification (A), un algorithme (C) ni une loi nationale (D). A. Les modèles inventent leurs propres biais indépendamment des données. B. Un modèle reproduit les motifs de ses données d’entraînement, donc des données non représentatives ou périmées mènent à des prédictions biaisées ou obsolètes. C. Les données historiques garantissent des prédictions futures exactes. D. Une fois entraîné, un modèle est immunisé contre les changements du monde. **Réponse : B.** Un modèle reproduit fidèlement les données historiques, y compris leurs biais et leur âge, puis les applique à grande échelle. Il n’invente pas le biais à partir de rien (A), le passé ne garantit pas l’avenir (C), et un modèle entraîné est justement ce qui dérive quand le monde change (D). A. Le modèle n’est pas assez intelligent. B. Des contraintes de tokens et de fenêtre de contexte : le coût croît avec les tokens et des entrées très longues peuvent dépasser ou encombrer la fenêtre ; récupérez plutôt les sections pertinentes. C. La température du prompt est mauvaise. D. Les données sont non structurées. **Réponse : B.** La facturation au token et une fenêtre de contexte finie expliquent à la fois le coût et les détails ratés, et le RAG ou le chunking n’envoie que les passages pertinents. L’intelligence du modèle (A), la température (C) et la structure des données (D) n’expliquent ni le coût par requête ni le débordement de contexte. A. Calculer un intérêt au centime exact pour un relevé. B. Bloquer toute transaction au-dessus d’un seuil réglementaire fixe. C. Résumer un appel client non structuré. D. Extraire des champs de factures scannées désordonnées. E. Rédiger un e-mail marketing. **Réponse : A et B.** Le calcul exact d’intérêt et un blocage à seuil fixe sont déterministes, doivent être exacts et auditables, et sont parfaits pour des règles. Résumer des appels (C), extraire de documents désordonnés (D) et rédiger de la copie (E) impliquent une entrée non structurée ou de la génération où l’IA gagne sa place. A. Les agents sont toujours plus exacts. B. Les agents peuvent agir de façon autonome vers un objectif, en utilisant des outils et en orchestrant plusieurs étapes, tandis qu’un assistant produit une réponse qu’un humain doit exploiter. C. Les agents n’ont jamais besoin de supervision humaine. D. Les assistants ne peuvent utiliser aucune donnée externe. **Réponse : B.** La différence définissante est l’action autonome, multi-étapes et utilisatrice d’outils vers un objectif. Les agents ne sont pas intrinsèquement plus exacts (A), ils ont besoin de *plus* de supervision à mesure que l’autonomie augmente (C), et les assistants peuvent utiliser des données fournies (D). A. Rien ; un bon modèle n’a besoin d’aucune maintenance. B. Une référence au lancement, une supervision continue de la dérive face à elle, des seuils d’alerte, une cadence de revue/réentraînement et un propriétaire nommé. C. Un remplacement immédiat par un modèle plus récent. D. Désactiver la journalisation pour réduire le coût. **Réponse : B.** Tout modèle appris dérive, donc supervision, seuils, cadence et propriétaire redevable sont obligatoires. « Se gère tout seul » (A) est le piège, un modèle plus récent (C) dérive aussi, et désactiver la journalisation (D) supprime le signal même nécessaire pour détecter les problèmes. A. Les données structurées sont toujours plus précieuses. B. Les données structurées entrent en lignes et colonnes et conviennent au ML classique et à la BI ; les données non structurées (texte, images, audio) sont là où la GenAI a débloqué du contenu d’entreprise jadis inexploitable. C. Les données non structurées ne peuvent pas du tout être utilisées par l’IA. D. La distinction n’a aucune incidence sur le choix de solution. **Réponse : B.** Le type de données détermine quelle solution est viable — la GenAI a rendu exploitable le vaste stock de contenu non structuré. Les données structurées ne sont pas intrinsèquement plus précieuses (A), les non structurées sont bel et bien exploitables (C), et la distinction pilote directement le choix de solution (D). A. Une boucle d’optimisation saine. B. Une boucle de rétroaction qui peut composer le biais, car les sorties du modèle façonnent les données dont il apprend ensuite. C. Un débordement de fenêtre de contexte. D. Du fine-tuning. **Réponse : B.** Quand les sorties deviennent de futures données d’entraînement, de petits biais peuvent s’amplifier avec le temps — une boucle de rétroaction, pas une optimisation bénigne (A). C’est sans rapport avec les fenêtres de contexte (C) et ce n’est pas le réentraînement délibéré que décrit le fine-tuning (D). A. GenAI pour les trois, sur une seule plateforme. B. Automatisation par règles pour (a), ML classique avec explicabilité et revue pour (b), GenAI avec un point de revue humaine pour (c). C. Un modèle fine-tuné pour les trois. D. Un agent autonome pour les trois. **Réponse : B.** Les trois problèmes ont des profils différents : règle déterministe, prédiction sur motif dans des données structurées, et génération non structurée. Une seule plateforme GenAI (A), un seul modèle fine-tuné (C) ou un agent généralisé (D) ignorent tous que des problèmes différents nécessitent des classes de solution différentes. A. Sur quelle période a-t-il été entraîné, et est-ce toujours d’actualité ? B. Qui est représenté dans les données et qui en est absent ? C. De quelle couleur est le tableau de bord ? D. Combien de GPU ont été utilisés ? E. Quel est le logo du fournisseur ? **Réponse : A et B.** La fraîcheur et la représentativité sont les questions de données qui déterminent si les prédictions sont fiables et équitables. La couleur du tableau de bord (C), le nombre de GPU (D) et l’image du fournisseur (E) ne vous disent rien sur la qualité du résultat. A. Correct ; un faible aléa garantit la vérité. B. Cela réduit la variabilité mais ne garantit pas l’ancrage ; une sortie non ancrée peut rester fausse avec assurance, donc la vérification et le RAG comptent davantage. C. Cela augmente les hallucinations. D. L’aléa n’a aucun effet sur la sortie. **Réponse : B.** Un aléa plus faible rend la sortie plus cohérente, pas plus vraie ; l’ancrage et la vérification traitent l’hallucination. Cela ne garantit pas la vérité (A), n’augmente pas l’hallucination en règle générale (C), et l’aléa affecte clairement la sortie (D). A. Quand les faits sous-jacents changent chaque semaine. B. Quand vous avez besoin d’un comportement ou d’un style spécialisé constant, que les données sont relativement stables, et que le prompting et le RAG ne suffisent pas. C. Chaque fois qu’une personnalisation est souhaitée, en première étape. D. Pour réduire les coûts de tokens sur une seule requête. **Réponse : B.** Le fine-tuning convient à un comportement spécialisé stable que les instructions et la récupération ne peuvent atteindre. Il est mauvais pour des faits changeant vite (A), c’est le dernier échelon et non le premier (C), et il n’existe pas pour rogner les tokens d’une seule requête (D). A. Orienter chaque problème séparément : une règle pour les retours, du ML classique pour la prévision, de la GenAI avec RAG et un point humain pour l’auto-répondeur. B. Proportionner la supervision à l’autonomie : l’auto-répondeur de remboursement a besoin d’un point d’approbation avant que l’argent ne quitte l’entreprise. C. Accepter le paquet plateforme unique pour simplifier les achats. D. Fine-tuner un modèle pour faire les trois. E. Donner à l’auto-répondeur l’autonomie complète dès le premier jour pour maximiser la vitesse. **Réponse : A et B.** Les trois problèmes sont des classes de solution différentes, et l’auto-répondeur qui dépense de l’argent doit avoir une supervision proportionnée à son autonomie. Un paquet unique (C) et un seul modèle fine-tuné (D) ignorent cette différence, et l’autonomie complète dès le premier jour sur des remboursements (E) crée un rayon d’impact inacceptable. ## À retenir - IA ⊃ ML ⊃ GenAI ; employez *algorithme, modèle, entraînement, inférence, prédiction* avec précision, et n’appelez pas « IA » de l’automatisation déterministe. - Le type et la qualité des données fixent le plafond du résultat ; la représentativité et la fraîcheur comptent plus que l’ingéniosité du modèle. - L’entraînement sur données historiques signifie que le modèle reproduit à grande échelle les motifs et biais d’hier — interrogez qui est dans les données et à quel point elles sont fraîches. - L’automatisation par règles bat l’IA chaque fois que la logique est déterministe, exacte et doit être auditable ; savoir quand *ne pas* utiliser l’IA est une compétence d’examen fondamentale. - Les agents ajoutent de l’autonomie et de l’usage d’outils ; la supervision doit croître avec l’autonomie car le pouvoir d’action est un rayon d’impact. - Tout modèle appris dérive — exigez des références, une supervision, des seuils, une cadence de revue et un propriétaire ; « régler et oublier » est toujours faux. - Vainquez le shadow AI avec une liste transparente approuvés/bloqués/en évaluation plus un défaut approuvé rapide, pas une interdiction générale. - Ne gravissez l’échelle d’adaptation qu’aussi haut qu’il le faut : le prompt d’abord, puis le RAG pour les faits changeants, et le fine-tuning en dernier pour un comportement spécialisé stable.