IA Act : pourquoi un groupe n'est pas une seule entreprise face à la loi

La plupart des dirigeants de groupe abordent l'IA Act comme une question unique, traitée une fois pour toutes au niveau du siège. C'est une erreur de raisonnement.

Le règlement européen sur l'intelligence artificielle ne connaît pas la notion de groupe. Il connaît des entités juridiques, et il leur attribue des rôles. Une holding, ses filiales françaises, une succursale à l'étranger : autant d'entités qui peuvent porter des obligations différentes selon ce qu'elles font de l'IA. Le vrai travail n'est pas de cocher une case au siège. C'est de répartir clairement qui est responsable de quoi.

‍

Dans un groupe, l'IA Act ne s'applique pas à l'ensemble comme une entité unique. Chaque société est responsable des systèmes d'IA qu'elle utilise sous sa propre autorité. La maison mère qui développe et fournit un outil à ses filiales endosse, elle, des obligations de fournisseur.

‍

Pourquoi un groupe n'est pas « une seule entreprise » face à l'IA Act

‍

Le point de départ est juridique, et il change tout le reste. Comprendre ce découpage évite de construire une conformité au mauvais niveau.

Chaque entité juridique est un déployeur distinct

Au sens du règlement, le déployeur est l'entité qui utilise un système d'IA sous sa propre autorité. Nous détaillons les rôles et les obligations de base dans notre article sur l'IA Act en entreprise. Ce qui change dans un groupe, c'est que ce statut s'apprécie entité par entité. Dès qu'une filiale fait tourner un outil d'IA pour son activité, recrutement, relation client, analyse de documents, elle en est le déployeur et porte les obligations correspondantes.

Conséquence directe : vous ne pouvez pas déclarer une conformité « groupe » globale. Si trois filiales utilisent le même outil, chacune reste responsable de son usage, de la transparence vis-à-vis de ses utilisateurs et du contrôle humain sur les décisions sensibles. Le siège peut outiller et coordonner. Il ne peut pas se substituer juridiquement à chaque entité.

Le report de décembre 2027 ne suspend pas la cartographie

Un accord européen de mai 2026, le « Digital Omnibus », a repoussé l'application des obligations applicables aux systèmes d'IA à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027 (et au 2 août 2028 pour ceux de l'annexe I). Beaucoup de dirigeants y voient une raison d'attendre.

C'est un mauvais calcul. D'abord parce que les pratiques interdites par l'article 5 du règlement sont, elles, sanctionnées depuis le 2 février 2025, sans report. Ensuite parce que recenser tous les systèmes d'IA d'un groupe, les classer par niveau de risque et identifier le rôle de chaque entité prend plusieurs mois dans une organisation multi-entités. Le délai supplémentaire n'est pas du repos, c'est le temps qu'il vous faut pour faire le travail correctement.

‍

Qui est fournisseur, qui est déployeur dans un groupe

‍

C'est la question qui décide du niveau d'obligations. Et dans un groupe, la réponse n'est pas toujours intuitive.

La maison mère qui diffuse un outil interne devient fournisseur

Le fournisseur est l'entité qui développe un système d'IA, ou le fait développer, et le met sur le marché ou en service sous son propre nom ou sa propre marque. Le règlement précise aussi qu'une entité qui appose son nom ou sa marque sur un système d'IA à haut risque, ou qui lui apporte une modification substantielle, en devient le fournisseur.

Traduisez ça dans un groupe. Si votre siège fait développer un assistant interne, un outil de présélection de candidats ou un moteur d'analyse, puis le diffuse à ses filiales sous la marque maison, il n'est plus un simple déployeur. Il devient fournisseur vis-à-vis de ses propres entités. Et les obligations du fournisseur sont autrement plus lourdes : documentation technique, gestion des risques, traçabilité, conformité démontrable. Beaucoup de groupes basculent dans ce statut sans s'en rendre compte, simplement parce qu'ils ont voulu mutualiser un outil.

Filiale ou maison mère hors Union européenne : le mandataire de l'article 22

Si la maison mère est établie hors de l'Union et fournit un système d'IA à haut risque sur le marché européen, l'article 22 impose de désigner par mandat écrit un mandataire établi dans l'Union. Ce mandataire conserve la documentation, coopère avec les autorités et démontre la conformité.

Pour un groupe international, ce point se règle tôt. Désigner une entité européenne du groupe comme mandataire est souvent la solution la plus simple, à condition qu'elle ait réellement les moyens de tenir ce rôle, pas seulement le titre.

‍

Organiser la conformité entre central et local

‍

Une fois les rôles posés, reste à organiser le travail. L'objectif n'est ni de tout centraliser ni de laisser chaque entité improviser, c'est de combiner les deux. C'est ce qui rend la gouvernance de l'IA en entreprise précisément opérante dans un groupe.

Un registre des systèmes d'IA partagé entre entités

Le socle commun, c'est l'inventaire. Un registre des systèmes d'IA partagé recense, pour chaque entité, les outils utilisés, leur finalité, leur niveau de risque et le rôle de l'entité (fournisseur ou déployeur). C'est ce document qui permet de voir, d'un coup d'œil, où se concentrent les obligations lourdes et quels usages basculent en haut risque.

Tenu au niveau du groupe mais alimenté par chaque entité, ce registre évite deux écueils : la conformité en silos, où personne n'a la vue d'ensemble, et la fausse conformité centrale, qui ignore ce que font vraiment les filiales. Il sert aussi de base à la conformité RGPD, puisque la plupart de ces outils traitent des données personnelles.

Doctrine commune, responsabilité locale

Le siège pose la doctrine : la charte IA en entreprise, la liste des données interdites et les règles de validation des usages sensibles. Chaque entité l'applique sur son périmètre et en répond.

Le bon relais de cette répartition est humain. Un référent IA en entreprise par entité, rattaché à une coordination groupe, fait remonter les usages, applique la doctrine et alerte en cas de dérive. C'est ce maillage qui fait tenir le cadre sur le terrain, plutôt qu'un classeur de procédures que personne n'ouvre.

‍

Pas automatiquement. Chaque filiale reste responsable des systèmes qu'elle déploie. Mais si la maison mère conçoit ou diffuse un outil d'IA sous la marque du groupe, elle devient fournisseur et porte les obligations associées. La conformité se répartit donc entre pilotage central et responsabilité locale.

‍

Répartir les rôles avant de remplir les obligations

‍

Dans un groupe, l'erreur n'est pas de mal remplir une obligation. C'est de l'attribuer à la mauvaise entité, ou de croire qu'une déclaration centrale couvre tout le monde. Le travail commence par la cartographie et la répartition des rôles. Les obligations viennent après, une fois qu'on sait qui porte quoi.

C'est un exercice qui croise le juridique, l'informatique et les métiers, et qui demande de regarder les usages réels, pas ceux qu'on imagine. C'est exactement le type de diagnostic que nous menons lors d'un call de cadrage : faire l'inventaire, clarifier les rôles de chaque entité et poser une feuille de route de mise en conformité adaptée à votre structure.