Ces dernières années, les entreprises ont investi massivement dans la collecte d'informations. Elles ont mis en place des solutions CRM, ERP, des plateformes e-commerce, des outils d'analyse, des systèmes de service client et des applications internes. Chaque nouvelle solution promettait une meilleure visibilité sur les opérations, mais créait également une source de données supplémentaire, de nouvelles définitions et de nouvelles intégrations à maintenir.
Il en résulte une contradiction fréquente. L'entreprise possède des millions d'enregistrements, mais les services continuent de se disputer sur le chiffre exact. Le marketing communique un nombre de clients, les ventes un autre, et la finance utilise une troisième définition. Ce même indicateur varie selon le système consulté, la date de collecte des données ou la personne qui a établi le rapport.
Cette fragmentation posait problème lorsque les données étaient principalement utilisées dans des rapports. Avec l'avènement de l'intelligence artificielle et des agents d'entreprise, le risque s'accroît. Un système automatisé ne peut pas interrompre une réunion pour demander quelle définition utiliser. Il traite les informations disponibles et produit une réponse, une recommandation ou une action.
Par conséquent, le défi ne se limite plus au simple stockage des données. Il s'agit de les transformer en ressources fiables, accessibles, compréhensibles et utilisables de manière cohérente. Tel est l'objectif de… produits de données.
Un produit de données est un ensemble d'informations conçu pour répondre à un besoin utilisateur spécifique. Il peut prendre la forme d'un tableau, d'une API, d'un modèle analytique, d'un flux d'événements, d'un tableau de bord ou d'une combinaison de plusieurs composants. Contrairement à un jeu de données traditionnel, il est géré comme un produit, avec des responsabilités, des utilisateurs, une documentation, des critères de qualité et un cycle de vie définis.
Google Cloud décrit l'approche de maillage de données comme un cadre architectural et organisationnel qui considère les données comme des produits développés par les équipes qui maîtrisent le mieux chaque domaine d'activité. Ces équipes doivent respecter des normes de gouvernance communes afin que l'information puisse être découverte et utilisée de manière cohérente au sein de l'organisation.
Prenons l'exemple d'un produit appelé “ Fiche Client 360° ”. Il ne s'agit pas simplement d'un tableau contenant des noms, des adresses e-mail et des achats. Il doit définir ce qui constitue un client actif, les systèmes qui fournissent ces informations, la fréquence de mise à jour, le niveau de qualité offert et les responsabilités en cas d'erreur.
Ce produit ne se contente pas de fournir des données. Il offre la possibilité de prendre des décisions fiables concernant les clients.
Dans de nombreux systèmes d'information, les données apparaissent comme un sous-produit des opérations. Un CRM enregistre les opportunités car il doit gérer les ventes. Un ERP stocke les factures car il doit prendre en charge les processus financiers. Une plateforme de support conserve les conversations pour gérer les dossiers. L'information existe, mais elle n'a pas nécessairement été conçue pour être réutilisée par d'autres services.
Lorsqu'une équipe d'analystes doit combiner ces sources, un processus d'interprétation se met en place. Elle doit déterminer la signification de chaque champ, identifier les enregistrements incomplets, connaître les règles du système et comprendre les liens entre les entités. Une part importante du travail consiste alors non pas à analyser, mais à comprendre.
Ce modèle favorise le recours aux connaissances informelles. Une personne sait qu'une certaine colonne ne doit plus être utilisée après une certaine année. Une autre se souvient que certains enregistrements sont dupliqués. Une troisième connaît la requête permettant d'exclure les tests internes. Lorsque ces personnes changent de rôle, l'organisation perd une partie du sens de ses propres données.
Une approche axée sur le produit exige de rendre ce savoir visible. L'information doit être documentée, testée et mise à jour afin que les autres consommateurs puissent l'utiliser sans avoir constamment besoin de se fier à des échanges informels.
Lorsque les données sont considérées comme des déchets techniques, leur qualité n'est souvent la responsabilité de personne. L'équipe source affirme ne gérer que l'application. L'équipe d'analyse reçoit des informations incomplètes et tente de les corriger. Les services opérationnels utilisent des rapports différents, et les problèmes n'apparaissent qu'à la fin du processus.
Un produit de données nécessite une responsabilité clairement définie. L'équipe en charge doit comprendre le domaine d'activité, identifier les utilisateurs et assurer un niveau de service satisfaisant. Cela ne signifie pas qu'une seule personne doive résoudre tous les problèmes techniques et fonctionnels, mais plutôt que la fiabilité du produit est clairement établie.
Le modèle de maillage de données propose précisément une structure de propriété orientée domaine. Les ventes peuvent être responsables des produits liés aux opportunités et aux clients potentiels. La finance peut gérer les informations relatives à la facturation, aux revenus et aux paiements. Les ressources humaines peuvent gérer les produits liés aux talents et à la structure organisationnelle.
La décentralisation ne supprime pas la gouvernance. Elle en modifie la forme. Les équipes deviennent responsables de leurs données, mais opèrent selon des normes communes qui permettent l'interopérabilité, la sécurité et le contrôle.
L'une des différences les plus importantes entre le stockage de données et la création d'un produit réside dans la compréhension de son public cible. Un produit sans utilisateurs clairement définis risque de devenir un simple amas d'informations inexploitées.
Les utilisateurs peuvent être des analystes, des applications, des dirigeants, des modèles prédictifs ou des agents d'IA. Chacun requiert des fonctionnalités différentes. Un analyste peut avoir besoin d'un historique détaillé et de flexibilité. Un système transactionnel exige des réponses rapides et des contrats stables. Un agent d'IA a besoin d'un contexte compréhensible, d'autorisations claires et de données suffisamment fiables pour étayer sa décision.
Concevoir du point de vue du consommateur implique de se poser des questions précises. Quel problème cherche-t-il à résoudre ? De quel niveau de mises à jour a-t-il besoin ? Quelles sont les conséquences d’une réponse incorrecte ? Quels champs sont essentiels ? Quelles définitions doivent être expliquées ?
Google Cloud recommande que les architectures de maillage de données permettent différents modèles de consommation et que les utilisateurs puissent évaluer si un produit convient à leurs besoins, à la qualité et aux conditions d'accès.
La valeur d'un produit ne réside pas dans le nombre de colonnes qu'il contient, mais dans sa capacité à faciliter une décision ou un processus spécifique.
Un logiciel n'est pas considéré comme terminé simplement parce qu'il fonctionne une fois. Il nécessite une documentation, un support, des indicateurs de performance, un système de gestion des versions et des mécanismes de gestion des modifications. Les produits de données requièrent une rigueur similaire.
Ces produits doivent être facilement repérables afin que les utilisateurs sachent qu'ils existent. Ils doivent comporter une description claire, une mention de propriété visible et des exemples d'utilisation. Ils doivent également être interopérables, c'est-à-dire qu'ils utilisent des normes permettant de les combiner avec d'autres produits sans modifications excessives.
La fiabilité est tout aussi importante. Les consommateurs doivent connaître la fréquence des mises à jour, l'exhaustivité des données, leur disponibilité et leurs éventuelles limitations. Si une source cesse de recevoir des informations pendant deux jours, le produit doit en informer le consommateur avant qu'un rapport ou un agent n'utilise des données incomplètes.
Martin Fowler souligne que la conception de produits de données implique l'automatisation de la gouvernance et la garantie que les équipes indépendantes suivent des pratiques communes permettant l'interopérabilité à grande échelle.
Le produit de données ne doit pas être évalué uniquement sur la base de son existence technique. Il doit être évalué sur la base de son utilité, de sa fiabilité et de l'expérience utilisateur.
L'un des principaux problèmes d'architecture de données survient lorsqu'un système est modifié sans que les utilisateurs en soient informés. Une équipe peut modifier le nom d'une colonne, changer un type de données ou supprimer une valeur jugée superflue. L'application d'origine continue de fonctionner, mais les rapports, les modèles et les automatisations qui reposent sur cette structure commencent à dysfonctionner.
Un contrat de données définit formellement les droits et obligations d'un utilisateur. Il peut inclure le schéma, les champs obligatoires, les types de données, la fréquence de mise à jour, les règles de qualité, le propriétaire et les politiques de compatibilité. Son objectif est d'éviter que les dépendances ne restent cachées.
Virgin Media O2 a expliqué comment elle utilisait les contrats de données comme couche de qualité et d'assurance pour garantir que les ensembles de données publiés étaient fiables, documentés et prêts à être utilisés.
Le contrat ne doit pas nécessairement être un document manuscrit jamais mis à jour. Il peut être exprimé dans des formats lisibles par machine et validé automatiquement au sein des processus. Si une modification enfreint une condition convenue, le système peut bloquer la publication ou alerter les parties concernées avant qu'elle n'affecte les consommateurs.
La confiance ne repose plus uniquement sur les conversations. Elle devient un bien vérifiable.
Toute organisation doit évoluer. De nouveaux domaines émergent, les processus se modifient et les définitions métiers changent. L'objectif d'un contrat de données n'est pas de figer la structure de manière permanente, mais de gérer le changement de façon responsable.
Lorsqu'une modification est compatible, elle peut être mise en œuvre sans impacter les utilisateurs. Si elle enfreint le contrat existant, il convient de la traiter par le biais d'une nouvelle version, d'une période de transition ou d'un préavis. Cela permet aux équipes en charge des utilisateurs d'adapter leurs processus.
Cette approche réduit les défaillances silencieuses. Sans contrats, une colonne peut subsister tout en changeant de signification. Le processus continue de fonctionner et le problème apparaît dans le mauvais rapport. Grâce à des règles sémantiques et de qualité, l'organisation peut détecter les informations qui ne répondent plus aux conditions attendues.
Le contrôle de version améliore également la traçabilité. Une équipe peut ainsi savoir quel modèle une version particulière d'un produit a été utilisée et reconstituer la cause d'un changement de résultat.
La stabilité ne signifie pas l'absence de changement. Elle signifie que le changement survient sans perturber l'écosystème de manière inattendue.
De nombreuses organisations découvrent des problèmes de qualité lorsqu'un cadre remet en question un chiffre ou qu'un client reçoit des informations erronées. Dès lors, une enquête est lancée, pouvant impliquer plusieurs systèmes, des consultations et des équipes. L'entreprise corrige l'incident, mais ne modifie pas toujours le processus qui a permis son apparition.
Les produits de données nécessitent une surveillance continue. Celle-ci peut inclure des validations d'exhaustivité, d'unicité, de cohérence, de mise à jour et de conformité aux règles du domaine. Une table clients ne doit pas accepter d'identifiants dupliqués sans explication. Un produit de facturation doit détecter les valeurs négatives inattendues. Un flux d'inventaire doit générer une alerte en cas d'arrêt de sa mise à jour.
Martin Fowler propose d'utiliser des fonctions d'adaptation ou fonctions de fitness automatiser les règles de gouvernance et vérifier en permanence si les produits répondent aux normes de l'organisation.
La qualité n'est pas une activité finale réalisée par une équipe distincte. Elle doit être intégrée au processus de développement et de déploiement. L'objectif est d'empêcher que des données erronées ne deviennent une dépendance fiable pour d'autres systèmes.
Les modèles génératifs peuvent produire des réponses convaincantes même lorsque les informations disponibles sont incomplètes ou contradictoires. La qualité du contexte est donc primordiale. Un agent connecté à des sources fragmentées n'acquiert pas d'intelligence simplement en utilisant un modèle avancé. Il acquiert surtout un moyen plus rapide de combiner les incohérences.
Microsoft souligne que les agents synthétisent les informations plutôt que de créer les données factuelles dont ils ont besoin. De ce fait, leur précision dépend de la qualité, de l'accessibilité et de la gouvernance des sources sous-jacentes. Des informations fragmentées ou non contrôlées peuvent engendrer des réponses erronées et des risques de sécurité.
Un produit de données fournit un contexte défini. Un commercial peut consulter un produit d'opportunités actives au lieu de se connecter directement à de multiples tables non documentées. Un assistant financier peut utiliser un produit de revenus validé, avec des règles et des responsables connus.
Cela réduit l'ambiguïté et facilite l'évaluation. L'entreprise peut ainsi analyser si l'agent a utilisé le bon produit, quelle version il a consultée et quelles étaient les limites des informations recueillies.
L'IA ne supprime pas le besoin d'architecture de données. Elle le rend beaucoup plus urgent.
Connecter un modèle à toutes les bases de données de l'entreprise peut sembler un moyen rapide de créer un assistant performant. Cependant, cette approche engendre des problèmes de sécurité, de sémantique et de maintenance. L'agent se retrouve confronté à des champs non documentés, des données sensibles et des structures conçues pour des besoins internes qui ne devraient pas être utilisées directement.
La couche produit permet de contrôler les informations mises à disposition. Chaque produit peut exposer uniquement les champs nécessaires, appliquer des politiques de confidentialité et proposer des définitions adaptées aux humains comme aux machines.
Cette séparation protège également les systèmes opérationnels. Au lieu d'exécuter des requêtes imprévisibles sur des applications critiques, les agents utilisent des interfaces contrôlées, des répliques ou des services conçus pour l'analyse et l'IA.
Les architectures modernes pour les agents d'entreprise recommandent un accès sécurisé et contrôlé aux sources structurées et non structurées, notamment lorsque les systèmes doivent fonctionner sur différentes plateformes ou clouds.
L'objectif n'est pas de limiter artificiellement l'IA, mais de lui offrir une surface d'information qu'elle puisse utiliser en toute confiance.
L'un des projets les plus courants consiste à créer une “ source unique de vérité ”. L'organisation rassemble des informations provenant de divers systèmes sur une plateforme centrale et s'attend à ce que les incohérences soient automatiquement résolues. Cependant, la consolidation des données n'élimine pas les différences d'interprétation.
Le service commercial peut considérer comme client toute entreprise présentant une opportunité commerciale. Le service financier, quant à lui, peut ne reconnaître que les organisations ayant déjà reçu une facture. Le service d'assistance peut collaborer avec les utilisateurs finaux même en l'absence de relation contractuelle directe. Aucune de ces définitions n'est nécessairement erronée ; elles reflètent simplement des contextes différents.
Un produit de données doit préciser la définition qu'il utilise et les décisions auxquelles il se rapporte. Plutôt que de prétendre à une vision unique et universelle, l'architecture peut proposer des produits connexes mais sémantiquement clairs.
Cette rigueur est essentielle pour l'IA. Une question comme “ Combien de clients avons-nous ? ” nécessite un contexte. Sans définition précise, l'agent pourrait choisir un chiffre techniquement accessible et le présenter avec une assurance que l'entreprise ne devrait pas lui accorder.
La qualité sémantique est tout aussi importante que la qualité structurelle. Un champ peut être complet et pourtant totalement inutile si personne ne sait ce qu'il signifie.
Le concept de maillage de données a gagné en popularité, mais il a aussi été simplifié à l'excès. Certaines organisations l'interprètent comme consistant simplement à fournir à chaque département sa propre plateforme ou son propre ensemble de tables. Il en résulte parfois une fragmentation encore plus importante.
Le maillage de données repose sur quatre principes : la propriété orientée domaine, les données en tant que produit, une infrastructure en libre-service et une gouvernance fédérée. La décentralisation n’est efficace que si les équipes partagent des normes, des plateformes et des mécanismes d’interopérabilité.
La gouvernance fédérée permet de prendre des décisions au plus près du terrain sans compromettre la cohérence des processus métier. Une équipe peut avoir une meilleure compréhension de la logique commerciale, mais elle doit néanmoins respecter les règles communes en matière de sécurité, d'identification, de documentation et d'accès.
Une infrastructure en libre-service réduit le coût de la mise en conformité avec ces règles. Si chaque domaine doit créer ses propres pipelines, catalogues et contrôles, cette stratégie sera excessivement coûteuse. Une plateforme commune transforme les bonnes pratiques en fonctionnalités réutilisables.
Le maillage de données n'est pas une technologie spécifique. Il s'agit d'un modèle organisationnel et architectural permettant de faire évoluer les responsabilités sans perdre le contrôle.
Un catalogue traditionnel peut afficher des noms techniques, des emplacements et des schémas. Cela facilite la recherche d'informations, mais n'indique pas nécessairement si elles doivent être utilisées. Deux produits peuvent contenir des données similaires, mais offrir des niveaux de qualité ou de mises à jour différents.
Un catalogue de produits doit inclure l'usage prévu, le propriétaire, les consommateurs, la qualité, la provenance, les modalités d'accès et des exemples. Il doit également indiquer si le produit est commercialisé, en développement ou en voie d'être retiré du marché.
La découvrabilité réduit les doublons. Lorsque les équipes ignorent quelles informations existent, elles créent de nouveaux extraits et des versions parallèles des mêmes données. Chaque copie engendre des coûts supplémentaires, des règles différentes et de nouvelles sources d'incohérences.
Pour les agents d'IA, le catalogue peut devenir une couche sémantique leur permettant de sélectionner les sources appropriées. Cependant, cette capacité requiert des métadonnées fiables et contrôlées.
Une organisation ne tire aucun avantage à cataloguer des milliers de tables incompréhensibles. Elle en tire profit lorsqu'un utilisateur ou un système peut rapidement trouver la source appropriée et comprendre les conditions d'utilisation.
Lorsque chaque produit nécessite de longs processus manuels, les équipes cherchent des raccourcis. Elles créent des ensembles de données temporaires qui finissent par devenir permanents, partagent des fichiers en dehors des plateformes officielles ou développent des intégrations qui ne sont consignées dans aucun document.
La gouvernance doit être intégrée aux outils et aux processus. Les classifications sensibles peuvent être appliquées automatiquement. Les contrats peuvent être validés lors de la livraison. Les politiques d'accès peuvent être configurées en fonction des domaines et des responsabilités.
Google Cloud définit la gouvernance des données comme une approche qui couvre l'intégralité du cycle de vie, de l'acquisition et de l'utilisation à l'élimination sécurisée, et souligne que la valeur des informations dépend de leur fiabilité, de leur découvrabilité et de leur gouvernance.
L'automatisation permet de faire le bon choix aussi le plus simple. Les équipes ne devraient pas avoir à effectuer des dizaines d'étapes pour publier un produit basique si la plateforme peut appliquer les normes par défaut.
Une gouvernance efficace n'empêche pas l'utilisation des données. Elle permet une utilisation à grande échelle sans compromettre la sécurité ni la confiance.
Même un produit bien conçu peut se dégrader. Une source peut cesser d'envoyer des enregistrements, une intégration peut commencer à les dupliquer, ou une mise à jour peut modifier une distribution critique. Le système peut continuer à fonctionner techniquement, même si les informations ne sont plus valides pour l'usage prévu.
L'observabilité des données analyse leur comportement, leur volume, leur fraîcheur, leur distribution et leur provenance. Elle permet d'identifier les anomalies avant qu'elles n'affectent les rapports, les modèles ou les agents.
Cela facilite également l'évaluation de l'impact. En cas d'incident sur un produit, la traçabilité de ce dernier permet d'identifier les panneaux, applications et modèles qui en dépendent. Sans cette visibilité, l'entreprise découvre les consommateurs concernés progressivement et de manière réactive.
Pour les systèmes d'IA, cette capacité est fondamentale. Un agent peut continuer à répondre même si sa source de données ne se met plus à jour. L'architecture doit communiquer l'état du produit et, si le risque le justifie, en désactiver temporairement l'utilisation.
La confiance ne devrait pas être binaire. Les consommateurs doivent connaître l'état actuel des informations et décider si elles peuvent être utilisées pour une recommandation, une automatisation ou une décision importante.
Les organisations s'attachent souvent à créer de nouvelles sources de données, mais rares sont celles qui éliminent celles qui ne devraient plus être utilisées. Au fil du temps, des produits dupliqués, des versions abandonnées et des ensembles de données dont les responsables ont rejoint d'autres services font leur apparition.
Chaque produit nécessite un cycle de vie défini. Ce cycle doit comporter des phases de conception, de lancement, d'exploitation, d'évolution et de retrait. Lorsqu'une version n'est plus recommandée, les utilisateurs doivent disposer d'une procédure de migration.
Supprimer la plateforme évite qu'elle ne devienne un catalogue d'options contradictoires. Cela permet également de réduire les coûts de stockage, de support et de gouvernance.
Avant de retirer un produit, l'entreprise doit comprendre ses dépendances. C'est une autre raison pour laquelle la traçabilité et les contrats sont importants. Un ensemble de données apparemment inactif peut alimenter une automatisation mensuelle ou un processus oublié de tous.
La gestion de produits implique de prendre des décisions concernant la continuité. Maintenir l'ensemble des données indéfiniment n'est pas une stratégie de données, mais une accumulation technologique.
La première étape ne devrait pas consister à réorganiser toutes les équipes ni à migrer immédiatement vers une nouvelle plateforme. Il est préférable d'identifier un domaine présentant des problèmes clairs de confiance, de duplication ou d'accès. Les clients, les ventes, les stocks ou la facturation sont souvent de bons candidats car ils génèrent une valeur transversale.
Ensuite, il convient de sélectionner un cas d'utilisation précis. Plutôt que de créer un produit trop généraliste, l'entreprise peut en concevoir un qui réponde à un besoin spécifique. Cela facilite la définition des utilisateurs, du niveau de qualité attendu et des indicateurs de performance.
Ensuite, la propriété, la documentation, un contrat et des contrôles automatisés sont mis en place. Le produit est publié dans un catalogue et son utilisation est suivie. Ces retours permettent d'ajuster la conception avant d'étendre le modèle à d'autres domaines.
Le succès initial ne se mesure pas à la quantité de données centralisées. Il se mesure à la réduction du temps consacré à la recherche d'informations, à la diminution des erreurs et à la réutilisation du produit dans différents processus.
La stratégie doit reposer sur une valeur avérée, et non sur une transformation théorique trop vaste pour être mise en œuvre.
Chez The Cloud Group, nous aidons les organisations à transformer leurs informations fragmentées en une architecture fiable pour l'analyse, l'automatisation et l'intelligence artificielle. Notre travail commence par la compréhension des processus, des systèmes sources et des décisions que l'entreprise doit améliorer.
Nous concevons des produits de données, des intégrations, des contrats, des plateformes cloud et des modèles de gouvernance qui permettent une utilisation cohérente des informations issues des CRM, ERP, applications internes et sources externes. L'objectif n'est pas simplement de transférer les données vers une nouvelle plateforme, mais de préserver leur signification, leur qualité et leur traçabilité.
Nous contribuons également à la préparation des sources pour les agents d'IA et les applications génératives, en établissant des couches d'accès clairement définies, des contrôles de sécurité et des contextes métier. Un agent ne devrait pas avoir à naviguer entre des systèmes contradictoires pour tenter de trouver la vérité. Il a besoin de produits fiables, conçus spécifiquement pour sa fonction.
L'intelligence artificielle peut accélérer les décisions et automatiser les processus, mais elle ne peut pas indéfiniment compenser une architecture de données fragmentée.
Car avant de construire une entreprise pilotée par l'IA, il est nécessaire de construire une entreprise capable de faire confiance à ses propres informations.
Il s'agit d'un ensemble de données conçu et géré pour répondre à un besoin spécifique de ses utilisateurs. Il comprend des informations, de la documentation, les parties responsables, des règles de qualité, des politiques d'accès et un cycle de vie défini.
Un jeu de données est un ensemble d'informations. Un produit de données y ajoute une finalité, une propriété, des normes de qualité, une documentation, un support et des conditions de consommation. Son objectif est de générer une valeur récurrente et fiable.
Il s'agit d'un accord formel entre les producteurs et les utilisateurs d'informations. Il définit les schémas, les champs, les types, la fréquence de mise à jour, les règles de qualité et les conditions de compatibilité. Il peut être validé automatiquement au sein des pipelines.
Ces produits fournissent aux systèmes d'IA des sources d'information fiables, documentées et contrôlées. Cela réduit le risque que les modèles et les agents utilisent des informations incorrectes, obsolètes ou hors contexte.
Il s'agit d'une approche architecturale et organisationnelle qui répartit la responsabilité des données entre les différents domaines d'activité. Elle repose sur une propriété décentralisée, les données en tant que produit, des plateformes en libre-service et une gouvernance fédérée.
Non. Le maillage de données est généralement plus pertinent dans les organisations comportant de multiples domaines, équipes et des défis en matière d'évolutivité. Les petites entreprises peuvent appliquer les principes des produits de données sans pour autant entreprendre une transformation organisationnelle complète.
Il doit exister un responsable clairement identifié au sein du domaine, qui comprenne son importance commerciale. Des ingénieurs de données, des analystes, des spécialistes de la sécurité et des gestionnaires de plateforme peuvent également être impliqués.
À travers des critères tels que l'exhaustivité, l'exactitude, la cohérence, l'originalité, la fraîcheur et la disponibilité, ces indicateurs doivent correspondre aux besoins réels de vos consommateurs.
La modification doit être évaluée au regard de votre contrat. En cas d'incompatibilité, une nouvelle version, un préavis et une période de transition permettant aux consommateurs d'adapter leurs processus peuvent être nécessaires.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
