Les évaluations d’IA survivront aux architectures d’IA

Nous avons passé deux mois à construire une pipeline agentique sur mesure pour un client opérant une place de marché en santé, incluant des outils de recherche web, d’extraction d’entités et de génération structurée de données. Puis GPT-5 est sorti et nous avons remplacé la majeure partie du système en une semaine. Même si cela peut sembler être un effort gaspillé, dans un domaine aussi dynamique que l’IA, c’est assez courant et la clé que nous avions construite dès le début était ce qui nous a permis d’agir rapidement malgré le fait que certains de nos travaux initiaux devenaient obsolètes. Au final, les évaluations que nous avions intégrées dès le départ étaient exactement ce qui nous a permis de changer de modèle sereinement, et ce sont ces mêmes évaluations qui ont guidé la dernière version.

Le projet

Notre client exploite une place de marché de santé qui connecte acheteurs et vendeurs dans les domaines clinique, opérationnel et IT. Le défi principal est de renseigner et maintenir à grande échelle des profils structurés de fournisseurs, tels que noms d’organisation, lignes de produits, modèles tarifaires, et spécialités ciblées à partir de sources publiques et privées.

Il s’agit d’un travail d’enrichissement de données, mais nettement plus ardu qu’il n’y paraît. Un agent doit rechercher un fournisseur donné sur le web, identifier la bonne entité (et non une société homonyme dans un autre secteur), extraire les champs pertinents, et générer des données structurées. L’identification correcte de l’entité était une contrainte majeure. Confondre un fabricant de dispositifs médicaux avec une marque d’électronique grand public portant le même nom de maison mère pouvait corrompre la place de marché et nuire à la confiance dans son contenu.

Première approche : framework agentique sur mesure

Nous avons conçu une pipeline basée sur OpenAI Agent SDK avec des outils de recherche web personnalisés. L’agent prenait un nom de fournisseur, lançait des recherches ciblées, analysait les résultats puis extrayait les profils structurés. Pendant deux mois, nous avons itéré pour obtenir quelque chose d’assez fiable pour la production. Le système fonctionnait, mais subsistait certaines limites. Il rencontrait notamment des difficultés à normaliser les entités et finissait par devenir difficile à maintenir à mesure que les résultats plafonnaient. Il subsistait aussi un problème d’hallucination concernant les liens et les données extraites des pages. Comme nous utilisions GPT 4o comme moteur LLM principal et sachant que l’API Responses plus mature d’OpenAI était disponible en alternative, il nous fallait étoffer notre manière de comparer les modèles le moment venu.

Construire les évaluations en amont

En parallèle du développement de la pipeline, nous avons mis en place un cadre d’évaluation. Cela s’est révélé la décision la plus importante du projet. Globalement, les évaluations devaient mesurer ce qui compte pour le produit, à savoir si le système retourne la bonne entité, si les champs extraits sont exacts et si la sortie est exploitable dans la place de marché. Nous avons choisi Braintrust pour effectuer les évaluations. Les cas de tests ont été développés à partir d’un jeu de données d’or constitué avec des experts métiers couvrant 50 à 100 entrées par champ à enrichir. Nous utilisions la F1, la précision, le rappel et une matrice de confusion avec un rapport de classification pour une analyse d’erreur plus manuelle.

Réévaluation après GPT-5

Quand OpenAI a publié GPT-5 avec la recherche web intégrée, nous avons mené une expérience en utilisant le même ensemble d’évaluations, remplaçant toute notre infrastructure de recherche et d’orchestration par les capacités natives du modèle. Les résultats se sont révélés supérieurs à ce que nous avions développé en plusieurs mois, ce qui est courant à mesure que les modèles génériques progressent vite. Les métriques de classification ont progressé d’environ 10%. L’approche coûtait plus cher par requête, mais elle était beaucoup plus simple à maintenir et, globalement, plus performante.

Grâce à ces évaluations déjà mises en place et réutilisables, la décision de migrer était fondée sur des données objectives. Nous pouvions identifier précisément où GPT-5 avec la recherche intégrée surpassait notre pipeline, où il faisait jeu égal et où il était moins performant.

L’itération suivante

La solution basée sur GPT-5 est maintenant en production, mais elle atteint ses limites. La qualité diminue à mesure que le nombre d’étapes de traitement et de validation augmente, notamment lorsqu’il faut crawler, rechercher, scraper, normaliser, synthétiser et vérifier les résultats. Ce processus multi-étapes ne peut être encapsulé dans une seule consigne à la fois cohérente et suffisamment précise. De plus, le coût de la recherche web intégrée est conséquent : il est deux fois plus élevé que l’utilisation d’un prestataire de recherche tel qu’Exa ou Firecrawl. Un autre point concerne l’enfermement propriétaire, qui rend impossible de tester d’autres modèles.

Nous expérimentons donc une architecture basée sur LangGraph, qui nous redonne une maîtrise fine des étapes de recherche et d’extraction tout en conservant un modèle de base plus performant. Les évaluations, encore une fois, sont la constante, bien qu’évolutive. Sans elles, comparer cette nouvelle approche à l’existant serait difficile et flou. Elles ont aussi évolué avec nos méthodes expérimentales, car il a fallu actualiser les cas de test pour refléter la dernière implémentation de la tâche ainsi que la nature changeante et dynamique du contenu web.

Le schéma

Les architectures agentiques ont aujourd’hui une durée de vie très courte, avec de nouveaux modèles, frameworks et patterns quasiment chaque mois, accompagnés de nouveaux outils. Des capacités auparavant réservées à l’ingénierie sur mesure deviennent d’un coup des fonctionnalités natives. Si votre cadre d’évaluation est couplé à une implémentation particulière, il faudra le reconstruire à chaque changement d’orientation, à chaque nouvelle solution plus performante. En revanche, si le cadre d’évaluation mesure les résultats, et non la façon d’y arriver, il reste valable quelle que soit l’architecture.

Cela signifie que les évaluations ne constituent pas seulement une phase de test en fin de projet, mais forment l’infrastructure qui rend possibles les choix d’architecture. Sans elles, passer d’une pipeline personnalisée à GPT-5 aurait relevé du pari. Avec elles, la comparaison a été menée, basée sur les données, en quelques jours.

À retenir concrètement

Étant donné la rapidité des améliorations des modèles fondamentaux d’IA et la sortie incessante de nouveaux outils, il est crucial d’investir dans les évaluations même avant d’avoir arrêté l’architecture, et de continuer à y investir à mesure que le projet évolue. Pour rester portables lors des changements de modèle, les évaluations doivent mesurer les résultats, pas les étapes intermédiaires. Ainsi, les choix d’architecture peuvent être traités comme des expérimentations, où les évaluations donnent une mesure claire pour guider la décision, plutôt que de s’en remettre à des débats sur ce qui « semble » mieux.