Gouvernance & direction

Ce qui fait échouer un projet d'authentification

Les projets échouent rarement sur la technologie. Cinq causes récurrentes, le signal précoce de chacune, et ce qu'un comité de pilotage devrait demander.

Un projet d'authentification échoue rarement parce que la solution ne fonctionne pas. Il échoue parce qu'il s'arrête à 70 % de la population, parce qu'il conserve un chemin faible qui annule son bénéfice, ou parce qu'il produit une friction que l'organisation finit par contourner officieusement.

Ces trois issues ont des causes identifiables, et chacune émet un signal avant d'être irréversible.

Cause 1 — L'enrôlement traité comme une formalité

Le mécanisme : la sécurité de la méthode retenue est étudiée en détail, et le moment où chaque utilisateur reçoit cette méthode est traité comme une tâche de déploiement. Or c'est là que le niveau réel se fixe. Une méthode forte obtenue par un chemin faible vaut ce chemin — le raisonnement est développé dans l'enrôlement comme plafond.

Le signal précoce : personne, dans l'équipe, ne peut décrire en une phrase la preuve exigée pour enrôler un nouvel appareil.

Cause 2 — Le parcours de secours laissé pour la fin

Le mécanisme : le chemin nominal est conçu, éprouvé, présenté. Le chemin de reprise est traité en fin de projet, sous contrainte de délai, et l'option la plus rapide est retenue — un code envoyé par courriel. L'ensemble du projet se retrouve alors plafonné par la sécurité d'une boîte mail.

Le signal précoce : le mot « secours » n'apparaît dans aucun document du projet avant la phase de recette.

Cause 3 — Les exceptions accordées une par une

Le mécanisme : chaque dérogation est défendable seule. Une population en mobilité, un métier avec des postes partagés, une filiale au système d'information distinct, un dirigeant pressé. Aucune n'est déraisonnable ; leur somme constitue le périmètre réel, que personne ne réexamine.

Le signal précoce : les dérogations sont accordées sans date de fin, et il n'existe pas de liste consolidée.

Cause 4 — Le support non associé à la conception

Le mécanisme : le support découvre le dispositif au démarrage. Il reçoit des demandes qu'il ne sait pas qualifier, et fait ce que fait un support compétent sous pression : il aide. La procédure de réinitialisation s'assouplit par la pratique, et devient le chemin le plus faible de la chaîne.

Le signal précoce : le volume de sollicitations attendu n'a pas été estimé, et aucun scénario de réinitialisation n'a été écrit avec les équipes concernées.

Cause 5 — Aucun critère d'arrêt

Le mécanisme : le projet avance parce qu'il a commencé. Aucun seuil ne déclenche de réexamen, aucune observation ne peut le remettre en cause. Quand un problème structurel apparaît, il n'existe aucune instance pour en tirer les conséquences, et il se traite en exception.

Le signal précoce : la note de cadrage ne contient aucune condition qui justifierait un arrêt ou un changement de solution.

Récapitulatif décisionnel

Cause Signal précoce Coût si elle n'est pas traitée
Enrôlement formalité preuve d'enrôlement non formulable niveau réel plafonné, invisible dans les indicateurs
Secours tardif absent des documents avant recette bénéfice du projet annulé
Exceptions cumulées dérogations sans échéance ni liste périmètre réel inconnu
Support non associé volume non estimé dérive de la procédure de reprise
Pas de critère d'arrêt note de cadrage sans condition décision par inertie

Les cinq signaux se vérifient en une réunion, sans audit et sans outil. C'est leur principal intérêt.

La cause commune

Ces cinq défauts partagent une origine : le projet est mandaté sur un déploiement, pas sur une propriété. On lui demande de couvrir une population, ce qui est mesurable et se pilote ; on ne lui demande pas de garantir qu'aucun chemin ne subsiste en dessous d'un plancher, ce qui est la seule question intéressante pour un attaquant.

Ce déplacement de mandat explique aussi pourquoi les indicateurs restent verts jusqu'au bout — le sujet est développé dans pourquoi le taux de couverture est un mauvais indicateur.

Trois questions pour un comité de pilotage

Elles tiennent en une page et se posent à chaque jalon.

  1. Quel est aujourd'hui le chemin le plus faible qui aboutit, sur chacun des parcours sensibles ?
  2. Combien de dérogations sont actives, et laquelle expire en premier ?
  3. Quel serait le délai de production d'un dossier de preuve sur une opération tirée au hasard ?

Un projet qui répond aux trois est piloté. Un projet qui répond au taux de couverture est suivi. Le format de restitution est traité dans présenter le risque à une direction.

Sur les opérations irréversibles, la question de fond reste la même : le dispositif sait-il établir qu'une opération a été voulue, et pas seulement qu'une session était ouverte ? C'est ce que cherche à établir le 4ᵉ facteur cognitif.

Ce que cette lecture ne couvre pas

Elle porte sur les causes internes. Elle ne traite pas les échecs dus au fournisseur — retard de feuille de route, fonction annoncée non livrée, rachat — qui relèvent de la solidité du contrat et de la réversibilité, examinées dans la trame d'appel d'offres.

Elle ne dit rien non plus des projets qui échouent pour une raison étrangère à l'authentification : arbitrage budgétaire, réorganisation, changement de priorité. Ces arrêts ne sont pas des échecs de conception, et les traiter comme tels conduit à corriger ce qui fonctionnait.

FAQ

Faut-il un plancher unique pour toute l'organisation ?

Un plancher par parcours est plus défendable qu'un plancher global : le niveau exigé pour consulter un annuaire interne et pour valider un virement n'a pas de raison d'être identique. Ce qui doit être unique, c'est la règle selon laquelle aucun chemin de reprise ne descend sous le plancher de son parcours.

Comment traiter les dérogations déjà accordées sans date de fin ?

En leur attribuant une échéance rétroactive, annoncée, avec un réexamen individuel. La difficulté n'est pas technique : elle consiste à accepter que certaines dérogations seront reconduites, et à l'écrire comme un risque assumé plutôt que de laisser l'ambiguïté.

À quel moment associer le support ?

À la conception des parcours, pas à la recette. C'est le support qui connaît les situations réelles d'échec, et son expertise vaut plus en amont, quand les parcours sont encore modifiables.

Un projet peut-il réussir sans traiter le parcours de secours ?

Il peut se terminer, être présenté comme réussi et se voir attribuer un indicateur satisfaisant. Il n'aura pas élevé le niveau de sécurité, ce qui apparaîtra au premier incident ou au premier audit sérieux.


Aller plus loin : pilier : authentification cognitive · où passe le temps d'un déploiement · cadrer un POC · auditer ses parcours de récupération

Demander une démonstration

Prouver l'intention, pas un secret

Découvrez le 4ᵉ facteur cognitif appliqué à vos parcours sensibles.

Demander une démonstration