Ce qui a été annoncé le 8 octobre 2026

L’annonce de Scality porte sur une pile destinée aux entreprises, aux administrations et aux fournisseurs de cloud spécialisés. Elle vise les organisations qui souhaitent déployer des modèles ouverts sur leur propre infrastructure sans reconstruire seules toute la chaîne de serving, de stockage et de supervision.

La solution réunit quatre éléments principaux :

• des modèles open weight validés et maintenus dans la pile ;

• une couche de service d’inférence qui sépare le traitement initial du prompt, appelé prefill, de la génération des tokens, appelée decode ;

• un plan de contrôle qui gère l’authentification, le suivi de la consommation, le routage et la planification des charges ;

• Scality AI Data Infrastructure, utilisé comme couche de stockage pour les modèles, les données et l’état d’inférence.

Scality indique que la pile fonctionne avec plusieurs familles de modèles ouverts, notamment Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM et DeepSeek. Elle est également présentée comme compatible avec des frameworks d’agents et déployable sur des serveurs standards de plusieurs fabricants. Ces compatibilités sont des éléments de l’offre annoncée, pas une garantie de résultat identique pour chaque modèle ou matériel.

Un point technique mis en avant concerne le cache KV, c’est-à-dire la mémoire intermédiaire qui conserve le contexte déjà calculé par le modèle. Selon les tests communiqués par Scality, son stockage partagé peut accélérer la restauration d’un contexte et éviter une partie des recalculs, notamment pour les longues conversations et les agents qui réutilisent souvent les mêmes informations. Ces chiffres restent à valider sur les modèles, GPU, tailles de contexte et niveaux de concurrence de chaque entreprise.

Pourquoi l’inférence IA on-premise devient stratégique

Pendant une phase pilote, appeler une API cloud est souvent le moyen le plus rapide de vérifier la valeur d’un assistant ou d’un agent. En production, les contraintes changent : le volume de requêtes augmente, les données deviennent plus sensibles et un changement de modèle peut modifier le comportement d’un processus métier.

Le premier enjeu est la prévisibilité économique. Une API facturée au token peut être simple à démarrer, mais son coût suit directement l’usage. Une infrastructure locale inverse le problème : la facture par requête peut devenir plus lisible, mais l’organisation prend en charge les GPU, le stockage, le réseau, le refroidissement, la maintenance et les compétences nécessaires. Le bon comparatif est donc le coût total de possession, pas seulement le prix du token.

Le deuxième enjeu est la maîtrise des données. Exécuter localement peut limiter l’exposition de documents internes, de code source ou de données réglementées, mais cela ne dispense pas de sécuriser les journaux, les caches, les sauvegardes et les accès administrateurs. Une architecture dite souveraine doit être vérifiable de bout en bout.

Le troisième enjeu concerne la stabilité du service. La page produit de Scality met en avant un contrôle sur la version du modèle, la quantification, le routage et les objectifs de niveau de service. Pour un produit qui vend une réponse générée par IA, cette stabilité peut être aussi importante que la performance brute : une mise à jour silencieuse du modèle peut changer les réponses livrées aux clients.

Il faut toutefois éviter une conclusion trop rapide. L’on-premise n’est pas automatiquement moins cher, plus sécurisé ou plus écologique. Il devient pertinent lorsque la sensibilité des données, la régularité de la charge, les exigences de latence ou la nécessité de contrôler les versions compensent la complexité d’exploitation.

Cas d’usage et méthode d’évaluation

La valeur d’une plateforme d’inférence ne se mesure pas à la liste des modèles disponibles. Elle se voit dans un flux métier précis, avec une charge, un niveau de service et un risque documentés.

Assistants internes sur des documents sensibles. Une direction juridique, une équipe RH ou un service industriel peut utiliser un modèle ouvert pour rechercher et synthétiser des documents internes. L’évaluation doit couvrir la qualité des réponses, la traçabilité des sources, la séparation des espaces et la durée de conservation des prompts et des caches.

Agents de développement logiciel. Des équipes engineering peuvent connecter leurs outils de code à une API compatible et exécuter localement des tâches de génération, de test ou de documentation. Le test doit mesurer le temps de réponse sur des dépôts réels, le coût par tâche, le taux de suggestions acceptées et les risques de fuite du code source.

Support client et opérations. Un assistant de support peut traiter une base de connaissances ou préparer des réponses sans envoyer les tickets à un service externe. Il faut alors suivre la latence au premier token, le taux d’escalade vers un humain, le taux d’erreur et la capacité à absorber les pics de demande.

Agents avec contexte long. Les workflows de planification, de recherche ou d’analyse peuvent réutiliser de longs contextes. Le cache KV partagé peut être utile dans ce scénario, mais le protocole de test doit comparer le recalcul et la restauration sur plusieurs tailles de contexte, plusieurs niveaux de concurrence et plusieurs modèles.

Avant un déploiement, une équipe peut documenter les indicateurs suivants :

• coût complet par requête et par workflow, en incluant l’infrastructure et l’exploitation ;

• latence au premier token et débit de génération ;

• taux d’erreur, d’indisponibilité et d’escalade humaine ;

• qualité métier évaluée sur un jeu de tests représentatif ;

• volume de données conservées dans les journaux et les caches ;

• temps nécessaire pour valider, déployer ou retirer une nouvelle version de modèle.

Implications pour les équipes et points de vigilance

Pour une DSI, l’annonce déplace une partie du travail du fournisseur cloud vers l’organisation. Il ne s’agit plus seulement de choisir un modèle, mais d’opérer une plateforme : capacité GPU, stockage, réseau, versions, sécurité, observabilité et support doivent être attribués clairement.

Produit et métiers. Commencez par sélectionner un flux où la charge est régulière, les critères de qualité sont mesurables et le bénéfice d’un traitement local est réel. Un assistant généraliste avec peu de volume donnera rarement un dossier économique convaincant.

Data et infrastructure. Dimensionnez séparément les besoins de calcul, de stockage des modèles, de cache et de données métier. La séparation prefill/decode peut améliorer l’utilisation des GPU, mais elle ajoute aussi des composants et des chemins réseau à surveiller.

Sécurité et conformité. Vérifiez le contrôle des accès, la journalisation, le chiffrement, le cloisonnement des tenants et le processus de mise à jour des modèles. La présence d’un logiciel open code facilite l’inspection, mais elle ne remplace ni une revue de sécurité ni une politique de gestion des vulnérabilités.

Achats et finance. Comparez une offre sur site à plusieurs scénarios cloud : charge moyenne, pic d’activité, croissance des usages et mode dégradé. Demandez aussi qui maintient les versions, qui garantit les niveaux de service et comment sont traitées les migrations de modèles.

Gouvernance IA. Formalisez un registre des modèles avec leur version, leur quantification, leurs données de référence, leurs évaluations et leur date de retrait. Cette discipline est utile pour la conformité, mais aussi pour comprendre rapidement pourquoi la qualité d’un assistant a changé.

Le piège classique consiste à acheter des GPU avant d’avoir défini le service à rendre. Un pilote plus utile commence par une charge réelle, un jeu de tests stable et une comparaison transparente avec l’option cloud déjà disponible.