Un aperçu des logiciels approuvés vous indique ce qui a été acheté, pas ce qui est utilisé. Entre ces deux notions se trouve un écart qui s'agrandit à mesure que les outils d'IA deviennent plus accessibles : une extension de navigateur, un compte gratuit, un chatbot que quelqu'un a utilisé de sa propre initiative pour accomplir une tâche plus rapidement. Ce que les données d'achat et de licences révèlent constitue un point de départ, mais pas un point final. Le reste de la réponse se trouve auprès des personnes qui effectuent le travail.
Si vous demandez « utilisez-vous des outils d'IA qui ne sont pas approuvés », vous n'obtenez généralement pas de réponse complète. Non pas parce que les gens veulent cacher quelque chose, mais parce que la question implique un risque. Celui qui admet utiliser un outil qui ne figure pas sur la liste s'attend à une conséquence : un avertissement, un entretien avec un responsable, une mention dans un dossier. Cette perspective suffit à faire taire quelqu'un, même si l'usage est anodin, voire utile.
Le résultat est une image déformée. Non pas parce qu'il ne se passe rien, mais parce que ce qui se passe n'est pas signalé. Un inventaire qui repose uniquement sur des déclarations volontaires n'enregistre principalement que ce qui était déjà connu.
La question elle-même ne change rien si le contexte reste inchangé. Ce qui fonctionne, c'est un ensemble d'éléments réunis : la question est dissociée d'un moment d'évaluation individuelle, les réponses ne sont pas rattachées à un nom dans un rapport transmis à la hiérarchie, et l'objectif est expliqué au préalable — il s'agit d'un aperçu de l'organisation, pas d'un jugement porté sur une personne.
Cela ne signifie pas qu'aucune enquête ni aucun entretien n'a lieu. Cela signifie que la question est posée dans un cadre où « oui, j'utilise cela » n'entraîne pas de correction. Ce n'est qu'alors que la réponse passe de ce que la personne pense que vous voulez entendre à ce qui se passe réellement.
Le résultat d'un entretien bien mené n'est pas une liste de noms d'outils. C'est un ensemble de données qui, pour chaque application, peut être rattaché à une tâche ou à un processus : quelle application, pour quelle partie du travail, avec quelles données, et qui d'autre y est concerné. C'est la même structure que ce que vous devez consigner par application lorsqu'une application est identifiée via les achats ou l'informatique — sauf qu'ici la source est l'utilisateur, pas le contrat.
Concrètement, cela signifie : un nom d'application, une brève description de son usage, une estimation de la fréquence, et une indication du type de données qui y sont saisies. Pas de spécifications techniques, pas d'évaluation du fournisseur à ce stade — cela viendra plus tard, lors de la classification. À ce stade, il s'agit d'obtenir une vue d'ensemble, pas de porter un jugement.
Ces entretiens constituent l'un des canaux, à côté des signaux techniques que vous consultez séparément. Ce que vous recueillez auprès des utilisateurs, vous le placez à côté de quels signaux informatiques sont exploitables comme piste distincte, et ce n'est qu'en les combinant qu'émerge une image plus complète que celle que chaque source produirait séparément. Une application qui apparaît dans les journaux réseau mais que personne n'explique reste une interrogation. Une application mentionnée lors d'un entretien mais qui ne laisse aucune trace numérique est tout aussi réelle — et peut-être justement pour cette raison plus facile à négliger.
L'ordre et la répétition de ce type d'interrogation dépendent de l'organisation : combien de départements, quel degré de hiérarchie dans les lignes de reporting, quelle expérience préalable de ce type d'inventaire. Dans une organisation comportant plusieurs sites ou une structure hiérarchisée, comment le demander aux collaborateurs sans sanction fonctionne un peu différemment que dans un site unique à structure plate, simplement parce que le nombre de niveaux intermédiaires où le principe de « non-sanction » doit être maintenu est plus élevé.
Une réponse honnête des collaborateurs constitue la matière première du reste de l'inventaire. Sans cette matière première, vous classifiez une liste que vous connaissiez déjà, ce qui n'est pas un inventaire mais une confirmation. Avec cette matière première, vous pouvez poursuivre vers comment construire un inventaire de l'IA à une échelle qui dépasse un seul département ou un seul site, avec des apports provenant de plusieurs directions à la fois.
Le ton de la question déterminera donc en partie la qualité de la réponse. Il ne s'agit pas d'une formulation plus habile, mais d'une structure dans laquelle répondre ne comporte aucun risque.
Dès qu'il est clair quelles applications sont réellement utilisées et pour quelles tâches, la question passe de « qu'utilisons-nous » à « qu'est-ce que cela signifie pour le travail lui-même ». C'est une question différente, avec un instrument différent. Le scan de travail de FTE TO AI calcule, pour chaque tâche, quelle part du travail peut être reprise par l'IA, sur la base des tâches que vous avez déjà recensées via cet inventaire. Là où le Responsible AI Scan met en évidence l'usage et les risques, le scan de travail examine le contenu du travail lui-même : quelles tâches se prêtent à une reprise, et dans quelle mesure. Ces deux questions sont proches l'une de l'autre, mais ne sont pas interchangeables.
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.