Les opinions exprimées dans ce texte n’engagent que leurs auteurs
Olivier KLEIN : Vous savez chère Elodie, « de mon temps », pour augmenter la productivité, l’efficacité et l’efficience des collaborateurs, on misait grandement sur la montée en compétences et la profondeur d’utilisation des outils et logiciels par les équipes, en partant du constat que moins de 20% des fonctionnalités des logiciels « legacy » étaient réellement maîtrisées et exploitées. Un vivier de marge de progression, en somme.
Mais l’IA que ce soit dans sa mouvance agentique ou dans une approche low code / no code a complètement changé la donne. L’ubérisation, d’abord : tout le monde peut développer un outil ou un service répondant à un besoin métier. Et aussi le self-caring : chaque collaborateur peut développer son propre outil, répondant exclusivement à son besoin, sont devenus des tendances majeurs d’efficacité égotique qui les éloignent toujours un peu plus des applications officielles.
Tous les DPO connaissent cette emblématique extraction Excel issue de l’application métier en vue de traiter « en parallèle et plus aisément » les informations des clients ou des usagers. Un shadow traitement au sens RGPD, qui échappe à toute évaluation et référencement, mais qui reste minoritaire et aisément identifiable.
Mais là, nous parlons d’un leitmotiv complètement différent : « j’ai un besoin > je développe (en solo) mon appli répondant à mon besoin » aboutissant à une explosion du nombre d’application à suivre par la DSI… avec l’impératif de maintien en condition opérationnelle, de surveillance et de sauvegarde, car c’est du temps cristallisé et capitalisé par le collaborateur pour lui permettre d’être plus efficace. Ça a de la valeur. Et pour le RSSI ? Une extension de la surface de risque et d’attaque dont il n’a pas forcément connaissance. Sans parler du devenir des agents orphelins après le départ du collaborateur.
Qu’en pensez-vous Elodie ? Comment la DSI doit-elle se positionner face à ce phénomène disruptif, sans briser pour autant l’implication et le mouvement de transformation et d’innovation initié par les collaborateurs ? Aidez-moi à y voir plus clair …
Elodie LE SAOUT : Cher Olivier, votre diagnostic est juste, et j’ajouterais que le sujet tient moins à l’outil qu’à ce qu’il emporte avec lui. Un agent construit en solo est rarement un simple tableur amélioré : c’est un flux de données, des secrets d’authentification (clés d’API, jetons OAuth) et, très souvent, l’appel à un modèle tiers hébergé hors du périmètre de l’entreprise. Le shadow IT d’hier se contentait de copier des données ; le self-caring agentique les fait circuler, s’exécuter et agir sous l’identité du collaborateur.
Les conséquences varient selon les secteurs, et c’est là que la DSI doit affiner sa lecture. Dans la finance, un agent adossé à un processus important crée une dépendance aux TIC non cartographiée, alors que DORA exige un inventaire des actifs et un registre d’informations sur les prestataires. En santé, une donnée patient confiée à un modèle opéré par un hébergeur non certifié HDS expose à une non-conformité caractérisée. Dans l’industrie, un script « astucieux » près d’un environnement OT contourne la logique de zones et de conduits de l’IEC 62443. Partout, le RGPD s’applique : finalité, base légale, sous-traitance (art. 28), transferts hors UE. Le « shadow traitement » marginal que vous décrivez devient alors un phénomène de masse, sans compter l’article 4 de l’AI Act, qui impose déjà de former les utilisateurs d’IA.
Pour autant, interdire serait la pire réponse : on ne sécurise pas ce que l’on ne voit pas, et l’on ne voit pas ce que l’on interdit. Je recommande une gouvernance par la facilitation, en quatre gestes :
1. Voir : découvrir les applications et les connexions OAuth réellement en usage (CASB, journaux d’identité), sans chercher de coupables.
2. Proportionner : trier selon la criticité. Un outil personnel sans donnée sensible reste libre ; un outil partagé ou touchant des données personnelles est déclaré et revu ; un outil qui supporte un processus critique est soit industrialisé, soit retiré.
3. Offrir un bac à sable officiel : une plateforme low code ou no code validée, avec authentification unique, traçabilité, prévention des fuites de données et modèles de langage encadrés par contrat. L’initiative reste libre, dans un cadre qui garantit la sécurité.
4. Piloter le cycle de vie : un propriétaire nommé, une revalidation périodique et, surtout, une procédure de départ qui révoque les secrets et reprend ou éteint les agents orphelins.
Enfin, ce « temps cristallisé » dont vous parlez est aussi un signal : chaque outil personnel révèle un besoin métier mal couvert par l’application officielle. Une DSI mature le traite comme un gisement de retours utilisateurs et industrialise les meilleures initiatives plutôt que de les subir. C’est à ce prix que l’on protège le patrimoine sans éteindre l’élan.
Olivier KLEIN : Merci Elodie pour ces précieux conseils, me voilà désormais upgradé à cette tendance contemporaine !
