Agent IA en entreprise : les obligations à intégrer dès la conception

Quand un agent IA peut lire des données internes, écrire dans un outil métier ou influencer une décision concernant un salarié, la conformité devient un sujet d’architecture. Il faut définir ce que l’agent peut faire, quelles données il peut atteindre et où une validation humaine est nécessaire — avant de le connecter à la production.

Le périmètre retenu ici est précis : les points de conformité à traduire dans la conception d’un agent en entreprise. Le guide de gouvernance de Brief IA, daté du 22 octobre 2026, distingue les obligations déjà applicables de celles qui concernent certains systèmes à haut risque à une date ultérieure. Son état des lieux réglementaire sert de repère ; les obligations concrètes dépendent toutefois de l’usage et du contexte du système.

Le cas : un agent qui prépare des décisions RH

Considérons un cas de conception hypothétique : une équipe veut relier un agent à des dossiers internes pour aider à répartir des demandes et préparer des synthèses RH. L’agent ne décide pas formellement d’une promotion ou d’une affectation, mais ses propositions pourraient influer sur les personnes concernées. Traiter cette fonction comme une simple automatisation de texte ferait manquer le point essentiel : les usages RH sont particulièrement sensibles.

Le guide de Brief IA indique que les systèmes utilisés pour le recrutement, la sélection, la promotion, le licenciement, la répartition des tâches, l’évaluation ou la surveillance des salariés relèvent de l’annexe III de l’AI Act. Il situe l’application des obligations correspondantes au 2 décembre 2027, après le report qu’il attribue au Digital Omnibus. Cette échéance et son périmètre ne signifient pas qu’un projet puisse attendre pour examiner ses risques : l’usage prévu, les données et le rôle de l’agent doivent être clarifiés dès sa définition.

La première décision d’ingénierie est donc de décrire la fonction réelle, et non le nom commercial de l’outil. L’agent classe-t-il des demandes, produit-il une recommandation, ou déclenche-t-il une action qui modifie la situation d’une personne ? Ces fonctions ne présentent pas les mêmes conséquences. Séparer préparation, recommandation et décision aide à rendre les responsabilités vérifiables.

Les obligations à traduire dans le système

Le guide de gouvernance rappelle que, depuis le 2 février 2025, les pratiques interdites par l’AI Act sont prohibées et les organisations qui utilisent des systèmes d’IA doivent assurer un niveau suffisant de maîtrise de l’IA de leur personnel. Il indique aussi que les obligations de transparence s’appliquent depuis le 2 août 2026. Pour une équipe technique, ces repères appellent au minimum une description claire de la fonction du système, des consignes d’utilisation et des modalités de contrôle adaptées à son usage.

Le RGPD mérite une attention distincte lorsque l’agent participe à une décision individuelle. Le guide rappelle que son article 22 encadre les décisions fondées exclusivement sur un traitement automatisé lorsqu’elles produisent des effets juridiques ou des effets significatifs sur une personne. Il ne suffit donc pas d’ajouter une approbation humaine à l’écran : il faut déterminer si cette approbation est réelle, si la personne peut examiner la proposition et si l’action finale reste sous contrôle approprié.

Dans le cas hypothétique, l’agent pourrait préparer une synthèse, mais ne devrait pas être présenté comme un décideur si une personne doit examiner les éléments et assumer la décision. Cette distinction doit apparaître dans le flux de travail, les droits d’accès et la documentation, plutôt que reposer sur une consigne vague adressée au modèle.

Il y a également une dimension sociale. Le guide de gouvernance indique que le Code du travail impose l’information et la consultation du CSE lors de l’introduction de nouvelles technologies dans l’entreprise. Pour un projet qui touche l’organisation du travail ou les salariés, cette étape ne se réduit pas à une validation technique de dernière minute : elle doit être prise en compte dans le calendrier et la gouvernance du déploiement.

Du principe réglementaire au contrôle technique

Une obligation n’est opérante que si l’équipe peut la relier à des mesures observables. Le guide consacré aux agents en entreprise souligne qu’il faut savoir qui approuve les accès, surveille les décisions, corrige l’agent et peut l’arrêter. Ce partage des rôles donne un point de départ concret : attribuer un propriétaire métier et un responsable technique, puis prévoir une procédure d’arrêt et de révocation des accès.

Dans une architecture, cela conduit à distinguer les permissions de lecture des permissions d’écriture, à limiter l’agent aux données utiles à sa mission et à soumettre les actions ayant un impact sur une personne à un contrôle adapté. Les données de référence doivent aussi être identifiables et maintenues : une procédure périmée ou un document hors périmètre peut fausser une recommandation, même si le modèle répond de façon convaincante. Pour un agent qui passe par des connecteurs, le guide sur les permissions et OAuth d’un serveur MCP complète ces repères d’architecture.

Checklist avant d’ouvrir l’accès aux données

• Décrire la finalité de l’agent et les décisions ou actions qu’il peut influencer.
• Identifier les données accessibles, leur propriétaire et les personnes autorisées à les consulter.
• Séparer les droits de lecture, d’écriture et de suppression ; limiter chaque accès au besoin de la mission.
• Définir qui valide une recommandation, qui traite une erreur et qui peut interrompre le système.
• Prévoir des journaux permettant de comprendre les actions et les accès de l’agent.
• Évaluer si l’usage touche des décisions concernant des personnes et organiser les consultations requises.
• Documenter les limites de l’agent et former les personnes qui le supervisent.

Cette liste n’est pas une certification de conformité. Elle aide à repérer les questions qu’une équipe doit instruire avant de connecter un agent à des données ou à des actions sensibles. Le niveau de contrôle doit correspondre aux conséquences possibles : un outil qui prépare un brouillon n’appelle pas nécessairement les mêmes garde-fous qu’un système intervenant dans une décision RH.

Ce que ce cadrage change pour les développeurs

La conformité ne se greffe pas proprement après l’intégration. Elle influence le contrat des outils exposés à l’agent, les permissions accordées, les validations nécessaires et les traces disponibles. Une spécification utile devrait donc préciser non seulement le résultat attendu, mais aussi les actions interdites, les cas d’escalade et les conditions d’arrêt.

Pour reprendre le cas hypothétique, un premier périmètre raisonnable pourrait se limiter à préparer une synthèse consultable par une personne, sans modifier les dossiers ni déclencher de décision. Cette proposition est un choix de conception, pas une preuve qu’un déploiement est conforme ou sans risque. Elle rend néanmoins plus explicites les responsabilités et les contrôles à examiner avant d’élargir l’autonomie de l’agent.

La question utile n’est pas seulement « quel modèle choisir ? », mais « quelles décisions et quelles données lui confions-nous, et qui peut reprendre la main ? ». Pour les équipes techniques, répondre à cela avant l’intégration transforme les exigences réglementaires en limites concrètes du système.

Sources : Agents IA en entreprise : le guide de référence 2026.