Référent IA : rôle, périmètre et outillage technique pour une PME

Dans beaucoup de PME, la fonction de référent IA apparaît sans fiche de poste. Quelqu'un de motivé est désigné, souvent parce qu'il utilise déjà les outils. La première question qu'il reçoit n'est pourtant pas « quel outil choisir ? », mais « qui valide cet usage ? ». Et il la reçoit avant d'avoir les moyens d'y répondre.

Pour répondre sérieusement, il faut savoir trois choses : quels usages et quels agents existent, avec quels droits ils agissent, et comment on vérifie ce qu'ils produisent. Aucune de ces réponses ne s'obtient en animant un atelier. C'est pour cela que le rôle devient technique, sans pour autant exiger de savoir coder.

Cet article suit cette logique : d'abord pourquoi le rôle change, puis le périmètre à tenir, puis les cinq instruments qui permettent de le tenir. Il complète l'article sur la structuration des processus, qui traite le préalable : cartographier le travail avant d'outiller.

Les incidents liés à l'IA remontent déjà au plus haut niveau. Selon une étude IBM publiée le 14 octobre 2026, 85 % des dirigeants français signalent un incident lié à l'IA remonté au conseil ou au comité exécutif dans l'année. Pourtant, 44 % seulement ont modifié leur gouvernance. Toujours selon cette étude, 87 % attendent une autonomie décisionnelle des agents d'ici 2027, mais 29 % seulement disposent d'une gouvernance conçue pour l'IA agentique.

Ces chiffres décrivent un décalage : les incidents sont déjà là, la gouvernance n'a pas suivi, et l'autonomie des agents va augmenter. Le référent se retrouve précisément dans cet écart.

Les agents modifient aussi la nature du risque. Selon une étude de Salt Security publiée le 13 octobre 2026, fondée sur plus de 380 répondants et sur de la télémétrie, 49,8 % des organisations confirment ou soupçonnent une action d'agent non prévue ou non autorisée au cours des douze derniers mois. 86,4 % ont au moins un agent en service. Salt Security est un éditeur de sécurité : ces chiffres décrivent ses répondants, pas toutes les entreprises.

La différence est concrète. Un assistant conversationnel produit un texte qu'une personne relit avant d'en faire quelque chose. Un agent, lui, exécute : il lit des fichiers, appelle des services, envoie, installe ou modifie. Le risque ne se situe plus seulement dans la qualité de la réponse, mais dans les actions et dans les droits qui les rendent possibles.

Un cas récent l'illustre. Le 22 octobre 2026, Forever Security a décrit un fichier d'instructions trouvé dans le dossier Téléchargements d'un client : il poussait un agent de code à installer un paquet piégé. L'installation a été bloquée avant exécution. Selon CSO Online (26 octobre 2026), les chercheurs ont reproduit la technique dans leurs tests, la plupart du temps avec une charge inoffensive, et la configuration modifiée de l'agent persistait d'une session à l'autre. Selon Forever Security, il n'y a pas de faille à corriger côté éditeur : l'agent fait ce pour quoi il est conçu, avec les droits dont il dispose.

C'est exactement le type de situation que le référent doit pouvoir anticiper. Pas en devenant expert en sécurité, mais en sachant poser les bonnes questions au bon moment, et en sachant à qui les transmettre.

Un éditeur spécialisé propose trois profils autour de l'IA : champion, product owner et responsable IA. Dans son article publié le 19 septembre 2026, il estime que le champion représente environ 10 à 20 % d'un poste, et que, dans une PME de 50 à 200 utilisateurs, ces rôles sont souvent tenus par deux personnes. Ce sont des repères d'éditeur, pas une norme : ils aident à dimensionner, sans dire ce qui convient à votre entreprise.

Le temps compte moins que le périmètre. Un référent à qui l'on confie « l'IA » en général finit par tout absorber, ou par ne rien trancher. Il faut donc dire clairement ce qu'il fait, et surtout ce qu'il ne décide pas seul.

Le tableau suivant propose un périmètre de départ. La colonne de droite est aussi importante que celle du milieu : elle protège le référent, et elle oblige les autres fonctions à rester dans la boucle.

On voit le schéma qui se répète sur chaque ligne : le référent organise, rend visible et déclenche, mais la décision qui engage l'entreprise reste à la direction, au métier ou à la DSI. Ce partage n'est pas une prudence de forme. C'est ce qui permet au rôle de tenir quand un usage pose problème.

Il reste une question : avec quoi le référent tient-il ce périmètre au quotidien ? C'est l'objet des cinq instruments.

Ces instruments ne sont pas une liste à cocher : ils s'enchaînent. Sans le registre, la grille n'a rien à évaluer. Sans la grille, l'inventaire accorde des droits sans critère. Et sans tests ni procédure, tout le reste se dégrade au premier changement de modèle.

Ce sont des propositions de méthode de ProovUp, à adapter à votre taille et à vos risques : ni des normes, ni des exigences réglementaires.

Le registre est le point de départ, parce qu'on ne gouverne pas ce qu'on ne voit pas. Dans la plupart des PME, les usages se sont installés par le bas : un abonnement pris par une équipe, une extension de navigateur, un agent branché sur une boîte mail partagée. Le référent ne cherche pas à les interdire, il cherche à les rendre visibles.

Une ligne de registre par usage, avec au minimum ces cinq rubriques :

Le champ le plus souvent oublié est le propriétaire technique. Un usage sans propriétaire technique, c'est un usage que personne ne saura modifier, suspendre ou retirer le jour où il faudra le faire. Pour le détail des champs, voir notre article sur le registre IA.

Le registre dit ce qui existe. Il ne dit pas encore si c'est acceptable : c'est le rôle de la grille.

La grille sert à prendre la même décision de la même façon, quel que soit l'usage et quelle que soit la personne qui le demande. Sans elle, l'arbitrage dépend de l'enthousiasme du demandeur ou de l'humeur du moment.

Elle tient en cinq critères. Pour chacun, une question à poser et un signal qui doit faire ralentir :

Un signal d'alerte n'est pas un refus. Il veut dire que l'usage passe par une revue plus poussée, avec la DSI, le juridique ou le métier selon le critère concerné. Les deux critères les plus sous-estimés sont les droits et la réversibilité : on se demande rarement si un outil agit avec plus de droits que la personne qui le lance, et encore moins comment on l'arrêterait.

Le critère « Droits » mène directement à l'instrument suivant : une fois l'usage accepté, encore faut-il savoir précisément ce que chaque agent a le droit de faire.

C'est l'instrument le plus technique, et celui qui fait la différence avec un simple suivi des usages. Un agent n'est pas un utilisateur comme les autres : il agit vite, en volume, et souvent sans que personne regarde chaque action. Ses droits doivent donc être connus, limités et traçables.

L'inventaire repose sur cinq principes :

Dans l'étude de Salt Security citée plus haut, parmi les organisations concernées, plus de la moitié citent un appel API externe non autorisé. C'est un point de contrôle concret : pour chaque agent, l'inventaire doit dire vers quels services il peut communiquer, et ce qui se passe s'il tente d'en joindre un autre.

Le cas du fichier d'instructions piégé montre un autre point : ce qui guide un agent fait aussi partie de son périmètre. Ses fichiers de consignes, ses connecteurs et sa configuration doivent être listés, avec un responsable, au même titre que ses droits. Pour aller plus loin sur ce sujet, voir notre article sur le cadrage et la sécurité des agents IA.

Des droits bien bornés limitent ce que l'agent peut faire. Ils ne garantissent pas que ce qu'il produit est juste : c'est le rôle du circuit de vérification.

L'enquête annuelle de Stack Overflow, publiée le 6 octobre 2026, montre que la confiance dépend de la vérifiabilité : 48,0 % des répondants font confiance à l'IA quand ils peuvent vérifier facilement la sortie, contre 6,6 % pour des décisions importantes.

Autrement dit, la confiance ne se décrète pas : elle se construit en rendant la vérification possible. Le référent organise donc un circuit simple, en quatre temps : la sortie est produite, elle passe un contrôle proportionné au risque, une personne nommée la valide, et une trace est conservée.

Le mot important est « proportionné ». Un résumé de réunion interne n'appelle pas le même contrôle qu'une réponse envoyée à un client ou qu'une modification dans un logiciel de gestion. Le niveau de contrôle se décide une fois, dans la grille d'évaluation, et non au cas par cas. Le référent n'a pas à tout relire : il s'assure que quelqu'un relit ce qui doit l'être.

Reste une question : ce circuit fonctionne aujourd'hui, mais tiendra-t-il quand le modèle, le fournisseur ou les paramètres changeront ?

Les outils d'IA changent sans prévenir : nouvelle version de modèle, nouveau paramètre par défaut, nouveau connecteur. Un usage validé en septembre peut se comporter autrement en novembre. Ce dernier instrument sert à le détecter, puis à réagir.

La procédure d'incident doit être écrite avant d'en avoir besoin. Le jour où un agent envoie un message qu'il n'aurait pas dû envoyer, personne n'a le temps de se demander qui prévenir. Une page suffit : qui décide de suspendre, comment on conserve les traces, qui informe les personnes concernées, et quand on revient sur la grille pour éviter que ça se reproduise.

La boucle se referme ici : chaque incident alimente le registre et fait évoluer la grille.

Ces instruments donnent au référent une vision d'ensemble. Ils ne lui donnent pas toutes les responsabilités. Le juridique, la sécurité informatique et les métiers restent responsables de leurs décisions : le référent organise la preuve, l'inventaire et la circulation de l'information entre eux.

Dans les faits, trois appuis sont indispensables. La direction, pour arbitrer quand un usage utile est aussi risqué. La DSI ou le prestataire informatique, pour mettre en œuvre les droits, les journaux et les retraits. Et les responsables métier, qui restent propriétaires de leurs usages et de la relecture de ce qui en sort. Ces rôles s'articulent avec la gouvernance des usages IA de l'entreprise.

Un rôle porté seul par une personne, sans appui de la direction et de la DSI, tient rarement dans la durée. La meilleure protection du référent, c'est un périmètre écrit et validé par la direction.

Le référent IA n'est plus seulement un animateur. Il doit savoir quels agents agissent, avec quels droits, et comment vérifier leurs sorties. Les cinq instruments s'enchaînent : le registre rend visible, la grille décide, l'inventaire borne, la vérification contrôle, et les tests maintiennent dans le temps.

Inutile de tout déployer d'un coup. Une fois le premier usage passé par les cinq instruments, étendez la méthode aux suivants : chaque nouvel usage ira plus vite, parce que la grille, l'inventaire et la procédure existent déjà.

Pour former la personne qui portera ce rôle, le parcours Référent IA couvre la stratégie, le ROI, l'adoption, la gouvernance et la conformité, en intra-entreprise : 3 jours, soit 21 heures, à partir de 6 500 € HT par entreprise, TVA 20 % en sus.

• IBM, étude gouvernance IA : communiqué du 14 octobre 2026, texte daté de Londres le 15 octobre 2026. Enquête auprès de dirigeants, périmètre France.
• Salt Security, « État de l'IA agentique et de la sécurité des API, 2S 2026 », 13 octobre 2026. Éditeur de sécurité, plus de 380 répondants.
• SafeBrain, « IA owner, champion, rôles et responsabilités », 19 septembre 2026. Blog d'éditeur : repères, pas une norme.
• Stack Overflow, Developer Survey 2026, 6 octobre 2026.
• Forever Security, analyse d’un fichier d’instructions piégé dans le dossier Téléchargements, 22 octobre 2026. Éditeur de sécurité : cas client et tests de reproduction.
• CSO Online, article sur les tests de reproduction (Codex, Claude Code), 26 octobre 2026.

Limites : enquêtes déclaratives et repères d'éditeurs. Les instruments proposés sont une méthode, à tester dans votre contexte.