Dépendre d'un LLM : cas Dataaxy

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. Le sujet n'était pas de faire un modèle plus élégant. Le sujet était plus simple : une décision automatisée commençait à dépendre trop fortement d'un LLM externe.

Cette décision paraît minuscule au départ. Une offre d'emploi arrive, le système doit répondre : est-ce qu'elle mérite d'être publiée sur Dataaxy ? Si oui, dans quelle catégorie ? Derrière cette question, il y a pourtant trois risques que beaucoup de fondateurs sous-estiment : le coût qui grimpe avec le volume, la dépendance à un fournisseur, et l'impossibilité de savoir précisément si la qualité s'améliore ou se dégrade.

J'ai donc remplacé cette brique par un système local, plus simple à mesurer et moins dépendant d'un provider externe. Mais le vrai enseignement n'est pas "il faut remplacer les LLM". Ce serait trop facile. Le vrai enseignement, c'est qu'un CEO doit savoir repérer le moment où une fonctionnalité IA n'est plus une expérimentation, mais 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. C'est exactement le genre de choix que je ferais encore 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, chaque erreur difficile reste difficile à corriger, parce que le système repose davantage sur un comportement probabiliste que sur une frontière produit vraiment maîtrisée.

Le risque n'est donc pas "le LLM peut se tromper". Tout système se trompe. Le risque, c'est de ne pas savoir combien ces erreurs coûtent, lesquelles comptent vraiment, et comment les réduire sans dépendre d'un acteur extérieur.

Mesurer l'impact business

Pour un fondateur, la question n'est pas de savoir si MiniLM, Gemini ou un autre modèle est plus élégant. La question est : qu'est-ce qu'une mauvaise classification coûte au 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 donc construit l'évaluation autour de cas réels. Pas uniquement des exemples faciles. 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. C'est exactement le genre de cas où un petit système local peut être plus intéressant qu'un LLM externe. Pas parce qu'il "comprend mieux". Parce qu'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.

C'est un point que je répète souvent en mission : une bonne architecture IA n'est pas celle qui met un modèle partout. C'est celle qui met le bon niveau d'automatisation au bon endroit. Le modèle quand il apporte de la nuance. La règle métier quand le cas est évident. L'évaluation pour savoir si 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.

Ce n'est pas une critique des LLM. J'en utilise, et ils sont souvent le meilleur point de départ. Le piège, c'est de confondre point de départ et architecture durable. Un LLM externe permet de lancer vite. Une fois que le cas d'usage est validé, il faut parfois reprendre une partie du contrôle.

Dans Dataaxy, le bon choix n'était pas de supprimer toute IA externe. C'était de déplacer une décision répétitive vers un système local, mesuré, avec un chemin de repli. Le LLM reste utile comme comparaison, fallback ou outil de labellisation. Il n'a simplement plus besoin d'être le passage obligé pour chaque offre.

Cette nuance est importante pour un CEO. Le bon arbitrage n'est pas "LLM ou pas LLM". C'est : quelle décision mérite un modèle généraliste, quelle décision mérite un modèle spécialisé, et quelle décision mérite juste une règle métier proprement 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.
• Le vrai sujet n'est pas le modèle, mais la mesure : 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 ? 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.