IA souveraine : la responsabilité reste en interne

13.07.2026

7 min de lecture

Qui intègre un modèle d’IA dans son environnement de production en assume la responsabilité : son comportement, ses risques et sa maintenance. Qu’il s’agisse d’un nouveau modèle allemand issu d’un consortium subventionné ne change rien à l’affaire. Le DSI (CIO) ne peut déléguer cette responsabilité ni à l’origine du modèle ni à sa licence open source. La souveraineté se mesure à la manière dont une organisation en contrôle le déploiement, en en garantit la traçabilité et en en prouve la conformité.

En bref

La gouvernance avant le choix. Les points de contrôle et les responsabilités doivent être définis avant même d’évaluer un modèle.
L’exploitation n’est pas un projet. Un consortium de recherche ne fournit pas de support durable. Qui corrigera le modèle lorsque les financements publics s’arrêteront ?
La souveraineté se prouve. Sans traces d’audit documentées, l’affirmation d’un contrôle effectif ne résiste ni à un audit ni à un contrôle réglementaire.

La gouvernance prime sur le choix du modèle

De nombreuses organisations entament l’évaluation d’un nouveau modèle par ses performances. Pourtant, elles commencent ainsi par la mauvaise extrémité. Il faut d’abord établir ses propres structures de gouvernance. Un modèle consortium, tel que celui récemment présenté par le projet Soofi, émerge de la collaboration entre plusieurs établissements de recherche et entreprises. Le choix de son déploiement ne concerne donc pas uniquement la direction informatique. Il impacte la conformité, le service juridique et, en définitive, le comité de direction.

Le Règlement européen sur l’IA (EU AI Act) impose des obligations de transparence, de classification des risques et de supervision humaine. Ces exigences s’appliquent indépendamment de l’origine du modèle, qu’il provienne d’un projet financé par des fonds publics ou non. Les politiques internes doivent définir les cas d’usage pour lesquels un modèle à maturité commerciale limitée est autorisé à être utilisé. En l’absence de cette définition, des conflits apparaissent ultérieurement lorsque qu’un département métier souhaite exploiter le modèle en production sans base juridique clairement établie.

S’ajoute à cela la question de la responsabilité. Un fournisseur commercial encadre contractuellement les limites de sa responsabilité. Dans le cadre d’un consortium, cette attribution est moins évidente, car la responsabilité est répartie entre plusieurs institutions. Un DSI (Directeur des Systèmes d’Information) doit clarifier dès le départ quels risques l’organisation assume elle-même et ceux qui peuvent être couverts par des contrats.

Une licence ouverte réduit la dépendance. Elle ne l’élimine pas.

Clarifier les responsabilités d’exploitation et d’intégration

L’intégration dans un paysage informatique existant dépasse largement la simple question de la compatibilité technique. Il s’agit de déterminer qui sera responsable de la disponibilité, des correctifs de sécurité et de l’adaptation aux nouvelles réglementations. Un consortium de recherche n’est pas conçu pour assurer un support opérationnel à long terme. Les financements du ministère fédéral de l’Économie (BMWK) et les fonds européens prennent fin à une date fixe. Après quoi, quelqu’un devra reprendre la responsabilité.

En pratique, de nombreuses équipes partent du principe que la licence ouverte leur permet de poursuivre le modèle en interne. Sans ressources dédiées pour l’optimisation fine, les audits de sécurité et la surveillance, cette approche crée rapidement une nouvelle dépendance. Cette fois, elle ne vise pas un fournisseur spécifique, mais la pérennité des institutions impliquées ou la volonté d’une communauté de maintenir le modèle.

L’angle mort

La disponibilité n’est pas le contrôle. Faire fonctionner un modèle dans son propre centre de données ne signifie pas pour autant le maîtriser. Sans surveillance des flux de données, sans contrôle des versions et sans un processus d’escalade défini, la souveraineté reste un concept théorique.

Construire une capacité de gouvernance interne

La souveraineté implique que l’organisation décide elle-même de l’utilisation du modèle, des données qu’il traite et du moment où il doit être ajusté ou remplacé. Pour cela, il faut des rôles et des processus qui portent ces décisions. Souvent, l’expertise se concentre entre les mains de quelques spécialistes en informatique. Le métier connaît les exigences, la direction générale les risques stratégiques. Sans répartition claire des rôles, des lacunes apparaissent précisément entre ces deux niveaux.

Les problèmes structurels se manifestent lorsqu’aucune instance n’est définie pour trancher sur l’utilisation du modèle dans un nouveau cas d’usage. Les problèmes humains surviennent lorsqu’un expert unique tombe malade ou quitte l’entreprise et que personne ne peut reprendre le contrôle. Ces deux aspects doivent être traités simultanément. La construction d’une capacité de gouvernance exige donc deux choses : des droits décisionnels clairement définis et un renforcement ciblé des compétences au sein des équipes qui portent le modèle.

Le projet Soofi vise, quant à lui, un contrôle total sur les données, leur provenance et l’infrastructure. Pour l’utilisateur, cela signifie qu’il doit lui-même vérifier si ce contrôle est effectivement exercé au sein de son organisation. S’approvisionner en modèles auprès d’un consortium sans mettre en place ses propres mécanismes de surveillance des flux de données et des versions du modèle ne fait que déplacer la dépendance vers un autre acteur.

Obligation de preuve et auditabilité dans la pratique

Les services de révision, les autorités de supervision et les clients exigent de plus en plus de savoir comment une organisation exerce effectivement le contrôle sur ses systèmes d’IA. Affirmer qu’un modèle est souverain parce qu’il a été développé en Europe ne suffit pas lors d’un audit. Le directeur des systèmes d’information (DSI) doit pouvoir démontrer quelles données ont été utilisées pour l’entraînement, comment les modifications ont été documentées et quels mécanismes de contrôle sont appliqués en cours d’exécution.

Dans le cas des modèles issus de contextes de recherche, la documentation des données d’entraînement et des procédures est souvent insuffisante pour répondre aux exigences d’un audit. Cette lacune a également été soulignée par la communauté spécialisée dans le rapport Soofi. Pour l’utilisateur, la question reste entière : peut-il vérifier de manière indépendante les informations fournies par le consortium, et quelles conclusions en tirer pour sa propre évaluation des risques ?

Sans preuves tangibles à présenter aux auditeurs internes ou externes, la souveraineté reste une simple assertion. La mise en place de pistes d’audit et la capacité à fournir des informations détaillées sur demande doivent donc figurer dès le départ dans la planification de l’intégration. Dans les secteurs réglementés, où les autorités exigent des preuves concrètes, ce point détermine l’obtention de l’autorisation.

Qu’est-ce que la gouvernance de l’IA ? La gouvernance de l’IA désigne le cadre contraignant composé de droits décisionnels, de critères de risque, d’obligations de documentation et de points de contrôle, qui définit qui décide du choix, du déploiement et du retrait d’un modèle, ainsi que qui en assume la responsabilité en cas de défaillance. Sans ce cadre, l’utilisation n’est ni maîtrisable ni présentable lors d’un audit. Cette exigence s’applique aussi bien aux modèles développés en consortium qu’à ceux proposés par des fournisseurs commerciaux.

La position opposée

L’argument le plus fort en opposition pèse lourd : un modèle financé publiquement, sous licence permissive, issu d’un large consortium européen représente déjà un progrès par rapport aux alternatives propriétaires. Il réduit la dépendance à l’égard de fournisseurs étrangers uniques et ouvre la voie à des adaptations internes. Cet argument reste valable tant que l’alternative offre effectivement moins de contrôle. Il oublie simplement un point : la disponibilité formelle d’un modèle ne garantit pas un contrôle opérationnel au sein de sa propre organisation. C’est précisément ce contrôle que le DSI doit instaurer.

L’impulsion d’action sur 90 jours

Dans les 30 premiers jours, une équipe composée de représentants des services informatique, juridique, conformité et d’un expert métier établit un catalogue de critères. Celui-ci définit les exigences applicables en matière de traçabilité des données, de processus de mise à jour, de voies d’escalade et de preuves au sein de l’organisation. Le CIO (Chief Information Officer) en assure le parrainage, tandis que la direction opérationnelle revient au RSSI (Responsable de la Sécurité des Systèmes d’Information).

Durant les 30 jours suivants, une matrice de dépendances des déploiements d’IA en cours est élaborée. Pour chaque système, elle identifie le propriétaire fonctionnel, le niveau d’escalade en cas d’incident et l’existence ou l’absence de preuves concernant l’origine des données et leur contrôle. Cette matrice révèle les lacunes actuelles, notamment l’absence de désignation de responsables en cas de doute.

Lors des 30 derniers jours, les premières mesures contractuelles et organisationnelles sont définies pour un scénario pilote sélectionné. Cela inclut notamment la clarification des responsabilités en cas de changement de modèle ou de faille de sécurité, avec une capacité d’action garantie sous 48 heures, ainsi que les modalités de preuve de cette réactivité.

Questions fréquentes

Quels sont les risques de responsabilité liés à l’utilisation d’un modèle consortial ?

Dans un modèle issu d’un consortium de recherche, les questions de responsabilité sont généralement moins clairement définies que chez les prestataires commerciaux. L’organisation doit évaluer dans quelle mesure elle engage sa propre responsabilité en cas de dommages liés au comportement du modèle. Les contrats conclus avec les différents partenaires du consortium n’offrent qu’une protection limitée, car la responsabilité est répartie entre plusieurs institutions.

Combien de temps faut-il pour acquérir une capacité de gouvernance interne suffisante ?

Ce processus commence par la définition des rôles et des processus décisionnels, et peut s’étendre, selon la situation de départ, sur plusieurs mois, voire jusqu’à un an. L’intégration technique, elle, est plus rapide. La capacité à évaluer, surveiller et, si nécessaire, remplacer un modèle de manière autonome exige un développement ciblé des compétences et une expérience pratique.

Que signifie la phase bêta fermée pour une utilisation en production ?

Une phase bêta fermée indique que le modèle n’est pas encore libéré pour une utilisation générale et que son architecture, son comportement ainsi que son support peuvent encore évoluer. Les entreprises qui évaluent le modèle à ce stade doivent clarifier quelles garanties sont prévues pour son développement futur et son support après la phase bêta. Sans ces engagements, l’utilisation en production reste associée à un niveau d’incertitude élevé.

Autres articles du réseau MBF Media