Matrice de sélection des fournisseurs et modèles d'IA
Un cadre de décision complet pour évaluer les fournisseurs d'IA selon 8 dimensions. Du schéma de l'erreur à 2 M$ aux 25 questions de RFP, 12 signaux d'alerte et une véritable étude de cas — tout ce qu'il faut pour choisir le bon fournisseur d'IA et éviter une dépendance coûteuse.
Pourquoi la sélection de fournisseurs d'IA échoue — le schéma de l'erreur à 2 M$
Une fintech européenne a choisi son fournisseur de LLM sur la base d'une démonstration de 45 minutes et d'un billet de blog vantant un benchmark. Dix-huit mois plus tard, elle a dépensé 2,1 M$ pour en migrer. Le modèle avait été déprécié, son équipe conformité a rejeté l'accord de traitement des données du fournisseur, et le coût par token avait triplé par rapport au budget initial. Rien de tout cela n'était imprévisible. Tout aurait été détecté par une évaluation structurée.
Cette histoire n'a rien d'exceptionnel. Au fil d'échanges avec plus de 80 responsables techniques à travers l'Europe, les mêmes modes de défaillance reviennent sans cesse. La cause profonde n'est presque jamais la technologie. C'est le processus — ou son absence.
Risque de dépendance
Les formats de prompt propres au fournisseur, les schémas d'appel de fonctions et les conventions de SDK s'accumulent en une dette de migration invisible. Coût d'ingénierie moyen pour changer de fournisseur de LLM en cours de projet : 50 000 à 200 000 $ et 3 à 6 mois. La plupart des équipes ne découvrent la dépendance qu'à la réception d'un avis de dépréciation ou d'une hausse de tarif.
Battage médiatique vs réalité
Les benchmarks publics (MMLU, GPQA, HumanEval) mesurent une capacité académique générale. Votre charge de production n'est pas générale. Un modèle classé n° 1 sur MMLU peut se classer n° 4 sur votre tâche spécifique d'extraction de contrats ou de support client. Les décisions fondées sur des benchmarks, sans pilote propre au domaine, déçoivent régulièrement.
Les 60 % cachés
La tarification d'API par token ne représente que 40 à 60 % de la dépense réelle d'infrastructure d'IA. Les frais de sortie (egress), le calcul de fine-tuning, les audits de conformité, les montées en gamme de support et l'ingénierie de migration constituent la majorité invisible. Les équipes qui ne budgétisent que les tokens constatent régulièrement des dépassements de coûts de 2 à 3x la deuxième année.
Les trois modes de défaillance, par fréquence
Les 8 dimensions d'évaluation
Toute sélection de fournisseur d'IA devrait être évaluée selon ces huit dimensions. Les pondérations par défaut ci-dessous conviennent à une grande entreprise déployant une infrastructure de LLM dans un contexte européen réglementé — ajustez-les selon vos priorités spécifiques. Un RSSI du secteur de la santé pondérera la sécurité à 35 %. Une startup en course vers le marché pondérera peut-être la performance technique à 40 %.
La somme des pondérations doit faire 100. Les sections 3, 4 et 5 approfondissent les trois dimensions les plus pondérées.
Performance technique
Qualité du modèle sur vos tâches spécifiques, latence, débit et précision en conditions réalistes.
Sécurité et conformité
Certifications (SOC 2, ISO 27001, HIPAA), résidence des données, posture GDPR, alignement sur l'EU AI Act.
Coût total de possession
Tarification d'API, coûts d'entraînement, frais cachés, egress, niveaux de support et coûts d'ingénierie de migration.
Support et SLA
Garanties de disponibilité, délais de réponse du support, CSM dédié, disponibilité d'un palier entreprise.
Intégration et écosystème
Qualité du SDK, compatibilité des frameworks (LangChain, LlamaIndex), intégration CI/CD, documentation.
Feuille de route et stabilité du fournisseur
Trésorerie disponible, cadence de sortie des modèles, politique de dépréciation, alignement sur votre feuille de route produit.
Conformité et adéquation réglementaire
Exigences sectorielles — HIPAA pour la santé, PCI-DSS pour la fintech, catégorisation de risque de l'EU AI Act.
Stratégie de sortie et portabilité
Mécanismes d'export des données, portabilité des modèles, parcours de migration, clauses de sortie contractuelles.
Organigramme du processus d'évaluation
flowchart TD
A([Start: Vendor Evaluation]) --> B[Discovery & Requirements]
B --> B1[Define use case & constraints]
B --> B2[Set must-have criteria]
B --> B3[Identify 15-20 candidate vendors]
B1 & B2 & B3 --> C[Initial Shortlist]
C --> C1[Apply MoSCoW filter]
C1 --> C2{Passes must-haves?}
C2 -- No --> X1[Eliminate]
C2 -- Yes --> D[PoC / Pilot Phase]
D --> D1[Technical benchmark on your data]
D --> D2[Security review & DPA check]
D --> D3[Pricing & TCO modelling]
D1 & D2 & D3 --> E[Weighted Scoring Matrix]
E --> E1[Score top 3 vendors]
E1 --> F[Commercial Negotiation]
F --> F1[SLA terms]
F --> F2[Data processing agreement]
F --> F3[Exit clause negotiation]
F1 & F2 & F3 --> G([Vendor Selected])
style A fill:#1a1a2e,stroke:#7c3aed,color:#e2e8f0
style B fill:#1e293b,stroke:#475569,color:#e2e8f0
style B1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style C1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C2 fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style D fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style D1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style E1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style F1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style X1 fill:#1f0d0d,stroke:#ef4444,color:#e2e8f0
style G fill:#0d1f12,stroke:#22c55e,color:#e2e8f0Dimension 1 en profondeur : Performance technique
Pondération par défaut : 25 %
L'évaluation de la performance technique comporte trois volets : la méthodologie de benchmark, la mesure de la latence et du débit, et les tests de précision sur votre domaine spécifique. Les trois doivent être réalisés avant tout engagement.
Méthodologie de benchmark
Les benchmarks publics sont un point de départ, pas un critère de décision. MMLU teste des connaissances académiques larges. HumanEval teste la génération de code Python. Aucun ne teste votre tâche spécifique. Constituez un jeu d'évaluation propre au domaine, à partir de données de production réelles, avant toute comparaison de fournisseurs.
Constitution du jeu d'évaluation
- 100 à 500 exemples issus de données de production réelles
- Inclure les cas limites et les modes de défaillance connus
- Couvrir les difficultés faible, moyenne et élevée
- Inclure des prompts adverses pertinents pour votre cas d'usage
- Créer des étiquettes de vérité terrain avec des annotateurs humains
Métriques de précision par type de tâche
- Extraction : score F1 sur la précision entité/valeur
- Classification : précision, rappel, F1 par classe
- Génération : évaluation humaine + ROUGE/BERTScore
- Raisonnement : Pass@1 et Pass@3 sur des tâches de logique
- Taux d'hallucination : vérification des affirmations factuelles
Métriques de latence et de débit
N'évaluez jamais la latence avec une seule requête. Mesurez sous une charge concurrente réaliste, avec votre profil de trafic de production attendu. La latence des démonstrations de fournisseurs correspond toujours au meilleur cas, requête unique.
| Métrique | Ce qu'elle mesure | Seuil acceptable | Comment la mesurer |
|---|---|---|---|
| Latence P50 | Temps de réponse médian | < 400 ms pour les tâches simples | Test de charge à 1x le volume de prod |
| Latence P95 | 95e centile — le plancher d'expérience utilisateur | < 1 200 ms pour les tâches complexes | Test de charge à 2x le volume de prod |
| Latence P99 | Pire cas — le pire 1 % des utilisateurs | < 3 000 ms (plafond du SLA) | Test de charge à 3x le volume de prod |
| Time to First Token | Vitesse perçue pour les réponses en streaming | < 300 ms au P95 | Mesurer le TTFT séparément de la latence totale |
| Tokens/seconde | Débit de génération par requête | > 40 tokens/s pour une UX en temps réel | Nombre de tokens / temps de génération total |
| Capacité de limite de débit | Maximum de requêtes / tokens par minute en concurrence | ≥ 2x le volume de production de pointe | Consulter la documentation + tester le comportement en rafale |
Protocole de test de précision
- Exécuter le jeu d'évaluation sur chaque fournisseur avec des prompts identiques
- Enregistrer la précision, la latence et le nombre de tokens par réponse
- Signaler les hallucinations ou échecs de format évidents
- Optimiser les prompts pour chaque fournisseur indépendamment
- Mesurer le gain de précision issu de l'optimisation
- Documenter l'effort d'ingénierie de prompts par fournisseur
- Tester les entrées adverses et les modes de défaillance connus
- Mesurer la performance sur des documents à long contexte
- Tester le comportement aux limites de la fenêtre de contexte
Dimension 2 en profondeur : Sécurité et conformité
Pondération par défaut : 20 %
La sécurité et la conformité sont la cause la plus fréquente d'échec d'une sélection de fournisseur d'IA après engagement. Ces vérifications doivent intervenir avant le PoC, pas après. Un fournisseur incapable de franchir la barre de conformité est éliminé, quelle que soit sa performance technique.
SOC 2 Type II
- Le Type II couvre une période de 6 à 12 mois (et non un instantané ponctuel)
- Demander le rapport complet sous NDA — un résumé est insuffisant
- Vérifier les Trust Services Criteria couverts : Sécurité + Disponibilité au minimum
- Examiner la lettre de direction pour repérer exceptions ou réserves ouvertes
- Vérifier la crédibilité du cabinet d'audit (Big 4 ou spécialiste reconnu)
ISO 27001
- Vérifier que le certificat est en cours de validité et non expiré
- Vérifier le périmètre : couvre-t-il les services spécifiques que vous utiliserez ?
- Les services d'IA hébergés dans le cloud devraient inclure l'Annexe A.17 (continuité d'activité)
- Distinguer la certification ISO 27001 des simples déclarations de conformité
- Associer ISO 27017 (sécurité du cloud) et ISO 27018 (PII dans le cloud) le cas échéant
GDPR et traitement des données
- Un DPA (accord de traitement des données) signé est obligatoire au titre de l'article 28 du GDPR
- Examiner la liste des sous-traitants et les droits d'approbation des changements de sous-traitants
- Confirmer la résidence des données : région UE uniquement, pas de transfert vers les États-Unis sans SCC
- Vérifier le SLA de suppression : à quelle vitesse les données sont-elles supprimées à la résiliation ou sur demande ?
- Confirmer que les prompts et les sorties ne seront jamais utilisés pour l'entraînement du modèle
Alignement sur l'EU AI Act
- Classer votre cas d'usage d'IA selon les catégories de risque de l'EU AI Act
- Les cas d'usage à haut risque (RH, crédit, santé) exigent des évaluations de conformité
- Demander une déclaration du fournisseur sur les obligations des modèles GPAI (transparence, droit d'auteur)
- Vérifier que le fournisseur tient une documentation technique conforme à l'article 53
- Vérifier la position du fournisseur sur les obligations de signalement d'incidents au titre de l'article 62
Options de résidence des données par grand fournisseur
| Fournisseur | Région UE | Les données ne quittent jamais l'UE | Option auto-hébergée | DPA disponible |
|---|---|---|---|---|
| OpenAI (direct) | Non disponible | Non — serveurs aux États-Unis | Non | Oui (Enterprise) |
| OpenAI via Azure | Oui (Suède, France, Pays-Bas) | Oui (PTU) | Non | Oui (Azure DPA) |
| Anthropic (direct) | Non disponible | Non — serveurs aux États-Unis | Non | Oui (Enterprise) |
| Anthropic via Bedrock | Oui (Francfort, Irlande) | Oui | Non | Oui (AWS DPA) |
| Mistral (direct) | Oui (France) | Oui — natif UE | Poids ouverts | Oui (standard) |
| Google Vertex AI | Oui (Belgique, Pays-Bas) | Oui (point de terminaison régional) | Non | Oui (GCP DPA) |
Dimension 3 en profondeur : Coût total de possession
Pondération par défaut : 15 %
La modélisation du TCO pour les fournisseurs d'IA comporte 5 catégories de coûts. La plupart des équipes ne budgétisent que la catégorie 1. Le tableau complet est généralement 2 à 3x supérieur aux estimations initiales. Construisez un modèle sur 3 ans avant tout engagement.
Coûts d'API et d'inférence
- Tarif des tokens d'entrée × volume mensuel projeté de tokens d'entrée
- Tarif des tokens de sortie × volume mensuel projeté de tokens de sortie
- Paliers de remise sur volume — modéliser à chaque tranche tarifaire
- Arbitrage entre usage engagé et paiement à l'usage à votre volume projeté
- Coûts de mise à niveau des limites de débit si vous avez besoin d'un débit dédié
C'est le seul coût que la plupart des équipes incluent dans leur budget.
Entraînement et personnalisation
- Calcul de fine-tuning : coût d'une exécution d'entraînement par époque × nombre d'exécutions attendues
- Inférence de fine-tuning : les modèles affinés coûtent généralement 2 à 4x l'inférence du modèle de base
- Calcul d'évaluation : exécution de votre suite d'évaluation à chaque mise à jour de version du modèle
- Coût de réindexation des embeddings lors d'un changement ou d'une mise à jour des modèles d'embedding
- Préparation et étiquetage des données pour les jeux d'entraînement
Ajoute généralement 20 à 40 % aux coûts d'API pour les équipes utilisant le fine-tuning.
Charges opérationnelles
- Temps d'ingénierie pour l'intégration du SDK, l'ingénierie de prompts et la maintenance
- Outillage de supervision et d'observabilité (LangSmith, Langfuse, Datadog LLM)
- Réplication multi-régions pour des exigences de latence ou de bascule
- Coût d'abonnement au palier de support pour un SLA entreprise
- Revue juridique des changements de conditions d'utilisation (2 à 4x par an)
Souvent 30 à 60 % des coûts d'API pour des déploiements de production matures.
Conformité et sécurité
- Lettres de transition SOC 2 et évaluations par des tiers
- Revue juridique du DPA GDPR et réexamen annuel
- Coûts de tests d'intrusion et d'évaluation de sécurité
- Infrastructure de journalisation d'audit et stockage de rétention
- Surcoût de résidence des données (le cas échéant)
Coûts ponctuels et récurrents annuels totalisant 10 000 à 50 000 $/an pour les secteurs réglementés.
Coûts de migration et de sortie
- Temps d'ingénierie pour réécrire prompts et adaptateurs en cas de changement de fournisseur
- Tests de non-régression sur votre suite d'évaluation après migration
- Coûts de fonctionnement en parallèle pendant la période de migration (2 fournisseurs simultanément)
- Re-création des embeddings de tout le corpus lors d'un changement de fournisseur d'embedding
- Risque d'indisponibilité et impact sur le chiffre d'affaires pendant la fenêtre de migration
La catégorie de coûts la plus sous-estimée. Comptez 3 à 6 mois de migration en cas de changement en cours de projet.
Cadre de décision : développer, acheter ou s'associer
Acheter (API SaaS)
- La rapidité de mise sur le marché est la priorité absolue
- L'équipe manque d'expertise en infrastructure ML
- Le volume représente moins de 5 000 $/mois de coûts d'API
- Le cas d'usage est standard (résumé, classification)
- Dépendance au fournisseur et changements de tarifs à l'échelle
- Les données quittent votre périmètre
- Personnalisation limitée pour les tâches propres au domaine
Développer (auto-héberger de l'open source)
- Le volume dépasse 10 000 $/mois de coûts d'API
- La souveraineté des données est non négociable
- Besoin d'une personnalisation poussée et d'un contrôle du fine-tuning
- L'équipe dispose de capacités en infrastructure ML et DevOps
- Charges opérationnelles élevées et responsabilité de la fiabilité
- Capex GPU ou coûts de location
- Charge de mise à jour des modèles et de correctifs de sécurité sur votre équipe
S'associer (plateforme d'IA cloud)
- Déjà fortement investi dans AWS, Azure ou GCP
- Besoin d'une conformité entreprise avec les accords cloud existants
- Vouloir une variété de modèles sans gérer plusieurs relations fournisseurs
- Besoin d'un outillage géré de fine-tuning et d'évaluation
- Dépendance à la plateforme cloud en plus de la dépendance au modèle
- La disponibilité des modèles est en retard sur les API des fournisseurs directs
- Tarification complexe à plusieurs dimensions (tokens + calcul + stockage)
Le modèle de matrice de notation
Un exemple concret comparant quatre fournisseurs pour un déploiement de LLM en grande entreprise européenne. Notez chaque fournisseur de 1 à 10 par dimension, multipliez par la pondération de la dimension, puis additionnez pour obtenir le total pondéré.
| Dimension | Pondération | Fournisseur AHyperscaler américain | Fournisseur BPlateforme cloud | Fournisseur CNatif UE | Fournisseur DHébergeur open source |
|---|---|---|---|---|---|
| Performance technique | 25% | 9/10(22.5) | 8/10(20.0) | 7/10(17.5) | 6/10(15.0) |
| Sécurité et conformité | 20% | 5/10(10.0) | 8/10(16.0) | 10/10(20.0) | 7/10(14.0) |
| Coût total de possession | 15% | 6/10(9.0) | 7/10(10.5) | 8/10(12.0) | 9/10(13.5) |
| Support et SLA | 10% | 8/10(8.0) | 9/10(9.0) | 6/10(6.0) | 5/10(5.0) |
| Intégration et écosystème | 10% | 9/10(9.0) | 7/10(7.0) | 6/10(6.0) | 5/10(5.0) |
| Feuille de route et stabilité du fournisseur | 10% | 8/10(8.0) | 7/10(7.0) | 9/10(9.0) | 6/10(6.0) |
| Conformité et adéquation réglementaire | 5% | 4/10(2.0) | 7/10(3.5) | 10/10(5.0) | 8/10(4.0) |
| Stratégie de sortie et portabilité | 5% | 4/10(2.0) | 6/10(3.0) | 9/10(4.5) | 8/10(4.0) |
| Total pondéré | 100% | 70.5 | 76.0 | 80.0Gagnant | 66.5 |
Lecture des résultats
Le fournisseur C (natif UE) l'emporte malgré des notes plus faibles en performance technique et en intégration. La forte pondération de la sécurité et conformité (20 %) et de l'adéquation réglementaire (5 %) reflète le contexte d'entreprise. Une startup sans exigences de conformité verrait un gagnant différent.
Règle de départage : Si deux fournisseurs sont à moins de 5 points l'un de l'autre, menez un pilote parallèle de 2 semaines sur un trafic à l'échelle de la production. La matrice resserre le champ — les données réelles sur votre charge tranchent.
Ajustement des pondérations : Avant la notation, demandez à vos parties prenantes clés (CTO, RSSI, DAF, DPO) d'attribuer les pondérations de façon indépendante, puis faites la moyenne ou négociez. Des pondérations différentes produisent des gagnants différents — la conversation sur les pondérations est aussi importante que la notation.
Modèle de RFP : 25 questions à envoyer à chaque fournisseur
Envoyez ces questions à chaque fournisseur envisagé avant de lancer un pilote. Les fournisseurs qui refusent de répondre ou dont les réponses sont vagues révèlent des problèmes. Exigez des réponses écrites — les réponses verbales d'un ingénieur avant-vente n'engagent pas contractuellement.
Performance technique
- 1Quels sont vos objectifs de latence publiés P50, P95 et P99 pour notre taille de requête attendue ?
- 2Quel débit (tokens/seconde) pouvez-vous garantir sur un palier dédié par rapport à une capacité partagée ?
- 3Comment gérez-vous la dégradation de latence en période de pointe ? Délestez-vous la charge ou mettez-vous les requêtes en file d'attente ?
- 4Quelle est votre méthodologie de benchmark de précision du modèle, et comment la validez-vous sur des données propres au domaine ?
- 5Quel est votre processus de communication des mises à jour de modèle susceptibles de changer le comportement des sorties ?
Sécurité et conformité
- 6Pouvez-vous fournir votre rapport SOC 2 Type II actuel sous NDA ?
- 7Détenez-vous un certificat ISO 27001 ? Si oui, quel périmètre couvre-t-il ?
- 8Quelles sont vos politiques de rétention et de suppression des journaux d'appels d'API, des données de prompt et des sorties du modèle ?
- 9Proposez-vous un accord de traitement des données (DPA) conforme à l'article 28 du GDPR ?
- 10Pouvez-vous confirmer par écrit que nos prompts et sorties ne seront jamais utilisés pour l'entraînement du modèle sans consentement explicite ?
- 11Quelles options de résidence des données en UE proposez-vous, et dans quelles régions ?
Tarification et conditions commerciales
- 12Quelle est votre structure tarifaire complète, incluant tokens d'entrée, tokens de sortie, fine-tuning et stockage ?
- 13Des remises sur volume sont-elles disponibles ? À quel palier, et quelle est la structure du contrat d'usage engagé ?
- 14Qu'advient-il de la tarification si nous dépassons notre volume engagé au cours d'un mois donné ?
- 15Existe-t-il des frais d'egress, de transfert de données ou de passerelle d'API non inclus dans la tarification par token ?
- 16Quelles sont les conditions des paliers de support entreprise, et que comprend chacun ?
Opérationnel et intégration
- 17Quel est votre SLA pour la disponibilité de l'API ? Comment calculez-vous et créditez-vous les interruptions ?
- 18Comment gérez-vous les augmentations de limites de débit pour les pics de trafic de production ?
- 19Quelle observabilité et quelle journalisation exposez-vous aux clients (usage de tokens, taux d'erreur, latence) ?
- 20Fournissez-vous un environnement de préproduction/bac à sable de test reflétant le comportement de production ?
- 21Quels SDK prenez-vous officiellement en charge et quel est votre processus de dépréciation des versions de SDK ?
Stratégique et sortie
- 22Quelle est votre feuille de route pour les 12 à 18 prochains mois ? Quelles capacités de modèle sont prévues ?
- 23Quel est le préavis minimum avant la dépréciation d'une version de modèle que nous utilisons en production ?
- 24Comment pouvons-nous exporter les poids de notre modèle affiné ou les couches d'adaptateur si nous décidons de partir ?
- 25Quel est le processus contractuel de résiliation anticipée de l'accord, et quelles garanties de suppression des données s'appliquent ?
- 26Pouvez-vous fournir des références de clients de notre secteur ou ayant des exigences de conformité similaires ?
Comment utiliser ces questions
Signaux d'alerte : 12 signes qu'un fournisseur vous décevra
Ce sont des signaux observables fortement corrélés à des défaillances en production, des problèmes de conformité ou une détérioration de la relation. Les signaux critiques sont des arrêts nets — n'allez pas plus loin. Les signaux élevés exigent une investigation approfondie. Les signaux moyens sont des avertissements à gérer par contrat.
| N° | Signal d'alerte | Gravité | Ce qu'il révèle |
|---|---|---|---|
| 1 | Aucune page de statut publique ni historique de disponibilité | Critique | Le fournisseur a quelque chose à cacher sur sa fiabilité. Tout fournisseur de production sérieux publie l'historique de ses incidents. |
| 2 | Le retrait de l'entraînement exige une revue juridique, pas un simple commutateur d'interface | Critique | Vos prompts propriétaires et données métier sont probablement utilisés pour l'entraînement du modèle. Non négociable pour une entreprise. |
| 3 | Aucun rapport SOC 2 Type II disponible (Type I uniquement) | Critique | Le Type I est un instantané ponctuel, sans preuve de contrôles dans la durée. Le Type II couvre une période d'exploitation de 6 à 12 mois. |
| 4 | La documentation GDPR/DPA exige une escalade commerciale | Critique | Un DPA devrait être en libre-service ou standard. Les exigences d'escalade révèlent soit une immaturité juridique, soit une friction délibérée. |
| 5 | La tarification exige un appel commercial pour les informations du palier de base | Élevé | Une tarification cachée signifie généralement qu'elle varie selon le budget perçu, créant de l'imprévisibilité dans vos prévisions de coûts. |
| 6 | Préavis de dépréciation de modèle inférieur à 6 mois | Élevé | Les systèmes de production ne peuvent migrer en toute sécurité en moins de 6 mois. Les fenêtres de dépréciation courtes anéantissent les plans d'ingénierie. |
| 7 | Aucune option de déploiement auto-hébergé ou VPC pour le palier entreprise | Élevé | Pour les secteurs réglementés ou les données très sensibles, la colocation est souvent inacceptable. Pas d'auto-hébergement = pas d'accord. |
| 8 | Le SDK est un simple wrapper REST sans logique de réessai/backoff | Élevé | Indicateur de maturité d'ingénierie. Les SDK de qualité production gèrent les réessais, le streaming, le backoff sur limite de débit et la classification des erreurs. |
| 9 | Limites de débit non documentées ou modifiées sans préavis | Moyen | Des limites de débit non documentées ou volatiles rendent la planification de capacité impossible et provoquent des défaillances de production inattendues. |
| 10 | Aucun engagement écrit sur la résidence des données | Moyen | Les assurances verbales ne sont pas opposables. Les exigences de résidence des données doivent figurer dans le DPA ou le MSA, pas dans une présentation commerciale. |
| 11 | Entreprise fondée il y a moins de 18 mois sans clients entreprise référençables | Moyen | Les fournisseurs en phase initiale peuvent pivoter, manquer de financement ou être rachetés. Pour une infrastructure d'IA de production, la longévité compte. |
| 12 | Aucune clause de sortie ni garantie de suppression des données dans le contrat standard | Moyen | Qu'advient-il de vos données et de vos modèles affinés à votre départ ? Si le contrat est muet, attendez-vous au pire. |
Arrêt net. Éliminez le fournisseur immédiatement, sauf si vous pouvez obtenir une remédiation contractuelle.
Exigent une investigation détaillée et un plan d'atténuation écrit avant de poursuivre.
Signal d'avertissement. À gérer par des protections contractuelles ou une acceptation documentée du risque.
Processus de présélection : de 20 fournisseurs à 3 finalistes en 2 semaines
La plupart des évaluations de fournisseurs s'enlisent parce que les équipes tentent d'évaluer trop d'options en parallèle. Ce processus de 2 semaines utilise une élimination progressive pour aboutir efficacement à 3 finalistes qualifiés, en réservant l'effort de PoC aux fournisseurs qui le méritent réellement.
Découverte
Ratisser large : 15 à 20 fournisseurs
Filtre MoSCoW
Appliquer les critères incontournables stricts
Recherche documentaire
Approfondir les 6 à 8 fournisseurs restants
Démonstration et appel technique
Appel de 30 min avec chaque fournisseur, poser les 25 questions de RFP
Notation et présélection
Appliquer la matrice de notation pondérée aux 3 à 4 meilleurs fournisseurs
Critères du filtre MoSCoW
Appliquez-les comme des barrières binaires réussite/échec. Tout fournisseur échouant à un Must Have est éliminé immédiatement — sans exception.
Must Have (tout échec = élimination)
- Rapport SOC 2 Type II disponible
- DPA conforme au GDPR disponible
- Résidence des données en UE (si exigée par votre DPO)
- Tarification publiée (pas de paliers de base réservés au commercial)
- SLA de disponibilité ≥ 99,9 % au contrat
- Retrait de l'entraînement en tant que paramètre de compte standard
Should Have (mieux noté, sans éliminer)
- Certificat ISO 27001
- Palier de support entreprise dédié
- Option de déploiement auto-hébergé ou VPC
- Support du fine-tuning et de la personnalisation
- Disponibilité multi-régions
- Portabilité et export des modèles
Étude de cas : comment une banque européenne a choisi son fournisseur de LLM
Processus de 3 mois • 12 fournisseurs évalués • Justification de la décision documentée
Une banque de détail paneuropéenne présente dans 7 pays avait besoin d'un fournisseur de LLM pour la recherche de documents internes et l'analyse de contrats. Avec 52 000 documents, un contenu riche en PII et des exigences réglementaires dans plusieurs juridictions, les enjeux étaient élevés. Voici comment elle a mené l'évaluation.
Découverte et exigences
- Cas d'usage défini : recherche de documents internes et analyse de contrats (52 000 documents)
- Exigences strictes établies : résidence des données en UE, DPA GDPR, SOC 2 Type II, latence P95 < 800 ms
- 12 fournisseurs candidats identifiés à partir de l'étude de marché et des relations cloud existantes
- Filtre MoSCoW appliqué — 5 fournisseurs éliminés immédiatement (pas de résidence UE ou pas de DPA)
PoC et évaluation technique
- PoC parallèle de 4 semaines mené avec 3 finalistes sur un sous-ensemble représentatif de 500 documents
- Mesuré : précision d'extraction sur les clauses IBAN/juridiques, latence P95 à 50 req/s, taux d'hallucination
- Revue de sécurité : examen des rapports SOC 2 Type II, des conditions de DPA, des listes de sous-traitants
- Modélisation du TCO : coût projeté sur 3 ans, incluant API, fine-tuning et paliers de support
Négociation et sélection
- 2 fournisseurs présélectionnés, à moins de 8 points de notation pondérée l'un de l'autre
- Test de charge de 2 semaines au volume de production (pointe à 200 req/s) sur les deux finalistes
- Clause de sortie contractuelle négociée : préavis de 90 jours, suppression complète des données, export des poids du modèle
- Décision finale : le fournisseur natif UE l'a emporté sur la pondération de résidence des données (30 % de la note) et les conditions de sortie
Justification de la décision finale
Le fournisseur retenu était un prestataire dont le siège est en Europe, offrant une résidence des données native en UE. Bien que classé troisième sur les benchmarks bruts de performance du modèle, il s'est classé premier une fois appliquée la pondération de 30 % attribuée à la sécurité et conformité. Les deux fournisseurs techniquement supérieurs avaient tous deux leur siège aux États-Unis, sans garantie de résidence des données limitée à l'UE au moment de l'évaluation.
La clause de sortie contractuelle négociée a donné à la banque le droit d'exporter tous les adaptateurs affinés et de changer de fournisseur avec un préavis de 90 jours. Cette seule clause a réduit la prime de risque de migration dans le modèle de risque de 400 000 € — le coût d'une future ingénierie de migration supposée.
Résultat à 12 mois : La banque a traité 890 000 requêtes documentaires la première année, avec un TCO inférieur de 30 % aux estimations initiales. Le fournisseur a étendu sa couverture UE, ce qui a encore renforcé la relation. Le processus d'évaluation structuré a été adopté comme standard pour toutes les futures sélections de fournisseurs d'IA.
Après-sélection : gestion du fournisseur et suivi des SLA
Choisir un fournisseur, c'est le début, pas la fin. Les relations avec les fournisseurs se dégradent sans gestion active. Les équipes qui obtiennent les meilleurs résultats traitent la gestion des fournisseurs comme une discipline continue, avec une cadence régulière, un suivi documenté des SLA et des chemins d'escalade clairs.
Tableau de bord de suivi des SLA : métriques clés
| Métrique | Objectif de SLA | Mesure | Déclencheur d'escalade |
|---|---|---|---|
| Disponibilité de l'API | ≥ 99,9 % par mois | Supervision synthétique toutes les 60 s depuis la région UE | Incident P1 si l'interruption dépasse 15 minutes |
| Latence P95 | < 800 ms pour les requêtes standard | 95e centile des temps de réponse sur une fenêtre glissante de 24 h | Alerte si le P95 dépasse 1 200 ms pendant plus de 5 minutes |
| Taux d'erreur | < 0,5 % d'erreurs 5xx par heure | Taux d'erreur sur tous les points de terminaison d'API, hors erreurs client | Escalade vers le fournisseur si > 1 % pendant deux heures consécutives |
| Marge de limite de débit | ≥ 30 % de capacité disponible par rapport aux limites contractuelles | Pic d'usage quotidien par rapport au plafond contractuel de limite de débit | Demander une hausse de limite quand la marge est < 20 % pendant 5 jours consécutifs |
| Coût pour 1 000 appels d'API | À moins de 10 % de la base modélisée | Moyenne glissante sur 7 jours par rapport au modèle de TCO initial | Réexaminer et renégocier si durablement > 20 % au-dessus de la base |
| Revue d'activité trimestrielle | Tenue tous les 90 jours | Mise à jour de la feuille de route fournisseur, revue des incidents, revue tarifaire, rapport de conformité aux SLA | Déclencher une revue de performance formelle si un SLA critique n'est pas respecté |
Cadence de gestion du fournisseur
Checklist de renouvellement de contrat
Commencez 3 mois avant le renouvellement du contrat. C'est votre fenêtre de levier.
- Réexécuter la matrice de notation pondérée avec les données de marché de l'année en cours
- Demander un rapport SOC 2 Type II à jour
- Évaluer 2 à 3 fournisseurs alternatifs pour établir une position de négociation
- Examiner les avis de dépréciation du fournisseur — des modèles dont vous dépendez sont-ils menacés ?
- Calculer le TCO complet des 12 derniers mois par rapport au modèle initial
- Examiner le DPA pour repérer tout changement de conditions au cours des 12 derniers mois
- Négocier : engagements de volume pour une meilleure tarification, un meilleur SLA, des préavis étendus
- Mettre à jour la clause de sortie : s'assurer que le SLA de suppression des données et les droits de portabilité des modèles sont à jour
Stratégie d'abstraction multi-fournisseurs
Le moyen le plus efficace de réduire la dépendance à un fournisseur est d'abstraire vos appels de LLM derrière une couche de routage dès le premier jour. C'est 1 à 3 jours d'investissement d'ingénierie qui éliminent des mois de risque de migration.
Options de routage open source
- LiteLLM — API unifiée pour plus de 100 fournisseurs
- Portkey — passerelle avec observabilité et basculements
- OpenRouter — routage de place de marché avec optimisation des coûts
- Couche d'abstraction personnalisée avec interface fournisseur
Ce que l'abstraction vous apporte
- Changer de fournisseur principal sans réécrire le code applicatif
- Exécuter automatiquement un fournisseur de secours en cas de limite de débit ou d'interruption
- Tester deux fournisseurs en A/B sur le trafic réel
- Router selon coût et qualité dynamiquement au moment de la requête
Besoin d'aide pour mener votre évaluation de fournisseurs d'IA ?
J'aide les CTO et responsables techniques à mener des évaluations de fournisseurs structurées — de la définition des exigences à la conception du PoC, la notation et la négociation du contrat. Vous obtenez un cadre objectif et quelqu'un qui a vu les mêmes erreurs commises 50 fois.
Ressources associées
Guide d'optimisation des coûts de LLM
Réduisez les coûts d'inférence de LLM de 60 à 90 % grâce au routage de modèles, à la mise en cache et au fine-tuning
Playbook de sécurité IA et de red-teaming
Protégez vos systèmes d'IA contre l'injection de prompt et les attaques de modèles
Guide de conformité à l'EU AI Act
Naviguez dans les exigences réglementaires pour les systèmes d'IA en Europe