La maîtrise de l'IA est souvent traduite en une formation : un module, un certificat, une case cochée. Ce n'est pas incorrect, mais ce n'est pas non plus ce que le mot exige. Maîtriser signifie qu'une personne comprend ce qu'un système fait et ne fait pas, où se situent les limites d'une réponse, et quand un résultat doit être vérifié avant d'être utilisé ailleurs. C'est une compétence différente de savoir manier une fenêtre de discussion.
Un collaborateur qui sait comment formuler une requête n'est pas forcément compétent au sens qui compte ici. La maîtrise de l'IA porte sur la reconnaissance du risque : quand une réponse contient-elle une erreur qui ne se remarque pas, quand des données de l'entreprise sont-elles partagées avec un système qui les utilise ailleurs, quand un résultat produit par l'IA devient-il la base d'une décision qui mériterait pourtant un contrôle. Ne pas enseigner cela, c'est apprendre aux collaborateurs à utiliser un outil sans leur apprendre quand ne pas lui faire confiance.
La maîtrise n'a de sens que si elle rejoint ce qui se passe réellement dans la pratique. Si des collaborateurs utilisent déjà un outil que personne n'a approuvé, une formation générique sur les principes de l'IA a peu de valeur tant que personne ne sait quels sont ces outils et à quoi ils servent. La maîtrise sans visibilité sur l'usage est un programme qui passe à côté de la pratique.
C'est là aussi que se trouve la manière la plus simple d'apprendre quelque chose : poser des questions. Non pas pour demander des comptes, mais pour comprendre ce qui se joue. Un collaborateur qui utilise un outil pour travailler plus vite le révèle rarement de son propre chef si la question ressemble à un contrôle susceptible de déboucher sur une sanction. La maîtrise ne commence donc pas par des instructions, mais par la création d'un climat où signaler ne représente pas un risque.
Une formation peut expliquer ce qu'est un modèle de langage, d'où vient le biais, et quand un résultat doit être vérifié. Une formation ne peut pas garantir que ces connaissances seront appliquées au moment où cela compte : sous la pression du temps, dans un délai serré, lors d'une tâche qui s'est déjà bien passée cent fois. Une formation ponctuelle ne peut pas non plus suivre les évolutions. Les systèmes sont modifiés, de nouveaux outils apparaissent, les usages se déplacent. C'est pourquoi la maîtrise ne relève pas d'un moment ponctuel, mais d'un rythme répété — tout comme la réévaluation périodique des classifications de risque n'est pas un exercice unique mais un processus récurrent.
La maîtrise chez les collaborateurs ne dispense pas une organisation de se poser la question de qui contrôle quoi. Si un collaborateur reprend un résultat de l'IA dans une décision, et que cette décision se révèle erronée, alors la question de qui est responsable lorsqu'une application d'IA commet une erreur ne trouve pas de réponse dans « le collaborateur aurait dû le savoir ». La responsabilité se situe à plusieurs niveaux : chez celui qui a déployé le système, chez celui qui a organisé le contrôle, chez celui qui a fixé le cadre. La maîtrise des individus fait partie de cette chaîne, elle ne la remplace pas. Ce que signifie le contrôle humain dans la pratique dépend de la question de savoir si la personne qui exerce ce contrôle comprend elle-même suffisamment ce qu'elle contrôle — sans cette compréhension, le contrôle n'est qu'une formalité.
De nombreuses organisations tentent de rattacher la maîtrise de l'IA à un processus de conformité ou de risque existant. Cela semble logique, mais dans la pratique, une seconde couche ajoutée à un processus existant n'est souvent pas utilisée : les collaborateurs suivent le processus qu'ils connaissent déjà et ignorent le nouveau, même s'il correspond mieux à la pratique. Pourquoi un second processus placé à côté de l'existant est ignoré est une question qui va au-delà de la formation : elle porte sur l'endroit où la maîtrise est consignée, vérifiée et utilisée dans le travail lui-même.
Nous ne pouvons pas dire quelle quantité de formation est suffisante, ni quel pourcentage de collaborateurs agit réellement différemment après un programme. Cela varie selon l'organisation, la fonction, le niveau de risque des tâches exercées. Une personne qui rédige quotidiennement des contrats clients avec l'assistance de l'IA a besoin d'un niveau de maîtrise différent d'une personne qui utilise l'IA occasionnellement pour un résumé. Il n'existe pas de réponse unique à la question « quelle quantité de formation suffit », et nous ne la donnons donc pas.
La maîtrise sans visibilité sur les risques des situations d'usage individuelles reste abstraite. Un collaborateur qui saisit des données de l'entreprise dans une fenêtre de discussion gratuite court un risque différent de celui qui utilise un système interne et protégé, et ce que vous faites des données de l'entreprise dans une fenêtre de discussion gratuite est une question qui exige une réponse différente selon la situation. La maîtrise n'est donc pas un programme unique pour toute l'organisation, mais un ancrage sur ce avec quoi les personnes travaillent réellement.
Cet ancrage commence par savoir quelles tâches sont déjà soutenues par l'IA et dans quelle mesure. Le scan de travail de FTE TO AI calcule, pour chaque tâche, quelle part du travail peut être reprise par l'IA, offrant ainsi une image concrète de l'endroit où la maîtrise est le plus nécessaire : non pas de manière générale, mais à l'endroit où le travail change réellement.
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.