Le modèle est la plus petite partie. Être prêt pour la production, c’est un jeu d’évaluation, un coût par requête, et une réponse définie à la question : que fait-on quand la sortie est fausse ?
Une démonstration prouve qu’un modèle peut avoir raison. La production exige de savoir à quelle fréquence il a tort, comment on l’apprend, et ce que fait le système quand cela arrive. Ces trois points relèvent de l’ingénierie, et ils prennent plus de temps que le choix du modèle sur lequel tout le monde se concentre.
Un jeu d’évaluation que vous n’avez pas écrit la veille
Sans jeu de test représentatif des entrées réelles, « ça a l’air mieux » est le seul signal de qualité disponible, et il ne vaut plus rien au bout de six semaines. Ce jeu doit être bâti à partir de données de production, tenu à l’écart de tout prompt et de tout entraînement, et rejoué à chaque changement.
Un coût par requête que vous pouvez multiplier
Le coût par requête multiplié par le volume attendu est le chiffre qui décide si la fonctionnalité part en production. C’est aussi celui que la plupart des preuves de concept ne produisent jamais, parce qu’au volume d’une démonstration il s’arrondit à zéro.
Un chemin d’échec défini
Toute fonctionnalité d’IA doit répondre à : que voit l’utilisateur quand le modèle se trompe avec assurance ? L’échec silencieux est le comportement par défaut, et c’est le pire. Replis, seuils de confiance et relecture humaine font partie de la conception, pas d’un raffinement ultérieur.
Où passe réellement l’effort
Sur les projets que nous menons, le choix du modèle dépasse rarement le dixième du travail. Le reste, c’est l’accès aux données, l’évaluation, le coût de service, et la tuyauterie qui permet de changer d’avis sur le modèle dans six mois sans réécrire le produit.