Module L34 · Partie K · Ingénierie de l’IA

Choisir un modèle : une décision d’ingénierie, pas un classement.

Il existe des milliers de modèles ouverts, des dizaines d’API, et un classement public par semaine. Choisir, c’est traduire un besoin en exigences mesurables (qualité sur vos données, latence, coût, confidentialité, licence, maintenabilité), présélectionner des candidats, les évaluer sur votre banc d’essai (L32), et décider avec un coût total de possession. Ce chapitre donne la méthode, les grilles, les mathématiques de la décision multicritère et de l’arbitrage taille/qualité/coût, et les pièges (classements, licences, dépendance, obsolescence).

Durée : 2 séances · Prérequis : L27, L31, L32, L33. Objectifs : écrire une spécification de modèle ; présélectionner par contraintes dures puis évaluer ; construire une frontière de Pareto qualité/coût ; lire une licence et une carte de modèle ; documenter la décision et ses conditions de révision.

Ce que vous saurez faire à la fin

Transformer « on veut un chatbot » en 8 exigences chiffrées.
Présélectionner 3–5 candidats parmi des centaines, en 1 heure, sans les tester tous.
Comparer sur votre banc d’essai avec IC et coût total, et tracer la frontière de Pareto.
Rédiger une décision d’architecture (ADR) avec ses hypothèses et ses déclencheurs de révision.

Fiche de cours · Définitions

Définitions

Définition (exigence, contrainte dure, critère). Contrainte dure : élimine un candidat (licence incompatible, données qui ne peuvent pas sortir, latence > SLO, mémoire). Critère : à optimiser ou pondérer (qualité, coût, vitesse, empreinte). Une exigence est mesurable si elle a une métrique, un jeu de test et un seuil.

Définition (modèle de fondation, affiné, spécialisé, distillé). Fondation : pré-entraîné général (LLaMA, Mistral, Qwen, Gemma ; ViT, CLIP ; Whisper). Affiné : adapté par SFT/LoRA à un domaine ou un format. Spécialisé : entraîné pour une tâche (NER, détection). Distillé : petit modèle entraîné à imiter un grand (DistilBERT, versions « mini »).

Définition (ouvert, à poids ouverts, propriétaire). Ouvert : poids, code, données et licence permissive (OLMo, Pythia). À poids ouverts : poids téléchargeables sous licence spécifique, parfois restrictive (LLaMA : usage ≥ 700 M d’utilisateurs interdit ; Gemma : conditions d’usage). Propriétaire : accessible par API seulement (GPT, Claude, Gemini).

Définition (licence). MIT/Apache-2.0/BSD : usage libre y compris commercial ; CC-BY-NC : pas d’usage commercial ; licences « responsables » (RAIL, OpenRAIL) : restrictions d’usage ; licences sur mesure (Llama Community License). La licence des données d’entraînement et celle du modèle sont distinctes ; celle des sorties aussi.

Définition (carte de modèle, fiche de données). Documentation standardisée (Mitchell et al. 2019) : usage prévu, données d’entraînement, évaluations par tranche, limites, risques, considérations éthiques. Datasheets (Gebru et al. 2018) pour les jeux de données.

Définition (frontière de Pareto). Ensemble des candidats qu’aucun autre ne domine sur tous les critères à la fois ; le choix final se fait sur cette frontière selon les priorités.

Définition (coût total de possession, TCO). Coût sur la durée : inférence (tokens ou GPU-heures), affinage, évaluation, intégration, exploitation (ops, monitoring, mises à jour), risques (dépendance, changement de prix, arrêt d’un modèle).

Définition (ADR — architecture decision record). Document court : contexte, options considérées, décision, justification, conséquences, conditions de révision.

Fiche de cours · Formules

Formules et grilles à connaître

Score pondéré : S = Σ_i w_i·u_i(x_i), avec u_i une normalisation (min-max ou utilité) et Σ w_i = 1 — utile pour trier, dangereux pour décider : vérifier la sensibilité aux poids

Dominance de Pareto : A domine B si A ≥ B sur tous les critères et > sur au moins un ; frontière = non dominés

TCO_{3 ans} = coût d’inférence (volume × prix ou GPU-h) + affinage + évaluation initiale + intégration + ops × 36 mois + provision pour risques (changement de fournisseur : 2–6 semaines d’ingénierie)

Seuil de rentabilité local vs API (L33) : volume V* tel que V·p_API = coût fixe GPU + ops ; en dessous, API

Qualité vs taille (lois d’échelle, L25) : perte ≈ E + A/N^α — les gains de qualité décroissent avec la taille tandis que le coût croît linéairement : la taille optimale est celle où le gain marginal de qualité ne vaut plus le coût marginal (dérivée)

Valeur attendue d’une décision sous incertitude : E[valeur] = Σ_scénarios P(s)·valeur(s) ; valeur de l’information d’un test = E[valeur avec test] − E[valeur sans test] − coût du test

Marge de qualité : exiger que la borne basse de l’IC (L32) du candidat dépasse le seuil, pas sa moyenne

Règle des 80/20 de la présélection : contraintes dures d’abord (licence, confidentialité, mémoire, langue, modalité) — elles éliminent 80 % des candidats sans rien tester

Fiche de cours · Théorèmes et démonstrations

Ce qu’on peut démontrer sur le choix

Proposition 1 (le score pondéré peut inverser un classement selon la normalisation). Deux normalisations valides (min-max, ou par rapport à un seuil) peuvent donner des vainqueurs différents pour les mêmes poids.

Exemple : critères qualité q ∈ {0,80 ; 0,85} et coût c ∈ {1 ; 3} (€/M tokens) pour A et B, poids 0,5/0,5. Min-max : u_q(A) = 0, u_q(B) = 1 ; u_c(A) = 1, u_c(B) = 0 → égalité 0,5/0,5. Normalisation par seuils (q ≥ 0,75 requis, coût ≤ 5) : u_q = (q − 0,75)/0,25 → A 0,2, B 0,4 ; u_c = (5 − c)/5 → A 0,8, B 0,4 ; scores A 0,5, B 0,4 : A gagne. Ajouter un troisième candidat C (q = 0,60, c = 0,5) change les min-max de A et B sans les concerner (indépendance des alternatives non pertinentes violée). Conclusion : le score pondéré est un outil de tri et d’explicitation des priorités ; la décision doit être vérifiée sur la frontière de Pareto et par analyse de sensibilité aux poids.

Proposition 2 (un classement public ne prédit pas la performance sur votre tâche). Si la corrélation entre score de benchmark et score sur votre tâche est ρ, la variance expliquée est ρ² ; pour ρ = 0,6 (typique entre MMLU et une tâche métier), 64 % de la variance reste inexpliquée.

Définition de la corrélation et de R² pour une relation linéaire. Empiriquement, les classements (MMLU, Arena) corrèlent avec la qualité générale mais pas avec la performance sur un domaine précis, une langue, un format de sortie ou une contrainte de latence — et ils sont sujets à la contamination et à la variance de prompt (L32). Ils servent à présélectionner (éliminer les modèles clairement faibles), jamais à choisir : seul votre banc d’essai mesure ρ = 1.

Proposition 3 (la taille optimale est finie). Si la qualité suit q(N) = q_max − A/N^α et le coût c(N) = c₀ + c₁N, la valeur v(N) = V·q(N) − c(N) (V : valeur d’un point de qualité) est maximale en N* = (αAV/c₁)^1/(1+α), fini.

v′(N) = VαA/N^1+α − c₁ = 0 ⇔ N^1+α = αAV/c₁. v″ < 0 : maximum. Au-delà de N*, chaque point de qualité coûte plus qu’il ne rapporte. Pratique : pour un classement de tickets, un modèle de 8B affiné atteint 94 % et un 70B 95,5 % pour 9× le coût — le point et demi vaut-il 9× ? La réponse dépend de V (coût d’une erreur), pas du classement.

Proposition 4 (valeur de l’information d’un test préalable). Tester un candidat sur 200 cas avant de l’intégrer vaut la peine dès que le coût du test est inférieur à P(le candidat déçoit) × coût de l’intégration ratée.

Arbre de décision : sans test, on intègre et l’on découvre l’échec avec probabilité p, coût C_int perdu ; avec test (coût C_test), on évite l’intégration dans ce cas. Espérance de coût sans test : p·C_int ; avec test : C_test + (1 − p)·0 (réussite) + p·0 (rejet avant intégration). Le test est rentable ssi C_test < p·C_int. Avec p = 0,3, C_int = 20 jours-ingénieur : un test de 2 jours est rentable dès que p > 0,1. C’est pourquoi le banc d’essai précède toujours l’intégration.

01 / Spécifier

De « on veut de l’IA » à huit exigences chiffrées

Dimension	Question	Exigence (exemple : assistant de support interne)	Type
Tâche	Que doit faire le modèle, exactement ?	Répondre à des questions sur 2 000 pages de doc, en français, avec citations	—
Qualité	Métrique, jeu, seuil (L32)	Exactitude ≥ 0,80 et fidélité ≥ 0,90 sur 300 questions annotées, IC bas ≥ 0,75	Critère + seuil
Latence	SLO utilisateur	p95 ≤ 5 s pour 300 tokens de réponse	Dure
Volume et coût	Requêtes/jour, budget	5 000 req/jour, ≤ 400 €/mois d’inférence	Dure
Confidentialité	Les données peuvent-elles sortir ? Où ?	Documents internes : hébergement UE ou local ; pas d’entraînement du fournisseur sur nos données	Dure
Licence et conformité	Usage commercial, redistribution, AI Act	Licence permettant l’usage interne commercial ; documentation du modèle disponible	Dure
Langue, modalité, contexte	Français ? images ? longueur ?	Français natif ; texte seul ; contexte ≥ 16 k tokens	Dure
Exploitation	Qui maintient ? quelle infra (L33) ?	1 ingénieur à 20 % ; GPU 24 Go disponible ou API	Critère
Évolution	Fréquence de changement des données/du modèle	Doc mise à jour mensuellement ; changement de modèle ≤ 2 j d’effort	Critère
Risques	Ce qui ne doit jamais arriver	Pas d’invention de procédure de sécurité (refus + escalade) ; pas de fuite entre services	Dure

Chaque ligne « dure » élimine ; chaque « critère » se mesure. Si une exigence n’a pas de métrique et de seuil, elle n’est pas encore une exigence : c’est un souhait.

02 / Présélectionner et comparer

Filtrer par contraintes dures, puis Pareto sur le banc d’essai — implémenté

import numpy as np
# Candidats (valeurs illustratives : à remplacer par VOS mesures). qualité = exactitude sur votre banc (IC bas), cout = €/mois à 5 000 req/j, p95 en s
candidats = {
 "API frontière (propriétaire, US)":   dict(qualite=0.88, ic_bas=0.85, cout=1900, p95=4.0, local=False, ue=False, licence_ok=True,  fr=True,  ctx=128000),
 "API frontière (propriétaire, UE)":   dict(qualite=0.86, ic_bas=0.83, cout=1500, p95=4.5, local=False, ue=True,  licence_ok=True,  fr=True,  ctx=128000),
 "API modèle moyen (UE)":              dict(qualite=0.81, ic_bas=0.78, cout=350,  p95=3.0, local=False, ue=True,  licence_ok=True,  fr=True,  ctx=32000),
 "Ouvert 70B int4 (GPU cloud UE)":     dict(qualite=0.84, ic_bas=0.81, cout=900,  p95=6.5, local=True,  ue=True,  licence_ok=True,  fr=True,  ctx=32000),
 "Ouvert 8B int4 (GPU local)":         dict(qualite=0.79, ic_bas=0.76, cout=120,  p95=2.5, local=True,  ue=True,  licence_ok=True,  fr=True,  ctx=32000),
 "Ouvert 8B affiné LoRA (GPU local)":  dict(qualite=0.83, ic_bas=0.80, cout=150,  p95=2.5, local=True,  ue=True,  licence_ok=True,  fr=True,  ctx=32000),
 "Ouvert 3B (edge)":                   dict(qualite=0.68, ic_bas=0.64, cout=40,   p95=1.5, local=True,  ue=True,  licence_ok=True,  fr=False, ctx=8000),
 "Ouvert 8B licence non commerciale":  dict(qualite=0.82, ic_bas=0.79, cout=120,  p95=2.5, local=True,  ue=True,  licence_ok=False, fr=True,  ctx=32000),
}
dures = dict(ic_bas=0.75, cout=400, p95=5.0, ue=True, licence_ok=True, fr=True, ctx=16000)
def passe(c): return c["ic_bas"] >= dures["ic_bas"] and c["cout"] <= dures["cout"] and c["p95"] <= dures["p95"] and c["ue"] and c["licence_ok"] and c["fr"] and c["ctx"] >= dures["ctx"]
retenus = {n: c for n, c in candidats.items() if passe(c)}
print("après contraintes dures :", list(retenus) or "aucun")
for n, c in candidats.items():
    if not passe(c): print(f"  éliminé : {n:36s} → " + ", ".join(k for k in ("ic_bas", "cout", "p95", "ue", "licence_ok", "fr", "ctx") if (c[k] < dures[k] if k in ("ic_bas", "ctx") else (c[k] > dures[k] if k in ("cout", "p95") else not c[k]))))
# Frontière de Pareto (maximiser qualité, minimiser coût) parmi les retenus
def domine(a, b): return a["qualite"] >= b["qualite"] and a["cout"] <= b["cout"] and (a["qualite"] > b["qualite"] or a["cout"] < b["cout"])
pareto = [n for n, c in retenus.items() if not any(domine(retenus[m], c) for m in retenus if m != n)]
print("\nfrontière de Pareto (qualité ↑, coût ↓) :", pareto)
# Score pondéré — et sa sensibilité aux poids (Proposition 1)
def score(c, w_q, w_c, w_l):
    q = (c["qualite"] - 0.75) / 0.15; co = 1 - c["cout"] / 400; la = 1 - c["p95"] / 5; return w_q * q + w_c * co + w_l * la
for w in ((0.6, 0.3, 0.1), (0.4, 0.5, 0.1), (0.5, 0.2, 0.3)):
    best = max(retenus, key=lambda n: score(retenus[n], *w)); print(f"poids qualité/coût/latence {w} → {best}")
print("\nSi le vainqueur change avec des poids raisonnables, la décision n'est pas robuste : retourner aux priorités métier (que vaut un point d'exactitude ?).")

02 / Présélectionner et comparer

Coût total de possession et taille optimale (Proposition 3)

import numpy as np
# TCO sur 3 ans pour trois options retenues (€) : inférence + affinage + évaluation + intégration + ops + risque
options = {
 "API modèle moyen (UE)":             dict(inference=350 * 36, affinage=0,     evaluation=3000, integration=6000,  ops_mois=400,  risque=8000),
 "Ouvert 8B affiné LoRA (GPU local)": dict(inference=150 * 36, affinage=4000,  evaluation=5000, integration=12000, ops_mois=1200, risque=3000),
 "Ouvert 8B int4 (GPU local)":        dict(inference=120 * 36, affinage=0,     evaluation=3000, integration=10000, ops_mois=1000, risque=3000),
}
print(f"{'option':36s} {'TCO 3 ans':>10s} {'dont ops':>9s} {'€/req':>7s}")
for n, o in options.items():
    tco = o["inference"] + o["affinage"] + o["evaluation"] + o["integration"] + o["ops_mois"] * 36 + o["risque"]
    print(f"{n:36s} {tco:10.0f} {o['ops_mois']*36:9.0f} {tco / (5000 * 365 * 3):7.4f}")
print("→ l'inférence n'est qu'une part ; l'exploitation (ops) domine pour le local ; le risque (changement de prix/arrêt) pèse sur l'API.")
# Taille optimale : q(N) = q_max − A/N^α ; coût c(N) = c0 + c1·N ; valeur V par point de qualité
q_max, A, alpha = 0.92, 1.9, 0.30                          # ajustés pour : 3B → 0,82 ; 8B → 0,86 ; 70B → 0,90 (illustratif)
q = lambda N: q_max - A / (N / 1e9) ** alpha / 10
for N in (3e9, 8e9, 70e9): print(f"qualité prédite {N/1e9:.0f}B : {q(N):.3f}")
c1 = 0.12                                                    # € par an et par milliard de paramètres (à 5 000 req/j, ordre de grandeur)
for V in (50, 500, 5000):                                    # € par an que vaut UN point (0,01) de qualité pour le métier
    Ns = np.logspace(9, 11.5, 400); v = V * 100 * q(Ns) - c1 * Ns / 1e9; N_opt = Ns[v.argmax()]
    print(f"un point de qualité vaut {V:5d} €/an → taille optimale ≈ {N_opt/1e9:5.1f}B (qualité {q(N_opt):.3f})")
print("→ la 'meilleure' taille dépend de ce que vaut la qualité pour VOUS ; pas de la course aux paramètres.")

03 / Lire

Lire une carte de modèle et une licence : la liste de contrôle

Élément	Où	Ce qu’il faut vérifier	Signal d’alerte
Usage prévu / exclu	Carte de modèle	Votre cas est-il dans l’usage prévu ? Exclusions (médical, juridique, mineurs) ?	Aucune mention d’usages exclus
Données d’entraînement	Carte, article	Sources, langues, dates de coupure, filtrage, données personnelles, contamination des benchmarks	« Données web » sans détail ; pas de date
Évaluations	Carte, article, classements indépendants	Par tranche, en français, avec IC ; jeux privés ; robustesse ; sécurité (red teaming)	Un seul chiffre ; seulement des benchmarks publics
Licence du modèle	Fichier LICENSE, page HF	Usage commercial ? redistribution ? restrictions (utilisateurs, secteurs, attribution) ? clause de résiliation ?	Licence « custom » non relue par un juriste
Licence des données et des sorties	Idem + conditions d’utilisation API	Le fournisseur revendique-t-il des droits sur les sorties ? Entraîne-t-il sur vos données ?	« Nous pouvons utiliser vos données pour améliorer le service »
Sécurité et alignement	Carte, rapports	Taux de refus, sur-refus, jailbreaks connus, biais mesurés	Aucune évaluation de sécurité
Reproductibilité	Dépôt	Code d’entraînement, recette, poids intermédiaires, tokeniseur	Poids seuls
Maintenance	Historique	Fréquence des mises à jour, versions figées disponibles (API), politique de dépréciation	Modèles retirés sans préavis
Conformité	AI Act, RGPD, secteur	Catégorie de risque, documentation exigée, transparence (contenu généré), DPIA	Aucune documentation fournie

04 / Décider

La décision d’architecture : modèle d’ADR et déclencheurs de révision

# ADR-007 : modèle pour l'assistant de support interne
Date : 2026-09 · Statut : accepté · Décideurs : équipe IA + DSI + juridique

Contexte
  5 000 questions/jour sur la documentation interne (FR), données confidentielles, budget 400 €/mois,
  SLO p95 5 s, 1 ingénieur à 20 % pour l'exploitation. Banc d'essai : 300 questions annotées + 60 refus + 40 adverses (L32).

Options considérées (contraintes dures : hébergement UE, licence commerciale, FR, contexte ≥ 16 k, coût ≤ 400 €/mois, p95 ≤ 5 s)
  A. API modèle moyen (UE)            exactitude 0,81 [0,78 ; 0,84]  fidélité 0,93  350 €/mois  p95 3,0 s
  B. Ouvert 8B affiné LoRA (local)    exactitude 0,83 [0,80 ; 0,86]  fidélité 0,91  150 €/mois  p95 2,5 s  ops 1 200 €/mois
  C. Ouvert 8B int4 (local)           exactitude 0,79 [0,76 ; 0,82]  fidélité 0,90  120 €/mois  p95 2,5 s
  (éliminés : API US — confidentialité ; 70B — coût ; 3B — qualité et FR)

Décision : A pour la mise en production initiale ; B préparé en parallèle.
Justification : A et B sont sur la frontière de Pareto ; la différence de qualité (2 pts) n'est pas significative (IC chevauchants) ;
  A demande 3× moins d'exploitation et permet de livrer en 3 semaines ; le TCO 3 ans est équivalent (±10 %).
  Le contrat API garantit : hébergement UE, pas d'entraînement sur nos données, version figée 12 mois.

Conséquences : dépendance à un fournisseur (mitigée par une couche d'abstraction et le banc d'essai réutilisable pour B) ;
  coûts variables avec le volume ; données transitant chez un tiers (accord de traitement signé).

Déclencheurs de révision : volume > 15 000 req/j (seuil de rentabilité local) ; hausse de prix > 30 % ; dépréciation du modèle ;
  exactitude mesurée < 0,78 deux semaines de suite (monitoring L35) ; exigence de hors-ligne ; B atteint 0,85 sur le banc.

Un ADR tient sur une page, se relit en 5 minutes, et évite de refaire le débat dans six mois. Les déclencheurs transforment la décision en processus : on ne « choisit » pas un modèle une fois, on le re-choisit à chaque signal.

05 / Pièges

Les erreurs classiques de sélection

Piège	Pourquoi c’est tentant	Conséquence	Parade
Choisir sur un classement public	Rapide, « objectif »	Proposition 2 : mauvaise prédiction sur votre tâche ; contamination	Banc d’essai privé avant toute décision
Tester avec 20 exemples	Pas de jeu annoté	IC de ± 20 points ; décision au bruit	≥ 150–300 cas (L28, L32) ; annoter est l’investissement le plus rentable
Le plus gros modèle « au cas où »	Peur de manquer de qualité	Coût et latence ×10 pour 1–2 points ; Proposition 3	Mesurer la qualité marginale ; commencer petit, monter si le banc l’exige
Ignorer la licence	« Tout le monde l’utilise »	Blocage juridique tardif, refonte	Licence lue et validée avant l’évaluation
Oublier l’exploitation	Le PoC marchait	Personne pour maintenir le GPU, les mises à jour, la sécurité	Compter les ops dans le TCO ; nommer un responsable
Verrouillage fournisseur	API pratique	Changer de modèle = réécrire les prompts, refaire l’évaluation	Abstraction (interface unique), prompts versionnés, banc réutilisable
Comparer à budgets inégaux	Un candidat a été réglé, l’autre non	Faux vainqueur	Même effort de prompt/affinage pour chaque candidat
Décider une fois pour toutes	Confort	Modèle obsolète en 12 mois	Déclencheurs de révision ; re-test trimestriel
Affiner avant d’avoir essayé le prompt et le RAG	L’affinage semble « sérieux »	Semaines perdues pour un gain que le RAG donnait	Escalade : prompt → RAG → LoRA → complet (L37)

06 / Articles

Les articles et documents à lire

Référence	Contribution	À retenir
Mitchell et al., Model Cards for Model Reporting, FAT* 2019 — 1810.03993	Documentation standard d’un modèle	Exiger une carte ; en écrire une pour les vôtres
Gebru et al., Datasheets for Datasets, 2018 — 1803.09010	Documentation des jeux de données	Provenance, consentement, usages (L36)
Bommasani et al., On the Opportunities and Risks of Foundation Models, 2021 — 2108.07258	Le paradigme des modèles de fondation	Homogénéisation : un défaut du modèle se propage à toutes les applications
Liang et al., HELM, 2022 (L32)	Évaluation multi-métriques comparable	Base de présélection plus riche qu’un score
Hoffmann et al., Chinchilla, 2022 (L25)	Qualité vs taille vs données	Proposition 3 : la taille optimale est une question de coût
Grinsztajn et al., 2022 (L31)	Arbres vs réseaux sur tableaux	Le « modèle à la mode » perd souvent
Sculley et al., Hidden Technical Debt in ML Systems, 2015	Coûts cachés	Le TCO est dominé par le système, pas le modèle
Nygard, Documenting Architecture Decisions, 2011 (blog) ; ThoughtWorks Technology Radar	Format ADR	Décision + contexte + conséquences + révision
Règlement (UE) 2024/1689 (AI Act) ; lignes directrices CNIL sur l’IA	Obligations par niveau de risque	Documentation, transparence, gestion des risques ; un critère de choix
Open Source Initiative, Open Source AI Definition (2024) ; licences RAIL	Ce que « ouvert » veut dire	Poids ouverts ≠ open source
Chatbot Arena, Open LLM Leaderboard, LiveBench, SEAL	Classements	Présélection seulement ; lire la méthodologie et la date

TP guidé

TP — Sélection complète pour un cas réel (4 h)

Cas. Choisir un besoin réel (support, extraction de documents, classification d’images de robot, transcription de réunions). Écrire les 8–10 exigences (tableau 01) avec métriques et seuils.
Présélection. Lister 10 candidats (HF Hub, APIs) ; appliquer les contraintes dures avec justification ligne par ligne (licence lue !) ; garder 3–4.
Banc d’essai. 150 cas annotés + 20 pièges ; même prompt/effort pour tous ; mesures L32 avec IC ; latence et coût réels (factures/mesures).
Analyse. Frontière de Pareto ; score pondéré avec 3 jeux de poids (sensibilité) ; TCO 3 ans ; Proposition 3 sur vos chiffres.
Décision. ADR d’une page avec déclencheurs de révision ; revue par un pair qui doit pouvoir reconstruire la décision à partir des chiffres seuls.
Livrable. Exigences, tableau des candidats, banc d’essai reproductible, ADR.

Exercices

Exercices auto-corrigés

Exercice 1 — Frontière de Pareto multi-critères

Écrivez pareto(points, sens) : points = dict nom → tuple de valeurs, sens = tuple de "max"/"min" ; renvoie l’ensemble des noms non dominés. Testez sur 3 critères.

Correction

def pareto(points, sens):
    def mieux_ou_egal(a, b): return all((x >= y) if s == "max" else (x <= y) for x, y, s in zip(a, b, sens))
    def domine(a, b): return mieux_ou_egal(a, b) and a != b
    return {n for n, p in points.items() if not any(domine(q, p) for m, q in points.items() if m != n)}

Exercice 2 — Sensibilité du score pondéré

Écrivez vainqueurs(candidats, normalise, grille_poids) qui renvoie le dict {vainqueur: nombre de jeux de poids où il gagne} pour une grille de poids (toutes les combinaisons (w_q, w_c) avec pas 0,1, w_q + w_c = 1), avec deux normalisations : "minmax" et "seuils" (q : (q − 0,75)/0,15 ; c : 1 − c/2000). Montrez que la normalisation change le vainqueur pour certains poids (Proposition 1).

Correction

def vainqueurs(candidats, normalise):
    from collections import Counter
    qs = np.array([v[0] for v in candidats.values()]); cs = np.array([v[1] for v in candidats.values()]); noms = list(candidats)
    if normalise == "minmax": uq = (qs - qs.min()) / (qs.max() - qs.min()); uc = (cs.max() - cs) / (cs.max() - cs.min())
    else: uq = (qs - 0.75) / 0.15; uc = 1 - cs / 2000
    res = Counter()
    for wq in np.round(np.arange(0, 1.01, 0.1), 1): res[noms[int(np.argmax(wq * uq + (1 - wq) * uc))]] += 1
    return res

Exercices

Exercices auto-corrigés (suite)

Exercice 3 — TCO et seuil de rentabilité

Écrivez tco(option, mois) (dict avec inference_mois, fixe, ops_mois, risque) et seuil_volume(prix_api_par_req, cout_fixe_local_mois, ops_local_mois, cout_var_local_par_req) : volume mensuel V* où API et local coûtent pareil (None si le local ne devient jamais rentable).

Correction

def tco(option, mois): return option["inference_mois"] * mois + option["fixe"] + option["ops_mois"] * mois + option["risque"]
def seuil_volume(prix_api, fixe_local, ops_local, var_local):
    if prix_api <= var_local: return None
    return (fixe_local + ops_local) / (prix_api - var_local)

Exercice 4 — Valeur de l’information d’un test (Proposition 4)

Écrivez test_rentable(p_echec, cout_integration, cout_test) et p_min(cout_integration, cout_test) (probabilité d’échec à partir de laquelle le test est rentable). Puis taille_test(delta, p) = nombre de cas pour détecter un écart delta d’exactitude autour de p (16p(1−p)/Δ²), et le coût du test à c € par cas annoté.

Correction

def test_rentable(p_echec, cout_integration, cout_test): return cout_test < p_echec * cout_integration
def p_min(cout_integration, cout_test): return cout_test / cout_integration
def taille_test(delta, p): return 16 * p * (1 - p) / delta ** 2

Fiche de cours · Exercices corrigés

Exercices corrigés (rédaction)

Exercice 1. Une direction demande « le meilleur modèle du classement Arena » pour classer des tickets de maintenance en 12 catégories. Rédiger la réponse.

Correction. (1) La tâche est une classification fermée sur du texte technique interne : ce que mesure l’Arena (préférence conversationnelle générale) y est faiblement corrélé (Proposition 2). (2) Les candidats naturels sont un encodeur affiné (BERT-like, ~100 M de paramètres : quelques ms, coût ≈ 0, hébergement local) ou un petit LLM en few-shot ; un modèle frontière coûterait 100× plus pour, probablement, une exactitude proche. (3) Proposer : annoter 600 tickets (50 par catégorie), banc d’essai avec macro-F1 (classes déséquilibrées, L32), comparer 3 candidats (encodeur affiné, LLM 8B few-shot, API moyenne) à effort égal, avec IC. (4) Décider par Pareto et TCO ; documenter dans un ADR avec déclencheurs (nouvelles catégories, dérive). Le « meilleur modèle » n’existe pas sans la tâche et le coût.

Exercice 2. Deux candidats : A (exactitude 0,84, IC [0,80 ; 0,88], 900 €/mois) et B (0,81, [0,78 ; 0,84], 150 €/mois). Le seuil d’exigence est 0,80 (borne basse). Que choisir et pourquoi ?

Correction. A satisfait l’exigence (borne basse 0,80 ≥ 0,80, à la limite) ; B ne la satisfait pas (0,78 < 0,80) bien que sa moyenne dépasse le seuil : on exige la borne basse (formulaire). Mais l’écart entre A et B (3 points) n’est pas significatif (IC chevauchants) : avant de payer 6× plus, agrandir le jeu de test (300 → 800 cas : IC ÷ 1,6) ou améliorer B (prompt, RAG, LoRA : L37) pour qu’il passe le seuil — un test de 2 jours vaut moins que 750 €/mois × 36 (Proposition 4). Si B ne passe toujours pas, A avec déclencheur de révision « B ≥ 0,82 en borne basse ».

Exercice 3. Quels sont les risques d’une dépendance totale à une API propriétaire, et comment les réduire concrètement ?

Correction. Risques : hausse de prix (historiquement dans les deux sens), dépréciation d’une version (les prompts réglés sur elle régressent), changement silencieux de comportement, panne ou limitation de débit, changement des conditions (usage des données), indisponibilité géographique, dépendance réglementaire (transferts de données), et dérive de la qualité mesurée. Réductions : (1) couche d’abstraction (une interface, plusieurs fournisseurs) ; (2) prompts et banc d’essai versionnés, exécutés automatiquement à chaque changement de version du fournisseur (L35) ; (3) versions figées contractuelles ; (4) un modèle ouvert de secours évalué et prêt (même si moins bon) ; (5) cache des réponses fréquentes ; (6) budget d’alerte ; (7) clause contractuelle sur les données ; (8) déclencheurs de révision dans l’ADR.

Vérification

Quelle est la première étape valide pour choisir un modèle ?

Deux questions supplémentaires

1. Pourquoi exiger la borne basse de l’IC plutôt que la moyenne ? Pour que l’exigence soit satisfaite avec une confiance connue, pas par chance d’échantillonnage.

2. À quoi sert un ADR ? À rendre la décision reconstructible, discutable, et révisable sur des déclencheurs explicites.

Référence

Les mots à retenir

Mot	Définition
Contrainte dure / critère	Élimine / se pondère.
Frontière de Pareto	Candidats non dominés ; le choix s’y fait selon les priorités.
Score pondéré	Outil de tri, sensible à la normalisation et aux poids.
TCO	Inférence + affinage + évaluation + intégration + ops + risques.
Carte de modèle	Usage, données, évaluations, limites, licence.
Poids ouverts ≠ open source	Lire la licence ; données et sorties sont à part.
ADR	Décision documentée avec déclencheurs de révision.
Valeur de l’information	Tester avant d’intégrer si C_test < p × C_intégration.

Suite

Le modèle est choisi et déployé. Maintenant il faut le garder vivant.

Chapitre suivant : maintenir un modèle — dérive des données et des concepts, monitoring, ré-entraînement, versions, retours utilisateurs, incidents, et le coût du silence.

← L33 Sommaire L35 : maintenir →