# D1 · Scoping AI Solutions Cadrer un problème pour l’IA, recueillir les exigences, définir des métriques de réussite et une enveloppe de coût, décider build versus buy, juger la faisabilité et rédiger un plan de solution. import { Accordions, AccordionItem } from '@prosefly/astro-components'; Ce domaine représente environ **12 %** de l’examen blanc OAI-API — soit à peu près **7 des 60 items** — et il reflète le cours Academy *Scope AI Solutions* (30 min). Il teste le travail que vous faites *avant* le moindre appel d’API : transformer une demande métier floue en une tâche définie, un critère de réussite mesurable et une enveloppe de coût, et décider si l’IA est même le bon outil. La plupart des items décrivent une demande d’une partie prenante et demandent ce que vous devriez établir en premier, ou si le problème convient tout court à un modèle de langage. ## Ce que vous devez savoir Le cadrage est un recueil d’exigences pour du logiciel probabiliste. Vous clarifiez la *tâche à accomplir*, les *entrées et sorties*, le *niveau de qualité* et *comment il sera mesuré*, le *volume et la latence* que le système doit soutenir, et l’*enveloppe de coût et de risque* que le métier acceptera. Vous décidez build-vs-buy (une intégration Responses API, un produit hébergé, ou pas d’IA du tout), et vous jugez la faisabilité honnêtement — certaines tâches, un modèle les fait bien, d’autres mal, et d’autres qu’il ne peut pas vérifier. Le résultat du cadrage est un court **plan de solution** qui nomme la métrique que vous allez faire bouger et la plus petite chose que vous pouvez livrer pour la tester. ## Objectifs d’apprentissage À la fin de cette page, vous devriez être capable de : 1. **Reformuler** une demande métier en une tâche d’IA bien posée avec des entrées, sorties et contraintes définies. 2. **Recueillir les exigences** — volume, latence, niveau de qualité, sensibilité des données, points d’intégration. 3. **Définir une métrique de réussite** mesurable avant de construire. 4. **Estimer une enveloppe de coût** à partir du volume de tokens et du prix du modèle, et la confronter à la valeur métier. 5. **Juger la faisabilité** et choisir build-vs-buy, y compris « ne pas utiliser d’IA ici ». 6. **Rédiger un plan de solution** qui cadre la plus petite première version utile. --- ## 1.1 Reformuler une demande en tâche Les parties prenantes décrivent des résultats (« rendre le support plus rapide ») ; vous avez besoin d’une tâche (« rédiger une première réponse à partir du texte du ticket et des trois derniers tickets du même client »). Une tâche bien posée nomme les entrées que le modèle verra, la forme de sortie qu’il doit produire, et la limite de ce qu’il ne doit *pas* faire. | Demande floue | Tâche reformulée | Entrées | Sortie | | --- | --- | --- | --- | | « Résumer nos réunions » | Produire une liste d’actions en 5 puces avec des responsables à partir d’une transcription | Texte de transcription | Liste Markdown, un responsable par action | | « Répondre aux questions de politique interne » | Répondre aux questions de politique RH ancrées uniquement dans les PDF de politique, avec citations | Question + chunks de politique récupérés | Réponse + sources citées | | « Trier les tickets » | Classer un ticket dans l’une de 8 files et une priorité | Objet + corps du ticket | JSON `{queue, priority}` | | « Aider les ingénieurs » | Suggérer un correctif de code pour un test en échec, pour revue humaine | Dépôt + sortie du test en échec | Proposition de patch | :::tip[Signal d’évaluation] Les énoncés qui disent « une partie prenante vous demande de… », « le métier veut… » ou « avant de commencer à construire » sont des items de cadrage. La bonne réponse **clarifie ou mesure d’abord quelque chose** plutôt que de sauter à un modèle ou un prompt. ::: ## 1.2 Recueillir les exigences Six questions décident de presque tous les choix de conception en aval. Posez-les avant de choisir un modèle. | Exigence | Question | Pourquoi elle guide la conception | | --- | --- | --- | | Volume | Combien de requêtes par jour, et le pic par minute ? | Fixe les limites de débit, batch vs temps réel, le coût | | Latence | Interactif (utilisateur en attente) ou en arrière-plan ? | Streaming, background mode, `fast` vs `flex` | | Niveau de qualité | Qu’est-ce qui est « assez bon », et qui décide ? | Choix du modèle, reasoning effort, gate de revue | | Sensibilité des données | PII, données réglementées, contraintes de résidence ? | Rétention, `store`, résidence, contrôles réseau | | Entrées | Texte, images, fichiers, données structurées ? | Capacité du modèle, entrées de fichiers, RAG | | Intégration | Où va la sortie, dans quel format ? | Sorties structurées, function calling | ## 1.3 Définir une métrique de réussite Si vous ne pouvez pas la mesurer, vous ne pouvez pas l’améliorer et vous ne pouvez pas prouver qu’elle fonctionne. Une métrique de cadrage doit être définie *avant* la construction et être évaluable sur un jeu de données de test mis à part (c’est là que D1 passe le relais à D3, les évaluations). ```text Type de tâche Bonne métrique de réussite Mauvaise métrique ───────────────── ─────────────────────────────── ───────────────── Classification accuracy / F1 sur un jeu labellisé "semble juste" Extraction correspondance exacte par champ "a l’air complet" Q&R ancrée % de réponses avec une citation "sonne juste" Résumé score sur grille par un grader LLM "se lit bien" Rédaction support % accepté par l’agent sans édition "plus rapide" (non mesuré) ``` :::tip[Signal d’évaluation] Quand une option dit « on saura que ça marche quand les clients seront plus contents » et une autre dit « on mesurera le pourcentage de brouillons qu’un agent accepte sans édition sur un échantillon de 200 tickets », la métrique mesurable et prédéfinie est correcte. Les résultats flous sont des distracteurs. ::: ## 1.4 L’enveloppe de coût Cadrez le coût avant de construire ; une solution qui fonctionne mais coûte plus cher que la valeur qu’elle crée est un cadrage raté. Estimez à partir des tokens attendus et du prix du modèle. Les prix de septembre 2026 par **million de tokens** : | Modèle | Entrée $/MTok | Sortie $/MTok | | --- | --- | --- | | `gpt-6-astra` | $10 | $50 | | `gpt-5.6-sol` | $4 | $20 | | `gpt-5.6-terra` | $2 | $12 | | `gpt-5.6-luna` | $0.20 | $1.20 | Exemple travaillé : un classificateur de tri sur `gpt-5.6-luna`, 800 tokens d’entrée et 40 tokens de sortie par ticket, 50 000 tickets/jour. ```text Entrée : 50 000 × 800 = 40 000 000 tok/jour = 40 MTok × $0.20 = $8.00/jour Sortie : 50 000 × 40 = 2 000 000 tok/jour = 2 MTok × $1.20 = $2.40/jour Total quotidien ≈ $10.40 → ≈ $312/mois ``` La même tâche sur `gpt-5.6-sol` reviendrait à peu près à `40 × $4 + 2 × $20 = $200/jour` (~$6 000/mois) pour aucun gain de précision sur une tâche que Luna gère — l’enveloppe de coût est ce qui rejette ce choix. ## 1.5 Build versus buy versus non | Option | Choisir quand | Points de vigilance | | --- | --- | --- | | **Construire sur l’API** | Vous avez besoin de contrôle, de données personnalisées, ou la tâche est au cœur de votre produit | Vous portez les évaluations, l’exploitation, le coût et la sécurité | | **Acheter un produit hébergé** | Une capacité banalisée existe (transcription, chat générique) et la rapidité de mise en valeur l’emporte | Flux de données, verrouillage, coût par siège à l’échelle | | **Utiliser ChatGPT / no code** | Un travailleur du savoir peut le faire dans l’UI avec Projects et des fichiers | Non reproductible ni auditable à l’échelle | | **Ne pas utiliser d’IA** | La tâche exige une réponse garantie correcte et déterministe | Forcer l’IA sur de l’arithmétique, des recherches, ou des règles exactes | :::caution[Le test « l’IA ne peut pas se vérifier elle-même »] Si la tâche exige une réponse qui doit être *prouvablement* correcte et qu’il n’existe pas de contrôle externe bon marché (recherches réglementaires, rapprochement financier avec une vérité terrain, instructions critiques pour la sécurité), un modèle probabiliste est le mauvais cœur — utilisez-le pour assister un système déterministe, pas pour le remplacer. ::: ## 1.6 Juger la faisabilité ```text Une vérité terrain ou un contrôle bon marché existe-t-il ? │ ┌──────────────┴───────────────┐ │ Oui │ Non ▼ ▼ Mesurable → bon usage de l’IA. Un humain peut-il revoir chaque sortie Construire avec une boucle au volume requis ? d’évaluation. │ ┌──────────┴──────────┐ │ Oui │ Non ▼ ▼ L’assistance humaine Reconsidérer le périmètre : réduire dans la boucle est la tâche, ajouter un contrôle, ou faisable. ne pas livrer d’IA ici. ``` ## 1.7 Le modèle de plan de solution Le livrable du cadrage est un plan d’une page. Chaque item de l’examen blanc qui demande « que doit contenir le plan » attend ces champs. ```text Problème : la douleur métier, en une phrase Tâche à accomplir : la tâche précise, avec entrées et sorties Utilisateurs & volume : qui, combien de requêtes/jour, pic/min Métrique de réussite : mesurable, sur un jeu de test mis à part, valeur cible Contraintes : latence, sensibilité des données, résidence, budget Enveloppe de coût : estimation $/requête × volume vs valeur créée Approche : build/buy/no-AI, modèle, récupération ? outils ? Risques & gates : modes de défaillance, points de revue humaine Première version : plus petite tranche livrable + comment vous l’évaluerez ``` ## Cadre de décision Utilisez le cadre **SCOPE** pour transformer toute demande en un plan sur lequel vous pourriez agir dès demain. | Lettre | Étape | Question à répondre | Sortie | | --- | --- | --- | --- | | **S** | State the job | Quelle tâche exacte, avec quelles entrées et sorties ? | Définition de tâche en une phrase | | **C** | Criteria | Comment mesurera-t-on « assez bon » ? | Une métrique et une cible sur un jeu de données | | **O** | Operating limits | Volume, latence, sensibilité des données, budget ? | Liste de contraintes + enveloppe de coût | | **P** | Path | Build, buy, ou pas d’IA ? Quel modèle et quels outils ? | Approche et choix de modèle | | **E** | Experiment | Quelle est la plus petite version qui teste la métrique ? | Périmètre de la première version + plan d’évaluation | L’habitude la plus précieuse qu’enseigne le cours est de finir **C** avant de commencer **P** : les équipes qui choisissent un modèle avant de définir la métrique sur-achètent presque toujours. ## Erreurs fréquentes | Erreur | Pourquoi elle survient | Que faire à la place | | --- | --- | --- | | Choisir le modèle d’abord | Ça donne l’impression d’avancer ; les modèles sont excitants | Définir la métrique et l’enveloppe de coût, puis choisir le modèle le moins cher qui les satisfait | | Aucune métrique de réussite mesurable | « Ça a l’air bien » est facile ; un jeu de données c’est du travail | Rédiger une métrique évaluable sur un jeu de test mis à part avant de construire | | Cadrer le système idéal, pas la première version | Ambition et pression des parties prenantes | Cadrer la plus petite tranche qui teste la métrique | | Ignorer le volume et le pic | Les démos tournent une fois ; la production tourne en continu | Estimer les requêtes/jour et le pic/min ; dimensionner limites et coût à partir de là | | Forcer l’IA sur du travail déterministe | L’IA est le mandat du trimestre | Utiliser du code déterministe pour les règles exactes ; laisser l’IA assister, pas décider | | Sauter les questions de sensibilité des données | Ça remonte tard, en bloqueur de lancement | Interroger sur les PII, les données réglementées et la résidence pendant le recueil | | Traiter le coût comme une réflexion après coup | Les calculs de tokens sont fastidieux | Calculer $/requête × volume et comparer à la valeur dans le plan | | Confondre « plus rapide » avec une métrique | La vitesse est intuitive mais non mesurée | Définir numériquement ce que « plus rapide » signifie (p. ex. temps de traitement médian) | ## Défi de mise en situation **Mise en situation.** Vous êtes développeur dans une entreprise de logistique. Le VP des Opérations dit : « Nos répartiteurs passent des heures à lire les rapports d’incident des chauffeurs. Construisez une IA qui les traite. » Il n’y a pas de jeu de données, pas de sortie définie, et le VP attend une démo dans une semaine. Les rapports d’incident sont en texte libre, contiennent parfois des détails de blessure (réglementés), arrivent à raison d’environ 3 000/jour avec des pics après les tempêtes, et actuellement un répartiteur lit chacun d’eux et soit le classe, soit l’escalade à la sécurité, soit demande plus de détails. **Trace de raisonnement d’expert.** 1. **Reformuler la demande en tâche.** « Les traiter » est un résultat, pas une tâche. Le vrai travail est : étant donné un rapport, le classer en `file / escalate / need-more-detail` et extraire des champs structurés (date, lieu, gravité, indicateur de blessure). C’est une tâche de classification-plus-extraction, pas un chat ouvert. 2. **Définir la métrique avant de construire.** Demandez à l’équipe sécurité 200 rapports historiques avec la décision qu’un répartiteur a réellement prise. Ce jeu labellisé donne une cible de précision et, surtout, un moyen de vérifier la décision d’*escalade* — celle à fort enjeu où un faux négatif est dangereux. 3. **Faire remonter tôt la sensibilité des données.** Les détails de blessure sont réglementés. Cela guide la rétention (`store: false` ou rétention courte), les questions de résidence, et un gate de revue humaine obligatoire sur toute décision `escalate` — vous ne clôturez jamais automatiquement un rapport relatif à la sécurité. 4. **Estimer l’enveloppe de coût.** 3 000/jour à ~1 200 tokens d’entrée + 60 de sortie sur `gpt-5.6-luna` fait ~`3.6 MTok × $0.20 + 0.18 MTok × $1.20 ≈ $0.72 + $0.22 = $0.94/jour`. Négligeable face aux heures de répartiteur économisées — l’enveloppe n’est pas la contrainte ici ; la justesse sur l’escalade l’est. 5. **Cadrer la première version, pas l’idéale.** Livrez le classificateur avec une confirmation humaine sur chaque `escalate`, mesuré face au jeu de 200 rapports. Différez le classement automatique jusqu’à ce que l’évaluation prouve que le rappel sur l’escalade est assez élevé. 6. **Rejeter le piège de la démo.** Une démo en semaine 1 qui classe sans évaluation et sans gate de revue aurait l’air impressionnante et serait dangereuse. Le plan dit : construire d’abord le jeu d’évaluation, puis le classificateur, puis mesurer. **Décision conforme à l’examen :** établir d’abord le jeu de données labellisé et la métrique d’escalade, cadrer une première version avec supervision humaine dans la boucle, et dimensionner le coût à partir du volume réel. **Pas** « commencer à prompter `gpt-6-astra` et le démontrer », **pas** « clôturer automatiquement les rapports de faible gravité avant de mesurer le rappel ». ## Pièges d’évaluation | Piège | Pourquoi il est tentant | Le discriminant | | --- | --- | --- | | « Prendre `gpt-6-astra` pour que la qualité ne soit jamais le problème » | Le meilleur modèle semble le plus sûr | Cadrer d’abord la métrique et le coût ; le modèle le moins cher qui passe l’évaluation gagne | | « Livrer la démo cette semaine pour montrer qu’on avance » | Pression des parties prenantes | Une démo sans métrique ni gate de revue est un échec de cadrage, pas un progrès | | « La métrique, c’est que les utilisateurs sont plus contents » | Ça sonne orienté client | Une métrique doit être mesurable sur un jeu de test mis à part avant la construction | | « Automatiser tout le workflow de bout en bout » | Ambition | Cadrer la plus petite tranche qui teste la métrique ; garder les humains sur les étapes à fort enjeu | | « L’IA peut tout faire, donc ça convient » | Battage | Si la tâche exige une justesse prouvable sans contrôle bon marché, l’IA est le mauvais cœur | | « Le coût n’importe pas, les tokens sont bon marché » | Vrai individuellement | À l’échelle, $/requête × requêtes/jour est le nombre qui tue ou sauve un projet | ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler. A. Quel modèle a la plus grande fenêtre de contexte. B. La tâche précise, ses entrées et sorties, et une métrique de réussite mesurable. C. S’il faut utiliser l’Agents SDK ou l’Agents API. D. La formulation du prompt de la première version. **Réponse : B.** Le cadrage commence par reformuler un résultat en une tâche définie et mesurable. Le contexte du modèle (A), le runtime (C) et la formulation du prompt (D) sont tous des choix en aval de l’étape `P` qui dépendent du travail et de la métrique que vous n’avez pas encore définis. A. Les clients se disent plus contents du support. B. Le modèle semble précis lors des tests. C. Une accuracy de classification d’au moins 92 % sur un jeu de test mis à part de 500 tickets labellisés. D. Les réponses sont générées en moins de deux secondes. **Réponse : C.** Une métrique doit être mesurable sur un jeu de test mis à part avec une cible. Le contentement (A) est un résultat non mesuré, « semble précis » (B) est subjectif, et la latence (D) est une contrainte, pas une métrique de qualité pour la classification. A. Demander à `gpt-6-astra` au reasoning effort `max` de se rappeler la date. B. Faire appeler par le modèle une function qui interroge la base de facturation et renvoie la valeur exacte. C. Fine-tuner un modèle sur toutes les dates de renouvellement passées. D. Mettre toute la table de facturation dans le prompt à chaque requête. **Réponse : B.** Les faits exacts et prouvables relèvent d’une recherche déterministe que le modèle appelle comme un outil, pas du rappel du modèle. Le rappel (A) peut halluciner, le fine-tuning (C) fige des données périmées, et déverser toute la table (D) est coûteux et toujours pas faisant autorité. A. Environ $0.76. B. Environ $7.60. C. Environ $76. D. Environ $760. **Réponse : B.** Entrée : `20 000 × 1 000 = 20 MTok × $0.20 = $4.00`. Sortie : `20 000 × 150 = 3 MTok × $1.20 = $3.60`. Total ≈ `$7.60/jour`. Le discriminant est de faire correctement l’arithmétique `tokens ÷ 1 000 000 × prix/MTok` : l’option A est 10× trop basse, et C et D sont 10× et 100× trop hautes. A. Le rapprochement exact est un travail déterministe ; le modèle devrait orchestrer des calculs déterministes, pas faire l’arithmétique lui-même. B. Toute sortie touchant des chiffres financiers a besoin d’une étape de vérification face à la vérité terrain avant utilisation. C. `gpt-6-astra` à l’effort `max` garantit une arithmétique correcte. D. Le fine-tuning sur les rapprochements passés rend l’arithmétique exacte. E. Comme c’est interne, aucune vérification n’est nécessaire. **Réponse : A et B.** L’arithmétique exacte est déterministe et doit être calculée par du code (ou un outil) avec une étape de vérification face au grand livre ; le modèle coordonne. Aucun reasoning effort (C) ni fine-tuning (D) ne rend un modèle probabiliste prouvablement exact, et « interne » (E) ne supprime pas le besoin de vérifier les chiffres financiers. A. Construire le système autonome complet et le démontrer. B. Assembler un petit jeu de données labellisé d’incidents passés et de leurs dispositions correctes, puis cadrer une première version avec supervision humaine dans la boucle mesurée face à lui. C. Choisir le plus grand modèle et activer tous les outils. D. Sauter la métrique et itérer sur le prompt jusqu’à ce que la démo ait l’air bien. **Réponse : B.** Sans données et avec une décision à fort enjeu, vous devez construire le jeu de données d’évaluation et cadrer une première version revue. Tout construire (A) ou maximiser les outils (C) saute la mesure, et ajuster le prompt jusqu’à une démo séduisante (D) n’a aucune métrique derrière. A. Construire vous permettrait de dire que vous l’avez construit. B. La transcription est une commodité résolue ; acheter apporte de la valeur plus vite et laisse votre équipe se concentrer sur la partie différenciante. C. Les produits hébergés sont toujours moins chers à toute échelle. D. Construire évite toute considération de flux de données. **Réponse : B.** Achetez la capacité banalisée, construisez le différenciateur. Le prestige (A) n’est pas une raison métier, l’hébergé n’est pas toujours moins cher à l’échelle (C), et acheter introduit, plutôt qu’il ne supprime, des considérations de flux de données (D). A. Le volume de requêtes quotidien et le pic par minute. B. Si les entrées contiennent des PII ou des données réglementées. C. Le modèle préféré du fondateur. D. La couleur du dashboard. E. Si le bureau utilise Mac ou Windows. **Réponse : A et B.** Le volume/pic dimensionne les limites de débit, le choix batch-vs-temps réel et le coût ; la sensibilité des données guide la rétention, la résidence et les gates de revue — les deux changent l’architecture. La préférence de modèle (C), la couleur de l’UI (D) et l’OS (E) non. A. Les deux devraient utiliser le streaming temps réel par cohérence. B. La fonctionnalité interactive a besoin d’une latence faible (streaming, éventuellement fast mode) ; l’arriéré convient bien à Batch, qui échange la latence contre un coût plus bas. C. Les deux devraient utiliser la Batch API. D. Les deux devraient utiliser le background mode avec webhooks. **Réponse : B.** Les exigences de latence diffèrent : le travail interactif a besoin de streaming/faible latence, tandis qu’un grand arriéré non urgent convient au traitement Batch moins cher et à latence plus élevée. Forcer un seul mode sur les deux (A, C) ignore l’exigence de latence ; le background mode (D) convient à l’arriéré mais pas à l’utilisateur en attente. A. L’ID du modèle que vous utiliserez. B. Une valeur cible sur un jeu de test mis à part, p. ex. « correspondance exacte par champ ≥ 95 % sur 300 factures labellisées ». C. La liste des ingénieurs du projet. D. Le template de prompt. **Réponse : B.** La ligne métrique de réussite nomme une cible mesurable sur un jeu de données. L’ID de modèle (A) est la ligne approche, l’affectation (C) n’est pas une métrique, et le prompt (D) est un détail d’implémentation, pas un critère de réussite. A. Obtempérer ; le meilleur modèle est toujours le plus sûr. B. Montrer l’évaluation et l’enveloppe de coût : Luna satisfait la métrique à environ un cinquantième du prix d’entrée, donc Astra ajoute du coût sans bénéfice mesurable. C. Utiliser Astra mais à l’effort `low` pour économiser. D. Sauter l’évaluation et répartir le trafic entre les deux. **Réponse : B.** La discipline de cadrage est « le modèle le moins cher qui passe l’évaluation », étayée par le calcul de coût. Obtempérer par défaut (A) sur-achète, Astra-en-`low` (C) coûte toujours bien plus par token que Luna, et répartir le trafic sans évaluation (D) n’a aucune base pour la décision. A. Rien ne change ; le modèle est assez précis. B. Ajouter un gate de revue humaine obligatoire avant l’action irréversible et définir une métrique spécifiquement pour la décision qui la déclenche. C. Augmenter le reasoning effort à `max` et sauter la revue. D. Journaliser l’action après coup à des fins d’audit uniquement. **Réponse : B.** Les actions irréversibles exigent un gate de revue et une métrique ciblée sur la décision déclenchante. Faire confiance à la précision (A) ou augmenter l’effort (C) ne rend pas une auto-action irréversible sûre, et la journalisation après coup (D) n’empêche pas le préjudice. ## Points clés à retenir - Le cadrage transforme un résultat en une tâche définie avec entrées, sorties et une métrique mesurable. - Définissez la métrique de réussite sur un jeu de test mis à part **avant** de choisir un modèle. - Recueillez le volume, la latence, le niveau de qualité, la sensibilité des données, les entrées et l’intégration — ils guident l’architecture. - Estimez l’enveloppe de coût à partir de `tokens × prix/MTok × volume` et comparez-la à la valeur métier. - Construisez le différenciateur, achetez la commodité, et ne forcez pas l’IA sur du travail déterministe prouvablement exact. - Utilisez le cadre SCOPE ; finissez Criteria avant de choisir Path. - Livrez la plus petite première version qui teste la métrique, avec des gates de revue sur les étapes à fort enjeu ou irréversibles.