Les outils créés avec l'IA par vos équipes : ce qu'il faut savoir avant de les laisser tourner

Le précédent que tout dirigeant connaît déjà

Je fais de l'infogérance pour des entreprises de toutes tailles depuis des années. Et dans presque chaque structure, je retrouve la même chose : un classeur Excel bardé de macros, ou une petite base Access, montés par un salarié débrouillard pour se simplifier la vie. Un suivi de stock, un calcul de marge, un planning. Rien d'officiel, rien de documenté. Juste un outil qui marche, que cette personne seule sait faire évoluer.

Le problème n'apparaît jamais tout de suite. Il apparaît le jour où cette personne change de poste ou quitte l'entreprise. L'outil, lui, reste, souvent devenu critique entre-temps. Plus personne ne sait l'ouvrir sans le casser, encore moins le faire évoluer.

Ce phénomène est en train de revenir, sous une forme beaucoup plus rapide et beaucoup plus connectée. Avec l'IA, il ne faut plus des semaines ni des compétences de développeur pour créer un outil : une soirée suffit, et le résultat ressemble, en apparence, à une vraie application.

Ce que je vois aujourd'hui chez mes clients

Récemment, dans une PME, on m'a montré ce genre d'outil. Un collaborateur y avait créé, avec l'IA, une petite application connectée directement au serveur de fichiers de l'entreprise, pour retrouver plus vite certains documents. Quand j'ai signalé la faille de sécurité possible, la réponse a été honnête et sincère : « c'est une application pour deux ou trois personnes seulement, ce n'est pas grave ».

C'est justement là qu'est le malentendu. Le risque n'est pas lié au nombre de personnes qui utilisent l'outil. Une application fragile, branchée sur le serveur de l'entreprise, est une porte d'entrée vers ce serveur, quel que soit le nombre de comptes qui s'y connectent. Si cette porte est compromise, ce n'est pas trois accès qui sont exposés. C'est tout ce que contient le serveur.

Pourquoi l'IA change l'échelle du problème

Le classeur Excel d'il y a dix ans restait généralement isolé sur un poste, avec des données copiées à la main. La différence aujourd'hui tient en trois points.

La vitesse. Ce qui prenait des semaines à un développeur amateur se fait désormais en une soirée, avec un outil d'IA qui écrit le code à la demande.

La connexion aux vraies données. Ces outils ne se contentent plus d'un fichier local : ils se branchent sur des dossiers partagés, des boîtes mail, des bases clients, parfois directement sur un serveur d'entreprise, pour aller chercher l'information utile.

Un code qui a l'air fiable. Une IA produit un code qui se lit bien et qui tourne. Rien n'indique, à l'œil d'un non-spécialiste, qu'il lui manque une authentification correcte ou une protection de base.

Ce n'est pas propre à la France ni à un secteur en particulier. Une entreprise s'est même créée cet été aux États-Unis sur ce seul constat : permettre aux collaborateurs non développeurs de créer des outils internes sans que la sécurité ne dépende de la personne qui les a montés. Quand une entreprise naît sur un problème aussi précis, c'est en général le signe qu'il est déjà massif.

Ce qui se cache derrière une application créée en une soirée

Dans les faits, ces petites applications présentent presque toujours les mêmes fragilités.

• Des identifiants écrits en dur dans le code : le mot de passe ou la clé d'accès au serveur, visible dans le code lui-même plutôt que stocké et chiffré séparément.
• Une authentification absente ou symbolique : pas de vérification sérieuse de qui se connecte, ou un mot de passe unique partagé entre plusieurs personnes.
• Des données copiées vers un service tiers dont personne n'a lu les conditions d'utilisation, pour héberger l'outil ou traiter les demandes.
• Aucune sauvegarde : si le service tombe ou si une erreur efface les données, il n'existe pas de copie de secours.
• Une maintenance qui dépend d'une seule personne, celle qui a créé l'outil. Le jour où elle part, l'outil continue de tourner sans que personne d'autre ne sache comment il fonctionne.
• Le RGPD jamais évoqué, simplement parce que personne n'a pensé à se poser la question au moment de créer l'outil.

Ces principes ne sont pas nouveaux, ni réservés aux équipes techniques. Ce sont les mêmes recommandations de base que l'ANSSI adresse à toutes les TPE et PME françaises : authentification sérieuse, sauvegardes régulières, accès limités aux seules personnes qui en ont besoin. Une application créée avec l'IA en une soirée n'est dispensée d'aucune de ces règles, même si personne ne les a appliquées au moment de la construire.

Interdire ne marche pas

La première réaction, en découvrant ce genre d'outil, est souvent d'y voir une faute. Ce n'en est pas une. La personne qui a créé cette application ne cherchait pas à mal faire. Elle cherchait une solution à un problème concret, avec les moyens qu'elle avait sous la main, et elle a plutôt bien réussi, sur le fond.

L'initiative n'est pas le problème. L'absence de cadre, si.

Interdire la création de tels outils ne change rien à ce constat : l'usage ne s'arrête pas, il devient simplement invisible, et personne ne le signale plus par crainte d'une sanction. Ce qui fonctionne, c'est l'inverse : un cadre clair, qui dit ce qui est permis, ce qui ne l'est pas, et à qui en parler avant de brancher un outil sur des données sensibles.

La méthode en trois temps

Poser ce cadre ne demande pas un grand projet informatique. Trois étapes suffisent, et elles peuvent se traiter en quelques semaines.

1. Recenser ce qui existe déjà

Avant toute règle, il faut savoir ce qui tourne réellement dans l'entreprise. Un tour de table simple, sans jugement, auprès des équipes : qui a créé un outil avec l'IA, à quoi il sert, et à quelles données il accède. C'est souvent la première fois que cette information est réunie quelque part.

2. Décider ce qui est autorisé

Une fois le recensement fait, il s'agit de trancher : quels types d'outils peuvent être créés librement, lesquels doivent passer par une validation avant d'être connectés à des données sensibles, et quelles données ne doivent jamais y entrer. Nous avions détaillé cette logique de cadrage dans notre article sur l'AI Act et les PME : la charte IA que nous avons partagée à cette occasion s'applique très bien ici, elle aussi.

3. Donner à ces outils un endroit où vivre correctement

Un outil créé par un collaborateur, une fois jugé utile, mérite d'être hébergé ailleurs que sur son ordinateur personnel ou un service choisi au hasard, avec un minimum de contrôle sur les accès et les sauvegardes. Centraliser l'usage de l'IA de l'entreprise à un seul endroit, ce que permet une plateforme comme Netaix, aide sur ce point précis, mais ne remplace pas les deux premières étapes.

Et pour aider vos équipes à bien utiliser l'IA au quotidien, au-delà de la création d'outils, partagez-leur notre guide : Bien utiliser l'IA au travail.

Ce qu'il faut retenir

La France a déjà connu 43,4 millions de comptes compromis sur les six premiers mois de 2026, un record, et se classe au premier rang européen des fuites de données. Ce chiffre concerne les canaux connus : messageries, sites, services en ligne. Chaque outil interne créé sans cadre, connecté à de vraies données d'entreprise, ajoute une porte de plus à surveiller.

Sources

• Guide RGPD du développeur, CNIL (sécurité des mots de passe, contrôle des accès, minimisation des données) : lincnil.github.io
• La cybersécurité pour les TPE/PME en 13 questions, ANSSI et Direction générale des Entreprises, via France Num : francenum.gouv.fr
• Prized (Y Combinator, été 2026) : permettre aux non-développeurs de créer des outils internes sécurisés : ycombinator.com
• « En France, 43 millions de comptes ont déjà été compromis en 2026 », Blog du Modérateur (28 juillet 2026) : blogdumoderateur.com