Un cahier des charges d'authentification se juge à une chose : la capacité d'un candidat à y répondre faussement sans être détecté. « La solution doit offrir une authentification forte » se valide par n'importe qui. « La réponse d'authentification doit être liée au domaine et inexploitable sur un autre domaine » ne se valide que par ceux qui le font. Voici une trame construite sur ce principe.
Le principe : exiger des propriétés, pas des étiquettes
Les termes du marché sont devenus des arguments commerciaux. « Anti-phishing », « Zero Trust », « passwordless » sont revendiqués par des offres dont les propriétés diffèrent radicalement.
La règle de rédaction est donc : chaque exigence doit être formulée de façon à ce que la réponse soit vérifiable par un test. Si vous ne pouvez pas imaginer le test qui prouve la réponse, l'exigence est décorative.
| Formulation faible | Formulation vérifiable |
|---|---|
| authentification forte | deux facteurs de catégories distinctes, dont un non rejouable |
| résistant au phishing | réponse liée à l'origine, inexploitable sur un autre domaine |
| passwordless | aucun secret mémorisé saisi par l'utilisateur sur aucun parcours |
| conforme RGPD | liste des données traitées, localisation, base légale, durée |
| souverain | juridiction de l'éditeur, du sous-traitant et de l'hébergeur |
| haute disponibilité | engagement chiffré, périmètre exclu, procédure de bascule |
Section 1 — Périmètre par parcours, jamais global
Le défaut le plus coûteux consiste à décrire un besoin global. Un dispositif adapté à la connexion courante ne l'est pas à la validation d'un virement, et l'inverse produit une friction qui sera contournée.
Structurez donc le besoin parcours par parcours, en indiquant pour chacun l'impact d'une compromission et l'exigence retenue. La grille de classement par niveau de risque est détaillée dans la méthode de choix par risque.
Incluez explicitement les parcours qu'on oublie : récupération de compte, enrôlement initial, réenrôlement après perte, accès des prestataires, comptes de secours.
Section 2 — Exigences fonctionnelles à formuler précisément
Les points suivants méritent une formulation propre, parce qu'ils départagent réellement les offres :
- Non-rejouabilité. Décrire ce qui circule entre le service et l'utilisateur, et démontrer qu'un interceptant complet ne peut rien réutiliser.
- Portée de la preuve. Préciser si la preuve porte sur l'ouverture de session ou sur l'action, et si le contexte de l'opération est affiché au moment de la validation.
- Gestion de session. Durée de vie, conditions de révocation, délai de prise d'effet, détection d'un usage depuis un contexte inhabituel.
- Parcours de secours. Niveau de preuve exigé, et interdiction explicite d'un secours plus faible que le facteur principal.
- Enrôlement. Modes proposés, et niveau de vérification d'identité initial.
- Intégration. Compatibilité avec l'IdP en place, possibilité d'un déploiement en surcouche sans refonte, protocoles pris en charge.
- Traçabilité. Contenu exact des journaux, format d'export, intégrité, durée de conservation.
Section 3 — Exigences que l'on oublie et qui coûtent cher
Ces clauses ne concernent pas la sécurité mais déterminent le coût réel du projet.
- Réversibilité. Que récupérez-vous si vous partez : les données d'enrôlement sont-elles exportables, ou faut-il réenrôler toute la population ? C'est souvent le vrai coût de sortie.
- Évolution des standards. Engagement sur la feuille de route post-quantique, et prise en charge des évolutions de protocole. Les cycles de renouvellement des infrastructures de clés sont longs.
- Chaîne de sous-traitance. Liste des sous-traitants, juridictions, et droit d'audit — exigence explicite de DORA et de NIS2 sur les tiers.
- Accès du fournisseur. Le support de l'éditeur peut-il agir sur vos comptes, avec quelle traçabilité, et pouvez-vous le désactiver ?
- Fin de vie. Durée d'engagement de maintien en sécurité des composants livrés, cohérente avec les attentes du Cyber Resilience Act pour les produits comportant des éléments numériques.
Section 4 — Ce qu'il faut demander de démontrer, et comment
Une soutenance vaut mieux qu'un questionnaire. Demandez une démonstration sur vos parcours, avec trois épreuves imposées :
- Faire valider une opération sensible et montrer ce que l'utilisateur voit exactement.
- Dérouler le parcours de perte d'appareil de bout en bout, sans le raccourcir.
- Produire, sur une opération réalisée pendant la démonstration, le dossier qu'on pourrait présenter six mois plus tard en cas de contestation.
La troisième épreuve est la plus discriminante et la moins demandée. Elle recoupe la question de la valeur probante des journaux.
Section 5 — Grille de notation : pondérer avant de recevoir les offres
Fixez et diffusez la pondération avant le dépouillement. Sans cela, la grille s'ajuste inconsciemment à l'offre qu'on préfère.
Une répartition défendable pour un contexte régulé : propriétés de sécurité vérifiables, capacité à prouver une action, intégration à l'existant, réversibilité et souveraineté, expérience utilisateur sur les parcours fréquents, coût complet sur la durée d'engagement. La question du chiffrage est traitée dans l'article sur les postes de coût.
Prévoyez enfin une clause d'écartement : toute réponse qui reprend une étiquette sans démontrer la propriété correspondante est notée zéro sur le critère. C'est la seule façon de rendre la trame opérante.
Ce que cette trame ne fait pas
Elle ne remplace ni une analyse de risque préalable — sans elle, vous ne savez pas quel niveau exiger par parcours — ni une évaluation juridique des clauses, qui relève de vos conseils.
FAQ
Faut-il imposer une technologie précise dans le cahier des charges ?
Non. Imposer une technologie ferme la porte à des réponses valables et vous rend responsable du choix technique. Exigez des propriétés vérifiables et laissez les candidats démontrer comment ils les tiennent.
Comment traiter les réponses qui affirment tout sans rien démontrer ?
C'est l'usage de la soutenance. Une affirmation non démontrée pendant l'épreuve imposée doit être traitée comme non satisfaite, ce qui suppose de l'avoir annoncé dans le règlement de la consultation.
Peut-on demander un test d'intrusion du fournisseur ?
Vous pouvez demander les résultats de tests indépendants récents et leur périmètre. Le périmètre compte plus que la conclusion : un rapport favorable sur un composant marginal ne dit rien du reste.
Comment intégrer la souveraineté sans écarter toute offre ?
En la traitant comme un critère documenté plutôt que comme un préalable : juridiction de l'éditeur et des sous-traitants, localisation des données, détention des clés, conditions de réversibilité. Vous obtenez alors une comparaison, pas un filtre binaire.
Aller plus loin : pilier : authentification cognitive · grille d'évaluation d'un fournisseur · choisir par le risque · tester sa MFA