Claude et votre DSI : sécuriser sans tuer le projet

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.

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.