Un responsable contrôle de gestion, ADV, supply ou RH n’a pas attendu la DSI. Il a ouvert son compte ChatGPT ou Claude personnel un week-end, et il a construit un outil qui automatise une partie du travail de son équipe. Trois mois plus tard, l’équipe l’utilise tous les jours. Les tableaux se remplissent plus vite, les relances partent seules, les écarts se détectent avant la clôture.
Le problème arrive ensuite. L’outil tourne sur un compte privé, avec des données de l’entreprise dedans, et une seule personne sait comment il fonctionne. La DSI vient de le découvrir, ou va le découvrir dans les prochaines semaines.
Ce scénario se répète dans des services entiers, sous des formes différentes. La gouvernance de l’IA en entreprise se pose rarement au moment où l’on choisit un outil : elle se pose quand un outil non choisi existe déjà, qu’il fonctionne, et qu’il faut décider quoi en faire. C’est cette décision qui compte, pas le règlement qu’on aurait aimé écrire avant.
Ce n’est pas un cas isolé. Selon le Work Trend Index 2024 de Microsoft et LinkedIn, 78 % des utilisateurs d’IA au travail apportent leurs propres outils d’IA sans validation de leur entreprise, un phénomène désigné sous le nom de BYOAI (« bring your own AI« ), une proportion qui monte à 80 % dans les petites et moyennes entreprises. L’écart entre ce que les équipes doivent accomplir et ce que la DSI peut livrer dans les délais attendus pousse les collaborateurs les plus à l’aise avec ces outils à combler le vide eux-mêmes.
Ces collaborateurs ont un avantage que la DSI n’a pas : ils connaissent le détail du processus. Un responsable ADV sait quelles commandes sortent du circuit standard et pourquoi. Un contrôleur de gestion sait quelles corrections il applique chaque mois avant de publier un chiffre. Un responsable RH sait quelles exceptions s’appliquent selon le type de contrat. Cette connaissance ne figure dans aucune spécification fonctionnelle. Elle vit dans la tête de la personne, dans ses habitudes, dans les corrections qu’elle fait sans même y penser.
Quand cette personne construit un outil avec un assistant IA, elle encode cette connaissance tacite dans du code ou des prompts. Le résultat fonctionne, parce qu’il reproduit exactement ce qu’elle faisait déjà. Mais rien de tout cela n’est documenté, contrôlé, ni transférable. Si la personne change de poste, l’outil devient une boîte noire. Si une donnée sensible sort par ce canal, personne ne peut dire précisément laquelle, ni vers où.
Ce n’est pas seulement un problème de sécurité informatique. Une donnée client ou salarié qui transite par un compte personnel échappe aux garanties que l’entreprise doit sur la conservation, l’accès ou la suppression de cette donnée. Le sujet remonte vite du bureau du manager à celui du responsable de la conformité.
La DSI qui découvre ce genre d’outil se retrouve devant un dilemme réel : le débrancher revient à supprimer un gain de productivité mesurable, sans solution de remplacement immédiate. Le laisser tourner revient à cautionner un risque qu’elle ne maîtrise pas.
Traiter ce type de situation ne consiste pas à choisir entre interdire et laisser faire. Quatre obstacles reviennent systématiquement et méritent d’être regardés avant toute décision : la dépendance à une seule personne, qui a construit et modifié l’outil sans jamais documenter les règles qu’elle y a mises ; l’absence de traçabilité sur les données qui transitent par un compte personnel, hors du périmètre de sécurité de l’entreprise ; le flou sur les contrôles réels, puisque personne d’autre ne peut dire ce que l’outil valide, corrige ou ignore ; et l’absence de plan de continuité si la personne change de poste, part en congé prolongé, ou quitte l’entreprise.
Avant de couper l’accès, la première étape consiste à comprendre ce que l’outil fait réellement, pas ce que son créateur pense qu’il fait. Un audit rapide, mené avec la personne plutôt que contre elle, permet de lister les règles métier, les cas particuliers traités, et les données utilisées.
Vient ensuite la séparation entre la logique métier, qui a de la valeur, et l’infrastructure, qui pose le risque. Les règles et les exceptions identifiées peuvent être reprises dans un environnement maîtrisé par l’entreprise, avec des données qui restent dans son périmètre. Le compte personnel disparaît, mais le travail effectué ne se perd pas.
| Situation actuelle | Situation cible |
| Compte IA personnel | Environnement IA géré par l’entreprise |
| Une seule personne connaît les règles | Règles documentées et partagées |
| Aucune traçabilité des données | Données suivies et encadrées |
| Continuité dépendante d’une personne | Continuité assurée par le système |
Le traitement de la personne compte autant que celui de l’outil. Sanctionner l’initiative revient à décourager les prochaines, alors que ce sont elles qui révèlent le plus vite les irritants réels du terrain. Associer ce collaborateur à la reprise du projet, en reconnaissant ce qu’il a apporté, conditionne la réussite de la bascule bien plus qu’un plan de migration technique seul.
La question à se poser n’est pas « faut-il interdire l’IA non maîtrisée », mais « comment reprendre la main sur ce qui fonctionne déjà« , sans perdre le temps que ce collaborateur a gagné à sa manière.
Ce type d’outil bricolé mérite un regard différent de celui qu’on porte habituellement sur le shadow IT. Une base de code non maintenue est un problème. Mais la connaissance qu’elle contient, les règles, les exceptions, les contrôles qu’un collaborateur a formalisés sans qu’on le lui demande, est une matière première rare. Elle a déjà passé le test le plus dur pour un projet IA : elle est utilisée tous les jours par une équipe qui n’a aucune obligation de s’en servir.
Chez JEMS, nous appelons cette approche l’Architecture Cognitive. Elle part du principe que les processus d’une entreprise ne sont jamais entièrement décrits dans un flowchart ou une documentation. Une partie vit dans les têtes, dans les habitudes, dans les corrections que chacun applique sans les écrire. Le rôle d’un système agentique gouverné n’est pas de remplacer ce savoir tacite, mais de le capturer et de le rendre explicite, contrôlable, transférable.
Un outil vibe-codé qui fonctionne n’est donc pas qu’un risque à traiter. C’est un signal à écouter, avant qu’il ne devienne un problème plus difficile à défaire. Cette lecture change la question de départ : elle pousse à se demander ce que cet outil révèle des limites de nos systèmes officiels, avant de chercher qui l’a autorisé.
Le gain de productivité que ce type d’outil a produit est réel, mesuré, vécu chaque jour par une équipe. Le supprimer sans rien mettre en face ferait perdre ce gain ; le maintenir en l’état ferait courir un risque que personne n’a choisi d’assumer. La bonne réponse n’est ni l’un ni l’autre.
Reprendre la main sur ces initiatives, formaliser ce qu’elles ont révélé, les intégrer dans un cadre que la DSI peut suivre et faire évoluer : c’est un chantier concret, qui se mène avec les équipes qui ont pris les devants plutôt que contre elles.
Si vous avez identifié ce type d’outil dans vos équipes, ou si vous voulez évaluer où se situe votre organisation sur ces sujets, les équipes JEMS peuvent échanger avec vous sur la démarche à suivre.
