Module 8 — Le cycle de vie d'un projet d'IA
L'image publique d'un projet d'IA, c'est la modélisation : un expert devant des courbes d'apprentissage. La réalité d'un projet qui aboutit ressemble à autre chose : l'essentiel de l'effort se joue avant et après le modèle. Ce module parcourt les sept étapes, avec les seuils de décision qui évitent de s'enliser.
La répartition réelle de l'effort
Les enquêtes de terrain convergent depuis des années : la modélisation représente 10 à 20 % du temps d'un projet abouti. Le reste : comprendre le problème, obtenir et nettoyer les données, construire l'infrastructure, déployer, surveiller. Un plan de projet qui alloue l'essentiel du temps au choix d'algorithme est un signal d'alarme en soi.
Étape 1 — Le cadrage : la décision avant le modèle
Un projet se cadre en quatre questions, dans cet ordre.
Quelle décision le système va-t-il éclairer ou automatiser ? « Prédire le churn » n'est pas une fin ; « appeler chaque semaine les 50 clients les plus à risque » en est une. Sans décision en aval, la meilleure prédiction ne produit aucune valeur.
Que vaut une amélioration ? Chiffrer l'écart entre la situation actuelle et une situation où la prédiction serait, disons, 20 % meilleure. Si ce chiffre est faible, arrêter là — le projet le plus rentable est parfois celui qu'on ne fait pas.
Quel est le coût de chaque type d'erreur ? Ce chiffrage (module 7) conditionne les métriques, le seuil, et le niveau de supervision humaine requis.
Existe-t-il une solution simple ? Une règle métier, un tri, une moyenne glissante règlent une part étonnante des demandes « IA ». Cette question vexe et fait économiser des trimestres.
Étape 2 — Les données : l'inventaire honnête
Trois vérifications avant toute modélisation. La disponibilité : les données existent-elles, sur une profondeur d'historique suffisante, avec les étiquettes nécessaires ? La légalité : a-t-on le droit de les utiliser pour cet usage (consentement, finalité, données personnelles) ? La représentativité : couvrent-elles les cas que le système rencontrera — ou seulement un sous-ensemble commode ?
Puis le nettoyage : doublons, valeurs manquantes, incohérences d'unités, étiquettes contradictoires. C'est ingrat et c'est déterminant : aucun algorithme ne rattrape des données fausses.
Étape 3 — La référence : le modèle le plus simple possible
Avant tout modèle ambitieux, construire une référence (baseline) : la règle triviale (classe majoritaire, valeur d'hier), puis un modèle simple (régression logistique, petit arbre). Trois services rendus : un point de comparaison qui donne un sens aux chiffres, une validation de bout en bout du pipeline de données, et — régulièrement — la découverte que la référence suffit au besoin.
Étape 4 — L'itération : améliorer ce qui limite
Le travail de modélisation proprement dit, mené en boucles courtes : analyser où le modèle se trompe (quels segments, quels types de cas), formuler une hypothèse (variable manquante, données insuffisantes sur un segment, modèle trop simple), la tester, mesurer sur le jeu de validation. L'analyse d'erreurs est la boussole ; l'empilement de complexité sans diagnostic est la dérive classique.
S'arrêter quand l'amélioration marginale ne paie plus l'effort — le seuil a été fixé au cadrage, ce qui évite la quête sans fin du point de performance supplémentaire.
Étape 5 — L'évaluation finale : une seule fois
Mesure sur le jeu de test (module 5), complétée de vérifications que la métrique globale ne montre pas : performance par segment (le modèle est-il bon partout, ou excellent en moyenne et défaillant sur un groupe ?), comportement sur les cas limites, robustesse aux entrées dégradées. C'est ici que se joue l'équité du système autant que sa qualité.
Étape 6 — Le déploiement : progressif, réversible
Un modèle en production est un logiciel : versionné, testé, supervisé, avec un plan de retour arrière. Le déploiement progressif est la norme : mode fantôme (le modèle prédit sans agir, on compare à l'existant), puis fraction du trafic, puis généralisation si les indicateurs tiennent. Le passage du notebook au service fiable — reproductibilité, latence, montée en charge — est un métier en soi : c'est le MLOps, auquel un cours du parcours est consacré.
Étape 7 — La surveillance : le modèle vieillit
Un modèle se dégrade sans qu'on le touche, parce que le monde bouge : comportements, prix, produits, fraudes évoluent. C'est la dérive (drift). On surveille trois familles de signaux : la distribution des entrées (les données d'aujourd'hui ressemblent-elles à celles de l'entraînement ?), la distribution des prédictions, et — dès que les vraies réponses arrivent — la performance réelle. Des seuils déclenchent alerte, puis réentraînement : le cycle reboucle sur l'étape 2.
« Comment saurons-nous, dans six mois, que le modèle s'est dégradé — et que se passera-t-il alors ? » Si le plan ne répond pas à cette question, le projet n'est pas prêt pour la production, quelle que soit la qualité du modèle aujourd'hui.
Ce qu'il faut retenir
- La modélisation pèse 10–20 % de l'effort ; les données et l'après-déploiement font le reste.
- Cadrage en quatre questions : quelle décision, quelle valeur, quels coûts d'erreur, existe-t-il une solution simple.
- Toujours une référence triviale avant le modèle ambitieux ; elle donne l'échelle et valide le pipeline.
- Déploiement progressif et réversible ; surveillance de la dérive avec seuils et plan de réentraînement — un modèle non surveillé est un modèle qui se dégrade en silence.
Au module suivant : ce que les réussites documentées et les échecs célèbres enseignent — les schémas qui se répètent des deux côtés.