Comment mettre en œuvre la Data Governance : une feuille de route pour les entreprises d'ici 2026

Vos tableaux de bord ne concordent pas. La finance affiche un chiffre d'affaires, les opérations un autre, et l'équipe qui entraîne un modèle ne peut pas expliquer pourquoi les prédictions ont changé après la mise à jour du pipeline de la semaine dernière. Pendant ce temps, le service juridique souhaite des contrôles plus stricts, l'ingénierie veut moins de tickets, et la direction attend des preuves que la gouvernance ne deviendra pas un énième comité sans résultats.

C'est le moment précis où les organisations commencent souvent à se demander comment mettre en œuvre la Data Governance. Non pas comme un exercice théorique. Mais comme un moyen de stopper les crises de données récurrentes sans ralentir la livraison au pas de course.

La réponse pratique est que la gouvernance ne fonctionne que lorsqu'elle associe une propriété claire, des règles exécutoires et un suivi opérationnel au sein des pipelines réels. Un document de politique générale a son importance. Mais si personne ne valide les enregistrements, ne surveille la ponctualité, ne suit les modifications de schéma ou ne détecte les dérives avant qu'elles n'atteignent les rapports et les modèles, ce document ne vous sauvera pas.

Table des matières

• Pourquoi la Data Governance n'est plus facultative

  • Le coût réel se manifeste dans les opérations

• Poser les bases d'une gouvernance réussie

  • Commencer par un problème métier, pas par un framework

  • Définir le périmètre du premier domaine de manière étroite

  • Obtenir le soutien de la direction en langage métier

• Établir votre équipe et votre modèle de gouvernance

  • Associer des personnes désignées aux jeux de données critiques

  • Rôles et responsabilités en matière de Data Governance

  • Choisir un modèle adapté au fonctionnement réel de votre entreprise

• Des politiques statiques aux workflows de qualité automatisés

  • Pourquoi les documents de politique générale échouent s'ils sont seuls

  • À quoi ressemble l'application opérationnelle

  • Rendre la gouvernance prête pour l'IA

• Choisir votre architecture et lancer un projet pilote

  • Choisir l'architecture en fonction du contrôle et du mouvement des données

  • Concevoir un projet pilote qui suscite la confiance

• Faire évoluer la surveillance et pérenniser votre programme

  • Déployer par domaine, pas par décret

  • Traiter les audits et la communication comme un travail opérationnel

Pourquoi la Data Governance n'est plus facultative

La plupart des organisations n'adoptent pas la gouvernance parce qu'elles aiment les frameworks. Elles l'adoptent après des mois de travail de réconciliation, de perte de confiance dans les rapports ou d'un examen douloureux de Compliance. À ce stade, le problème sous-jacent est évident. Les données constituent déjà une infrastructure métier, mais elles sont gérées comme une tâche secondaire.

L'enjeu financier est difficile à ignorer. Le coût moyen d'une mauvaise qualité des données s'élève à 12,9 millions de dollars par an et par entreprise, et Gartner prévoit que 80 % des initiatives de Data Governance échoueront d'ici 2027 sans un vecteur de crise, c'est pourquoi une valeur précoce et visible est si importante, comme le résume le rapport de Profisee sur les conclusions de Gartner en matière de gouvernance.

Voilà également pourquoi une définition générique de la gouvernance ne suffit pas. Si vous faites face à des rapports contradictoires, à un manque de clarté sur la propriété des données, à des entrées d'IA peu fiables ou à des réponses d'audit tardives, vous n'avez pas besoin d'un énième exercice basé sur un glossaire. Vous avez besoin de contrôles qui modifient les opérations quotidiennes. Pour une introduction utile à cette discipline clé, consultez cet aperçu de ce qu'est la Data Governance, mais c'est sur la mise en œuvre que les équipes gagnent ou perdent généralement.

Le coût réel se manifeste dans les opérations

Une mauvaise gouvernance apparaît rarement sous la forme d'un incident dramatique unique. Elle se manifeste plutôt comme un frein opérationnel répété :

• Les analystes revérifient les chiffres : les équipes perdent du temps à réconcilier les rapports au lieu de répondre aux questions stratégiques.

• Les ingénieurs corrigent les anomalies liées aux mauvaises entrées : les corrections de pipelines deviennent routinières parce que les changements de schéma et les chargements tardifs ne sont pas détectés à temps.

• Les équipes de Compliance et de sécurité cherchent des preuves : la préparation des audits se transforme en une recherche manuelle à travers les outils, les feuilles de calcul et les boîtes de réception.

• Les équipes d'IA perdent confiance dans les données d'entrée des modèles : la dérive, les caractéristiques obsolètes et les transformations non documentées rompent la confiance bien avant qu'un modèle ne défaille complètement.

La gouvernance devient urgente lorsque les dirigeants se rendent compte qu'ils ne débattent pas de stratégie, mais de la source de données à laquelle faire confiance.

Dans les environnements réglementés, la gouvernance croise également la gestion des dossiers, la conservation, la confidentialité et le contrôle des accès. Si votre infrastructure comprend Microsoft 365, ce guide sur la conformité au RGPD avec Microsoft 365 est utile car il montre comment les décisions de gouvernance affectent les outils opérationnels, et pas seulement la rédaction des politiques.

Poser les bases d'une gouvernance réussie

Un démarrage fragile ressemble toujours à la même chose. L'entreprise forme un groupe de travail, rédige de grands principes généraux et tente de tout gouverner en même temps. Six mois plus tard, personne n'est capable d'identifier un seul processus qui a été simplifié.

Un bon démarrage est plus ciblé et plus rigoureux.

Commencer par un problème métier, pas par un framework

La première décision à prendre ne concerne pas DAMA, DCAM ou votre modèle de politique. C'est de savoir quel problème vous allez éliminer en premier. La gouvernance fonctionne lorsqu'elle est liée à un résultat métier qui intéresse déjà les collaborateurs.

Les bonnes cibles de départ présentent généralement trois caractéristiques :

• Leur défaillance est coûteuse : tableaux de bord de direction, rapports financiers, dossiers réglementés, données de référence clients ou tables d'entrée des modèles.

• Elles dépassent les frontières d'une seule équipe : une seule équipe ne peut pas résoudre le problème seule.

• Elles peuvent être mesurées : anomalies dans les rapports, retards de chargement, questions de propriété en suspens, écarts de preuves lors d'audits ou échecs récurrents de validation.

Les retombées économiques globales sont bien réelles. En effet, des données bien gouvernées dans les secteurs public et privé peuvent générer des avantages sociaux et économiques équivalents à 1 % à 2,5 % du PIB, d'après le résumé de Snowflake sur les conclusions de l'OCDE en matière de gouvernance. Cependant, on n'obtient pas le soutien de la direction avec un simple argument macroéconomique. Vous l'obtiendrez en démontrant comment un domaine gouverné réduit les frictions opérationnelles dès ce trimestre.

Définir le périmètre du premier domaine de manière étroite

Votre premier déploiement doit être suffisamment restreint pour être bien exécuté et suffisamment important pour avoir de l'impact. Cela signifie généralement un domaine, un sponsor, un groupe de propriétaires et une liste restreinte de contrôles.

Commencez par définir :

1. Le domaine de données
   Sélectionnez les clients, les finances, les produits, les sinistres, les patients ou un autre domaine à fort impact. Ne commencez pas par « toutes les données de l'entreprise ».

2. L'événement métier à protéger
   Clôture mensuelle. Reporting réglementaire. Intégration des clients. Scoring de modèles. Tableau de bord des KPI de la direction.

3. L'ensemble minimal de contrôles
   Propriété, définitions standardisées, règles d'accès, logique de conservation, contrôles de qualité, visibilité sur le lignage (lineage) et remontée des incidents.

4. Les indicateurs de réussite que vous utiliserez
   Moins de désaccords sur les indicateurs métriques, tri plus rapide des incidents, meilleures preuves d'audit, moins d'actifs en aval défectueux ou confiance accrue dans les données d'entrée des modèles.

Règle pratique : Si le périmètre ne tient pas sur une seule page, c'est qu'il est trop large pour un premier déploiement.

La standardisation fait également partie des fondations. Les équipes ont besoin de définitions partagées, de nomenclatures cohérentes et de décisions claires quant aux systèmes de référence. Dans les domaines disposant de conventions établies, les normes sémantiques réduisent les ambiguïtés évitables. Les équipes de santé s'appuient souvent sur des normes telles que HL7 et LOINC précisément pour cette raison.

Obtenir le soutien de la direction en langage métier

Les dirigeants ne financent pas la gouvernance pour le simple plaisir d'avoir des métadonnées plus propres. Ils la financent lorsqu'ils constatent une réduction des risques opérationnels, une prise de décision plus rapide, une meilleure posture d'audit et des analyses ou de l'IA plus fiables.

Cela signifie que votre dossier de présentation initial doit éviter les termes abstraits comme « améliorer la qualité des données ». Utilisez plutôt des formulations directes :

• Réduire les divergences d'indicateurs entre les tableaux de bord

• Sécuriser le traitement des données réglementées

• Raccourcir le temps de résolution des incidents

• Stabiliser la fiabilité des entrées des modèles

• Clarifier qui valide les accès et les exceptions aux politiques

Les meilleurs sponsors sont généralement les dirigeants qui subissent déjà les coûts des problèmes de données. Un directeur financier confronté à des travaux de réconciliation répétés, un directeur des opérations gérant des KPI erronés, ou un chief data officer cherchant à soutenir l'IA en toute sécurité comprendront l'intérêt de la démarche bien plus vite qu'un public purement technique.

Établir votre équipe et votre modèle de gouvernance

La gouvernance échoue lorsque tout le monde est « impliqué » mais que personne n'est responsable. Vous avez besoin de décideurs nominatifs, d'une instance pour les arbitrages et d'un modèle conforme à la structure opérationnelle existante de votre entreprise.

Associer des personnes désignées aux jeux de données critiques

Pour chaque jeu de données critique, attribuez à la fois un data owner (propriétaire des données) et un data steward (gestionnaire de données). Le propriétaire valide la politique, les règles d'usage et les exigences de qualité. Le gestionnaire s'occupe du suivi opérationnel. Cette division du travail est essentielle pour des décisions claires et une gestion cohérente d'un domaine à l'autre, comme le soulignent les recommandations de mise en œuvre d'Alation concernant les rôles de propriétaires de données et de stewards.

Si les limites des rôles sont floues, les demandes d'accès s'embourbent, les définitions dérivent et les problèmes de qualité restent sans solution car personne ne sait exactement qui a le pouvoir de trancher. Ce guide pratique sur les responsabilités du data owner est utile pour formaliser ces droits décisionnels.

Rôles et responsabilités en matière de Data Governance

Choisir un modèle adapté au fonctionnement réel de votre entreprise

Il n'existe pas de modèle de gouvernance unique et parfait. Il n'existe que le modèle que votre structure organisationnelle peut supporter.

Le modèle centralisé fonctionne lorsque les normes de données doivent être strictement contrôlées et que l'organisation accepte une autorité partagée. C'est un choix courant dans les fonctions réglementées, mais il peut générer des goulots d'étranglement si la moindre définition ou dérogation doit passer par une file d'attente centrale.

Le modèle fédéré transfère la responsabilité au niveau des domaines métiers. Il fonctionne bien lorsque les équipes gèrent leurs propres pipelines et produits de données, mais à condition que des standards communs restent appliqués. Dans le cas contraire, chaque domaine finit par inventer sa propre version du principe de qualité.

Le modèle hybride est celui auquel de nombreuses entreprises finissent par aboutir. Une équipe centrale définit la politique commune, la taxonomie, les exigences de contrôle et les critères d'audit. Les équipes de domaine assurent quant à elles l'exécution au sein de leurs propres systèmes.

Un test décisionnel simple peut vous aider à vous positionner :

• Choisissez le modèle centralisé si la cohérence globale importe plus que la rapidité locale.

• Choisissez le modèle fédéré si les domaines sont mûrs et autonomes.

• Choisissez le modèle hybride si vous avez besoin à la fois de standards d'entreprise et d'une responsabilisation des domaines.

Si vous hésitez, le modèle hybride est généralement le point de départ le plus sûr. Il évite le cloisonnement sans prétendre qu'une seule équipe centrale puisse gérer chaque détail opérationnel.

Des politiques statiques aux workflows de qualité automatisés

La plupart des guides de gouvernance passent trop de temps sur la rédaction des politiques et pas assez sur leur mise en œuvre. C'est là que les projets s'essoufflent. Une politique rédigée dans Confluence ou SharePoint peut satisfaire à une exigence documentaire, mais elle n'empêchera pas un retard de traitement, une altération de schéma ou l'insertion d'un enregistrement mal formé dans une table critique.

Pourquoi les documents de politique générale échouent s'ils sont seuls

L'une des principales raisons de l'échec des programmes de gouvernance réside dans le fossé qui sépare la définition de la politique et son application opérationnelle. La gouvernance moderne doit être directement intégrée aux pipelines via la détection automatique d'anomalies, la validation et le suivi de la fraîcheur des données, comme le décrivent les guides d'implémentation de Semarchy.

Ce fossé se manifeste de manières bien connues :

• Une règle de qualité existe, mais aucun système ne la vérifie automatiquement

• Une règle de conservation existe, mais la suppression ou l'archivage reste manuel

• Une définition métier existe, mais les tableaux de bord et les modèles continuent de s'appuyer sur des logiques contradictoires

• Une politique d'accès existe, mais les preuves de son application sont éparpillées

• Une dépendance de schéma existe, mais aucune alerte ne se déclenche lorsqu'une colonne est modifiée

La gouvernance statique génère une certitude passive. Les équipes pensent que le contrôle fonctionne simplement parce que le document existe. La gouvernance opérationnelle crée une certitude active car c'est le système lui-même qui vérifie continuellement la règle.

À quoi ressemble l'application opérationnelle

Le passage d'une gouvernance statique à une gouvernance concrète repose généralement sur un ensemble de patterns techniques précis.

• La validation à l'échelle de l'enregistrement
  En rendant les règles métier applicables, la validation au niveau de l'enregistrement applique des logiques définies par l'utilisateur sur des lignes de données individuelles. Cela renforce l'exhaustivité de la gouvernance et simplifie la préparation des audits pour chaque transaction ou saisie, comme l'explique le dossier de digna démontrant pourquoi la Data Governance soutient la Compliance, l'IA et la confiance de l'entreprise.

• Le suivi de la ponctualité (fraîcheur)
  Les rapports échouent souvent parce que les données arrivent en retard, et non parce qu'elles manquent totalement. Surveiller les fenêtres de livraison attendues permet de détecter les données obsolètes avant que les dirigeants ne prennent des décisions sur la base d'indicateurs dépassés.

• Le suivi du schéma
  Les modifications de schéma silencieuses sont fréquentes dans les environnements dynamiques. L'ajout ou la suppression de colonnes, ainsi que les changements de types de données, peuvent perturber les transformations en aval sans symptôme évident à la source.

• La détection des anomalies
  Certaines anomalies ne violent pas une règle explicite. Une métrique peut rester dans une plage valide mais évoluer de manière inhabituelle. La détection automatisée d'anomalies permet de repérer ces ruptures de tendance sans obliger les équipes à coder manuellement chaque seuil.

• Lignage (lineage) et acheminement des incidents
  Lorsqu'un contrôle échoue, les équipes doivent savoir quel composant en amont a changé, qui en est le propriétaire et qui doit intervenir. Sans lignage, la résolution des incidents de gouvernance s'apparente à un travail d'enquête aveugle.

Une politique ne devient concrète que lorsqu'un système est capable de l'appliquer, de la mesurer et de transmettre les alertes de défaillance à un responsable désigné.

Rendre la gouvernance prête pour l'IA

C'est le volet que la plupart des approches traditionnelles de gouvernance sous-estiment encore aujourd'hui. Les pipelines d'IA et de machine learning n'ont pas seulement besoin de contrôles d'accès et de métadonnées. Ils doivent être protégés contre les dérives, les modifications silencieuses de schéma et l'instabilité des variables (features) d'entrée.

C'est là que l'Observability moderne prend tout son sens. Des plateformes comme le comparatif de digna entre automatisation et outils de qualité des données mettent en avant l'éventail de solutions que les équipes analysent désormais : détection d'anomalies, ponctualité des pipelines, validation au niveau de l'enregistrement et surveillance des schémas au sein d'une même couche opérationnelle. digna est une option dans cette catégorie. Elle exécute ses analyses directement au sein de la base de données du client et prend en charge la détection d'anomalies, la validation, le suivi de la ponctualité et la surveillance des schémas sans transférer les données de production hors de l'infrastructure contrôlée par le client.

Pour les équipes de ML et d'analytics, les questions pratiques de contrôle sont directes :

• Quelles tables alimentent les modèles critiques ou les reportings exécutifs ?

• Quelles conditions de données doivent impérativement être respectées au niveau de chaque enregistrement ?

• Quelle marge de fraîcheur est acceptable avant que les résultats ne présentent un risque ?

• Quels changements structurels doivent bloquer les traitements en aval ?

• Qui reçoit l'alerte, et quelles preuves de contrôle sont conservées ?

Si vous pouvez apporter des réponses opérationnelles à cela, et non pas de simples réponses théoriques dans un document, votre programme de gouvernance est bel et bien entré en production.

Choisir votre architecture et lancer un projet pilote

Une fois le modèle opérationnel défini, l'erreur suivante consiste généralement à acquérir des outils avant de décider comment ils devront s'exécuter dans votre environnement. Les choix d'architecture sont fondamentaux car la gouvernance touche aux données sensibles, aux flux réglementés et aux pipelines de production.

Choisir l'architecture en fonction du contrôle et du mouvement des données

Dans les entreprises réglementées, la première préoccupation n'est généralement pas la richesse des fonctionnalités. C'est l'emplacement où s'effectue le traitement et l'identité des personnes autorisées à accéder aux données.

Les équipes évaluent généralement quelques critères pratiques :

• Déploiement contrôlé par le client
  Le recours au cloud privé ou aux options sur site (on-premise) est indispensable lorsque les services juridiques, la sécurité ou les achats refusent que les données de production quittent les environnements contrôlés.

• Exécution en base de données
  Cette approche réduit le mouvement des données et maintient les vérifications au plus près de l'entrepôt de données (data warehouse) ou du lac (data lake). Elle simplifie également les audits de sécurité car la validation et le suivi s'exécutent là où résident déjà les données.

• Intégration avec la stack existante
  La gouvernance ne peut pas fonctionner de manière cloisonnée par rapport à votre entrepôt de données, vos orchestrateurs de pipelines, votre couche de BI et vos processus de modélisation. Autrement, la propriété et le traitement des anomalies se fragmentent inévitablement.

• Utilisabilité pour les différents rôles
  Les ingénieurs ont besoin de détails opérationnels. Les analystes recherchent des indicateurs de confiance. Les responsables de la gouvernance ont besoin de tendances et de preuves de conformité. Si chaque public requiert un outil distinct, l'adoption globale en pâtira.

Les choix architecturaux doivent refléter vos propres contraintes, et non les configurations par défaut des solutions du marché. Les secteurs de la finance, de la santé, des télécoms et du secteur public s'intéressent ainsi naturellement davantage à l'emplacement d'exécution, à l'auditabilité et aux limites d'accès qu'aux fonctionnalités de catalogue séduisantes.

Concevoir un projet pilote qui suscite la confiance

Un pilote n'est pas une maquette miniature d'un programme d'entreprise globale. C'est la preuve que la gouvernance peut résoudre un problème visible et précis sans ajouter de lourdeur bureaucratique.

La démarche MVP (Minimum Viable Project) réussit car elle cible des priorités limitées. Les organisations adoptant une approche par projet minimum viable signalent des taux de réussite initiaux supérieurs de 40 %, les projets pilotes atteignant 85 % d'adoption en 6 mois en se concentrant d'abord sur un seul domaine de données à fort impact, selon les conseils d'implémentation de la gouvernance de Profisee.

Utilisez un pilote pour répondre à quatre questions clés :

1. Pouvons-nous détecter les anomalies plus tôt ?
   Sélectionnez un domaine caractérisé par des erreurs récurrentes, des rapports figés ou des transferts peu fiables.

2. Pouvons-nous attribuer clairement les responsabilités ?
   Désignez un propriétaire unique, un steward et un sponsor exécutif.

3. Pouvons-nous appliquer un ensemble restreint de contrôles pertinents ?
   Par exemple, des suivis de fraîcheur de données, des alertes de schéma et quelques règles de validation par enregistrement.

4. Pouvons-nous démontrer rapidement de la valeur métier ?
   Réduction du temps d'enquête technique, correction rapide des désaccords de rapports, constitution de preuves d'audit plus fiables ou confiance renforcée dans un pipeline de données alimentant un modèle.

Un bon pilote a une portée de fin précise. Les équipes savent quelles tables entrent dans le périmètre, quels contrôles sont actifs, qui traite les alertes et ce qui définit un succès. Un mauvais pilote dévie vers un projet de « gouvernance » flou, rythmé par des réunions régulières mais sans changement réel dans les opérations quotidiennes.

Faire évoluer la surveillance et pérenniser votre programme

La partie délicate de la gouvernance n'est pas de la lancer, mais de veiller à ce qu'elle reste utile au-delà des premières victoires.

Les programmes matures obtiennent généralement de meilleurs résultats car ils maintiennent un lien étroit entre la gouvernance et les opérations. Les organisations possédant un programme de gouvernance mature réalisent des gains de qualité de données 30 % plus rapides et réduisent de 25 % leurs risques de Compliance sur 12 mois, mais uniquement lorsqu'elles exécutent des audits réguliers de qualité des données associés à des indicateurs clés de gouvernance tout en maintenant une dynamique de collaboration transversale.

Déployer par domaine, pas par décret

Après la phase pilote, étendez votre démarche par vagues successives. N'intégrez de nouveaux domaines de données qu'une fois le précédent structuré autour d'une attribution de rôle claire, de workflows de contrôles actifs, d'un parcours d'alertes validé et de routines de revue bien ancrées dans les pratiques quotidiennes des équipes.

Suivez une logique par phases :

• Diffusez les standards communs avec parcimonie : réutilisez les structures de rôles de propriété existantes, les formats de règles de qualité, les processus d'escalade d'incidents et le formalisme des éléments de preuve.

• Adaptez les contrôles locaux : les domaines liés à la finance, aux fiches clients ou aux variables pour le machine learning n'ont pas besoin d'exécuter des vérifications identiques.

• Suivez régulièrement vos KPI : concentrez-vous sur les indicateurs de performance qui démontrent l'effet protecteur de votre gouvernance au jour le jour, et pas simplement l'existence de documents signés.

• Maintenez l'implication des équipes de domaine : l'équipe centrale définit les prérequis de conformité globale, mais les équipes locales doivent conserver une marge de manœuvre dans leur exécution concrète.

Une gouvernance mature ne signifie pas une accumulation de règles théoriques supplémentaires. Elle se traduit par une proportion accrue de contrôles fiables qui s'exécutent de façon transparente, limitant ainsi les interventions manuelles systématiques.

Traiter les audits et la communication comme un travail opérationnel

Une gouvernance pérenne repose sur l'exécution rigoureuse de tâches régulières et structurées : listes de contrôle de qualité de données, modèles types de politiques, de registres d'incidents, comités de stewardship réguliers et gestion rigoureuse des preuves de fonctionnement des contrôles.

Elle dépend tout autant de la communication. Vos équipes ont besoin de savoir de manière concrète dans quelles situations la gouvernance a évité un incident de reporting majeur, stoppé une modification de schéma risquée ou facilité la préparation d'un audit de Compliance difficile. Si vous ne communiquez auprès des collaborateurs que pour imposer des règles de gestion ou pour arbitrer des blocages techniques, votre démarche sera de nouveau perçue comme une contrainte administrative inutile.

Adoptez un rythme simple et régulier. Des points de contact mensuels par domaine de données. Des preuves documentaires produites de façon claire et pragmatique. Un suivi limpide des anomalies en cours de résolution. Des structures de rôles conçues pour résister aux réorganisations internes de l'entreprise. En définitive, la gouvernance ne doit pas être pensée comme un projet ponctuel : c'est un véritable modèle de fonctionnement interne.

Si votre équipe s'efforce aujourd'hui de faire sortir la gouvernance des documents de travail pour la matérialiser sous forme de contrôles temps réel directement intégrés dans ses flux techniques, sachez que digna a été spécifiquement conçue pour répondre aux attentes de cette couche opérationnelle. Elle permet aux équipes de détecter intelligemment les anomalies, de valider la conformité de chaque transaction, d'assurer le suivi de la fraîcheur des données et d'anticiper les modifications de schémas au sein de vos infrastructures contrôlées. Une solution particulièrement adaptée si vous devez concilier une gouvernance stricte de vos analyses de données, vos impératifs de Compliance et la fiabilité de vos développements d'IA sans risquer d'exposer vos données en dehors de votre environnement cloud ou sur site.