Une évaluation de fournisseur ne se juge pas au nombre de questions posées, mais à la nature des réponses acceptées. Une affirmation commerciale n'est pas une preuve ; une documentation technique, une démonstration reproductible ou une clause contractuelle en sont. Voici une grille organisée par phase, avec pour chaque question la preuve à exiger et le signal d'alerte correspondant.
Phase 1 — Avant-vente : cadrer la revendication de sécurité
| Question | Preuve à exiger | Signal d'alerte |
|---|---|---|
| Votre méthode transmet-elle une valeur qu'un intermédiaire pourrait rejouer ? | description du protocole, schéma d'échange | réponse en termes de « chiffrement fort » sans réponse sur le rejeu |
| Sur quoi porte la preuve : la session ou l'action ? | démonstration sur une opération sensible | glissement vers la connexion seule |
| Quel est le parcours de secours par défaut ? | documentation d'exploitation | « c'est configurable » sans valeur par défaut assumée |
| Comment l'identité initiale est-elle établie ? | procédure d'enrôlement | renvoi systématique au client |
| Quels risques votre solution ne couvre-t-elle pas ? | liste explicite | affirmation qu'il n'y en a pas |
La dernière ligne est la plus discriminante de toute la grille. Un fournisseur capable de nommer spontanément ses angles morts — vol de session, compromission de l'appareil, parcours de récupération — travaille dans un cadre d'analyse de risque. Un fournisseur qui n'en voit aucun n'a pas conduit l'exercice, ou ne souhaite pas le partager.
Phase 2 — Preuve technique : la démonstration qui compte
Une démonstration commerciale montre un parcours nominal. Demandez plutôt à voir les cas défavorables :
- Le parcours de récupération complet, de la déclaration de perte à la reprise d'accès. C'est le parcours que l'attaquant utilisera.
- L'inscription d'un facteur supplémentaire depuis une session déjà ouverte. Quelle preuve est redemandée ?
- Le comportement en cas d'indisponibilité du service : échec ouvert ou fermé, et selon quelle règle.
- Une opération sensible en cours de session, pour observer ce qui est affiché à l'utilisateur et ce qui est journalisé.
- Le parcours sur mobile, souvent absent des démonstrations et pourtant majoritaire chez les utilisateurs.
- Un export de journaux réel, au format que votre SIEM devra ingérer.
Phase 3 — Données, juridiction et conformité
| Question | Preuve à exiger | Signal d'alerte |
|---|---|---|
| Quelles données personnelles sont traitées, et pour quelle finalité ? | registre de traitement, DPA | inventaire imprécis |
| Où sont hébergées les données, et sous quelle juridiction ? | contrat, localisation des centres de données | réponse à la région sans réponse à la juridiction |
| Des données biométriques sont-elles centralisées ? | architecture technique | stockage central de gabarits sans justification |
| Quels sous-traitants interviennent ? | liste contractuelle, procédure de notification | liste incomplète ou non contractualisée |
| Quelles certifications sont détenues, et dans quel périmètre ? | attestation avec périmètre et date | certification annoncée sans périmètre |
| Une qualification est-elle en cours ? | mention explicite de l'état d'avancement | présentation d'une démarche en cours comme acquise |
| Quelle durée de rétention des journaux est incluse ? | documentation contractuelle | rétention courte, extension facturée |
Deux points de vigilance. D'abord, la distinction entre certification obtenue et démarche en cours doit être posée noir sur blanc : une qualification en cours d'obtention est une information légitime, sa présentation comme acquise ne l'est pas. Ensuite, la localisation des données ne se confond pas avec la juridiction applicable : un hébergement en Europe opéré par une entité soumise à un droit extraterritorial ne répond pas à la même question.
Phase 4 — Exploitation, contrat et sortie
C'est la phase la moins glamour et la plus déterminante pour le coût réel.
- Réversibilité. Que récupérez-vous si vous partez, sous quel format, dans quel délai ? Faut-il réenrôler l'ensemble du parc ? La réponse détermine votre position dans toutes les renégociations futures.
- Niveau de service. Engagement de disponibilité, pénalités, procédure d'escalade, astreinte. L'authentification est un service dont l'indisponibilité bloque l'entreprise entière.
- Gestion des vulnérabilités. Politique de divulgation, délai de correction, tests d'intrusion réguliers et partage des synthèses.
- Notification d'incident. Délai contractuel d'information, cohérent avec vos propres obligations au titre de NIS2, de DORA ou du RGPD. Un délai fournisseur supérieur à votre délai réglementaire vous met mécaniquement en défaut.
- Trajectoire technique. Feuille de route post-quantique et agilité cryptographique. Sur des cycles de renouvellement longs, la question n'est pas « êtes-vous post-quantique ? » mais « comment change-t-on d'algorithme sans remplacer le parc ? ».
- Dépendances. De quels composants tiers le service dépend-il pour fonctionner, et que se passe-t-il si l'un d'eux devient indisponible ?
Signaux d'alerte et livrable attendu
Les huit signaux d'alerte
- La résistance au phishing est affirmée sans explication du mécanisme qui la produit.
- Aucun risque résiduel n'est reconnu.
- Le parcours de récupération est présenté comme un détail de configuration.
- Une certification est annoncée sans périmètre ni date, ou une démarche en cours est présentée comme achevée.
- Des chiffres de performance sont avancés sans méthode de mesure.
- L'intégration est annoncée comme « transparente » sans inventaire de vos parcours.
- La réversibilité n'est pas contractualisée.
- Les références citées ne peuvent être contactées.
Ce que la grille révèle en creux
Une évaluation bien conduite produit un livrable simple : un tableau des risques résiduels assumés, avec pour chacun la contre-mesure retenue et le responsable. C'est ce document, et non le comparatif de fonctionnalités, qui sera utile lors du prochain audit ou du prochain incident.
Sur le risque de manipulation de l'utilisateur — le seul qu'aucun facteur de possession ne traite — la question à poser devient : que se passe-t-il si l'utilisateur légitime réalise lui-même l'opération sous influence ? Les approches fondées sur une preuve d'intention humaine consciente répondent sur ce terrain précis ; les autres devront désigner une contre-mesure organisationnelle.
FAQ
Combien de fournisseurs consulter ?
Trois suffisent généralement, à condition qu'ils relèvent de catégories différentes plutôt que de la même famille de produits. Consulter cinq offres équivalentes apporte moins d'information que consulter trois approches distinctes.
Faut-il un proof of concept systématique ?
Sur tout périmètre significatif, oui, mais en le cadrant : deux ou trois parcours réels, dont la récupération de compte, avec des critères de succès écrits avant le démarrage. Un PoC sans critères préalables se conclut toujours par une impression favorable.
Comment vérifier une affirmation de résistance au phishing ?
Posez une question factuelle et unique : la réponse d'authentification est-elle liée au domaine et non rejouable ? Si une valeur peut être saisie sur une autre page et retransmise, l'affirmation ne tient pas, quel que soit le niveau de chiffrement invoqué.
Quel poids donner à la souveraineté dans la notation ?
Cela dépend de votre exposition réglementaire et de la sensibilité de vos données. Pour une entité soumise à NIS2 ou pour un acteur public, la juridiction applicable et la localisation sont des critères de décision, pas des préférences.
Aller plus loin : pilier : authentification cognitive · choisir une solution d'authentification · les postes de coût d'une solution MFA · souveraineté et authentification