Shadow AI : reprendre le contrôle sans bloquer les usages utiles de l’IA générative

Le shadow AI désigne les outils, modèles, comptes ou automatisations d’intelligence artificielle utilisés sans validation ou sans visibilité suffisante de l’organisation. Il peut s’agir d’un salarié qui colle un document dans un assistant gratuit, d’un développeur qui appelle une API avec une carte personnelle ou d’une équipe qui connecte un agent à sa messagerie sans revue de sécurité.

Le phénomène n’est pas uniquement un problème de discipline. Il révèle souvent un écart entre le besoin métier et la capacité de l’entreprise à proposer une solution. Une interdiction générale peut réduire quelques usages visibles tout en déplaçant les autres vers des comptes privés et des appareils non gérés.

Les outils et fonctions évoluent rapidement. Les recommandations doivent être adaptées au système d’information, aux contrats et aux obligations de l’organisation.

Pourquoi le shadow AI se développe

Les outils sont accessibles en quelques minutes et apportent un gain immédiat pour :

• rédiger ;
• traduire ;
• résumer ;
• analyser un fichier ;
• générer du code ;
• préparer une présentation ;
• transcrire une réunion ;
• automatiser des actions.

Le processus interne peut, lui, prendre plusieurs semaines. Si la politique se limite à « demandez une autorisation » sans délai ni alternative, l’utilisateur choisit souvent l’outil disponible.

D’autres causes s’ajoutent : fonctionnalités IA activées dans des logiciels déjà achetés, essais gratuits, absence de classification des données, confusion entre offre grand public et entreprise, ou méconnaissance des traces conservées.

Les risques ne se limitent pas à l’entraînement du modèle

Même lorsqu’un fournisseur affirme ne pas utiliser les données pour entraîner ses modèles, il faut examiner :

• conservation des prompts et fichiers ;
• logs de sécurité et support ;
• sous-traitants ;
• région de traitement ;
• accès administrateurs ;
• connecteurs ;
• partages publics ;
• propriété et licences ;
• incidents ;
• suppression ;
• évolution des conditions.

Les principaux risques sont la fuite de secret, l’exposition de données personnelles, la violation contractuelle, le code vulnérable, l’usage de contenu protégé, la décision non vérifiée et l’agent trop privilégié.

Cartographier sans transformer l’audit en chasse aux utilisateurs

Une démarche punitive décourage le signalement et détruit la visibilité. L’objectif est de comprendre les besoins et les chemins de données.

Les sources possibles sont :

• enquête anonyme ;
• ateliers métier ;
• demandes d’achat ;
• dépenses et cartes ;
• inventaire des extensions ;
• journaux de proxy ou CASB dans le respect du cadre social et juridique ;
• SSO ;
• analyse des applications SaaS ;
• revue des dépôts et secrets ;
• incidents de support.

Les résultats sont agrégés par type d’usage et classe de données. Ne pas publier un classement des « mauvais élèves ».

Classer les scénarios, pas seulement les outils

Un même assistant peut être acceptable pour reformuler un texte public et interdit pour analyser un dossier médical. La matrice combine :

• sensibilité de la donnée ;
• impact de la sortie ;
• autonomie ;
• droits d’accès ;
• capacité de vérification ;
• contrat et configuration ;
• traçabilité ;
• réversibilité.

Quatre réponses internes peuvent suffire :

1. usage libre dans un outil approuvé ;
2. usage autorisé avec conditions ;
3. revue préalable obligatoire ;
4. usage interdit.

Cette simplicité facilite l’adoption.

Fournir une voie approuvée suffisamment utile

L’organisation doit proposer un service qui répond aux usages fréquents :

• authentification entreprise ;
• contrat et région maîtrisés ;
• non-entraînement sur les données selon les conditions retenues ;
• espaces séparés ;
• modèles adaptés ;
• limite de taille et classification ;
• connecteurs approuvés ;
• support ;
• historique contrôlé ;
• possibilité de supprimer ;
• coût lisible.

Une passerelle multi-modèles peut router les requêtes selon la donnée et le besoin. Elle centralise authentification, quotas, filtrage, logs minimisés et choix de région, sans imposer un seul modèle à toutes les tâches.

L’expérience doit rester fluide. Si l’outil approuvé est lent, incapable de lire les formats courants ou inaccessible sur mobile, le contournement persistera.

Écrire une politique compréhensible

La politique tient sur une page de règles, complétée par une FAQ. Elle répond à des situations :

• Puis-je traduire un document client ?
• Puis-je envoyer du code propriétaire ?
• Puis-je connecter ma messagerie ?
• Puis-je générer une image commerciale ?
• Puis-je utiliser une sortie pour recruter ?
• Puis-je créer un compte avec mon email professionnel ?
• Que faire après une saisie accidentelle ?

Chaque réponse indique l’outil, la donnée, le niveau de revue et le contact. Les interdictions sont justifiées et accompagnées d’une alternative lorsque possible.

Déployer des contrôles techniques proportionnés

Les contrôles possibles incluent :

• SSO et gestion du cycle de vie des comptes ;
• blocage ciblé de services à risque ;
• DLP sur données sensibles ;
• extensions de navigateur gérées ;
• coffre de secrets ;
• passerelle API ;
• restrictions d’upload ;
• segmentation réseau ;
• connecteurs en lecture seule ;
• validation avant action ;
• quotas et alertes ;
• journal d’audit.

Un blocage réseau total peut être contourné par téléphone ou réseau personnel. Il doit être réservé aux scénarios justifiés et complété par la formation et l’offre approuvée.

Encadrer les connecteurs et agents

Le risque change d’échelle lorsqu’un outil accède aux fichiers, à l’email, au CRM ou au code. Il ne reçoit jamais par défaut tous les droits de l’utilisateur.

Exiger :

• OAuth ou identité de service dédiée ;
• permissions minimales ;
• portée et durée limitées ;
• environnement test ;
• actions sensibles confirmées ;
• logs ;
• révocation simple ;
• liste des outils ;
• protection contre la prompt injection ;
• revue des données envoyées aux sous-agents.

Une connexion « pratique » à l’ensemble du drive peut exposer des dossiers que l’utilisateur n’avait jamais l’intention de traiter.

Former à partir de cas réels

Une formation générique sur les hallucinations ne suffit pas. Les équipes doivent pratiquer :

• reconnaître les classes de données ;
• anonymiser ou minimiser ;
• vérifier une source ;
• éviter les secrets dans le code ;
• relire un résultat ;
• comprendre les partages ;
• signaler une erreur ;
• utiliser l’environnement approuvé.

Les managers apprennent à ne pas imposer une productivité IA sans fournir le cadre. Les acheteurs et administrateurs apprennent à détecter les fonctions activées par défaut.

Mettre en place un processus d’exception rapide

Une équipe peut avoir besoin d’un modèle spécialisé absent du catalogue. L’exception recueille : finalité, données, durée, fournisseur, test, propriétaire et mesures compensatoires.

Le délai est proportionné. Une expérimentation sur données synthétiques peut être approuvée rapidement. Un agent RH connecté nécessite une revue complète.

L’exception expire et n’autorise pas automatiquement la production.

Réagir à une exposition accidentelle

La procédure doit être connue avant l’incident :

1. arrêter l’envoi et préserver les éléments utiles ;
2. identifier outil, compte, données et destinataires ;
3. vérifier les capacités de suppression et le support ;
4. révoquer tokens et connecteurs ;
5. informer sécurité, DPO et responsables selon le cas ;
6. évaluer l’impact et les obligations de notification ;
7. corriger le processus ;
8. partager le retour sans stigmatiser.

Un utilisateur qui signale rapidement réduit le risque. La culture doit donc valoriser le signalement.

Mesurer la réduction du risque

Suivre :

• taux d’adoption des outils approuvés ;
• délai d’accès ;
• demandes d’exception ;
• usages non couverts ;
• incidents et quasi-incidents ;
• données bloquées par classe ;
• connecteurs actifs ;
• comptes personnels détectés ;
• satisfaction ;
• coût par usage utile.

Une baisse du trafic vers les outils non approuvés n’est pas suffisante si les équipes n’ont plus de solution ou utilisent leur téléphone.

Un programme en 90 jours

0–30 jours

Inventorier, publier des règles temporaires, traiter les données les plus sensibles, proposer un outil de base et ouvrir un canal de questions.

31–60 jours

Classer les usages, négocier les configurations, déployer identité et passerelle, former les équipes prioritaires et créer le processus d’exception.

61–90 jours

Intégrer le registre, les connecteurs, les mesures, les revues et la gestion d’incident. Ajuster l’offre selon les besoins réels.

Reprendre le contrôle par la qualité du service

Le shadow AI diminue lorsque le chemin autorisé devient le chemin le plus simple pour les usages légitimes. La sécurité conserve des portes fortes pour les données et actions critiques, mais l’entreprise reconnaît aussi la valeur des outils.

Partitech peut conduire l’inventaire technique, construire la passerelle, intégrer le SSO, les modèles, les contrôles et le monitoring, puis déployer des parcours adaptés aux équipes. Le résultat attendu n’est pas une interdiction théorique, mais une utilisation visible, gouvernée et réellement adoptée.

Parlons de votre projet

Auditer les usages IA et déployer un cadre sécurisé et adoptable avec Partitech. Contactez Partitech.