Quand un projet IA patine en entreprise, le réflexe est presque toujours le même : on cherche un meilleur modèle. On regarde les classements, on compare les versions, on attend la prochaine sortie en se disant que celle-là, enfin, fera l'affaire.
Jonathan Frankle, Chief AI Scientist de Databricks, balaie cette hypothèse d'une phrase : « l'intelligence du modèle n'est typiquement pas le goulot d'étranglement, les modèles sont vraiment intelligents ». Il est bien placé pour le dire - il a cofondé MosaicML, rachetée par Databricks pour 1,3 milliard de dollars selon VentureBeat, et passe ses journées à déployer de l'IA chez des milliers d'entreprises.
Le vrai blocage est ailleurs. Et il est beaucoup moins glamour : vous ne savez pas dire si ce que l'IA produit est bon.
Le problème n'est pas le moteur, c'est l'absence de contrôle qualité
Imaginez que vous recrutiez un collaborateur brillant, diplômé des meilleures écoles, capable de rédiger cinquante notes par jour. Formidable. Sauf que personne, dans votre entreprise, n'est capable de relire ces notes et de dire « celle-ci est juste, celle-là est à jeter ». Au bout de trois semaines, vous ne saurez plus si ce recrutement vous fait gagner ou perdre de l'argent. Vous finirez par ne plus lui confier que des tâches sans conséquence.
C'est exactement ce qui arrive aux projets IA. Dans une enquête de VentureBeat sur les agents qui n'atteignent jamais la production, Hanlin Tang, CTO Neural Networks de Databricks, résume le phénomène : les équipes « volaient à l'aveugle, elles n'avaient aucun moyen d'évaluer ces agents ». Le pilote marche en démo, impressionne en comité, et meurt au moment de passer à l'échelle - parce que personne ne peut signer que la sortie est fiable.
Frankle appelle ça l'infrastructure manquante de l'IA d'entreprise. Dans sa masterclass chez Radical Ventures, il pose le diagnostic : l'adoption est moins limitée par le talent que par « la confiance, la mesure et la preuve ».
Pourquoi plus de puissance ne résout rien
La raison est simple : ce qui compte pour votre entreprise est toujours spécifique. Pas « rédiger un bon email », mais « rédiger la relance client conforme à notre politique commerciale ». Pas « analyser des chiffres », mais, selon la formule de Frankle, « le chiffre que le directeur financier doit reporter en fin de mois ».
Un modèle peut dominer tous les classements et rester de peu de valeur sur ce terrain-là. « Ce qui manque, c'est la spécificité, et aucune puissance supplémentaire n'y change grand-chose. » Databricks a d'ailleurs publié en décembre 2024 sa propre suite de tests métier (DIBS), couvrant six cas d'entreprise - finance, logiciel, industrie - pour montrer que les classements académiques ne prédisent pas la performance réelle sur ces tâches.
C'est la même intuition que celle que nous défendons depuis longtemps : le modèle est une commodité, le moat est ailleurs. Tout le monde aura le même moteur l'an prochain. Ce que personne ne peut acheter à votre place, c'est votre définition du travail bien fait.
L'évaluation, pour être précis
Derrière le mot « évaluation » (ou eval), il y a une mécanique très concrète. Une éval, c'est un jeu de cas représentatifs de votre métier - une vraie demande client, un vrai contrat, une vraie écriture comptable - accompagné, pour chacun, du critère qui dit si la réponse est acceptable. On fait tourner l'IA dessus, on compte combien de cas passent, et on obtient un score reproductible.
Quand le critère est trop subtil pour une simple règle, on utilise un juge : un second modèle à qui l'on a appris votre grille de lecture et qui note les sorties du premier. Le juge n'est pas plus malin que vous - il applique votre jugement à grande échelle.
Bonne nouvelle : ça ne demande pas un entrepôt de données. Les travaux de Databricks relayés par VentureBeat indiquent qu'un juge robuste peut se construire à partir de 20 à 30 exemples bien choisis. La condition : viser les cas limites qui créent du désaccord entre vos experts, pas les cas évidents où tout le monde est d'accord.
Le vrai travail est humain
Et c'est là que la difficulté se déplace. Frankle est catégorique : « tous les problèmes deviennent des problèmes humains. Le plus dur est de faire sortir une idée du cerveau d'une personne pour la rendre explicite. Et le plus dur encore, c'est que les entreprises ne sont pas un cerveau, mais plusieurs. »
Construire une éval, c'est obliger une organisation à écrire noir sur blanc ce qu'elle appelle un bon dossier - et à trancher quand le juridique, le commerce et la finance ne sont pas d'accord. C'est inconfortable. C'est aussi, accessoirement, le début d'un company brain : vos critères, vos cas limites, vos arbitrages, enfin sortis des têtes et rendus exploitables.
Frankle recommande d'ailleurs de progresser par paliers : commencer par un simple prompt sur un modèle du marché pour voir si la tâche est faisable, puis ajouter la recherche documentaire et les évals, et n'envisager un modèle affiné que si le retour sur investissement le justifie. On ne monte d'un cran que quand le cran précédent a prouvé sa valeur.
Ce qu'on fait
Chez Elephant, on ne commence jamais un chantier IA par le choix du modèle. On commence par la question qui fâche : comment saurez-vous que c'est bon ?
Concrètement : on s'assoit avec vos experts métier, on collecte une vingtaine de cas réels - en cherchant volontairement ceux sur lesquels ils ne sont pas d'accord entre eux - et on transforme leurs arbitrages en critères explicites. On en tire une éval exécutable, qui donne un score avant chaque mise en production et détecte les régressions quand vous changez de modèle.
Le bénéfice est double. Vous obtenez une IA dont la qualité est mesurable, donc déployable au-delà du pilote. Et vous pouvez changer de modèle du jour au lendemain sans rien reconstruire : votre éval reste valable, c'est le moteur qui se remplace. L'humain, lui, reste aux commandes - il définit le critère, tranche les cas ambigus, garde la main sur ce qui compte.
Un modèle plus intelligent améliore la réponse. Savoir juger la réponse, c'est ce qui vous permet de l'utiliser.
