Lorsque les tarifs de renouvellement de votre fournisseur d'identité montent en flèche : optez pour une solution sur site à un tiers du prix
Lorsque le prix de renouvellement de votre fournisseur d'identité explose : passer à une solution sur site pour un tiers du coût
Il y a un moment que beaucoup d'équipes informatiques reconnaîtront. L'avis de renouvellement de votre plateforme d'identité cloud arrive, et le nombre qu'il contient n'a aucun rapport avec ce que vous aviez signé il y a trois ans. Vous avez construit toute votre couche d'authentification sur ce service. Chaque VPN, chaque application SaaS, chaque connexion utilisateur y transite. Le fournisseur le sait, et chaque cycle de renouvellement a tendance à être plus élevé que le précédent : plus l'intégration est profonde, plus votre position de négociation est faible.
Une grande entreprise privée européenne exploitant des services numériques à haute disponibilité s'est retrouvée exactement dans cette situation avec Okta. Au moment du renouvellement, les prix avaient considérablement augmenté. L'équipe a fait ce que nous pensons que plus d'organisations devraient faire : au lieu de considérer l'augmentation comme un coût de fonctionnement, elle l'a traitée comme une date limite pour évaluer les alternatives.
Ils gèrent désormais l'intégralité de leur processus d'authentification sur OpenOTP, le serveur d'authentification RCDevs, entièrement déployé sur site. Okta a été désactivé. Cet article décrit le déroulement de cette transition, car l'objection la plus courante que nous entendons ne concerne ni les fonctionnalités ni le prix. Elle est la suivante : “ nous sommes trop engagés auprès de notre fournisseur actuel pour pouvoir le quitter ”. Ce cas suggère le contraire.
Un fournisseur d'identité cloud comme Okta peut-il être entièrement remplacé sur site ?
La réponse courte de ce projet : oui, y compris la fédération, le MFA et les intégrations d'applications qui rendent un environnement réel compliqué.
L'entreprise fonctionnait sur Microsoft Active Directory, avec plusieurs centaines d'utilisateurs s'authentifiant via Okta à un portefeuille d'environ 20 applications. Celles-ci allaient du SaaS moderne à l'infrastructure réseau : Office 365, le VPN Ivanti (anciennement Pulse Secure), Cisco Umbrella, ainsi que des plateformes de gestion des points de terminaison, de collaboration interne et de finance.
Cette combinaison est déterminante. Le remplacement d’un fournisseur d’identité (IdP) dans le cloud est rarement bloqué par les applications SaaS phares, qui prennent toutes en charge SAML ou OpenID Connect et peuvent être redirigées vers un nouveau fournisseur d’identité. Les difficultés se situent généralement au niveau de la couche réseau et de la multitude d’outils secondaires. Dans ce déploiement, RCDevs Federation Services a pris en charge les fédérations SAML et OIDC, tandis que le VPN était connecté via Pont RADIUS, le composant OpenOTP qui ajoute l'authentification forte aux équipements parlant RADIUS. Le client a conservé ses équipements VPN existants ; seule l'autorité d'authentification derrière ceux-ci a changé.
Les données d'identité n'ont été transférées à aucun cloud. Les comptes utilisateurs restent dans l'Active Directory de l'entreprise, qui demeure la source de vérité, et OpenOTP gère les deux facteurs d'authentification : à la connexion, il valide le mot de passe par rapport à l'AD lui-même, puis applique le second facteur (notification push, OTP ou FIDO2) selon les politiques définies. Ces politiques, ainsi que les utilisateurs et les intégrations, sont gérées dans WebADM, la console IAM centrale qui exécute et pilote tous les services de la suite, sur une infrastructure que le client possède.
Combien de temps prend réellement la migration depuis Okta ?
C'est la crainte de la migration elle-même qui pousse la plupart des entreprises à accepter des augmentations de prix lors du renouvellement, ce qu'elles trouvent injuste. Voici donc les chiffres réels de ce projet, calculés en heures d'ingénierie facturées et effectuées conjointement par le service d'assistance RCDevs et l'équipe informatique du client.
La preuve de concept a pris un peu plus de huit heures. La migration et le déploiement en production ont pris dix-neuf heures, plus rapidement que ce que nous avions prévu avec le client. Le transfert de l'authentification Office 365 a été traité comme une étape finale distincte et a pris trois heures supplémentaires.
Ces heures ont couvert la migration complète d'une infrastructure Okta existante vers une infrastructure OpenOTP existante, avec des applications déplacées par étapes plutôt qu'en une seule bascule.
L'approche par étapes a également signifié aucune interruption de service pour les utilisateurs pendant la migration. La seule exception concernait Office 365 : un changement de fédération doit y être répliqué sur l'infrastructure Azure de Microsoft avant d'être effectif partout, un délai de propagation qui appartient à Microsoft 365 plutôt qu'à l'IdP cible, et la raison pour laquelle cette charge de travail est arrivée en dernier.
L'équipe conjointe a géré le projet de bout en bout, de la première session de preuve de concept (POC) au déploiement final d'Office 365.
Trois éléments qui changent avec une solution IAM souveraine sur site : coût, contrôle, souveraineté
Pour cette entreprise, les changements correspondent directement aux trois raisons pour lesquelles les organisations européennes nous contactent au sujet de la sortie des plates-formes d'identité cloud américaines.
1. Coût : IAM trois fois moins cher, sans surcoût
En comparant la licence OpenOTP aux prix de renouvellement qu'Okta venait de proposer, le client a trouvé notre solution trois fois moins chère. D'une importance égale, le coût est stable et forfaitaire : une licence couvre la suite complète, et les fonctionnalités que les plateformes d'identité cloud facturent couramment comme des modules complémentaires séparés, telles que l'authentification multifacteur adaptative, les politiques d'accès conditionnel et l'intégration d'annuaires, sont incluses, tout comme le cluster haute disponibilité actif-actif. Le montant du prochain renouvellement est prévisible.
2. Contrôle : l'authentification ne dépend plus d'un service cloud externe
La plateforme d'identité fonctionne désormais entièrement en interne. L'authentification ne dépend pas de la disponibilité, de la feuille de route ou des décisions commerciales d'un service cloud externe. Pour un opérateur de services numériques à haute disponibilité, supprimer une dépendance tierce du chemin de connexion constitue en soi un gain de résilience.
3. Souveraineté : les données d'identité restent dans la juridiction du client
L'identité est l'un des ensembles de données les plus sensibles qu'une organisation détient : qui y travaille, à quoi il accède, quand et d'où. Avec un déploiement entièrement sur site d'un fournisseur européen, ces données ne quittent jamais la juridiction du client et échappent aux cadres extraterritoriaux tels que le CLOUD Act américain. Pour les entreprises européennes qui pèsent les obligations de la NIS2 et la dépendance vis-à-vis des fournisseurs, il s'agit de plus en plus d'une exigence plutôt que d'une préférence.
Subir la hausse au renouvellement n'est pas une fatalité
La leçon que ce client formulerait probablement mieux que nous : une augmentation de renouvellement est aussi une opportunité d'audit. Leur authentification actuelle fait tout ce qu'elle faisait auparavant, pour un tiers du coût, sur une infrastructure qui leur appartient, avec leur répertoire comme source unique de vérité. La dépendance qui a rendu l'augmentation de prix possible a disparu.
Si votre propre renouvellement approche et que les chiffres n'ont plus de sens, la migration est plus gérable qu'il n'y paraît. Nous serions heureux de vous en faire la démonstration sur votre environnement, comme nous l'avons fait ici, avant que vous ne vous engagiez quoi que ce soit.
Pour en savoir plus
- Comparaison des solutions IAM et MFA dans le cloud
- Fonctionnalités de la licence OpenOTP Security Suite
OpenOTP, développé par le fournisseur européen RCDevs, offre les mêmes fonctionnalités qu'un fournisseur d'identité dans le cloud (fédération SAML et OIDC, authentification multifactorielle, intégrations RADIUS), tout en fonctionnant entièrement sur l'infrastructure propre à l'organisation.
Dans ce projet, une trentaine d'heures de travail d'ingénierie ont été nécessaires au total : une preuve de concept d'un peu plus de huit heures, dix-neuf heures pour la migration en production, et trois de plus pour le basculement vers Office 365.
Aucun élément n'a été remplacé dans ce déploiement. Les applications SAML et OIDC ont été redirigées vers le nouveau fournisseur d'identité, et les appareils VPN existants ont continué à fonctionner avec l'authentification déplacée vers RADIUS Bridge.
Rien ne bouge. Active Directory reste la source de vérité : OpenOTP valide le mot de passe par rapport à l'AD à la connexion, puis applique le second facteur (push, OTP ou FIDO2) selon les politiques WebADM.
La loi CLOUD peut obliger les fournisseurs américains à remettre des données qu'ils hébergent, où qu'elles se trouvent. Les données d'identité détenues sur site par l'organisation elle-même, auprès d'un fournisseur européen, ne sont tout simplement pas dans ce champ d'application.
Il peut être fédéré à un IdP sur site comme d'autres applications SAML et OIDC. Dans ce projet, le passage de l'authentification Office 365 à OpenOTP a été géré comme une étape finale distincte et a pris trois heures.
