Les garde-fous IA : une architecture, pas une charte

La plupart des entreprises qui déploient l’IA rédigent une charte d’usage. Douze pages, validées en comité, signées par tous — et jamais relues. Les garde-fous IA qui fonctionnent sont d’une autre nature : ils ne sont pas écrits dans un document, ils sont définis dans l’architecture. Ce que Claude peut lire, ce qu’il ne peut jamais lire, quelles données restent en interne, quelles actions exigent une validation humaine : autant de permissions configurées dans le système, pas de consignes confiées à la mémoire des collaborateurs.

La différence tient en une image : la charte est un panneau de limitation de vitesse, l’architecture est une glissière de sécurité. Le panneau suppose que chacun le voie, s’en souvienne et choisisse de le respecter — y compris pressé, fatigué, un vendredi à 18 h. La glissière ne suppose rien : elle empêche la sortie de route.

Pourquoi les chartes échouent — mécaniquement

Ce n’est pas une question de discipline ou de culture d’entreprise. Une charte d’usage IA échoue pour des raisons structurelles : elle exige un comportement parfait, permanent, de la part de chaque collaborateur, dans l’outil le plus fluide qu’ils aient jamais utilisé. Il suffit d’un copier-coller de trop — un fichier client dans une conversation, un extrait de contrat pour « gagner du temps » — et la règle est violée sans même que son auteur s’en rende compte.

Le paradoxe est cruel : plus l’IA est adoptée, plus la charte est violée, puisque chaque usage est une occasion d’écart. Les entreprises que nous auditons le constatent toutes — celles qui ont une charte stricte et aucune architecture ont simplement une charte stricte et des usages incontrôlés. Souvent accompagnés d’un shadow IT prospère : les outils interdits, utilisés sur téléphone personnel.

À quoi ressemblent des garde-fous architecturaux ?

Concrètement, les garde-fous — le troisième pilier du Harness, la couche d’orchestration entre Claude et vos process — se déclinent en quatre familles de permissions :

• Les périmètres de lecture : quelles sources Claude peut consulter, par équipe et par usage — le contexte Sales n’expose pas les données RH, et inversement.
• Les zones interdites : les données qui ne transitent jamais — paie, données de santé, secrets industriels — parce que la connexion n’existe pas, tout simplement.
• Les validations obligatoires : les actions que Claude prépare mais ne déclenche jamais seul — un envoi client, une écriture dans un système, une publication.
• La traçabilité : qui a utilisé quoi, sur quelles données — non pour surveiller les personnes, mais pour pouvoir répondre le jour où la question est posée.

Le garde-fou est un levier d’adoption, pas un frein

L’intuition dit le contraire, l’expérience est constante : les équipes utilisent davantage un système bien bordé. La raison est simple — l’incertitude paralyse. Quand personne ne sait ce qui est autorisé, chacun s’autocensure ou transgresse ; les prudents n’utilisent rien, les audacieux utilisent tout. Quand les limites sont dans l’architecture, la question ne se pose plus : tout ce qui est possible est autorisé, par construction.

L’autre bénéficiaire est la DSI. Une charte lui demande de faire la police d’usages qu’elle ne voit pas ; une architecture lui donne des périmètres qu’elle a validés elle-même. C’est souvent ce pilier qui décide de la survie du projet — les déploiements IA meurent rarement d’un problème technique, ils meurent en comité, faute de gouvernance démontrable.

Depuis août 2026, le garde-fou n’est plus seulement une bonne pratique

Quand cet article a été écrit, fin 2025, l’architecture de permissions était un argument de gestion du risque. Elle est devenue, depuis, un argument de conformité. Le règlement européen sur l’intelligence artificielle — règlement (UE) 2024/1689, dit AI Act — s’applique par vagues successives. Deux d’entre elles concernent déjà toute entreprise qui déploie Claude : l’article 4, qui impose au déployeur de prendre des mesures pour soutenir la « maîtrise de l’IA » chez les personnes qui l’utilisent pour son compte, est en vigueur depuis le 2 février 2025 ; les obligations de transparence de l’article 50 — informer un interlocuteur qu’il s’adresse à une IA, signaler les contenus générés — sont applicables depuis le 2 août 2026.

Le calendrier a été remanié en cours de route, ce qui explique une partie de la confusion ambiante. Le « Digital Omnibus » sur l’IA, adopté par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin, publié au Journal officiel de l’Union le 24 juillet 2026, a reporté les obligations les plus lourdes : les systèmes à haut risque de l’annexe III (recrutement, scoring de crédit, éducation, services essentiels) passent au 2 décembre 2027, ceux intégrés à des produits déjà réglementés (annexe I) au 2 août 2028 ; le marquage technique des contenus générés bénéficie d’un délai de grâce jusqu’au 2 décembre 2026. Ce qui a été reporté, ce sont les obligations documentaires du haut risque — ni la transparence, ni la maîtrise de l’IA. Ce même texte — règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026 — a en revanche réécrit l’article 4 dans son intégralité : l’obligation de formation subsiste, mais elle est passée d’une obligation de résultat à une obligation de moyens. Ce qui doit être démontré n’est plus le niveau atteint par chaque personne, c’est le dispositif mis en place pour le développer.

La conséquence pratique est modeste, mais elle tombe exactement là où cet article situe le problème. Si un assistant est exposé à des clients, ou si des contenus qu’il produit sont publiés, l’information de l’interlocuteur relève désormais du droit et non du choix éditorial : c’est typiquement une règle qui tient dans l’architecture — une mention configurée une fois, dans le gabarit — plutôt que dans une charte que chaque équipe appliquerait de mémoire. Quant à l’obligation de maîtrise de l’IA, elle se documente : savoir qui a été formé, à quoi et quand suppose un dispositif, pas un séminaire d’une heure. Le test de la glissière s’applique tel quel : si un collaborateur publie demain un texte généré sans mention, qu’est-ce qui l’en empêche ?

Faut-il jeter la charte ?

Non — mais il faut la remettre à sa place. Une page, pas douze : les principes, les responsabilités, l’esprit des règles. La charte dit pourquoi ; l’architecture fait respecter le comment. Tout ce qui dans votre charte actuelle est un interdit vérifiable a vocation à migrer dans l’architecture ; ce qui reste — le jugement, les cas limites, l’éthique d’usage — tient sur une page que l’on peut réellement lire.

Un test simple pour évaluer votre dispositif actuel : prenez les trois interdits les plus importants de votre charte, et demandez-vous ce qui se passe techniquement si un collaborateur les ignore demain matin. Si la réponse est « rien ne l’en empêche », vous n’avez pas des garde-fous — vous avez des vœux.

C’est le travail que nous menons avec la DSI pendant le Programme Autonomie Claude : transformer les vœux en permissions, dans l’architecture, dès la première semaine. Parce qu’un déploiement IA qui commence par ses garde-fous est un déploiement qui n’aura pas à s’arrêter.