“Et si on mettait de l’IA là-dessus ?” La phrase circule dans les démos depuis trois ans. Elle marche partout parce qu’on peut effectivement brancher un LLM sur n’importe quoi. Branchable ne veut pas dire utile. La majorité des cas où on l’utilise, un regex, une règle métier ou une jointure SQL faisaient déjà le travail, mieux et pour mille fois moins cher.

Cinq situations où je vois passer des projets IA qui n’avaient aucune raison d’être.

La classification quand les catégories sont stables

Votre service client reçoit des emails et doit les router vers les bons services. Un commercial vous propose un LLM pour classer les emails.

La question à poser : les catégories sont-elles stables et bien définies ? Si oui, un classifieur entraîné sur 200-500 exemples labellisés (ou même un ensemble de règles par mots-clés) fait le travail avec une précision de 90-95%, un coût quasi-nul à l’inférence, et une explicabilité totale (vous savez exactement pourquoi un email a été classé dans telle catégorie).

Un LLM coûte 10 à 100 fois plus par requête pour un résultat similaire. Et vous avez moins de contrôle sur le comportement aux frontières.

L’IA générative est utile pour la classification quand les catégories sont floues, nombreuses, ou évoluent souvent. Pour des catégories stables et bien définies, les solutions classiques sont meilleures.

L’extraction de données structurées sur format connu

Extraire des montants, des dates, des noms depuis des documents.

Un regex ou un parseur structuré fait ça parfaitement sur des formats connus. Il est prévisible, testable, déterministe. Un LLM peut le faire aussi, mais avec un risque d’hallucination sur des valeurs numériques précises (dates, montants), et un coût plus élevé.

L’exception : les documents non structurés avec des formats très variables (contrats rédigés en langue naturelle, emails). Là, le LLM apporte de la valeur. Pour des factures ou des formulaires avec un format connu, un parseur structuré est supérieur.

Une recherche dans une base de données déjà bien structurée

Votre catalogue produit a 10 000 références. Quelqu’un vous propose d’y mettre un LLM pour la recherche.

Si vos références sont dans une base de données relationnelle avec des attributs bien définis (catégorie, couleur, taille, prix), une recherche SQL ou Elasticsearch est plus rapide, plus précise, plus transparente, et infiniment moins chère.

Le LLM apporte de la valeur pour la recherche en langue naturelle sur du contenu non structuré (documentation, articles, emails). Pour de la recherche sur des attributs structurés, le moteur de recherche classique gagne.

Générer du contenu en volume sans relecture humaine

Votre équipe marketing veut « générer des descriptions produits avec l’IA » pour accélérer la production.

Cas d’usage légitime quand un humain relit avant publication. Cas d’usage à risque quand la sortie part directement en ligne. La différence entre les deux n’est pas dans l’outil, elle est dans le processus de relecture qui existe ou pas en aval. Sans cette étape, vous publiez des erreurs factuelles sur vos propres produits, sans même le savoir.

Le piège : mesurer le gain de productivité sur la génération sans mesurer le coût de la relecture et des corrections. Souvent, le gain net est inférieur à ce que la démo laissait entendre.

Le chatbot RAG sur une documentation déjà mal maintenue

« Mettons un chatbot sur notre base de connaissances pour que les employés trouvent les informations plus facilement. »

Si votre base de connaissances est bien structurée et maintenue, un moteur de recherche efficace (Elasticsearch, Typesense) est souvent plus précis, moins coûteux, et plus prévisible qu’un RAG. Les chatbots RAG sont utiles quand la documentation est volumineuse, variée, et que les questions sont ouvertes. Ils sont moins utiles quand les questions sont factuelles et que les réponses sont dans des documents clairement identifiables.

Et si votre base de connaissances n’est pas bien maintenue, le chatbot RAG va reproduire et amplifier les incohérences. C’est un problème d’organisation, pas de technologie.

L’IA comme solution de dernier recours

L’IA est la solution de dernier recours. Pas par principe : par discipline d’audit. Avant de signer un projet, on doit avoir éliminé deux alternatives. La règle métier déterministe, qui marche depuis trente ans dans le même genre de problème. Et la réorganisation de processus, qui résout parfois le sujet sans aucune ligne de code. Si ces deux options ont été examinées et écartées sur dossier, alors le LLM mérite qu’on en parle. Sinon, vous faites de l’IA pour l’IA, et vous le payez deux fois : la facture d’API, plus la dette technique de ne pas avoir cherché plus simple.