Vous demandez à votre équipe data de « faire du machine learning » et trois mois plus tard, vous avez une maquette Streamlit qui tourne sur le laptop d'un stagiaire et zéro ligne en production. J'ai vu cette scène au moins cinq fois dans des boîtes différentes. J'ai aussi vu l'inverse : un modèle qui a fait gagner 340 000 euros par an à une ETI de logistique dont personne ne parle, parce qu'il n'y a rien de sexy à optimiser du remplissage de camions.
L'écart entre ces deux mondes ne tient presque jamais à l'algorithme. Il tient à des décisions qu'on prend (ou qu'on ne prend pas) avant d'écrire la première ligne de code. Voici ce que j'ai appris en accompagnant des déploiements d'apprentissage automatique dans des contextes où le budget n'est pas illimité et où le comité de direction pose des questions désagréables.
Points clés à retenir
- Un projet ML en entreprise échoue rarement pour des raisons algorithmiques : la donnée, le cadrage métier et la maintenance tuent plus de projets que les modèles.
- L'apprentissage supervisé couvre l'immense majorité des cas utiles en entreprise (prédiction, scoring, classification), bien avant le deep learning.
- Le coût réel d'un modèle n'est pas son entraînement, mais son maintien en conditions de production sur 12 à 24 mois.
- Un modèle sans propriétaire métier identifié devient une dette technique en moins d'un an.
- La conformité RGPD et la gestion des biais ne sont pas des cases à cocher en fin de projet : elles se décident au moment de la collecte.
L'apprentissage automatique en entreprise : ce que les cas concrets ont en commun
Il faut d'abord clarifier une confusion que je rencontre sans arrêt en réunion. Beaucoup de dirigeants emploient « IA », « machine learning » et « automatisation » comme synonymes. Ce n'est pas la même chose, et le mélange coûte cher.
Qu'est-ce que le Machine Learning, en une définition qui tient en réunion ?
Le machine learning, c'est un programme qui n'exécute pas des règles écrites à la main, mais qui infère ces règles à partir d'exemples. Vous ne dites pas à la machine « si le client n'a pas commandé depuis 90 jours, il est à risque ». Vous lui donnez 200 000 lignes d'historique avec une étiquette « a churné / n'a pas churné » et elle trouve elle-même les combinaisons de variables qui prédisent le mieux.
L'automatisation classique, elle, suit des règles fixes. Et l'IA générative produit du texte ou des images. Ces trois familles répondent à des problèmes différents. Confondre les deux premières est l'erreur de cadrage la plus fréquente que je vois.
Franchement, dans 80 % des cas métier que j'ai traités, la bonne réponse était de l'apprentissage supervisé classique, pas un réseau de neurones profond. Oui, ça vexe parfois les data scientists qui veulent jouer avec des transformers.
Pourquoi l'apprentissage supervisé reste le cœur des usages en entreprise
L'apprentissage supervisé, c'est simple à expliquer et redoutablement efficace : vous avez des exemples étiquetés, vous voulez prédire l'étiquette d'un nouvel exemple. Un score de risque, une probabilité de conversion, une classification de tickets, une estimation de délai de livraison. Tout cela vit très bien avec une régression logistique ou un gradient boosting, deux familles d'algorithmes qui tournent sur un serveur modeste et qu'on peut expliquer à un auditeur.
L'apprentissage non supervisé (clustering, détection d'anomalies) sert surtout à explorer la donnée avant de formuler une hypothèse. Et le deep learning brille quand la donnée d'entrée est non structurée : image, son, texte brut. Si votre problème se résume à un tableau de 40 colonnes et 500 000 lignes, un réseau profond est un marteau-pilon pour écraser une mouche, avec en prime un coût d'explication qui vous coûtera cher en comité.
Le point que je martèle : choisissez la famille d'algorithme après avoir écrit la question métier au tableau, jamais l'inverse. J'ai vu une équipe passer six semaines sur une architecture à base de transformers pour un problème qu'une régression logistique réglait à 91 % de précision en deux jours. Six semaines. Pour rien.
Trois cas concrets, chiffres à l'appui
Passons aux choses sérieuses. Voici des déploiements réels, décrits tels que je les ai vécus, dans des secteurs où vous ne verrez probablement jamais d'article LinkedIn.
Logistique : prédire le remplissage des camions
Une PME de transport routier, 180 salariés, gérait ses tournées avec l'expérience d'un dispatcheur de 25 ans de métier et un tableur Excel de 4 000 lignes. Nous avons construit un modèle de régression qui estime le volume et le poids réels d'une commande à partir de l'historique client, du type de produit et de la saisonnalité. Gain mesuré sur quatre mois : le taux de remplissage moyen est passé de 72 % à 84 %, soit l'équivalent de 11 camions en moins par mois. La personne qui a le plus défendu le projet en interne ? Le dispatcheur lui-même, une fois qu'il a compris que le modèle ne le remplaçait pas mais lui évitait les mauvaises surprises le matin.
Notez bien : aucun réseau de neurones. Un gradient boosting tout ce qu'il y a de plus banal, avec un travail énorme sur la qualité des données en amont.
Assurance : détecter les dossiers à risque de fraude
Chez un courtier, l'objectif était de trier automatiquement les dossiers sinistres pour orienter les vérifications manuelles. Problème : sur 100 dossiers, seuls 3 posaient réellement problème. Un modèle naïf qui dit « pas de fraude » partout atteint 97 % d'exactitude et ne sert à rien. Là, la vraie difficulté n'est pas l'algorithme, c'est la définition de la métrique : on voulait maximiser le rappel sur la classe minoritaire, quitte à générer des faux positifs que l'enquêteur écarterait en deux minutes. Résultat : les enquêteurs ont concentré leur temps sur 12 % des dossiers et ont détecté deux fois plus de cas avérés par trimestre. Le coût du projet a été absorbé en cinq mois.
Industrie : maintenance prédictive, la désillusion
Ici, j'avoue un échec. Un site industriel voulait prédire les pannes d'une ligne de production. Techniquement, le modèle tenait debout sur les données historiques. En production, il s'est effondré en trois semaines. Raison : la ligne avait été révisée entre-temps, les capteurs recalibrés, et le régime de production changé. Le modèle apprenait un monde qui n'existait plus. Nous avons sous-estimé la dérive des données (data drift). Leçon : sans surveillance continue et procédure de réentraînement, un modèle de maintenance prédictive est une bombe à retardement. Ce projet a été arrêté, puis relancé six mois plus tard avec une brique de suivi dès le premier jour.
Le cycle de vie réel d'un projet ML en entreprise
La phase qui consomme le plus de temps n'est pas celle que le grand public imagine. Le nettoyage et la préparation de la donnée représentent, dans mon expérience, entre 60 et 70 % de l'effort total. Ensuite seulement viennent l'entraînement puis le déploiement, qui posent à leur tour des questions que personne n'avait anticipées.
- Collecte et qualité : d'où vient la donnée, qui la possède, est-elle à jour ?
- Cadrage de la métrique métier, pas la métrique statistique.
- Entraînement et validation, avec un jeu de test jamais touché avant la fin.
- Mise en production (API, batch nocturne, intégration dans l'outil existant).
- Surveillance de la dérive et réentraînement planifié.
- Gouvernance : qui décide qu'on déploie, qui répond si le modèle se trompe ?
Ce que coûte vraiment un modèle une fois en ligne
Le chiffre qui surprend tout le monde : maintenir un modèle en production sur 24 mois coûte souvent autant ou plus que de le construire. Ingénierie, monitoring, gestion des versions, astreinte en cas de panne silencieuse. Beaucoup d'entreprises financent la construction et découvrent la facture de maintenance en année deux, quand l'équipe qui a fait le modèle est partie voir ailleurs.
RGPD, biais algorithmiques : ce qu'on ne peut plus ignorer
En Europe, un modèle qui prend des décisions sur des personnes (crédit, recrutement, tarification) tombe dans le champ de la réglementation sur les décisions automatisées. Concrètement, cela signifie qu'il faut pouvoir expliquer pourquoi le modèle a dit non, et prévoir un recours humain. Le biais algorithmique n'est pas un problème théorique : si votre historique de recrutement est biaisé, le modèle apprendra ce biais et le reproduira à grande échelle. J'ai vu un modèle de scoring candidat pénaliser systématiquement les profils issus de certaines filières, pour la simple raison que le passé de l'entreprise les avait sous-représentés. Ça se corrige, mais seulement si on le cherche.
Quand le ML est pertinent, et quand il ne l'est pas
| Situation | Approche adaptée | Pourquoi |
|---|---|---|
| Règles stables et auditables (calcul de TVA, seuils de conformité) | Automatisation classique | Une règle fixe est plus fiable et explicable qu'un modèle |
| Prédire une valeur ou une classe à partir d'un historique | Apprentissage supervisé | C'est exactement le cas d'usage du ML |
| Analyser des images, du son, du texte brut | Deep learning | La donnée non structurée exige des réseaux profonds |
| Générer du contenu rédactionnel | IA générative | Ce n'est pas du ML prédictif |
| Explorer un jeu de données sans hypothèse | Apprentissage non supervisé | Sert à formuler des hypothèses, pas à décider |
Le vrai signal d'alerte, c'est quand quelqu'un veut « faire de l'IA » sans avoir formulé la décision métier que le modèle est censé améliorer. Si vous ne savez pas ce que vous ferez différemment selon que le modèle prédit A ou B, vous n'avez pas de projet.
Les erreurs que je vois le plus souvent
Elles se répètent avec une régularité déprimante, quel que soit le secteur.
- Lancer un projet sans sponsor métier identifié, et se retrouver sans décideur au moment du déploiement.
- Négliger la qualité de la donnée et croire qu'on la « nettoiera plus tard ».
- Choisir l'algorithme avant d'avoir défini la question.
- Ignorer le coût de la maintenance et de la surveillance.
- Traiter la conformité RGPD en fin de projet, quand tout est à refaire.
- Vouloir tout de suite du deep learning parce que c'est plus valorisant en interne.
La cinquième est celle qui coûte le plus cher, et pas seulement en euros. Reprendre une architecture de collecte de données après coup, quand les consentements n'ont pas été tracés, revient à tout recommencer. J'ai vu une équipe perdre quatre mois là-dessus.
Par où commencer concrètement
Ma recommandation, et là je serai direct : commencez petit, sur un problème à fort volume de décisions et faible enjeu réglementaire. Un modèle qui classe 50 000 lignes par jour dans un entrepôt, ou qui estime un délai de livraison. Pas un système de scoring de crédit pour votre premier projet.
Construisez la brique de suivi dès le premier jour, même si elle paraît inutile sur votre premier jeu de test. C'est elle qui vous sauvera dans six mois, quand la réalité aura bougé et que votre modèle, lui, sera resté figé sur un monde disparu.
Et surtout : mesurez l'écart entre ce que le modèle apporte et ce que coûte son maintien. Tant que ce ratio reste favorable, vous avez le droit de continuer. Le jour où il s'inverse sans que personne ne s'en aperçoive, vous n'avez plus un modèle en production — vous avez une dette technique qui prend des décisions à votre place.
