Brancher une API de vérification d’identité ou d’âge sur une plateforme en production prend rarement plus de quelques jours de développement. Ce qui dure, c’est tout le reste : l’arbitrage sur le mode d’intégration, la révision du parcours utilisateur, la mise à jour du registre de traitements et la validation juridique. Voici les quatre modes d’intégration disponibles, ce qu’ils coûtent réellement en charge d’équipe, et le plan de déploiement en cinq jours ouvrés que nous appliquons chez IDxLAB avec les éditeurs qui déploient GreenBadg.
Le choix ne se joue pas sur la difficulté technique, elle est comparable dans les quatre cas. Il se joue sur trois variables : le contrôle que vous gardez sur l’expérience utilisateur, la surface de données personnelles que votre système absorbe, et la charge de maintenance que vous acceptez pour les trois prochaines années.
Vous redirigez l’utilisateur vers une page de vérification opérée par le fournisseur, il revient sur votre service avec un jeton signé. Côté développement, c’est une URL à construire, un webhook à écouter et une signature à valider. Un développeur back-end sérieux le met en production dans la journée.
L’avantage réel n’est pas la vitesse : c’est que les documents d’identité, les selfies ou les données bancaires utilisées pour la vérification ne traversent jamais votre infrastructure. Votre analyse d’impact s’en trouve considérablement allégée. L’inconvénient est une rupture visuelle dans le tunnel, atténuable par un thème aux couleurs de votre marque.
La vérification se déroule dans un conteneur intégré à votre page. L’utilisateur ne quitte jamais votre domaine, la conversion en bénéficie sur les parcours d’inscription sensibles. Le développement reste léger, mais vous héritez de trois sujets : la politique de sécurité de contenu (CSP), le comportement sur navigateurs mobiles restrictifs, et la gestion des retours d’erreur dans votre propre interface. Comptez deux à trois jours en incluant les tests cross-browser.
Vous construisez intégralement l’interface, vous appelez l’API en REST depuis votre back-end. C’est le mode qui offre le contrôle maximal sur l’expérience et sur la donnée de sortie. C’est aussi celui qui vous rend responsable de la collecte : si votre serveur reçoit une pièce d’identité, même transitoirement, elle entre dans votre périmètre RGPD, votre plan de sauvegarde, vos journaux et votre analyse d’impact. Pour un éditeur de contenus soumis à la loi SREN du 21 mai 2024, ce choix mérite un arbitrage explicite entre la direction technique et le responsable conformité, pas une décision de sprint.
Le mode le plus élégant quand vous disposez déjà d’un CIAM ou d’un fournisseur d’identité. La vérification devient un claim transmis dans le jeton d’identité, par exemple une preuve de majorité booléenne, sans aucune autre donnée. Vous ne développez pas de parcours : vous déclarez un fournisseur supplémentaire dans votre broker d’identité, Keycloak, Auth0 ou équivalent. Une demi-journée de configuration, à condition que votre équipe maîtrise déjà OIDC. C’est l’option qui rend l’intégration réversible : changer de prestataire revient à changer une configuration, pas à réécrire du code métier.
Jour 1. Cadrage. Quels parcours sont concernés, quel niveau de preuve exigé, quelle durée de validité de l’attestation, que se passe-t-il en cas d’échec de vérification. Une heure d’atelier entre DSI, produit et conformité évite trois jours de reprise.
Jour 2. Intégration en environnement de recette avec les identifiants de test. Le jeton, le webhook, la validation de signature, l’idempotence des rappels.
Jour 3. Traitement des cas limites : abandon en cours de parcours, double soumission, rejeu, expiration du jeton, utilisateur qui change d’appareil en milieu de flux. C’est ici que se joue la qualité de l’intégration.
Jour 4. Conformité et observabilité. Mise à jour du registre de traitements, définition de ce que vous journalisez (un statut et un horodatage suffisent, jamais la donnée sous-jacente), politique de rétention, alerting sur le taux d’échec.
Jour 5. Déploiement progressif sur une fraction du trafic, puis généralisation. Gardez un interrupteur de contournement documenté : une dépendance externe dans un tunnel d’inscription doit toujours pouvoir être basculée en mode dégradé sans redéploiement.
Trois d’entre elles reviennent systématiquement. Stocker le résultat brut de la vérification plutôt qu’une attestation minimale : vous créez une base de données de pièces d’identité dont vous n’avez pas besoin, et qui devient votre principal risque en cas de fuite. Ne pas signer ni vérifier les webhooks : un rappel falsifié suffit alors à valider un compte. Enfin, câbler l’appel API en dur dans le code métier au lieu de passer par une couche d’abstraction : le jour où le référentiel technique de l’Arcom évolue ou que vous changez de prestataire, la reprise se compte en semaines.
La CNIL et l’Arcom convergent sur un même principe : le service qui vérifie l’identité ne doit pas savoir quel site l’utilisateur consulte, et le site ne doit rien apprendre de l’identité de l’utilisateur. C’est exactement l’architecture de GreenBadg, conçue par IDxLAB et déployée auprès d’éditeurs exigeants du secteur adulte comme le groupe Dorcel, ainsi que sur des cas d’usage phygitaux de contrôle d’accès.
Conséquence concrète pour un DSI : la donnée qui entre dans votre système est une attestation, pas une identité. Vous n’avez ni pièce d’identité à chiffrer, ni base biométrique à protéger, ni durée de conservation à négocier avec votre délégué à la protection des données. L’intégration se réduit à ce qu’elle devrait toujours être : vérifier une signature et lire un booléen. C’est aussi ce qui permet de tenir le délai d’une semaine sans dette technique ni dette juridique. Les équipes d’IDxLAB, ancrées dans l’écosystème French Tech Aix-Marseille, accompagnent ce cadrage sur idxlab.eu.
De quelques heures à trois jours de développement selon le mode retenu : une demi-journée en fédération OpenID Connect, une journée en redirection hébergée, deux à trois jours pour un composant embarqué ou une intégration serveur à serveur. Le calendrier global d’une semaine s’explique par le cadrage, les cas limites et la validation conformité, pas par le code.
Non, et c’est même contraire au principe de minimisation du RGPD dès lors qu’une attestation suffit. Conservez uniquement le statut de vérification, son horodatage et sa durée de validité. Toute donnée d’identité stockée devient une charge de sécurité et un risque en cas de fuite.
La vérification d’identité établit qui est la personne, la vérification d’âge établit seulement qu’elle dépasse un seuil, majorité ou 15 ans par exemple. Pour se conformer à la loi SREN, un éditeur n’a besoin que de la seconde. Exiger la première expose à une collecte disproportionnée.
Passez par une couche d’abstraction interne exposant une méthode unique du type « cet utilisateur dispose-t-il d’une attestation valide ». Privilégiez les modes standardisés comme OpenID Connect, où le changement de prestataire relève de la configuration. Documentez enfin un mode dégradé activable sans redéploiement.
Prévoyez une campagne de vérification progressive plutôt qu’un blocage immédiat : bandeau d’information, délai de mise en conformité, puis restriction d’accès aux contenus concernés. Le déploiement par paliers sur une fraction du trafic permet de mesurer le taux d’abandon avant la généralisation.
