Machine Learning : avant de dire oui

En board meeting, quelqu'un pose la question : "Nos concurrents font de l'IA, pourquoi pas nous ?" Le CTO répond mal, ou pas assez clairement. Le CEO dit oui sans savoir à quoi il dit oui. Six mois plus tard, le budget R&D a fondu sans résultat mesurable. J'ai vu cette scène se jouer plusieurs fois. Le ML est devenu un argument commercial avant d'être une décision technique, et ça coûte cher. Ce que j'aurais voulu vous dire plus tôt, en tant que CTO : pas pour convaincre, mais pour qu'on décide mieux ensemble.

Ce que le ML fait, en langage business

Pas de maths. Pas d'algorithmes. Une seule idée : le ML automatise des décisions trop complexes pour être écrites à la main.

Quatre exemples :

• Quel lead a le plus de chances de convertir ? Scoring commercial. Au lieu qu'un commercial trie 500 contacts à l'instinct, un modèle analyse les comportements passés et priorise.
• Quel client risque de churner ce mois-ci ? Prédiction de churn. Au lieu d'attendre que quelqu'un parte pour réagir, on intervient avant, sur les bons comptes.
• Ce contenu viole-t-il vos CGU ? Modération automatique. Au lieu de faire lire des milliers de messages à des humains, un modèle filtre en temps réel.
• Combien vaut cette maison à La Réunion ? Estimation immobilière. Surface, quartier, vue mer ou pas, proximité des commerces, historique des ventes du secteur. Un agent immobilier fait ça à l'instinct sur 10 biens par semaine. Un modèle le fait sur 10 000 annonces en continu.

Un humain pourrait faire tout ça. Mais pas à cette échelle, pas à cette vitesse, et pas à ce coût.

Quand le ML crée un avantage compétitif réel

Tout le monde ne devrait pas faire du ML. Mais dans certains contextes, il crée un écart que vos concurrents ne comblent pas en embauchant plus.

La personnalisation à l'échelle, d'abord. Livrer à chaque utilisateur une expérience qu'on ne pourrait pas livrer manuellement. Recommandation de contenu, tarification dynamique, parcours adaptatif. Netflix n'a pas une équipe humaine qui choisit ce que vous regardez ensuite. Son modèle, si.

La détection de signaux faibles. Voir ce qu'un humain raterait dans le volume. Fraude en temps réel sur des millions de transactions. Clients à risque avant qu'ils partent. Panne machine avant qu'elle se produise. Un humain saurait interpréter chaque signal individuellement. Il ne peut juste pas tous les traiter à la vitesse requise.

L'automatisation de tâches cognitives répétitives. Extraction d'infos dans des documents, tri de tickets support, qualification de leads entrants. Des tâches prévisibles, volumineuses, coûteuses en temps humain. Pas intellectuellement stimulantes. Exactement ce qu'un modèle fait bien.

Posez-vous la question : est-ce qu'un de ces cas ressemble à un problème que vous contournez encore avec des humains ou des règles bricolées ?

Les 3 questions à poser à votre équipe tech

Pas besoin de compétence technique pour les poser. Il faut juste que l'équipe joue franc jeu.

"Qu'est-ce qu'on ferait sans ML ?"

Si la réponse est "rien, ce problème n'a pas d'autre solution", le ML est probablement stratégique. Si c'est "des règles un peu moins précises", pesez le coût. J'ai vu des règles simples bien maintenues couvrir 80% des cas à 10% du prix d'un modèle. Parfois le bon choix, c'est de ne pas faire de ML.

"On a les données pour ça ?"

Un modèle sans données de qualité, c'est un moteur sans carburant. J'ai vu des équipes se lancer dans un projet ML pour découvrir six semaines plus tard que leurs données étaient éparpillées dans trois outils sans cohérence. Le projet ML est devenu un projet data. Deux fois plus de temps, deux fois plus cher. Cette question révèle souvent le vrai investissement à faire.

"C'est quoi le coût si le modèle se trompe ?"

La tolérance à l'erreur, c'est une décision business, pas technique. Bloquer un client légitime en détection de fraude, ça n'a pas le même coût qu'une mauvaise recommandation produit. Cette question force une discussion que trop d'équipes évitent : quel niveau d'erreur on accepte, et qui assume.

Si votre équipe ne peut pas répondre clairement à ces trois questions, le projet n'est pas prêt. Pas l'équipe. Le projet.

Ce que le ML coûte vraiment

Un modèle en production, ce n'est pas une feature qu'on livre et qu'on oublie. Il a besoin de données fraîches, de monitoring, de réentraînements réguliers. Il dérive si les comportements changent. Quelqu'un doit s'en occuper, en continu. C'est de l'infrastructure, pas un projet.

Comptez 3 à 6 mois avant un premier signal fiable. Données disponibles, problème bien cadré, équipe expérimentée. Si une de ces conditions manque, doublez.

Un data scientist senior ne se manage pas comme un dev backend. Besoins spécifiques en infra, en environnement, en autonomie. Le marché est tendu. Attirer ce profil prend du temps, le garder en prend encore plus.

Le ML mal cadré est un des meilleurs moyens de brûler du budget R&D sans ROI. Et la dette technique qui s'accumule autour d'un projet ML raté est particulièrement douloureuse. J'en parle dans mon article sur la gestion de la dette technique.

Comment décider ensemble

Deux questions, quatre cases.

Vrai problème + données disponibles → GO. Investir.

Vrai problème + pas de données → Investir dans la data d'abord. Le ML viendra après.

Pas de problème clair + données disponibles → Pas maintenant. Revenez quand vous aurez le problème.

Pas de problème clair + pas de données → Stop. Ce n'est pas le bon moment.

Une seule case justifie de commencer. Si votre équipe ne peut pas vous placer dans l'une des quatre, le projet n'est pas mûr. C'est un problème de cadrage, pas de compétence.

Ce qu'il faut retenir

• Le ML automatise des décisions trop complexes pour des règles manuelles. Si le problème se résout avec des règles, commencez par là.
• Trois questions suffisent pour cadrer un projet ML : qu'est-ce qu'on ferait sans ? On a les données ? Quel est le coût de l'erreur ?
• Le ML mal cadré brûle du budget. Bien cadré, il crée un avantage que vos concurrents ne copient pas facilement.

Questions fréquentes

Faut-il une équipe data pour faire du ML en startup ?

Pas forcément une équipe. Mais au moins une personne qui maîtrise le cycle complet : collecte, nettoyage, entraînement, déploiement, monitoring. Un data scientist seul sans ingénieur data pour préparer les pipelines avancera lentement. Certains projets tiennent avec un profil, d'autres en demandent deux ou trois dès le départ.

Combien de temps avant de voir des résultats ?

Données disponibles, problème bien défini : 3 à 6 mois pour un premier signal exploitable. C'est le délai avant de savoir si l'approche fonctionne, pas avant le déploiement en prod. Si le problème de données n'est pas résolu en amont, ajoutez 2 à 4 mois.

Le ML est-il pertinent pour une startup early-stage ?

Rarement. En early-stage, le problème principal c'est de valider qu'on résout le bon problème pour les bonnes personnes. Le ML demande des données qu'on n'a pas encore, un budget qu'on ne peut pas gaspiller, du temps qu'on n'a pas. Il y a des exceptions, si la proposition de valeur repose sur une capacité impossible sans ML. Mais dans la majorité des cas, c'est trop tôt.

Conclusion

La question n'est pas que le CEO comprenne le ML. C'est que le duo CEO/CTO ait un cadre commun pour en parler.

Ce que j'attends en tant que CTO : des décisions claires sur la tolérance au risque, le budget, les priorités business. Pas une validation technique. Ce que le CEO peut attendre de moi : une réponse honnête à "est-ce que ça vaut le coup, et pourquoi maintenant ?". Pas du jargon.

Quel problème dans votre produit résiste encore à vos règles actuelles ? Si vous avez une réponse précise, vous tenez peut-être votre prochain projet ML.

Discutons-en 30 minutes.