Quand utiliser l'IA et quand s'en passer

Un chef de produit lance : « Ajoutons de l'IA. » L'équipe acquiesce, mais la vraie question arrive juste après : ajouter de l'IA à quoi, et pourquoi ? Certains problèmes sont transformés par le machine learning. D'autres deviennent plus lents, plus chers et moins fiables dès qu'on y greffe un modèle. L'examen AI Practitioner teste votre capacité à distinguer les deux, et chaque réunion budgétaire réelle fait pareil. Cette leçon vous donne le jugement pour dire oui pour de bonnes raisons et non sans hésiter.

Le sujet précédent vous a appris ce que sont l'IA et le ML et comment les modèles apprennent. Celui-ci ouvre la moitié pratique : face à un problème métier, le machine learning est-il seulement le bon outil ? Ratez cette décision et aucune modélisation soignée ne sauvera le projet.

Où l'IA et le ML gagnent leur place

Le machine learning apporte de la valeur dans trois schémas récurrents. Quand un problème colle à l'un d'eux, le ML mérite d'être envisagé. Quand il ne colle à aucun, méfiez-vous.

Le premier schéma est assister une décision humaine. Le modèle ne décide pas ; il présente une prédiction, et une personne agit dessus. Un radiologue signe toujours le compte rendu, mais un modèle signale les trois zones les plus susceptibles de mériter un second regard. Un conseiller accorde toujours le prêt, mais un modèle note d'abord le risque de défaut. La valeur, c'est un humain plus rapide et mieux informé, pas un humain remplacé.

Le deuxième schéma est passer à l'échelle au-delà de la capacité humaine. Certaines tâches sont simples pour un élément et impossibles pour des millions. Lire un avis produit est facile ; lire 4 millions d'avis par jour pour suivre le sentiment ne l'est pas. Un modèle qui classe chaque avis en quelques millisecondes transforme une tâche impossible en routine. Le signal ici, c'est un volume qu'aucune équipe ne pourrait couvrir.

Le troisième schéma est automatiser un jugement répétitif. Pas une mécanique répétitive, qu'un simple script gère déjà, mais des décisions répétitives qui demandaient auparavant une personne : router un ticket de support vers la bonne file, taguer des photos par contenu, transcrire des appels. Quand la même décision floue se répète sans fin et qu'un petit taux d'erreur est tolérable, l'automatisation par le ML libère les gens pour un travail qui a vraiment besoin d'eux.

Remarquez ce qui unit les trois : le motif est complexe ou à fort volume, et une réponse bonne mais imparfaite est vraiment utile. Gardez cette idée, car les cas où le ML échoue sont exactement ceux qui la brisent.

Le côté coût du bilan

L'examen cite explicitement l'analyse coût-bénéfice comme raison de dire non, et le piège est de ne compter que la moitié du coût. Les équipes chiffrent le premier entraînement et s'arrêtent là. Un modèle en production est un système vivant, avec des coûts récurrents qui dépassent souvent la construction.

Vous payez pour collecter et étiqueter les données avant même de pouvoir entraîner quoi que ce soit, et l'étiquetage est souvent le poste le plus lourd. Vous payez pour entraîner, et pour de grands modèles la facture est réelle. Puis, après le lancement, les coûts continus démarrent : surveiller le modèle pour repérer quand sa précision baisse, le réentraîner sur des données fraîches à mesure que le monde change (un modèle de fraude entraîné sur la fraude de l'an dernier vieillit), et le temps d'ingénierie pour maintenir toute la chaîne. Un modèle construit en deux semaines peut demander des années d'entretien.

La vraie question n'est donc jamais « le ML peut-il faire ça ? ». C'est « la valeur dépasse-t-elle le coût total sur la durée ? ». Un modèle qui gagne 0,1 % de conversion peut être une prouesse technique et un mauvais investissement s'il faut trois ingénieurs pour le garder en vie. Pesez le bénéfice contre les données, l'entraînement et la maintenance ensemble, pas contre le seul entraînement.

Quand une prédiction est la mauvaise forme de réponse

C'est l'idée la plus précieuse de la leçon et celle que l'examen sonde le plus. Le machine learning produit des prédictions, et les prédictions sont probabilistes : souvent justes, parfois fausses, jamais garanties. Dès que la tâche exige un résultat précis, exact et prouvable, une prédiction est la mauvaise forme de réponse, peu importe la précision du modèle.

Le calcul de la TVA est l'exemple net. La TVA suit des règles publiées, et le montant sur la facture doit être exactement correct et défendable lors d'un audit. Un modèle « précis à 99,7 % » sur la TVA est un système cassé, parce que les 0,3 % sont un problème juridique. Le bon outil est une règle : chercher le taux, multiplier, terminé. La même logique couvre le calcul d'un solde de compte, l'application d'une remise fixe, la vérification d'un mot de passe ou l'application d'une règle métier stricte. Logique connue plus réponse exacte exigée égale écrivez la règle, pas le modèle.

Comparez avec la prévision des ventes du prochain trimestre. Aucune règle ne peut produire le chiffre exact, une prédiction approchée est vraiment utile, et être proche est déjà une victoire. C'est le terrain naturel du ML. Le test à emporter à l'examen : si la tâche exige une seule réponse prouvée correcte à partir d'une logique connue, écartez le ML ; si elle exige une bonne estimation de quelque chose d'incertain, le ML est candidat.

Autres raisons de dire non

Au-delà de la règle du résultat exact, quatre signaux indiquent qu'un problème n'a pas besoin de ML.

• La logique est simple et connue. Si vous pouvez écrire la règle en quelques lignes et qu'elle ne changera pas, écrivez-la. Un modèle pour décider si un nombre est pair est absurde ; n % 2 == 0 est exact, gratuit et permanent.
• Vous n'avez pas assez de données de qualité. Le ML apprend d'exemples. Quarante fiches partielles n'enseigneront pas un modèle d'attrition fiable. Pas de données, pas de motif, pas de modèle, quelle que soit la beauté du cas d'usage.
• Les erreurs sont intolérables et invérifiables. Si une sortie erronée cause un vrai préjudice et qu'aucun humain ne la relit, la nature probabiliste du ML devient un risque. Ajoutez une relecture humaine, ou utilisez une méthode déterministe.
• Vous ne pouvez pas définir le succès. Si vous ne savez pas dire à quoi ressemble une bonne prédiction ni la mesurer, vous ne pouvez ni entraîner ni évaluer un modèle. Un objectif flou produit un système flou et peu fiable.

Un guide de décision rapide

Le machine learning a besoin que les trois premières penchent vers oui et que le piège du résultat exact soit absent. Ratez l'une d'elles et la réponse honnête est que le ML est le mauvais outil ici.

Conseils pour l'examen

L'examen tend des pièges qui récompensent la règle du résultat exact et punissent l'enthousiasme « de l'IA partout ».

• Le mot-clé le plus fort pour écarter le ML est « un résultat précis est nécessaire » ou « un résultat exact/précis ». Quand vous le voyez, la réponse est que le ML n'est pas adapté ; choisissez l'option à base de règles ou déterministe.
• « Coût-bénéfice » dans un énoncé signale en général que la bonne réponse pèse la maintenance continue et le coût des données, pas seulement la précision. Guettez une option qui mentionne le coût total sur la durée.
• Schémas de valeur à reconnaître comme pro-ML : « assister la décision », « passer à l'échelle », « automatiser », « gérer un fort volume », « détecter des motifs que les humains manquent ».
• Ne vous laissez pas séduire par « la tâche est répétitive ». Une répétition avec une logique simple et fixe est un script, pas un modèle. L'examen plante ce piège pour voir si vous confondez automatisation et ML.

La règle à emporter : le machine learning échange l'exactitude contre la capacité à gérer la complexité et l'échelle, donc il convient quand le motif est difficile et qu'une estimation est utile, et il échoue quand la réponse doit être exactement juste à partir d'une logique connue. Une fois décidé que le ML est le bon outil, la question suivante est quelle technique correspond au problème, et c'est là que commence la prochaine leçon sur la régression, la classification et le clustering.