Plateforme d’agents IA : achat, SLA et risques fournisseur

Procurement pour agents : vous n’achetez pas une API, vous achetez un risque

L’achat d’IA se fait souvent comme l’achat d’une API “classique”.

Erreur.

Un agent outillé :

• lit des données,
• déclenche des actions,
• et laisse des traces.

Donc l’impact est :

• technique,
• juridique,
• réputationnel,
• et financier.

Avant d’acheter : clarifier “agent” (sinon vous achetez une démo)

Dans les appels d’offres, “agent” peut vouloir dire :

• un chatbot avec tool calling,
• un workflow avec étapes,
• un multi-agents,
• ou un système complet avec HITL, traces, evals.

Donc la première exigence procurement est un glossaire :

• quels canaux (mail, chat, voix) ?
• quelles actions (lecture seule, écriture SI, paiement) ?
• quelles données (PII, docs) ?
• quels niveaux d’autonomie (assist vs autopilot) ?

Si ces réponses ne sont pas écrites, vous achetez de l’ambiguïté. Et l’ambiguïté finit toujours en dépassement de budget.

La question procurement n’est pas :

“Quel modèle est le plus intelligent ?”

La question procurement est :

“Quel système est gouvernable quand ça casse ?”

SLA vs SLO : ce que vous devez demander (et ce que vous devez mesurer)

SLA (contractuel)

Le SLA est une promesse contractuelle :

• uptime,
• temps de réponse support,
• pénalités.

SLO (opérationnel)

Le SLO est votre objectif produit :

• latence P95/P99,
• coût par tâche,
• taux d’erreur,
• taux d’escalade.

Un fournisseur peut avoir un SLA “OK” et vous livrer une expérience instable si vous ne fixez pas vos SLOs et si vous ne tracez pas.

Voir : /blog/agents-ia/observabilite/observabilite-agents-traces-evals-2026.

Risque “verrouillage” : comment éviter de devenir otage

Les agents créent du lock-in par trois chemins :

1. Le modèle (API/provider)
2. Les outils (schemas, permissions, connecteurs)
3. Les traces (observabilité, evals)

Le modèle, c’est le plus visible. Les outils et les traces, c’est ce qui vous empêche de migrer.

Donc procurement doit exiger :

• export des logs/traces,
• formats ouverts (JSON, OTel quand possible),
• séparation entre orchestration et provider,
• et documentation claire des outils.

Sinon, vous pourrez “changer de modèle”… mais pas changer de système.

Logs, rétention, et “où vont mes données ?”

Procurement doit obtenir des réponses claires :

• où sont stockées les données (région) ?
• que loggue le fournisseur (prompts, outputs, tool calls) ?
• combien de temps ?
• qui y accède ?
• et comment on supprime ?

Si vous ne savez pas ça, vous ne pouvez pas :

• respecter le RGPD,
• auditer,
• ou gérer un incident.

La CNIL publie des recommandations IA/RGPD et une checklist utile pour cadrer minimisation, finalité, sécurité et gouvernance.¹²

Traduction procurement :

• la donnée “utile” doit être minimisée,
• les logs doivent être gouvernés,
• et la rétention doit être définie.

Sécurité des outils : la surface d’attaque qui compte vraiment

Dans un agent, le danger n’est pas le texte. C’est l’outil.

Un agent qui peut :

• écrire dans un CRM,
• déclencher un paiement,
• ou envoyer un email…

… doit être considéré comme un système à privilèges.

Procurement doit demander :

• allowlist d’outils,
• permissions minimales,
• audit des tool calls,
• sandbox,
• secrets management,
• et protections contre prompt injection.

Le site MCP publie des “security best practices” sur les risques et recommandations autour de l’écosystème d’outils (supply chain, permissions, isolation).³

Voir aussi : /blog/agents-ia/securite/securite-agents-prompt-injection-dlp-secrets.

Risque fournisseur : quotas, suspensions, et le piège des usages “grand public”

On arrive au sujet qui fait mal.

Beaucoup d’équipes bricolent :

• elles se connectent via un produit grand public,
• elles utilisent des logins ou des rate limits non destinés à être “revendus”,
• et elles pensent que ça tiendra.

Puis elles scale. Et elles découvrent :

• le rate limit,
• la détection d’abus,
• ou la suspension.

Exemple : Claude.ai (grand public) vs API

Anthropic précise dans sa politique que vous ne pouvez pas réutiliser les rate limits / login de Claude.ai pour fournir un service à des tiers : il faut passer par l’authentification API (API keys).⁴

Ce point n’est pas “une nuance”. C’est une frontière.

Scénario incident : “clés suspendues” (et comment ne pas découvrir ça en prod)

Le risque n’est pas théorique :

• une clé peut être suspendue,
• un quota peut être abaissé,
• un compte peut être flaggé,
• et votre produit peut se retrouver aveugle.

Procurement doit demander :

• que se passe-t-il en cas de suspension (process, délais, support) ?
• existe-t-il un mode dégradé (fallback) ?
• comment monitorer quotas/429 ?

Et côté architecture, vous devez prévoir :

• multi-keys (par environnement),
• séparation dev/staging/prod,
• rotation,
• et circuit breakers.

Sinon, votre agent est un single point of failure juridique et technique.

Le cas des harness type OpenClaw (Claude Code / Gemini / Codex)

OpenClaw documente des “ACP sessions” qui pilotent des harness externes (Claude Code, Codex, Gemini CLI) depuis OpenClaw.⁵

C’est puissant pour automatiser des tâches. Mais ça introduit un risque procurement :

• si vous routez des usages “produit” via un abonnement/tooling non prévu pour ça,
• vous pouvez vous exposer à des sanctions, un blocage, ou une coupure.

On peut le dire simplement :

Multi-provider : une exigence de résilience (pas un caprice d’architecte)

Un agent en prod dépend de :

• un modèle,
• des outils,
• des OCR/STT/TTS,
• des bases,
• et du réseau.

Donc vous devez prévoir :

• fallback modèle,
• fallback OCR,
• et mode dégradé.

Le multi-provider n’est pas “pour faire joli”. C’est pour survivre à :

• une panne,
• un quota,
• ou une suspension.

Et si vous ne pouvez pas faire multi-provider, vous devez au minimum :

• avoir une stratégie de dégradation,
• et un plan de continuité.

Rétention & ZDR : les options qui changent la gouvernance

Les fournisseurs ne proposent pas tous le même niveau de contrôle sur :

• la rétention des données,
• l’usage pour entraînement,
• et les capacités de tracing.

Par exemple, OpenAI note que certaines options (comme Zero Data Retention) peuvent impacter les capacités de tracing (certaines features peuvent ne pas être disponibles).⁶

Traduction procurement :

• si vous exigez ZDR, vous devez vérifier l’impact sur l’observabilité,
• et prévoir une observabilité “chez vous” (OTel, logs outillés).

Sinon, vous risquez un paradoxe : “on a tout bloqué pour la conformité” → “on ne peut plus débugger”.

Clauses à demander (checklist procurement)

Contrat / juridique

• SLA + pénalités
• DPA (traitement données)
• localisation des données
• sous-traitants (subprocessors)
• conditions de résiliation + export
• clauses de changement (modèles, features)
• usage autorisé (ToS)

Sécurité

• chiffrement au repos/en transit
• gestion secrets (KMS, rotation)
• logs d’accès
• pentest / certifications (si applicable)
• isolation tenant
• contrôle outils (allowlist, permissions)

Produit / ops

• quotas/rate limits explicites
• métriques et observabilité (traces)
• rétention logs configurable
• ZDR / options de rétention (si dispo)
• support incident (RCA, délais)

Scorecard : comparer deux fournisseurs sans se faire hypnotiser

Pour éviter le concours de démos, vous pouvez utiliser une scorecard simple :

L’objectif n’est pas de faire du tableur pour le plaisir. L’objectif est de rendre la discussion factuelle.

Multi-agents / workflow : ce que procurement doit exiger en “capabilities”

Les vendors vont vous dire “oui, on fait des agents”. Très bien.

Demandez alors :

• avez-vous un runtime/workflow (graph) ou juste du “loop” ?
• avez-vous de la persistance d’état (reprise après incident) ?
• avez-vous des budgets (tokens/tools/time) codables ?
• avez-vous du HITL intégré (approval nodes, review queues) ?
• pouvez-vous exporter les traces (OTel/JSON) ?
• comment versionnez-vous prompts/outils ?

Si les réponses sont vagues, vous allez payer en prod.

Cas d’usage : assureur, marketing, SDR (ce que procurement doit anticiper)

Assureur

• données sensibles,
• obligations d’audit,
• actions SI critiques.

Donc procurement doit prioriser :

• logs/rétention/contrôle,
• HITL,
• et sécurité outils.

Marketing (faceless / content ops)

• risque plateforme (ban),
• risque spam SEO,
• risques droits/claims.

Procurement doit s’assurer :

• que la stack permet QA/humain,
• et que l’automatisation respecte les policies.

SDR / prospection

• deliverability,
• conformité,
• réputation domaine.

Procurement doit exiger :

• throttling,
• logging,
• opt-out strict,
• et audit.

Le piège “agent plateforme” : quand vous payez pour des features que vous n’utilisez pas

Certaines plateformes vous vendent :

• un builder,
• un runtime,
• de l’observabilité,
• de l’évaluation,
• du hosting.

Super.

Mais procurement doit vérifier :

• quelles features sont réellement utilisées,
• ce qui est “included” vs “add-on”,
• et ce qui est indispensable pour la prod.

Sinon, vous payez une plateforme complète… et vous ne gardez que l’API.

Stratégie “exit plan” : décider comment vous partez avant d’entrer

Procurement “senior” pose une question qui rend tout le monde nerveux :

“Si on doit partir dans 12 mois, on fait comment ?”

Un exit plan concret inclut :

• export des prompts/versioning,
• export des traces (au minimum trace_id, tool calls, coûts, latences),
• export des datasets d’évaluation,
• export des mémoires (RAG index, sources),
• et un mapping d’outils (schemas, endpoints, permissions).

Le but n’est pas de partir. Le but est de ne pas être prisonnier.

Et le simple fait d’avoir un exit plan vous force à construire proprement.

Dernier conseil : “faire simple” est une stratégie de risque

Les plateformes d’agents adorent montrer :

• des flows complexes,
• des multi-agents qui débattent,
• des démos multimodales.

Procurement doit ramener le sujet à la réalité :

• quelles 3 actions business sont réellement automatisées ?
• quels garde-fous existent ?
• quels incidents ont été vécus ?
• quels runbooks sont fournis ?

Un système simple, observable, idempotent, avec HITL, bat souvent un système “wow” qui casse au premier 429.

Et si quelqu’un vous dit “on n’aura pas besoin de tout ça”, c’est souvent vrai… jusqu’au premier incident. Le procurement n’achète pas une démo : il achète le droit de dormir.

Méthode : choisir sans se tromper (et sans refaire en 3 mois)

1

Écrivez 3 workflows critiques

Pas “un agent”. Trois workflows : documents assurance, SDR, marketing content ops. Listez outils, données, actions.

2

Classez les actions par risque

Zones vertes (auto), oranges (sampling), rouges (HITL). Sans ça, vous achetez à l’aveugle.

3

Testez sur des traces réelles

Pas sur des démos. Sur des cas et des erreurs. Vérifiez logs, retry, idempotence, mode dégradé.

4

Validez ToS + licences + quotas

Vérifiez que votre usage (multi-tenant, volume, revente) est autorisé. Anthropic a une politique explicite côté Claude.ai vs API.⁴

5

Négociez la gouvernance, pas “le modèle”

SLA, rétention, observabilité, sécurité outils, support incident. C’est là que se joue la prod.

FAQ

Questions frequentes

Pourquoi parler ToS en technique ?+

Parce qu’un blocage d’accès est un incident produit. Les ToS et l’usage autorisé déterminent votre risque de suspension. En agentic, ce risque est réel, surtout quand on scale.

Multi-provider : obligatoire ?+

Pas toujours, mais fortement recommandé si l’agent est critique. Sinon, au minimum : plan de continuité et mode dégradé.

Quelle est la question #1 à poser à un fournisseur ?+

“Comment tracez-vous les tool calls et comment gérez-vous la rétention/suppression ?” Sans traces, vous ne débuggez pas. Sans rétention, vous ne gouvernez pas.

Le plus gros piège ?+

Confondre un produit grand public avec une API contractuelle. Anthropic précise que les rate limits/logins Claude.ai ne peuvent pas être réutilisés pour fournir un service : il faut passer par l’API.⁴

Sources et references

1. [1]CNIL, “Développement des systèmes d’IA : recommandations pour respecter le RGPD”.
2. [2]CNIL (PDF), “Développement des systèmes d’IA : que faut-il vérifier ?” (checklist).
3. [3]Model Context Protocol (MCP), “Security best practices”.
4. [4]Anthropic, “Claude.ai policy” (no reusing Claude.ai login/rate limits; use API keys).
5. [5]OpenClaw docs, “ACP: Agents”.
6. [6]OpenAI Agents SDK (Python), “Tracing” (note ZDR limitations).