Évaluer un fournisseur d'IA hors capacités

Quand plusieurs fournisseurs proposent des modèles équivalents, le choix se joue sur les conditions d'exploitation, qui ne figurent dans aucune comparaison publique. C'est le déplacement à intégrer dans les processus d'achat.

Les appels d'offres que je relis portent encore massivement sur les capacités : taille de fenêtre, scores publiés, langues supportées. Ces critères ne départagent plus grand-chose, et ils orientent vers le fournisseur qui communique le mieux plutôt que vers celui qui tiendra.

Quatre critères décident réellement, et aucun ne demande de compétence technique particulière pour être évalué.

Le délai entre l'annonce du retrait d'une version et son arrêt effectif détermine votre charge d'exploitation plus sûrement que toute caractéristique technique. C'est le critère que je place en premier.

Un système en production est réglé sur un comportement. Le retrait d'une version impose une migration : nouveau modèle, revérification du jeu de tests, ajustement des seuils, bascule progressive. Avec six mois de préavis, cela s'intègre dans un cycle normal. Avec trois semaines, cela devient une urgence.

La question à poser tient en une phrase : combien de temps une version reste-t-elle disponible après l'annonce de son remplacement ? La réponse est parfois écrite, souvent pas, et l'absence de réponse est une réponse.

Le second aspect est l'existence de versions figées. Un fournisseur qui propose d'épingler une version datée protège de la dérive silencieuse décrite dans le jour où le modèle a changé sans prévenir.

Le tarif annoncé ne dit rien tant qu'il n'est pas rapporté à votre rapport entre jetons envoyés et jetons produits. Deux fournisseurs au même prix affiché peuvent différer d'un facteur deux sur votre usage.

Les jetons d'entrée et de sortie ne coûtent pas le même prix, et le rapport entre les deux varie fortement d'un fournisseur à l'autre. Un système documentaire envoie beaucoup et produit peu ; un système de rédaction fait l'inverse.

Le calcul prend une heure. On relève le nombre moyen de jetons envoyés et produits par requête sur un mois réel, on applique les grilles des fournisseurs candidats, et on compare.

Ce calcul doit être refait après toute campagne de réduction de contexte, parce qu'elle change précisément le rapport qui décide, la démarche décrite dans réduire de moitié le contexte envoyé.

Consulter l'historique d'incidents publié plutôt que l'engagement contractuel donne une image bien plus fidèle. La plupart des fournisseurs publient une page d'état avec un historique.

Ce qu'il faut y regarder n'est pas le nombre d'incidents mais leur durée et leur communication. Un incident de vingt minutes annoncé en temps réel est bien moins gênant qu'un incident d'une heure découvert par les utilisateurs.

Le second point est la dégradation partielle. Un service qui ralentit sans tomber ne compte pas comme indisponible et provoque pourtant l'abandon des utilisateurs, le mécanisme décrit dans la latence devient un critère de conception.

D'où l'intérêt d'une couche d'abstraction avec un second fournisseur configuré : le basculement en cas d'incident devient un changement de configuration plutôt qu'une indisponibilité.

Un préavis de retrait, un engagement de documentation, et une clause de localisation suffisent à couvrir l'essentiel du risque d'exploitation. Le reste relève de la négociation ordinaire.

Le préavis de retrait est le point le plus concret et le plus souvent absent. Une durée chiffrée vaut mieux qu'un engagement de moyens.

L'engagement de documentation évite de reconstituer un dossier des années plus tard sur une page qui a changé.

La clause de localisation détermine ce qu'on a le droit d'envoyer, et elle doit être vérifiable, un engagement contractuel sur une région donnée, pas une déclaration d'intention.

Ces trois lignes ont plus d'effet sur trois ans d'exploitation que n'importe quelle négociation tarifaire, parce qu'elles portent sur ce qui coûte réellement : les migrations subies et les usages qu'on doit abandonner.