Pourquoi les applications « Skunkworks » créées par l’IA deviennent le nouveau risque pour les entreprises
Pour de nombreuses organisations, Claude Code et les autres outils de codage basés sur l’IA ne constituent pas avant tout un problème technologique. Il s’agit plutôt d’un problème d’exécution et de gouvernance.
L’engouement suscité est facile à comprendre. Anthropic décrit Claude Code comme un outil de codage « agentique » capable de lire une base de code, de modifier des fichiers, d’exécuter des commandes, de s’intégrer à des outils de développement, d’effectuer des tests et de livrer du code validé. Anthropic le présente également comme une porte d’entrée vers le développement logiciel pour les créateurs sans formation en ingénierie.
C’est un outil puissant. Cela modifie également le comportement des dirigeants.
Un haut dirigeant peut désormais décrire un outil de planification, un outil de suivi des exceptions de facturation, un tableau de bord de service sur le terrain ou un flux de travail de gestion des stocks, et voir le résultat fonctionner rapidement. Ce qui nécessitait auparavant une analyse de rentabilité, un examen de l’architecture, des ressources de développement, une planification de l’intégration, des tests et un contrôle des changements peut désormais commencer par une simple invite.
Le risque ne réside pas dans le fait que les dirigeants expérimentent. Le risque, c’est que les prototypes commencent à devenir des systèmes de production avant que quiconque n’ait répondu aux questions difficiles : À qui appartiennent les données? Quel est le système de référence? Comment l’accès est-il contrôlé? Comment le système sera-t-il testé? Que se passera-t-il si l’IFS, l’ERP, le CRM, la paie ou la couche d’intégration changent? Qui assurera le soutien technique lorsque la personne à l’origine de l’initiative quittera l’entreprise?
On a déjà vu ce film
Les outils sont nouveaux, mais le scénario, lui, ne l’est pas.
Pendant le boom des points-com et les années qui ont suivi, les organisations se sont développées à un rythme effréné. Les services ont créé des applications Web sur mesure, des bases de données Access, des modèles Excel, des flux de travail Lotus Notes et des applications d’entreprise fortement personnalisées pour résoudre des problèmes opérationnels urgents. Bon nombre de ces outils se sont avérés utiles. Mais beaucoup sont également devenus non documentés, sans soutien technique et profondément ancrés dans les opérations quotidiennes.
Des années plus tard, les entreprises ont découvert le coût réel de la situation. Le plus coûteux n’était pas la mise en place initiale, mais plutôt la maintenance, la logique d’affaires cachée, les intégrations orphelines, les dépendances fragiles entre les données et le fait que plus personne au sein de l’organisation ne comprenait pleinement le fonctionnement du processus.
McKinsey a décrit ce « côté obscur » du développement d’applications d’entreprise comme des solutions créées par les utilisateurs métier, souvent à l’aide d’outils tels qu’Excel ou des plateformes « low-code », qui ne bénéficient ni d’une gouvernance informatique ni d’un développement structuré. McKinsey met également en garde contre le fait que ces applications « fantômes » peuvent créer des « couplages fantômes », c’est-à-dire des situations où une application fantôme dépend de données d’entreprise sans que le service informatique n’en ait connaissance.
Le codage par IA augmente les enjeux, car il permet de créer davantage de logiciels, plus rapidement, avec une expérience utilisateur plus convaincante.
L’histoire de la productivité est réelle, mais incomplète
Les outils de codage basés sur l’IA peuvent tout à fait améliorer la productivité dans un contexte approprié. Une étude de Microsoft Research a révélé que les développeurs utilisant GitHub Copilot ont accompli une tâche de codage JavaScript contrôlée 55,8 % plus rapidement que le groupe témoin.
Mais cela ne signifie pas pour autant que toutes les applications générées par l’IA sont prêtes pour une utilisation en entreprise. Dans un essai contrôlé randomisé mené en 2025 par METR, des développeurs open source expérimentés travaillant dans leurs propres dépôts bien établis ont mis 19 % plus de temps lorsqu’ils utilisaient des outils d’IA du début de l’année 2025, même s’ils estimaient que ces outils leur permettaient d’être plus rapides.
Cet écart est important pour les dirigeants. Un prototype fonctionnel peut donner l’impression de rapidité. Or, les opérations de production exigent bien plus que de la rapidité.
Les applications d’entreprise ne se résument pas à des écrans et à des flux de travail. Elles gèrent les contrats, les droits d’accès, la tarification, les approbations, les règles de planification, les transactions d’inventaire, les contrôles financiers, les pistes de vérification, la sécurité, le comportement hors ligne des appareils mobiles, la production de rapports et l’intégrité des données. Dans les environnements à forte intensité de services et d’actifs, une petite erreur dans un flux de travail peut se traduire par un retard de la part d’un technicien, une erreur de facturation, un manquement au SLA, un problème de conformité ou une défaillance ayant des répercussions sur les clients.
Le véritable risque, ce sont les opérations « fantômes »
Le nouveau risque n’est pas le « TI fantôme » au sens traditionnel du terme. Il s’agit plutôt d’opérations « fantômes ».
Un dirigeant met au point un outil pour résoudre un problème concret. Une équipe commence à l’utiliser. Quelqu’un le relie aux données de production. Une autre personne y ajoute un flux de travail. Un planificateur s’appuie dessus. Un technicien le met à jour. Le service des finances demande un rapport généré par cet outil. Soudainement, l’entreprise fonctionne grâce à une application qui n’a jamais été conçue pour faire partie du modèle opérationnel.
C’est là que les exemples édifiants prennent toute leur importance.
En 2020, Public Health England a signalé que 15 841 cas de COVID-19 n’avaient pas été inclus dans les rapports quotidiens en raison d’un problème technique dans un processus de chargement de données, lié à des fichiers dépassant les limites de taille maximales. Les personnes concernées ont reçu les résultats de leurs tests, mais la production de rapports et la recherche des contacts ont été perturbées.
En 2012, Knight Capital a connu une défaillance logicielle dans l’un de ses principaux systèmes d’acheminement des ordres. Selon la SEC, Knight a accumulé, sans le vouloir, des positions en titres de plusieurs milliards de dollars en environ 45 minutes et a perdu plus de 460 millions de dollars.
Ces exemples ne concernent pas le « Claude Code ». Ils illustrent une leçon plus générale : lorsque les logiciels interviennent dans les opérations réelles, la gouvernance, les contrôles, les essais et le soutien ne sont pas facultatifs.
À quoi devrait ressembler la mise en pratique
Cas d’utilisation n° 1 : Prototypage assisté par l’IA
Le problème : Les dirigeants d’entreprise ont souvent du mal à expliquer ce dont ils ont besoin tant qu’ils ne peuvent pas le visualiser.
La mise en pratique : Utilisez Claude Code ou des outils similaires pour créer des prototypes, des flux de travail cliquables, des maquettes de tableaux de bord ou des automatisations de validation de concept. Utilisez ensuite ces éléments pour affiner les exigences, valider les parcours utilisateurs et accélérer la conception.
La valeur ajoutée : une harmonisation plus rapide sans prétendre que le prototype est le système de production.
Cas d’utilisation 2 : Extensions régies autour des plateformes d’entreprise
Le problème : Les équipes développent souvent des applications parallèles parce que le backlog de l’entreprise est trop lent.
L’application pratique : Déterminez si le besoin relève de la configuration IFS, d’une extension approuvée, d’une intégration, d’un rapport ou d’un prototype temporaire. Définissez la propriété des données, les API, la sécurité, les tests et le soutien avant la mise en production.
L’avantage : une plus grande agilité sans créer un autre système d’enregistrement non pris en charge.
Cas d’utilisation 3 : code généré par l’IA avec des contrôles d’entreprise
Le problème : l’IA peut générer plus de code que les équipes ne peuvent en examiner, tester et prendre en charge correctement.
L’application pratique : traiter le code généré par l’IA comme un logiciel. Exiger une révision de l’architecture, un contrôle des sources, une couverture de test, une révision de sécurité, une gestion des versions, une documentation et une responsabilité clairement attribuée.
L’avantage : la rapidité alliée à la responsabilisation.
La situation devient urgente. Le rapport 2026 de Tricentis sur la transformation de la qualité révèle que 6 organisations sur 10 déclarent encore déployer du code non testé; 32 % d’entre elles indiquent que la pression exercée par la direction pour privilégier la rapidité au détriment de la qualité est un facteur déterminant, tandis que 30 % invoquent le volume de code généré par l’IA, devenu trop important pour être entièrement testé.
Ce qu’il faut éviter
L’erreur n’est pas d’utiliser des outils de codage basés sur l’IA. L’erreur est de considérer le code généré comme du « logiciel gratuit ».
Évitez de développer autour de l’application d’entreprise simplement parce que le backlog est gênant. Évitez de connecter des applications « skunkworks » directement aux données de production sans responsabilité ni contrôles. Évitez de créer une nouvelle source de vérité pour les clients, les stocks, les actifs, les contrats, les prix, les horaires ou les ordres de travail. Évitez de sauter les tests simplement parce que la démonstration semblait convaincante. Évitez de supposer que la personne qui a demandé la création de l’application sera en mesure d’en assurer le soutien six mois plus tard.
Les directives de l’OWASP concernant les applications LLM soulignent des risques tels que la gestion non sécurisée des résultats, la divulgation d’informations sensibles, l’autonomie excessive et la dépendance excessive. Ces risques s’aggravent lorsque les applications générées par l’IA sont connectées à des systèmes opérationnels et se voient conférer le pouvoir d’agir.
Comment Gogh peut vous aider
Gogh aide les clients d’IFS à utiliser l’IA sans perdre le contrôle opérationnel.
Notre vision est simple : l’IA doit accélérer la découverte, la conception, les essais, la capture des connaissances, l’automatisation et l’amélioration continue. Elle ne doit pas créer un deuxième modèle opérationnel non pris en charge, parallèle à celui d’IFS.
Nous aidons nos clients à commencer par le flux de travail, et non par l’outil. Nous déterminons clairement quels processus relèvent d’IFS, lesquels doivent être gérés par le biais d’intégrations approuvées, lesquels peuvent être pris en charge par le biais de rapports ou d’automatisation, et quelles idées n’en sont encore qu’à l’étape du prototype. Nous nous concentrons ensuite sur la mise en œuvre pratique : configuration, gestion des services, planification, exécution des tâches mobiles, intégrations, propriété des données, tests, préparation à la mise en service, adoption et optimisation à long terme.
L’objectif n’est pas de freiner l’innovation. L’objectif est d’empêcher que l’expérience d’IA d’aujourd’hui ne devienne le système obsolète de demain.
Si vos dirigeants, vos équipes opérationnelles ou vos analystes d’affaires expérimentent Claude Code ou d’autres outils de codage basés sur l’IA, la bonne question n’est pas « Pouvons-nous développer cela? »
La meilleure question est : « Cela devrait-il faire partie de la façon dont nous gérons l’entreprise? »
Commencez par là. Créez rapidement des prototypes. Gérez soigneusement. Déployez à grande échelle ce qui a sa place dans la plateforme d’entreprise. Maintenez l’activité de l’entreprise sans créer la prochaine génération d’applications non prises en charge. Communiquez avec nous pour obtenir plus d’information.
