L’essentiel
- L’Omnibus numérique a reporté au 2 décembre 2027 les obligations relatives aux systèmes à haut risque autonomes, mais la littératie en IA, les pratiques interdites, la transparence et les devoirs applicables aux modèles à usage général sont déjà exigibles.
- La plupart des défis de la gouvernance de l’IA relèvent de l’organisation et non de la technique : responsabilité non attribuée, inventaire incomplet, preuves introuvables au moment où on les demande.
- 78 % des dirigeants ne se disent pas confiants dans leur capacité à passer un audit indépendant de gouvernance de l’IA en 90 jours.
- La responsabilité se dilue parce que les obligations se répartissent entre fournisseur du modèle, fournisseur du système et déployeur, sans que personne ne consigne qui porte quoi.
- Chacun des sept blocages ci-dessous se referme sur une obligation nommée, un contrôle et un artefact qu’un auditeur réclamera.
Ce qui a changé en 2026 : l’échéance a bougé, pas les obligations
Le plus lourd des défis de la gouvernance de l’IA en ce moment tient à un calendrier que la plupart des publications n’ont pas encore intégré. Le règlement (UE) 2026/1744, dit Omnibus numérique sur l’IA, a été publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet 2026, neuf jours avant l’échéance initiale. Le Parlement européen l’avait adopté le 16 juin 2026 par 423 voix contre 57 et 174 abstentions, le Conseil ayant donné son approbation définitive le 29 juin 2026. Ce qui a bougé : les obligations applicables aux systèmes à haut risque autonomes de l’annexe III s’appliquent désormais à partir du 2 décembre 2027, et celles visant l’IA intégrée aux produits réglementés de l’annexe I à partir du 2 août 2028. Ce qui n’a pas bougé : l’interdiction des pratiques inacceptables, applicable depuis le 2 février 2025. Le devoir de littératie en IA de l’article 4, applicable à la même date. Les obligations relatives aux modèles à usage général du chapitre V, applicables depuis le 2 août 2025. Les devoirs de transparence de l’article 50. Cette asymétrie constitue le premier piège. En comité budgétaire, un report de seize mois se lit comme une autorisation de mettre le programme en veille. Il n’en est rien. Les obligations qui mordent aujourd’hui sont justement celles qui exigent un modèle opérationnel plutôt qu’une modification produit, et ce sont celles que la plupart des organisations n’ont pas commencées. Notre cadre réglementaire de l’IA détaille la cartographie complète des obligations par rôle et par date.
Blocage 1 : personne ne porte la gouvernance
Demandez qui est responsable et vous obtiendrez un comité, pas un nom. L’enquête Grant Thornton 2026, menée auprès de 950 dirigeants, montre que seuls 48 % des conseils ont formulé des attentes en matière de gouvernance de l’IA et que 46 % ont intégré le risque IA à leur supervision courante, alors même que 73 % des dirigeants désignent la gouvernance comme le chantier prioritaire. L’enquête annuelle Kiteworks 2026, conduite auprès de 459 professionnels de la sécurité et de la conformité, est plus directe encore : 39 % traitent la gouvernance de l’IA comme une mission annexe plutôt que comme une fonction dédiée. Un comité ne peut pas être tenu pour responsable. Il peut seulement être réuni. Le jour où survient un incident, l’autorité demande qui a autorisé la mise en service, et une charte de comité de pilotage ne constitue pas une réponse. Le contrôle : un responsable nommé par système, une instance de décision dotée du pouvoir documenté de suspendre un déploiement, et une matrice de responsabilités qui survit à un changement de personne. Ce responsable n’a pas besoin d’être technicien. Il lui faut l’autorité de dire non et le budget pour en tirer les conséquences. C’est la pièce porteuse de tout cadre de gouvernance de l’IA, et le moins coûteux des sept correctifs. L’artefact : une décision d’autorisation signée par système, nommant le responsable et datant l’approbation.
Blocage 2 : on n’inventorie pas ce qu’on ne voit pas
Toute obligation du règlement IA s’accroche à un système. Faute de pouvoir énumérer vos systèmes, aucun autre contrôle ne s’applique, puisqu’il n’a rien sur quoi se poser. Cette dépendance place l’inventaire à la racine de la plupart des défis de la gouvernance de l’IA. L’ampleur de l’écart est désormais mesurée. Kiteworks relève que 65 % des organisations ont découvert un usage d’IA fantôme au cours de l’année écoulée. Une enquête Gartner menée auprès de 302 responsables cybersécurité entre mars et mai 2025 établit que 69 % soupçonnent ou constatent que des salariés utilisent des outils d’IA générative publics pourtant interdits. Presque aucun de ces outils n’a été soumis à un examen de gouvernance. La difficulté est structurelle. L’IA arrive incorporée à des logiciels déjà achetés, via des API tierces, et par des achats individuels qui ne passent jamais devant un service achats. Les systèmes agentiques aggravent le phénomène : un agent qui appelle d’autres modèles et agit à travers plusieurs applications n’a aucun point d’enregistrement unique. Notre article sur l’IA fantôme détaille les techniques de découverte. Le contrôle : une découverte continue associée à un registre indexé par cas d’usage, propriétaire métier, rôle réglementaire, classification de risque et étape du cycle de vie. Les données d’achat et de notes de frais constituent une meilleure source initiale qu’un scan réseau, car l’IA fantôme s’achète plus qu’elle ne s’installe. L’artefact : un export daté de l’inventaire, transmissible sans retouche.
Blocage 3 : la responsabilité se fragmente le long de la chaîne de valeur
Voici le mécanisme qui produit le blocage 1, et celui que presque aucune publication n’aborde. Les obligations ne reposent pas sur une seule entreprise. Elles se répartissent entre le fournisseur du modèle à usage général, le fournisseur du système qui bâtit dessus, et le déployeur qui l’exploite dans un contexte précis. The Future Society nomme cela le problème des mains multiples : la responsabilité s’efface précisément parce que ces trois acteurs diffèrent en ressources, en expertise et en information contextuelle, et qu’aucun n’en détient assez pour s’acquitter seul du devoir. Le règlement est explicite sur l’attribution des rôles. L’article 3, point 4 définit le déployeur comme la personne physique ou morale utilisant un système d’IA sous sa propre autorité, hors activité personnelle à caractère non professionnel. L’article 2, paragraphe 1, point a) vise les fournisseurs qui mettent des systèmes sur le marché de l’Union quel que soit leur lieu d’établissement, et le point b) les déployeurs établis ou situés dans l’Union. L’article 25 bascule ensuite un déployeur en fournisseur dès lors qu’il appose son nom ou sa marque sur un système à haut risque, ou qu’il le modifie substantiellement. C’est sur ce dernier point que les organisations se font prendre. Affiner un modèle, changer sa destination ou l’habiller de sa propre marque peut vous faire passer de déployeur à fournisseur, avec un jeu d’obligations nettement plus lourd. Les équipes qui bâtissent sur des modèles d’IA franchissent souvent cette ligne sans le consigner. Le contrôle : une qualification écrite du rôle par système, refaite à chaque modification substantielle, avec une répartition contractuelle des devoirs en amont plutôt qu’une hypothèse implicite. L’artefact : la fiche de qualification du rôle, motivée et datée.
Blocage 4 : le contrôle humain se conçoit, il ne se déclare pas
La plupart des programmes revendiquent un humain dans la boucle. Peu savent décrire ce que cette personne peut réellement faire, ce qui range la supervision parmi les défis de la gouvernance de l’IA qui n’apparaissent qu’au moment de l’audit. Le règlement ne se contente pas de la déclaration. L’article 14, paragraphe 1 exige que les systèmes à haut risque soient conçus et développés de manière à pouvoir être « effectivement contrôlés par des personnes physiques » pendant leur période d’utilisation, y compris au moyen d’interfaces homme-machine appropriées. Le mot qui compte est « effectivement ». Le paragraphe 3 scinde ensuite le devoir : les mesures de supervision sont soit intégrées au système par le fournisseur avant sa mise sur le marché, soit identifiées par le fournisseur et mises en œuvre par le déployeur. Les programmes retiennent systématiquement la première branche et n’exécutent jamais la seconde. Le fournisseur livre un bouton d’arrêt, le déployeur n’attribue à personne l’autorité de l’actionner, et la supervision n’existe que sur le schéma d’architecture. La distinction entre humain dans la boucle et humain sur la boucle compte ici, car les deux emportent des exigences de compétence et d’effectifs différentes. Le contrôle : une fiche de conception de la supervision nommant le rôle, la compétence exigée, l’autorité de passer outre ou d’arrêter, le délai dans lequel la personne doit pouvoir agir, et le journal qui enregistre chaque intervention. L’artefact : des journaux d’intervention montrant que la reprise en main a servi au moins une fois, ou l’explication documentée de son absence d’usage.
Blocage 5 : la littératie en IA est déjà une obligation
De tous les défis de la gouvernance de l’IA, celui-ci est le plus souvent renvoyé à l’année suivante. À tort. L’article 4 s’applique depuis le 2 février 2025 et l’Omnibus numérique n’y a pas touché. Le texte est bref et son périmètre large. Fournisseurs et déployeurs « prennent des mesures pour garantir, dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA de leur personnel et des autres personnes s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte », en tenant compte de leurs connaissances techniques, de leur expérience, de leur formation, du contexte d’utilisation et des personnes sur lesquelles les systèmes sont employés. L’article 3, point 56 définit cette maîtrise comme les compétences, connaissances et compréhension permettant un déploiement éclairé et une conscience des risques. Observez ce que le texte ne dit pas. Il ne vise pas seulement les systèmes à haut risque, ni les seuls profils techniques. Il atteint quiconque exploite ou utilise de l’IA pour votre compte, prestataires compris. Les budgets ne suivent pas. Grant Thornton relève que 34 % des directions financières jugent la formation insuffisamment financée, et que les collaborateurs de terrain (37 %) et l’encadrement intermédiaire (30 %) sont les populations les plus demandeuses, précisément celles que l’article couvre. Le contrôle : une formation par rôle, cartographiée sur les systèmes que chaque rôle manipule réellement, actualisée lorsque le système change plutôt qu’une fois l’an. L’artefact : des relevés de présence et d’acquisition rattachés à des personnes nommées et à des systèmes nommés.
Blocage 6 : la preuve est introuvable
Une organisation peut détenir tous les contrôles et échouer à un audit, car détenir un contrôle et le prouver sont deux exercices distincts. La restitution de la preuve est le moins discuté des sept défis de la gouvernance de l’IA, et le plus susceptible d’être éprouvé en premier. Les chiffres 2026 sont sévères. 78 % des dirigeants ne se disent pas confiants dans leur capacité à passer un audit indépendant de gouvernance de l’IA sous 90 jours. La moitié des organisations interrogées par Kiteworks ne peuvent pas produire un relevé complet des accès à l’IA dans un jour ouvré. Seules 33 % tiennent des pistes d’audit infalsifiables, et 63 % ont subi des conséquences de conformité liées à des lacunes de gouvernance sur douze mois. Un schéma voisin mérite d’être nommé : 61 % placent la souveraineté des données en tête de leurs enjeux de conformité, mais 29 % seulement l’imposent par un mécanisme technique. Une politique déclarée sans point d’application ne produit aucune preuve. Le délai de restitution est la mesure qui compte. Une preuve qui demande trois semaines d’assemblage est, du point de vue d’une demande de l’autorité, une preuve que vous n’avez pas. Nos guides sur l’audit de l’IA et la documentation des systèmes d’IA détaillent ce que réclament effectivement les autorités de surveillance du marché, la CNIL et l’ANSSI intervenant en France selon les usages concernés. Le contrôle : rattacher chaque preuve au contrôle précis qu’elle démontre au moment où elle est produite, et figer des instantanés de configuration à chaque modification d’un paramètre significatif. L’artefact : un registre contrôle-preuve assorti d’un délai de restitution mesuré.
Blocage 7 : la gouvernance avance moins vite que les usages
Le dernier des sept blocages est celui qui, en silence, engendre les six autres. Quand le parcours de gouvernance prend huit semaines et que le métier attend une réponse en cinq jours, les équipes contournent, et chaque contournement devient l’IA fantôme de demain. Le coût n’a rien de théorique. Grant Thornton établit que 46 % des organisations citent les défaillances de gouvernance et de conformité parmi les causes principales de sous-performance ou d’échec de l’IA, devant la formation insuffisante (31 %) et la maturité insuffisante des données (23 %). La friction de gouvernance est le premier contributeur nommé à l’échec des projets. La réponse habituelle, ajouter des relecteurs, aggrave le problème. Le correctif tient dans la proportionnalité. Le contrôle : un guichet d’entrée à plusieurs niveaux, où un cas d’usage à faible risque documenté est tranché en quelques jours contre un socle réduit, et où seuls les systèmes franchissant un seuil de classification entrent en évaluation complète. Associez-y une bibliothèque de contrôles réutilisables pour que le dixième système hérite du travail fait sur le premier. Notre guide du risque lié à l’IA explique comment calibrer ces niveaux. L’artefact : le délai entre dépôt et décision, suivi par niveau et publié aux côtés des indicateurs de conformité.
Traiter les défis de la gouvernance de l’IA en 90 jours
Vouloir tout mener de front est la façon la plus sûre d’enliser un programme. Les dépendances vont dans un seul sens. Jours 1 à 30. Voir. Construisez l’inventaire et qualifiez les rôles des systèmes déjà en production. Rien en aval n’est possible sans ces deux briques, et l’essentiel se fait sur pièces, à partir des données d’achat et de notes de frais. Jours 31 à 60. Assumer. Nommez un responsable par système, installez l’instance de décision avec pouvoir d’arrêt, et refermez les deux obligations déjà exigibles : la formation à l’IA des rôles concernés, et les fiches de conception de la supervision pour tout système qui décide ou oriente une décision touchant une personne. Jours 61 à 90. Prouver. Reliez les contrôles aux preuves, mesurez le délai de restitution face à une cible d’un jour ouvré, puis répétez un audit à blanc sur vos trois systèmes les plus exposés. Calibrez ensuite les niveaux du guichet d’entrée à partir de ce que la répétition vous aura appris. Les référentiels servent à ce stade, pas au départ. ISO/IEC 42001 donne la forme du système de management et le NIST AI RMF le vocabulaire du risque, mais aucun ne remplace le fait de savoir ce que vous exploitez et qui en répond.
Questions fréquentes
Quel est le principal défi de la gouvernance de l’IA ? La responsabilité non attribuée. La plupart des organisations disposent d’un comité de pilotage mais d’aucune personne nommément responsable d’un système donné, si bien que nul ne détient l’autorité d’arrêter un déploiement. L’enquête Grant Thornton 2026 montre que 48 % seulement des conseils ont formulé des attentes en la matière. Un comité se réunit, il ne répond pas. L’échéance du règlement IA pour le haut risque a-t-elle vraiment été repoussée ? Oui. Le règlement (UE) 2026/1744, dit Omnibus numérique sur l’IA, est entré en vigueur le 27 juillet 2026 et a reporté au 2 décembre 2027 les obligations visant les systèmes à haut risque autonomes de l’annexe III, et au 2 août 2028 celles portant sur l’IA intégrée aux produits de l’annexe I. Les pratiques interdites, la littératie en IA de l’article 4, les devoirs relatifs aux modèles à usage général et la transparence de l’article 50 n’ont pas été reportés. Par quels défis de la gouvernance de l’IA faut-il commencer ? Par l’inventaire puis la responsabilité, dans cet ordre, car les cinq autres en dépendent. On n’attribue pas de responsable à un système non recensé, on ne qualifie pas un rôle réglementaire sans responsable pour trancher, et on ne produit pas de preuve pour un contrôle jamais assigné. Les biais et l’explicabilité comptent, mais ce sont des problèmes situés en aval. Qui est responsable, le fournisseur ou le déployeur ? Les deux, avec des devoirs distincts. Le fournisseur porte les obligations de conception, dont l’intégration des capacités de supervision et la fourniture de la notice d’utilisation. Le déployeur porte les devoirs d’exploitation. L’article 25 fait basculer un déployeur en fournisseur s’il appose sa marque sur un système à haut risque ou le modifie substantiellement, ce qu’un simple affinage peut déclencher. Comment bâtir un inventaire quand personne ne déclare ses outils ? Partez de la dépense plutôt que du réseau. Les données d’achat, les notes de frais et les abonnements SaaS révèlent davantage d’IA fantôme qu’un scan, car elle s’achète plus qu’elle ne s’installe. Croisez avec les journaux d’identité et de passerelle, puis conditionnez le maintien de l’accès à l’enregistrement. Kiteworks relève 65 % de découvertes sur douze mois : postulez l’écart plutôt que de le tester. La formation à l’IA est-elle réellement obligatoire ? Oui, au titre de l’article 4 du règlement IA, applicable depuis le 2 février 2025. Elle vise fournisseurs et déployeurs, ne se limite pas aux systèmes à haut risque, et couvre le personnel comme toute personne exploitant de l’IA pour votre compte, prestataires inclus. La mesure est proportionnée au rôle, aux connaissances techniques et au contexte : un module en ligne annuel et uniforme y satisfera difficilement.
Conclusion
Les défis de la gouvernance de l’IA qui enlisent les programmes en 2026 ne sont pas ceux dont le marché parle. Ce ne sont ni la précision des modèles ni les biais algorithmiques pris dans l’abstrait. Ce sont une décision sans titulaire, un système non recensé, un rôle non qualifié, une supervision que personne ne peut exercer, une obligation de formation déjà en vigueur, une preuve qui met trois semaines à s’assembler, et un processus assez lent pour que le métier l’évite. Chacun appelle un contrôle, et chaque contrôle un artefact. L’Omnibus numérique a offert seize mois sur le haut risque, et rien du tout sur ce qui s’applique déjà. Traiter cette fenêtre comme un temps de préparation plutôt que comme une pause fait toute la différence. Commencez par ce que vous exploitez et par qui en répond, puis construisez la chaîne de preuve de la conformité IA à partir de là.