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
Oublions les maths et les algorithmes. Une idée suffit : 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 accomplir chacune de ces tâches. Il ne pourrait pas suivre ce volume au même rythme ni au même 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 consiste à adapter l'expérience de chaque utilisateur sans intervention manuelle. Recommandation de contenu, tarification dynamique, parcours adaptatif. Netflix n'a pas une équipe humaine qui choisit ce que vous regardez ensuite. Son modèle s'en charge.
Le ML repère aussi des signaux faibles qu'un humain perdrait dans le volume. Fraude en temps réel sur des millions de transactions. Clients à risque avant leur départ. Panne machine avant qu'elle se produise. Un humain saurait interpréter chaque signal séparément. Il ne peut pas tous les traiter assez vite.
Le troisième cas concerne les tâches cognitives répétitives. Extraction d'informations dans des documents, tri de tickets support, qualification de leads entrants. Elles sont prévisibles, nombreuses et coûteuses en temps humain. Un modèle les absorbe 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
Vous n'avez pas besoin de compétence technique pour les poser. L'équipe doit simplement jouer 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 lancer un projet ML puis découvrir, six semaines plus tard, des données éparpillées dans trois outils sans cohérence. Le projet ML s'est transformé en projet data. Deux fois plus de temps, deux fois plus cher. Cette question révèle souvent l'investissement à faire en premier.
"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 ne se livre pas pour être oublié. Il a besoin de données fraîches, de monitoring et de réentraînements réguliers. Il dérive lorsque 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.
Un projet ML mal cadré brûle vite le budget R&D sans produire de ROI. La dette technique laissée par un projet raté coûte ensuite cher à reprendre. 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
Le CEO n'a pas besoin de comprendre le ML dans le détail. Le duo CEO/CTO a besoin d'un cadre commun pour en parler.
En tant que CTO, j'attends des décisions claires sur la tolérance au risque, le budget et les priorités business. Pas une validation technique. 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.