# Slides — Session 9 : Construire des produits IA **Programme :** Applied AI — Niveau intermédiaire · **Formateur :** Yann Isola **28 slides · 2 heures · Palette : encre #1A2230, sarcelle #0F7A6C, cuivre #B4612A** --- ## Slide 1 — Titre # Construire des produits IA ### Du modèle au produit : penser utilisateur, mesurer, décider **Applied AI — Session 9 · Yann Isola** > **Notes :** Accueil. Annoncer le fil rouge : « aujourd'hui, on ne parle pas de comment marche l'IA, mais de comment on en fait un produit que les gens utilisent, auquel ils font confiance, et qui rapporte plus qu'il ne coûte. » --- ## Slide 2 — Programme de la session 1. 🧭 Pensée produit vs pensée technique 2. 🎨 UX de l'incertitude & human in the loop 3. 📐 Quand l'IA a de la valeur — et les métriques pour le prouver 4. 💰 Coût-bénéfice & l'arbre build / buy / fine-tune 5. 🤝 Confiance, IA responsable, études de cas > **Notes :** 5 blocs, 2 démos live sur la page interactive (calculateur ROI et arbre de décision). Prévenir : 5 exit tickets jalonnent la session. --- ## Slide 3 — L'accroche ### « Qui a déjà utilisé un produit IA frustrant ? » *(récolte au tableau — on y reviendra)* > **Notes :** 3–4 réponses max. Typiquement : chatbot qui tourne en rond, réponses fausses affirmées avec aplomb, pas de moyen de parler à un humain. Garder ces exemples visibles : ils illustrent les blocs 2 et 5. --- ## Slide 4 — Deux façons de penser | Pensée technique | Pensée produit | |---|---| | « Quel modèle utiliser ? » | « Quel problème est-ce que je résous ? » | | « GPT-4 ou Claude ? RAG ou fine-tuning ? » | « Pour qui ? Quelle douleur ? Quelle fréquence ? » | | Part de la solution | Part du problème | | Succès = ça marche techniquement | Succès = l'utilisateur revient | > **Notes :** RAG = Retrieval-Augmented Generation (génération augmentée par récupération). Marteler : la question technique est légitime, mais elle vient en **second**. La techno la plus impressionnante n'est pas la plus utile. --- ## Slide 5 — Anti-exemple vécu ### La startup au chatbot magnifique - 6 mois de développement : RAG sophistiqué, réécriture de requêtes, reranking - Entretiens utilisateurs après lancement : *« En fait, on voulait juste une recherche rapide avec des filtres »* - 💸 Solution en quête de problème > **Notes :** Cas composite mais représentatif. Le coût n'est pas que financier : 6 mois de retard sur le vrai besoin. Question au groupe : « qu'aurait-il fallu faire au jour 1 ? » (Réponse : parler aux utilisateurs avant de coder.) --- ## Slide 6 — L'IA invisible ### Les meilleurs produits IA ne crient pas « IA ! » - 📧 Tri anti-spam : personne n'y pense, tout le monde l'utilise - ✍️ Suggestions de réponse, correction automatique - 🗺️ Estimation du temps de trajet **L'IA est un moyen, pas un argument.** > **Notes :** Contraste avec les produits « AI-powered » comme argument marketing sans valeur. Transition : « si l'IA est un moyen, encore faut-il gérer son défaut majeur : elle se trompe. » --- ## Slide 7 — L'incertitude est une donnée de conception ### L'IA se trompe. Toujours. Parfois. Le produit doit être conçu **en sachant** que : - certaines réponses seront fausses, - l'utilisateur ne saura pas lesquelles, - … sauf si le produit l'aide à le savoir. > **Notes :** C'est LA différence avec le logiciel classique (déterministe). Un bouton « enregistrer » marche ou plante. Une réponse d'IA peut être *plausiblement fausse*. Toute l'UX découle de ça. --- ## Slide 8 — Trois piliers de l'UX IA 1. **Gérer l'incertitude** — prévoir l'erreur dans le parcours 2. **Indicateurs de confiance** — montrer quand l'IA est sûre… et quand elle ne l'est pas 3. **Dégradation gracieuse** — quand l'IA échoue, le produit reste utilisable > **Notes :** UX = User Experience (expérience utilisateur). Exemples slide suivante. « Dégradation gracieuse » : si le service IA tombe, l'utilisateur doit pouvoir continuer en manuel — jamais d'écran mort. --- ## Slide 9 — Exemples concrets | Produit | Bonne pratique | |---|---| | DeepL | Propose des **alternatives** de traduction — assume la non-unicité | | GitHub Copilot | **Suggère** sans imposer — l'humain accepte ou ignore | | OCR de factures | Surligne en orange les champs à **faible confiance** → relecture ciblée | | Assistant support | « Je ne suis pas sûr — voulez-vous parler à un conseiller ? » | > **Notes :** OCR = Optical Character Recognition (reconnaissance optique de caractères). Point commun : l'incertitude est **visible et actionnable**, jamais cachée. Question 2 du quiz porte là-dessus. --- ## Slide 10 — Ce qu'il ne faut PAS faire - ❌ Affirmer avec le même aplomb le vrai et le faux - ❌ Masquer les cas d'échec (« pas de résultat » silencieux) - ❌ Bloquer tout le flux dès qu'un élément est incertain - ❌ Noyer l'utilisateur sous des scores techniques incompréhensibles > **Notes :** Le dernier point est subtil : afficher « confiance : 0,87 » ne parle à personne. Préférer des codes simples : vert / orange / « à vérifier ». Reprendre les frustrations récoltées slide 3 — la plupart rentrent dans ces cases. --- ## Slide 11 — Le spectre « human in the loop » ``` Entièrement Approbation Contrôle humain Entièrement automatisé → humaine → (override) → manuel 🤖 🤖✋👤 🤖👁️👤 👤(🤖 assiste) ``` **Human in the loop = humain dans la boucle.** > **Notes :** Dessiner au tableau. Définitions nettes : *automatisé* = l'IA agit seule ; *approbation* = rien ne s'exécute sans validation préalable ; *override* = l'IA agit, l'humain surveille et peut annuler ; *manuel* = l'humain fait, l'IA assiste. --- ## Slide 12 — Où placer le curseur ? ### Règle d'or : plus le coût d'une erreur est élevé, plus l'humain est proche. | Cas | Position | Pourquoi | |---|---|---| | Filtrage spam | Automatisé | Erreur bénigne, réversible | | Modération de contenu | Override | Volume énorme, mais recours nécessaire | | Aide au diagnostic médical | Approbation | Coût d'erreur majeur | | Rédaction de contrat | Manuel assisté | Responsabilité juridique | > **Notes :** Exercice participatif : proposer d'autres cas (virement suspect, tri de CV, réponse client) et faire voter le groupe sur la position. Exit ticket n°1 juste après : virement frauduleux → approbation humaine. --- ## Slide 13 — Le curseur bouge dans le temps - Lancement : **approbation humaine** (on apprend, on mesure) - Confiance établie + métriques stables : glissement vers **override** - Cas simples uniquement : **automatisation** progressive **On automatise sur preuve, pas sur promesse.** > **Notes :** Point souvent oublié : la position n'est pas figée. Le taux d'escalade (bloc suivant) est justement l'instrument qui dit si on peut déplacer le curseur. --- ## Slide 14 — Quand l'IA ajoute de la valeur ### Le triangle de la valeur ``` Volume élevé ▲ ╱ ╲ ╱ ╲ ╱ 💎 ╲ ╱───────╲ Tolérance à Boucle de l'imperfection rétroaction claire ``` **Les trois conditions ensemble — pas deux sur trois.** > **Notes :** Chaque condition : *volume* (la tâche revient assez souvent pour amortir l'effort), *tolérance* (une erreur se rattrape sans catastrophe), *rétroaction* (on sait mesurer si l'IA fait bien, et le signal alimente l'amélioration). --- ## Slide 15 — Le triangle en pratique | Tâche | Volume | Tolérance | Rétroaction | Verdict | |---|---|---|---|---| | Tri de 10 000 tickets/jour | ✅ | ✅ | ✅ (reclassements) | 💎 Idéal | | Résumés de réunions | ✅ | ✅ | ⚠️ | 👍 Bon | | Calcul de paie | ✅ | ❌ | ✅ | ❌ Non | | Rapport annuel actionnaires | ❌ | ❌ | ❌ | ❌ Non | > **Notes :** Exercice inverse avec le groupe : « donnez une tâche de votre métier, testons-la contre le triangle ». 2–3 tours. C'est l'exercice 1.1 du dossier d'exercices — et l'exit ticket n°4. --- ## Slide 16 — Le piège des « deux sur trois » - Volume + tolérance, **sans rétroaction** → le produit stagne, la qualité dérive sans qu'on le voie - Volume + rétroaction, **sans tolérance** → chaque erreur coûte trop cher (paie, virements, juridique) - Tolérance + rétroaction, **sans volume** → le jeu n'en vaut pas la chandelle (tâche bi-annuelle) > **Notes :** Insister sur le premier cas, le plus sournois : le produit « marche » au lancement puis se dégrade en silence. D'où le bloc métriques qui suit. --- ## Slide 17 — Les 4 métriques phares d'un produit IA | Métrique | Question à laquelle elle répond | |---|---| | **Taux de complétion de tâche** | L'utilisateur finit-il ce qu'il a commencé ? | | **Temps gagné** | Mesuré (horodatage), pas déclaré | | **Score de confiance utilisateur** | Enquêtes + taux de réutilisation | | **Taux d'escalade** | À quelle fréquence l'humain reprend-il la main ? | > **Notes :** Le taux d'escalade est le canari dans la mine : il monte souvent **avant** que les plaintes n'arrivent. « Temps gagné » : méfiance envers le déclaratif — les utilisateurs surestiment ou sous-estiment ; mesurer les horodatages réels. --- ## Slide 18 — Lire les métriques ensemble ### Un exemple qui doit inquiéter : - Complétion : 85 % ✅ - Temps gagné : +30 % ✅ - Escalade : 20 % → **35 %** en 2 semaines 🔴 **Que s'est-il passé ?** > **Notes :** Faire chercher le groupe : mise à jour du prompt/modèle qui a dégradé un cas d'usage, nouveau segment d'utilisateurs aux besoins différents, dérive des données d'entrée… Action : comparer les cas escaladés avant/après, rollback si besoin. C'est l'exit ticket n°2 (écrit, 3 min). --- ## Slide 19 — Tests A/B pour fonctionnalités IA **Trois objets à tester :** 1. **Variantes de prompt** — A : 72 % de complétion, B : 81 % → B gagne 2. **Routage de modèle** — petit modèle rapide pour les cas simples, gros modèle pour les complexes 3. **Feature flags** (interrupteurs logiciels) — activer pour 5 % des utilisateurs, observer, élargir > **Notes :** Test A/B = comparer deux variantes sur des populations distinctes. Rappels méthodo : significativité statistique (un écart sur 40 utilisateurs ne prouve rien), une seule variable à la fois, déploiement progressif. Question 6 du quiz. --- ## Slide 20 — Coût-bénéfice : les deux plateaux de la balance | 💸 Coûts | 💎 Valeur créée | |---|---| | Appels API (par requête) ⚠ | Temps gagné × coût horaire | | Infrastructure & hébergement | Revenus additionnels | | Maintenance & évolution des prompts | Gains de qualité (moins d'erreurs, moins de reprises) | | **Supervision humaine & escalades** | Satisfaction / rétention client | > **Notes :** API = Application Programming Interface (interface de programmation). ⚠ Les tarifs API évoluent vite — donner des ordres de grandeur « au moment où je parle » et montrer les pages de tarifs officielles. Le coût le plus sous-estimé : la **supervision humaine** — un produit à 82 % de précision garde 18 % de traitement manuel. --- ## Slide 21 — Démo live : le calculateur ROI ### Cas : support client, 5 000 tickets/mois - Traitement manuel : 12 min/ticket à 30 €/h - Coût IA : ≈ 0,08 €/ticket ⚠ + forfait infra - Précision : 85 % (15 % escaladés) **→ Page interactive, onglet « Calculateur ROI »** > **Notes :** ROI = Return On Investment (retour sur investissement). Démo en direct : saisir les valeurs, montrer l'économie mensuelle et le point d'équilibre (breakeven). Puis jouer : « que se passe-t-il si la précision tombe à 60 % ? » → montrer que la précision pèse plus que le coût API. C'est le cœur de l'exercice 2. --- ## Slide 22 — La leçon du calculateur ### La précision domine le coût API - Coût API ×3 → l'économie baisse de quelques % - Précision 85 % → 65 % → l'économie s'effondre (escalades = travail humain complet) **Piloter le taux d'escalade, pas la négociation tarifaire.** > **Notes :** C'est la conclusion attendue de l'exercice 2.4. Corollaire produit : investir dans l'amélioration de la précision (meilleurs prompts, meilleures données) rapporte plus que changer de fournisseur pour 20 % moins cher. --- ## Slide 23 — L'arbre de décision : build / buy / fine-tune ``` Besoin identifié │ ├─ Une API sur étagère + bon prompt suffit ? ──── OUI → 🛒 BUY (≈80 % des cas) │ │ NON ├─ Domaine spécifique + données d'entraînement │ + volume qui justifie le coût ? ─────────────── OUI → 🔧 FINE-TUNE │ │ NON └─ Souveraineté totale exigée / le modèle EST le produit / budget conséquent ? ────────────── OUI → 🏗️ BUILD (rare) ``` > **Notes :** Fine-tuning = affinage d'un modèle existant sur ses propres données. Build from scratch = construire depuis zéro. Ordre de lecture important : on descend l'arbre, on ne saute pas d'étage. « Buy » est le défaut ; les deux autres se justifient sur preuve. --- ## Slide 24 — Buy / Fine-tune / Build : le comparatif | | 🛒 Buy (API) | 🔧 Fine-tune | 🏗️ Build | |---|---|---|---| | Délai | Jours | Semaines | Mois/années | | Coût initial | Faible | Moyen | Très élevé ⚠ | | Compétences | Prompting, intégration | + données, évaluation | + recherche ML | | Maintenance | Minimale | Continue (ré-entraînements) | Totale | | Quand ? | Défaut (≈80 %) | Précision plafonne + volume + données | Souveraineté / cœur de métier | > **Notes :** ML = Machine Learning (apprentissage automatique). Démo : onglet « Arbre de décision » de la page interactive — faire répondre le groupe pour 2 scénarios : classification de courriels internes (→ buy), détection de fraude propriétaire à très fort volume (→ fine-tune, voire build si le modèle est l'avantage concurrentiel). --- ## Slide 25 — Exit ticket n°3 ### Une PME veut un assistant de rédaction de devis. ### Build, buy ou fine-tune ? Justifiez en une phrase. > **Notes :** PME = Petite et Moyenne Entreprise. Réponse attendue : **buy** — une API + un prompt structuré avec les gabarits de devis suffit ; le fine-tuning ne se justifierait qu'avec un volume élevé et une spécificité prouvée après essai. Si quelqu'un défend fine-tune, demander : « avec quelles données ? à quel coût ? pour gagner quoi ? » --- ## Slide 26 — Construire la confiance : 3 leviers 1. **Expliquer ce que l'IA a fait** — pas comment elle fonctionne *« J'ai résumé ces 3 documents »* > *« architecture transformer à 70 milliards de paramètres »* 2. **Montrer les sources** — citations cliquables, traçabilité 3. **Permettre les corrections** — bouton « c'est faux » qui alimente l'amélioration > **Notes :** Anti-exemple : l'assistant qui affirme sans citer → la confiance s'effondre à la **première** erreur détectée, et ne revient pas. La correction utilisateur ferme la boucle de rétroaction du triangle de la valeur — tout se rejoint. --- ## Slide 27 — La confiance est asymétrique - 📈 Elle se construit lentement : des dizaines d'interactions réussies - 📉 Elle se détruit vite : **une** erreur grave affirmée avec aplomb - 🔁 Elle se répare avec de la transparence, pas avec des promesses **Concevez pour le jour où l'IA se trompera. Ce jour arrivera.** > **Notes :** Relier aux frustrations de la slide 3. Transition vers l'IA responsable : « la confiance de l'utilisateur, c'est une chose. La responsabilité vis-à-vis des personnes affectées, c'en est une autre. » --- ## Slide 28 — IA responsable : 4 chantiers concrets | Chantier | Question test | |---|---| | **Détection de biais** | Le produit note-t-il différemment selon le prénom sur un CV ? | | **Filtrage de contenu** | Entrées ET sorties — résiste-t-il à l'injection de prompt ? | | **Consentement** | L'utilisateur sait-il qu'il interagit avec une IA ? | | **Confidentialité** | Quelles données partent vers l'API ? Réutilisées pour l'entraînement ? | ⚠ Cadre réglementaire : AI Act européen (calendrier d'application en évolution) + RGPD. > **Notes :** RGPD = Règlement Général sur la Protection des Données. CV = Curriculum Vitae. Le test du prénom est réel (études sur les biais de tri de CV). L'exercice 3 est un audit complet d'un cas de ce type — l'annoncer ici. Non négociable même si le timing est serré. --- ## Slide 29 — Trois études de cas éclair | Cas | Montage | Métriques clés | |---|---|---| | **Support client** | Triage auto + réponse suggérée + escalade humaine | Résolution au 1er contact, taux d'escalade | | **Pipeline de contenu** | Brief humain → ébauche IA → révision humaine → publication | Temps gagné, taux de reprise | | **Base de connaissances interne** | RAG + citations obligatoires + bouton signalement | Complétion, confiance, signalements | > **Notes :** 90 secondes par cas. Pour chacun, faire nommer par le groupe : position sur le spectre human in the loop, et validation du triangle de la valeur. Point commun des trois : **l'IA fait le premier jet, l'humain garde la décision.** --- ## Slide 30 — Synthèse & prochaine étape ### À retenir 1. 🧭 Le **problème** avant le modèle 2. 🎨 L'incertitude se **design**, elle ne se cache pas 3. 📐 Valeur = volume + tolérance + rétroaction ; mesurer : complétion, temps, confiance, **escalade** 4. 💰 **Buy** par défaut, fine-tune sur preuve, build presque jamais 5. 🤝 Confiance = expliquer, sourcer, corriger — et responsabilité dès la conception ### Pour la session 10 - Exit tickets n°4 et n°5 (maintenant, 5 min) - Exercices : canvas produit (binôme possible), coût-bénéfice, audit IA responsable - Quiz de 10 questions en autonomie > **Notes :** Distribuer les deux derniers exit tickets. Rappeler que la page interactive est réutilisable sur leurs propres projets — c'est l'outil, pas juste le support de cours. Clôture.