Un inventaire de l'usage de l'IA débouche généralement sur une liste trop longue pour être traitée d'un seul mouvement. La question qui suit n'est alors pas « que devons-nous faire » mais « que devons-nous faire d'abord ». C'est une question de classification, et la réponse ne dépend pas du nombre de systèmes, mais de ce que ces systèmes font et pour qui.
Le premier facteur est le niveau de risque de l'application elle-même. Un système qui prépare des décisions concernant des personnes — recrutement, octroi de crédit, attribution de soins ou d'allocations — exige un traitement différent d'un outil qui reformule du texte pour un usage interne. Ce que signifie un niveau de risque élevé pour votre organisation varie donc selon l'application, et ces différences déterminent quels systèmes sont traités en priorité.
Le deuxième facteur est le rôle de l'organisation par rapport à ce système. Celui qui achète un modèle et l'utilise sans modification n'a pas les mêmes obligations que celui qui fait entraîner un modèle sur ses propres données ou qui adapte structurellement le résultat. Le fait que vous soyez fournisseur ou utilisateur d'une application d'IA ne détermine pas seulement les obligations applicables, mais aussi le temps nécessaire pour s'y conformer — un fournisseur a généralement plus à préparer qu'un utilisateur.
Le troisième facteur est de savoir si le système est déjà en usage ou encore en cours d'acquisition. Un risque déjà actif — avec de vrais utilisateurs, de vraies décisions, de vraies données — exige un ordre de traitement différent d'un risque encore en phase contractuelle, où des accords peuvent encore être formalisés avant la mise en service du système.
Cette classification n'est pas figée dans le temps. Un système qui présente aujourd'hui un risque faible peut ne plus l'être après une adaptation. Ce que signifie le fait d'adapter vous-même un modèle — réglage fin, un nouveau jeu de données, une autre application de la même technologie sous-jacente — dépend de ce qui change précisément, mais la classification établie auparavant ne tient donc pas automatiquement.
Il en va de même pour le changement de rôle. Une organisation qui acquiert un modèle prêt à l'emploi et l'adapte ensuite de manière significative peut ainsi passer d'utilisateur à fournisseur. Le moment où ce rôle change n'est pas toujours celui de l'adaptation elle-même, mais celui où cette adaptation modifie le caractère du système. C'est également une question de classification, et elle exige aussi une réévaluation dès que la situation évolue — pas un contrôle ponctuel qui reste valable ensuite.
Et un système encore en cours d'acquisition passe de planifiable à urgent au moment de sa mise en service. La classification qui s'appliquait à la phase contractuelle ne vaut pas pour la phase d'utilisation.
La conséquence pratique est qu'un inventaire ne produit pas une liste de priorités une fois pour toutes, mais une structure qui doit être parcourue à plusieurs reprises. Les systèmes présentant un niveau de risque élevé et un rôle de fournisseur actif exigent une attention immédiate. Les systèmes présentant un niveau de risque faible et pas encore en usage peuvent être planifiés — mais la planification doit prévoir un moment de réexamen, car des adaptations, un changement de rôle ou une mise en service peuvent inverser la classification.
Cela exige un endroit fixe où sont consignées les décisions relatives à cette classification : quel système a été désigné comme urgent, sur la base de quel facteur, et à quel moment cette évaluation a été effectuée pour la dernière fois. Une liste de décisions de contrôle est la forme sous laquelle cette classification devient démontrable — non pas comme une charge administrative supplémentaire, mais comme la seule preuve que la classification n'est pas le fruit du hasard, mais le résultat d'un processus reproductible.
La réglementation proprement dite — quels délais s'appliquent, quelles obligations par classe de risque correspondent à quelle date — se trouve ailleurs. Cette page décrit le mécanisme permettant de distinguer l'urgent du planifiable ; le texte de loi actuel et les délais ne se trouvent pas ici.
La distinction entre urgent et planifiable indique un ordre d'attention, pas le contenu du travail lui-même. Une fois qu'il est clair quelle application d'IA a la priorité, la question reste ouverte de savoir ce que cette application fait précisément avec le travail qui l'entoure : quelle part d'une tâche se déroule automatiquement, quelle part exige un contrôle, et quelle part reste confiée à une personne. C'est à cette question que répond le scan de travail de FTE TO AI, qui calcule pour chaque tâche quelle part du travail peut être reprise par l'IA — un complément à la classification établie ici, centré sur le contenu du travail lui-même.
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.