Personne ne les a commandées, personne ne les documente, et pourtant elles font tourner une partie de votre entreprise. Les automatisations bricolées par les salariés eux-mêmes, dans un coin de Power Automate ou dans une macro Excel, sont devenues la forme la plus courante du shadow IT en PME. La bonne réponse n'est ni la tolérance résignée, ni l'interdiction générale.

Le shadow IT a changé de nature

Pendant quinze ans, le shadow IT désignait des logiciels installés sans autorisation ou des abonnements payés sur la carte bancaire d'un service. Aujourd'hui, ce qui échappe au contrôle n'est plus seulement un outil : c'est un traitement automatique qui lit des données, les transforme et les envoie ailleurs, sans que personne ne l'ait validé.

La cause est simple et plutôt saine. Les plateformes d'automatisation sont devenues assez accessibles pour qu'un responsable ADV, un chargé de recrutement ou un conducteur de travaux construise lui-même le petit enchaînement qui lui fait gagner deux heures par semaine. Chez Microsoft, cette ouverture est même le comportement par défaut : la documentation Power Platform rappelle que tout utilisateur disposant d'une licence est membre de l'environnement par défaut avec le rôle de créateur, et qu'on ne peut pas l'empêcher d'y créer des applications ou des flux. Le levier de contrôle porte sur les connecteurs autorisés, via les stratégies de données, pas sur le droit de créer.

Ce que dit le rapport IBM 2026

Dans son Cost of a Data Breach Report 2026, consulté le 10 septembre 2026, IBM annonce un coût mondial moyen de 4,99 millions de dollars par violation de données, en hausse de 12 % sur un an, et une progression de 56 % des attaques s'appuyant sur l'IA. À l'inverse, les organisations qui utilisent massivement l'IA et l'automatisation dans leur dispositif de sécurité économisent en moyenne 1,93 million de dollars par incident. L'automatisation n'est donc pas le problème : son absence de cadre l'est.

L'édition précédente chiffrait déjà le phénomène côté outils non déclarés. Dans l'analyse publiée par IBM le 12 novembre 2025, 20 % des organisations étudiées avaient subi une violation liée à des outils d'IA adoptés sans validation, avec jusqu'à 670 000 dollars de surcoût, et 97 % de celles touchées par une violation impliquant l'IA reconnaissaient ne pas disposer de contrôles d'accès appropriés. Ce qui coûte cher n'est donc pas l'outil inconnu en lui-même : ce sont les droits d'accès qui traînent derrière lui.

Les cinq cachettes habituelles

Dans une PME de 30 à 200 personnes, les automatisations non recensées se trouvent presque toujours aux mêmes endroits :

  • L'environnement par défaut de Power Platform, où s'accumulent des flux créés au fil des années, souvent sans copropriétaire.
  • Les règles de boîte aux lettres : transferts automatiques, classements, réponses conditionnelles. Le shadow IT le plus ancien et le plus discret.
  • Les comptes personnels d'outils grand public (Zapier, Make, IFTTT) ouverts avec une adresse professionnelle mais gérés à titre individuel.
  • Les classeurs Excel à macros qui rapatrient des extractions et produisent le fichier envoyé chaque lundi à la direction.
  • Les scripts et tâches planifiées installés sur un poste de travail, qui tournent tant que le poste reste allumé.

À cette liste s'ajoute désormais une sixième cachette : les assistants configurés directement par les utilisateurs, qui lisent des documents internes pour produire des synthèses. La logique est la même, l'exposition est plus large.

Le jour où ça casse : le départ d'un salarié

Le point de rupture est presque toujours le même, et il n'a rien de spectaculaire. Un salarié part, son compte est désactivé, et trois semaines plus tard un fichier n'arrive plus, une synchronisation s'est arrêtée sans alerte.

Microsoft documente précisément ce cas. Sa base de connaissances 4556130, mise à jour le 15 juin 2026, définit le flux orphelin comme un flux qui n'a plus de propriétaire valide, et précise que ces flux échouent lorsqu'ils utilisent des connexions rattachées au compte supprimé. La parade tient en une phrase : ajouter un copropriétaire. L'administrateur repère les flux sans propriétaire depuis le centre d'administration Power Platform, onglet Ressources, ou traite le parc en lot avec les commandes Get-AdminFlowOwnerRole et Set-AdminFlowOwnerRole.

Le principe vaut bien au-delà de Microsoft : une automatisation qui s'authentifie avec le compte nominatif d'un salarié est une panne programmée. Elle attend une démission, un congé longue durée ou une réinitialisation de mot de passe.

Inventorier sans jouer à la police

La tentation est d'envoyer une note interdisant toute automatisation non validée. C'est la meilleure façon de rendre le phénomène invisible plutôt que de le réduire. Une démarche en quatre temps donne de bien meilleurs résultats.

  1. Amnistie annoncée. Demandez à chaque service de déclarer ce qui tourne, en expliquant que l'objectif est de fiabiliser, pas de sanctionner. Une réunion de trente minutes par service produit souvent plus qu'un audit technique.
  2. Relevé technique de contrôle. Côté administration, listez les flux existants, les règles de transfert de messagerie et les applications tierces autorisées sur votre annuaire. Vous y trouverez ce que la déclaration a oublié.
  3. Tri par conséquence, pas par technologie. Pour chaque automatisation, posez trois questions : que se passe-t-il si elle s'arrête sans prévenir, quelles données sortent de l'entreprise, qui s'en aperçoit.
  4. Reprise des cas critiques. Seules les automatisations qui portent un processus réel méritent d'être reconstruites proprement, avec une identité applicative dédiée, une journalisation et une alerte en cas d'échec.

Trois garde-fous qui suffisent en PME

Inutile de bâtir un comité de gouvernance. Trois règles couvrent l'essentiel du risque.

La propriété appartient à l'entreprise. Chaque automatisation qui compte a deux propriétaires nommés, dont un responsable métier, et s'exécute sous une identité applicative plutôt que sous le compte d'une personne. Les comptes des plateformes utilisées sont ouverts au nom de l'entreprise.

Les connecteurs sont encadrés. Une stratégie de données qui sépare les connecteurs professionnels des services grand public évite le scénario le plus coûteux : la donnée client qui part vers un service non contractualisé. C'est le point de contrôle réellement disponible dans l'environnement par défaut.

Le silence n'est pas un succès. Une automatisation sans supervision ne signale jamais ses pannes. Une alerte vers une boîte partagée en cas d'échec et un contrôle mensuel sur une valeur métier vérifiable évitent les découvertes tardives.

Le volet conformité, en pratique

Une automatisation construite hors cadre crée souvent un flux de données personnelles qui n'apparaît nulle part : ni dans votre documentation interne, ni dans vos contrats. Si un flux recopie chaque nuit votre base clients vers un service tiers ouvert sur un compte personnel, vous ne pouvez ni dire où sont ces données, ni les faire supprimer, ni y couper l'accès au départ du salarié. La règle de bon sens tient en une ligne : toute automatisation qui fait sortir des données de votre système d'information doit être connue, contractualisée et réversible.

Questions fréquentes

Qu'appelle-t-on shadow IT dans le domaine des automatisations ?

Il s'agit de tout enchaînement automatique créé et exploité sans validation de l'entreprise : flux no-code, règles de messagerie, macros, scripts planifiés ou assistants configurés par un utilisateur. La particularité est qu'ils manipulent des données réelles avec les droits de la personne qui les a créés.

Faut-il interdire aux salariés de créer leurs propres automatisations ?

Non, et c'est rarement possible techniquement. Chez Microsoft, tout utilisateur licencié peut créer des flux dans l'environnement par défaut. L'approche efficace consiste à encadrer les connecteurs autorisés, à recenser l'existant et à reprendre uniquement les automatisations qui portent un processus critique.

Comment savoir combien d'automatisations tournent déjà chez nous ?

Croisez deux sources : une déclaration par service, sans reproche, et un relevé technique côté administration (flux existants, règles de transfert de messagerie, applications tierces autorisées sur l'annuaire). L'écart entre les deux listes est instructif.

Que devient une automatisation quand son créateur quitte l'entreprise ?

Elle ne disparaît pas, mais elle cesse souvent de fonctionner. Microsoft indique qu'un flux sans propriétaire valide échoue dès qu'il utilise une connexion liée au compte supprimé. Ajouter un copropriétaire avant le départ, et basculer sur une identité applicative, évitent la panne silencieuse.

Une automatisation créée par un salarié pose-t-elle un problème de conformité ?

Elle le peut, dès lors qu'elle fait circuler des données personnelles vers un outil non contractualisé. Le risque pratique est de ne plus savoir où sont les données ni comment y couper l'accès. Recenser les flux sortants et vérifier les contrats des services utilisés traite la majorité des cas.

Vous soupçonnez qu'une partie de vos processus repose sur des automatisations que personne ne maîtrise ? Nous réalisons l'inventaire et reprenons proprement ce qui doit l'être. Parlons de votre projet, ou découvrez notre approche de l'automatisation des tâches métiers.