Une équipe voulait tester quelque chose. Un chatbot pour les questions clients, un script qui résume des rapports, une connexion avec un modèle de langage pour trier des e-mails. Il n'a fallu aucune grande décision : quelqu'un disposait d'un compte, d'une clé API ou d'une période d'essai gratuite, et en une après-midi, quelque chose fonctionnait déjà. Le pilote marchait, ou marchait suffisamment bien, et personne n'avait plus de raison de l'arrêter.
Ce n'est pas une exception. C'est la manière ordinaire dont l'IA pénètre dans une organisation. Pas par un appel d'offres ou un budget approuvé, mais par un montage pilote qui survit à son propre statut d'essai. La phase de test n'a jamais été officiellement clôturée, parce qu'il n'y a jamais eu non plus de commencement officiel à clôturer.
Un pilote qui fonctionne est utilisé. Et ce qui est utilisé devient une dépendance. L'équipe qui a construit l'outil de synthèse de rapports a peut-être quitté l'organisation, mais la synthèse arrive encore chaque semaine. Personne n'a reçu pour mission de l'arrêter, et personne ne veut prendre le risque qu'une chose cesse de fonctionner sans savoir ce qui la remplacera.
À cela s'ajoute le fait qu'un montage pilote n'a généralement pas de responsable au sens qu'attend une structure de gouvernance. Aucune classification des risques n'a été établie, aucune analyse des données n'a été réalisée, aucune décision n'a été prise sur qui est responsable en cas de problème. Le pilote existe dans un espace intermédiaire : trop utilisé pour être ignoré, trop informel pour être géré. C'est exactement le schéma qui conduit à des collaborateurs qui utilisent un outil que personne n'a approuvé — sauf qu'ici, c'est au niveau de l'équipe plutôt qu'au niveau individuel.
Le réflexe lors de la découverte d'un montage pilote non autorisé est souvent : qui a permis cela, et pourquoi ne le savions-nous pas. Cette question est compréhensible, mais elle produit l'effet inverse. Quiconque sent, dès la première conversation, qu'une recherche de coupable s'annonce, ne racontera plus rien la fois suivante. Et le prochain montage pilote — qui ne manquera pas d'apparaître — disparaîtra alors tout aussi bien de la vue que celui-ci.
Un inventaire construit sur la confiance produit plus de résultats qu'un audit construit sur le contrôle. Non pas parce que les personnes n'auraient rien à cacher, mais parce que l'information que vous recherchez se trouve chez l'utilisateur, et cet utilisateur ne parle que s'il n'est pas sanctionné pour ce qu'il révèle.
Dès qu'un montage pilote est identifié, la première question n'est pas de savoir s'il peut continuer à exister, mais ce qu'il fait exactement. Quelles données y entrent, qui utilise le résultat, et que se passe-t-il si le résultat est erroné. Ce sont les mêmes questions qui s'appliquent à toute autre application d'IA, et la réponse déterminera s'il s'agit d'un outil informel ou d'un risque qui mérite de l'attention.
Vient ensuite la classification : l'application s'inscrit-elle dans une catégorie de risque déjà existante, ou nécessite-t-elle une nouvelle évaluation. Puis : que doit-on documenter pour démontrer que l'organisation sait ce qui fonctionne et pourquoi. C'est précisément ce que traite ce qu'il faut documenter par application — non pas comme une bureaucratie supplémentaire, mais comme la documentation minimale nécessaire pour distinguer un pilote d'un risque.
Un montage pilote qui passe ce test peut continuer à exister, désormais avec un responsable et une classification. Un montage pilote qui ne passe pas le test doit être démantelé — mais il s'agit d'un processus contrôlé, pas d'un licenciement de la personne qui l'a un jour lancé.
Le montage pilote qui n'a jamais été arrêté est une forme d'un schéma plus large. Pensez à l'extension de navigateur ayant accès à votre messagerie que quelqu'un a un jour installée pour gagner du temps, ou aux données d'entreprise qui atterrissent dans une fenêtre de chat gratuite parce que c'était plus rapide que l'outil officiel. Toutes ces situations partagent une caractéristique : elles naissent d'un besoin pratique, pas d'un choix politique, et elles perdurent tant que personne ne s'interroge à leur sujet.
La liste informatique des logiciels approuvés n'est donc pas le point de départ d'un inventaire — elle est le point de départ d'une recherche de ce qui échappe à cette liste. Qui souhaite savoir à quoi ressemble cette recherche trouvera une méthode dans comment construire un inventaire de l'IA.
Un montage pilote qui apparaît au grand jour soulève généralement une question qui va au-delà de la gouvernance : pourquoi cela fonctionnait-il en réalité si bien que personne n'a osé l'arrêter. C'est une question sur le travail lui-même, pas seulement sur le risque. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, rendant ainsi visible ce qu'un montage pilote laissait déjà entrevoir implicitement : qu'une partie du travail peut être organisée différemment. Là où le Responsible AI Scan dresse la carte de ce qui fonctionne et sous quel risque, le scan de travail montre d'où provient cet usage et ce qu'il signifie structurellement pour la répartition des tâches.
Le Responsible AI Scan, avec l'inventaire, la classification et l'ensemble de gouvernance décrits ci-dessus, est en cours de développement. Qui y est déjà confronté aujourd'hui et souhaite être informé dès que l'outil sera disponible peut s'inscrire sur la liste d'attente.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.