Mistral héberge les automatisations de Studio. Ce que la préversion prend en charge

Mistral ajoute une pièce à son outil Studio. La fonction Managed Deployments permet d’héberger les programmes qui exécutent ses automatisations. Les notes du 9 octobre 2026 la présentent en préversion publique. Une équipe peut envoyer son code puis laisser Mistral Cloud construire et faire fonctionner son environnement. Elle garde toutefois la responsabilité du programme et des accès qu’il utilise. Cette nouveauté porte sur l’exécution des tâches. Elle n’annonce pas un nouveau modèle d’IA.

Un programme doit tourner pour que la tâche avance

Un workflow décrit un enchaînement de tâches. Il peut faire intervenir un modèle d’IA au cours de cet enchaînement. Un worker est le programme qui exécute ce travail. Écrire les étapes ne suffit donc pas. Il faut aussi disposer d’un environnement qui lance ce programme et le maintient en fonctionnement. Managed Deployments prend en charge cette partie sur Mistral Cloud.

Le guide de la fonction décrit un chemin concret. Mistral récupère le code dans un dépôt GitHub. Il construit une image Docker à partir du fichier fourni dans ce dépôt. Cette image rassemble le programme et ce dont il a besoin pour fonctionner. La plateforme lance ensuite le conteneur correspondant. Le développeur n’a pas à administrer lui-même les serveurs qui l’hébergent.

L’hébergement ne remplace pas le travail sur le code

Le dépôt peut être public ou privé. Le guide de fonctionnement précise que Mistral exécute l’image telle que le projet la définit. Son point de démarrage doit donc lancer le worker. Le développeur choisit les dépendances et prépare ce démarrage. La plateforme ne transforme pas automatiquement un dépôt quelconque en automatisation correcte.

Les commandes de Studio ou de l’API permettent de démarrer un déploiement et de l’arrêter. Elles permettent aussi de le mettre à jour ou de le relancer. Studio affiche les journaux de construction et ceux du worker. Ces traces aident à comprendre un échec. La nouveauté retire une partie de l’exploitation technique quotidienne. Elle ne garantit ni la qualité des réponses du modèle ni la réussite de chaque étape.

Des offres payantes et des limites de capacité

Trois déploiements ou dix selon l’offre

La page des quotas réserve la fonction aux offres payantes. Une organisation Pay-as-you-go peut faire fonctionner trois déploiements gérés en même temps. Une organisation Enterprise dispose d’un plafond de dix. L’offre gratuite n’en autorise aucun. Ces chiffres concernent les déploiements simultanés. Ils ne représentent pas un nombre de tâches par jour et ne donnent pas le prix complet d’une automatisation.

Mistral choisit aussi la taille des instances. Tous les workers gérés reçoivent la même taille dans cette préversion. Les mesures de processeur et de mémoire par déploiement ne sont pas encore exposées. Ça limite la visibilité sur les ressources consommées. La préversion peut évoluer. Il faut donc lire ces plafonds comme les conditions documentées aujourd’hui.

Les accès et les secrets gardent leurs propres règles

Chaque déploiement utilise un compte de service dédié. La plateforme fournit un jeton qui change régulièrement. Le SDK du worker le récupère automatiquement. Le guide exige la version 3.10 ou une version ultérieure de ce SDK. Il situe les workers gérés dans la région néerlandaise nl-north-1. Cette localisation du worker ne décrit pas à elle seule le trajet de toutes les données vers les services qu’un programme appelle.

Le guide de sécurisation distingue un autre contrôle. Il limite les identités autorisées à enregistrer des workflows dans un déploiement. Studio l’active par défaut pour les nouveaux déploiements gérés. Les autres clients n’appliquent pas forcément le même réglage. Ce contrôle ne vérifie pas le code envoyé par une personne autorisée. Il ne remplace pas non plus la protection de ses identifiants.

La gestion des secrets mérite enfin une attention précise. Modifier un secret ne relance pas le worker. Celui-ci conserve la valeur lue à son démarrage jusqu’à un redémarrage. Mistral avertit aussi que les arguments secrets utilisés pendant la construction peuvent rester dans l’historique et les couches de l’image. Une personne qui accède à cette image peut les retrouver. Héberger le programme ne rend donc pas chaque utilisation d’un secret sûre par défaut.

Ce que cette nouveauté change vraiment

Mistral rapproche le code d’une automatisation de son environnement d’exécution. C’est utile lorsque la difficulté tient au maintien du programme en service. Le sujet reste différent du choix d’un modèle ou de la rédaction d’une bonne demande. Pour aborder ces outils en formation, cette distinction aide à comprendre où se trouve le travail. L’IA peut participer à une tâche sans prendre en charge tout le système qui la fait fonctionner.

Pour échanger sur les usages de l’IA dans vos équipes, vous pouvez me contacter.

Pour compléter cette lecture, découvrez aussi les modèles Mistral pour la transcription et les dialectes arabes. Leurs capacités restent une autre couche du choix technique.