La plupart des migrations logicielles échouent graduellement — une fuite lente qu'on repère en surveillance avant qu'elle ne devienne un incident. Un basculement de fédération n'a pas cette courtoisie. Dès que le nouveau fournisseur d'identité devient celui contre lequel tout le monde s'authentifie, chaque application qui lui fait confiance fonctionne ou ne fonctionne pas, pour chaque employé, au même moment. Il n'existe pas de déploiement canari pour « est-ce que toute l'entreprise peut se connecter ».
Le mode de défaillance qui mord réellement les équipes n'est pas le fournisseur d'identité lui-même — les fournisseurs testent ce chemin de façon obsessive, et l'écran de connexion fonctionne presque toujours en démonstration. C'est tout ce qui se trouve en aval de l'affirmation : une correspondance de revendications subtilement fausse pour la structure de groupe d'un département, un fournisseur de services qui attend un nom d'attribut envoyé par l'ancien fournisseur d'identité et que le nouveau n'envoie pas, une tâche de synchronisation qui n'a pas fini de répliquer les appartenances aux groupes quand les gens commencent leur journée. Rien de tout cela n'apparaît lors d'une connexion de test réussie par la personne qui a configuré le système, parce que son propre compte est habituellement le mieux approvisionné de tout l'annuaire.
La solution n'est pas de tester davantage le chemin heureux — c'est de faire fonctionner les deux systèmes en parallèle assez longtemps pour révéler les chemins malheureux. Gardez l'ancien fournisseur d'identité actif et faisant autorité pendant que le nouveau tourne à ses côtés, et ne déclarez pas le basculement terminé tant que des personnes extérieures à l'équipe de projet — idéalement quelqu'un d'un département que personne n'avait pensé à tester — ne se sont pas réellement connectées aux applications qu'elles utilisent au quotidien, pas seulement au tableau de bord du fournisseur d'identité. Cela signifie choisir une poignée de comptes réels dans différentes équipes, différents types d'appareils et différentes conditions réseau, puis observer chacun s'authentifier auprès de chaque application dans le périmètre, pas seulement les deux ou trois qu'il était pratique de tester en premier. Les projets qui tournent mal sont ceux qui traitent « le nouveau fournisseur d'identité a émis un jeton » comme la ligne d'arrivée plutôt que comme la mi-parcours.
L'autre élément qu'on oublie, c'est la sortie de secours. Tout basculement de fédération a besoin d'un chemin d'urgence qui ne dépend pas du système qu'on bascule — un compte administrateur d'urgence sur l'ancien fournisseur d'identité, ou un identifiant local qui contourne entièrement la fédération, testé avant la migration et non inventé pendant l'incident. Les équipes qui traitent cela comme une case à cocher plutôt que comme une procédure répétée sont celles qui réveillent tout le monde à 8 h un lundi parce que le plan de retour en arrière s'est avéré être un paragraphe dans un document que personne n'avait réellement essayé d'exécuter.
Rien de tout cela n'est vraiment un problème de fournisseur d'identité. C'est un problème de responsabilité — qui a l'autorité de donner le feu vert ou non, qui surveille réellement les taux de réussite de connexion durant la première heure, et à quelle vitesse le déclencheur de retour en arrière peut être actionné dès que quelqu'un remarque un problème. Un plan de basculement qui liste les étapes techniques mais pas la personne dont la main est sur le levier de retour en arrière n'est pas un plan, c'est un espoir. Réglez d'abord la question de la responsabilité, et la migration technique devient la partie facile — la majeure partie du travail d'ingénierie réel avait déjà été validée pendant la phase d'exécution en parallèle.
Un basculement de fédération n'est pas terminé quand le nouveau fournisseur émet son premier jeton réussi. Il est terminé quand quelqu'un qui n'a rien eu à voir avec la migration peut se connecter un lundi ordinaire, réseau capricieux inclus, sans appeler personne.