TI fantômes 2.0 : les applications d'IA fantômes bâties sans les TI

TI fantômes 2.0 : les équipes ne se contentent plus d'acheter des logiciels, elles les bâtissent

Les TI fantômes classiques, c'était facile à imaginer : un service qui payait un abonnement SaaS jamais approuvé, ou un processus critique qui tournait dans un fichier Excel sur le poste de quelqu'un. Les TI le découvraient tard, mais au moins un fournisseur entretenait le produit.

Les TI fantômes 2.0, c'est autre chose. Avec les assistants de codage, les générateurs d'applications et les agents d'IA, les employés n'achètent plus seulement des outils. Ils les bâtissent. Les ventes, les finances et les opérations produisent elles-mêmes des applications, des automatisations et des intégrations.

Quelques scénarios illustratifs (ce ne sont pas de vrais clients) :

• Ventes : un outil de soumission bâti avec l'IA qui lit les prix dans le CRM et met à jour l'étape des occasions.
• Finances : un script de conciliation qui télécharge chaque nuit les relevés bancaires et les compare au système comptable.
• Opérations : un formulaire d'accueil client, généré en un après-midi, qui écrit directement dans une base de données.

Pourquoi maintenant? Bâtir une application est devenu facile. Ces outils ont l'air soignés, règlent de vrais problèmes et sont prêts bien avant que le carnet de demandes des TI se vide. Beaucoup d'employés choisissaient déjà leurs propres outils d'IA : le Work Trend Index 2024 de Microsoft et LinkedIn indiquait que 78 % des utilisateurs d'IA apportaient leurs propres outils au travail. Dans un sondage Gartner de 2025 rapporté par Infosecurity Magazine, 69 % des responsables de la cybersécurité avaient des preuves ou des soupçons que des employés utilisaient l'IA générative publique au travail.

Ces chiffres mesurent l'usage de l'IA en général, pas les applications bâties par les équipes d'affaires. Mais une fois les outils en main, bâtir avec eux est la suite logique.

L'intention est généralement bonne. Les gens veulent mieux faire leur travail.

Le problème, c'est que personne n'est responsable du résultat.

Pourquoi les applications d'IA fantômes sont plus risquées qu'un fichier Excel rebelle

Quand un fichier Excel déraille, les dégâts restent généralement dans le fichier. Une application bâtie avec l'IA, elle, agit : elle appelle des API, écrit dans des bases de données, envoie des courriels et manipule des données clients.

Elles sont branchées sur de vrais systèmes et de vraies données

Pour que son application fonctionne, la personne qui la bâtit colle souvent une clé d'API ou un mot de passe directement dans le code ou dans une requête. Des renseignements sur des clients ou des employés peuvent aboutir dans un service d'IA externe que personne n'a évalué.

Au Québec, la Loi 25 entre alors en jeu. Selon la Commission d'accès à l'information, les entreprises doivent désigner une personne responsable de la protection des renseignements personnels, réaliser une évaluation des facteurs relatifs à la vie privée avant d'acquérir ou de développer un système d'information qui touche des renseignements personnels, déclarer les incidents de confidentialité qui présentent un risque de préjudice sérieux et tenir un registre de ces incidents. Les sanctions administratives pécuniaires peuvent atteindre 10 millions de dollars ou 2 % du chiffre d'affaires mondial. Une application bâtie sans en parler à personne et qui traite des renseignements personnels saute cette évaluation.

À l'échelle canadienne, les autorités fédérales, provinciales et territoriales de protection de la vie privée ont publié conjointement, en décembre 2023, des principes sur l'IA générative. Ils visent aussi les organisations qui utilisent l'IA générative, pas seulement celles qui la développent, et insistent sur la responsabilité et sur le fait de ne pas mettre de renseignements personnels dans les requêtes sans autorisation. Ce sont des repères généraux, pas un avis juridique : votre responsable de la protection des renseignements personnels ou votre conseiller juridique doit évaluer les cas précis.

Personne n'est responsable du code une fois qu'il fonctionne

La plupart de ces applications n'ont ni gestion du code source, ni revue de code, ni tests, ni documentation. Tout repose sur une personne et un compte. Quand cette personne change de poste ou quitte l'entreprise, ou qu'une bibliothèque ou une API change, l'application brise et personne ne sait la réparer.

Le code généré que personne n'a revu présente aussi des failles typiques : authentification absente, validation des entrées faible, dépendances périmées. Dans le rapport 2025 de Veracode, qui a testé plus de 100 modèles de langage sur 80 tâches de programmation, le code produit introduisait des vulnérabilités du Top 10 de l'OWASP dans 45 % des cas. Ce sont des tests contrôlés, pas des applications en production, mais la leçon tient : un code qui fonctionne n'est pas forcément sécuritaire.

Elles tombent en panne en silence

Le plus grand danger, c'est que personne ne les voit. Un processus autrefois manuel dépend maintenant d'une application dont les TI n'ont jamais entendu parler, sans surveillance, sans sauvegarde ni alerte. Quand elle s'arrête, ou qu'elle tourne en produisant de mauvais résultats, le premier signe peut être un client mécontent ou une fin de mois qui ne balance pas.

Ce que coûtent vraiment les applications d'IA fantômes : des passifs cachés au bilan

L'IA fantôme apparaît rarement comme un poste budgétaire. Son coût s'accumule là où un chef des finances ne regarde qu'une fois que quelque chose a mal tourné.

Les données disponibles mesurent l'IA fantôme au sens large, soit les outils d'IA utilisés sans autorisation, et pas précisément les applications bâties par les équipes. Ça reste le meilleur indicateur :

• Dans le rapport Cost of a Data Breach 2025 d'IBM, une organisation sur cinq a déclaré une violation de données causée par l'IA fantôme. Celles où l'IA fantôme était très présente ont payé 670 000 $ US de plus par violation que celles où elle l'était peu ou pas.
• Selon le même rapport, ces incidents ont compromis plus souvent des renseignements personnels (65 %, contre une moyenne mondiale de 53 %) et de la propriété intellectuelle (40 % contre 33 %).
• Le rapport 2026 d'IBM établit le coût moyen d'une violation de données pour les organisations canadiennes à un record de 7,11 millions de dollars canadiens.
• Gartner, selon Infosecurity Magazine, prévoit que d'ici 2030 la moitié des entreprises subiront des retards dans leurs mises à niveau en IA ou une hausse de leurs coûts d'entretien à cause d'une dette technique non gérée liée à l'IA générative.

Ces données reflètent surtout de grandes organisations; nous n'avons trouvé aucune donnée propre aux PME ou au Québec. Mais une PME a moins de marge pour absorber le même type d'incident.

Au-delà des violations de données, voici les catégories de coûts à suivre :

• Exposition aux incidents : enquête, avis aux personnes touchées, correctifs et sanctions possibles.
• Reprise : rebâtir correctement une application devenue critique.
• Outils en double : plusieurs équipes qui paient des abonnements d'IA qui se chevauchent.
• Entretien invisible : des heures passées discrètement à garder en vie des outils fragiles.
• Audit et conformité : reconstituer après coup où sont allées les données.

L'évolution du code généré par l'IA dans le temps est traitée dans notre article sur le coût caché des logiciels générés par l'IA. Ici, on parle du côté organisationnel : des passifs que personne n'a inscrits nulle part.

Interdire, ignorer ou encadrer : les trois réponses possibles de la direction

Quand une direction découvre des applications d'IA fantômes, elle choisit généralement l'une de ces trois réponses.

Beaucoup d'organisations n'ont aucun encadrement. Dans le rapport 2025 d'IBM, 63 % des organisations ayant subi une violation de données n'avaient pas de politique de gouvernance de l'IA ou en étaient encore à l'élaborer, et parmi celles qui en avaient une, seulement 34 % vérifiaient régulièrement l'usage d'IA non autorisée. Gartner, selon Infosecurity Magazine, recommande d'adopter des politiques sur les outils d'IA pour toute l'entreprise, de faire des audits réguliers pour détecter l'IA fantôme et d'inclure les risques de l'IA générative dans l'évaluation des solutions SaaS.

Encadrer, c'est la seule réponse qui garde à la fois la rapidité et le contrôle.

Un cadre de gouvernance pratique pour les applications d'IA bâties en dehors des TI

Le cadre tient en quatre étapes : découvrir ce qui existe, le classer selon le risque, poser des garde-fous et faire passer les applications critiques à un vrai processus de développement. Pas besoin d'un gros service des TI pour y arriver.

1. Découvrir : faire l'inventaire de ce qui existe déjà

Commencez par une amnistie, sans chercher de coupables. Demandez aux équipes de déclarer les outils d'IA, scripts, automatisations et applications qu'elles utilisent ou ont bâtis, en précisant que le but est de les soutenir, pas de les punir. Recoupez ensuite avec les journaux d'authentification unique (SSO) et les comptes de dépenses pour repérer les abonnements à des outils d'IA. Attendez-vous à en trouver plus que prévu.

2. Classer : hiérarchiser selon la sensibilité des données et la criticité

Trois niveaux suffisent pour la plupart des PME :

• Productivité personnelle : aide une seule personne, aucune donnée sensible. Règle : outils approuvés seulement, aucune donnée de production.
• Outil d'équipe : partagé dans une équipe, utilise des données internes. Règles : un responsable nommé, des identifiants dans un coffre-fort numérique, des flux de données documentés et une sauvegarde.
• Critique ou exposée aux clients : un processus ou un client en dépend, ou elle traite des renseignements personnels. Règles : gestion du code source, revue de code, tests automatisés, pipeline CI/CD et revue de sécurité, plus une évaluation des facteurs relatifs à la vie privée si des renseignements personnels sont en jeu.

3. Encadrer : outils approuvés, gestion des secrets, règles sur les données

• Publiez une courte liste d'outils d'IA approuvés et une façon simple d'en demander un nouveau.
• Tenez les données de production et les renseignements personnels à l'écart des outils non approuvés.
• Gardez les identifiants dans un coffre-fort de secrets, jamais dans le code ni dans les requêtes.
• Donnez aux comptes des applications seulement les accès nécessaires (moindre privilège).
• Offrez un bac à sable avec des données de test pour expérimenter sans risque.

4. Promouvoir : un chemin clair du prototype à la production

Dès qu'une application atteint le niveau critique, elle passe à la gestion du code source, aux pipelines CI/CD, à la revue de code et aux tests, par exemple dans Azure DevOps, avec un responsable nommé. Les étapes techniques sont détaillées dans notre article sur le passage du prototype à la production. Ce qui compte ici, c'est un déclencheur clair et convenu d'avance.

Vient ensuite la décision : consolider ou rebâtir? On consolide quand le périmètre est stable, que le code est compréhensible et que les problèmes de gestion des données se corrigent. On rebâtit en logiciel sur mesure quand la revue de sécurité révèle des problèmes de fond (aucun vrai modèle d'authentification, par exemple), quand l'application doit s'intégrer à plusieurs systèmes centraux ou monter en charge, ou quand personne ne peut expliquer comment elle fonctionne. L'IA accélère le développement, mais cette décision demande encore des développeurs d'expérience. C'est là qu'interviennent le développement de logiciels sur mesure et les services-conseils DevOps de Groupe Conseil CG.

À quoi ressemble une bonne pratique : les TI comme facilitateur, pas comme gardien

Le but n'est pas d'empêcher les gens de bâtir. C'est de faire en sorte que bâtir de façon sécuritaire soit l'option la plus simple. Les équipes font leurs prototypes librement dans un bac à sable. Les TI fournissent des gabarits, des dépôts partagés et des pipelines prêts à l'emploi. Les applications critiques ont un vrai soutien technique.

Chaque application importante a trois rôles clairs :

• Responsable d'affaires : décide de ce que l'application doit faire et répond de son utilisation.
• Responsable technique : entretient le code, les dépendances et les déploiements.
• Revue de sécurité et de vie privée : approuve les flux de données et les accès avant la mise en production.

Scénario hypothétique. Reprenons l'outil de soumission du début. Pendant l'amnistie, la directrice des ventes le déclare. Il est classé critique, puisque des clients reçoivent ce qu'il produit. Sa clé d'API passe du code à un coffre-fort de secrets. Le code est versé dans un dépôt partagé, un développeur le révise, et on ajoute une authentification et une validation des entrées. Un pipeline déploie désormais chaque modification après des tests automatisés. La directrice reste responsable d'affaires; les TI deviennent responsables techniques. L'équipe garde son outil, et l'entreprise sait où vont ses données.

Ce que la direction devrait mesurer

Quelques indicateurs suffisent pour savoir si l'usage de l'IA est sous contrôle :

• Nombre d'applications bâties avec l'IA connues, et proportion qui a un responsable nommé.
• Proportion des applications critiques sous gestion du code source et CI/CD.
• Nombre d'outils d'IA utilisés par rapport au nombre d'outils approuvés.
• Délai entre une demande de prototype et une mise en production avec soutien.
• Incidents ou exceptions de traitement des données liés à des applications non encadrées.

Révisez-les chaque trimestre. Si le chemin du prototype à la production est trop lent, les équipes recommenceront à bâtir dans l'ombre.

La prochaine vague : les agents d'IA rendront les TI fantômes 2.0 encore plus difficiles à voir

Des agents qui agissent sur les systèmes, en envoyant des courriels, en modifiant des dossiers ou en déclenchant des paiements, sont déjà là. Tout ce qui n'est pas encadré a alors plus d'impact.

Le Gen AI Security Project de l'OWASP appelle ce risque « agentivité excessive » (excessive agency) : un système d'IA qui a trop de fonctionnalités, de permissions ou d'autonomie peut poser des gestes dommageables. Ses recommandations rejoignent le cadre présenté plus haut : moindre privilège, extensions réduites au minimum, approbation humaine pour les actions à fort impact et surveillance. Gartner, selon Infosecurity Magazine, prévoit que d'ici 2030 plus de 40 % des organisations subiront des incidents de sécurité et de conformité liés à des outils d'IA non autorisés.

Les entreprises qui posent leurs garde-fous maintenant adopteront l'IA plus vite, pas moins vite, parce qu'elles sauront ce qui roule, qui en est responsable et à quoi chaque outil a accès.

FAQ

Qu'est-ce que l'IA fantôme, et en quoi diffère-t-elle des TI fantômes traditionnelles?

Les TI fantômes traditionnelles, c'est surtout l'achat ou l'utilisation d'outils non approuvés, comme un abonnement SaaS ou un fichier Excel critique. L'IA fantôme englobe les outils d'IA utilisés sans autorisation et, de plus en plus, les applications, automatisations et agents que les employés bâtissent eux-mêmes, souvent branchés sur de vrais systèmes et de vraies données.

Devrait-on interdire ChatGPT et les outils de codage par IA?

Une interdiction pousse généralement l'usage vers les appareils et comptes personnels, où les TI ne voient plus rien. Une liste d'outils approuvés, des règles sur les données et un chemin clair vers la production gardent les gains de productivité et rendent le risque visible.

Comment créer une liste d'outils d'IA approuvés sans ralentir les équipes?

Gardez la liste courte, publiez une façon simple de demander un nouvel outil et offrez un bac à sable avec des données de test. Gartner, selon Infosecurity Magazine, recommande aussi d'inclure les risques de l'IA générative dans l'évaluation des solutions SaaS.

Quels contrôles minimaux une application bâtie par un non-développeur doit-elle respecter avant de toucher des données de production?

Au minimum : un responsable nommé, des outils approuvés seulement, des identifiants dans un coffre-fort et des accès selon le moindre privilège. Si elle est critique ou traite des renseignements personnels, ajoutez la gestion du code source, la revue de code, les tests et une revue de sécurité.

Qui est responsable en vertu de la Loi 25 si une application bâtie avec l'IA fait fuir des données clients?

Les obligations de la Loi 25 visent l'entreprise, pas seulement l'employé qui a bâti l'application. C'est de l'information générale : consultez votre responsable de la protection des renseignements personnels ou votre conseiller juridique pour un cas précis.

Quand faut-il rebâtir une application d'IA bâtie par une équipe plutôt que la consolider?

Rebâtissez quand la revue de sécurité révèle des problèmes de fond, quand l'application doit s'intégrer à plusieurs systèmes centraux ou monter en charge, ou quand personne ne peut expliquer son fonctionnement. Sinon, la consolider suffit souvent.

Les applications d'IA fantômes montrent que vos équipes veulent avancer plus vite. Les interdire ne fonctionne pas, et les ignorer accumule un risque que personne ne voit. Un cadre simple fonctionne : découvrir, classer, encadrer, promouvoir. Il transforme des expériences éparpillées en actifs fiables pour l'entreprise.

Si vous avez besoin d'aide pour mettre en production les applications que vos équipes ont bâties, que ce soit en les rebâtissant en logiciel sur mesure ou en les intégrant à DevOps, parlons de votre projet.