Le machine learning, ou apprentissage automatique, est la branche de l'intelligence artificielle qui permet à un système d'améliorer ses performances sur une tâche à partir de l'expérience — les données — sans qu'un programmeur ne code explicitement chaque règle. Au lieu d'écrire « si le montant dépasse X et que le pays est Y, marquer comme suspect », on entraîne un modèle avec des milliers de transactions étiquetées et l'algorithme découvre de lui-même les motifs. Cet article laisse de côté la promesse abstraite pour descendre sur le terrain : quels types de problèmes le machine learning résout-il réellement dans une entreprise, comment mesure-t-on la qualité d'un modèle, qu'exige la réglementation européenne et où la plupart des projets trébuchent-ils ?
Les trois paradigmes de l'apprentissage automatique
Presque tout problème métier s'inscrit dans l'un de trois paradigmes. L'apprentissage supervisé travaille avec des données étiquetées — des exemples dont on connaît déjà la bonne réponse — et se subdivise en deux familles : la régression, qui prédit une valeur numérique continue (le prix d'un logement, la demande du prochain trimestre), et la classification, qui attribue une catégorie discrète (client qui partira ou non, courrier légitime ou spam).
L'apprentissage non supervisé opère sans étiquettes : il cherche une structure cachée dans les données. Sa technique phare est le clustering ou regroupement, qui segmente les clients en profils affinitaires sans que personne n'ait défini ces profils au préalable. L'apprentissage par renforcement, enfin, entraîne un agent qui apprend par essais et erreurs en maximisant une récompense ; c'est le paradigme de l'optimisation des itinéraires logistiques ou de la gestion dynamique des prix.
Le cycle de vie d'un projet de machine learning
Un modèle ne surgit pas de nulle part : il est le fruit d'un processus discipliné. La méthodologie de référence dans l'industrie reste CRISP-DM, avec ses six phases : compréhension du métier, compréhension des données, préparation des données, modélisation, évaluation et déploiement. La règle que toute équipe chevronnée confirme est que la phase de préparation des données — nettoyage, traitement des valeurs manquantes, normalisation, ingénierie des caractéristiques — consomme habituellement la plus grande partie de l'effort du projet, bien au-delà de l'entraînement du modèle lui-même.
Pour entraîner et valider correctement, les données sont réparties en trois ensembles : entraînement (avec lequel le modèle apprend), validation (avec lequel on ajuste les hyperparamètres) et test (avec lequel on mesure la performance finale sur des données jamais vues). Faire l'impasse sur cette séparation est le chemin le plus court pour se tromper soi-même.
Le déploiement, par ailleurs, n'est pas la fin du projet mais le début de sa phase la plus longue. La discipline connue sous le nom de MLOps applique au cycle de vie du modèle les mêmes idées que DevOps apporte au logiciel : versionnage des données et des modèles, automatisation du réentraînement, surveillance continue de la performance en production et reproductibilité de chaque expérience. Un modèle qui est entraîné une fois puis abandonné se dégrade inévitablement à mesure que la réalité qu'il prédit change ; un modèle gouverné par MLOps détecte cette dégradation tôt, se réentraîne avec des données fraîches et conserve la traçabilité nécessaire pour auditer quelle version a pris chaque décision, une exigence que l'AI Act lui-même impose aux systèmes à haut risque.
Comment mesurer un modèle : au-delà de l'exactitude
La métrique la plus intuitive, l'exactitude (accuracy), est trompeuse lorsque les classes sont déséquilibrées. Si seulement 1 % des transactions sont frauduleuses, un modèle qui dit « aucune n'est une fraude » a raison 99 % du temps et est totalement inutile. C'est pourquoi on utilise des métriques plus fines :
| Métrique | Ce qu'elle mesure | Quand l'utiliser |
|---|---|---|
| Précision (precision) | De ce que j'ai prédit positif, combien était juste | Lorsqu'un faux positif coûte cher |
| Rappel (recall) | De tous les positifs réels, combien j'ai détectés | Lorsqu'un faux négatif coûte cher (fraude, diagnostic) |
| F1-score | Équilibre entre précision et rappel | Classes déséquilibrées |
| RMSE / MAE | Erreur moyenne de la prédiction numérique | Problèmes de régression |
| AUC-ROC | Capacité à discriminer entre classes | Classification binaire, comparaison de modèles |
Un autre concept central est l'équilibre entre surapprentissage (overfitting) et sous-apprentissage (underfitting). Un modèle en surapprentissage mémorise le bruit de l'ensemble d'entraînement et échoue sur des données nouvelles ; un modèle en sous-apprentissage est trop simple pour capturer le motif. La validation croisée et la régularisation sont les outils qui maintiennent le modèle au point juste.
Applications concrètes par domaine d'activité
- Prédiction du désabonnement (churn) : classification supervisée qui identifie les clients à forte probabilité de départ pour activer la rétention avant de les perdre.
- Détection de fraude : combine classification supervisée et détection d'anomalies ; la métrique qui importe est le rappel, car laisser passer une fraude coûte plus cher que d'examiner une fausse alerte.
- Prévision de la demande : régression sur des séries temporelles qui ajuste les stocks et réduit le capital immobilisé et les ruptures de stock.
- Maintenance prédictive : avec des données de capteurs IoT, anticipe la panne d'une machine avant qu'elle ne provoque l'arrêt.
- Segmentation de la clientèle : clustering non supervisé qui découvre des profils de comportement pour personnaliser les campagnes.
- Systèmes de recommandation : filtrage collaboratif qui suggère des produits pertinents et augmente la valeur moyenne du panier.
Le fil conducteur de toutes ces applications est que le modèle ne remplace pas la décision humaine, mais l'éclaire d'une probabilité fondée. L'équipe antifraude continue d'examiner les alertes ; le responsable des achats continue d'approuver la commande que suggère la prévision de la demande. La valeur du machine learning réside dans le fait de prioriser l'attention humaine vers ce qui compte le plus, non de l'éliminer, et les projets qui le comprennent dès le départ intègrent l'utilisateur métier dans la conception au lieu de lui imposer une boîte fermée qu'il ne comprend pas et à laquelle il ne fait pas confiance.
Réglementation : l'AI Act et le RGPD appliqués au machine learning
Tout projet de machine learning portant sur des données de personnes au sein de l'UE opère sous deux cadres. Le Règlement général sur la protection des données (RGPD) exige une base légale pour traiter les données, une limitation de la finalité et, à son article 22, accorde au citoyen le droit de ne pas faire l'objet de décisions fondées uniquement sur un traitement automatisé lorsqu'elles produisent des effets juridiques ou significatifs ; cela oblige à prévoir une supervision humaine et une information claire.
Le Règlement sur l'intelligence artificielle (AI Act, Règlement UE 2024/1689), déjà en vigueur avec une application échelonnée, classe les systèmes par niveau de risque : inacceptable (interdit), haut risque (soumis à des obligations strictes de gestion des risques, de qualité des données, de documentation, de traçabilité et de supervision humaine), risque limité (obligations de transparence) et risque minimal. Un modèle de scoring de crédit ou de présélection de personnel relève de la catégorie haut risque et doit satisfaire à des exigences rigoureuses. Connaître la catégorie dans laquelle s'inscrit un système est la première étape de tout projet sérieux.
Erreurs courantes qui font échouer les projets
- Fuite de données (data leakage) : inclure dans l'entraînement une information qui ne sera pas disponible au moment de la prédiction réelle produit des métriques spectaculaires en laboratoire et un échec en production.
- Optimiser l'exactitude avec des classes déséquilibrées : l'erreur classique qui produit des modèles inutiles qui « ont raison » en ignorant la classe minoritaire.
- Ignorer la dérive du modèle (model drift) : les motifs changent avec le temps ; un modèle qui n'est ni surveillé ni réentraîné se dégrade en silence.
- Biais dans les données d'entraînement : si les données historiques reflètent une discrimination, le modèle l'apprend et l'amplifie.
- Commencer par le modèle et non par le problème : choisir un algorithme sophistiqué avant de définir quelle décision métier on va améliorer, c'est inverser l'ordre logique.
Questions fréquentes
Combien de données me faut-il pour entraîner un modèle ?
Cela dépend de la complexité du problème et de l'algorithme. Des modèles classiques comme les arbres de décision ou la régression peuvent fonctionner avec des milliers d'exemples bien étiquetés ; les réseaux profonds exigent des volumes bien plus importants. Plus que la quantité, c'est la qualité qui importe : des données représentatives, sans biais et correctement étiquetées.
Quelle différence y a-t-il entre machine learning et deep learning ?
Le deep learning est un sous-ensemble du machine learning fondé sur des réseaux de neurones à de nombreuses couches. Il excelle sur les données non structurées (images, texte, audio), tandis que pour les données tabulaires d'entreprise, les méthodes classiques — comme les arbres boostés par gradient — rendent souvent autant voire mieux à moindre coût.
Est-il obligatoire d'expliquer les décisions d'un modèle ?
Dans les systèmes à haut risque selon l'AI Act et dans les décisions automatisées ayant des effets significatifs selon le RGPD, oui : la transparence et la supervision humaine doivent être garanties. Les techniques d'IA explicable (XAI) aident à interpréter pourquoi un modèle a pris une décision concrète.
Puis-je démarrer sans une équipe de science des données interne ?
Oui. De nombreuses organisations démarrent avec un cas d'usage circonscrit et à forte valeur, en s'appuyant sur du conseil externe et des plateformes de ML gérées, et construisent une capacité interne à mesure que le projet démontre son retour.
Conclusion
Le machine learning cesse d'être une promesse et commence à générer de la valeur le jour où on le traite pour ce qu'il est : un projet d'ingénierie des données discipliné, et non un tour de magie algorithmique. Le facteur décisif n'est jamais l'algorithme choisi, mais la qualité des données, le choix d'une métrique qui reflète vraiment l'objectif métier et la vigilance continue face à la dérive du modèle. Et en Europe, cette rigueur technique est indissociable de la conformité réglementaire : classer le système selon l'AI Act et respecter le RGPD n'est pas de la bureaucratie ajoutée, mais une partie de la conception responsable. Chez Summum Inteligencia Artificial, nous accompagnons chaque projet depuis la définition du problème jusqu'au déploiement et à la surveillance en production, avec la légalité européenne comme exigence de départ.