Le shadow IT ne passe pas à l'échelle dans une entreprise réglementée

N'importe qui dans vos équipes peut aujourd'hui construire une automatisation utile en un après-midi. Un script lit une boîte mail, appelle un modèle, dépose un résumé dans un ticket. La démo est magnifique. Ça tourne sur un portable. Pendant un temps, ça aide même.

Sauf qu'il y a un gouffre entre cette automatisation et un agent que l'organisation exploite vraiment, et ce gouffre n'est pas une question de qualité de modèle. Il concerne tout ce que la démo n'a jamais eu à gérer : l'identité, le moindre privilège, la dérive, l'audit, et le simple fait que la chose agit désormais sur des données qu'elle n'a pas produites.

La plupart des équipes lisent cet écart comme un problème de prompt. Elles supposent qu'un meilleur prompt, un modèle plus gros ou une chaîne plus astucieuse transformera le script du portable en quelque chose que l'entreprise peut assumer. Non. L'écart entre une automatisation sur portable et un agent en production est un écart d'architecture, pas de prompt. Les pièces manquantes sont structurelles, et aucune ingénierie de prompt ne les fait apparaître.

Une règle déterministe et un agent probabiliste sont deux systèmes différents

Prenez la différence concrètement.

Une règle déterministe de validation de facture passe ou échoue, et elle échoue de la même manière à chaque fois. Vous pouvez la tester une fois et faire confiance au test. Toute votre gouvernance IT repose sur cette hypothèse : un build testé reste testé, les releases sont sous contrôle du changement, et la même entrée produit la même sortie.

Un agent qui valide un dossier de crédit brise ces trois hypothèses. Il lit des documents qu'il n'a jamais vus, raisonne dessus de façon probabiliste, et peut arriver à une conclusion différente demain parce que le modèle sous-jacent a été mis à jour pendant la nuit. Rien dans votre processus de contrôle du changement n'a été conçu pour remarquer que le système a changé alors que vous n'avez rien livré.

C'est la première chose à admettre honnêtement. Une automatisation sur portable peut être réellement utile et totalement irresponsable en même temps. Ces deux propriétés ne s'opposent pas sur la machine de quelqu'un. Elles deviennent irréconciliables dès que la chose touche du travail réglementé.

Trois basculements définissent le gouffre

Le gouffre n'est pas un mur. Il y en a trois, et chacun est l'endroit où un pilote bien intentionné meurt discrètement.

Du code de confiance à l'entrée contrôlée par l'adversaire. Le logiciel traditionnel traite des données que vos systèmes ont produites. Un agent lit du contenu qu'il n'a pas écrit : un e-mail client, un contrat scanné, un PDF d'un tiers. Ce contenu n'est pas fiable. Si un document empoisonné contient du texte qui ressemble à une instruction, et que l'agent le traite comme telle, le document vient de détourner un système ayant accès à vos plateformes centrales. C'est l'injection de prompt indirecte, et la seule configuration ne l'arrête pas. Le script du portable n'avait pas à s'en soucier. L'agent en production ne peut pas se le permettre.

Des releases statiques à la dérive continue. Votre processus de release suppose que le changement est un événement que vous planifiez. Une mise à jour de modèle est un changement que vous n'avez ni planifié ni livré. Le comportement de l'agent bouge sous vos pieds. Un système bien élevé dans la démo du mois dernier peut se dégrader silencieusement ce mois-ci, et sans surveillance de la dérive vous l'apprenez d'un client, pas d'un tableau de bord.

De la stack d'un fournisseur à la stack de votre régulateur. Sur un portable, le développeur prend le modèle le plus commode. Dans une entreprise réglementée, quels modèles vous pouvez utiliser, et où ils tournent, est fixé par votre régime réglementaire et votre propre homologation de sécurité. La commodité n'est pas une entrée admise dans cette décision.

Chaque basculement correspond à un morceau d'architecture que la démo n'avait pas. L'automatisation a passé la démo précisément parce qu'aucun des trois n'était dans le périmètre. La version entreprise ne passe pas à l'échelle parce que les trois y sont.

L'identité est l'endroit où le modèle du portable casse en premier

Des trois basculements, l'identité est celui qui arrête les projets au comité de sécurité, il vaut donc la peine d'être précis.

L'automatisation sur portable tourne sous le jeton personnel d'un développeur, avec un accès permanent à la production. C'est efficace, et c'est aussi le constat unique qui met fin à la mission. Un jeton de développeur volé est un passe-partout. Rien en lui n'est restreint, éphémère ou journalisé à la granularité qu'exige un processus réglementé.

La posture en production est l'inverse. Chaque agent tourne sous sa propre identité non humaine, avec des credentials à courte durée de vie et à moindre privilège, et une allow-list de sortie explicite. L'agent reçoit quelques capacités nommées, read_dossier, request_document, post_decision_for_review, et rien d'autre. Un credential d'agent volé ne vaut alors presque rien, parce qu'il n'y a pas de secret statique à voler et que l'identité ne peut exécuter que la poignée d'actions pour laquelle elle a été cadrée, vers la poignée de destinations qu'elle a le droit d'atteindre.

Remarquez ce que cela change pour la personne qui doit approuver. « L'agent peut toucher nos systèmes » est inauditable et inapprouvable. « L'agent peut exécuter ces sept actions nommées, chacune journalisée » est un contrôle qu'un comité peut signer. Cette traduction, d'une capacité vague vers un ensemble d'actions nommées et testables, c'est l'essentiel de ce que signifie transformer du shadow IT en actif d'entreprise.

Transformer un outil en actif que l'entreprise peut assumer

Rien de tout cela n'est un argument contre les automatisations construites par les équipes. Ces expériences font émerger les bonnes idées, et elles doivent continuer. L'argument porte contre le fait de faire passer une expérience pour un système de production parce qu'elle marche en démo.

Faire d'une automatisation sur portable quelque chose que l'organisation exploite, c'est lui donner trois choses qu'elle n'a jamais eues : une identité, une frontière autour de ce qu'elle lit, et un enregistrement de ce qu'elle a décidé et pourquoi. Ajoutez une surveillance de la dérive pour qu'une mise à jour silencieuse du modèle ne la dégrade pas sans qu'on le voie. Ajoutez une couche de politique pour que les décisions à conséquence restent avec une personne. Ce n'est pas de la bureaucratie posée sur un outil qui marche. C'est la différence entre un outil et un actif que l'entreprise peut défendre devant un régulateur.

Les organisations coincées dans le cimetière des pilotes ont presque toujours passé la démo puis heurté l'un de ces murs. Environ 40 % des projets d'IA agentique devraient être annulés d'ici 2027 (Thoughtworks), et l'essentiel de cet échec est architectural, pas technique. Elles ont mis à l'échelle le portable, pas l'architecture, et ce ne sont pas la même chose.

Le recadrage à emporter dans votre prochaine revue d'architecture est celui-ci. Non pas « comment rendre notre automatisation plus précise ? » mais que doit construire notre organisation pour que cette chose puisse agir ici en sécurité, sous une identité, sur des données que nous ne contrôlons pas, avec un enregistrement que nous pouvons inspecter ? Répondez, et vous avez franchi le gouffre. Sautez l'étape, et vous avez une très bonne démo qui ne quittera jamais le portable.

Si vous voulez éprouver où l'une de vos automatisations se situe sur ce gouffre, prenez rendez-vous et apportez-nous la plus difficile.