La sécurité n'est pas une option, c'est un prérequis.
Chaque compte, chaque jeton, chaque route API est pensé pour limiter au maximum ce qu'une erreur ou une attaque pourrait exposer.
Ce qui protège les comptes
Façon grands éditeurs
Après plusieurs échecs de connexion, le délai avant nouvelle tentative grimpe progressivement (1, 5, 10, 15, 20 min) avant suspension du compte.
Déverrouillage rapide, sans compromis
Un code personnel à 4 chiffres, hashé et jamais stocké en clair, avec option biométrique secondaire — plus rapide qu'un mot de passe complet à chaque ouverture.
Fini la clé API partagée
Chaque utilisateur reçoit un jeton personnel hashé côté serveur (30 jours), plutôt qu'une clé unique partagée par toute l'application.
Comment une faille a été trouvée et corrigée
Des clients ne pouvaient pas se connecter
Le problème semblait aléatoire au début — certains comptes fonctionnaient, d'autres non, sans logique apparente.
Une table d'authentification pour le mauvais public
L'app vérifiait une table de comptes conçue pour un tout autre logiciel interne, qui n'avait jamais contenu de comptes clients.
Reconstruction du modèle d'authentification
Le login a été entièrement réécrit pour s'appuyer directement sur les vrais comptes de l'intranet, avec propagation du changement partout où l'identité utilisateur était utilisée.
Ce qui est systématiquement vérifié
Jamais de secret en clair
Aucune clé API, mot de passe ou jeton n'est transmis par un canal non chiffré — toujours HTTPS, jamais de FTP simple pour des données sensibles.
Des messages qui ne fuitent rien
Une erreur d'authentification renvoie toujours le même message générique, sans jamais indiquer si c'est l'email ou le mot de passe qui est incorrect.
Mots de passe hashés, jamais en clair
Bcrypt côté serveur pour les comptes admin, hash SHA-256 pour les codes PIN côté appareil — aucun mot de passe n'est jamais lisible directement en base.
Cloisonnement strict par rôle
Un client ne peut techniquement pas accéder aux données d'un autre client, ni aux fonctions réservées aux comptes admin — vérifié côté serveur, jamais uniquement côté interface.
Questions fréquentes sur la sécurité
Les données sont-elles chiffrées au repos ? Les mots de passe et codes PIN sont hashés (jamais stockés en clair). Les autres données suivent les protections standards de l'hébergeur. Que se passe-t-il en cas de perte du téléphone ? Le jeton de session peut être révoqué côté serveur, et le code PIN local ne donne accès à rien sans une session valide déjà établie. Les audits de sécurité sont-ils faits en interne ou par un tiers ? En interne pour l'instant, avec une méthodologie inspirée des standards du secteur (OWASP) plutôt qu'un simple ressenti.