PAM souverain : les vraies questions que personne ne pose avant de signer avec un acteur américain

# PAM souverain : les vraies questions que personne ne pose avant de signer avec un acteur américain

*En 2026, la gestion des accès privilégiés (PAM) est devenue un enjeu critique dans tous les SI européens. Pourtant, la majorité des PME et ETI signent encore avec des acteurs américains — souvent par réflexe, rarement par conviction. Nous avons interrogé un DSI d'une ETI industrielle française d'environ 800 collaborateurs, récemment passé à Heimlane après plusieurs années sous solution US. Il répond sans filtre.*

RiffLab : On va commencer par la question qui dérange. Changer de PAM en 2026, c'est un projet lourd. Beaucoup de DSI nous disent qu'ils n'ont « pas le temps ». C'est une vraie contrainte ou une façon de ne pas rouvrir le débat ?

Honnêtement ? Les deux. La migration d'un PAM, c'est toucher aux accès les plus sensibles du SI — comptes administrateurs, accès serveurs, connexions aux équipements industriels dans mon cas. Personne n'a envie de rouvrir ça un mardi matin. Mais quand j'entends « pas le temps », je traduis souvent par « on ne s'est pas posé les bonnes questions au moment du renouvellement de contrat ».

Ce qui m'a forcé à rouvrir le débat, c'est une clause contractuelle. Notre prestataire américain a modifié unilatéralement ses conditions de traitement des données de journalisation. Les logs d'activité des comptes privilégiés — qui accède à quoi, quand, depuis où — partaient désormais transiter sur des infrastructures hors UE pour une fonctionnalité d'analyse comportementale. On n'avait rien demandé. C'était opt-out, pas opt-in. Et le opt-out n'était pas trivial à activer.

À ce moment-là, le temps, on l'a trouvé.

RiffLab : Justement, sur la question des données de journalisation — est-ce que les équipes IT mesurent vraiment ce que contiennent ces logs ?

Rarement, et c'est un vrai angle mort. Un log PAM, ce n'est pas une entrée dans un fichier texte anodin. C'est la cartographie en temps réel de qui détient réellement le pouvoir dans votre SI. Quel administrateur a accès à quel système critique, à quelle fréquence, avec quelle durée de session. Si vous combinez ces données sur plusieurs mois, vous obtenez une modélisation précise des vulnérabilités humaines de votre infrastructure.

Ce que j'explique à mes équipes : ces logs ont plus de valeur pour un adversaire — ou pour un acteur soumis à une injonction légale étrangère — que n'importe quel mot de passe isolé. Et pendant des années, on les a stockés chez un acteur américain soumis au Cloud Act sans même en avoir conscience.

Avec Heimlane, la première chose que j'ai vérifiée, c'est où tournaient les instances et qui avait physiquement accès aux données de journalisation. Pas dans la brochure commerciale — dans le DPA et dans l'architecture technique réelle.

RiffLab : On rentre dans le concret. Au quotidien, pour un ingénieur système ou un administrateur réseau, qu'est-ce que ça change vraiment de passer sur un outil comme Heimlane ?

La première semaine, ça change la résistance au changement. Ne nous racontons pas d'histoires : quand vous dites à un admin qu'il va devoir passer par un coffre-fort pour accéder à un serveur qu'il atteignait en deux clics avant, il n'est pas ravi. C'est vrai avec n'importe quel PAM, quel que soit l'éditeur.

Mais ce qui m'a surpris positivement avec une solution plus récente comme Heimlane, c'est la granularité des politiques d'accès temporaires. On peut définir des fenêtres d'accès très précises — accès valide deux heures, sur ce périmètre, révocation automatique — sans que l'administrateur soit obligé d'ouvrir un ticket au helpdesk à chaque fois. Ça réduit la friction opérationnelle, ce qui est exactement ce dont vous avez besoin pour que la politique de sécurité soit réellement appliquée et pas contournée.

Ce que j'ai en revanche dû corriger : on avait tendance à reproduire les mauvaises habitudes héritées de l'ancienne solution. Des accès permanents accordés « provisoirement » il y a dix-huit mois. La migration force un audit réel des droits existants. C'est douloureux, mais c'est le seul moment où vous voyez vraiment l'état de votre SI.

RiffLab : Vous parlez de réduire la friction. Mais les solutions américaines dominantes ont des années d'intégration native avec Active Directory, avec les outils de ticketing, avec les SIEM. Comment vous gérez ce delta d'intégration ?

C'est la question légitime, et je ne vais pas vous répondre que tout est parfait. Il y a un delta d'intégration, et il serait malhonnête de le nier.

Ce que j'ai constaté : les connecteurs natifs avec notre stack existante étaient suffisants pour les cas d'usage critiques. Là où ça a demandé plus de travail, c'est sur des automatisations spécifiques qu'on avait construites par-dessus l'ancienne solution au fil des années — des scripts maison, des workflows un peu bricolés. Ces dépendances-là, vous ne les voyez pas dans les comparatifs produits. Vous les découvrez au moment de migrer.

Ma recommandation aux DSI qui regardent ce sujet : avant d'évaluer un PAM alternatif, faites d'abord l'inventaire de ce que vous avez réellement construit autour de votre solution actuelle. C'est souvent là que réside la vraie complexité de migration — pas dans la solution cible.

Et sur l'argument « des années d'intégration » avec les acteurs américains : oui. C'est précisément pour ça que le lock-in fonctionne. Ce n'est pas un argument en faveur du statu quo, c'est un argument pour commencer à travailler sur la réversibilité maintenant, pas dans trois ans.

RiffLab : Le sujet PAM reste souvent cantonné à la DSI et au RSSI. Est-ce que la direction générale de votre ETI comprend réellement les enjeux souverains dont vous parlez ?

Depuis le règlement DORA et les obligations de traçabilité qui s'appliquent désormais à des secteurs bien au-delà de la finance, le sujet remonte naturellement au COMEX. Pas parce que les dirigeants ont soudainement développé une conscience souverainiste — soyons honnêtes — mais parce que le risque juridique est devenu tangible.

Ce qui a fait basculer la conversation dans mon entreprise, ce n'est pas un discours sur la souveraineté numérique européenne. C'est quand j'ai posé la question : « Si demain un régulateur américain adresse une injonction à notre prestataire PAM, qui est informé en premier — vous ou moi ? » La réponse dans les CGU était claire : personne côté client n'est informé avant exécution dans un délai raisonnable. À ce moment-là, le sujet devient stratégique pour tout le monde autour de la table.

RiffLab : Dernière question, et elle est directe. Heimlane est une solution encore jeune. Est-ce qu'on ne prend pas un risque supplémentaire en misant sur un acteur européen de taille modeste plutôt que sur un acteur américain qui sera là dans vingt ans ?

C'est l'argument qu'on entend à chaque fois qu'on parle d'alternative européenne, et il mérite une réponse franche.

Oui, miser sur un acteur plus jeune comporte un risque de continuité. Ce risque existe et il doit être évalué sérieusement — plans de réversibilité, accès aux sources en cas de défaillance, engagements contractuels sur la portabilité des données. J'ai négocié ces clauses. Elles existent.

Mais je retourne la question : qu'est-ce que vous appelez « être là dans vingt ans » ? Un acteur américain racheté deux fois, dont les conditions contractuelles ont changé trois fois, dont le support Europe est externalisé au niveau n-2, et dont vous dépendez pour la visibilité totale sur les accès les plus critiques de votre infrastructure — c'est ça, la stabilité ?

Le vrai risque, ce n'est pas la taille de l'éditeur. C'est de construire une dépendance dont vous ne maîtrisez ni les conditions de sortie, ni la gouvernance des données, ni la juridiction applicable. Ça, j'ai arrêté d'appeler ça de la sécurité.

*Propos recueillis par la rédaction de RiffLab Media. L'interlocuteur a souhaité conserver l'anonymat.*