Un projet d’IA est d’abord un projet de données. La formule est simple ; ses conséquences le sont moins. Quand un modèle n’arrive pas en production, ou y arrive sans être utilisé, la cause se trouve rarement dans l’algorithme. Elle se trouve dans ce qui l’entoure : les données qui l’alimentent, la question qu’on lui pose, l’endroit où sa réponse est livrée et la manière dont il est suivi une fois en service.
Quatre causes d’échec
1. Des données dispersées et des définitions qui varient
Les projets butent sur des données réparties entre plusieurs systèmes, des définitions qui changent d’un service à l’autre et des référentiels dont personne n’est responsable. Un modèle entraîné sur des données dont la définition n’est pas stabilisée apprend des incohérences, pas des comportements.
2. Des populations qui n’ont pas été séparées
Toutes les lignes d’une table de faits ne se valent pas. Avoirs, retours, règlements partiels, écritures non affectées, dates incohérentes, cas extrêmes : si ces populations ne sont pas identifiées et exclues par des règles justifiées et tracées, elles brouillent l’apprentissage. Cette étape de préparation est celle qui pèse le plus sur le résultat, et celle que la plupart des projets sous-estiment.
3. Un livrable qui reste un notebook
Un modèle qui vit dans un environnement de data science, à côté du système d’information, n’est pas utilisé. Pour qu’une prédiction serve une décision, elle doit devenir une table de faits intégrée au modèle de données, affichée dans le tableau de bord que les équipes ouvrent déjà, à côté de l’indicateur réel.
4. Un modèle que personne ne mesure ni ne supervise
Un modèle qui n’est ni mesuré ni supervisé se dégrade en silence : les données changent, les comportements aussi, et la prédiction s’éloigne du réel sans que personne ne s’en aperçoive. Traçabilité des entraînements, évaluation continue, infrastructure durcie et supervisée font partie du projet, pas d’une phase ultérieure.
Comment nous les évitons
Notre méthode pour un projet prédictif tient en quatre étapes, chacune avec un livrable vérifiable : préparation des données (jeux d’entraînement et de test documentés), modélisation (comparatif chiffré, modèle retenu et ses limites), prédictions (table de prédictions intégrée au data warehouse) et restitution (dashboard opérationnel et écarts documentés). Elle s’inscrit dans l’approche DataReady qui cadre l’ensemble de la mission.
L’engagement se décide étape par étape : un cadrage de cas d’usage de deux à trois semaines, qui aboutit à une note de cadrage et à une décision motivée de lancer — ou non — une preuve de concept ; une preuve de concept de six à dix semaines au forfait, qui livre un modèle mesuré et un tableau de bord opérationnel ; puis l’industrialisation et le run. Personne n’a à s’engager sur un programme complet pour commencer.
Deux illustrations
Chez un équipementier industriel international, le taux de livraison à l’heure n’était mesuré qu’a posteriori. Sept années de commandes accumulées dans le datamart Opérations ont permis d’entraîner un modèle prédictif, à condition de définir avec le métier des règles d’exclusion justifiées et tracées, et de construire des variables explicatives à partir de l’historique. La prédiction a été intégrée au modèle en étoile existant et restituée dans le tableau de bord déjà utilisé, à côté de l’indicateur réel. Lire le cas client
Dans la direction financière d’un groupe industriel, la trésorerie prévisionnelle reposait sur des échéances théoriques que les clients ne respectent pas. La table de faits a été scindée en factures réglées et factures ouvertes, les règlements partiels, avoirs et écritures non affectées ont été exclus, et le modèle a appris pour chaque compte l’écart habituel entre échéance et règlement. La prévision est arrivée sous la forme d’une colonne « paiement prédit » dans le rapport des comptes clients existant. Les limites du modèle ont été livrées en même temps que ses résultats. Lire le cas client
Commencer sans attendre une refonte
Vous n’avez pas besoin d’un socle moderne pour commencer. Nos modèles se construisent sur les données et les outils que vous avez aujourd’hui. La méthode ne présume ni du moteur de calcul, ni du mode de stockage : si votre architecture évolue demain, les modèles restent valables — seule change la manière dont ils sont exécutés et alimentés. Un projet IA n’a donc pas à devenir le prétexte d’une refonte technique, ni à attendre qu’elle soit terminée pour produire de la valeur.
Pour aller plus loin : la page Intelligence Artificielle & Automatisation décrit la méthode, les domaines d’intervention et les formats ; le Diagnostic Data & IA permet d’objectiver la maturité de vos données avant un premier projet.
Les résultats chiffrés correspondent à des réalisations mesurées sur les périmètres et jeux de données décrits ; ils ne constituent pas un engagement de performance sur un autre périmètre. Les offres signalées comme « à cadrer » décrivent une approche proposée et non une réalisation existante.