API IA : le projet de rachat de Stainless par Anthropic change la donne

Ce que les médias ont réellement révélé mardi

12 mai 2026 — The Information a révélé l’information, en citant une personne au fait du dossier. Montant envisagé : au moins $300 millions, dont une partie serait probablement réglée en actions Anthropic. Selon les sources, il s’agirait de la première acquisition d’Anthropic — un signal à prendre au sérieux. Le groupe ne cherche pas à acheter une équipe spécialisée dans les modèles ni un laboratoire de recherche. Il rachète la plomberie logicielle.

La valorisation dit tout autant que le prix. En décembre 2024, Stainless a levé une série A sur la base d’une valorisation de $150M. Cinq mois plus tard, Anthropic propose environ 2x ce montant. Le jour même où les discussions ont été révélées, Bloomberg indiquait qu’Anthropic visait une valorisation de $900B lors d’un nouveau tour de $30B+. Les négociations sont avancées, mais rien n’est signé. Les conditions peuvent encore évoluer.

Ce que construit réellement Stainless, en un paragraphe

Stainless est un compilateur propulsé par l’IA : à partir d’une spécification OpenAPI, il produit des SDK prêts pour la production en TypeScript, Python, Go, Kotlin, Java, Ruby, PHP et C#. Terraform est en bêta, tandis que Rust et Swift figurent sur la feuille de route. Les SDK générés intègrent déjà les retries, le streaming, la pagination et une gestion typée des erreurs. Pour une startup de quatre ans, la liste des clients est hors norme : OpenAI, Anthropic, Google, Cloudflare, Meta, Runway, Groq, Cerebras, Lithic et Modern Treasury. Ensemble, ces bibliothèques cumulent plusieurs dizaines de millions de téléchargements par semaine. L’organisation github.com/stainless-sdks en maintient publiquement une partie ; le reste se trouve dans les dépôts des clients, où Stainless pousse directement ses commits.

Les scénarios crédibles pour OpenAI et Google

Il y en a quatre. Chacun pose un problème différent.

Scénario A — ils restent chez Stainless dans le cadre de leur contrat. C’est l’option la moins chère à court terme, mais elle devient intenable au renouvellement. Chaque nouvelle version de SDK passerait par un prestataire détenu par le principal concurrent, auquel il faudrait faire confiance pour ne pas examiner les spécifications OpenAPI désormais compilées par sa filiale. Je ne vois pas OpenAI renouveler ce contrat. Google pourrait patienter un trimestre, le temps de mettre une solution de remplacement sur pied.

Scénario B — ils créent un fork du générateur. La valeur de Stainless réside dans la propriété intellectuelle du compilateur, pas dans son résultat. Créer un fork du dernier SDK généré ne demande qu’un git clone. Reprendre le compilateur qui devra produire les SDK des dix prochaines années exige en revanche plusieurs trimestres d’ingénierie, avec une échéance impérative : être prêt avant la prochaine évolution majeure de l’API. C’est difficile et coûteux, mais défendable. Je miserais sur cette option pour OpenAI dans les six mois.

Scénario C — ils reconstruisent en interne toute la génération des SDK. OpenAI dispose des effectifs nécessaires. Il faut alors s’attendre à 6–12 mois de turbulences : changements incompatibles, langues non prises en charge et longue traîne de cas limites que Stainless avait déjà résolus. Les SDK Kotlin et Go sont moins étoffés que leurs équivalents Python et TypeScript ; ce sont eux qui régresseront en premier.

Scénario D — statu quo discret pendant douze mois, le temps qu’Anthropic prouve qu’il ne démantèlera pas l’équipe et ne retardera pas les versions destinées à ses concurrents. C’est possible, mais impossible d’en faire un pari raisonnable. Une dépendance de production ne se conçoit pas autour du bon vouloir d’un concurrent.

Conséquence opérationnelle : figez dès aujourd’hui les versions de vos SDK. Recensez les bibliothèques officielles dont vous dépendez. Identifiez aussi, parmi celles déployées en production, les langages dont la couverture de tests est la plus faible : c’est là que le risque de régression se matérialisera d’abord.

Pourquoi les appels API IA en fetch direct changent la donne

J’exploite six fournisseurs d’IA dans une même stack Cloudflare Workers : Anthropic, Google AI Studio, xAI, OpenAI, DataForSEO et Browser Rendering. Je n’importe aucun de leurs SDK. Chaque appel payant passe par fetch() vers l’endpoint AI Gateway, avec un corps JSON qui reprend le format REST propre à chaque fournisseur.

J’ai fait ce choix il y a trois semaines pour une autre raison : tous les appels payants devaient passer par un wrapper callAi() unique, chargé d’appliquer un plafond de dépenses quotidien de $20 et une limite de $1 par instance. Les SDK dissimulent ce point de contrôle derrière un appel de méthode. Pour imposer ces plafonds avec un SDK, il faut soit monkey-patcher le client, soit envelopper chaque point d’appel. Avec fetch(), une seule fonction suffit.

Le mécanisme BYOK passthrough d’AI Gateway de Cloudflare permet d’utiliser un seul en-tête d’authentification (cf-aig-authorization) et un même format d’URL pour Anthropic, OpenAI, Google, xAI et la génération d’images OpenAI. La structure ressemble à ceci :

export async function callAi(env: Env, ctx: Ctx, runner: () => Promise<Response>) {
  await assertUnderCostCap(env, ctx);
  const started = Date.now();
  const res = await runner();
  await recordCost(env, ctx, res, Date.now() - started);
  return res;
}

// usage – one provider, no SDK in the dep tree
const res = await callAi(env, ctx, () => fetch(
  `https://gateway.ai.cloudflare.com/v1/${env.ACCOUNT}/${env.GATEWAY}/anthropic/v1/messages`,
  {
    method: "POST",
    headers: {
      "cf-aig-authorization": `Bearer ${env.AI_GATEWAY_TOKEN}`,
      "x-api-key": env.ANTHROPIC_API_KEY,
      "anthropic-version": "2023-06-01",
      "content-type": "application/json",
    },
    body: JSON.stringify({ model, max_tokens, messages }),
  },
));

Effet collatéral inattendu cette semaine : cette architecture n’est pas exposée aux conséquences qu’un changement de propriétaire de Stainless pourrait avoir sur le rythme des versions, les changements incompatibles ou les mécanismes de télémétrie. En contrepartie, il faut écrire soi-même les payloads des requêtes — précisément le genre de détail que les SDK sont censés masquer. Le compromis est intéressant si (a) vous utilisez au moins trois fournisseurs, (b) vous avez besoin d’un point de contrôle unique des coûts et (c) vous cherchez désormais aussi à limiter le risque lié au propriétaire d’un fournisseur. Cette troisième raison n’existait pas lundi.

Pour une présentation plus complète de cette stack Cloudflare Workers et de la manière dont elle maîtrise son budget, consultez mon article sur les environnements Cursor Cloud Agent face à Cloudflare Workers.

Que faire cette semaine ?

Passez en revue vos fichiers package.json et requirements.txt pour repérer les SDK livrés par Stainless. Les clients Anthropic et OpenAI pour Python et Node sont les plus évidents. Le nouveau @google/genai de Google vient lui aussi de Stainless : consultez l’organisation github.com/stainless-sdks pour obtenir la liste complète plutôt que de vous fier à des suppositions.

Figez chaque SDK généré par Stainless sur sa version mineure actuelle. Acceptez les correctifs, mais soumettez toute nouvelle version mineure à une revue. Ce travail prend 15 minutes et vous offre un trimestre de marge de manœuvre.

Pour tout nouveau chemin de code qui appelle l’API d’un modèle, écrivez d’abord la version en fetch direct, puis celle qui utilise le SDK. Si la version directe tient en moins de 40 lignes, types compris, livrez-la. La plupart des endpoints de chat completion et de messages respectent facilement ce seuil. Le streaming et l’utilisation d’outils ajoutent encore 20 lignes. Cela reste sous la limite pour un chemin de code que vous conserverez pendant des années.

Si vous exploitez une passerelle — Cloudflare AI Gateway, OpenRouter, Portkey ou LiteLLM — faites-y transiter chaque appel de modèle. Vous obtenez une authentification unique, un point d’observabilité commun et un seul endroit où changer de fournisseur lorsque le SDK sous-jacent devient un risque politique.

Programmez dans votre calendrier un rappel à 90 jours pour vérifier à nouveau quels SDK OpenAI et Google maintiennent en interne et lesquels passent encore par Stainless. La décision entre fork et statu quo tombera avant la fin de l’année.

Le véritable enjeu

La concurrence entre modèles s’est déplacée des poids vers la plomberie logicielle. Le modèle lui-même devient de plus en plus interchangeable ; c’est la couche d’intégration qui crée l’adhérence. C’est la seule lecture de cette opération qui rende son prix rationnel.

Anthropic cherche à lever $30B pour une valorisation de $900B, tout en consacrant $300M à l’infrastructure des SDK plutôt qu’à un lancement de modèle plus spectaculaire : voilà le signal. Les deux entreprises dépassent le modèle pour prendre position sur la couche de déploiement. Le modèle devient la partie bon marché ; l’intégration devient le rempart concurrentiel. La même logique apparaît dans la manière dont Anthropic vend Claude aux entreprises de taille intermédiaire : l’analyse de la stack d’automatisation à $50K illustre cette présence sur le marché professionnel qui justifie de posséder la couche SDK.

Pour les fondateurs, les 12 prochains mois consisteront à maîtriser leur couche d’intégration comme ils maîtrisent leur couche de données. Ne cherchez pas à optimiser le confort d’utilisation d’un SDK, mais sa substituabilité. Le modèle que vous appelez aujourd’hui ne sera pas celui que vous appellerez en 2027. Construisez le wrapper qui survivra au remplacement.