# Module 6 — La stratégie multi-modèles ## Section 1 — Démarrer ### Comment utiliser ce cours Ce module représente environ **7 heures** de travail. Chemin conseillé : 1. **Lisez les chapitres 1 à 5** (la logique de portefeuille) — 100 minutes. 2. **Faites la démonstration commentée du chapitre 6** (comparer 3 modèles sur une tâche) — 30 minutes. 3. **Réalisez l'atelier du chapitre 7** (grille de routage Banque Équatoriale) — 90 minutes. 4. **Étudiez l'exemple travaillé du chapitre 8**, puis **produisez votre livrable** (chapitre 9) — 60 minutes. 5. **Faites les mini-exercices et le quiz** (chapitre 10), vérifiez avec les **corrigés en annexe D** — 30 minutes. 6. **Parcourez la FAQ (chapitre 11)** et gardez la **fiche mémo (annexe A)**. > **Conventions de lecture.** Les blocs à chasse fixe sont des **prompts à copier-coller**. Les encadrés « Piège », « Bonne pratique », « Le saviez-vous » et ⚠️ « Attention » signalent un point clé. ------------------------------------------------------------------------ ### Fiche du module | Rubrique | Valeur | |----|----| | Module | 6 — La stratégie multi-modèles | | Palier | Avant-garde (Praticien) | | Durée | 7 heures | | Prérequis | Module 5 validé | | Plateforme d'atelier | Claude + ChatGPT + Gemini (benchmark) | | Compétence clé visée | Router la bonne tâche vers le bon modèle | | 3 promesses portées | Les 3 (productivité, coûts, sécurité) | | Votre livrable | Grille de routage multi-modèles | | Validation | Quiz ≥ 75 % + grille conforme à la grille de notation (14/20) | ------------------------------------------------------------------------ ## Section 2 — Comprendre ### Ch.1 — Pourquoi un seul modèle ne suffit pas ## 1.1 Le réflexe « un outil pour tout » est une erreur La plupart des entreprises — et beaucoup de fournisseurs concurrents — proposent « un » outil d'IA pour tout faire. C'est une erreur d'architecture : une même organisation a des tâches très différentes (trier, rédiger, traduire, traiter des données sensibles), et aucune ne mérite le même modèle. Le multi-modèles est le levier qui **réconcilie les trois promesses** : un petit modèle rapide pour le volume (productivité et coûts), un grand modèle pour les cas complexes (qualité), et un modèle hébergé en environnement maîtrisé pour les données sensibles (sécurité). ## 1.2 Un argument de différenciation Là où le concurrent vend « un » outil, vous proposez une **architecture arbitrée** : la bonne tâche sur le bon modèle. C'est un argument de vente puissant, et c'est aussi une assurance contre la dépendance à un fournisseur unique (vous le verrez au Module 10). > **Idée force du module.** On ne choisit pas « le meilleur modèle » ; on compose un **portefeuille de modèles** par usage, comme un chef compose un menu avec plusieurs ingrédients. > > **Le saviez-vous ?** Les systèmes IA les plus efficaces en production combinent presque toujours plusieurs modèles : un léger qui filtre et trie, un puissant qui traite les cas difficiles, parfois un troisième en repli. Mono-modèle = soit trop cher, soit trop faible. ------------------------------------------------------------------------ ### Ch.2 — Objectifs et compétences visées À l'issue de ce cours, vous serez capable de : 1. **Raisonner en portefeuille** : composer un ensemble de modèles par usage. 2. **Établir une grille de routage** : pour chaque type de tâche, le modèle cible et sa justification. 3. **Concevoir une cascade** : essayer le modèle léger, escalader si nécessaire. 4. **Prévoir un repli (fallback)** et arbitrer entre modèle propriétaire et modèle ouvert hébergé. ------------------------------------------------------------------------ ### Ch.3 — Pourquoi ça compte pour votre organisation | Promesse | Comment le multi-modèles la sert | |----|----| | Productivité ×3 | Un modèle léger traite le volume sans saturer | | Réduction des coûts | On ne paie le modèle cher que là où il est nécessaire | | Sécurité / conformité | Les données sensibles vont vers un environnement maîtrisé | Le multi-modèles est aussi une **assurance de continuité** : un repli permet de tenir si un fournisseur devient indisponible. ------------------------------------------------------------------------ ### Ch.4 — Concepts et vocabulaire clés - **Routing** — aiguillage automatique d'une requête vers le modèle le plus adapté selon sa complexité ou sa nature. - **Spécialisation** — usage d'un modèle taillé pour une tâche (extraction, traduction, code, vision) plutôt que d'un généraliste. - **Fallback (repli)** — modèle de secours déclenché si le premier échoue ou est indisponible. - **Cascade (model cascade)** — on essaie d'abord le modèle léger ; si la confiance est insuffisante, on escalade vers le plus puissant — pour ne payer le coût élevé que lorsqu'il est nécessaire. - **Ensemble / vote** — plusieurs modèles répondent et l'on compare les réponses pour fiabiliser un résultat critique. - **Modèle ouvert vs propriétaire** — un modèle ouvert peut être hébergé chez soi (souveraineté, coût maîtrisé) ; un modèle propriétaire est plus capable mais accessible seulement via le fournisseur. > **Piège classique.** « Tout envoyer au modèle le plus puissant pour être sûr. » C'est payer cher partout, saturer le débit, et exposer parfois des données là où il ne faudrait pas. Le routage est plus intelligent que la force brute. ------------------------------------------------------------------------ ### Ch.5 — Comprendre en profondeur ## 5.1 La logique de portefeuille Composer un portefeuille, c'est répondre, pour chaque type de tâche, à trois questions : **quelle qualité est requise ? quel volume ? quelle sensibilité des données ?** La réponse dicte le modèle. | Type de tâche | Qualité requise | Volume | Modèle type | |----------------------|-----------------|----------|--------------------| | Tri / classification | Moyenne | Élevé | Léger | | Rédaction soignée | Élevée | Moyen | Puissant | | Traduction | Élevée | Variable | Spécialisé/capable | | Données sensibles | Variable | Variable | Hébergé maîtrisé | ## 5.2 La cascade : payer cher seulement si nécessaire Le principe de **cascade** : on traite d'abord avec un modèle léger ; si le résultat est incertain (faible confiance), on **escalade** vers un modèle plus puissant. On ne paie le coût élevé que sur la fraction des cas qui l'exigent. Sur un support où 70 % des cas sont simples, la cascade peut diviser la facture tout en gardant la qualité sur les cas difficiles. ## 5.3 Le fallback : tenir quand un fournisseur tombe Que se passe-t-il si le fournisseur principal est indisponible (panne, quota atteint, blocage géographique) ? Sans **repli**, le service s'arrête. Un fallback (un autre modèle, parfois un modèle ouvert hébergé) garantit la continuité — un enjeu majeur en CEMAC, où l'accès à un service étranger n'est jamais garanti. ## 5.4 Propriétaire vs ouvert hébergé Un modèle **propriétaire** (accessible via le fournisseur) est souvent plus capable. Un modèle **ouvert hébergé** (chez soi ou chez un hébergeur maîtrisé) offre souveraineté, coût maîtrisé et confidentialité — au prix d'une capacité parfois moindre. Le choix dépend de la **sensibilité des données** et de l'exigence de souveraineté (Module 10). **Mini-exercice 5.A.** Pour une tâche de tri de 10 000 e-mails/mois dont seuls 5 % sont ambigus, quelle stratégie de modèles proposez-vous ? *(Corrigé en annexe D.)* ------------------------------------------------------------------------ ## Section 3 — Pratiquer ### Ch.6 — Démonstration commentée : comparer trois modèles Le palier Avant-garde vous demande de **benchmarker**. Comparez Claude, ChatGPT et Gemini sur une même tâche pour ressentir leurs différences. ## 6.1 La même tâche sur trois modèles Posez ce prompt **identique** sur Claude, ChatGPT et Gemini : `Classe ce ticket de support bancaire dans l'une des catégories : « solde/compte », « carte/paiement », « réclamation », « autre ». Réponds uniquement par la catégorie. Ticket : « Bonjour, ma carte a été débitée deux fois pour le même achat hier, pouvez-vous régulariser ? »` **Observation attendue :** les trois donneront probablement « carte/paiement ». Sur une tâche simple, ils convergent — ce qui justifie d'utiliser le **moins cher**. La différence apparaît sur les tâches complexes (rédaction nuancée, raisonnement long), où un modèle puissant se distingue. ## 6.2 Tirer la leçon de routage **Conclusion pratique :** quand plusieurs modèles donnent le même résultat, routez vers le plus économique. Réservez le modèle premium aux tâches où la comparaison montre une vraie différence de qualité. > **Bonne pratique.** Constituez un petit **jeu de tests** (5 à 10 cas représentatifs) et passez-le sur plusieurs modèles avant de décider du routage. La décision se prend sur des preuves, pas sur une réputation. ------------------------------------------------------------------------ ### Ch.7 — Mode opératoire détaillé (action par action) ## 7.0 Prérequis de l'atelier - un **compte Claude** actif (+ ChatGPT et Gemini pour le benchmark) ; - les **prompts du module** (dossier `prompts/`) ; - environ **90 minutes** + le gabarit de la grille de routage (chapitre 9). ## 7.1 Atelier — étape 1 : construire la grille de routage (cas Banque Équatoriale) **Cas.** Banque Équatoriale (Guinée Équatoriale) veut un système qui (a) classe les demandes clients, (b) rédige des réponses, (c) traite des documents contenant des données bancaires sensibles, en **français, anglais et espagnol**. 1. Pour chacune des trois tâches, déterminez : qualité requise, volume, sensibilité des données. 2. Routez chaque tâche vers un modèle cible avec une **justification** (coût / qualité / sécurité). Utilisez le prompt `01_grille_routage.txt` pour structurer, puis ajustez. 3. Repère attendu : tri = modèle léger ; rédaction multilingue = modèle capable ; documents sensibles = modèle hébergé en environnement maîtrisé. **Checklist de vérification — étape 1.** Avant de passer à l'étape 2, assurez-vous que : - \[ \] chaque tâche est routée vers un modèle avec une justification ; - \[ \] la justification relie chaque choix à une promesse (coût / qualité / sécurité) ; - \[ \] la tâche « données sensibles » va vers un environnement maîtrisé. ## 7.2 Atelier — étape 2 : prévoir le repli et argumenter 1. Définissez la **règle de repli** : que se passe-t-il si le fournisseur principal devient indisponible dans la zone ? Quel modèle de secours ? 2. Rédigez un **paragraphe d'argumentation client** expliquant pourquoi cette architecture multi-modèles coûte moins et sécurise mieux qu'un modèle unique (prompt `02_argumentaire_client.txt`). **Checklist de vérification — étape 2.** Avant de produire votre livrable, assurez-vous que : - \[ \] un fallback est prévu pour la continuité de service ; - \[ \] votre argumentaire relie l'architecture aux 3 promesses ; - \[ \] la donnée sensible reste dans un environnement maîtrisé même en repli. > \[!WARN\] **Attention — la donnée commande le routage.** Une donnée bancaire sensible ne se route pas vers un modèle pour des raisons de coût ou de qualité : elle se route d'abord selon la **confidentialité** et la **résidence des données**. La sécurité prime sur l'optimisation — un principe que vous approfondirez aux Modules 9 et 10. ## 7.3 Transposition Microsoft Copilot Dans l'écosystème Microsoft, le routage multi-modèles se gère via **Copilot Studio** (choix du modèle par agent) et **Azure AI** (catalogue de modèles). Le principe d'arbitrage est identique ; les produits fournissent les briques. ## 7.4 Bonnes pratiques et pièges - Raisonnez en portefeuille, pas en « meilleur modèle ». - Concevez une cascade pour les tâches à volume. - Prévoyez toujours un repli. - Routez la donnée sensible selon la confidentialité, pas le coût. **Mini-exercice 7.A.** Donnez un exemple de cascade pour un service de support : quel modèle d'abord, quand escalader ? *(Corrigé en annexe D.)* ------------------------------------------------------------------------ ### Ch.8 — Exemple travaillé : une grille de routage de qualité (cas Banque Équatoriale) ## 8.1 La grille | Tâche | Modèle cible | Justification | Repli | |----|----|----|----| | Classer les demandes | Modèle léger | Volume élevé, qualité suffisante → coût minimal | Autre modèle léger d'un second fournisseur | | Rédiger les réponses (FR/EN/ES) | Modèle capable multilingue | Qualité de rédaction et multilingue → qualité prime | Modèle capable alternatif | | Traiter documents sensibles | Modèle hébergé en environnement maîtrisé | Données bancaires → confidentialité et résidence priment | Hébergement souverain de secours | ## 8.2 Règle de repli Si le fournisseur principal devient indisponible dans la zone, basculer le tri et la rédaction vers le fournisseur alternatif ; les documents sensibles restent **toujours** en environnement maîtrisé, jamais sur un service externe non validé. ## 8.3 Argumentaire client (extrait) > « Plutôt qu'un outil unique, nous proposons une architecture où chaque tâche est traitée par le modèle adapté : un modèle économique pour le tri (vous payez moins), un modèle de qualité pour vos réponses multilingues (vos clients sont mieux servis), et un environnement maîtrisé pour vos documents sensibles (vos données restent protégées). C'est plus économique, plus performant et plus sûr qu'un modèle unique. » > > **Pourquoi cet exemple est bon.** Chaque tâche est routée avec une justification reliée à une promesse ; un fallback est prévu ; la donnée sensible reste en environnement maîtrisé ; l'argumentaire parle au client. ------------------------------------------------------------------------ ## Section 4 — Livrable & évaluation ### Ch.9 — Votre livrable ## 9.1 Consigne Produisez une **grille de routage multi-modèles** pour le cas Banque Équatoriale : tableau tâche → modèle cible → justification (coût/qualité/sécurité) → modèle de repli, accompagnée d'un paragraphe d'argumentation client. ## 9.2 Grille de notation (sur 20 — seuil : 14/20) | Critère | Points | |-------------------------------------------|--------| | Chaque tâche routée avec justification | 6 | | Justification reliée à une promesse | 4 | | Fallback prévu | 4 | | Donnée sensible en environnement maîtrisé | 3 | | Argumentaire client clair | 3 | ## 9.3 Checklist avant de déposer - \[ \] Les 3 tâches sont routées avec justification. - \[ \] Chaque justification cite une promesse (coût/qualité/sécurité). - \[ \] Un fallback est prévu pour chaque tâche. - \[ \] La donnée sensible reste en environnement maîtrisé. - \[ \] Mon argumentaire client est compréhensible et convaincant. Déposez votre grille sur le canal Teams (ou portfolio) avant J+2. ------------------------------------------------------------------------ ### Ch.10 — Auto-évaluation ## 10.1 Quiz (seuil : 4 bonnes réponses sur 5) 1. Qu'est-ce qu'une cascade et quel coût économise-t-elle ? 2. Pourquoi ne pas tout envoyer au modèle le plus puissant ? 3. Quand préférer un modèle ouvert hébergé ? 4. À quoi sert un fallback ? 5. Qu'est-ce qui commande le routage d'une donnée sensible : le coût ou la confidentialité ? Répondez par vous-même, **puis** vérifiez avec l'**annexe D**. ## 10.2 Auto-positionnement Reportez votre niveau sur la grille d'auto-évaluation, ligne « Multi-modèles ». ------------------------------------------------------------------------ ### Ch.11 — Points de vigilance : les pièges fréquents de ce module Avant de continuer, prenez 2 minutes pour vérifier les 3 confusions les plus fréquentes sur ce module — même après un score correct au quiz, elles reviennent souvent dans la pratique. | Piège fréquent | Pourquoi c'est trompeur | Comment corriger | |----|----|----| | Vouloir **tout router vers le modèle puissant** | Le réflexe de sécurité ('le plus gros modèle') coûte cher sans bénéfice réel sur les tâches simples | Rappelez-vous le principe de portefeuille de modèles et de cascade | | Router une **donnée sensible selon le coût** | L'économie semble un critère raisonnable mais ne l'est jamais sur une donnée sensible | La confidentialité prime toujours sur l'arbitrage économique | | Oublier le **repli (fallback)** | Un système qui fonctionne en test peut tomber en panne en production sans plan B | Prévoyez systématiquement un modèle ou un chemin de repli | Si l'une de ces confusions vous parle, revisitez **Ch.4 — Concepts et vocabulaire clés** ou **Ch.6 — Démonstration commentée** avant de passer au module suivant. ### Ch.12 — Questions fréquentes (FAQ) **« Gérer plusieurs modèles, n'est-ce pas plus complexe ? »** Un peu, mais le gain (coût, qualité, sécurité, continuité) le justifie largement. Les plateformes (Copilot Studio, Azure AI) gèrent une grande partie de cette complexité. **« Comment savoir quel modèle est “suffisant” pour une tâche ? »** Par le test : passez un petit jeu de cas représentatifs sur plusieurs modèles et comparez. La décision se prend sur des preuves. **« Et si tous les modèles donnent la même réponse ? »** Tant mieux : routez vers le moins cher. La convergence est un signal que la tâche est simple. **« Le repli n'est-il pas un luxe ? »** Non, c'est une assurance de continuité — essentielle dans des zones où l'accès à un fournisseur peut être coupé. Un service sans repli est fragile. ------------------------------------------------------------------------ ### Ch.13 — Pour aller plus loin - Construisez un **jeu de tests** pour une tâche de votre service et comparez 3 modèles. - Esquissez une cascade pour un cas à volume de votre quotidien. - Réfléchissez à ce qui se passerait si votre fournisseur principal était indisponible une journée. **Et ensuite — Module 7 :** vous abordez les **protocoles et l'interopérabilité** (API, connecteurs, MCP) — comment un modèle se branche sur les outils et les données d'une entreprise. C'est le premier module avec des éléments techniques concrets (sans coder). ------------------------------------------------------------------------ ## Annexes (ressources) ### Mémo · Prompts · Glossaire · Corrigés - **Portefeuille de modèles**, pas « le meilleur modèle ». Choisir selon qualité requise · volume · sensibilité. - **Cascade** : léger d'abord, escalade si incertain → payer cher seulement si nécessaire. - **Fallback** : un repli pour la continuité. - **Donnée sensible → environnement maîtrisé**, quoi qu'il arrive. - **Décider sur des tests**, pas sur une réputation. # Annexe B — Vos prompts du module Dans `prompts/` : `00_contexte_projet_claude.txt`, `01_grille_routage.txt`, `02_argumentaire_client.txt`, `03_benchmark_tri.txt`. # Annexe C — Glossaire express | Terme | En une phrase | |-----------------|--------------------------------------------| | Routing | Aiguiller chaque tâche vers le bon modèle | | Spécialisation | Modèle taillé pour une tâche précise | | Cascade | Léger d'abord, escalade si incertain | | Fallback | Modèle de secours pour la continuité | | Ensemble / vote | Plusieurs modèles comparés pour fiabiliser | | Ouvert hébergé | Modèle hébergé chez soi (souveraineté) | # Annexe D — Corrigés **Mini-exercice 5.A.** Une **cascade** : un modèle léger traite les 95 % de cas clairs ; les 5 % ambigus (faible confiance) sont escaladés vers un modèle puissant. Coût minimal, qualité préservée sur les cas difficiles. **Mini-exercice 7.A (exemple).** Modèle léger pour rédiger la première réponse à tous les tickets ; si la confiance est faible ou le ticket complexe (réclamation sensible), escalade vers un modèle puissant et/ou un agent humain. **Quiz — corrigé.** 1. La cascade traite d'abord avec un modèle léger et n'escalade vers le puissant que si nécessaire ; elle économise le surcoût du grand modèle sur les cas simples. 2. Parce que beaucoup de tâches n'en ont pas besoin : on paie cher partout et on sature le débit, parfois on expose des données. 3. Quand la confidentialité, la résidence des données ou la souveraineté priment (et pour maîtriser le coût). 4. À garantir la continuité de service si le fournisseur principal est indisponible. 5. La confidentialité (et la résidence) commandent : la sécurité prime sur l'optimisation de coût ou de qualité.