Cohere remet une pièce sur “secure/sovereign AI”. Ce n’est pas un slogan, c’est un signal achat
Quand un éditeur de modèles de langage (LLM) lève des montants massifs en répétant “IA sécurisée” et “IA souveraine”, ce n’est pas juste du marketing. C’est le reflet d’une demande qui s’est durcie côté entreprises et administrations. Cohere l’illustre très clairement.
Le 29 octobre 2026, Cohere annonce un premier closing de Série E avec un objectif pouvant aller jusqu’à 7 milliards CAD et une valorisation annoncée (objectif) de 35,7 milliards CAD, en expliquant la levée par la demande mondiale pour une IA “secure, sovereign” dans les entreprises et les gouvernements (PR Newswire, 29/10/2026). Cohere avait déjà levé 500 M$ en juillet 2024 (valorisation 5,5 Md$ selon Bloomberg relayé par TechCrunch) puis 500 M$ en août 2025 (valorisation 6,8 Md$, communication Cohere) en mettant en avant le positionnement “secure enterprise and sovereign AI solutions”.
Traduction pour une organisation lyonnaise: le marché ne se joue plus seulement sur “le modèle est-il bon ?”. Il se joue sur “peut-on le mettre en prod sans ouvrir une brèche juridique, sécurité ou budgétaire ?”.
Pourquoi “IA sécurisée entreprise” et “IA souveraine” tirent les achats (et donc les levées)
1) Le cadre réglementaire se resserre: tu dois produire des preuves, pas des intentions
Dans l’UE, l’AI Act est entré en vigueur le 1er août 2024 (Commission européenne). Les obligations sur les modèles à usage général (GPAI) s’appliquent à partir du 2 août 2025, et le texte est globalement applicable à partir du 2 août 2026 (EUR-Lex, règlement 2024/1689). Pour une boîte à Lyon, ça se traduit par des demandes internes plus fréquentes: documentation, traçabilité, gouvernance des risques, transparence sur le fournisseur, capacité à auditer.
Et côté données perso, la CNIL a publié une FAQ le 18 juillet 2024 sur l’IA générative: elle insiste sur une approche “besoins concrets” et maîtrise des risques, avec vigilance particulière quand des données personnelles entrent dans le pipeline (CNIL). Donc oui, “on mettra un bandeau RGPD” ne suffit plus.
2) La notion de “cloud de confiance” devient un critère d’appel d’offres, pas un bonus
En France, la qualification SecNumCloud (référentiel v3.2 du 08/03/2022) sert de repère dans beaucoup de consultations: exigences d’exploitation, séparation des environnements, journalisation, etc. (cyber.gouv.fr). Même si tu n’exiges pas SecNumCloud, tu vas finir par exiger des morceaux de SecNumCloud: qui administre, où sont les logs, comment on isole, comment on répond à incident.
3) “Souverain” ne veut pas dire “hébergé en France”. Les acheteurs ont appris à être méfiants
Erreur classique: confondre “données en UE” avec “pas de risque extraterritorial” ou “pas de transfert” au sens RGPD. Dans un LLM, il faut regarder toute la chaîne: sous-traitants, accès de support, supervision, sauvegardes, consoles d’admin, clés de chiffrement, télémétrie.
4) À Lyon, tu as un mix sectoriel qui fait monter la barre
Entre santé, industrie, énergie, finance, assurance, secteur public, transport, tu as beaucoup d’acteurs qui portent des contraintes fortes: données sensibles, exigences d’audit, continuité d’activité. Résultat: le “LLM entreprise” doit passer des comités sécurité, DPO, achats, parfois des exigences client. Et là, un fournisseur qui sait vendre de la “secure/sovereign AI” capte des budgets.
Ce que recouvrent vraiment “IA sécurisée entreprise” et “IA souveraine” (et ce que ça ne garantit pas)
IA sécurisée peut viser: isolation, chiffrement, contrôle d’accès, journalisation, gestion des vulnérabilités, engagements contractuels (SLA, support, incident), preuves d’audit.
IA souveraine recouvre souvent: localisation des traitements et données, contrôle juridique (exposition à des lois extraterritoriales), maîtrise opérationnelle (qui opère, qui administre), réversibilité (sortie), parfois qualification (ex: SecNumCloud) selon les secteurs.
Point clé: aucun de ces mots ne garantit automatiquement que tu es conforme, ni que tu es “safe”. Ce sont des hypothèses à vérifier, et surtout à contractualiser.
9 critères pour choisir un LLM entreprise à Lyon (données, coût, souveraineté)
Objectif: te donner un cadre comparatif. Pas une shortlist, pas une recommandation fournisseur. Tu peux t’en servir tel quel dans une matrice de décision et dans un appel d’offres.
1) Données: usage, conservation, réutilisation
C’est le nerf de la guerre. Un LLM manipule plus que “le prompt”: documents, pièces jointes, embeddings, sorties, métadonnées, traces techniques.
- Questions à poser:
- Les prompts, documents, sorties, embeddings, métadonnées sont-ils conservés ? Combien de temps ?
- Ces données servent-elles à entraîner ou améliorer des modèles ? Opt-in ou opt-out ? Qu’est-ce qui est garanti contractuellement ?
- Existe-t-il un mode “zéro rétention” (ou équivalent) ? Que couvre-t-il vraiment: contenu, logs techniques, métriques, abus detection ?
- Ce que tu veux obtenir: une politique écrite, des durées, des exclusions claires, et un engagement contractuel.
Pour cadrer l’approche données côté entreprise, tu peux aussi te référer à la logique “besoins concrets + maîtrise des risques” rappelée par la CNIL.
2) Hébergement et isolation: SaaS, tenant dédié, VPC, on-prem
Le même modèle peut être consommé comme une API publique, déployé en tenant dédié, installé dans ton VPC, ou carrément on-prem. Ce n’est pas un détail. Ça change l’attaque surface, la conformité, le run, le budget.
- Questions à poser:
- Quelles options d’hébergement existent réellement: SaaS mutualisé, tenant dédié, VPC (dans notre cloud), on-prem (dans notre DC) ?
- Isolation réseau: endpoints privés, pas d’exposition Internet, peering, restrictions IP, egress control ?
- Qui administre quoi selon chaque option (éditeur, intégrateur, vous) ?
- Piège fréquent: croire que “tenant dédié” équivaut à de l’on-prem. Exige une description d’architecture et des périmètres d’administration.
3) Souveraineté: localisation et chaîne de sous-traitance
Ici, tu cherches du factuel. Où sont les traitements, où sont les données, qui a accès, quel droit s’applique, et qui est responsable.
- Questions à poser:
- Où ont lieu l’inférence, le stockage, les sauvegardes, les logs, l’observabilité ? Pays et régions cloud précis.
- Liste complète des sous-traitants et des briques critiques (hébergeur, monitoring, support, ticketing, anti-abus, etc.).
- Accès de support: d’où, par qui, avec quel contrôle, quel enregistrement des actions ?
- Qui détient et gère les clés de chiffrement ? Options BYOK ou HYOK ?
- Ce que tu veux obtenir: une cartographie de flux et une annexe contractuelle de sous-traitance.
4) Sécurité technique: chiffrement, IAM, segmentation, durcissement
Les DSI et RSSI lyonnais ne veulent plus “un LLM”, ils veulent une brique qui s’intègre dans leurs standards sécurité.
- Questions à poser:
- Chiffrement en transit et au repos: quels algorithmes, quelles garanties, quels périmètres (contenu, embeddings, logs) ?
- Gestion des identités: SSO, SAML/OIDC, SCIM, MFA, RBAC, séparation des rôles admin ?
- Segmentation: réseaux, projets, environnements (dev/preprod/prod) réellement isolés ?
- Politique de vulnérabilités: fréquence de patch, pentests, bug bounty, divulgation responsable ?
5) Journalisation et audit: logs utiles, exploitables, exportables
Sans logs propres, tu ne sais pas enquêter. Et avec les agents IA qui appellent des outils, la question des traces devient non négociable.
- Questions à poser:
- Quels logs sont disponibles: requêtes, réponses, identités, sources RAG, actions/outils appelés, erreurs, latence ?
- Peut-on désactiver la rétention de contenu tout en gardant des logs techniques ? Où est la ligne ?
- Export SIEM: formats, API, streaming, conservation, horodatage, intégrité.
- Traçabilité admin: chaque action d’administration est-elle tracée ?
Si tu veux cadrer ça proprement, commence par t’aligner en interne sur ce que tu dois tracer. Lyon IA a un point d’entrée pratique ici: https://lyon-ia.com/blog/tracabilite-decisions-ia.
6) Conformité et gouvernance: RGPD, AI Act, ISO 42001, SecNumCloud (quand c’est pertinent)
Le sujet n’est pas de cocher des logos. Le sujet, c’est: “quelles obligations tu portes” et “quelles preuves ton fournisseur peut fournir”.
- Questions à poser:
- Le fournisseur fournit-il un DPA (accord de sous-traitance), et quelles clauses sur transferts, sous-traitants, audits ?
- Quelles informations et artefacts pour l’AI Act (documentation, transparence, gestion des risques, informations sur entraînement, etc.) ?
- Alignement ISO/IEC 42001: quelles politiques, quels rôles, quels audits, quelle amélioration continue ?
- SecNumCloud: est-ce requis pour votre cas ? Si non, quelles exigences “type SecNumCloud” sont quand même respectées ?
Pour l’angle “cloud de confiance” dans des projets GenAI à Lyon, tu peux t’appuyer sur ce guide: https://lyon-ia.com/blog/cloud-et-ia-de-confiance-secnumcloud-utile-pour-vos-projets-genai-a-lyon-quand-lexiger. Et pour structurer une gouvernance IA inspirée d’ISO 42001: https://lyon-ia.com/blog/isoiec-42001-ia-a-quoi-sert-la-norme-et-comment-une-pme-lyonnaise-sen-inspire.
7) Performance et fiabilité: latence, qualité, limites, résilience
Un LLM “entreprise” doit être testable sur tes cas. Pas sur un benchmark marketing.
- Questions à poser:
- Quelles limites: tokens/minute, requêtes/minute, quotas, burst, files d’attente ?
- Latence: moyenne, P95, P99, par région, avec et sans contexte long.
- Résilience: multi-zone, plan de reprise, mécanismes de fallback, statut page, historique d’incidents.
- Engagements contractuels: SLA de disponibilité, temps de réponse support, pénalités, maintenance planifiée.
Si tu as déjà vécu des dépréciations d’API ou des changements de modèle, tu sais que la continuité est un vrai sujet. Tu peux formaliser un plan “anti panne” applicatif: https://lyon-ia.com/blog/fin-de-gpt-4o-et-depreciations-api-plan-anti-panne-pour-vos-apps-genai-a-lyon.
8) Modèle économique: coût total, prévisibilité, facturation
Le critère achat IA le plus mal traité, c’est le coût complet. Beaucoup regardent le prix token, personne ne regarde le reste, puis ça explose.
- Questions à poser:
- Facturation: tokens, requêtes, capacité réservée, instances, egress, stockage, RAG, logs, guardrails ?
- Prévisibilité: plafonds, alertes, budgets, rate limiting, mécanismes anti emballement.
- Coûts indirects: intégration SSO, mise en conformité, observabilité, run, MLOps, support.
- Clauses d’évolution tarifaire: révision, indexation, changements d’unités de facturation.
Pour lire une facture et comprendre le “coût du token” sans te faire balader: https://lyon-ia.com/blog/cout-du-token-facture-api-ia. Et pour remettre le coût dans une vision projet: https://lyon-ia.com/blog/cout-projet-ia-generative-entreprise.
9) Support, intégration et écosystème: qui t’aide quand ça casse, et avec quoi tu branches
Un LLM en entreprise, c’est un produit + une chaîne d’intégration. Et à Lyon, tu veux pouvoir mobiliser des compétences, internes ou locales, sans être dépendant d’un seul expert.
- Questions à poser:
- Support: horaires, canal, délais, support incident critique, langue, astreinte, CSM ?
- Run: outils d’observabilité, dashboards, métriques, traces, intégration SIEM.
- Intégration: SDK, compatibilité, connecteurs, RAG, bases vectorielles, orchestration, agents.
- Écosystème: partenaires intégrateurs, références proches de votre secteur, capacité à faire du VPC/on-prem si nécessaire.
Matrice de décision: un cadre simple, utilisable en comité achats à Lyon
Tu peux scorer chaque fournisseur sur 1 à 5, avec un poids selon ton contexte. Exemple de pondération typique “entreprise régulée” dans la métropole:
- Données (critère 1): poids 5
- Hébergement/isolation (critère 2): poids 4
- Souveraineté/sous-traitance (critère 3): poids 5
- Sécurité technique (critère 4): poids 4
- Logs/audit (critère 5): poids 4
- Conformité/gouvernance (critère 6): poids 4
- Fiabilité/SLA (critère 7): poids 3
- Coût total/prévisibilité (critère 8): poids 4
- Support/écosystème (critère 9): poids 3
Tu peux ensuite définir des critères éliminatoires avant même de scorer, par exemple: pas de mode zéro rétention contractuel, pas de VPC/on-prem possible alors que tes données l’exigent, impossibilité d’exporter des logs, refus d’audit raisonnable, sous-traitance opaque.
Questions à poser en appel d’offres (copier-coller)
- Données: “Confirmez contractuellement que nos prompts, documents, sorties et embeddings ne sont pas utilisés pour entraîner ou améliorer vos modèles, sauf opt-in explicite. Précisez la rétention par type de donnée.”
- Architecture: “Fournissez une architecture cible selon 3 modes: SaaS, tenant dédié, VPC et on-prem si disponible. Indiquez clairement qui administre quoi.”
- Sous-traitants: “Listez tous les sous-traitants impliqués dans le service, y compris monitoring et support. Indiquez les localisations exactes des traitements, logs, sauvegardes.”
- Accès support: “Décrivez le processus d’accès support (just-in-time, bastion, MFA), les pays depuis lesquels il peut être exercé, et les traces disponibles.”
- Logs et audit: “Décrivez les logs disponibles (contenu ou non), leur durée de conservation, et les modalités d’export. Fournissez un exemple de schéma d’événements.”
- SLA: “Proposez SLA, pénalités, maintenance, et engagement de disponibilité par région. Précisez votre historique d’incidents et votre procédure d’escalade.”
- Économie: “Fournissez un chiffrage complet sur 12 mois: volume moyen, pics, coûts annexes (stockage, egress, observabilité, guardrails), et options de plafonnement.”
- Réversibilité: “Décrivez la procédure de sortie: export des données, des embeddings, des logs, délais, coûts, formats, effacement attesté.”
- Conformité: “Fournissez DPA, documentation AI Act pertinente, certifications (le cas échéant), et éléments de preuve auditable.”
Le point final qui change tout: achète un mode d’exploitation, pas un modèle
La demande “IA sécurisée/souveraine” qui alimente les levées type Cohere, c’est une demande de run: architecture, contrat, audit, support, preuves. Le modèle n’est qu’une brique.
Plan d’action concret pour une entreprise lyonnaise sur 30 jours:
- Semaine 1: écris 2 pages “exigences minimales” sur données, logs, souveraineté, SLA. Mets achats, DPO, RSSI autour de la table.
- Semaine 2: fais un test sur 2 cas d’usage réels avec jeu de tests et contraintes (latence, coût, zéro rétention, export logs).
- Semaine 3: demande l’architecture et les annexes contractuelles (DPA, sous-traitants, réversibilité). Ce qui n’est pas écrit n’existe pas.
- Semaine 4: score avec ta matrice, fixe 2 ou 3 critères éliminatoires, et prépare un pilote avec métriques (qualité, coût, risque).
Si tu fais ça, tu réponds vraiment au besoin “choisir un LLM entreprise” sans tomber dans la guerre de logos. Et tu transformes “IA souveraine” et “IA sécurisée entreprise” en critères achat IA vérifiables, opposables, et pilotables. Sources: PR Newswire (29/10/2026), TechCrunch (22/07/2024), Cohere blog (14/08/2025), Commission européenne (AI Act en vigueur 01/08/2024), EUR-Lex (règlement 2024/1689), CNIL (FAQ 18/07/2024), ANSSI cyber.gouv.fr (SecNumCloud v3.2), ISO (ISO/IEC 42001:2023).
Laisser un commentaire