IA managée sur cloud souverain (Numspot x Mistral) : les questions à poser en AURA

Tu as un cas d’usage GenAI qui marche en pilote. Et là, la vraie question arrive: où tu le mets en prod, avec quelles données, et sous quel contrat. En Auvergne-Rhône-Alpes, entre industrie, santé, banque-assurance, énergie et acteurs publics, la réponse “on met ça sur un cloud public et on verra” ne passe pas toujours. L’annonce Numspot x Mistral AI sur une offre d’IA managée “opérée de bout en bout en France” remet une option sur la table pour les acheteurs régulés. Mais “souverain” et “managé” sont des mots. Toi, tu dois acheter des garanties vérifiables.

Objectif ici: traduire PaaS IA managée et opérée en France en check-list d’achat, cadrer les workloads réalistes (RAG, assistants internes, classification) et pointer les clauses qui font ou défont un projet avec données sensibles. Avec, à la fin, une matrice simple on-prem vs cloud souverain IA vs cloud public.

1) Ce que dit vraiment l’annonce Numspot x Mistral (et ce qu’elle ne dit pas)

À date, Numspot et Mistral ont annoncé le 15 septembre 2026 une offre d’IA “managée” sur une infrastructure cloud souveraine, présentée comme “opérée de bout en bout en France” (source: Numspot). Numspot précise aussi que le processus de qualification du service est “en cours”. Traduction acheteur: ce n’est pas parce que la qualification est en route qu’elle est acquise. Il faut donc acheter sur des preuves et un périmètre contractuel, pas sur une trajectoire.

Point pratique: dans les organisations AURA, les projets GenAI finissent souvent par toucher l’un de ces trois sujets: RGPD, secret des affaires, exigences sectorielles (santé, finance, OIV/OSE, collectivités). Donc tu ne peux pas te contenter d’un “hébergé en France” sans cartographie des flux et sans clauses de logs, de sous-traitants, de rétention et de réversibilité.

2) “PaaS IA managée”: ce que tu achètes vraiment (et ce que tu n’achètes plus)

Un PaaS IA managé, côté achat, c’est un service où le fournisseur opère la plateforme: exploitation, patching, disponibilité, sécurité plateforme, support, capacité. Toi, tu consommes une API ou une console, avec des quotas, des limites, des métriques. Tu n’administres pas ton cluster GPU au quotidien.

Les docs Numspot sur les “managed services” et la mention d’une “Mistral AI Platform” vont dans ce sens. Ce modèle a un avantage clair pour les équipes lyonnaises qui n’ont pas une squad infra IA complète: tu réduis l’effort d’opération. Mais tu échanges ça contre une dépendance plus forte au contrat et aux contrôles fournis.

Les questions simples à poser dès la phase cadrage

• Qui opère quoi: Numspot opère l’infra et la plateforme, ok. Mais qui opère l’observabilité, le support, les outils de ticketing, les accès d’urgence?
• Ce que tu gères: IAM côté client, clés, chiffrement, réseau, paramétrage rétention, red team, tests d’injection de prompt?
• Le niveau d’isolement: tenant dédié, environnements isolés, option single-tenant, segmentation réseau, clés par client?
• Le run: SLA de disponibilité, SLO de latence, fenêtres de maintenance, procédure incident, notification, RTO/RPO.

Si tu ne mets pas ça au clair, tu te retrouves avec un POC “facile” et une prod impossible à certifier en audit.

3) “Opérée en France”: découpe le slogan en exigences testables

“Opérée en France” mélange souvent trois réalités différentes. Tu dois les séparer, sinon tu achètes un mot.

3.1 Localisation du traitement et des données

Tu veux savoir où passent et où restent:

• les prompts et outputs,
• les documents ingérés (PDF, mails, procédures),
• les embeddings et l’index vectoriel (qui peuvent ré-exposer des infos),
• les métadonnées (IDs utilisateurs, noms de projets, tags),
• les logs (API, admin, erreurs, traces),
• les sauvegardes et exports.

Point d’attention: côté Mistral, il existe des endpoints régionaux (UE vs US). Même si ton fournisseur “est français”, tu verrouilles contractuellement l’endpoint autorisé et tu vérifies les flux induits (source: docs Mistral, “regional inference”).

3.2 Localisation des équipes d’exploitation et conditions d’accès

“Les serveurs sont en France” ne suffit pas si une équipe support hors UE peut accéder à l’admin, aux logs, ou à une console. Tu veux des réponses écrites sur:

• où sont les équipes (support N1, N2, SRE, sécurité),
• comment elles accèdent (bastion, MFA, PAM, sessions enregistrées),
• accès d’urgence (break-glass): qui, quand, avec quelle validation, quelle traçabilité.

3.3 Chaîne de sous-traitance

Tu ne négocies pas avec une slide, tu négocies avec une liste de sous-traitants. Hébergement, réseau, outils d’observabilité, ticketing, analytics, SOC, maintenance. Et pour chacun: lieu, rôle, niveau d’accès, engagement de localisation et de notification en cas de changement.

La doctrine “Cloud au centre” de l’État pousse vers des offres qualifiées SecNumCloud quand la sensibilité est élevée, et insiste sur la chaîne de responsabilité. Même hors secteur public, c’est une bonne grille de lecture quand tu es régulé ou exposé (source: numerique.gouv.fr).

4) SecNumCloud: utile, mais ne te fais pas piéger par les mots

Pour des SI avec données “d’une sensibilité particulière”, la qualification SecNumCloud est un repère: exigences sécurité, organisation, exploitation, traçabilité, etc. Sur le papier, c’est exactement le type de garde-fou que tu veux quand tu mets de la GenAI sur des données internes sensibles.

Mais: Numspot communique avoir franchi des jalons J0 et J1 sur plusieurs services PaaS et indique des services “en cours de qualification”. Très bien. Sauf que “en cours” n’est pas “qualifié”. Donc à l’achat:

• demande le périmètre exact couvert par la qualification (si existante) ou par la trajectoire,
• exige que ton service (pas “la plateforme en général”) soit dans le périmètre contractuel visé,
• prévois une clause si la qualification n’aboutit pas dans les délais compatibles avec ton audit.

Autre point concret: SecNumCloud a des exigences fortes sur la journalisation et la localisation des journaux (source: référentiel ANSSI). Pour un PaaS IA, c’est central, parce que les logs peuvent contenir des prompts, des extraits de documents, ou des identifiants métiers. Tu dois le traiter comme une donnée sensible, pas comme un détail technique.

5) Workloads réalistes en AURA (et ceux qui dérapent vite)

Tu ne mets pas “toute l’entreprise” dans un LLM au jour 1. Les déploiements qui tiennent en secteurs régulés démarrent par des workloads où la valeur est nette et le périmètre maîtrisable.

5.1 RAG sur corpus interne: le meilleur ratio valeur/risque

Typique dans l’industrie lyonnaise, la chimie, l’énergie, ou les ETI: procédures qualité, modes opératoires, documentation maintenance, référentiels RH, achats, HSE.

• Ce qui marche: recherche assistée + réponse sourcée, avec cloisonnement par entité (site, BU, filiale).
• Ce qui casse: ingestion “en vrac” sans gouvernance documentaire, droits mal alignés, et logs trop bavards.

Si tu veux une base méthode côté RAG: https://lyon-ia.com/blog/rag-ia-documents-entreprise

5.2 Assistants internes: utile, mais limite l’action au début

Cas AURA fréquents: helpdesk IT dans des groupes multi-sites, support exploitation, assistant conformité, assistant achats.

• Phase 1: lecture, synthèse, proposition de réponse, génération de brouillons.
• Phase 2: actions dans les SI, mais seulement avec garde-fous (approbation humaine, scopes limités, journaux, tests de sécurité).

Sur la construction d’un assistant interne, tu peux t’appuyer sur: https://lyon-ia.com/blog/assistant-interne-documentation-entreprise

5.3 Classification, routage, tri: GenAI “discrète” mais rentable

Parfait pour banques mutualistes régionales, assureurs, mutuelles, services publics, et PME avec beaucoup d’entrants: mails, formulaires, tickets, comptes-rendus.

• Avantage: tu peux imposer une rétention courte et éviter de stocker du texte long.
• Vigilance: biais de classification, traçabilité des décisions, et gestion des erreurs (reprise, escalade).

5.4 Ce qui dérape vite

• Latence ultra basse ou contraintes temps réel industrielles: sans engagements SLO et architecture réseau propre, tu vas souffrir.
• Charges très variables: tu dois comprendre quotas, limites, burst, et modèle de facturation (sinon budget qui explose).
• Multi-données très sensibles (santé + secret industriel + données RH): exige une cartographie complète des flux, y compris embeddings et logs.

6) Checklist acheteur: les clauses qui comptent vraiment avec des données sensibles

6.1 Journalisation: ce que tu veux voir écrit, pas “configurable”

• Qu’est-ce qui est loggé: appels API, prompts, outputs, erreurs, traces admin, accès support.
• Où sont les logs: pays, région, stockage, sauvegardes.
• Durée de conservation: par défaut et options, avec preuve de purge.
• Qui y accède: RBAC/PAM, justification, traçabilité.

Tu veux aussi une réponse claire sur les logs d’inférence: si le service garde des extraits de prompts “pour améliorer le service”, tu dois pouvoir refuser et auditer.

6.2 Localisation: verrouillage contractuel des flux

• liste des localisations pour documents, index, embeddings, métadonnées, backups, logs, monitoring, support, ticketing, artefacts.
• clause de notification avant tout changement de localisation ou de sous-traitant.
• si endpoints régionaux: endpoint autorisé et interdiction de fallback hors périmètre.

6.3 Sous-traitants: la liste exhaustive et leurs droits

• liste nominative, rôle, pays, accès (lecture, admin, “break-glass”).
• interdiction d’ajout de sous-traitant critique sans accord.
• processus d’intervention: ticket, validation, enregistrement des sessions.

6.4 Rétention: “zero data retention” ou juste une promesse?

Mistral indique des éléments sur le stockage des données et évoque des mesures additionnelles possibles selon les cas, dont “zero data retention” (source: help Mistral). Ton job: transformer ça en paramétrage et en clause.

• Prompts/outputs: sont-ils stockés? combien de temps? pour quoi faire?
• Logs: peux-tu réduire, pseudonymiser, ou exclure certains champs?
• Embeddings: durée de vie, purge sur demande, purge automatique à la fin d’un projet.

Pour cadrer ça côté entreprise: https://lyon-ia.com/blog/politique-conservation-donnees-ia

6.5 Réversibilité: sortir vite et propre

• Export self-service de tes données: documents, index, embeddings, config, prompts templates, métriques.
• Format d’export et compatibilité (si tu changes de fournisseur).
• Effacement: certificat, délai, périmètre (prod + backup + logs).
• Coûts de sortie: extraction, bande passante, accompagnement.

6.6 Sécurité applicative GenAI: tu ne l’achètes pas “incluse”

Un PaaS IA te donne une plateforme. Il ne te donne pas automatiquement une appli sûre. Deux points reviennent en audit: fuite via prompts et injection de prompt.

• Sur l’injection de prompt: https://lyon-ia.com/blog/injection-de-prompt-securite
• Sur la sécurisation LLM en prod: https://lyon-ia.com/blog/securiser-vos-llm-en-production-menaces-et-parades-pour-les-entreprises

7) Cas d’usage typiques en secteurs régulés en région (sans fantasmer)

Santé (Lyon, Grenoble, Clermont): documentation, codage, qualité

• RAG sur procédures, référentiels, qualité, protocoles internes.
• Classification de comptes-rendus, routage, pré-remplissage, avec minimisation.
• Point dur: données de santé. Exige une cartographie flux + rétention + logs béton.

Banque-assurance, mutuelles: front back-office, conformité, entrants

• Tri et routage de demandes, aide à la réponse, synthèse de dossiers.
• RAG sur référentiels internes (produits, conformité, procédures).
• Point dur: traçabilité. Qui a demandé quoi, sur quelle base, quelle source.

Industrie, énergie, chimie (couloir rhodanien): support exploitation et knowledge

• Assistant maintenance et HSE sur documentation interne.
• Recherche technique multi-sites avec cloisonnement.
• Point dur: secret industriel et segmentation réseau, plus maîtrise des exports.

Collectivités et établissements publics: relation usagers, aide interne

• Assistant interne pour agents, RAG sur procédures, réponses type.
• Routage des demandes entrantes, classification, extraction.
• Point dur: doctrine cloud et exigences “niveau État” parfois demandées même hors périmètre central.

Pour la logique achats côté secteur public en AURA (check-list utile même en privé): https://lyon-ia.com/blog/pacte-numerique-et-ia-ai-act-10-verifications-avant-un-marche-public-ia-en-aura

8) Matrice de décision: on-prem vs cloud souverain IA vs cloud public

Prends ça comme une grille rapide. Pas comme une religion.

Option A: On-prem (ou “IA locale”)

• Quand c’est le bon choix: données ultra sensibles, contraintes réseau fortes, besoin d’isolement maximal, contrôle total des logs, intégrations OT/legacy.
• Coûts cachés: GPU, compétences, patching, sécurité, disponibilité.
• À regarder: capacité à maintenir un run 24/7 et à tester régulièrement la sécurité.

Option B: Cloud souverain IA managée (cloud souverain IA, PaaS IA SecNumCloud visé)

• Quand c’est le bon choix: secteurs régulés, exigences de localisation, besoin de PaaS sans opérer l’infra, recherche d’alignement SecNumCloud.
• Ce que tu gagnes: industrialisation plus rapide, meilleur cadrage sur localisation et exploitation (si contracté correctement).
• Ce que tu dois verrouiller: qualification réelle vs “en cours”, logs, sous-traitants, rétention, réversibilité, endpoints.

Option C: Cloud public

• Quand c’est le bon choix: vitesse, large écosystème, services avancés, workloads moins sensibles ou bien anonymisés.
• Risque typique: dérive de données (logs, analytics, support), complexité multi-région, conformité difficile à prouver en audit si le contrat est flou.
• Bon compromis: garder les données sensibles on-prem, n’envoyer que du minimisé/anonymisé.

Si tu veux creuser l’alternative locale: https://lyon-ia.com/blog/heberger-son-ia-en-france et https://lyon-ia.com/blog/modeles-dia-en-local-ce-que-ta-pme-lyonnaise-peut-faire-tourner-sans-le-cloud

9) Plan d’action concret avant d’embarquer des données sensibles

• 1. Écris ton périmètre: quels types de données, quels utilisateurs, quels usages (RAG, tri, assistant), quels niveaux de sensibilité.
• 2. Cartographie les flux: documents, embeddings, prompts, outputs, logs, backups. Sans ça, pas d’achat propre.
• 3. Exige la vérité sur la qualification: qualifié, en cours, ou non. Et sur quel service exact.
• 4. Négocie les clauses: journalisation, localisation, sous-traitants, rétention, réversibilité. Pas en annexe “best effort”.
• 5. Teste en conditions d’audit: export, purge, accès support, preuve de localisation, limitation des logs, scénarios incident.
• 6. Démarre petit: un corpus, un service, un assistant en lecture seule, et tu montes en puissance.

Si tu as besoin d’une grille de lecture contrat (utile quel que soit le fournisseur): https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses

Ce que tu dois obtenir avant de signer (version courte)

Si tu ne dois retenir que ça, retiens ça:

• “Cloud souverain IA”: tu veux une liste de localisations par type de donnée, et un verrouillage des endpoints.
• “Numspot Mistral AI”: tu veux une chaîne de sous-traitance exhaustive + qui accède à quoi.
• “PaaS IA SecNumCloud”: tu veux le statut réel (qualifié vs en cours) et le périmètre exact, plus des engagements sur logs et rétention.
• RAG, assistants internes, classification: oui, réaliste. Mais seulement si tu traites embeddings et logs comme des données sensibles.

Tu peux aller vite. Mais pas en achetant des mots. Achète des preuves, des clauses, et un périmètre qui tient face à ton RSSI, ton DPO et ton auditeur.