Une fonctionnalité IA peut très bien marcher en démo et devenir un risque quand elle tourne tous les jours. C'est ce que j'ai vu avec Dataaxy, un job board spécialisé dans les métiers data et IA. Nous ne cherchions pas un modèle plus élégant. Une décision automatisée dépendait simplement trop d'un LLM externe.
Cette décision paraît minuscule au départ. Une offre d'emploi arrive. Le système doit déterminer si elle mérite d'être publiée sur Dataaxy et, si oui, dans quelle catégorie. Mais le coût grimpe avec le volume, le fournisseur devient une dépendance et personne ne sait précisément si la qualité s'améliore ou se dégrade.
J'ai remplacé cette brique par un système local, plus simple à mesurer et moins dépendant d'un provider externe. Il ne faut pas en conclure que tous les LLM doivent disparaître. Un CEO doit surtout repérer le moment où une fonctionnalité IA quitte l'expérimentation pour devenir une partie critique du produit.
Comprendre le risque
Dataaxy agrège des offres issues de plusieurs ATS. Sur le papier, classifier une offre semble simple. Si le titre contient "Data Engineer", elle est probablement pertinente. Si le titre contient "Account Executive", elle ne l'est probablement pas.
La réalité est moins propre. Une startup IA recrute des commerciaux, des juristes, des product managers et des customer success managers. Leurs descriptions parlent souvent d'IA, de données, de modèles, de clients techniques. Pour un job board spécialisé, ces offres sont des faux positifs. Elles ont les bons mots, mais pas le bon métier.
Au début, un LLM externe est une excellente solution. On écrit un prompt, on décrit les règles, on obtient vite un premier résultat. Je ferais encore ce choix pour tester une hypothèse. Le problème commence plus tard, quand la fonctionnalité devient régulière.
À ce moment-là, chaque offre synchronisée devient un appel API. Chaque changement de modèle peut modifier la qualité. Chaque panne ou ralentissement du provider touche une partie du pipeline. Et surtout, une erreur repérée reste difficile à corriger, parce que le système repose davantage sur un comportement probabiliste que sur une frontière produit vraiment maîtrisée.
Tout système peut se tromper, LLM compris. Le risque vient de ce qu'on ignore : le coût des erreurs, celles qui comptent vraiment et la manière de les réduire sans dépendre d'un acteur extérieur.
Mesurer l'impact business
Pour un fondateur, l'élégance du modèle compte moins que le coût d'une mauvaise classification pour le produit.
Dans Dataaxy, un faux positif est plus dangereux qu'un faux négatif. Si une bonne offre est ratée, elle pourra revenir au prochain passage ou être ajoutée plus tard. Si une mauvaise offre apparaît dans les résultats, l'utilisateur la voit tout de suite. Il se dit que le job board n'est pas si spécialisé. La confiance baisse.
C'est un arbitrage produit, pas un arbitrage ML. La bonne métrique n'est pas seulement l'accuracy globale. Il faut regarder les erreurs visibles par l'utilisateur, celles qui abîment la promesse du produit. Dans ce cas, la promesse est claire : montrer des offres data et IA pour des praticiens, pas toutes les offres d'entreprises qui vendent de l'IA.
J'ai construit l'évaluation autour de cas réels, y compris les exemples difficiles. Les offres qui comptent sont celles qui piègent le système : sales dans une entreprise IA, solutions engineer très technique, manager data, support d'un produit database, product manager avec beaucoup de vocabulaire machine learning.
Après remplacement, l'évaluation finale donne une base solide : 0.936 de précision sur la décision pertinent / non pertinent, 4.7% de faux positifs parmi les offres prédites pertinentes, 0.783 de précision sur la catégorie, et 0.793 de macro-F1 sur les catégories. Ces chiffres ne disent pas "le système est parfait". Ils disent quelque chose de plus utile : on sait enfin mesurer la qualité de la décision.
Et quand on sait mesurer, on peut arbitrer.
Agir sans sur-ingénierie
La tentation, sur un sujet IA, est de répondre par plus d'IA. Plus gros modèle. Plus de prompting. Plus d'orchestration. Parfois c'est nécessaire. Ici, ça aurait été une mauvaise dépense d'énergie.
La tâche était répétitive, bornée et assez stable. Dans ce cas, un petit système local peut être plus intéressant qu'un LLM externe. Il ne "comprend" pas mieux. Il coûte moins cher à exécuter, se teste plus facilement et reste sous contrôle.
Sous le capot, Dataaxy utilise maintenant des embeddings locaux et une couche de classification légère. Je garde volontairement le détail technique au second plan, parce que ce n'est pas ce qu'un CEO doit retenir. Ce qu'il doit retenir, c'est la logique de décision : quand une tâche devient fréquente, mesurable et centrale pour l'expérience produit, il faut se demander si l'appel LLM externe est encore le bon outil.
J'ai aussi gardé des règles explicites dans le système. Par exemple, certains titres comme Account Executive, Sales Engineer ou Engineering Manager n'ont pas besoin d'une grande prédiction probabiliste. Le produit sait déjà qu'ils sont hors cible. Une règle claire et testée vaut parfois mieux qu'une réponse intelligente mais instable.
Je le répète souvent en mission. Une bonne architecture IA place le bon niveau d'automatisation au bon endroit. Le modèle apporte la nuance, la règle métier traite le cas évident et l'évaluation vérifie que l'ensemble tient encore.
Décider quoi automatiser
Le cas Dataaxy pose une question plus large : à partir de quand une dépendance IA devient-elle un risque produit ?
Je regarderais quatre signaux. Si la fonctionnalité tourne souvent, son coût marginal compte. Si elle influence directement l'expérience utilisateur, ses erreurs doivent être mesurées. Si elle dépend d'un fournisseur externe, il faut un plan en cas de changement de prix, de panne ou de dégradation. Si elle encode une règle métier spécifique, votre équipe doit pouvoir l'ajuster sans attendre qu'un modèle généraliste devine votre intention.
J'utilise des LLM, souvent comme point de départ. Une fois l'usage validé, il faut réexaminer ce qu'on achète et ce qu'on construit dans la fonctionnalité IA. Le piège consiste à prendre ce départ pour une architecture durable. Un LLM externe permet de lancer vite. Il faut parfois reprendre une partie du contrôle.
Dans Dataaxy, nous avons déplacé une décision répétitive vers un système local, mesuré et doté d'un chemin de repli. Le LLM reste utile comme comparaison, fallback ou outil de labellisation. Il n'est simplement plus le passage obligé pour chaque offre.
Pour un CEO, l'arbitrage ne se résume pas à "LLM ou pas LLM". Il faut attribuer chaque décision au bon outil : modèle généraliste, modèle spécialisé ou simple règle métier testée.
Ce qu'il faut retenir
- Une dépendance à un LLM externe devient risquée quand elle porte une décision produit fréquente, visible et coûteuse en cas d'erreur.
- La mesure compte davantage que le modèle : quelles erreurs coûtent cher, à quelle fréquence, et avec quel impact utilisateur ?
- Un système local plus simple peut être meilleur qu'un LLM externe si la tâche est stable, répétitive et bien cadrée.
Questions fréquentes
Faut-il éviter les LLM externes dans un SaaS ?
Non. Un LLM externe est souvent le meilleur moyen de tester vite une fonctionnalité IA. Le problème apparaît quand une fonctionnalité validée continue de dépendre entièrement de ce provider alors qu'elle est devenue fréquente, mesurable et centrale pour le produit.
Quand faut-il remplacer un appel LLM par un système local ?
Quand la tâche est répétitive, que les critères de qualité sont clairs, et que les erreurs peuvent être mesurées sur des cas réels. Si le besoin demande du raisonnement ouvert ou change tout le temps, garder un LLM externe peut rester plus pertinent.
Pourquoi les faux positifs étaient-ils plus graves que les faux négatifs ?
Parce qu'ils sont visibles par l'utilisateur. Une bonne offre manquée peut être récupérée plus tard. Une mauvaise offre affichée donne immédiatement l'impression que le job board n'est pas assez spécialisé. Dans un produit de curation, la confiance vaut plus que l'exhaustivité.
Qu'est-ce qu'un CEO doit retenir de ce cas ?
Une fonctionnalité IA n'est pas seulement un coût API. C'est une décision automatisée. Il faut savoir ce qu'elle décide, combien coûtent ses erreurs, comment la qualité est mesurée, et ce qui se passe si le fournisseur externe change les règles du jeu.
Conclusion
Le cas Dataaxy ne raconte pas qu'un classifier local est toujours meilleur qu'un LLM externe. Ce serait une mauvaise conclusion.
Il raconte autre chose : quand une fonctionnalité IA devient récurrente, elle mérite le même niveau de sérieux qu'une brique de paiement, de recherche ou de facturation. On doit connaître son coût, ses erreurs, ses dépendances et son plan de repli.
Si vous construisez une feature IA dans un SaaS, commencez par cette question : quelle décision automatisez-vous exactement ? J'ai détaillé la suite dans ce guide pour intégrer l'IA dans un SaaS : coût de l'erreur, évaluations, données et passage en production. Ensuite seulement, choisissez l'outil.
J'accompagne ce type de cadrage sur mes missions d'ingénierie IA et LLM. Si vous voulez savoir si votre cas mérite un LLM, un modèle local ou une règle métier bien placée, on peut le cadrer en 30 minutes.