Shadow IT : passer de l’interdiction au catalogue SaaS encadré

Comparer les réponses possibles

Trois attitudes reviennent souvent. La première consiste à bloquer tout outil non validé. Elle semble claire, mais elle déplace parfois les usages vers des comptes personnels ou des échanges moins visibles. La deuxième consiste à accepter les outils métiers tant qu’aucun incident n’est remonté. Elle préserve la vitesse, mais rend les dépendances difficiles à maîtriser. La troisième consiste à créer un catalogue vivant : certains outils sont autorisés, d’autres refusés, et les nouveaux besoins suivent un parcours court.

| Approche | Ce qu’elle protège | Ce qu’elle risque | Quand l’utiliser | | --- | --- | --- | --- | | Interdiction stricte | La cohérence technique et contractuelle | Des contournements invisibles | Pour les usages clairement incompatibles avec les exigences internes | | Tolérance au cas par cas | La réactivité métier | Une accumulation de données et de comptes non suivis | Pour des expérimentations limitées, datées et réversibles | | Catalogue SaaS encadré | La vitesse avec un minimum de contrôle | Un effort de maintenance du catalogue | Pour les besoins récurrents ou transverses |

Le catalogue n’est pas une liste figée validée une fois pour toutes. Il décrit plutôt les conditions d’usage : qui peut créer un espace, quelles données sont admises, comment les accès sont retirés, quel support est assuré et comment l’outil peut être quitté.

Partir des usages, pas des outils

Un inventaire efficace ne commence pas par une chasse aux logos. Il commence par les gestes de travail : collecter des demandes, signer un document, enrichir un fichier client, publier un formulaire, traduire un contenu, suivre un planning ou analyser des tickets. Deux outils différents peuvent porter le même risque si le même type de données y circule.

Cette lecture par usage évite de traiter tous les SaaS de la même manière. Un tableau blanc collaboratif pour un atelier interne n’appelle pas le même niveau de contrôle qu’un outil qui reçoit des données RH, des exports commerciaux ou des informations liées à la facturation. La gouvernance devient plus acceptable lorsqu’elle distingue les zones de risque au lieu d’imposer une validation lourde à chaque demande.

Définir des niveaux d’usage

Un catalogue utile peut classer les outils en niveaux simples. Le niveau expérimentation autorise un test limité, sans donnée sensible et avec une date de revue. Le niveau équipe permet un usage récurrent sur un périmètre identifié. Le niveau entreprise suppose une gestion plus forte des identités, des droits, de la contractualisation, du support et de la réversibilité.

Ce classement aide la DSI à parler le langage des métiers. Une demande n’est plus seulement acceptée ou refusée. Elle peut être acceptée pour un test court, réorientée vers un outil déjà disponible, ou transformée en projet si elle devient structurante.

Chronologie d’une reprise en main

1. **Semaine 1 : cartographier les usages visibles.** Interroger les responsables métiers, l’assistance informatique, les achats et les équipes projet pour repérer les outils déjà utilisés. 2. **Semaine 2 : classer les données manipulées.** Identifier les usages sans données sensibles, ceux qui touchent des données internes et ceux qui impliquent des informations critiques. 3. **Semaine 3 : choisir les premières règles.** Fixer les usages interdits, les usages testables et les usages qui nécessitent une validation renforcée. 4. **Semaine 4 : publier un premier catalogue.** Mieux vaut un catalogue court et maintenu qu’un portail complet jamais adopté. 5. **Mois 2 : traiter les doublons.** Lorsque plusieurs équipes paient des outils proches, comparer les besoins réels avant d’imposer une consolidation. 6. **Mois 3 : organiser la revue.** Vérifier les comptes actifs, les propriétaires, les données présentes et les sorties possibles.

Installer une validation courte

Le point faible de beaucoup de démarches reste le délai. Si la validation prend plusieurs semaines pour un usage simple, les équipes chercheront une autre voie. Le parcours doit donc être proportionné : quelques questions pour un test sans donnée sensible, une analyse plus complète pour un outil qui devient critique.

Un formulaire léger peut suffire pour démarrer : objectif métier, type de données, utilisateurs concernés, durée prévue, besoin d’intégration, existence d’un outil déjà disponible et responsable désigné. Les réponses doivent produire une décision actionnable, pas ouvrir une longue série de réunions.

Checklist avant d’ajouter un SaaS au catalogue

• Le besoin métier est formulé sans citer uniquement le nom de l’outil.
• Un responsable interne de l’usage est identifié.
• Les catégories de données autorisées sont écrites clairement.
• Les règles de création et de suppression des comptes sont définies.
• Les accès administrateur sont limités et connus.
• La sortie de l’outil a été examinée, notamment l’export des données et des preuves utiles.
• Le support attendu est réaliste pour la DSI et pour le métier.
• La date de réexamen est fixée avant généralisation.

Cette checklist rejoint deux sujets déjà traités par DEV N SI : la réversibilité d’un logiciel SaaS et la protection des comptes par MFA. Le shadow IT rend ces sujets plus difficiles parce qu’ils doivent être rattrapés après coup, lorsque l’outil est déjà installé dans les habitudes.

Accepter certains tests pour éviter les angles morts

Tout refuser peut donner une impression d’ordre, mais l’organisation perd alors des signaux utiles. Les métiers expérimentent parce qu’ils rencontrent des limites dans les outils existants : lenteur, manque d’autonomie, fonctionnalité absente, ergonomie trop lourde ou besoin ponctuel non priorisé. Ces essais peuvent révéler une amélioration à apporter au SI officiel.

La tolérance contrôlée donne un cadre à cette exploration. Elle autorise des pilotes courts, avec un périmètre explicite et une sortie prévue. L’outil ne devient pas automatiquement un composant durable du système d’information. Il doit franchir un seuil de maturité : usage récurrent, dépendance métier, données significatives ou intégration avec d’autres services.

Illustrer le modèle cible

*Un catalogue SaaS encadré relie chaque besoin métier à un niveau d’usage, une règle de validation et une date de revue.*

Le modèle cible reste volontairement simple : un besoin entre dans le catalogue, reçoit un niveau d’usage, puis suit une revue périodique. Les outils refusés ne disparaissent pas du radar : ils alimentent une liste d’irritants, utile pour comprendre ce que les équipes ne trouvent pas dans l’offre existante.

Mesurer la progression sans créer une usine à gouvernance

Les bons indicateurs sont proches de l’action. Combien d’outils ont un responsable identifié ? Combien d’usages manipulent des données sensibles sans cadre suffisant ? Combien de comptes restent actifs après le départ d’un utilisateur ? Combien de doublons peuvent être regroupés sans casser un processus métier ?

Ces mesures ne servent pas à produire un tableau de conformité décoratif. Elles permettent de décider : retirer un outil, renforcer l’authentification, négocier un contrat, former une équipe, ou intégrer officiellement une solution devenue utile.

Prochaine étape

Pour lancer la démarche, choisissez un périmètre réduit : un service métier, une famille d’outils ou un type de données. L’objectif du premier mois n’est pas de reprendre tout le shadow IT. Il est de prouver qu’un cadre court, lisible et proportionné peut sécuriser les usages sans bloquer l’autonomie qui les a fait naître.