· 7 min de lecture
Claude et votre DSI : sécuriser sans tuer le projet
Un projet Claude survit à sa DSI à une condition : définir les périmètres de données avec elle, dès le début, plutôt que de lui présenter un déploiement à valider après coup. Concrètement : classer les données par sensibilité, décider ce qui ne sort jamais du système d’information, anonymiser ce qui doit l’être, et inscrire ces règles dans l’architecture elle-même — pas dans une charte que personne ne lit.
Un projet Claude ne meurt presque jamais d’un problème technique. Il meurt en comité, quand la DSI pose la question à laquelle personne n’a préparé de réponse : « Où vont nos données ? ». La parade tient en une phrase : définir les périmètres de sécurité avec la DSI dès le début du projet — classer les données par sensibilité, décider ce qui ne sort jamais du système d’information, anonymiser ce qui doit l’être — plutôt que de lui présenter un déploiement à valider après coup.
La sécurité des données n’est pas l’obstacle du projet IA. C’est sa condition de survie. Et la DSI n’est pas l’adversaire à contourner : c’est le seul allié capable de rendre le projet défendable devant une direction, un client ou un auditeur.
Pourquoi la DSI dit non — et pourquoi elle a souvent raison
Mettez-vous à sa place. On lui demande de valider un outil que les équipes utilisent déjà en douce, sans qu’elle sache quelles données y transitent, sous quel contrat, avec quelles garanties. Son « non » n’est pas de l’obstruction : c’est la seule réponse rationnelle à une question mal posée.
Le tort des porteurs de projet est symétrique : arriver avec un outil choisi, un déploiement planifié, et demander une signature. La DSI découvre le projet en position de censeur — le seul rôle qu’on lui a laissé. Inversez l’ordre : arrivez avec des questions, pas avec un fait accompli, et le censeur devient architecte.
La conversation qui change tout : classer avant de connecter
Le travail commun avec la DSI commence par une cartographie des données, pas par un choix d’outil. Toutes les données de l’entreprise n’ont pas la même sensibilité, et les traiter comme un bloc mène à l’une des deux impasses : tout interdire, ou tout exposer.
La classification tient en trois niveaux dans la plupart des PME et ETI. Les données publiques ou sans enjeu — documentation produit, contenus marketing — circulent librement. Les données internes sensibles — contrats, données clients, éléments RH — ne transitent qu’anonymisées ou dans un cadre contractuel adapté. Et un noyau dur — paie, secrets industriels, données de santé le cas échéant — ne sort jamais du système d’information, quel que soit l’outil.
Cette cartographie a une vertu inattendue : elle montre presque toujours que l’essentiel des cas d’usage à forte valeur vit dans les deux premiers niveaux. Le projet peut donc démarrer vite, sur un périmètre incontesté, pendant que les questions difficiles du noyau dur se traitent posément — au lieu de bloquer tout le monde dès le premier jour.
Les décisions concrètes à poser avec la DSI
Une fois les données classées, les décisions s’enchaînent naturellement. Ce sont elles qui constituent le pilier garde-fous du Harness d’entreprise — la couche d’orchestration entre Claude et vos process :
- Le cadre contractuel : un déploiement d’entreprise, avec des engagements écrits sur l’usage des données — jamais des comptes grand public individuels pour un usage professionnel.
- Ce qui reste interne : les traitements sur données du noyau dur se font dans le système d’information, ou ne se font pas.
- L’anonymisation : remplacer noms, montants et identifiants avant envoi quand la tâche ne les requiert pas — la plupart des tâches ne les requièrent pas.
- Les accès : qui peut utiliser quels contextes et quels skills, aligné sur les droits existants du système d’information plutôt que réinventé à côté.
- La traçabilité : savoir quels usages tournent, sur quelles catégories de données, pour pouvoir répondre à un audit sans reconstruire l’historique à la main.
Ce que la DSI va demander — et ce qui est réellement documenté
Passé le cadrage, la DSI descend d’un cran : elle veut des pièces. Trois questions reviennent systématiquement, et toutes les trois ont une réponse publique — encore faut-il l’avoir sous la main plutôt que de la promettre pour le prochain comité.
Les certifications d’abord. Anthropic publie sur sa page de conformité régionale un SOC 2 Type 2 (sécurité, disponibilité, confidentialité), les normes ISO/IEC 27001 pour le management de la sécurité, 27017 pour la sécurité du cloud et 27018 pour la protection des données personnelles dans le cloud, ainsi qu’une inscription au registre CSA STAR. La prise en charge du HIPAA passe par un accord spécifique — le point à retenir pour une DSI française : ces certifications décrivent ce que la plateforme permet, pas ce que votre déploiement obtient automatiquement. Un audit se gagne sur la configuration, pas sur le logo du fournisseur.
L’entraînement ensuite. Anthropic indique ne pas utiliser par défaut les données des déploiements commerciaux pour entraîner ses modèles. C’est la réponse à la peur numéro un des comités de direction — et elle se vérifie dans le contrat, pas dans une page marketing : faites remonter l’engagement dans l’accord de traitement des données signé par votre entreprise.
La résidence des données enfin, et c’est là que les projets se cassent. Il n’existe pas de résidence européenne sur l’API directe d’Anthropic : les options de déploiement par pays passent par AWS Bedrock, Google Cloud Vertex AI ou Microsoft Foundry. Si votre DSI impose un traitement en Europe — clause contractuelle client, doctrine interne, secteur régulé —, ce choix d’hébergeur n’est pas un détail d’infrastructure à trancher plus tard : c’est une décision d’architecture qui conditionne le reste du projet, y compris les fonctionnalités disponibles. À vérifier au cadrage, pas à la mise en production.
La rétention : le paramètre que personne ne regarde
La question « entraînez-vous sur nos données ? » masque presque toujours la vraie : « combien de temps les gardez-vous ? ». Ce sont deux sujets distincts, et le second est un paramètre de votre déploiement — pas une propriété du fournisseur.
Sur les offres entreprise, les données sont conservées sans limite de durée tant qu’aucune période de rétention personnalisée n’est définie ; l’administrateur peut en configurer une, avec un plancher de trente jours. Autrement dit, une organisation qui n’a rien paramétré a choisi la conservation indéfinie sans le savoir. C’est typiquement le genre d’angle mort qu’un audit révèle au pire moment, et il se referme en une configuration.
Au-delà, la rétention zéro (ZDR) existe, mais elle n’est pas incluse d’office : elle s’active organisation par organisation, après confirmation d’éligibilité par l’équipe commerciale, et certains modèles imposant une rétention de trente jours en sont exclus sauf autorisation expresse. Deux conséquences pratiques. D’une part, la rétention zéro se négocie au contrat, pas au moment du déploiement — anticipez le délai. D’autre part, elle a un coût fonctionnel : restreindre les modèles disponibles change ce que vos cas d’usage peuvent faire. Arbitrez ce compromis avec la DSI et le métier ensemble, sur le périmètre de données qui le justifie vraiment — rarement sur la totalité des usages.
Ces éléments ont été vérifiés sur la documentation publique d’Anthropic en septembre 2026. Les politiques d’un éditeur évoluent : faites reconfirmer par écrit, au moment de la signature, les trois points qui engagent votre entreprise — entraînement, rétention, localisation.
Des règles dans l’architecture, pas dans une charte
Une charte d’usage que personne ne lit ne protège rien. Les périmètres définis avec la DSI doivent vivre dans l’architecture elle-même : les garde-fous sont configurés dans le système, pas confiés à la vigilance de chacun. Un utilisateur ne doit pas avoir à se demander s’il a le droit — le système le sait à sa place.
C’est ce déplacement qui change la position de la DSI : elle ne signe plus un pari sur la discipline des équipes, elle valide une architecture qu’elle a contribué à dessiner. Dans le Programme Autonomie Claude, ce travail se fait en début de sprint, avec elle — parce qu’un projet que la DSI a co-construit est un projet qu’elle défend.
Questions fréquentes
Comment convaincre sa DSI de déployer Claude en entreprise ?
En l’associant dès le début plutôt qu’en lui demandant de valider un projet ficelé. Concrètement : cartographier ensemble les données par niveau de sensibilité, définir ce qui ne sort jamais du système d’information, choisir un cadre contractuel d’entreprise et inscrire ces règles dans l’architecture. Une DSI qui co-construit les périmètres devient le meilleur allié du projet.
Quelles données ne faut-il jamais envoyer à une IA externe ?
Le noyau dur défini avec la DSI : données de paie, secrets industriels, données de santé, et toute donnée soumise à une obligation contractuelle ou réglementaire stricte. Pour les données internes sensibles — contrats, données clients —, l’anonymisation avant envoi suffit dans la plupart des cas, car la tâche n’a généralement pas besoin des noms ni des montants réels.
Les données d’entreprise envoyées à Claude sont-elles utilisées pour entraîner les modèles ?
Non par défaut : Anthropic indique ne pas utiliser les données des déploiements commerciaux pour entraîner ses modèles. C’est distinct de la question de la rétention, qui est un paramètre de votre déploiement : sur les offres entreprise, les données sont conservées sans limite de durée tant qu’aucune période personnalisée n’est configurée, le plancher configurable étant de trente jours. Les deux points doivent figurer dans l’accord de traitement des données signé, pas seulement dans une page publique.
Peut-on héberger Claude en Europe pour respecter la résidence des données ?
Pas via l’API directe d’Anthropic, qui n’offre pas de résidence européenne. Les options de déploiement par pays passent par AWS Bedrock, Google Cloud Vertex AI ou Microsoft Foundry. Si une contrainte de traitement en Europe s’impose — clause client, doctrine interne, secteur régulé —, ce choix d’hébergeur se tranche au cadrage du projet : il conditionne l’architecture et les fonctionnalités disponibles, et ne se rattrape pas en fin de parcours.
Une charte d’usage de l’IA suffit-elle à sécuriser les données ?
Non. Une charte repose sur la vigilance individuelle, qui cède toujours sous la pression du quotidien. Les règles doivent être inscrites dans l’architecture : garde-fous configurés dans le système, accès alignés sur les droits existants, anonymisation outillée. L’utilisateur ne doit pas avoir à se souvenir des règles — le système les applique pour lui.
Pour aller plus loin
Pour passer de la lecture à l'exécution : notre approche en 3 semaines et les résultats mesurés chez nos clients.
Lutece