Beaucoup de projets de machine learning décevants n'échouent pas sur le modèle. Ils échouent avant le début de l'entraînement : personne ne sait dire si le processus actuel fonctionne bien, la décision que prendrait le modèle vaut quelques centaines de dollars par mois, ou le résultat atterrit dans un tableau de bord que personne n'ouvre. Les enquêtes disent la même chose de manière agrégée. Gartner s'attend à ce que plus de 40 % des projets d'IA agentique soient annulés d'ici fin 2027, en invoquant des coûts croissants, une valeur métier floue ou des contrôles des risques insuffisants. Dans l'enquête 2025 de McKinsey, 39 % des répondants déclaraient un impact quelconque de l'IA sur l'EBIT au niveau de l'entreprise, et la plupart d'entre eux le situaient sous 5 %. L'étude de BCG de septembre 2025 a montré que 5 % des entreprises tiraient de la valeur de l'IA à grande échelle et que 60 % déclaraient des gains minimes en chiffre d'affaires et en coûts malgré des investissements importants.
Construire des systèmes de ML est notre métier, et nous vous dirons quand même de ne pas en acheter un lorsqu'une règle ou un rapport coûte moins cher. Cette note liste les cinq signes que nous vérifions, ce que chacun signifie pour l'entreprise, et ce qu'il faut construire à la place.
La version courte pour la personne qui signe le budget
Quoi. Cinq questions sur votre processus, vos données et votre équipe. Si une seule réponse est « non », un modèle n'est probablement pas la prochaine étape.
Quand. Posez-les avant une phase de cadrage, pas après une preuve de concept. Y répondre prend un après-midi.
Ce que coûte de les ignorer. Une phase de cadrage avec une équipe externe coûte typiquement 6k–14k € sur 2–3 semaines, une preuve de concept 14k–38k € sur 4–7 semaines, et un système de production 45k–120k € sur 10–20 semaines. Ce sont nos fourchettes publiées ; d'autres prestataires auront des chiffres différents, mais l'ordre de grandeur tient. Une règle ou un rapport se livre généralement en quelques jours.
Risque. Le scénario coûteux n'est pas un modèle qui échoue. C'est un modèle qui fonctionne à peu près aussi bien qu'une règle que vous auriez pu écrire, et qu'il faut désormais réentraîner, surveiller et payer chaque mois.
Le propre guide d'ingénierie de Google s'ouvre sur ce même point. La règle n° 1 de ses Rules of Machine Learning est « Don't be afraid to launch a product without machine learning », parce que des heuristiques simples mènent souvent presque au bout avec bien moins de complexité.
Signe 1 : vous ne savez pas dire si le processus actuel fonctionne bien
Ce que cela signifie. Si personne ne peut donner le taux de rupture de stock actuel, la part actuelle de commandes frauduleuses ou le délai actuel de réponse à un ticket de support, personne ne pourra dire si un modèle l'a amélioré. Le projet se termine par une démo et un débat.
Symptôme typique. L'objectif est formulé comme une direction (« réduire les ruptures », « personnaliser le site ») plutôt que comme un chiffre avec une méthode de mesure et une fenêtre de temps.
Quoi faire à la place. Construisez d'abord la mesure. Un rapport hebdomadaire du seul chiffre que le modèle ferait bouger, calculé de la même manière chaque semaine, pendant quatre à huit semaines. Ce rapport est la référence que tout modèle ultérieur devra battre, et il est utile en lui-même : une fois le chiffre visible, il peut s'avérer que c'est un autre problème qui mérite d'être résolu. La règle n° 2 du guide de Google dit la même chose en d'autres termes : concevez et implémentez les métriques avant toute chose.
Signe 2 : la décision est rare, ou le volume est faible
Ce que cela signifie. Un modèle rentabilise son coût en améliorant légèrement de nombreuses petites décisions. Si la décision se produit cinquante fois par mois, l'amélioration n'a presque rien à multiplier.
Calcul illustratif. Supposons qu'un modèle améliore chaque décision de 2 % de la valeur en jeu.
| Décisions par mois | Valeur en jeu par décision | Gain mensuel à 2 % | Mois pour rembourser une preuve de concept de 14k € |
|---|---|---|---|
| 50 | 200 € | 200 € | 70 |
| 200 000 | 1 € | 4 000 € | 3,5 |
Les chiffres sont illustratifs, pas mesurés. Ce qui compte, c'est la forme : la première ligne n'est jamais rentabilisée, avant même de compter le monitoring et le réentraînement ; la seconde l'est en moins d'un trimestre.
Quoi faire à la place. Pour les décisions rares à forte valeur, donnez à la personne qui les prend un meilleur tableur : les cinq ou six données qu'elle utilise réellement, côte à côte, avec le résultat de l'an dernier à côté de chaque cas. Une checklist plus un humain font mieux qu'un modèle entraîné sur cinquante exemples.
Signe 3 : une règle simple capte déjà l'essentiel de la valeur
Ce que cela signifie. Beaucoup de problèmes ont une règle qui traite la majorité des cas. Bloquer les commandes au-dessus d'un seuil de valeur expédiées à une nouvelle adresse avec une nouvelle carte. Montrer les meilleures ventes de la catégorie aux visiteurs sans historique. Réapprovisionner quand le stock couvre moins de N jours des ventes du mois dernier. Un modèle doit battre la règle d'assez pour couvrir son coût de construction et d'exploitation, et souvent il n'y parvient pas.
Symptôme typique. Personne n'a essayé la règle, donc personne ne sait ce qu'il reste à gagner pour un modèle.
Quoi faire à la place. Livrez la règle, mesurez-la avec le rapport du signe 1, et tenez une liste des cas où elle se trompe. Cette liste remplit deux fonctions : elle vous dit combien de valeur un modèle pourrait encore ajouter, et elle devient les premières données étiquetées et le jeu de test si vous en construisez un plus tard.
Quand la règle ne suffit plus. La règle n° 3 de Google fait contrepoids : préférez le machine learning à une heuristique complexe. Quand la règle s'est transformée en dizaines d'exceptions qu'une seule personne comprend, et que chaque nouvelle exception en casse une ancienne, un modèle est plus facile à maintenir que le recueil de règles. C'est à ce moment-là que le ML commence à avoir du sens.
Signe 4 : vos données n'enregistrent pas le résultat que vous voulez prédire
Ce que cela signifie. Un modèle apprend à partir d'exemples dont la réponse est connue. Si la réponse n'a jamais été notée, il n'y a rien à apprendre.
Symptômes typiques.
- Une prévision de la demande sur un historique de ventes qui n'enregistre pas les ruptures de stock. Quand le rayon était vide, les ventes étaient nulles mais pas la demande, et le modèle apprend que le produit est impopulaire précisément les jours où il était le plus demandé.
- Une prédiction de l'attrition où personne n'a noté quand un client est parti, seulement qu'il a cessé d'apparaître.
- Un scoring de fraude où les rétrofacturations sont dans le portail d'un prestataire de paiement et n'ont jamais été rapprochées des commandes.
Quoi faire à la place. Commencez dès maintenant à enregistrer le résultat, dans le même système que les données d'entrée, avec un horodatage. La plupart des résultats demandent trois à six mois d'historique avant qu'un modèle puisse être entraîné puis testé sur une période ultérieure qu'il n'a pas vue. Faites tourner un rapport ou une règle en attendant. Si le résultat arrive tardivement (les rétrofacturations peuvent prendre des semaines), prévoyez ce délai dans la conception plutôt que de le découvrir en production.
Signe 5 : personne n'est chargé d'agir sur le résultat
Ce que cela signifie. Une prévision ne change rien tant que quelqu'un ne commande pas moins de stock à cause d'elle. Un score de fraude ne change rien tant qu'une commande n'est pas bloquée. S'il n'y a ni personne nommée, ni système où le résultat apparaît, ni action convenue pour chaque valeur, le modèle est un coût sans retour.
Symptôme typique. La réponse à « qui utilisera ceci et que fera-t-il différemment lundi » est un nom de département, pas une personne et une décision.
Quoi faire à la place. Prenez la décision à la main pendant un mois avec un rapport. Placez le rapport là où la décision est prise, et observez si quelqu'un s'en sert. Si personne n'agit sur un rapport, personne n'agira sur un modèle, et le problème à résoudre est le processus, pas la prédiction.
Un auto-diagnostic rapide
Répondez à chaque question pour le processus que vous voulez améliorer.
| Question | Si la réponse est non | Construisez plutôt ceci | Effort typique |
|---|---|---|---|
| Pouvez-vous donner la valeur actuelle de la métrique, et comment elle est mesurée ? | Pas de référence, pas de preuve d'amélioration | Un rapport hebdomadaire de cette seule métrique | Quelques jours |
| La décision se produit-elle au moins des milliers de fois par mois, ou chacune vaut-elle beaucoup ? | Trop peu de volume pour rentabiliser un modèle | Un tableur ou une checklist pour la personne qui décide | Quelques jours |
| Avez-vous essayé la règle évidente et l'avez-vous mesurée ? | Vous ne savez pas ce qu'un modèle pourrait ajouter | La règle, plus un journal des cas où elle se trompe | De quelques jours à deux semaines |
| Le résultat que vous voulez prédire est-il enregistré, avec une date, sur les derniers mois ? | Rien à partir de quoi apprendre | L'enregistrement du résultat, puis un rapport | Trois à six mois d'enregistrement |
| Y a-t-il un responsable nommé et une action définie pour chaque résultat ? | Le résultat ne changera rien | Un processus manuel appuyé sur un rapport pendant un mois | Un mois |
Cinq « oui » ne garantissent pas qu'un modèle sera rentable. Un seul « non » suffit généralement pour dire qu'il ne le sera pas encore.
Quand le ML devient rentable
La même checklist, lue dans l'autre sens, décrit un bon projet de ML :
- La métrique est mesurée de la même manière depuis des semaines, et il existe une référence à battre.
- La décision est fréquente, ou chacune porte assez de valeur pour qu'une petite amélioration compte.
- Une règle existe, a été mesurée et est devenue trop complexe à maintenir.
- Le résultat est enregistré depuis assez longtemps pour entraîner sur une période et tester sur une période ultérieure.
- Une personne nommée agira sur le résultat, dans un système qu'elle utilise déjà.
Même alors, la première étape est modeste : un modèle simple comparé à la règle sur la même métrique, d'abord sur des données historiques, puis sur une part du trafic réel. Si le modèle ne bat pas la règle de plus que ce qu'il coûte à exploiter, gardez la règle. C'est un résultat, pas un échec.
Comment vérifier votre propre cas
Nous proposons un teardown gratuit en six questions sur /teardown. Il interroge sur le processus, les données et le responsable, et l'une de ses réponses possibles est « ne faites pas encore de ML », avec ce qu'il faut construire à la place. Si la réponse est qu'un modèle a du sens, les fourchettes publiées sur /pricing vous indiquent ce que coûte l'étape suivante avant tout appel.
Sources
- Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, juin 2025 — https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
- McKinsey & Company, The state of AI in 2025: Agents, innovation, and transformation, novembre 2025 — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Boston Consulting Group, The Widening AI Value Gap: Build for the Future 2025 (communiqué de presse), septembre 2025 — https://www.bcg.com/press/30september2025-ai-leaders-outpace-laggards-revenue-growth-cost-savings
- Google for Developers, Rules of Machine Learning: Best Practices for ML Engineering (Martin Zinkevich), page mise à jour en août 2025 — https://developers.google.com/machine-learning/guides/rules-of-ml