Pour la gestion documentaire en 2026, il est difficile de trouver une plateforme qui ne promette pas centralisation, automatisation, intégration, sécurité et intelligence artificielle. Le vocabulaire s’est uniformisé. La capacité réelle des solutions, pas toujours.
Une organisation peut comparer des dizaines de fonctionnalités, assister à une démonstration fluide et pourtant choisir une plateforme qui ne reflète pas ses règles, gère mal les exceptions ou crée des dépendances coûteuses. Le problème ne tient pas seulement à ce qui a été demandé au fournisseur, mais surtout à la manière dont les exigences ont été formulées et validées.
Par exemple, « Avez-vous un workflow ? » est une question trop vague. En revanche, « Pouvez-vous appliquer des critères différents au même document selon le contrat, l’activité, le site et le niveau de risque, tout en conservant l’historique de la règle utilisée pour chaque décision ? » permet d’observer une capacité concrète.
C’est le saut que les entreprises doivent faire : passer d’une liste de fonctionnalités à un référentiel d’exigences fondé sur des preuves. La plateforme doit protéger les documents et les décisions, s’adapter à l’activité, communiquer avec d’autres systèmes et utiliser l’automatisation ou l’IA sans transformer la vitesse en perte de contrôle.
Le point de départ : Exiger des résultats vérifiables, pas des étiquettes
Une fonctionnalité n’est qu’une possibilité technique. En revanche, une exigence utile décrit le résultat nécessaire, le contexte dans lequel il doit fonctionner et la preuve qui démontrera qu’il est atteint.
Par exemple, « recherche avancée » peut désigner aussi bien un simple champ de texte qu’une recherche par métadonnées, contenu, entité, statut, validité, contrat et autorisations. De même, « intégration par API » peut renvoyer à une poignée d’opérations ou à une architecture documentée, supervisée et suffisante pour le processus. De la même façon, « IA documentaire » peut être une démonstration préparée ou une capacité mesurable par type de document, langue et niveau de confiance.
Avant de consulter le marché, classez chaque besoin en trois groupes :
- Exigence minimale : sans cette capacité, la plateforme ne protège pas le processus et ne remplit pas l’objectif de l’organisation.
- Capacité dépendante du contexte : elle peut être décisive pour certains secteurs, activités ou profils, mais elle n’est pas universelle.
- Évolution souhaitable : elle crée de la valeur future, à condition qu’il existe un cas d’usage, une gouvernance et une trajectoire d’adoption réaliste.
Cette classification évite deux extrêmes : acheter une solution insuffisante parce que la présentation semble simple, ou acheter une complexité que l’entreprise ne pourra pas exploiter.
Première exigence : Contrôle documentaire tout au long du cycle de vie
Une plateforme de gestion documentaire n’est pas seulement un endroit où les fichiers sont disponibles. Elle doit contrôler la création ou la réception du document, sa classification, sa validation, ses versions, son utilisation, son renouvellement, sa conservation et son sort final selon les règles de l’organisation.
La norme ISO 15489-1 établit des principes pour la création, la capture et la gestion des documents d’archives, quel que soit leur format ou leur environnement technologique. Parmi les éléments pertinents figurent les métadonnées, les responsabilités, les contrôles, la surveillance et la conservation des preuves dans le temps. Ainsi, pour une entreprise, cela se traduit par une question pratique : la plateforme conserve-t-elle seulement le PDF ou aussi le contexte nécessaire pour comprendre ce qu’il prouve ?
Dans une activité avec des prestataires, un document peut être lié à une entreprise, à un intervenant, à un équipement, à un contrat et à un site. En outre, sa validité peut dépendre de dates, de l’activité, de l’organisme émetteur, de la version et de critères locaux. C’est pourquoi une plateforme adaptée doit conserver ces relations sans obliger l’équipe à les reconstruire dans des tableurs.
Ce qu’il faut exiger : des métadonnées structurées, le contrôle des versions, les relations entre entités, des règles de validité et de conservation, une recherche cohérente avec les autorisations et la conservation de l’historique pertinent.
Comment le vérifier : remettre au fournisseur un ensemble de documents liés et lui demander de démontrer la réception, la classification, la modification, le renouvellement, la recherche et l’export, y compris une version remplacée et une exception.
Deuxième exigence : Une traçabilité qui reconstitue la décision
Un journal d’activité indiquant que quelqu’un a « modifié le document » ne suffit pas pour un audit ou pour enquêter sur un incident. L’organisation doit pouvoir répondre : qui a pris la décision, quand, avec quel profil, sur quelle version, selon quelle règle, avec quelles données et quelles actions ont suivi ?
Cette exigence devient plus importante lorsque la plateforme automatise des étapes ou utilise l’IA. Si un document est rejeté, par exemple, il ne suffit pas de connaître le résultat. Il faut distinguer une règle automatique, une recommandation algorithmique, une décision humaine et une modification ultérieure. Il doit également être possible d’identifier les remplacements, les réouvertures, les exceptions et les approbations conditionnelles.
Une bonne traçabilité protège l’organisation et améliore le processus. De plus, elle permet de repérer les critères ambigus, les écarts entre validateurs, les règles qui génèrent des rejets excessifs et les étapes où le travail est bloqué.
Ce qu’il faut exiger : un historique chronologique, l’identité et le profil de l’acteur, la version du document, la règle ou le critère applicable, l’origine des données, les décisions automatiques et humaines, les justifications et la gestion des exceptions.
Comment le vérifier : sélectionner une décision ancienne et demander sa reconstitution complète. Ensuite, modifier une règle et confirmer que le système préserve la distinction entre les décisions prises avant et après le changement.
Troisième exigence : Sécurité, confidentialité et continuité démontrables
« La plateforme est sûre » n’est pas une exigence, mais une affirmation qui doit être décomposée en contrôles, responsabilités et preuves.
Le NIST Cybersecurity Framework 2.0 organise la gestion des risques en six fonctions : Gouverner, Identifier, Protéger, Détecter, Répondre et Rétablir. Cette vision est utile car elle empêche que l’évaluation se limite au contrôle des accès. Une plateforme peut authentifier correctement les utilisateurs et présenter malgré tout des lacunes en matière de détection, de réponse aux incidents, de rétablissement ou de gestion de la chaîne d’approvisionnement.
Lorsqu’il existe des données personnelles, la protection des données dès la conception et par défaut doit être intégrée dès l’architecture et revue en continu. Cela implique de limiter les accès et les traitements au strict nécessaire, de définir des durées, de séparer les profils, de bien connaître les sous-traitants et d’éviter que les données des clients soient réutilisées à d’autres fins sans base légale ni information adéquate.
Ce qu’il faut exiger : un contrôle d’accès par fonction et par contexte, une authentification adaptée au risque, le chiffrement, des journaux protégés, la gestion des vulnérabilités, des sauvegardes, une restauration testée, la réponse aux incidents, la localisation et les flux des données, des sous-traitants identifiés et des mécanismes de protection de la vie privée dès la conception.
Comment le vérifier : demander la documentation technique et contractuelle, les résultats ou synthèses de tests appropriés, les délais de restauration convenus, la matrice des responsabilités et un exercice d’accès. Un utilisateur doit pouvoir voir exactement ce dont il a besoin, sans recevoir d’informations d’une autre entreprise, d’un autre contrat ou d’un autre processus.
Quatrième exigence : Configuration avec autonomie et gouvernance
Les processus documentaires évoluent : de nouveaux champs, types de documents, critères, alertes, langues, profils et circuits d’approbation apparaissent. La question n’est pas de savoir s’il y aura des changements, mais plutôt combien de temps, de coûts et de risques chaque changement introduira.
Une plateforme configurable permet d’adapter les données, les règles et les workflows sans transformer chaque changement en projet de développement. Toutefois, l’autonomie sans gouvernance crée aussi des problèmes. Des modifications faites directement en production, sans tests, approbation ni historique, peuvent compromettre les décisions et les rapports.
La bonne exigence n’est donc pas le « no-code » isolément, mais la capacité de configuration avec des environnements ou des mécanismes de test, des droits d’administration, le contrôle des versions, la documentation et la possibilité de revenir en arrière.
Ce qu’il faut exiger : la configuration des champs, formulaires, règles, alertes, profils, tableaux de bord et flux ; la séparation entre configuration et développement spécifique ; le contrôle des modifications ; les tests ; l’historique ; et la clarté sur ce que l’équipe du client peut gérer.
Comment le vérifier : pendant la démonstration, demander une modification qui n’a pas été préparée. Un bon test consiste à créer une nouvelle exigence documentaire applicable uniquement aux équipements d’une catégorie, sur un site, avec une alerte anticipée et un circuit d’exception. Mesurer qui l’exécute, combien de temps cela prend et quel impact contractuel cela aurait.
Cinquième exigence : Intégration et portabilité pour éviter de nouveaux silos
La gestion documentaire fonctionne rarement de manière isolée. Elle reçoit des données de l’ERP, des ressources humaines, des achats, des systèmes HSE, des annuaires d’identité, des plateformes d’accès et des applications opérationnelles. Elle doit également renvoyer des statuts, des blocages, des dates d’expiration, des preuves et des indicateurs.
Il ne suffit pas de confirmer qu’il existe une API. Il faut savoir quels objets et quelles actions sont disponibles, comment se fait l’authentification, s’il existe des événements ou des notifications, comment les erreurs sont traitées, quelles limites s’appliquent et qui supervise l’intégration.
La portabilité mérite la même attention. Le règlement européen sur les données, applicable depuis septembre 2025, renforce les règles de changement entre services de traitement de données, notamment les dispositions contractuelles, les interfaces ouvertes et l’export des données et des actifs numériques exportables. Son application concrète à chaque service et contrat doit être validée juridiquement, mais la direction est sans équivoque : l’accès et la sortie ne peuvent pas être laissés pour le moment de la migration.
Ce qu’il faut exiger : des API documentées et suffisantes, des mécanismes d’intégration supervisables, un modèle clair de propriété des données, l’export des documents, métadonnées, versions, relations et historiques, des formats exploitables, des conditions de sortie et un accompagnement de la transition.
Comment le vérifier : réaliser une intégration ou une simulation avec des données du processus et un export indépendant. Confirmer non seulement que les fichiers sortent, mais aussi qu’ils conservent la structure, les identifiants, les relations et un contexte suffisant pour être réutilisés.
Sixième exigence : Une expérience adaptée au travail réel
Une plateforme peut techniquement remplir toutes les exigences et échouer parce qu’elle oblige les utilisateurs à contourner l’interface. En gestion documentaire, cette friction se traduit par des dépôts incomplets, des rejets répétés, des appels, des e-mails et des informations enregistrées hors du système.
Les profils ont des besoins différents. Un administrateur configure. Un validateur, lui, compare preuves et critères, tandis qu’un responsable cherche les risques et les priorités. De son côté, un intervenant sur le terrain doit terminer une tâche rapidement sur un appareil mobile. Enfin, un fournisseur externe doit comprendre ce qui manque et comment corriger.
Le design doit réduire l’ambiguïté et l’effort, et non masquer la complexité. En effet, des messages de rejet clairs, des actions cohérentes, une recherche rapide, un contexte visible et des parcours mobiles adaptés sont des capacités opérationnelles, et non des détails esthétiques.
Ce qu’il faut exiger : des parcours par fonction, une utilisation mobile lorsque c’est pertinent, l’accessibilité, un langage et des langues adaptés, des statuts et des messages compréhensibles, une aide contextuelle, une recherche efficace et la réduction des saisies en double.
Comment le vérifier : demander à des utilisateurs représentatifs de réaliser des tâches sans formation préalable approfondie. Mesurer le taux d’achèvement, le temps, les erreurs et les questions. Inclure au moins un prestataire externe et une tâche sur le terrain, s’ils font partie du processus.
Septième exigence : Une automatisation qui traite les exceptions sans masquer les risques
Automatiser un parcours parfait est relativement simple. La qualité de la plateforme se révèle cependant lorsqu’une information manque, qu’une date est incohérente, que des documents se contredisent ou qu’une règle ne s’applique pas au cas.
Une automatisation responsable doit distinguer les cas clairs des situations qui exigent une revue. De plus, elle doit orienter les exceptions vers la bonne personne, en expliquer le motif, empêcher les décisions risquées et préserver la possibilité d’une intervention humaine. Elle doit aussi éviter les boucles silencieuses, les tâches sans responsable et l’excès de notifications.
Ce qu’il faut exiger : des règles transparentes, le traitement des exceptions, des niveaux de service, l’escalade, des alertes pertinentes, la prévention des exécutions en double, la surveillance des échecs, la possibilité d’intervention et l’enregistrement de l’action automatique.
Comment le vérifier : tester un cas normal et plusieurs cas difficiles : document illisible, champ manquant, validité contradictoire, doublon, règle sans correspondance et indisponibilité d’un système intégré. La démonstration doit montrer comment le processus échoue, se rétablit et informe, et pas seulement comment il se déroule quand tout va bien.
Huitième exigence : Une IA utile, mesurable et soumise à la supervision humaine
En 2026, l’IA peut déjà soutenir la classification, l’extraction d’informations, la comparaison avec les exigences, l’identification d’anomalies, la traduction et la préparation des décisions. Cependant, cela ne signifie pas que toutes les entreprises ont besoin de la même IA, ni qu’une réponse générée doit être tenue pour vraie.
Le règlement européen sur l’intelligence artificielle est désormais une référence incontournable dans l’Union européenne, avec une application progressive et des modifications introduites en 2026. Toutefois, la classification et les obligations dépendent du cas d’usage. Indépendamment du cadre juridique précis, des principes comme la supervision humaine, la documentation, la journalisation, la robustesse, la cybersécurité et le contrôle de l’exactitude sont des critères prudents pour tout processus documentaire ayant un impact opérationnel.
Le NIST AI Risk Management Framework souligne la nécessité de mesurer, documenter et suivre la supervision, les erreurs, les réclamations, les remplacements de la recommandation automatique et les exceptions aux politiques. Pour l’acheteur d’une plateforme, cela signifie demander comment l’IA se comporte lorsqu’elle ne sait pas.
Ce qu’il faut exiger : des cas d’usage délimités, des métriques par type de document et par langue, des niveaux de confiance, une explication suffisante pour la revue, une supervision humaine configurable, l’enregistrement des entrées et des résultats, la gestion des erreurs, la protection des données et de la clarté sur l’utilisation éventuelle des données du client pour entraîner ou améliorer des modèles.
Comment le vérifier : utiliser un échantillon représentatif de l’organisation elle-même, y compris des documents de faible qualité, les langues pertinentes et des exceptions. Mesurer l’extraction correcte, les faux positifs, les faux négatifs, l’orientation vers la revue et le temps humain économisé. Ne jamais accepter uniquement l’échantillon préparé par le fournisseur.
Neuvième exigence : Des données opérationnelles qui mènent à l’action
Des tableaux de bord colorés ne garantissent pas une bonne gestion. C’est pourquoi la plateforme doit produire des informations cohérentes, à jour, explicables et liées aux entités et décisions d’origine.
Pour le HSE/EHSQ et la gestion des prestataires, il peut être nécessaire de connaître les documents arrivant à expiration, les causes de rejet, les délais de validation, la charge par équipe, la conformité par contrat, les intervenants bloqués, les équipements en attente ou la concentration des risques. L’indicateur doit permettre d’accéder au cas concret et d’agir.
Il importe également de connaître la qualité des données elles-mêmes. En effet, les champs vides, les doublons, les classifications incohérentes et les intégrations en retard réduisent la confiance et limitent toute automatisation future.
Ce qu’il faut exiger : des indicateurs configurables, des filtres et du détail, une fréquence de mise à jour connue, une traçabilité jusqu’à la source, un export contrôlé, la définition des calculs, des alertes exploitables et des métriques de qualité des données.
Comment le vérifier : soumettre trois questions de gestion et demander d’y répondre en direct. Ensuite, choisir une valeur du tableau de bord et remonter le chemin jusqu’aux documents, règles et décisions qui l’ont produite.
Dixième exigence : Évolution, support et coût total transparents
La sélection ne s’arrête pas à la mise en production. L’organisation doit savoir comment la plateforme sera supportée, mise à jour et adaptée au fil des années.
Le prix initial représente rarement le coût total. Licences, mise en œuvre, configuration, migration, intégrations, stockage, environnements, support, formation, modifications, utilisation de l’IA et sortie peuvent suivre des modèles différents. Le risque augmente lorsque les frontières entre paramétrage, conseil et développement ne sont pas claires.
Une relation technologique durable exige des responsabilités, des niveaux de service, un processus d’escalade, de la transparence sur l’évolution du produit et des conditions pour récupérer les données. Elle exige en outre de distinguer une promesse de feuille de route d’un engagement contractuel.
Ce qu’il faut exiger : un modèle de prix compréhensible, des hypothèses de volume, les coûts des changements courants, le support et les niveaux de service, la politique de mise à jour, la compatibilité, la pérennité du fournisseur, les limites du produit, les conditions de sortie et les responsabilités des deux parties.
Comment le vérifier : calculer des scénarios à trois ou cinq ans avec croissance, nouvelles intégrations, évolution des processus, utilisation accrue et transition éventuelle. Demander que chaque coût incertain soit décrit, et non caché dans une catégorie générique.
Tout ne doit pas être obligatoire pour toutes les entreprises
Une évaluation mature évite de transformer des tendances en exigences universelles. Fonctionnement mobile hors ligne, plusieurs langues, identification automatique, intégration au contrôle d’accès, modules d’inspection, signature électronique ou certains modèles d’IA peuvent être essentiels dans un contexte et sans intérêt dans un autre.
C’est pourquoi chaque exigence doit être liée à un risque, un objectif, un utilisateur ou une décision. Si l’équipe ne peut pas expliquer quel problème elle résout et comment elle mesurera le résultat, elle doit se demander si elle achète une capacité ou seulement une possibilité.
L’inverse est également vrai. Une exigence en apparence spécifique peut être structurante pour l’activité. Par exemple, une entreprise comptant des centaines de prestataires sur plusieurs sites ne doit pas accepter une gestion des règles qui ignore le contrat, l’activité et le lieu. De même, une organisation qui travaille sur le terrain ne doit pas évaluer l’expérience mobile comme un complément décoratif.
Le référentiel doit être exigeant, mais contextuel.
Comment transformer les exigences en une démonstration qui révèle la plateforme
Les démonstrations commerciales ont tendance à montrer le meilleur parcours, avec des données préparées et des utilisateurs expérimentés. Pour réduire cette asymétrie, l’entreprise doit fournir un scénario commun aux fournisseurs.
Utilisez un processus complet de l’organisation
Choisissez un cas présentant du volume, de l’impact et de la diversité : homologation d’un prestataire, documents des intervenants, autorisation d’équipements ou contrôle des dates d’expiration. Incluez des données anonymisées ou synthétiques ayant la même structure que le processus réel.
Incluez une exception difficile
Ajoutez un document illisible, une validité dépendant du contexte, un remplacement de version, un intervenant associé à plusieurs contrats ou une approbation qui exige une justification. C’est précisément dans les exceptions qu’apparaissent les limites du modèle de données et du workflow.
Demandez une modification en direct
Introduisez un champ, une règle, une alerte ou un profil qui ne figurait pas dans le scénario initial. L’objectif n’est pas de surprendre le fournisseur, mais d’observer l’autonomie, la méthode, le temps et la gouvernance de la configuration.
Testez la sortie avant l’entrée
Demandez un export avec documents, métadonnées, relations, versions et historique. La portabilité doit être validée avant la signature, tant que l’entreprise dispose encore d’un pouvoir de négociation.
Observez chaque profil
Incluez l’administrateur, le validateur, le responsable, l’utilisateur mobile et l’entité externe, le cas échéant. N’acceptez pas que l’expérience d’un seul profil représente toute l’activité.
Consignez les preuves et les critères d’acceptation
Pour chaque exigence critique, définissez le résultat attendu, le scénario de test, la preuve, le responsable de la validation et la conséquence d’un non-respect. Un enregistrement autorisé, un rapport de pilote et une matrice des écarts valent mieux que des notes de réunion éparses.
Le contrat doit refléter ce qui a déterminé le choix
Si une capacité a été déterminante, elle ne doit pas disparaître entre la proposition et le contrat. Précisez les intégrations, les volumes, les configurations, les responsabilités, les niveaux de service, la migration, les critères d’acceptation, le traitement des données, l’utilisation de l’IA, le support, les mises à jour et la sortie.
Évitez les formulations où tout dépend d’une « analyse ultérieure ». Certaines incertitudes sont légitimes, surtout en matière d’intégration et de migration, mais elles doivent reposer sur des hypothèses, des limites et un processus de décision.
Il est aussi important d’établir la gouvernance côté client. Qui décide des règles documentaires et qui peut configurer ? À qui revient l’approbation des modifications ? Enfin, qui suit la qualité des données, la sécurité, les accès, la performance de l’IA et l’adoption ? En somme, une bonne plateforme ne remplace pas les responsabilités de l’organisation.
Gestion documentaire en 2026 : Une plateforme qui rend l’entreprise plus apte au changement
Le meilleur critère n’est pas le nombre de modules, mais la capacité à garder le contrôle pendant que l’organisation évolue.
En résumé, une plateforme adaptée protège le document et son contexte, reconstitue les décisions, limite les accès, intègre les données, permet de modifier les processus avec gouvernance, traite les exceptions et offre aux utilisateurs une expérience cohérente. Lorsqu’elle utilise l’IA, elle mesure les résultats, montre l’incertitude et préserve la supervision humaine. Lorsque la relation prend fin, elle restitue des informations exploitables.
GEDOC présente une nouvelle génération de plateforme HSE renforcée par l’intelligence artificielle, entièrement configurable, no-code et prête pour l’intégration. L’offre publiée sur le site couvre la gestion des entreprises, des intervenants, des équipements et des processus, la lecture et l’analyse documentaires, les workflows, les alertes, les tableaux de bord et la supervision humaine aux points critiques.
Pour évaluer si cette approche répond à votre réalité, apportez à la démonstration un vrai processus, une exception difficile et une modification que votre entreprise doit réaliser. La conversation devient plus utile lorsqu’elle passe de « qu’offre la plateforme ? » à « comment prouvez-vous que vous pouvez fonctionner, contrôler et évoluer avec nous ? ».
Pour approfondir : Comment choisir une plateforme de gestion documentaire.
À lire aussi : Sélection des plateformes de gestion documentaire : Processus et critères et Maîtrise des coûts dans la sélection d’une plateforme de gestion documentaire.
Questions fréquentes
Quelles sont les exigences minimales d’une plateforme de gestion documentaire en 2026 ?
Le contrôle des documents et des métadonnées tout au long du cycle de vie, la traçabilité, la sécurité et la confidentialité, la recherche, la gestion des versions, la configuration, l’intégration, la portabilité, une expérience adaptée aux profils, une automatisation qui gère les exceptions, un reporting explicable, le support et des conditions commerciales transparentes. Cependant, l’importance des capacités supplémentaires dépend du processus et du risque.
Une plateforme doit-elle intégrer l’intelligence artificielle pour être considérée comme moderne ?
Pas nécessairement. La modernité doit s’évaluer à l’aune de l’adéquation, de la sécurité, de l’ouverture et de la capacité d’évolution. Lorsque l’IA résout un cas réel, l’entreprise doit exiger des métriques, une supervision humaine, la traçabilité, la protection des données et la gestion des erreurs. Une étiquette IA sans preuve n’apporte aucune valeur.
Comment comparer des plateformes sans s’enfermer dans des listes de fonctionnalités ?
Transformez chaque exigence critique en un scénario, un résultat attendu et une preuve. Utilisez le même processus et les mêmes cas d’exception avec tous les fournisseurs. Incluez une configuration en direct, un export, des parcours par profil et des critères d’acceptation.
Que faut-il tester lors d’une preuve de concept ?
Un processus complet, des données représentatives, des règles contextuelles, des exceptions, les intégrations prioritaires, l’expérience des utilisateurs, la qualité des rapports, la portabilité et, s’il y a de l’IA, l’exactitude et l’orientation vers une revue humaine. La preuve doit mesurer les résultats et l’effort opérationnel.
Comment évaluer une API de gestion documentaire ?
Vérifiez les données et les actions disponibles, la documentation, l’authentification, les limites, les événements, le traitement des erreurs, la supervision, le versionnage et les coûts. Une API sert à soutenir des processus concrets ; sa seule présence ne garantit pas une intégration suffisante.
Quels coûts faut-il inclure dans le coût total de possession ?
Licences, mise en œuvre, configuration, migration, intégrations, stockage, environnements, support, formation, modifications, consommation de services d’IA, croissance des volumes et sortie. Ils doivent être estimés selon des scénarios réalistes, avec des hypothèses documentées.
ISO, ISO 15489-1:2016, Information and documentation, Records management, Part 1: Concepts and principles.
NIST, The NIST Cybersecurity Framework (CSF) 2.0.
European Data Protection Board, Data protection by design and by default.
Union européenne, Règlement (UE) 2023/2854, règlement européen sur les données.
Commission européenne, AI Act, Regulatory framework for AI.
Commission européenne, « AI Omnibus enters into force ».
NIST, AI Risk Management Framework Playbook, Measure.