Clavier numérique aléatoire : sécurité réelle ou impression de protection ?

Il nous est tous arrivé de croiser ce type d’interface : au moment de saisir un code confidentiel, le site n’affiche pas un simple champ de saisie, mais un pavé numérique à l’écran. Les chiffres sont mélangés. On ne tape rien au clavier. On clique sur les cases, souvent une par une, jusqu’à composer le code attendu.

L’effet est immédiat. L’interface semble plus sérieuse, plus contrôlée, plus sécurisée qu’un champ classique. Elle donne l’impression que quelque chose a été prévu pour éviter les regards indiscrets, les enregistreurs de touches ou les habitudes trop mécaniques. Et cette impression n’est pas complètement absurde : déplacer les chiffres, masquer la progression, empêcher la saisie directe au clavier peut effectivement réduire certains risques très simples.

Mais c’est justement là que le sujet devient intéressant.

Un clavier numérique aléatoire n’est pas une sécurité forte à lui seul. C’est d’abord une interface. Elle peut participer à une stratégie plus large, mais elle ne remplace ni une connexion HTTPS, ni une vérification côté serveur, ni une gestion correcte des sessions, ni une limitation des tentatives, ni les mécanismes de détection d’anomalies que l’on attend dans un système réellement sensible. Pour ces bases indispensables, vous pouvez vous référer à l’article « Protection de base pour un formulaire », qui détaille des mécanismes essentiels à mettre en place avant même de penser à ce type d’interface.

Dans le présent article, nous allons uniquement explorer ce mécanisme en mettant en place une version simple d’un clavier numérique aléatoire en HTML, CSS, JavaScript et PHP. L’idée n’est pas de proposer une solution prête pour la production, mais plutôt de disposer d’un exemple concret, Damier numérique aléatoire, sur lequel s’appuyer. À partir de là, nous pourrons observer son fonctionnement, comprendre ce qu’il apporte réellement, ce qu’il ne couvre pas, et pourquoi une interface qui semble rassurante ne doit pas être confondue avec une sécurité complète.

Comprendre ce que fait réellement ce type de clavier

Avant de plonger dans le code, prenons un moment pour clarifier le rôle réel de ce composant. Un clavier numérique aléatoire est avant tout une interface. Il modifie la manière dont l’utilisateur saisit son code, mais il ne change pas fondamentalement la nature de l’information transmise. Le code existe toujours, il est simplement sélectionné autrement.

Ce type de dispositif peut réduire certains risques très simples, mais il ne protège pas contre des attaques plus structurées. Pour comprendre pourquoi, il faut regarder au-delà de l’apparence et s’intéresser à la circulation des données entre le navigateur et le serveur.

Une interface qui rassure, mais qui ne suffit pas

Sur le web, ce que nous voyons à l’écran n’est qu’une partie du système. Une interface peut rassurer, limiter certains risques, sans pour autant constituer une véritable sécurité. Tout dépend de ce qui se passe autour : la transmission des données, la vérification côté serveur, la gestion des tentatives et des sessions.

Construire une version minimale pour comprendre

Pour ne pas rester dans l’abstrait, nous allons construire une version minimale du composant à partir d’un petit exemple, puis en analyser les limites. Le code complet est présenté dans des fichiers séparés afin de garder l’article lisible. Les commentaires intégrés dans chaque fichier accompagnent la lecture étape par étape : structure HTML, mise en forme CSS, génération du clavier en JavaScript, puis vérification côté serveur en PHP. L’objectif n’est pas de recopier un composant prêt pour la production, mais de comprendre où se situe chaque responsabilité dans le processus.

• pave_01.html pose la structure de la page. On y trouve le titre, une aide courte, une zone de progression, un emplacement destiné au clavier numérique, deux boutons d’action et un message de retour après vérification.
• style.css donne au composant une forme lisible : une largeur raisonnable, un affichage en grille, des boutons suffisamment grands et une progression représentée par des points.
• app.js génère le clavier côté navigateur. Il mélange les chiffres, crée les boutons, mémorise les clics, met à jour l’affichage de la progression et envoie la saisie au serveur lorsque quatre chiffres ont été sélectionnés.
• verify.php reçoit le code saisi et le vérifie côté serveur dans un cadre volontairement simplifié. Il ajoute aussi quelques protections élémentaires pour l’exemple : une session, un compteur de tentatives, une temporisation et un blocage temporaire après plusieurs erreurs.

Ce découpage est important. Il nous permet de voir le rôle de chaque couche sans tout mélanger. Le HTML décrit l’interface. Le CSS la rend utilisable. Le JavaScript crée l’interaction. Le PHP prend la décision finale.

Pour tester l’exemple sans recopier chaque bloc de code, une archive ZIP regroupe les quatre fichiers commentés. Elle permet de retrouver la structure HTML, la mise en forme CSS, la génération du clavier en JavaScript et la vérification côté serveur en PHP, Télécharger les fichiers commentés.

Dans une vraie application, cette séparation reste essentielle. Le navigateur peut aider l’utilisateur à saisir une information, mais il ne doit pas être considéré comme un espace de confiance. Tout ce qui arrive du client doit être vérifié côté serveur. Le serveur ne doit pas croire une saisie simplement parce que l’interface semblait bien construite.

Notre exemple est donc volontairement limité. Il ne prétend pas représenter le fonctionnement réel d’une banque ou d’un service sensible. Il sert à poser un terrain d’observation : un composant simple, assez réaliste pour être parlant, mais assez court pour que nous puissions en comprendre les limites.

À partir de là, on peut regarder les choses de plus près. Une fois le clavier en place, quelques questions simples s’imposent : qu’est-ce qui est vraiment caché ? qu’est-ce qui est juste déplacé ailleurs ? qu’est-ce qui reste accessible dans le navigateur ? et surtout, à quel moment peut-on parler de sécurité réelle ?

Pourquoi cela paraît plus sûr

Ce type de clavier donne rapidement une impression de protection. Le code n’est pas tapé au clavier, les chiffres changent de place, et la saisie n’apparaît pas dans un champ classique. L’interface semble donc éviter les gestes trop visibles ou trop faciles à enregistrer.

Cette impression n’est pas entièrement trompeuse. Dans certains cas simples, le clavier aléatoire peut réduire l’intérêt d’un enregistreur de frappe basique ou empêcher de retenir une position fixe à l’écran. Il ajoute une petite distance entre le geste de l’utilisateur et le code saisi.

Mais cette protection reste limitée. Le navigateur doit toujours connaître, d’une manière ou d’une autre, quel chiffre correspond à chaque bouton. Le code n’est donc pas rendu secret par l’interface : il est seulement saisi autrement.

C’est cette nuance qui nous intéresse. Le clavier peut réduire quelques risques simples, mais il ne transforme pas l’interface en mécanisme de sécurité fort.

Ce que le clavier protège un peu

Un clavier numérique aléatoire peut avoir un intérêt dans des scénarios très précis. Si un logiciel se contente d’enregistrer les touches frappées au clavier, il ne récupérera pas directement le code, puisque l’utilisateur clique sur des boutons à l’écran. Le mélange des chiffres peut aussi limiter une observation trop mécanique. Si le chiffre 1 n’est pas toujours au même endroit, il devient moins utile de retenir uniquement une suite de positions.

Enfin, l’affichage par points évite que le code apparaisse en clair dans un champ visible. Cela ne le rend pas invisible pour le système, mais cela limite au moins son exposition immédiate à l’écran.

Ces apports existent, mais ils restent modestes. Ils concernent des risques simples, pas une attaque structurée ni un environnement compromis.

Ce qu’il ne protège pas

Le clavier aléatoire atteint vite ses limites dès que l’on sort des scénarios les plus simples.

Il ne protège pas contre l’inspection du code JavaScript. Si la logique du clavier est envoyée au navigateur, elle peut être lue, étudiée, modifiée ou rejouée. Il ne protège pas non plus contre l’inspection du DOM : les boutons, leurs valeurs, leurs attributs ou leur organisation peuvent être observés avec les outils de développement du navigateur.

Il ne protège pas davantage contre l’observation de l’écran. Une personne placée à proximité, une capture vidéo, un partage d’écran ou un logiciel malveillant peuvent suivre les clics. Le fait que les chiffres changent de place complique un peu l’observation, mais ne la rend pas impossible.

Plus largement, ce type d’interface ne protège pas une machine compromise. Si le navigateur, une extension ou la page elle-même est contrôlée par un script malveillant, le clavier aléatoire ne suffit plus. Le problème n’est alors plus la disposition des chiffres, mais la confiance que l’on peut accorder à l’environnement dans lequel la saisie a lieu.

Enfin, il ne protège rien si le serveur vérifie mal la saisie, si les tentatives ne sont pas limitées, si les sessions sont mal gérées ou si les échanges ne passent pas par HTTPS. Dans ce cas, l’interface peut sembler sérieuse, mais la sécurité réelle reste fragile.

Le faux secret côté navigateur

On pourrait imaginer une variante plus subtile. Au lieu de placer directement les chiffres dans les boutons, le serveur enverrait une table temporaire : telle case correspond à tel chiffre, tel identifiant correspond à telle valeur, telle position doit être interprétée d’une certaine manière.

L’idée semble plus robuste, mais elle rencontre une limite classique du web : pour que le navigateur affiche le clavier et transmette une saisie exploitable, il doit recevoir une partie de la logique ou des correspondances nécessaires. Il suffit d’ouvrir les outils de développement du navigateur pour voir cette limite. La console permet de lister les boutons générés et la valeur associée à chacun :

[...document.querySelectorAll('.pin-pad button')] 
    .map((button, index) => ({
      case: index + 1,
      texteVisible: button.textContent, 
      valeurEnvoyee: button.dataset.value 
  }))

[...document.querySelectorAll('.pin-pad button')] 
    .map((button, index) => ({
      case: index + 1,
      texteVisible: button.textContent, 
      valeurEnvoyee: button.dataset.value 
  }))

Si cette information sert côté client, elle devient observable ou déductible. Elle peut être moins évidente à lire qu’un simple chiffre dans un bouton, mais elle n’est pas réellement secrète. Elle circule dans un environnement que l’utilisateur, le navigateur ou un script peuvent inspecter. Après quelques clics, la saisie en cours peut également être consultée :

Et lorsque les quatre chiffres sont envoyés, l’onglet réseau du navigateur affiche la requête vers verify.php, avec un corps JSON contenant le code transmis.

Ce constat ne signifie pas que la requête circule en clair sur le réseau lorsque le site utilise HTTPS. Il montre autre chose : dans le navigateur, l’information doit exister pour que l’interface fonctionne. Elle peut être masquée à l’écran, mais elle n’est pas secrète pour le client.

On peut donc compliquer la lecture, mais pas créer un vrai secret dans le navigateur. La formule à retenir est simple : un secret transmis au client n’est plus vraiment un secret.

Le vrai rôle du serveur

Dans notre exemple, le serveur reçoit la saisie et décide si elle est valide. C’est un point essentiel : le navigateur collecte une action, mais il ne doit pas prendre la décision finale.

Même avec un clavier aléatoire, tout ce qui arrive du client doit être considéré comme une donnée à vérifier. Le serveur doit contrôler le format reçu, comparer la valeur attendue, compter les tentatives, temporiser les erreurs et bloquer temporairement les essais trop nombreux.

Notre fichier PHP reste volontairement simple. Il sert à montrer le principe, pas à fournir un système d’authentification complet. Dans une vraie application, le code ne serait pas écrit en clair dans un fichier, les messages ne révéleraient aucune information inutile, et la vérification s’inscrirait dans une gestion plus large des comptes, des sessions et des journaux d’activité.

C’est ici que la différence devient nette. Le clavier appartient à l’interface. La sécurité commence réellement lorsque le serveur applique des règles strictes, cohérentes et difficiles à contourner.

Pourquoi certaines banques l’utilisent quand même

On peut alors se poser une question légitime : si ce clavier ne suffit pas, pourquoi le rencontre-t-on parfois dans des interfaces bancaires ou sensibles ?

La réponse tient surtout au contexte. Une banque ne repose pas sur ce seul composant. Le clavier aléatoire peut être une petite mesure parmi d’autres : HTTPS, sessions courtes, limitation des tentatives, détection d’anomalies, authentification forte, application mobile, validation côté serveur, surveillance des connexions, procédures de blocage.

Dans cet ensemble, le clavier peut réduire quelques risques périphériques. Il peut aussi participer à une expérience de connexion plus encadrée. Mais il ne porte pas la sécurité à lui seul.

C’est une distinction importante. Une mesure faible n’est pas forcément inutile lorsqu’elle est intégrée à un dispositif plus complet. Elle devient problématique lorsqu’elle est présentée comme une protection suffisante.

Interface rassurante, sécurité réelle

Le clavier numérique aléatoire n’est donc ni une solution miracle, ni un simple décor inutile. Il se situe entre les deux.

Il peut réduire certains risques simples : la frappe clavier enregistrée, la mémorisation d’une position fixe, l’affichage direct du code à l’écran. Mais il ne protège pas contre l’inspection du navigateur, les scripts injectés, les machines compromises, les faiblesses serveur ou les échanges mal sécurisés.

La vraie leçon est ailleurs. Une interface peut donner une impression de sécurité sans garantir une protection forte. Pour évaluer un dispositif, nous devons donc regarder ce qui se passe derrière l’écran : comment les données circulent, où la décision est prise, quelles limites sont imposées, comment les sessions sont protégées, et comment le système réagit face aux erreurs ou aux attaques.

Développer ce type de composant peut être un bon exercice. Il nous oblige à distinguer l’expérience utilisateur, la logique côté navigateur et la vérification serveur. Il nous rappelle surtout qu’en sécurité, ce qui rassure visuellement ne suffit jamais. Ce qui compte, c’est l’ensemble du dispositif.