Posséder une plus grande part de la stack, c’est surtout posséder davantage de modes de défaillance

« Posséder davantage de la stack » fait partie de ces formules qui peuvent tout vouloir dire ; alors, trop souvent, elles ne veulent rien dire.

De là où je suis, c’est généralement une démarche très précise : vous essayez de maîtriser vos modes de défaillance. Pas des fonctionnalités. Pas une vision. Des modes de défaillance.

Dans l’infrastructure d’IA (intelligence artificielle), les pannes qui comptent sont à la fois triviales et implacables. La capacité quand la demande explose. La latence quand le workload est interactif. Les coûts quand l’utilisation baisse et que quelqu’un demande pourquoi la facture a doublé. La gouvernance quand des régulateurs, des auditeurs ou des équipes sécurité arrivent et que vous ne savez plus expliquer qui a changé quoi, où les données sont passées et pourquoi le système s’est comporté de cette manière.

Alors, quand je lis que Nscale rachète Anyscale pour « posséder davantage de la stack de compute IA », je ne pense pas d’abord « synergies ». Je pense à l’endroit où les défaillances se cachaient entre les couches, et à ce qui se passe lorsqu’une seule entreprise devient responsable d’une part plus large du problème.

Il existe une version « pro-client » de cette histoire, et une version « anti-client ». La différence n’est pas technique. Elle est contractuelle et architecturale. Tout se joue sur un point : est-ce que l’acquéreur transforme « control plane + compute » en portabilité, ou en une nouvelle forme de lock-in, simplement emballée dans une developer experience de qualité ?

Pourquoi l’intégration verticale revient sans cesse

Les workloads d’IA exposent les coutures de l’infrastructure moderne. Ils sont irréguliers, coûteux et sensibles à l’exploitation. Quand la stack est répartie entre plusieurs fournisseurs, chaque couche peut, de façon crédible, refuser la responsabilité.

• Le fournisseur de compute reproche au framework son inefficacité.
• La couche framework reproche au cluster ses « noisy neighbors ».
• La couche plateforme reproche au client ses prompts ou ses données.
• Le client reproche tout le monde, puis réduit discrètement le périmètre.

Ce cycle de renvoi de faute est d’abord un échec de gouvernance. Il devient aussi un échec de pricing, parce que personne ne peut vendre un résultat avec assurance. Chacun vend un composant et une liste de réserves.

« Posséder davantage » vise à casser ce cycle. Oui, « one throat to choke ». Mais surtout : un seul endroit où vit l’instrumentation, un seul endroit où les SLO sont définis, un seul endroit où les arbitrages entre coûts et performance deviennent explicites.

Si vous êtes l’acquéreur, l’enjeu est là : vous cessez de négocier des interfaces entre entreprises, et vous commencez à concevoir des interfaces entre responsabilités.

Quatre modes de défaillance que vous achetez, que vous l’assumiez ou non

Si vous envisagez un ensemble compute + control plane, ne commencez pas par des roadmaps produit. Commencez par un registre des défaillances. Ces quatre-là reviennent à chaque fois.

1) Défaillance de capacité : « On ne peut pas l’exécuter quand ça compte »

Il ne s’agit pas seulement d’avoir assez de GPU. Il s’agit de pouvoir promettre des classes de capacité avec des règles de préemption crédibles. Un job de training peut attendre. Un endpoint en production ne le peut pas. Un run d’embeddings batch peut être décalé si le client est prévenu et que le SLA le reflète.

Si vous possédez le control plane, vous pouvez encoder ces règles, pas seulement les documenter. Et si vous possédez aussi le compute, vous pouvez aligner les incitations pour éviter que le système surbooke en silence avant de s’excuser.

Ce que les clients veulent réellement, c’est de la prévisibilité. Si vous ne pouvez pas garantir l’approvisionnement, garantissez au moins le comportement du système quand l’offre est contrainte.

2) Défaillance de latence : « Ça marche, mais ça semble cassé »

La latence se résume rarement à un seul chiffre. C’est une chaîne : délai de scheduling, accès aux données, exécution du modèle, sauts réseau, cold starts, retries et throttles. Quand des fournisseurs différents possèdent des maillons différents, chacun optimise localement, au détriment de l’expérience de bout en bout.

Un control plane unifié peut traiter la latence comme un budget de premier rang. Il peut imposer le placement, la stratégie de cache, des warm pools et la backpressure. Mais uniquement s’il a une autorité réelle sur les ressources sous-jacentes, pas une API « best effort » vers la flotte de quelqu’un d’autre.

3) Défaillance de coût : « C’est impressionnant, mais on ne peut pas se le permettre »

Les coûts de l’IA racontent surtout une histoire d’utilisation. La capacité idle est une taxe. Le surdimensionnement est une taxe. Un scheduling inefficace est une taxe. Et une plateforme qui permet de lancer des workloads chers sans friction en est une aussi.

C’est ici que l’intégration verticale peut aider… ou se retourner contre vous.

• Aider, si vous rendez visibles les unit economics dans le produit : coût par token, coût par job, coût par exécution de workflow. Pas seulement une facture mensuelle.
• Nuire, si vous utilisez le control plane pour orienter les clients vers les types d’instances, les régions ou les services propriétaires les plus rentables, en appelant cela « optimisation ».

J’ai vu un modèle tarifaire être reconstruit deux fois en un an parce que les équipes ont d’abord optimisé l’adoption, puis la marge, avant de découvrir que les patterns d’usage étaient dépendants de la trajectoire. Une fois que les clients prennent des habitudes, vous pouvez changer les prix, mais vous ne pouvez pas changer la physique de leur workload. Soyez lucide et transparent sur le modèle de coûts dès le départ.

Si ce sujet vous parle, la même logique de gouvernance vaut au-delà de l’IA. J’ai développé l’argument dans Budget overruns are rarely a surprise. They are a governance choice.

4) Défaillance de gouvernance : « On n’arrive plus à expliquer le système »

C’est le mode de défaillance qui met fin aux programmes dans les secteurs régulés, et qui les fige silencieusement partout ailleurs.

La gouvernance n’est pas un document de politique. C’est un ensemble de contrôles qui tient sous pression : qui peut déployer ; qui peut changer le routing ; qui peut accéder aux logs ; comment les secrets tournent ; comment les versions de modèles sont promues ; comment les incidents sont capturés puis rejoués ; comment vous prouvez la résidence et la rétention des données.

Un rachat de control plane est, au fond, un rachat de gouvernance. Si vous le traitez comme un simple add-on de developer tools, vous passerez à côté du plus difficile, et vous décevrez, chez vos clients, ceux qui portent le risque.

Comment un M&A « compute + control plane » devient de la portabilité, pas de la captivité

Il existe un test simple pour savoir si vous construisez une plateforme ou un piège : un client sérieux peut-il sortir sans downtime et sans réécrire la moitié de sa stack ?

Vous n’avez pas à rendre le départ facile économiquement. Vous devez le rendre possible techniquement. La portabilité rend les engagements long terme rationnels. C’est ainsi que vous gagnez le droit d’être « sticky ».

Voici la structure que je viserais si je devais acheter un control plane pour l’adosser au compute.

1) Séparer le « contrat du control plane » de la « fourniture de compute »

Les clients devraient pouvoir exécuter la même couche d’orchestration sur votre infrastructure et sur celle d’un autre fournisseur, même si la meilleure expérience est chez vous. Cela implique :

• Des API ouvertes et documentées pour la soumission de jobs, les intentions de scheduling et l’observabilité.
• Une configuration portable, idéalement sous forme de code.
• Une frontière nette entre ce qui relève de la policy (portable) et ce qui relève du tuning de performance (spécifique au fournisseur).

Quand le control plane est indissociable du fournisseur de compute, vous n’avez pas intégré une stack. Vous avez fusionné deux systèmes de facturation.

2) Faire de l’« export » une fonctionnalité produit, pas un ticket support

La portabilité meurt dans les interstices : métriques impossibles à exporter, logs propriétaires, registries de modèles impossibles à mirrorer, définitions de workloads que seule votre UI comprend.

Traitez donc l’export comme un backup : un parcours de premier rang, avec des tests. Un client devrait pouvoir :

• Exporter les spécifications de workloads et les policies.
• Répliquer les artefacts (modèles, containers, datasets quand c’est autorisé).
• Reconstituer ailleurs les baselines d’observabilité.

Ce n’est pas de la philanthropie. C’est la façon la plus efficace de réduire l’appréhension en procurement, sécurité et revues d’architecture.

3) Publier le comportement en défaillance, puis l’imposer automatiquement

Dans l’infrastructure, le signal de confiance le plus fort n’est pas « nous sommes fiables ». C’est : « voici comment nous échouons ».

La rareté de capacité doit déclencher des actions déterministes. Les pics de latence doivent se dégrader avec élégance. Les garde-fous de coût doivent stopper les dérives. Les violations de gouvernance doivent bloquer les changements par défaut.

Écrivez ces comportements, puis rendez-les exécutables dans le control plane. C’est aussi le point d’alignement des équipes : la plateforme, la flotte et le commercial doivent se mettre d’accord sur ce que « bon » veut dire.

4) Tarifer le control plane comme un système de décision, pas comme un péage

Si votre monétisation ressemble à « payez plus pour comprendre ce qui se passe », les clients vous contourneront. Ils construiront des outils parallèles, ou ils éviteront une adoption profonde.

Un meilleur schéma consiste à facturer le compute à l’usage, et à traiter le control plane comme :

• Une capacité incluse jusqu’à une échelle raisonnable, puis
• Une couche payante pour la gouvernance avancée, les policies multi-région, le reporting de conformité et l’intégration enterprise.

Le récit devient limpide : le client paie pour réduire le risque et l’overhead, pas pour le privilège d’être enfermé.

La vérité qui dérange : la portabilité est la meilleure stratégie de rétention

Après un deal comme le rachat d’Anyscale par Nscale, le réflexe est d’« intégrer en profondeur ». L’intégration profonde, très bien. Le couplage caché, non.

Si vous voulez que les clients standardisent sur votre stack, donnez-leur deux choses en même temps :

• Une meilleure maîtrise des modes de défaillance que ce qu’ils obtiennent en assemblant plusieurs fournisseurs.
• Une sortie crédible qui rende l’engagement acceptable.

Ce duo semble contradictoire tant qu’on ne l’a pas vécu. La portabilité ne réduit pas la stickiness ; elle en change la nature. Les clients restent parce que la plateforme tient ses promesses sous pression, pas parce que partir exigerait une réécriture.

Mon point de vue est simple : si « posséder davantage de la stack » ne rend pas le comportement en défaillance plus lisible et plus gouvernable pour le client, ce n’est pas un progrès. C’est juste un autre endroit pour cacher le même risque.

Lecture connexe si vous concevez le control plane lui-même : AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.