Les tableaux comparatifs de fonctionnalités mentent.

Chaque fournisseur d’IA a une liste de fonctionnalités impressionnante. Chaque démo tourne à la perfection sur des données préparées. Chaque présentation commerciale promet une transformation qui n’arrive jamais tout à fait comme elle a été vendue, et vous ne le découvrez qu’après avoir signé un contrat qui vous verrouille pour dix-huit mois.

Le marché des fournisseurs d’IA punit les approches d’évaluation traditionnelles, parce que ces approches ont été conçues pour des logiciels qui fonctionnent de la même manière à chaque exécution — précisément ce que les outils d’IA ne font pas. Un modèle qui excelle sur votre consigne de test peut halluciner sur les données réelles que vous lui donnez trois semaines après la mise en œuvre. Le fournisseur qui semble réactif pendant la phase commerciale peut mettre des jours à répondre une fois le contrat signé.

Il faut changer notre manière d’évaluer.

Ce que cachent vraiment les listes de fonctionnalités

Les fournisseurs se battent sur le nombre de fonctionnalités. Plus de fonctionnalités, ça suggère plus de valeur. Cette logique s’effondre quand on l’applique à l’IA.

Une fonctionnalité qui existe n’est pas une fonctionnalité qui marche pour votre cas d’usage. L’écart entre “notre produit peut faire X” et “notre produit fait X de manière fiable pour des clients comme vous” est souvent énorme, et les fournisseurs ont un intérêt financier à brouiller cette distinction à chaque occasion.

Regardez les capacités des modèles. La plupart des fournisseurs offrent désormais l’accès à des modèles de pointe d’OpenAI, d’Anthropic et de Google. Le modèle lui-même se banalise. Ce qui compte, c’est tout ce qui entoure ce modèle : l’infrastructure de formulation des consignes, la qualité d’intégration, la gestion des erreurs quand ça déraille. Ces détails d’implémentation apparaissent rarement sur les pages de comparaison de fonctionnalités.

simonw, créateur de Datasette et voix respectée sur les outils d’IA, a capturé cette réalité dans une discussion sur Hacker News à propos de l’évaluation de l’IA:

“If you try to fix problems by switching from eg Gemini 2.5 Flash to OpenAI o3 but you don’t have any evals in place how will you tell if the model switch actually helped?”

Le modèle compte moins que votre capacité à mesurer ce que n’importe quel modèle fait pour vous. Les fournisseurs qui poussent des noms de modèles comme principal argument de vente cachent souvent une infrastructure faible derrière une crédibilité empruntée.

Les signaux d’alerte que révèlent les présentations des fournisseurs

Observez comment les fournisseurs répondent à des questions précises sur les limites, et vous apprenez tout ce que vous devez savoir sur la relation dans laquelle vous entreriez.

Le virage vers des démos préparées. Vous décrivez votre cas d’usage. Ils montrent une autre démo. Ça arrive tout le temps. La démo préparée marche parce qu’elle a été conçue pour marcher. Votre cas d’usage n’a pas été conçu. Ce virage vous dit qu’ils ne peuvent pas gérer votre scénario — ou qu’ils choisissent de ne pas vous montrer leur outil en difficulté.

Le flou sur les données d’entraînement. D’où viennent les données qui ont servi à entraîner leurs modèles personnalisés ? Beaucoup de fournisseurs ne peuvent pas ou ne veulent pas répondre. Ça compte à la fois pour la qualité et pour le risque juridique. Des modèles entraînés sur des données aspirées, d’une provenance incertaine, portent un risque de droits d’auteur qui pourrait finir sur votre bureau plus tard.

L’absence d’histoires d’échec. Chaque outil échoue parfois. Les fournisseurs qui prétendent le contraire mentent, ou n’ont jamais été testés à grande échelle. Les fournisseurs honnêtes décrivent où leurs outils peinent. Ils connaissent leurs limites parce qu’ils ont vu de vrais clients se heurter à ces limites. Cette honnêteté signale un partenariat plutôt qu’un numéro de vente.

Des fonctionnalités futures vendues comme du présent. “Cette capacité est sur notre feuille de route” se traduit par “nous n’avons pas cette capacité.” Évaluez ce qui existe, pas ce qui pourrait exister. Les feuilles de route changent. Les financements se tarissent. Les priorités bougent. Des fonctionnalités promises pour le T3 n’arrivent parfois jamais.

Mener des évaluations qui révèlent la vérité

Les démos montrent les meilleurs cas. Une vraie évaluation demande de construire des tests que l’outil choisi pourrait rater, puis d’observer de près comment il échoue.

Commencez par des cas limites issus de votre travail réel. Pas des échantillons “représentatifs”. Des cas limites. Les demandes bizarres qui embrouillent votre équipe humaine. Les formats de données sales que vous recevez vraiment. Les questions inhabituelles que les clients posent parfois. Les outils d’IA qui gèrent bien les cas typiques mais s’effondrent sur les cas limites vont générer des escalades et de la frustration une fois déployés.

Nathan Lambert, chercheur qui écrit beaucoup sur les capacités des modèles d’IA, a décrit sa propre expérience de bascule:

“Claude 3.5 just does what I need a few percentage points more reliably than ChatGPT”

Quelques points de pourcentage. C’est comme ça que les vraies différences se manifestent. Pas des écarts de capacité spectaculaires que n’importe qui verrait en démo, mais de petits écarts de fiabilité qui, multipliés par des milliers d’utilisations, deviennent des impacts majeurs sur les façons de travailler. Vous ne verrez pas ces écarts sans des tests soutenus sur vos tâches réelles.

Structurez votre évaluation pour faire ressortir ces écarts :

Faites passer des consignes identiques d’un fournisseur à l’autre. Même entrée, outils différents, sorties mesurées. Faites-le à grande échelle. Pas cinq tests. Cinquante tests minimum. Cent si la décision compte vraiment.

Testez dans la durée. Un outil qui marche parfaitement le lundi peut peiner le jeudi si le fournisseur gère des problèmes de capacité ou déploie des mises à jour. Une évaluation d’un jour vous parle d’un jour. Une évaluation de deux semaines commence à révéler des motifs.

Impliquez les personnes qui utiliseront réellement l’outil. Les évaluateurs techniques testent des choses différentes des utilisateurs au quotidien. Les deux perspectives comptent. Quelqu’un qui utilisera cet outil huit heures par jour remarque des frictions que quelqu’un qui teste un après-midi ne verra pas.

Documentez les échecs avec précision. Quand quelque chose se passe mal, capturez exactement ce qui s’est passé. La qualité du support fournisseur se révèle dans la manière dont ils répondent à des échecs documentés. Certains dépannent. D’autres se défaussent.

Le verrouillage fournisseur que personne n’évoque assez tôt

En IA, les coûts de changement s’additionnent plus vite qu’on ne l’imagine.

Vous écrivez des consignes. Vous formez les équipes aux interfaces. Vous intégrez des outils dans des processus. Vous créez de la documentation interne. Vous développez une connaissance tacite de ce qui marche et de ce qu’il faut éviter. Tout ça devient un coût irrécupérable qui rend le changement douloureux — même quand changer serait intelligent.

Une enquête de 2025 auprès de responsables informatiques a constaté que 45 % déclarent que le verrouillage fournisseur a déjà entravé leur capacité à adopter de meilleurs outils. Presque la moitié des organisations se sentent piégées avec des fournisseurs qu’elles ont choisis avant de comprendre toutes les implications de ce choix.

Pensez au verrouillage dès l’évaluation initiale, pas après. Posez des questions inconfortables aux fournisseurs :

Pouvez-vous exporter tous les modèles de consignes et les configurations dans un format portable ? Que deviennent vos données si vous partez ? Y a-t-il des frais de sortie ? Combien de temps prend la suppression des données ? Est-ce qu’ils utilisent vos données pour entraîner des modèles dont des concurrents pourraient bénéficier ?

Les fournisseurs qui répondent à ces questions clairement et favorablement sont des fournisseurs qui pensent que la qualité de leur produit — pas vos coûts de sortie — vous gardera comme client. Cette confiance est en elle-même un signal à noter.

Les décisions d’architecture prises pendant la mise en œuvre influencent aussi le verrouillage. Construire des abstractions entre vos systèmes et l’API du fournisseur crée de la flexibilité pour plus tard. Coder en dur une logique spécifique au fournisseur partout dans votre base de code crée une dépendance de plus en plus difficile à briser avec le temps.

Un certain verrouillage est acceptable. On ne peut pas obtenir une intégration profonde sans un minimum d’engagement. Mais connaître votre niveau de verrouillage et le choisir délibérément, c’est différent de le découvrir par accident quand vous essayez de partir.

Ce que les démonstrations ne peuvent pas vous montrer

La qualité du support.

Pendant la phase commerciale, chaque question reçoit une réponse rapide. Après la signature, les délais de réponse s’allongent parfois de manière spectaculaire. L’équipe de support qui vous vend n’est pas l’équipe qui vous aide, et les incitations changent une fois l’accord conclu.

Demandez des références spécifiquement sur les expériences de support. Pas des clients référents qui ont déployé avec succès et n’ont jamais eu besoin d’aide. Des références qui ont eu des problèmes. Comment ces problèmes ont-ils été gérés ? Combien de temps la résolution a-t-elle pris ? Se sont-ils sentis accompagnés, ou comme des tickets dans une file ?

La capacité de votre organisation à absorber le changement compte aussi. Un outil que votre équipe n’utilisera pas échoue, quelle que soit sa puissance. Comprendre la préparation de votre organisation à une nouvelle technologie, les exigences de formation et la tolérance au changement devrait influencer le choix du fournisseur autant que la comparaison des fonctionnalités.

Et peut-être le plus important : le processus d’évaluation lui-même compte. La façon dont les fournisseurs se comportent pendant l’évaluation prédit la façon dont ils se comporteront comme partenaires. Des tactiques de pression pendant la vente suggèrent des tactiques de pression au renouvellement. La transparence sur les limites suggère la transparence sur les problèmes. La relation que vous vivez pendant l’évaluation est souvent la meilleure version de la relation que vous aurez jamais avec ce fournisseur.

La question qui remplace toutes les listes de contrôle

Les cadres d’évaluation apportent de la structure. La structure aide. Mais chaque cadre finit par produire un score pondéré qui masque l’appel au jugement qu’aucun système de notation ne peut faire à votre place.

Quand des praticiens décrivent leurs meilleures décisions de fournisseurs d’IA, ils parlent rarement de cadres d’évaluation. Ils parlent d’adéquation. L’outil qui a marché, c’est l’outil qui correspondait à la manière dont leur équipe travaille réellement, qui adressait leurs problèmes spécifiques, qui semblait juste à l’usage quotidien une fois que l’éclat de la démo avait disparu.

La question qui compte : “Au regard de tout ce que nous avons appris pendant l’évaluation, croyons-nous que ce fournisseur va nous aider à réussir, et lui faisons-nous assez confiance pour bâtir une dépendance à son infrastructure ?”

La confiance est difficile à transformer en score sur un tableur. Elle émerge quand on observe comment les gens se comportent quand ça devient difficile. Les meilleures évaluations créent intentionnellement de petites difficultés, puis observent attentivement.

Certains fournisseurs n’aimeront pas cette approche. Ces fournisseurs vous disent quelque chose d’important.