Profils de données

Cette page décrit le service de détection de données sensibles. Ce service vous aide à déterminer l'emplacement des données sensibles et à haut risque dans votre organisation.

Présentation

Le service de découverte vous permet de protéger les données de votre organisation en identifiant l'emplacement des données sensibles et à haut risque. Lorsque vous créez une configuration d'analyse de découverte, la protection des données sensibles analyse vos ressources pour identifier les données à profiler. Ensuite, il génère des profils de vos données. Tant que la configuration de la découverte est active, la protection des données sensibles profile automatiquement les données que vous ajoutez et modifiez. Vous pouvez générer des profils de données pour l'ensemble de l'organisation, pour des dossiers et des projets individuels.

Chaque profil de données est un ensemble d'insights et de métadonnées que le service de découverte collecte à partir de l'analyse d'une ressource compatible. Les insights incluent les infoTypes prédits ainsi que les niveaux de risque et de sensibilité calculés de vos données. Utilisez ces informations afin de prendre des décisions avisées pour la protection, le partage et l'utilisation de vos données.

Les profils de données sont générés à différents niveaux de détail. Par exemple, lorsque vous profilez des données BigQuery, les profils sont générés au niveau du projet, de la table et des colonnes.

L'image suivante présente une liste de profils de données au niveau des colonnes. Cliquez sur l'image pour l'agrandir.

Capture d'écran des profils de données de colonne

Pour obtenir la liste des insights et des métadonnées inclus dans chaque profil de données, consultez la documentation de référence sur les métriques.

Pour en savoir plus sur la hiérarchie des ressources Google Cloud, consultez la page Hiérarchie des ressources.

Découverte de données BigQuery

Lorsque vous profilez des données BigQuery, les profils de données sont générés au niveau du projet, des tables et des colonnes. Après avoir profilé une table BigQuery, vous pouvez examiner les résultats plus en détail en effectuant une inspection approfondie.

Pour en savoir plus sur BigQuery, consultez la documentation BigQuery.

Découverte de données Cloud SQL

Lorsque vous profilez des données Cloud SQL, les profils de données sont générés au niveau du projet, des tables et des colonnes. Avant de pouvoir commencer la découverte, vous devez fournir les détails de connexion de chaque instance Cloud SQL à profiler.

Pour en savoir plus sur Cloud SQL, consultez la documentation Cloud SQL.

Génération de profils de données

Pour commencer à générer des profils de données, vous devez créer une configuration d'analyse de découverte (également appelée configuration de profil de données). Cette configuration d'analyse vous permet de définir le champ d'application de l'opération de découverte et le type de données que vous souhaitez profiler. Dans la configuration de l'analyse, vous pouvez définir des filtres pour spécifier des sous-ensembles de données que vous souhaitez profiler ou ignorer. Vous pouvez également définir la programmation du profilage.

Lors de la création d'une configuration d'analyse, vous définissez également le modèle d'inspection à utiliser. Le modèle d'inspection vous permet de spécifier les types de données sensibles (également appelés infoTypes) que la protection des données sensibles doit analyser.

Lorsque la protection des données sensibles crée des profils de données, elle analyse vos données en fonction de votre configuration d'analyse et de votre modèle d'inspection.

Ressources compatibles

Cette section décrit les ressources que Sensitive Data Protection peut profiler.

BigQuery et BigLake

La protection des données sensibles profile les tables compatibles avec l'API BigQuery Storage Read, y compris les suivantes:

  • Tables BigQuery standards
  • Tables BigLake stockées dans Cloud Storage

Les éléments suivants ne sont pas acceptés:

Cloud SQL

La protection des données sensibles peut profiler des tables Cloud SQL.

Rôles requis pour configurer et afficher des profils de données

Les sections suivantes répertorient les rôles utilisateur requis pour chaque type d'utilisation. Selon la configuration de votre organisation, vous pouvez décider de demander à différentes personnes d'effectuer différentes tâches. Par exemple, la personne qui configure les profils de données peut être différente de la personne qui en assure le suivi régulier.

Rôles requis pour utiliser des profils de données au niveau de l'organisation ou des dossiers

Ces rôles vous permettent de configurer et d'afficher des profils de données au niveau de l'organisation ou du dossier.

Assurez-vous que ces rôles sont attribués aux personnes appropriées au niveau de l'organisation. Votre administrateur Google Cloud peut également créer des rôles personnalisés qui ne disposent que des autorisations pertinentes.

Objectif Rôle prédéfini Autorisations pertinentes
Créer une configuration d'analyse et afficher les profils de données Administrateur DLP (roles/dlp.admin)
  • dlp.inspectTemplates.create
  • dlp.jobs.create
  • dlp.jobTriggers.create
  • dlp.columnDataProfiles.list
  • dlp.jobs.list
  • dlp.jobTriggers.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Créez un projet qui servira de conteneur d'agent de service1. Créateur de projet (roles/resourcemanager.projectCreator)
  • resourcemanager.organizations.get
  • resourcemanager.projects.create
Accorder l'accès au profilage des données2 Choisissez l'une des options suivantes :
  • Administrateur de l'organisation (roles/resourcemanager.organizationAdmin)
  • Administrateur de sécurité (roles/iam.securityAdmin)
  • resourcemanager.organizations.getIamPolicy
  • resourcemanager.organizations.setIamPolicy
Afficher les profils de données (lecture seule) Lecteur de profils de données DLP (roles/dlp.dataProfilesReader)
  • dlp.columnDataProfiles.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Lecteur DLP (roles/dlp.reader)
  • dlp.jobs.list
  • dlp.jobTriggers.list

1 Si vous ne disposez pas du rôle de créateur de projet (roles/resourcemanager.projectCreator), vous pouvez toujours créer une configuration d'analyse, mais le conteneur d'agent de service que vous utilisez doit correspondre à un projet existant.

2 Si vous ne disposez pas du rôle Administrateur de l'organisation (roles/resourcemanager.organizationAdmin) ou Administrateur de sécurité (roles/iam.securityAdmin), vous pouvez toujours créer une configuration d'analyse. Une fois la configuration d'analyse créée, une personne de votre organisation disposant de l'un de ces rôles doit accorder à l'agent de service un accès de découverte.

Rôles requis pour utiliser des profils de données au niveau du projet

Ces rôles vous permettent de configurer et d'afficher des profils de données au niveau du projet.

Assurez-vous que ces rôles sont attribués aux personnes appropriées au niveau du projet. Votre administrateur Google Cloud peut également créer des rôles personnalisés qui ne disposent que des autorisations pertinentes.

Objectif Rôle prédéfini Autorisations pertinentes
Configurer et afficher des profils de données Administrateur DLP (roles/dlp.admin)
  • dlp.inspectTemplates.create
  • dlp.jobs.create
  • dlp.jobTriggers.create
  • dlp.columnDataProfiles.list
  • dlp.jobs.list
  • dlp.jobTriggers.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Afficher les profils de données (lecture seule) Lecteur de profils de données DLP (roles/dlp.dataProfilesReader)
  • dlp.columnDataProfiles.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Lecteur DLP (roles/dlp.reader)
  • dlp.jobs.list
  • dlp.jobTriggers.list

Configuration de l'analyse de découverte

Une configuration d'analyse de découverte ou une configuration de profil de données spécifie la ressource (organisation, dossier ou projet) à profiler, le modèle d'inspection à utiliser et ce qu'il faut faire avec les résultats. Il contient également des informations administratives telles que le conteneur d'agent de service auquel associer l'analyse et le compte de facturation à utiliser.

Types de découverte

Le service de découverte est compatible avec les types d'opérations suivants:

Champs d'application de la configuration d'analyse

Vous pouvez créer une configuration d'analyse aux niveaux suivants:

  • Organisation
  • Dossier
  • Projet
  • Table (mode test)

Au niveau de l'organisation et du dossier, si deux configurations d'analyse actives ou plus ont le même projet dans leur champ d'application, la protection des données sensibles détermine la configuration d'analyse qui peut générer des profils pour ce projet. Pour en savoir plus, consultez la section Remplacer les configurations d'analyse sur cette page.

Une configuration d'analyse au niveau du projet peut toujours profiler le projet cible et n'entre pas en concurrence avec les autres configurations au niveau du dossier parent ou de l'organisation.

Une configuration d'analyse au niveau de la table vise à vous aider à explorer et à tester le profilage sur une seule table.

Emplacement de la configuration de l'analyse

La première fois que vous créez une configuration d'analyse, vous devez indiquer où vous souhaitez que la protection des données sensibles la stocke. Toutes les configurations d'analyse ultérieures que vous créez sont stockées dans cette même région.

Par exemple, si vous créez une configuration d'analyse pour le dossier A et que vous la stockez dans la région us-west1, toute configuration d'analyse que vous créez ultérieurement pour une autre ressource est également stockée dans cette région.

Les métadonnées concernant les données à profiler sont copiées dans la même région que vos configurations d'analyse, mais les données elles-mêmes ne sont ni déplacées ni copiées. Pour en savoir plus, consultez la section Considérations relatives à la résidence des données.

Modèle d'inspection

Un modèle d'inspection spécifie les types d'informations (ou infoTypes) que la protection des données sensibles recherche lors de l'analyse de vos données. Ici, vous combinez des infoTypes intégrés et des infoTypes personnalisés facultatifs.

Vous pouvez également fournir un niveau de probabilité pour affiner ce que la protection des données sensibles considère comme une correspondance. Vous pouvez ajouter des ensembles de règles pour exclure les résultats indésirables ou inclure des résultats supplémentaires.

Par défaut, si vous modifiez un modèle d'inspection utilisé par votre configuration d'analyse, les modifications ne sont appliquées qu'aux futures analyses. Votre action ne provoque pas d'opération de reprofilage des données.

Si vous souhaitez que les modifications apportées au modèle d'inspection déclenchent des opérations de reprofilage sur les données concernées, ajoutez ou mettez à jour une programmation dans votre configuration d'analyse, puis activez l'option permettant de reprofiler les données lorsque le modèle d'inspection change. Pour en savoir plus, consultez la section Fréquence de génération de profils de données.

Vous devez disposer d'un modèle d'inspection dans chaque région où vous avez des données à profiler. Si vous souhaitez utiliser un seul modèle pour plusieurs régions, vous pouvez utiliser un modèle stocké dans la région global. Si des règles d'administration vous empêchent de créer un modèle d'inspection global, vous devez définir un modèle d'inspection dédié pour chaque région. Pour en savoir plus, consultez la section Considérations relatives à la résidence des données.

Les modèles d'inspection sont un composant essentiel de la plate-forme de protection des données sensibles. Les profils de données utilisent les mêmes modèles d'inspection que ceux que vous pouvez utiliser dans tous les services de protection des données sensibles. Pour en savoir plus sur les modèles d'inspection, consultez la page Modèles.

Conteneur d'agent de service et agent de service

Lorsque vous créez une configuration d'analyse pour votre organisation ou pour un dossier, la protection des données sensibles nécessite la fourniture d'un conteneur d'agent de service. Un conteneur d'agent de service est un projet Google Cloud utilisé par Sensitive Data Protection pour suivre les frais facturés liés aux opérations de profilage au niveau de l'organisation et du dossier.

Le conteneur de l'agent de service contient un agent de service. Il s'agit d'un compte de service géré par Google qui permet à la protection des données sensibles de profiler les données en votre nom. Vous avez besoin d'un agent de service pour vous authentifier auprès de Sensitive Data Protection et d'autres API. Votre agent de service doit disposer de toutes les autorisations requises pour accéder à vos données et les profiler. L'ID de l'agent de service est au format suivant:

service-PROJECT_NUMBER@dlp-api.iam.gserviceaccount.com

Ici, PROJECT_NUMBER est l'identifiant numérique du conteneur de l'agent de service.

Lorsque vous définissez le conteneur de l'agent de service, vous pouvez choisir un projet existant. Si le projet que vous sélectionnez contient un agent de service, la protection des données sensibles lui accorde les autorisations IAM requises. Si le projet ne comporte pas d'agent de service, la protection des données sensibles en crée un et lui accorde automatiquement des autorisations de profilage des données.

Vous pouvez également demander à Sensitive Data Protection de créer automatiquement le conteneur et l'agent de service de l'agent de service. La protection des données sensibles accorde automatiquement des autorisations de profilage de données à l'agent de service.

Dans les deux cas, si la protection des données sensibles n'accorde pas l'accès au profilage des données à votre agent de service, une erreur s'affiche lorsque vous affichez les détails de la configuration de l'analyse.

Pour les configurations d'analyse au niveau du projet, vous n'avez pas besoin d'un conteneur d'agent de service. Le projet que vous profilez joue le rôle de conteneur de l'agent de service. Pour exécuter des opérations de profilage, la protection des données sensibles utilise l'agent de service de ce projet.

Accès au profilage des données au niveau de l'organisation ou du dossier

Lorsque vous configurez le profilage au niveau de l'organisation ou du dossier, la protection des données sensibles tente d'accorder automatiquement à votre agent de service l'accès au profilage des données. Toutefois, si vous ne disposez pas des autorisations nécessaires pour attribuer des rôles IAM, la protection des données sensibles ne peut pas effectuer cette action en votre nom. Une personne disposant de ces autorisations dans votre organisation, comme un administrateur Google Cloud, doit accorder à votre agent de service l'accès au profilage des données.

Fréquence de génération du profil de données

Par défaut, la protection des données sensibles profile vos données comme suit:

  1. Une fois que vous avez créé une configuration d'analyse pour une ressource particulière, le service de protection des données sensibles effectue une analyse initiale, profilant les données dans le champ d'application de votre configuration d'analyse. Après l'analyse initiale, il surveille en permanence ces données pour détecter tout ajout ou toute modification.

  2. La protection des données sensibles profile les nouvelles tables que vous ajoutez peu de temps après.

  3. Tous les 30 jours, la protection des données sensibles reprofile les tables existantes qui ont subi des modifications de schéma au cours des 30 derniers jours.

Dans votre configuration d'analyse, vous pouvez personnaliser la fréquence de profilage en créant une ou plusieurs planifications pour différents sous-ensembles de données. Vous pouvez spécifier des sous-ensembles de données que vous ne souhaitez jamais profiler. Vous pouvez également spécifier les types d'événements qui doivent déclencher des opérations de reprofilage. Il peut s'agir, par exemple, de mises à jour du schéma de table et des mises à jour de modèles d'inspection.

Les options de reprofilage suivantes sont disponibles:

  • Ne pas reprofiler: ne reprofilez jamais une fois les profils initiaux générés.
  • Reprofiler tous les jours: attendez 24 heures avant de reprofiler les données mises à jour.
  • Reprofiler toutes les semaines: attendez sept jours avant de reprofiler les données mises à jour.
  • Reprofiler tous les mois: attendez 30 jours avant de reprofiler les données mises à jour.

La programmation spécifie le plus long délai d'attente avant que la protection des données sensibles ne s'accumule des mises à jour avant de reprofiler vos données. Si aucune modification applicable (telle que des modifications de schéma ou de modèle d'inspection) n'est effectuée au cours de la période spécifiée, aucune donnée n'est reprofilée. Lorsque la prochaine modification applicable se produit, les données concernées sont reprofilées lors de la prochaine modification, qui est déterminée par différents facteurs (tels que la capacité disponible de la machine ou le nombre d'unités d'abonnement achetées). La protection des données sensibles commence alors à attendre que les mises à jour s'accumulent selon le calendrier que vous avez défini.

Par exemple, supposons que votre configuration d'analyse soit définie de manière à reprofiler tous les mois en cas de modification du schéma. Les profils de données ont été créés pour la première fois le jour 0. Aucune modification de schéma n'est apportée au 30e jour. Par conséquent, aucune donnée n'est reprofilée. Le premier changement de schéma a lieu le 35e jour. La protection des données sensibles reprofile les données mises à jour à la prochaine occasion. Le système attend ensuite 30 jours supplémentaires que les mises à jour du schéma s'accumulent avant de reprofiler les données mises à jour.

L'opération peut prendre jusqu'à 24 heures à compter du début du reprofilage. Si le délai dépasse 24 heures et que vous êtes en mode de tarification par abonnement, vérifiez si vous disposez d'une capacité restante pour le mois.

Pour obtenir des exemples, consultez la section Exemples de tarification du profilage des données.

Performances du profilage

Le temps nécessaire au profilage de vos données varie en fonction de plusieurs facteurs, y compris, mais sans s'y limiter, les suivants:

  • Nombre de tables en cours de profilage
  • Tailles des tables
  • Nombre de colonnes dans les tables
  • Types de données dans les colonnes

Par conséquent, les performances de la protection des données sensibles lors d'une tâche d'inspection ou de profilage passée n'indiquent pas son comportement dans les tâches de profilage futures.

Conservation des profils de données

La protection des données sensibles conserve la dernière version d'un profil de données pendant 13 mois. Lorsque la protection des données sensibles reprofile une table mise à jour, les profils de données existants sont remplacés par de nouveaux.

Étudions les cas de figure suivants :

  • Le 1er janvier, Sensitive Data Protection profile la table A. La table A ne change pas pendant plus d'un an et n'est donc pas profilée à nouveau. Dans ce cas, la protection des données sensibles conserve les profils de données de la table A pendant 13 mois avant de les supprimer.

  • Le 1er janvier, Sensitive Data Protection profile la table A. Dans le mois qui suit, un membre de votre organisation met à jour le schéma de cette table. En raison de cette modification, le mois suivant, la protection des données sensibles reprofilera automatiquement la table A. Les profils de données nouvellement générés écrasent ceux créés en janvier.

Pour en savoir plus sur la facturation par Sensitive Data Protection pour le profilage des tables nouvelles et modifiées, consultez la section Tarifs du profilage des données.

Si vous souhaitez conserver les profils de données indéfiniment ou conserver une trace des modifications qu'ils subissent, envisagez d'enregistrer les profils de données dans BigQuery lorsque vous configurez le profilage. Vous choisissez l'ensemble de données BigQuery dans lequel enregistrer les profils, et vous contrôlez la règle d'expiration de table pour cet ensemble de données.

Remplacer les configurations d'analyse

Vous ne pouvez créer qu'une seule configuration d'analyse pour chaque combinaison de champ d'application et de type de découverte. Par exemple, vous ne pouvez créer qu'une seule configuration d'analyse au niveau de l'organisation pour le profilage des données BigQuery et une seule configuration d'analyse au niveau de l'organisation pour la découverte de secrets. De même, vous ne pouvez créer qu'une seule configuration d'analyse au niveau du projet pour le profilage des données BigQuery et une seule configuration d'analyse au niveau du projet pour la découverte de secrets.

Si deux configurations d'analyse actives ou plus ont le même projet et le même type de découverte dans leur champ d'application, les règles suivantes s'appliquent:

  • Parmi les configurations d'analyse au niveau de l'organisation et du dossier, la configuration la plus proche du projet peut exécuter la détection pour ce projet. Cette règle s'applique même si une configuration d'analyse au niveau du projet avec le même type de découverte existe également.
  • La protection des données sensibles traite les configurations d'analyse au niveau du projet indépendamment des configurations au niveau de l'organisation et au niveau du dossier. Une configuration d'analyse que vous créez au niveau du projet ne peut pas remplacer une configuration que vous créez pour un dossier ou une organisation parent.

Prenons l'exemple suivant, qui comporte trois configurations d'analyse actives. Supposons que toutes ces configurations d'analyse sont destinées au profilage des données BigQuery.

Schéma d'une hiérarchie de ressources avec une configuration d'analyse appliquée à une organisation, à un dossier et à un projet

Ici, la Configuration d'analyse 1 s'applique à l'ensemble de l'organisation, la Configuration d'analyse 2 s'applique au dossier Équipe B et la Configuration d'analyse 3 s'applique au projet Production. Dans cet exemple :

  • La protection des données sensibles profile toutes les tables des projets qui ne se trouvent pas dans le dossier Équipe B selon la configuration d'analyse 1.
  • La protection des données sensibles profile toutes les tables des projets du dossier Équipe B, y compris les tables du projet Production, conformément à la configuration d'analyse 2.
  • La protection des données sensibles profile toutes les tables du projet Production en fonction de la configuration d'analyse 3.

Dans cet exemple, la protection des données sensibles génère deux ensembles de profils pour le projet Production, un défini pour chacune des configurations d'analyse suivantes:

  • Configuration d'analyse 2
  • Configuration d'analyse 3

Cependant, même s'il existe deux ensembles de profils pour un même projet, ils ne sont pas tous regroupés dans votre tableau de bord. Vous ne voyez que les profils qui ont été générés dans la ressource (organisation, dossier ou projet) et la région que vous consultez.

Pour plus d'informations sur la hiérarchie des ressources de Google Cloud, consultez la page Hiérarchie des ressources.

Instantanés de profils de données

Chaque profil de données inclut un instantané de la configuration d'analyse et du modèle d'inspection utilisé pour la générer. Vous pouvez utiliser cet instantané pour vérifier les paramètres que vous avez utilisés pour générer un profil de données particulier.

Points à prendre en compte concernant la résidence des données

La protection des données sensibles est conçue pour permettre la résidence des données. Si vous devez respecter les exigences de résidence des données, tenez compte des points suivants :

Régions d'inspection

La protection des données sensibles inspecte vos données dans la même région que celle où elles sont stockées. Autrement dit, vos données ne quittent pas leur région actuelle.

En outre, un modèle d'inspection ne peut être utilisé que pour profiler des données résidant dans la même région que ce modèle. Par exemple, si vous configurez le profileur de données pour qu'il utilise un modèle d'inspection stocké dans la région us-west1, la protection des données sensibles ne peut profiler que les données de cette région.

Vous pouvez définir un modèle d'inspection dédié pour chaque région contenant des données. Si vous fournissez un modèle d'inspection stocké dans la région global, la protection des données sensibles l'utilise pour les données des régions sans modèle d'inspection dédié.

Le tableau suivant fournit des exemples de scénarios :

Scénario Assistance
Analyse de données situées dans la région us à l'aide d'un modèle d'inspection situé dans la région us. Compatible
Analyse de données situées dans la région global à l'aide d'un modèle d'inspection situé dans la région us. Non compatible
Analyse de données situées dans la région us à l'aide d'un modèle d'inspection situé dans la région global. Compatible
Analyse de données situées dans la région us à l'aide d'un modèle d'inspection situé dans la région us-east1. Non compatible
Analyse de données situées dans la région us-east1 à l'aide d'un modèle d'inspection situé dans la région us. Non compatible
Analyse de données situées dans la région us à l'aide d'un modèle d'inspection situé dans la région asia. Non compatible

Configuration du profil de données

Lorsque la protection des données sensibles crée des profils de données, elle prend un instantané de votre configuration d'analyse et de votre modèle d'inspection et les stocke dans chaque profil de données de table. Si vous configurez le profileur de données pour utiliser un modèle d'inspection de la région global, la protection des données sensibles copie ce modèle dans n'importe quelle région contenant des données à profiler. De même, il copie la configuration d'analyse dans ces régions.

Prenons l'exemple suivant : le projet A contient la table 1. La table 1 se trouve dans la région us-west1, la configuration d'analyse se trouve dans la région us-west2 et le modèle d'inspection se trouve dans la région global.

Lorsque la protection des données sensibles analyse le projet A, elle crée des profils de données pour le Tableau 1 et les stocke dans la région us-west1. Le profil de données de table de la table 1 contient des copies de la configuration d'analyse et du modèle d'inspection utilisé dans l'opération de profilage.

Si vous ne souhaitez pas que votre modèle d'inspection soit copié dans d'autres régions, ne configurez pas la protection des données sensibles pour analyser les données dans ces régions.

Stockage régional des profils de données

Après avoir inspecté vos données, la protection des données sensibles génère des profils de données. Chaque profil de données est stocké dans la région où sont stockées ses données cibles, et l'inspection est également traitée. Pour afficher des profils de données dans la console Google Cloud, vous devez d'abord sélectionner leur région. Si vous disposez de données dans plusieurs régions, vous devez changer de région pour afficher chaque ensemble de profils.

Régions non compatibles

Si vous avez des tables dans une région non compatible avec la protection des données sensibles, elle ignore ces tables et affiche une erreur lorsque vous affichez les profils de données.

Emplacements multirégionaux

La protection des données sensibles traite une zone multirégionale comme une seule région et non comme un ensemble de régions. Par exemple, l'emplacement multirégional us et l'emplacement us-west1 sont considérés comme deux régions distinctes pour ce qui est de la résidence des données.

Conformité

Pour en savoir plus sur la manière dont la protection des données sensibles traite vos données et vous aide à respecter les exigences de conformité, consultez Sécurité des données.

Étapes suivantes