Claude Enterprise : les décisions d’architecture qui conditionnent la réussite de votre projet IA

Cet article traite de ce premier chantier, celui sans lequel le second ne tient pas.

Avec son offre Enterprise, Anthropic fournit les briques pour répondre à ces questions. Mais des briques ne font pas une architecture. Cet article décrit le travail d'étude et de conception à mener lors d'un déploiement de Claude Enterprise, et les décisions qu'il faut prendre avant d'ouvrir le service.

Les fonctions de sécurité existent. Ce qui manque presque toujours, c'est la décision de les configurer, dans le bon ordre, et en cohérence avec le reste du système d'information.

Pourquoi un déploiement d'IA générative est-il d'abord un projet d'architecture ?

Parce que l'assistant IA n'est pas un outil isolé. Il se branche sur l'annuaire de l'entreprise, reçoit des documents parfois sensibles, produit des traces qui intéressent la conformité et la sécurité, et stocke des données chez un tiers.

Concrètement, cinq exigences reviennent dans tous les cahiers des charges :

• des contrôles d'accès fins, par rôle - Role-Based Access Control (RBAC) ;
• un provisionnement automatique des comptes depuis l'annuaire - System for Cross-domain Identity Management(SCIM) ;
• des journaux d'audit et une API de conformité, intégrés aux outils de sécurité comme Microsoft Purview ;
• une rétention des données paramétrable ;
• des clés de chiffrement gérées par le client - Customer-Managed Encryption Keys (CMEK).

Chacune de ces exigences a une réponse technique. Mais chacune soulève aussi des questions d'organisation, de conformité et de compromis. C'est là que se joue la réussite du projet.

Étape 1 — Étudier l'existant avant de dessiner la cible

Avant de configurer quoi que ce soit, il faut comprendre l'environnement dans lequel l'outil va s'insérer.

• L'identité : quel annuaire (Entra ID, Okta…) ? Le SSO et le SCIM sont-ils déjà pratiqués ? Existe-t-il des groupes par métier ?
• La sécurité : l'entreprise dispose-t-elle de licences Purview ? D'un SIEM ? D'un SOC, interne ou externalisé ?
• Les données : quelles catégories seront confiées à l'IA ? Existe-t-il une classification ou des étiquettes de sensibilité ?
• Les obligations : NIS2, secteur régulé, clauses contractuelles, exigences de localisation des données ?
• Les usages actuels : des collaborateurs utilisent-ils déjà des outils d'IA avec des comptes personnels ?

Ce dernier point est souvent le plus révélateur. Le « shadow AI » est rarement nul. Le déploiement d'un outil officiel est aussi l'occasion de le résorber.

Étape 2 — Concevoir l'architecture cible

L'architecture s'organise autour de trois piliers :

• l'annuaire, source de vérité des identités et des groupes ;
• la plateforme Claude Enterprise, où s'appliquent les rôles et les politiques ;
• l'environnement de sécurité du client, qui exploite les journaux et, le cas échéant, détient les clés.

Contrôle d'accès : raisonner par groupe, jamais par utilisateur

Les droits se pilotent par des rôles personnalisés rattachés à des groupes. Un groupe par profil métier, un rôle par groupe, le strict nécessaire pour chacun.

Les rôles d'administration, eux, doivent rester limités à quelques personnes nommées.

Provisionnement : SCIM plutôt que la création à la volée

La création de comptes « à la première connexion » est tentante, car simple. Elle a un défaut majeur : elle ne supprime jamais les comptes.

Avec SCIM, l'annuaire devient l'unique source de vérité. Un départ dans l'annuaire, et l'accès disparaît automatiquement. L'ordre compte : vérification du domaine, SSO testé puis imposé, et seulement ensuite SCIM.

Traçabilité : une source, deux métiers

C'est souvent le point le plus mal compris.

La console d'administration permet d'exporter des journaux d'audit. Mais l'outil structurant est l'API de conformité d’Anthropic (Compliance API) : elle expose les événements d'audit et le contenu des conversations, et c'est elle qu'utilisent les outils tiers.

Tant que l'API de conformité n'est pas activée, rien n'est enregistré. Et ce trou ne se rattrape pas. Elle s'active le premier jour.

Faut-il ensuite alimenter Microsoft Purview, un SIEM, ou les deux ? Tout dépend de qui, dans l'entreprise, va exploiter ces données :

• Purview sert la conformité. Il regarde ce qui est écrit : des données personnelles collées dans une conversation, un document confidentiel partagé. C'est l'outil du DPO.
• Le SIEM sert la sécurité. Il regarde qui fait quoi, d'où et quand, et croise ces événements avec le reste : une connexion depuis l'étranger juste après un échec d'authentification, suivie d'un export massif. C'est l'outil du SOC.

Ce n'est donc pas un doublon : la même donnée sert deux métiers. Une PME sans SOC se contentera de Purview, ou d'une simple archive. Une organisation soumise à NIS2 et dotée d'un SOC aura besoin des deux.

Rétention : deux politiques, pas une

La durée de conservation est paramétrable, avec un minimum de 30 jours. Mais attention : les conversations et les projets obéissent à des politiques distinctes, et les projets sont conservés indéfiniment par défaut.

Ne régler que la rétention des conversations laisse donc échapper tout ce qui est rangé dans des projets. Et une suppression est définitive : si une obligation d'archivage existe, il faut exporter avant la purge.

Étape 3 — Maîtriser les risques : le cas des clés de chiffrement

Les clés de chiffrement gérées par le client sont souvent présentées comme le sommet de la sécurité. Elles le sont. Mais elles ont un prix, et il faut le connaître avant de signer.

Ce que la CMEK apporte

Le client chiffre ses données stockées avec sa propre clé, hébergée dans son coffre (AWS, Google Cloud ou Azure). Il peut tracer chaque usage de la clé, et la révoquer.

Ce qu'elle coûte

À la date de rédaction, selon la documentation d'Anthropic :

• l'activation est définitive et ne s'applique pas aux données déjà présentes ;
• elle couvre toute l'organisation, sans exception par utilisateur ;
• les opérations de chiffrement sont traitées dans des régions américaines, un point à examiner de près au regard des exigences de localisation d'une entreprise européenne ;
• plusieurs fonctions disparaissent : recherche dans les conversations, certains outils comme Claude Code sur le web, export des journaux depuis la console, partage public des artefacts…
• une révocation rend les données chiffrées définitivement illisibles, en moins d'une heure.

La CMEK n'est pas un réflexe. C'est une décision de gouvernance, qui revient au RSSI et au DPO.

Trois options se présentent en général : la CMEK pour tous, aucune CMEK avec une rétention courte et une traçabilité solide, ou une séparation entre une population sensible et les autres. Aucune n'est meilleure dans l'absolu. Celle qui convient dépend des obligations réelles de l'entreprise, pas de l'intuition.

Étape 4 — Déployer dans le bon ordre

L'ordre des opérations n'est pas un détail. Plusieurs décisions sont irréversibles ou non rétroactives.

1. Identités : domaine, SSO imposé, SCIM et groupes.
2. Traçabilité : activation de l'API de conformité, avant les premiers utilisateurs.
3. Chiffrement : décision CMEK, puis activation si elle est retenue, avant toute donnée sensible.
4. Droits : rôles personnalisés, validés sur un groupe pilote.
5. Rétention : politiques alignées avec le DPO et l'archivage.
6. Exploitation : connexion à Purview et/ou au SIEM.
7. Conformité : registre des traitements, analyse d'impact si nécessaire.

Viennent ensuite l'extension progressive à davantage d'utilisateurs et l'ouverture aux outils complémentaires : connecteurs, agents, outils de développement. Chacun mérite d'être évalué au regard des choix faits plus haut, car la CMEK, notamment, conditionne ce qui reste disponible.

Et la conduite du changement ?

Une architecture parfaitement sécurisée qui n'est pas adoptée ne sert à rien.

Le déploiement doit s'accompagner d'une formation des administrateurs, de règles d'usage claires pour les collaborateurs (quelles données confier, lesquelles jamais), et de quelques ambassadeurs métier qui feront vivre l'outil. C'est aussi ce qui permet de passer d'un groupe pilote à l'ensemble des équipes sans perdre la maîtrise.

Et après le socle ?

Une fois la plateforme sécurisée, le vrai potentiel s’ouvre : identification des cas d’usage à fort impact, connecteurs vers vos outils, agents, automatisation des tâches récurrentes, mesure des gains.

Comment OPNEO vous accompagne

OPNEO intervient comme DSI à temps partagé ou de transition. Sur ce type de projet, nous apportons :

• une étude de l'existant : identité, sécurité, données, obligations et usages actuels de l'IA ;
• la conception de l'architecture cible et de la configuration de la plateforme ;
• un registre des risques et des notes de décision pour les choix structurants, CMEK en tête ;
• le pilotage du déploiement, dans le bon ordre, avec les équipes internes et les prestataires ;
• la mise en conformité : RGPD, NIS2, AI Act, cohérence avec un SMSI ISO 27001 ;
• des cas d’usage IA à forte valeur : de l’identification au déploiement, une fois le socle en place ;
• la conduite du changement : formation, règles d'usage, accompagnement des premiers utilisateurs jusqu'à la généralisation.

Notre conviction est simple : l'IA générative est un formidable levier, à condition d'être déployée comme n'importe quel composant critique du système d'information. Avec méthode.

Vous préparez un déploiement de Claude Enterprise, ou d'un autre assistant IA ? Parlons-en.