Neoclouds : quand l'IA sort du cloud généraliste

Neoclouds : quand l'IA sort du cloud généraliste

Les hyperscalers ont longtemps été la réponse par défaut à « où on déploie ». Pour les charges d'IA, ce réflexe commence à montrer ses limites. Les modèles demandent des GPU en grande quantité, un réseau très rapide entre machines et une disponibilité de capacité qui ne suit pas toujours la demande. C'est le terrain des neoclouds.

Le phénomène est déjà chiffré. David Linthicum, qui cite Synergy Research Group, rapporte 9 milliards de dollars de revenus pour les neoclouds au quatrième trimestre 2025, soit +223 % sur un an et plus de 25 milliards sur l'année. ABI Research estime que le revenu du GPU-as-a-service chez les neoclouds pourrait dépasser 250 milliards de dollars d'ici 2030, contre 42 milliards en 2025. Ce sont des projections de cabinets d'analyse, à prendre comme des ordres de grandeur et non comme des certitudes.

Ce qu'est vraiment un neocloud

Un neocloud n'est pas un petit hyperscaler. C'est une infrastructure spécialisée dans le calcul IA : clusters GPU denses, refroidissement liquide, interconnexion haut débit. L'idée est simple. Un hyperscaler propose des centaines de services, un neocloud se concentre sur une seule chose, faire tourner des GPU le plus vite possible.

Le délai de mise en service est un argument clé. D'après l'analyse citée, un neocloud peut mettre une capacité en ligne en quelques mois, là où la construction d'un data center hyperscale prend trois à cinq ans. Pour une équipe qui doit déployer un modèle de scoring, un assistant ou un moteur de recommandation dans le trimestre, cette différence compte.

Où un SaaS doit-il exécuter ses charges IA ?

Le piège serait de migrer tout le SaaS vers un neocloud. Ce n'est ni nécessaire ni raisonnable. Une architecture saine sépare les charges :

L'idée : sortir uniquement la partie qui consomme du GPU, et garder le reste là où vos équipes savent déjà opérer.

Les trois questions à poser avant de bouger

1. Ma charge GPU est-elle mesurée ? Sans métriques, la décision est un pari. Mesurez le coût par requête d'inférence, le taux d'utilisation des GPU et la latence p95 aujourd'hui. Sans cette base, impossible de dire si le neocloud est moins cher ou simplement différent.

2. Quelle est ma stratégie de sortie ? Un neocloud est un fournisseur de plus à intégrer. Vérifiez que vos images de conteneurs sont portables, que vos modèles sont stockés hors du fournisseur et que votre orchestration (Kubernetes ou équivalent) n'est pas liée à une API propriétaire. Le vendor lock-in se construit silencieusement, en quelques mois.

3. Qui opère la plateforme ? Un cluster GPU demande du monitoring, des mises à jour de drivers, de la gestion de quotas et des procédures d'incident. Si l'équipe n'a pas ces compétences, le gain de coût part en astreintes.

Ce que l'architecture doit prévoir

Pour une équipe DevOps, le travail concret tient en quelques principes :

• Conteneuriser la charge IA avec une image portable, indépendante du fournisseur.
• Découpler la couche applicative de l'appel au modèle via une API interne, pour pouvoir changer de backend sans réécrire le SaaS.
• Isoler les données sensibles : seules les données strictement nécessaires au calcul doivent quitter votre périmètre, avec un contrôle des journaux.
• Piloter par la capacité réservée et à la demande : garder une base réservée pour le trafic constant, et ouvrir de la capacité à la demande pour les pics ou les entraînements.

Exemple de squelette d'appel minimal, qui isole le fournisseur derrière une variable de configuration :

// inference.ts : le fournisseur GPU est une configuration, pas un choix figé
type InferenceConfig = {
  baseUrl: string;   // endpoint du neocloud ou du cloud généraliste
  model: string;
  apiKey: string;
};

export async function infer(cfg: InferenceConfig, prompt: string): Promise<string> {
  const res = await fetch(`${cfg.baseUrl}/v1/chat/completions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${cfg.apiKey}`,
    },
    body: JSON.stringify({
      model: cfg.model,
      messages: [{ role: "user", content: prompt }],
    }),
  });

  if (!res.ok) {
    throw new Error(`Inférence en échec : ${res.status}`);
  }

  const data = await res.json();
  return data.choices[0].message.content;
}

Ce code ne change pas selon le fournisseur. C'est précisément l'intérêt : vous comparez les offres sur des chiffres réels, pas sur des promesses commerciales.

Le point de vigilance : la maturité commerciale

L'analyse de Linthicum souligne un point intéressant. Les neoclouds ont grandi en vendant beaucoup à quelques grands clients technologiques, avec des contrats massifs et une part de revenus circulaires. Microsoft représentait à lui seul 62 % du chiffre d'affaires de CoreWeave en 2024. Pour un client, cela signifie deux choses : le marché est réel, mais la maturité de l'offre pour les entreprises de taille moyenne reste inégale. Demandez des SLA écrits, des garanties de disponibilité et une documentation d'architecture avant de signer.

Checklist pour une équipe SaaS

• Mesurer le coût, la latence et le taux d'utilisation GPU de chaque charge IA
• Séparer les charges GPU du reste de l'application
• Conteneuriser les charges IA et stocker les modèles hors fournisseur
• Introduire une couche d'abstraction pour changer de backend sans réécrire le SaaS
• Vérifier localisation des données, journaux et clauses de sortie du contrat
• Tester un backend alternatif sur une charge réelle avant la mise en production

Le bon réflexe n'est pas de choisir un camp. Un SaaS moderne garde son socle sur un cloud généraliste et ouvre les GPU là où ils apportent un gain mesurable. Les neoclouds ne remplacent pas vos hyperscalers, ils ajoutent une option au moment où l'IA devient une charge de production.