ENTRA ID SYNC JACKING: Comprendre l’attaque, mesurer les risques et se protéger


Si vous n’avez pas de connaissances evoluées dans l’environnmeent ENtra ID on vous explique dans ce post étape par étape comment fonctionne une attaque de Sync Jacking sur l’environnement Entra ID et comment s’en protéger.

SyncJacking est une technique d’attaque relativement anciénne, qui permet à un attaquant disposant de droits limités dans l’Active Directory local d’une entreprise de prendre le contrôle complet d’un compte Microsoft Entra ID (ex-Azure AD), y compris un compte d’administrateur global. L’attaque exploite le mécanisme de synchronisation entre l’annuaire local et le cloud, géré par l’outil Microsoft Entra Connect.

Cette vulnérabilité a été découverte en octobre 2022 par les chercheurs de Semperis, puis officiellement confirmée par Microsoft (MSRC) en mai 2025 comme une vulnérabilité importante d’escalade de privilèges. Microsoft déploie depuis fin 2025 des protections au niveau de la plateforme, avec une application progressive prévue à partir de mars 2026.

Pourquoi ce document vous concerne Si votre organisation utilise Microsoft 365, Entra ID et un annuaire Active Directory local synchronisé via Entra Connect (ce qui est le cas de la majorité des grandes entreprises), vous êtes potentiellement exposé. Deux dates clés à retenir : Mars 2026 – Microsoft commence à activer les protections automatiques. 30 septembre 2026 – les versions d’Entra Connect antérieures à 2.5.79.0 cesseront de fonctionner.

En quelques chiffres

Découverte initialeOctobre 2022 par Semperis
Confirmation MicrosoftMai 2025 (MSRC)
Permissions nécessaires2 seulement (Write/GenericWrite + Delete sur des comptes AD)
Cible potentielleN’importe quel compte synchronisé, jusqu’à Global Administrator
Traces dans l’AD localAucune
Traces dans Entra IDTrès limitées
Date de durcissementMars 2026 (déploiement progressif)
Version minimale Entra Connect2.5.79.0 avant le 30 septembre 2026

1. Les notions de base à connaître

Avant de comprendre SyncJacking, il est utile de rappeler comment fonctionne l’identité dans une organisation moderne qui utilise Microsoft 365.

1.1. Active Directory (AD) : l’annuaire local

L’Active Directory est l’annuaire historique de Microsoft, installé sur des serveurs au sein de l’entreprise. Il contient les comptes utilisateurs, les groupes, les ordinateurs, et gère les autorisations. C’est lui qui décide qui peut ouvrir une session sur un poste de travail, accéder à un partage de fichiers, ou imprimer.

À retenir L’AD local est l’annuaire « physique » de l’entreprise, gérée par les équipes internes, hébergée sur des serveurs sur site (ou dans un datacenter privé).

1.2. Microsoft Entra ID : l’annuaire cloud

Microsoft Entra ID, anciennement appelé Azure Active Directory ou Azure AD, est l’équivalent de l’Active Directory mais dans le cloud Microsoft. C’est lui qui gère les accès à Microsoft 365 (Outlook, Teams, SharePoint, OneDrive), à Azure, mais aussi à des milliers d’applications SaaS tierces (Salesforce, ServiceNow, etc.).

À retenir Entra ID est l’annuaire « cloud » qui contrôle l’accès aux services en ligne. Il est hébergé et géré par Microsoft.

1.3. L’identité hybride

La très grande majorité des entreprises possèdent les deux : un AD local historique et un Entra ID pour le cloud. Pour éviter à l’utilisateur d’avoir deux comptes différents, on synchronise les deux annuaires. C’est ce qu’on appelle l’identité hybride.

Concrètement, l’utilisateur saisit un seul couple identifiant/mot de passe et peut accéder aussi bien à son poste de travail Windows qu’à Microsoft 365.

1.4. Microsoft Entra Connect : le pont entre les deux mondes

Entra Connect (anciennement Azure AD Connect) est l’outil Microsoft qui assure la synchronisation entre l’AD local et Entra ID. Il est installé sur un serveur de l’entreprise et fait régulièrement (toutes les quelques minutes) le pont entre les deux annuaires :

  • Création d’un compte dans l’AD local => création automatique dans Entra ID.
  • Modification du nom, du service ou du mot de passe localement => répercussion dans Entra ID.
  • Synchronisation du hash du mot de passe (Password Hash Sync), activée par défaut, pour permettre l’authentification cloud avec le même mot de passe.
Une analogie simple Imaginez Entra Connect comme un facteur qui fait des allers-retours entre deux bureaux : votre bureau interne (AD local) et votre bureau cloud (Entra ID). Il livre les courriers (modifications de comptes) toutes les deux minutes. SyncJacking, c’est l’équivalent d’un faux facteur qui réussit à substituer l’adresse d’un colis : votre courrier finit chez quelqu’un d’autre.

1.5. Comment Entra Connect reconnaît un compte

Pour savoir que le compte « Alice » de l’AD local correspond bien au compte « Alice » dans Entra ID, Entra Connect utilise un identifiant unique appelé source anchor (ancre de source).

Cet identifiant est généralement dérivé d’un attribut technique du compte AD local appelé objectGUID, lui-même converti en une valeur appelée ImmutableID côté Entra ID. Depuis quelques versions, Entra Connect privilégie un attribut nommé mS-DS-ConsistencyGuid, qui joue le même rôle.

Source anchor (ancre de source) C’est l' »empreinte digitale » qui permet à Entra Connect de relier un compte AD local à son équivalent dans Entra ID. Si on parvient à modifier cette empreinte, on peut faire pointer Entra Connect vers un autre compte.

1.6. Hard matching et soft matching

Entra Connect dispose de deux méthodes pour faire correspondre les comptes :

  • Hard matching (correspondance forte) : basée sur le source anchor (objectGUID / ImmutableID / mS-DS-ConsistencyGuid). C’est la méthode principale et c’est elle qui est exploitée par SyncJacking.
  • Soft matching (correspondance souple) : basée sur des attributs comme l’UPN (User Principal Name, l’adresse de connexion type prenom.nom@societe.com) ou l’adresse SMTP principale. Une variante de SyncJacking existe également via ce mécanisme.

Qu’est-ce que SyncJacking ?

SyncJacking est la contraction de Sync (synchronisation) et Hijacking (détournement). C’est une technique d’attaque qui détourne le processus de synchronisation d’Entra Connect pour prendre le contrôle d’un compte cloud.

2.1. L’idée centrale

L’attaquant ne pirate pas directement le compte cloud de la victime. Il ne devine pas son mot de passe. Il ne contourne pas la MFA. Il fait quelque chose de plus subtil :

Il convainc Entra Connect que son propre compte local (qu’il maîtrise totalement) est en réalité le compte de la victime. Lors du prochain cycle de synchronisation, le mot de passe et certaines propriétés de son compte attaquant sont alors synchronisés vers le compte cloud de la victime. Il peut désormais se connecter comme elle.

Le piège L’attaquant n’a pas besoin d’être administrateur. Il lui suffit de disposer de quelques droits sur deux comptes existants dans l’AD local. Or, dans beaucoup d’organisations, ces droits sont délégués à des équipes support, à des prestataires, ou hérités historiquement sans audit régulier.

2.2. Les prérequis de l’attaquant

Pour réussir un SyncJacking, l’attaquant a besoin de deux permissions très spécifiques dans l’Active Directory local :

  1. Write-All-Properties ou GenericWrite sur un compte AD non synchronisé qu’il contrôle (par exemple un compte de test, un compte personnel, ou un compte qu’il a créé lui-même).
  2. Delete sur le compte AD synchronisé de la victime qu’il souhaite usurper.

L’attaquant doit également connaître le mot de passe du compte qu’il contrôle (le sien).

Profils typiquement à risque Les membres du groupe Account Operators, qui peuvent gérer tous les comptes utilisateurs. Les utilisateurs ou groupes ayant reçu une délégation de contrôle (Delegation of Control) sur des unités d’organisation (OU) mélangeant des comptes synchronisés et non synchronisés. Les administrateurs de serveurs de support ou de help-desk avec des droits trop larges. Les comptes de service avec des droits hérités historiquement.

3. Comment fonctionne SyncJacking, étape par étape

Pour bien comprendre, suivons un scénario concret. Mettons en scène trois personnages :

  • Nutshell : un administrateur global de l’entreprise, dont le compte cloud nutshell@societe.onmicrosoft.com est synchronisé depuis l’AD local. C’est la cible.
  • Alice : un compte AD local non synchronisé que l’attaquant contrôle entièrement (il connaît son mot de passe et possède des droits Write-All-Properties dessus).
  • L’attaquant : un utilisateur interne malveillant ou un attaquant ayant compromis un poste avec ces droits.

3.1. Étape 1 – Copier l’UPN de la victime

L’attaquant ouvre les propriétés du compte Alice dans l’AD local et copie l’UPN de la victime (nutshell@societe.onmicrosoft.com) dans l’attribut userPrincipalName d’Alice.

À ce stade, deux comptes locaux ont le même UPN, ce qui est inhabituel mais autorisé techniquement.

3.2. Étape 2 – Copier l’ancre de source

L’attaquant copie la valeur de l’attribut mS-DS-ConsistencyGuid du compte Nutshell vers le même attribut du compte Alice. C’est le point clé : Alice possède désormais la même « empreinte digitale » que Nutshell aux yeux d’Entra Connect.

3.3. Étape 3 – Supprimer le compte original de la victime

L’attaquant supprime le compte Nutshell de l’AD local. Cette suppression ne touche pas immédiatement le compte cloud de Nutshell dans Entra ID.

3.4. Étape 4 – Attendre le cycle de synchronisation

Entra Connect tourne par défaut toutes les deux minutes. Lors du prochain cycle :

  • Il constate que Nutshell n’existe plus dans l’AD local.
  • Il voit qu’Alice possède désormais le même source anchor que celui qu’il avait associé à Nutshell.
  • Il en conclut que Alice est en réalité Nutshell et remappe le compte cloud existant.
  • Avec Password Hash Sync, le mot de passe d’Alice est synchronisé vers le compte cloud de Nutshell.

3.5. Étape 5 – Connexion comme la victime

L’attaquant se connecte à Microsoft 365 ou au portail Azure avec l’UPN nutshell@societe.onmicrosoft.com et le mot de passe d’Alice (qu’il connaît). Il dispose désormais du rôle Global Administrator et peut faire tout ce que Nutshell pouvait faire.

Le pire ? Aucune trace exploitable L’attaque ne génère aucun événement dans les logs de l’Active Directory local : ce ne sont que des modifications d’attributs et une suppression de compte, toutes considérées comme légitimes par le système. Côté Entra ID, on observe uniquement une succession de deux événements : Change user password puis Update user (avec un DisplayName modifié) pour le même UPN. Sans outillage dédié, ces deux lignes passent inaperçues parmi des milliers d’événements quotidiens.

4. Pourquoi SyncJacking est particulièrement dangereux

4.1. Une attaque « bas privilèges, haute récompense »

Beaucoup d’attaques cloud nécessitent au préalable de compromettre un compte à privilèges. SyncJacking renverse cette logique : il suffit de droits restreints sur des comptes locaux, parfois inhérents à des fonctions de support ou de gestion de proximité, pour escalader jusqu’à un compte Global Administrator.

4.2. Une discrétion redoutable

L’absence de traces dans les logs AD et la finesse des traces Entra ID rendent la détection difficile. Sans outillage spécialisé (Microsoft Defender for Identity, Semperis Directory Services Protector, ou équivalent), l’attaque peut rester invisible pendant des semaines.

4.3. Une persistance native

Une fois un compte cloud usurpé, l’attaquant peut, selon le rôle de la victime, créer de nouveaux comptes, modifier les politiques de Conditional Access, désactiver la MFA, ou exfiltrer massivement des données. Il peut également installer une persistance dans Entra ID (création d’applications, ajout de credentials sur des service principals, etc.).

4.4. Les chemins d’attaque indirects

La délégation de contrôle est un mécanisme historique de l’AD. Une OU contenant à la fois des comptes utilisateurs standards et des comptes à privilèges, déléguée à une équipe support, devient un vecteur SyncJacking. De même, les groupes Account Operators (souvent oubliés) confèrent par défaut les permissions nécessaires.

Une faille « by design » Avant l’engagement de Microsoft fin 2025, la firme considérait cette faiblesse comme un comportement « by design » du produit. C’est en mai 2025, après plusieurs années d’échanges avec Semperis, que le MSRC a reconnu la vulnérabilité comme une faille d’escalade de privilèges et entamé le travail de durcissement de la plateforme.

5. Comment détecter une tentative de SyncJacking

La détection est difficile mais pas impossible. Voici les indicateurs et les bonnes pratiques.

5.1. Le pattern d’événements Entra ID

Dans les journaux d’audit Entra ID, surveiller la séquence suivante, pour un même UPN :

  • Un événement Change user password.
  • Suivi rapidement d’un événement Update user avec un changement de DisplayName.

Cette combinaison n’est pas spécifique à 100% à SyncJacking, mais elle est suffisamment inhabituelle pour mériter une investigation.

5.2. Surveiller les attributs sensibles

Toute modification des attributs suivants doit être tracée et alertée :

  • mS-DS-ConsistencyGuid (ancre de source)
  • objectGUID (en cas de manipulation avancée)
  • userPrincipalName (UPN)
  • proxyAddresses (utilisé pour le soft matching)
  • ImmutableID (côté Entra ID)

Idéalement, seul le compte de service d’Entra Connect et un nombre très limité d’administrateurs doivent pouvoir modifier ces attributs.

5.3. Les suppressions de comptes synchronisés

Toute suppression d’un compte synchronisé, en particulier d’un compte à privilèges, doit générer une alerte immédiate. Coupler cette alerte avec l’apparition de comptes « nouvellement synchronisés » peu après est un indicateur fort.

5.4. Outils dédiés

  • Microsoft Defender for Identity : détecte les comportements anormaux sur l’AD local.
  • Microsoft Entra Connect Health : fournit des alertes en temps réel sur les anomalies de synchronisation.
  • Semperis Directory Services Protector (DSP) : outil tiers spécialisé dans la détection des attaques sur l’AD et Entra ID, dont SyncJacking.
  • SIEM : règles de corrélation custom sur les patterns décrits ci-dessus.

6. Comment se protéger : un plan en dix mesures

Aucune mesure isolée ne suffit. La défense efficace contre SyncJacking repose sur une approche en profondeur, combinant le durcissement technique, la surveillance et la gouvernance des accès.

6.1. Mesure 1 – Mettre à jour Entra Connect

Microsoft impose la version 2.5.79.0 ou supérieure avant le 30 septembre 2026. Au-delà de cette date, les versions antérieures cesseront purement et simplement de synchroniser.

Action concrète Vérifier la version installée d’Entra Connect. S’assurer que l’auto-upgrade est activé. Planifier une mise à jour manuelle si l’auto-upgrade n’est pas possible (environnement complexe, ADFS, etc.). Tester la version cible dans un environnement de pré-production avant la bascule.

6.2. Mesure 2 – Désactiver le « hard match takeover »

Cette fonctionnalité permet à Entra Connect de « reprendre » un compte cloud existant et d’en faire devenir l’AD local la source d’autorité. C’est précisément ce qu’exploite SyncJacking. Elle doit être désactivée si elle n’est pas indispensable.

Commande PowerShell (à exécuter depuis le module Microsoft Graph PowerShell ou MSOnline) :

Set-EntraDirSyncFeature -Feature BlockCloudObjectTakeoverThroughHardMatch -Enabled $true

À noter Cette mesure réduit la surface d’attaque mais ne suffit pas. Les tests de Semperis ont montré que SyncJacking peut, dans certains cas, fonctionner même avec cette option activée. Elle reste néanmoins une étape obligatoire du durcissement.

6.3. Mesure 3 – Désactiver le soft matching si possible

Le soft matching (correspondance par UPN ou par adresse SMTP) est rarement nécessaire au-delà d’une migration initiale. S’il n’est pas utilisé, le désactiver bloque une variante connue de SyncJacking.

Une variante du soft matching s’utilise pour cibler des comptes cloud non synchronisés (par exemple, un compte d’administrateur cloud créé directement dans Entra ID) en créant dans l’AD local un compte avec le même UPN.

6.4. Mesure 4 – Imposer la MFA partout

La MFA (authentification multifacteur) ne bloque pas la manipulation des comptes, mais elle bloque l’usage final que peut faire l’attaquant. Même si son mot de passe est synchronisé vers le compte cloud cible, il sera bloqué à l’étape de la MFA s’il ne dispose pas du facteur d’authentification de la victime.

  • Activer la MFA pour 100% des comptes synchronisés.
  • Prioriser les comptes à privilèges (Global Admins, Privileged Role Admins, etc.).
  • Utiliser une MFA forte (clés FIDO2, authentificator avec number matching) plutôt que SMS.
  • Mettre en place du Conditional Access pour exiger la MFA dans tous les scénarios à risque.

6.5. Mesure 5 – Auditer les permissions déléguées

La majorité des SyncJacking exploitables proviennent de permissions trop larges accordées historiquement. Un audit régulier est indispensable.

  • Lister tous les utilisateurs et groupes ayant des droits Write-All-Properties, GenericWrite ou Delete sur des comptes utilisateurs.
  • Examiner les délégations de contrôle (Delegation of Control) sur les OU.
  • Réviser les compositions des groupes sensibles, en particulier Account Operators.
  • Appliquer le principe du moindre privilège : un administrateur de support ne devrait pas pouvoir modifier les attributs de synchronisation.

6.6. Mesure 6 – Restreindre le groupe Account Operators

Les membres du groupe Account Operators peuvent, par défaut, gérer tous les comptes utilisateurs (création, modification, suppression). Cela inclut suffisamment de droits pour exécuter un SyncJacking. Ce groupe doit être vidé ou strictement contrôlé.

6.7. Mesure 7 – Durcir le serveur Entra Connect

Le serveur sur lequel tourne Entra Connect est un actif Tier 0 (équivalent en criticité à un contrôleur de domaine). Sa compromission équivaut à la compromission du tenant cloud.

  • Ne jamais installer Entra Connect sur un contrôleur de domaine.
  • Dédier un serveur, isolé, sans rôle additionnel.
  • Activer Credential Guard et Windows Defender Application Control.
  • Restreindre l’accès local Administrateur à un cercle minimal.
  • Appliquer le principe du moindre privilège au compte de service de synchronisation.
  • Surveiller toute connexion interactive sur ce serveur.

6.8. Mesure 8 – Monitorer la synchronisation

Utiliser Entra Connect Health pour surveiller :

  • Les erreurs de synchronisation inhabituelles.
  • Les modifications de masse d’attributs (notamment mS-DS-ConsistencyGuid et UPN).
  • Les suppressions de comptes suivies de nouvelles synchronisations.

Compléter ces logs par une intégration au SIEM de l’entreprise avec des règles de corrélation dédiées.

6.9. Mesure 9 – Vérifier la présence de l’application dédiée

Microsoft a déployé une application de première partie (first-party application) dédiée à la synchronisation : Microsoft Entra AD Synchronization Service, dont l’identifiant est :

6bf85cfa-ac8a-4be5-b5de-425a0d0dc016

Cette application doit être visible dans Enterprise Applications du portail Entra ID. Elle ne doit pas être modifiée ni supprimée. Sa présence est requise pour le bon fonctionnement de la synchronisation après le durcissement de mars 2026.

6.10. Mesure 10 – Préparer la procédure de récupération

Lorsque le durcissement Microsoft sera actif (mars 2026), toute tentative de remapping illégitime renverra l’erreur :

Hard match operation blocked due to security hardening. Review OnPremisesObjectIdentifier mapping.

Dans les rares cas de récupération légitime (fusion d’entités, migration complexe, restauration après incident), un administrateur peut nettoyer manuellement l’attribut OnPremisesObjectIdentifier via Microsoft Graph API :

POST https://graph.microsoft.com/beta/users/{UserId}?$select=onPremisesObjectIdentifier Body: { « onPremisesObjectIdentifier »: null }

Cette opération doit être strictement encadrée, journalisée, et n’être exécutée qu’après confirmation que la situation est légitime.

7. Le calendrier Microsoft 2025-2026

Microsoft a publié un calendrier de durcissement progressif qu’il convient d’anticiper.

Octobre 2022Découverte de SyncJacking par Semperis et signalement au MSRC.
Mai 2025MSRC confirme la vulnérabilité comme escalade de privilèges importante.
Fin 2025Annonce des protections « Entra Connect Security Hardening » par Microsoft.
Mars 2026Début du déploiement des protections de plateforme sur les tenants. Blocage des opérations de remapping non autorisées.
30 sept. 2026Date butoir : les versions d’Entra Connect antérieures à 2.5.79.0 cessent de fonctionner.

8. Plan d’action immédiat

Pour les organisations qui souhaitent agir dès maintenant, voici une feuille de route opérationnelle structurée en trois horizons.

8.1. Court terme (0-30 jours)

  • Identifier la version d’Entra Connect en production et planifier la mise à niveau.
  • Activer Entra Connect Health et vérifier la remontée des logs vers le SIEM.
  • Auditer les membres du groupe Account Operators et restreindre.
  • Cartographier les délégations de contrôle sur les OU contenant des comptes synchronisés.
  • Vérifier que la MFA est imposée sur tous les comptes Global Admin.

8.2. Moyen terme (1-3 mois)

  1. Migrer vers Entra Connect 2.5.79.0 ou supérieur en environnement de test puis en production.
  2. Désactiver le hard match takeover.
  3. Désactiver le soft matching si non utilisé.
  4. Étendre la MFA à 100% des utilisateurs synchronisés via Conditional Access.
  5. Mettre en place des règles de détection SIEM sur les patterns SyncJacking.
  6. Durcir le serveur hébergeant Entra Connect (Tier 0).

8.3. Long terme (3-12 mois)

  1. Mettre en place un outil ITDR (Identity Threat Detection and Response) – Microsoft Defender for Identity ou solution tierce.
  2. Automatiser l’audit récurrent des permissions sensibles sur les comptes AD.
  3. Réviser le modèle d’administration AD (Tier model) et le modèle d’administration Entra ID.
  4. Réduire le nombre de comptes synchronisés à privilèges (séparer les comptes cloud des comptes locaux pour les rôles sensibles).
  5. Exercice de Red Team incluant SyncJacking dans le scénario.
La cible à atteindre Un environnement où SyncJacking est techniquement bloqué (hardening Microsoft + désactivation hard/soft match takeover), où une tentative serait détectée par le monitoring, et où la MFA forte empêche dans tous les cas l’usage final du compte usurpé.

9. Glossaire

Active Directory (AD)Annuaire local Microsoft, installé sur des serveurs internes à l’entreprise.
Account OperatorsGroupe AD intégré qui peut gérer tous les comptes utilisateurs. Souvent à l’origine de privilèges trop larges.
Conditional AccessMécanisme d’Entra ID permettant d’imposer des conditions (MFA, conformité, géolocalisation) avant d’autoriser l’accès.
Entra Connect (anciennement Azure AD Connect)Outil Microsoft qui synchronise les annuaires AD local et Entra ID.
Entra ID (anciennement Azure AD)Annuaire cloud Microsoft. Gère les accès à Microsoft 365 et aux applications cloud.
Global AdministratorRôle Entra ID le plus puissant. Contrôle total sur le tenant.
Hard matchingMéthode de mise en correspondance des comptes AD/Entra ID basée sur le source anchor.
ImmutableIDReprésentation côté Entra ID du source anchor du compte AD local.
ITDRIdentity Threat Detection and Response. Catégorie d’outils dédiés à la détection des attaques sur l’identité.
MFAMulti-Factor Authentication. Authentification multifacteur exigeant un second élément en plus du mot de passe.
mS-DS-ConsistencyGuidAttribut AD utilisé par Entra Connect (versions récentes) comme source anchor.
MSRCMicrosoft Security Response Center. Équipe Microsoft en charge des vulnérabilités.
objectGUIDIdentifiant unique d’un objet AD local. Souvent utilisé comme source anchor.
Password Hash SyncMécanisme synchronisant le hash du mot de passe AD vers Entra ID. Activé par défaut.
Soft matchingMéthode de mise en correspondance basée sur des attributs mutables (UPN, SMTP).
Source anchor (ancre de source)Attribut unique reliant un compte AD à son équivalent Entra ID.
Tier 0Niveau de criticité maximal d’un asset (contrôleur de domaine, serveur ADCS, serveur Entra Connect).
UPNUser Principal Name. Identifiant de connexion type prenom.nom@societe.com.

10. Sources et pour aller plus loin

Avertissement Ce document est un support de vulgarisation. Il décrit le mécanisme général de SyncJacking et les mesures de protection génériques. La mise en oeuvre opérationnelle dans votre environnement doit être validée par vos équipes sécurité et identité, et adaptée à votre contexte (présence d’ADFS, multi-forêts, partenariats, etc.). Avant toute action sur un environnement de production, tester en pré-production.

Laisser un commentaire