Un chef d'équipe cherche une solution à un problème récurrent : trop de texte, trop peu de temps, une échéance qui ne bouge pas. Il trouve quelque part un outil qui accélère le travail. L'outil coûte peu, se paie avec une carte de crédit ou un compte privé, et ne demande aucune approbation de l'IT. En une journée, le service travaille déjà avec. Personne n'a rien fait de mal — il y avait un problème, il y avait une solution, et le chemin entre les deux passait en dehors de tout formulaire.
Ce n'est pas une exception. C'est le schéma habituel dès qu'un outil d'IA est plus économique et plus accessible que la procédure pour le demander. Plus la voie de demande est lourde, plus il est probable que quelqu'un la contourne. La liste IT des applications approuvées ne décrit alors plus ce qui se passe réellement, mais ce qui a un jour été demandé.
Un abonnement qui fonctionne n'est pas résilié. Le service qui utilise l'outil voit le problème résolu, pas la faille de gouvernance qui en est résultée. Sans élément déclencheur, personne ne vient spontanément signaler qu'on travaille en dehors du champ de vision de l'IT ou du risk avec un outil qui traite du texte, des données clients ou des documents internes.
Ce schéma est comparable à une extension de navigateur ayant accès à votre messagerie : quelqu'un installe quelque chose de petit, cela fonctionne, et la question de savoir qui lit encore les données n'est jamais posée car aucun moment ne se présente pour la poser. C'est ainsi que se forme un ensemble d'applications, individuellement petites et utiles, qui constituent ensemble un angle mort plus grand que quiconque n'en est individuellement responsable.
Le premier réflexe est souvent : repérer, désigner, faire arrêter. Cela produit l'effet inverse. Celui qui sait qu'un abonnement personnel entraînera une réprimande ne le signale pas — il utilise désormais l'outil plus discrètement, peut-être via un autre compte, peut-être en dehors des heures de bureau. L'inventaire ne devient alors pas plus complet mais moins complet, et le problème se déplace vers un endroit encore plus difficile à voir.
Un inventaire qui fonctionne ne commence pas par la question « qui a fait cela » mais par « qu'est-ce qui tourne ici ». Sans sanction, vous obtenez une réponse à la question de savoir quels outils sont utilisés, pour quel travail, et avec quelles données. Avec une sanction, vous n'obtenez que du silence, et un service qui cachera encore mieux le prochain outil.
La première étape n'est pas de corriger mais de rendre visible. Cela signifie poser des questions aux personnes qui font le travail, pas seulement aux systèmes que gère l'IT. Comment constituer un inventaire IA décrit à quoi peut ressembler cette tournée de questions : ce qui est utilisé, pour quelle tâche, avec quelles données en entrée.
Dès qu'une application est identifiée, la question suivante n'est pas de savoir si elle peut continuer d'exister, mais quel rôle elle joue et quel niveau de risque lui correspond. Un outil qui résume des notes internes demande autre chose qu'un outil qui traite des données clients. Cette classification détermine ce qui doit être consigné par application — non pas comme un exercice administratif, mais comme base permettant de démontrer plus tard ce qui se passait et pourquoi c'était justifié.
Le risque d'un abonnement isolé n'existe pas seul. Le même schéma d'une chose qui arrive sans demande se retrouve avec une installation pilote qui n'a jamais été arrêtée et avec un fournisseur qui a intégré l'IA dans son produit sans que cela n'ait fait l'objet d'une discussion séparée. Celui qui recense un service avec son propre abonnement ferait bien de poser la même question plus largement — non pas comme une chasse aux contrevenants, mais comme un état des lieux de ce qui se passe réellement.
Un inventaire ponctuel consigne ce qui tourne aujourd'hui. Sans répétition, c'est une photo qui vieillit dès le jour où elle est prise. De nouveaux services découvrent de nouveaux outils, des abonnements existants reçoivent de nouvelles fonctions, et le prochain angle mort se forme de la même manière que le précédent. La façon de reconnaître ce schéma avant qu'il ne se répète est décrite dans des collaborateurs qui utilisent un outil que personne n'a approuvé — comme suite à l'inventaire, pas comme son remplacement.
Un abonnement qu'un service a souscrit lui-même vous apprend généralement quelque chose sur le travail lui-même : il y avait une tâche qui prenait trop de temps, et quelqu'un a cherché une issue. Cette issue est désormais identifiée, mais la question sous-jacente demeure — quelle part de ce travail peut structurellement être confiée à l'IA, et sous quelles conditions. Le scan de travail de FTE TO AI calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA, indépendamment de l'outil qu'un service avait déjà trouvé de sa propre initiative.
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.