Presque chaque entreprise exploite un second paysage informatique qui ne figure dans aucun inventaire : le fichier Excel du planning d'équipe, la base Access de 2009 pour la gestion des moyens de contrôle, la macro qui ne fonctionne que parce que personne n'y touche. Gartner estime que ce shadow IT représente 30 à 40 pour cent des dépenses informatiques des grandes entreprises. Cet article montre pourquoi ce chaos s'installe, ce qu'il coûte vraiment et comment y mettre fin sans retirer leurs outils aux services métier.
Pourquoi le shadow IT apparaît : pour de bonnes raisons
Le shadow IT est rarement de la malveillance. Il naît parce qu'un service métier a un vrai problème et que la solution officielle prend trop de temps, coûte trop cher ou n'existe tout simplement pas. Alors quelqu'un construit un tableur. Il fonctionne, il est partagé, il gagne des macros, il est copié, et deux ans plus tard c'est un outil dont trois services dépendent. Selon une enquête Gartner, 41 pour cent des salariés acquièrent, modifient ou construisent déjà des solutions dont leur DSI ignore l'existence, et la tendance monte.
Le besoin sous-jacent est légitime : les services métier connaissent leurs processus mieux que quiconque et veulent les numériser. C'est exactement pourquoi l'interdiction pure échoue. Bloquer les outils ne rend pas le contrôle, cela ne produit que des tableurs mieux cachés.
Ce que le chaos coûte vraiment
Le prix se voit rarement tout de suite, mais d'autant plus clairement en cas d'incident. Les recherches de Raymond Panko sur la qualité des tableurs arrivent à la même conclusion à travers de nombreuses études : environ 94 pour cent des classeurs audités contiennent au moins une erreur, avec un taux d'erreur d'environ 5 pour cent par cellule de formule. Non pas parce que les auteurs sont négligents, mais parce que personne ne teste, ne relit ni ne versionne les tableurs.
Des cas célèbres montrent combien cela peut coûter : en 2020, l'agence de santé publique anglaise a perdu 15 841 cas de Covid parce qu'un ancien format Excel cessait simplement d'accepter des données vers 65 000 lignes, sans message d'erreur. JPMorgan a perdu plus de six milliards de dollars en 2012, en partie à cause d'un modèle de risque fait de tableurs avec des copier-coller manuels. Et l'étude influente des économistes Reinhart et Rogoff a soutenu des politiques d'austérité dans le monde entier pendant des années, jusqu'à ce qu'une simple erreur de plage dans leur tableur soit découverte en 2013.
S'y ajoutent les coûts silencieux : double saisie, perte de savoir au départ des personnes, pas de sauvegardes, pas de contrôle d'accès, pas de traçabilité. Au plus tard quand arrivent les questions RGPD ou un audit, le tableur pratique devient un problème de conformité.
Le réflexe « interdire davantage » ne résout rien
Beaucoup d'entreprises répondent par des directives : pas de macros, pas de bases locales, pas d'outils non autorisés. Le résultat est prévisible, car le besoin sous-jacent demeure. Les processus qui tournaient dans Excel migrent vers des comptes cloud privés ou vers le prochain outil non observé. L'IA générative aggrave actuellement la situation : Gartner s'attend à ce que d'ici 2030 environ 40 pour cent des organisations subissent des incidents de sécurité ou de conformité liés à un usage d'IA non approuvé.
La meilleure question n'est pas « comment empêcher les services métier de construire ? » mais « où peuvent-ils construire sans que cela devienne dangereux ? ». La tendance va clairement dans ce sens : Gartner estime qu'environ 70 pour cent des nouvelles applications d'entreprise naissent désormais d'approches low-code ou no-code, portées par des personnes hors de l'informatique classique.
Des garde-fous plutôt que des interdictions : ce qu'une plateforme interne doit offrir
Une plateforme d'applications interne donne un lieu sûr à l'énergie des services métier. Pour que cela fonctionne, et ne crée pas simplement un nouveau shadow IT sous un autre nom, il lui faut cinq choses à nos yeux :
- Un point d'entrée central avec single sign-on : une connexion, des droits de groupe clairs, pas de mots de passe partagés dans les messageries d'équipe.
- Une vraie base de données plutôt que des fichiers partagés : données centrales, règles d'accès au niveau des lignes, modifications de structure versionnées.
- Un chemin défini vers la production : développement, test et validation sont des étapes séparées, et un professionnel examine chaque application avant la mise en service.
- L'exploitation incluse : sauvegardes, supervision, mises à jour et scans de sécurité tournent centralement, pas par application ni à la demande.
- La traçabilité : qui a changé quoi, qui a validé quoi, quelle version tourne ? Sans journal d'audit, cela reste du chaos.
À quoi ressemble le chemin en pratique
La transition réussit non pas en big bang mais application par application. Ce qui marche bien : commencer par un processus qui fait mal, comme le planning d'équipe ou la saisie de données de contrôle. Le service métier décrit ce que l'outil doit faire et le construit sur la plateforme, aujourd'hui assisté par IA directement dans le navigateur. Avant la mise en service, des contrôles automatiques et une relecture humaine examinent la sécurité et les accès aux données. Ensuite l'application tourne centralement, avec sauvegardes, supervision et un responsable inscrit dans le système plutôt que dans les conversations de couloir.
C'est exactement le modèle autour duquel nous avons construit Kinster, notre plateforme d'applications auto-hébergée : les services métier développent leurs applications web internes avec l'aide de l'IA dans le navigateur, chaque application passe des contrôles automatiques et une relecture par needful-apps, et l'exploitation, sauvegardes et supervision comprises, fait partie du paquet. L'expérience Excel du service n'est pas dévalorisée mais traduite en un outil qui survit à plusieurs utilisateurs, à de vrais droits et à un redémarrage le lundi matin.
Questions fréquentes
Qu'est-ce qui compte comme shadow IT ?
Tout matériel ou logiciel exploité sans que la DSI le sache ou l'approuve : fichiers Excel avec macros et logique métier, bases Access privées, services cloud non approuvés et, de plus en plus, outils d'IA utilisés librement. Ce qui compte n'est pas l'outil mais le fait que personne ne porte la responsabilité de l'exploitation, de la sécurité et des données.
Excel est-il donc fondamentalement le mauvais outil ?
Non. Pour les analyses personnelles et les calculs ponctuels, Excel est excellent. Cela devient critique quand un tableur se transforme en système multi-utilisateurs : plusieurs éditeurs, de la logique métier dans des macros, des processus dont des services dépendent. Alors manquent droits, versionnage, sauvegardes et tests, et c'est exactement là que le processus doit passer dans une vraie application.
Les services métier perdent-ils leur autonomie avec une plateforme ?
Au contraire, elle devient officielle pour la première fois. Sur une plateforme avec garde-fous, les services continuent de construire eux-mêmes, aujourd'hui avec l'IA même plus vite que dans Excel. La différence : connexion, droits, base de données, sauvegardes et relecture sont déjà là, au lieu que chaque service doive les improviser.
Comment démarrer concrètement ?
Par un inventaire (quels tableurs et bases sont critiques pour l'activité ?) et un processus pilote au bénéfice tangible. Ensuite migrer application par application, pas tout d'un coup. Lors du premier entretien gratuit, nous examinons volontiers vos candidats ensemble.