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

Gérer un projet IA : cadrer, estimer sous incertitude, piloter, arrêter, capitaliser.

Un projet IA n’est pas un projet logiciel classique : le résultat est incertain (personne ne sait, avant d’avoir mesuré, si l’exigence est atteignable), les données sont le chemin critique, la valeur dépend d’une adoption, et le produit vit après la livraison (L35). Ce chapitre donne la méthode de cadrage (problème, valeur, faisabilité), l’estimation probabiliste (intervalles, simulation Monte-Carlo, jalons de décision), l’organisation (rôles, rituels, portefeuille), le pilotage par les mesures (banc d’essai comme tableau de bord), la communication (résultats avec incertitude, démonstrations honnêtes), la gestion des risques et de l’arrêt, l’administration (budget, contrats, données, conformité) — avec des simulations et des références.

Durée : 3 séances · Prérequis : L24, L32, L34, L37, L38. Objectifs : produire un cadrage en une page avec critères de succès et de sortie ; estimer un projet par intervalles et simulation ; organiser un cycle en jalons de décision ; construire le tableau de bord d’un portefeuille ; communiquer un résultat incertain à un décideur ; arrêter un projet proprement.

Ce que vous saurez faire à la fin

Écrire un cadrage qui distingue problème, solution, valeur, faisabilité et risques.
Donner une estimation en distribution (P10/P50/P90) et la défendre.
Découper un projet en jalons dont chacun peut arrêter le projet — et savoir ce qu’on apprend à chaque jalon.
Administrer : budget de calcul et d’annotation, contrats de données et d’API, conformité, capitalisation.

Fiche de cours · Définitions

Définitions

Définition (cadrage). Document d’une page : problème (qui, quoi, aujourd’hui, coût du statu quo), résultat attendu (KPI métier), hypothèse de solution (escalade, L37), exigences mesurables (L34), faisabilité (données, calcul, compétences), risques, critères de succès et de sortie, jalons, budget, responsable.

Définition (jalon de décision). Point du projet où l’on décide, sur des mesures, de continuer, pivoter ou arrêter : faisabilité des données (J1), preuve de concept sur le banc d’essai (J2), pilote en conditions réelles (J3), production (J4), revue post-déploiement (J5). Un jalon a un livrable, un critère, une date et un décideur.

Définition (estimation probabiliste). Estimer chaque tâche par un intervalle (P10, P50, P90) plutôt qu’un point ; agréger par simulation Monte-Carlo ; communiquer la distribution du délai/coût et la probabilité de tenir une date.

Définition (valeur, coût, risque). Valeur = gain métier attendu (temps, erreurs évitées, revenu) × probabilité d’adoption ; coût = TCO (L34) + coût d’opportunité ; risque = probabilité × impact des échecs (techniques, données, adoption, conformité). Décision par valeur attendue et par tolérance au risque.

Définition (portefeuille de modèles). Ensemble des systèmes IA d’une organisation avec, pour chacun : propriétaire, valeur, coût d’exploitation, risque, état de santé (monitoring), dette, date de revue. Sert à arbitrer les ressources et à décommissionner.

Définition (rituels). Revue d’expériences hebdomadaire (banc d’essai, décisions), revue de jalon, revue de production mensuelle (dérive, incidents, coûts), rétrospective, revue de portefeuille trimestrielle.

Définition (adoption). Utilisation effective par les personnes visées ; mesurée (taux d’usage, taux d’acceptation des suggestions, taux de contournement) ; conditionnée par la confiance, l’intégration au flux de travail, la formation, l’explicabilité et la gestion des erreurs.

Définition (capitalisation). Ce qui survit au projet : jeux de données documentés, bancs d’essai, composants réutilisables, ADR, post-mortems, compétences — souvent plus précieux que le modèle.

Fiche de cours · Formules

Formules à connaître

Valeur attendue d’un projet : E[V] = Σ_scénarios P(s)·(gain(s) − coût(s)) ; avec jalons : on paie chaque phase seulement si la précédente réussit — E[coût] = c₁ + p₁c₂ + p₁p₂c₃ + … (structure d’option)

Estimation à trois points (PERT) : moyenne ≈ (P10 + 4·P50 + P90)/6, écart-type ≈ (P90 − P10)/2,56 (approximation gaussienne) ; la somme de tâches indépendantes a une variance = somme des variances — mais les tâches d’un projet sont corrélées (même équipe, mêmes surprises) : simuler avec corrélation

Loi de Hofstadter empirique : les projets ML dépassent de 2 à 3× l’estimation initiale ; les postes sous-estimés : données (annotation, nettoyage), évaluation, intégration, adoption

Probabilité de tenir la date D : P(T ≤ D) lue sur la distribution simulée ; s’engager sur P80, communiquer P50 et P90

Budget de calcul : heures GPU = Σ expériences × durée × (1 + taux d’échec) ; règle : 3× le budget de la « meilleure exécution » ; budget d’annotation (L36)

Retour sur investissement : ROI = (gain annuel − coût annuel d’exploitation)/coût initial ; délai de récupération = coût initial/(gain − coût) mensuel

Valeur de l’information d’un jalon (L34, Proposition 4) : un jalon vaut la peine si son coût < P(échec révélé) × coût évité des phases suivantes

Coût de l’adoption : bénéfice réel = bénéfice théorique × taux d’usage × taux d’acceptation ; un modèle à 95 % utilisé à 20 % vaut moins qu’un modèle à 85 % utilisé à 90 %

Vélocité d’apprentissage : nombre d’expériences mesurées par semaine — le meilleur prédicteur de succès d’une équipe ML (Ng) ; à suivre comme un KPI

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

Ce qu’on peut démontrer sur le pilotage

Proposition 1 (les jalons de décision réduisent le coût attendu d’un projet incertain). Un projet en n phases de coûts c_i avec probabilités de succès p_i révélées à chaque jalon coûte en espérance c₁ + p₁c₂ + p₁p₂c₃ + … < Σc_i ; sans jalon (tout engagé d’avance), on paie Σc_i quoi qu’il arrive.

On ne paie la phase k que si toutes les précédentes ont réussi, événement de probabilité Π_i<kp_i < 1 ; l’espérance du coût est donc strictement inférieure à la somme dès qu’un p_i < 1. Exemple : 4 phases à 50 k€ avec p = 0,7, 0,6, 0,8 : espérance 50 + 35 + 21 + 16,8 = 123 k€ contre 200 k€. Ce raisonnement (options réelles) suppose que les jalons ont des critères honnêtes : un jalon qu’on ne franchit jamais négativement n’a aucune valeur. D’où : critères de sortie écrits à l’avance, décideur nommé, et une culture où arrêter un projet sur mesure est un succès de pilotage.

Proposition 2 (l’estimation par somme de P50 sous-estime la somme). Si les durées sont asymétriques (queue à droite, ce qui est la règle), la médiane de la somme est supérieure à la somme des médianes ; la moyenne de la somme est la somme des moyennes.

Pour une loi asymétrique à droite, moyenne > médiane. La somme de n tâches indépendantes tend vers une gaussienne (TCL, L11) dont médiane = moyenne = Σ moyennes > Σ médianes. Additionner des P50 (« si tout se passe normalement ») donne donc un planning que l’on tient avec une probabilité < 50 %, souvent bien moins avec la corrélation entre tâches (un retard de données retarde tout). Remède : estimer par intervalles, simuler, s’engager sur P80.

Proposition 3 (l’adoption est une contrainte multiplicative : elle domine la précision au-delà d’un seuil). Bénéfice = B₀ × q × u où q est la qualité relative (0–1) et u le taux d’usage ; à effort constant, si q ≥ 0,85 et u ≤ 0,5, un point de u vaut plus qu’un point de q.

∂B/∂u = B₀q et ∂B/∂q = B₀u : le gain marginal de l’usage dépasse celui de la qualité dès que q > u. Dans la plupart des projets, q est déjà élevée (le modèle marche sur le banc) et u faible (interface, confiance, flux de travail) : l’effort doit aller à l’adoption — intégration, explication des erreurs, formation, retours — et la mesure d’adoption doit être dans le tableau de bord dès le pilote. Un projet « techniquement réussi et jamais utilisé » est l’échec le plus fréquent en IA.

Proposition 4 (arrêter tôt a une valeur calculable). Si à un jalon la probabilité estimée d’atteindre l’exigence tombe à p et que le reste du projet coûte R pour une valeur V en cas de succès, continuer vaut pV − R ; arrêter vaut 0 (plus la capitalisation). Continuer n’est rationnel que si p > R/V.

Comparaison des valeurs attendues (coûts déjà engagés exclus : ils sont irrécupérables — sunk cost). Pour R = 100 k€ et V = 300 k€, il faut p > 1/3 ; si le banc d’essai plafonne à 0,72 pour une exigence de 0,85 après avoir épuisé les paliers raisonnables (L37), p est probablement < 0,2 : arrêter, capitaliser (données, banc, apprentissages), et éventuellement re-cadrer (exigence différente, périmètre réduit, humain dans la boucle) — ce qui est un nouveau projet, avec son propre cadrage.

01 / Cadrer

Le cadrage en une page : modèle rempli

CADRAGE — Assistant de tri et de réponse aux tickets de maintenance (v1.2, 2026-09)

Problème     : 1 800 tickets/mois triés à la main par 3 techniciens (25 % de leur temps) ; 18 % mal routés (délai +2 jours) ;
               coût du statu quo ≈ 0,75 ETP + retards estimés à 30 k€/an.
Résultat visé: routage automatique validé par un humain ; KPI : part des tickets routés sans correction ≥ 85 %, délai médian −1 jour.
Hypothèse    : escalade L37 — baseline règles (existe : 62 %), classifieur sur plongements (J2), puis LLM few-shot si nécessaire ;
               suggestion de réponse en v2 seulement.
Exigences    : macro-F1 ≥ 0,85 (borne basse IC) sur 600 tickets annotés ; latence < 2 s ; hébergement interne ; 12 catégories ;
               refus (« à trier manuellement ») quand confiance < seuil ; journalisation.
Faisabilité  : 40 000 tickets historiques (2 ans) avec catégorie finale (étiquettes gratuites mais bruitées : à mesurer) ;
               GPU 24 Go disponible ; 1 ingénieur ML à 60 %, 1 technicien référent à 20 %.
Risques      : étiquettes historiques incohérentes (catégories renommées en 2025) — J1 ; dérive saisonnière — monitoring ;
               adoption (les techniciens contournent) — pilote avec eux ; données personnelles dans les tickets — anonymisation.
Jalons       : J1 (S+3) qualité des données : kappa ≥ 0,7 sur 300 tickets ré-annotés, sinon re-cadrer les catégories.
               J2 (S+7) preuve de concept : F1 ≥ 0,85 borne basse, sinon palier suivant ou arrêt (p < 1/3).
               J3 (S+12) pilote 4 semaines avec 3 techniciens : taux d'acceptation ≥ 80 %, retours qualitatifs.
               J4 (S+16) production + monitoring ; J5 (S+28) revue : KPI atteint ? coûts ? décision de v2.
Critères de sortie : J1 échoué deux fois ; J2 < 0,75 après palier 5 ; J3 acceptation < 50 % ; coût > 2× budget.
Budget       : 45 jours-personne, 400 € de calcul, 1 500 € d'annotation ; TCO 3 ans ≈ 38 k€ ; gain estimé 45 k€/an (P50), P10 : 15 k€.
Responsable  : cheffe de projet maintenance ; décideur des jalons : directeur des opérations.

Chaque ligne est vérifiable. Les critères de sortie sont écrits avant que quiconque ait investi son ego dans le projet — c’est leur seule chance d’être appliqués.

02 / Estimer

Estimation par intervalles et simulation Monte-Carlo : le planning comme distribution

import numpy as np
rng = np.random.default_rng(0)
# Tâches estimées en jours (P10, P50, P90) ; dépendances séquentielles simplifiées ; corrélation commune (facteur "équipe/surprises")
taches = {"cadrage": (2, 3, 5), "accès et audit des données": (3, 6, 15), "annotation 600 tickets": (4, 7, 14), "nettoyage et séparation": (2, 4, 9),
          "baseline + plongements": (3, 5, 9), "évaluation et analyse d'erreurs": (2, 4, 8), "palier suivant (si nécessaire, p = 0,5)": (0, 6, 15),
          "intégration et interface": (5, 10, 20), "pilote 4 semaines (calendaire, effort)": (4, 6, 10), "mise en production + monitoring": (3, 5, 10)}
def tirer(p10, p50, p90, z):
    """Log-normale calibrée sur P10/P50/P90 ; z partagé pour la corrélation."""
    mu = np.log(max(p50, 0.1)); sig = (np.log(max(p90, 0.1)) - np.log(max(p10, 0.1))) / 2.56; return np.exp(mu + sig * z)
N = 20000; total = np.zeros(N)
for i in range(N):
    z_commun = rng.normal(); duree = 0.0
    for nom, (a, b, c) in taches.items():
        if "p = 0,5" in nom and rng.random() < 0.5: continue                                   # tâche conditionnelle
        z = 0.6 * z_commun + 0.8 * rng.normal(); duree += tirer(a, b, c, z)                       # corrélation ≈ 0,36 entre tâches
    total[i] = duree
somme_p50 = sum(b for _, (a, b, c) in taches.items()) - 3                                        # somme des P50 (tâche conditionnelle comptée à moitié)
print(f"somme des P50 : {somme_p50:.0f} jours | simulation : P10 {np.percentile(total, 10):.0f}, P50 {np.percentile(total, 50):.0f}, P80 {np.percentile(total, 80):.0f}, P90 {np.percentile(total, 90):.0f} jours")
print(f"probabilité de tenir 'la somme des P50' : {np.mean(total <= somme_p50):.0%} (Proposition 2) ; s'engager sur P80 = {np.percentile(total, 80):.0f} jours")
# Sensibilité : quelle tâche explique le plus la variance ? (corrélation entre sa durée tirée et le total)
contrib = {}
for nom, (a, b, c) in taches.items():
    z = rng.normal(0, 1, 5000); d = tirer(a, b, c, z); contrib[nom] = np.std(d)
for nom, s in sorted(contrib.items(), key=lambda kv: -kv[1])[:4]: print(f"  incertitude dominante : {nom:42s} σ ≈ {s:.1f} j")
print("→ réduire l'incertitude là où elle est (données, intégration) : un audit des données de 2 jours (J1) vaut plus qu'une semaine de modélisation.")

02 / Estimer

Valeur attendue, jalons et décision d’arrêt — simulés (Propositions 1 et 4)

import numpy as np
rng = np.random.default_rng(1)
# Projet en 4 phases : coûts et probabilités de succès estimées ; valeur en cas de succès (P10/P50/P90 du gain annuel × 3 ans − exploitation)
phases = [("J1 données", 8000, 0.75), ("J2 preuve de concept", 15000, 0.6), ("J3 pilote", 20000, 0.8), ("J4 production", 12000, 0.95)]
V = lambda: max(0, np.exp(rng.normal(np.log(110000), 0.5)) - 20000)                                # valeur 3 ans, log-normale (P50 ≈ 90 k€)
def simuler(avec_jalons=True, n=20000):
    res = []
    for _ in range(n):
        cout, ok = 0.0, True
        for nom, c, p in phases:
            if not ok and avec_jalons: break                                                        # arrêt au jalon raté
            cout += c
            if rng.random() > p: ok = False
        res.append((V() if ok else 0.0) - cout)
    return np.array(res)
a, s = simuler(True), simuler(False)
print(f"avec jalons : valeur nette attendue {a.mean():8.0f} € ; P(perte) {np.mean(a < 0):.0%} ; perte max {a.min():.0f} €")
print(f"sans jalons : valeur nette attendue {s.mean():8.0f} € ; P(perte) {np.mean(s < 0):.0%} ; perte max {s.min():.0f} €")
print(f"coût attendu avec jalons (Proposition 1) : {8000 + 0.75*15000 + 0.75*0.6*20000 + 0.75*0.6*0.8*12000:.0f} € vs {sum(c for _, c, _ in phases)} € engagés d'avance")
# Décision d'arrêt à J2 (Proposition 4) : p estimée d'atteindre l'exigence après la preuve de concept, reste R, valeur V
R = 20000 + 12000; Vm = 90000
for p in (0.6, 0.35, 0.15): print(f"à J2, p = {p:.2f} : continuer vaut {p*Vm - R:7.0f} € → {'continuer' if p * Vm - R > 0 else 'ARRÊTER (seuil p > R/V = %.2f)' % (R / Vm)}")
print("\nLes coûts déjà engagés n'entrent pas dans la décision (sunk cost) ; ce qui compte est ce qu'il reste à payer contre ce qu'on peut encore gagner.")

03 / Organiser et piloter

Cycle, rôles, rituels, tableau de bord : le projet piloté par les mesures

Jalon	Question	Livrable	Critère (exemple)	Décision possible
J0 Cadrage	Vaut-il la peine d’essayer ?	Cadrage une page, estimation P10/P50/P90	Valeur attendue > 0 avec jalons ; sponsor nommé	Go / no-go
J1 Données	A-t-on de quoi mesurer et apprendre ?	Audit, jeu de test annoté, datasheet (L36)	Kappa ≥ 0,7 ; ≥ n cas ; droits OK	Continuer / re-cadrer / arrêter
J2 Preuve de concept	L’exigence est-elle atteignable ?	Banc d’essai (L32), escalade (L37), ADR (L34)	Borne basse ≥ exigence sur le test scellé	Continuer / palier suivant / arrêter
J3 Pilote	Est-ce utile et utilisé en vrai ?	Système intégré, mesures d’adoption et de KPI	Acceptation ≥ 80 % ; KPI en amélioration ; incidents gérés	Déployer / itérer / arrêter
J4 Production	Est-ce exploitable durablement ?	Monitoring, runbooks, gouvernance (L35, L38)	SLO tenus 4 semaines ; alertes calibrées	Généraliser
J5 Revue	Le KPI est-il atteint ? À quel coût ?	Rapport valeur/coût réel, post-mortem du projet	KPI ≥ cible ; TCO ≤ budget	v2 / maintenance / décommission

# Tableau de bord d'un projet IA : les indicateurs qui prédisent l'issue, mis à jour chaque semaine
tableau = {
 "vélocité d'apprentissage": ("expériences mesurées / semaine", 6, "≥ 5"), "qualité (banc d'essai)": ("macro-F1 borne basse", 0.83, "≥ 0,85 à J2"),
 "données": ("kappa ; cas annotés", "0,78 ; 540/600", "≥ 0,7 ; 600"), "risques ouverts": ("nombre critiques", 1, "0 à J3"),
 "délai": ("P80 restant vs jalon", "9 j vs 12 j", "P80 ≤ jalon"), "budget": ("consommé / total", "58 %", "≤ avancement"),
 "adoption (pilote)": ("taux d'acceptation", "—", "≥ 80 % à J3"), "dette": ("tests automatisés (ML Test Score)", 2, "≥ 3 à J4"),
}
print(f"{'indicateur':28s} {'mesure':34s} {'valeur':16s} {'cible':16s}")
for k, (m, v, c) in tableau.items(): print(f"{k:28s} {m:34s} {str(v):16s} {c:16s}")
print("\nRituels : revue d'expériences (hebdo, 30 min, le banc d'essai à l'écran) ; revue de jalon (décideur présent, critères écrits) ; rétrospective (à chaque jalon) ; revue de production (mensuelle après J4).")

04 / Communiquer et administrer

Communiquer des résultats incertains ; administrer budget, contrats, données, conformité

Communiquer (L24 appliqué)

Un résultat = une métrique, un jeu, un IC, une baseline, une date. « 0,86 [0,83 ; 0,89] de macro-F1 sur 600 tickets de test (baseline règles : 0,62), version v7, 12/09 ».
Démonstrations honnêtes : cas tirés au sort, pas choisis ; montrer aussi les échecs ; jamais de démo sur des exemples du train.
Traduire en métier : « 85 % de tickets bien routés ≈ 1 500 tickets/mois sans intervention, 270 à vérifier, délai −1 jour ».
Dire l’incertitude sans la noyer : P50/P90 pour les délais, IC pour la qualité, scénarios pour la valeur ; ce qu’on saura au prochain jalon.
Annoncer les limites avant qu’on les découvre : dérive, cas non couverts, dépendances.
Gérer les attentes sur l’IA : ni magie ni menace ; un outil qui se trompe X % du temps de façon mesurée, avec un humain qui décide.

Administrer

Budget : jours-personne, calcul (GPU-h avec marge ×3, API avec plafond et alerte), annotation, licences, exploitation (36 mois) ; suivi consommé vs avancement.
Contrats : API (versions figées, données non réutilisées, hébergement, SLA, prix), données (licence, durée, usages), prestataires d’annotation (qualité mesurée, confidentialité).
Données : registre des traitements, base légale, anonymisation, accès, conservation, suppression ; propriétaire nommé.
Conformité : classification AI Act, documentation (L38), revue juridique aux jalons J1 et J4.
Fournisseurs et dépendances : liste, risques, alternatives (L34) ; pas de composant critique sans plan B.
Capitalisation : à chaque jalon, ce qui est réutilisable est versionné et documenté (jeux, banc, composants, ADR) — même si le projet s’arrête.

05 / Portefeuille

Gérer plusieurs systèmes IA : la revue de portefeuille

import numpy as np
# Portefeuille : pour chaque système, valeur annuelle, coût d'exploitation, santé (monitoring), risque, dette → décisions
systemes = [
 ("tri des tickets",         45000,  9000, 0.92, "faible",  1, "maintenir"),
 ("assistant documentation", 30000, 14000, 0.80, "moyen",   3, "réduire la dette (tests, monitoring)"),
 ("détection d'obstacles",  120000, 25000, 0.97, "critique",1, "maintenir ; audit annuel"),
 ("prévision de stock",       8000, 12000, 0.60, "faible",  4, "décommissionner ou re-cadrer"),
 ("OCR factures",            22000,  6000, 0.88, "moyen",   2, "maintenir"),
 ("chatbot RH (pilote)",         0, 18000, 0.70, "moyen",   2, "arrêter le pilote : valeur non démontrée à J3"),
]
print(f"{'système':26s} {'valeur/an':>10s} {'coût/an':>8s} {'net':>8s} {'santé':>6s} {'risque':>9s} {'dette':>6s}  décision")
for n, v, c, s, r, d, dec in systemes: print(f"{n:26s} {v:10d} {c:8d} {v-c:8d} {s:6.2f} {r:>9s} {d:6d}  {dec}")
tot_v = sum(s[1] for s in systemes); tot_c = sum(s[2] for s in systemes); print(f"\nportefeuille : valeur {tot_v} €/an, coût {tot_c} €/an, net {tot_v - tot_c} €/an ; {sum(1 for s in systemes if s[1] < s[2])} systèmes à valeur nette négative")
print("Règles de revue : (1) tout système a un propriétaire et une date de revue ; (2) valeur nette négative deux revues de suite → décommission ou re-cadrage ;")
print("(3) santé < 0,8 → plan de remédiation ; (4) risque critique → audit et supervision humaine documentée ; (5) la dette se rembourse avant les nouvelles fonctionnalités.")

Décommissionner proprement : informer les utilisateurs, retirer le service, archiver modèle + données + documentation (obligations de conservation), supprimer ce qui doit l’être (RGPD), mettre à jour le registre. Un système IA oublié en production est un risque de sécurité et de conformité.

06 / Articles

Les références à lire

Référence	Contribution	À retenir
Ng, Machine Learning Yearning, 2018 (gratuit)	Stratégie d’un projet ML : métrique unique, jeux dev/test, analyse d’erreurs, vélocité d’itération	Le banc d’essai comme boussole ; itérer vite et mesuré
Sculley et al., 2015 ; Sambasivan et al., 2021 (L36) ; Paleyes et al., 2022 (L38)	Dettes, cascades de données, échecs de déploiement	Où va vraiment le temps
Studer et al., CRISP-ML(Q), 2021 (L38)	Phases et AQ	Le cycle ; les jalons s’y calent
Flyvbjerg, What You Should Know About Megaprojects and Why, 2014 ; Flyvbjerg & Gardner, How Big Things Get Done, 2023	Biais d’optimisme, prévision par classe de référence	Estimer à partir de projets comparables (référence externe), pas de l’intérieur
Kahneman & Tversky, Intuitive Prediction: Biases and Corrective Procedures, 1977	Le point de vue extérieur	Proposition 2 en psychologie
McConnell, Software Estimation: Demystifying the Black Art, 2006	Estimation par intervalles, cône d’incertitude	P10/P50/P90 ; s’engager sur P80
Hubbard, How to Measure Anything, 2014	Valeur de l’information, calibration des estimateurs	Mesurer ce qui réduit le plus l’incertitude
Ries, The Lean Startup, 2011 ; Reinertsen, The Principles of Product Development Flow, 2009	Apprentissage validé, coût du délai, files d’attente	Jalons = expériences ; petits lots
Davenport & Ronanki, Artificial Intelligence for the Real World, HBR 2018	Étude de 152 projets : commencer par des cas « augmentation » à faible risque	L’adoption et l’intégration décident
Bughin et al. (McKinsey), The State of AI (annuel) ; Gartner, hype cycle	Taux d’échec et facteurs de succès des projets IA	Données, compétences, adoption, gouvernance
Amershi et al., Software Engineering for Machine Learning: A Case Study, ICSE-SEIP 2019	Comment Microsoft organise ses équipes ML ; niveaux de maturité	Les données comme chemin critique ; expérimentation gérée
NIST AI RMF ; ISO/IEC 42001 ; AI Act (L38)	Gestion des risques et gouvernance	À intégrer aux jalons, pas à la fin

TP guidé

TP — Piloter un projet IA de bout en bout (projet fil rouge, 4 semaines)

Cadrage. Une page (modèle 01) pour un cas réel, avec critères de succès et de sortie, revu par une personne extérieure qui doit pouvoir dire « non » à J0.
Estimation. Tâches en P10/P50/P90, simulation Monte-Carlo (code de la partie 02), P80 communiqué ; identification des deux tâches qui dominent l’incertitude et action pour la réduire (audit de données, prototype d’intégration).
J1–J2. Audit des données, jeu de test annoté, banc d’essai (L32), escalade (L37), ADR (L34) ; revue de jalon avec décideur, critères appliqués — y compris si cela mène à l’arrêt.
J3. Pilote avec de vrais utilisateurs (même 3) ; mesure d’adoption et retours ; une itération.
Tableau de bord et rituels. Indicateurs de la partie 03 mis à jour chaque semaine ; compte rendu de 10 lignes au sponsor avec incertitudes.
Clôture. Rapport J5 (valeur/coût réels vs estimés, écarts expliqués), post-mortem du projet, capitalisation (jeu, banc, composants, ADR versionnés), et — si le projet s’est arrêté — ce qui a été appris et ce qui est réutilisable.

Exercices

Exercices auto-corrigés

Exercice 1 — PERT et simulation

Écrivez pert(p10, p50, p90) → (moyenne, écart-type) et simuler_total(taches, n, rho, rng) : somme de durées log-normales calibrées sur (P10, P50, P90), avec un facteur commun de corrélation rho (z = √ρ·z_commun + √(1−ρ)·z_propre). Vérifiez que la médiane simulée dépasse la somme des P50 (Proposition 2) et que la corrélation élargit P90.

Correction

def pert(p10, p50, p90): return (p10 + 4 * p50 + p90) / 6, (p90 - p10) / 2.56
def simuler_total(taches, n=20000, rho=0.3, rng=None):
    rng = rng or np.random.default_rng(0); zc = rng.normal(0, 1, n); tot = np.zeros(n)
    for p10, p50, p90 in taches:
        z = np.sqrt(rho) * zc + np.sqrt(1 - rho) * rng.normal(0, 1, n); mu = np.log(p50); sig = (np.log(p90) - np.log(p10)) / 2.56; tot += np.exp(mu + sig * z)
    return tot

Exercice 2 — Coût attendu avec jalons et seuil d’arrêt

Écrivez cout_attendu(phases) (phases = liste de (coût, p_succès)) selon la Proposition 1, p_min_continuer(R, V) = R/V, et decider(p, R, V) → "continuer"/"arrêter".

Correction

def cout_attendu(phases):
    total, proba = 0.0, 1.0
    for c, p in phases: total += proba * c; proba *= p
    return total
def p_min_continuer(R, V): return R / V
def decider(p, R, V): return "continuer" if p * V - R > 0 else "arrêter"

Exercices

Exercices auto-corrigés (suite)

Exercice 3 — Adoption vs qualité (Proposition 3)

Écrivez benefice(B0, q, u) et meilleur_investissement(B0, q, u, dq, du) qui renvoie "qualité" si augmenter q de dq rapporte plus qu’augmenter u de du, sinon "adoption". Vérifiez le seuil q > u.

Correction

def benefice(B0, q, u): return B0 * q * u
def meilleur_investissement(B0, q, u, dq, du):
    return "qualité" if benefice(B0, q + dq, u) - benefice(B0, q, u) > benefice(B0, q, u + du) - benefice(B0, q, u) else "adoption"

Exercice 4 — Revue de portefeuille

Écrivez decisions_portefeuille(systemes) : liste de dicts {nom, valeur, cout, sante, risque, dette, revues_negatives} → dict nom → décision selon les règles : valeur − coût < 0 et revues_negatives ≥ 2 → "décommissionner" ; sinon santé < 0,8 → "remédier" ; sinon risque == "critique" → "auditer" ; sinon dette ≥ 3 → "réduire la dette" ; sinon "maintenir".

Correction

def decisions_portefeuille(systemes):
    out = {}
    for s in systemes:
        if s["valeur"] - s["cout"] < 0 and s["revues_negatives"] >= 2: out[s["nom"]] = "décommissionner"
        elif s["sante"] < 0.8: out[s["nom"]] = "remédier"
        elif s["risque"] == "critique": out[s["nom"]] = "auditer"
        elif s["dette"] >= 3: out[s["nom"]] = "réduire la dette"
        else: out[s["nom"]] = "maintenir"
    return out

Fiche de cours · Exercices corrigés

Exercices corrigés (rédaction)

Exercice 1. Un sponsor demande « quand le modèle sera-t-il prêt ? » après le cadrage. Rédiger la réponse en cinq phrases.

Correction. « Nous avons dix tâches estimées par intervalles ; la simulation donne une médiane de 52 jours ouvrés et 80 % de chances de finir sous 68 jours — je m’engage sur 68. L’incertitude vient surtout de l’accès aux données et de l’intégration, pas de la modélisation : nous faisons un audit de deux jours cette semaine pour la réduire. Le premier jalon, dans trois semaines, dira si les étiquettes historiques sont utilisables ; s’il échoue, nous re-cadrons les catégories avant d’aller plus loin — c’est prévu et ce n’est pas un échec. Vous aurez chaque semaine un compte rendu de dix lignes avec la qualité mesurée, le délai P80 restant et le budget consommé. Et pour être clair : “prêt” signifie 85 % de tickets bien routés mesurés sur 600 cas tenus à l’écart, validé par les techniciens pendant quatre semaines — pas une démo. »

Exercice 2. À J2, après les paliers 1 à 5, le banc plafonne à 0,74 [0,71 ; 0,77] pour une exigence de 0,85. Reste à payer : 32 k€ ; valeur si succès : 90 k€. Rédiger la recommandation.

Correction. Seuil de poursuite p > R/V = 0,36 (Proposition 4). Après cinq paliers, la probabilité d’atteindre 0,85 avec les paliers 6–7 est faible (estimation honnête : 0,15–0,25, car l’analyse d’erreurs montre des tickets intrinsèquement ambigus et un kappa de 0,72 qui plafonne la mesure — L36, Théorème 4) : continuer vaut ≈ 0,2 × 90 − 32 < 0 → arrêter le projet tel que cadré. Mais re-cadrer est possible : (a) exigence à 0,75 avec routage assisté (le technicien valide en un clic : valeur estimée 60 % de l’initiale, coût restant 15 k€, p ≈ 0,8 → 0,8 × 54 − 15 > 0) ; (b) fusion de 3 catégories ambiguës, à négocier avec le métier ; (c) ré-annotation du test pour lever le plafond de mesure. Recommandation : arrêter le projet initial (décision documentée), proposer (a) + (c) comme nouveau cadrage d’une page, capitaliser le jeu de données, le banc et l’ADR. Les 43 k€ déjà dépensés n’entrent pas dans le calcul.

Exercice 3. Le pilote J3 montre une qualité conforme (0,87) mais un taux d’acceptation de 40 % : les techniciens contournent l’outil. Analyser et proposer.

Correction. Proposition 3 : à q = 0,87 et u = 0,4, le bénéfice est 35 % du potentiel ; chaque point d’usage vaut 2× un point de qualité. Causes typiques, à établir par entretiens et télémétrie : l’outil est hors du flux de travail (un onglet de plus), les erreurs ne sont pas expliquées (une suggestion fausse sans confiance affichée détruit la confiance), le seuil de refus est mal placé (trop de « à trier manuellement » ou pas assez), le temps de validation dépasse le temps de tri manuel, absence de formation, crainte pour le poste. Actions : intégrer dans l’outil de ticketing existant ; afficher la confiance et les deux catégories alternatives ; un clic pour corriger (et la correction alimente le jeu d’entraînement — boucle de retour, L35) ; régler le seuil sur le coût réel des erreurs avec les techniciens ; mesurer l’usage par personne et discuter, pas imposer ; communiquer le sens (moins de tri, pas moins de postes). Re-mesurer après 2 semaines ; critère J3 inchangé (≥ 80 %) — s’il n’est pas atteint, le projet n’est pas prêt pour la production, quelle que soit la qualité du modèle.

Vérification

Un projet a déjà coûté 60 k€ ; il en reste 30 k€ à dépenser pour une valeur de 90 k€ en cas de succès, avec une probabilité estimée à 0,25. Que faire ?

Deux questions supplémentaires

1. Pourquoi additionner des P50 donne-t-il un planning intenable ? Les durées sont asymétriques : la médiane de la somme dépasse la somme des médianes (Proposition 2) ; simuler et s’engager sur P80.

2. Pourquoi mesurer l’adoption dès le pilote ? Le bénéfice est multiplicatif en qualité et usage ; au-delà d’une qualité correcte, l’usage domine (Proposition 3).

Référence

Les mots à retenir

Mot	Définition
Cadrage	Problème, valeur, exigences, faisabilité, risques, jalons, critères de succès et de sortie.
Jalon de décision	Livrable, critère, date, décideur ; peut arrêter le projet.
P10/P50/P90, P80	Estimation par intervalles ; simulation ; engagement à P80.
Coût attendu avec jalons	c₁ + p₁c₂ + p₁p₂c₃ + … ; options réelles.
Seuil d’arrêt	Continuer ssi p > R/V ; coûts engagés exclus.
Adoption	Bénéfice = B₀ × q × u ; mesurer l’usage.
Portefeuille	Propriétaire, valeur, coût, santé, risque, dette, revue, décommission.
Capitalisation	Jeux, bancs, composants, ADR, post-mortems — ce qui survit au projet.

Fin de la partie K

Vous savez construire, mesurer, choisir, maintenir, gouverner et piloter un système d’IA.

Quinze chapitres : le Transformer démonté, le RAG mesuré, les LLM alignés, les prompts testés, l’OCR et l’ASR de bout en bout, les familles de réseaux et leurs biais, quarante métriques, les infrastructures et leurs coûts, le choix et la maintenance des modèles, les données, l’escalade avant le from scratch, CRISP-ML(Q)/MLOps/AIOps, et le pilotage. Chaque chapitre a ses articles : lisez-les en trois passes (L24), reproduisez-en un (L24), et rendez votre travail mesurable — c’est la seule chose qui distingue l’ingénierie de l’IA de la magie.

Pour continuer

Refaire le projet fil rouge de L39 sur un cas réel, avec tous les livrables des chapitres L32–L38.
Contribuer à un projet libre (vLLM, PaddleOCR, faster-whisper, Evidently, DVC) : une correction de bug mesurée vaut un mois de cours.
Suivre une conférence par an (NeurIPS, ICML, ICLR, ACL, ICRA ; MLSys pour les systèmes) et rédiger vos fiches d’articles.
Une question ? La pastille WhatsApp reste là.

← L38 Sommaire Lycée → Prépa Revenir au début de la partie K