Plateforme de gouvernance de l’IA : ce que c’est, ce que ça doit faire, et comment départager les offres

Réponse directe. Une plateforme de gouvernance de l’IA est un logiciel qui tient l’inventaire des systèmes d’IA d’une organisation, les classe au regard des obligations applicables, et conserve les preuves datées de ce qui a été décidé et contrôlé. Gartner décrit cette catégorie comme l’ensemble des outils garantissant que les systèmes d’IA respectent les politiques internes, les réglementations et les normes d’IA responsable — définition que nous reprenons telle qu’elle est citée par OneTrust sur sa page de solution, et non d’une publication Gartner que nous aurions consultée.

En pratique, en Europe et en 2026, trois fonctions séparent un outil réellement utile d’un tableau de bord : découvrir les usages, y compris ceux que personne n’a déclarés ; qualifier chaque système au regard du texte applicable ; prouver, à une date donnée, que la qualification a été faite et par qui.

Pourquoi la question se pose maintenant

L’AI Act est applicable par paliers, et deux d’entre eux sont régulièrement confondus. Les obligations des fournisseurs de modèles à usage général s’appliquent depuis le 2 août 2025 ; c’est leur EXÉCUTION par la Commission qui a commencé le 2 août 2026. Les obligations de transparence de l’article 50, elles, s’appliquent depuis le 2 août 2026. Les interdictions de l’article 5 et l’obligation de maîtrise de l’IA de l’article 4 sont en vigueur depuis février 2025. Les systèmes à haut risque de l’annexe III suivent au 2 décembre 2027, ceux de l’annexe I au 2 août 2028.

Ce calendrier a une conséquence simple et peu commentée : l’obligation qui mord d’abord n’est pas une obligation technique, c’est une obligation documentaire. Il faut pouvoir dire quels systèmes d’IA sont utilisés, par qui, pour quoi, et sur quelle base on a conclu qu’ils ne relevaient pas d’une catégorie plus contraignante. Une organisation qui ne sait pas ce qu’elle utilise ne peut pas produire cette démonstration, quelle que soit la qualité de ses intentions.

C’est ce vide que la catégorie occupe. Et c’est pourquoi la première question à poser à un éditeur n’est pas « que savez-vous mesurer », mais « comment savez-vous ce qui est utilisé ».

Les sept critères qui départagent réellement les offres

1. 1.La découverte des usages non déclarés

   Un registre alimenté par formulaire déclaratif reflète ce que les équipes acceptent de déclarer. C’est une limite structurelle, pas un défaut d’adoption : un collaborateur qui a collé un extrait de contrat dans un assistant grand public ne le déclarera pas spontanément.

   Ce qu’il faut demander. Par quel mécanisme technique l’outil détecte un usage qui n’a pas été déclaré. Extension navigateur, journaux de proxy, intégration au fournisseur d’identité, analyse des notes de frais — chaque mécanisme a une couverture et un angle mort différents. Un éditeur qui répond « par la sensibilisation des équipes » répond qu’il ne détecte rien.

   Ce qu’il faut vérifier derrière. Ce que le mécanisme capture exactement. Un dispositif qui lit le contenu des requêtes envoyées aux assistants résout un problème de gouvernance en créant un problème de surveillance des salariés, avec les obligations d’information et de consultation qui vont avec.

2. 2.La qualification au regard du texte, et sa traçabilité

   Classer un système comme « non à haut risque » est une décision juridique. Elle doit pouvoir être rejouée.

   Ce qu’il faut demander. Sur quelle version du texte la qualification s’appuie, ce qui se passe quand le texte change, et si l’outil conserve la qualification antérieure avec sa date. Une plateforme qui recalcule silencieusement les classifications à chaque mise à jour réglementaire détruit la preuve qu’elle est censée produire.

3. 3.La preuve datée, et son opposabilité

   « Opposable » ne veut rien dire en soi. Ce qui compte est la capacité à produire, sur demande d’un auditeur, d’un donneur d’ordre ou d’une autorité, un document qui montre l’état d’une décision à une date passée, avec son auteur.

   Ce qu’il faut demander. Un export d’un état antérieur, pas un export de l’état courant. Et le journal d’audit qui montre qui a modifié quoi.

4. 4.L’articulation avec les régimes voisins

   L’IA n’a pas son propre silo réglementaire. Un système d’IA traitant des données personnelles relève du RGPD. Un système opéré par un fournisseur relève, en finance, du régime des prestataires tiers de services TIC de DORA. Un dispositif de décision individuelle automatisée relève de l’article 22 du RGPD.

   Ce qu’il faut demander. Si l’inventaire sert plusieurs registres ou s’il faut en tenir un par réglementation. La bonne réponse est un référentiel unique avec plusieurs vues ; la mauvaise réponse est trois saisies.

5. 5.La localisation du traitement, et ce qu’elle garantit vraiment

   Un hébergement en France ne rend pas un service souverain. Le critère utile se décompose : où sont stockées les données, où se fait l’inférence, qui opère le support, et quel droit s’applique à l’opérateur.

   Ce qu’il faut demander. La liste des sous-traitants ultérieurs et leur pays d’établissement. Pas la mention « hébergé en Europe » sur la page d’accueil.

6. 6.La réversibilité, testée et pas seulement écrite

   Une plateforme de gouvernance devient le dépôt de la mémoire de conformité d’une organisation. En sortir doit être possible.

   Ce qu’il faut demander. Le format exact de restitution, le délai contractuel, ce qui est restitué et ce qui ne l’est pas — en particulier les journaux d’audit et les pièces jointes — et si une restitution de test a déjà été exécutée chez un client.

7. 7.Le coût réel de maintien

   Le coût d’une plateforme de gouvernance n’est pas son abonnement. C’est le temps humain nécessaire pour que l’inventaire reste vrai six mois après le déploiement.

   Ce qu’il faut demander. Combien de systèmes l’outil a découverts tout seul chez un client comparable, et combien ont dû être saisis à la main.

Ce qu’aucune plateforme de cette catégorie ne fait

Cette section existe parce que son absence sur les pages concurrentes est la première chose qu’un acheteur expérimenté remarque.

• Elle ne rend pas un système conforme. Elle documente son état. La mise en conformité d’un système à haut risque est un travail d’ingénierie et d’organisation, pas un travail de saisie.
• Elle ne remplace pas une analyse juridique sur les cas limites — et les cas limites sont nombreux, en particulier sur la frontière déployeur / fournisseur de l’article 25.
• Elle n’audite pas la sécurité d’un modèle ou d’un agent. L’injection de requête, l’exfiltration par un outil connecté ou la dérive d’un agent autonome relèvent de la sécurité applicative. Une plateforme de gouvernance peut consigner qu’un agent existe et qui en répond ; elle ne teste pas sa robustesse.
• Elle ne garantit aucune citation par les moteurs de réponse, aucune position dans Google, et aucun résultat de contrôle. Si une page vous promet l’un des trois, c’est le signal qu’il faut lire le reste avec attention.

Où SiyadAI se situe dans cette grille

Nous éditons une plateforme de cette catégorie, et la grille ci-dessus est celle sur laquelle nous acceptons d’être jugés.

Ce que la plateforme fait, et qui est vérifiable sur nos pages produit : la découverte des usages par reconnaissance des outils d’IA visités, via une extension Chrome et Edge qui identifie les services utilisés par nom de domaine, sans lire le contenu des requêtes ; un registre des usages à champs structurés, avec classification AI Act et liaison aux analyses d’impact ; des exports de preuve ; un hébergement et un traitement dans l’Union européenne.

Ce que nous ne faisons pas figure dans la section précédente, et ce n’est pas une formule de modestie : si votre besoin principal est l’audit de sécurité d’agents autonomes, la bonne réponse n’est pas notre plateforme.

Le moyen le plus rapide de savoir si cela vous concerne n’est pas une démonstration commerciale, c’est de regarder ce que vos équipes utilisent déjà.