Étiquettes, 2FA, NFC, biométrie — sécurité CRM Cycles

Imprimer des étiquettes prix sur une planche A4 et signer électroniquement une facture NF525 sont deux préoccupations qui n’ont rien à voir — sauf qu’elles partagent la même promesse : réduire le frottement quotidien sans rogner la sécurité. CRM Cycles regroupe dans ses derniers modules le système d’étiquettes (impression masse, formats Avery/Herma, imprimantes réseau) et la couche d’authentification renforcée (2FA via app authenticator, NFC, biométrie). Le but : que le commerçant puisse passer une journée entière à scanner, vendre, encaisser et imprimer sans saisir un mot de passe sept fois.

Étiquettes : impression masse avec position de départ

Étiqueter le stock prend en moyenne 1 à 2 heures par semaine dans un magasin de 5 000 références. Le système d’étiquettes de CRM Cycles est conçu pour minimiser cette friction.

Workflow d’impression en 4 étapes

Sélectionner un format (feuille A4 ou rouleau thermique) — ex. « Avery 38×21 — 39 étiquettes/feuille ».
Choisir la position de départ sur la grille interactive (formats feuille uniquement). Évite de gaspiller une planche A4 déjà partiellement utilisée : on clique sur la case où on veut que la première étiquette s’imprime.
Sélectionner les produits dans un tableau filtrable (marque, catégorie, stock, zone/emplacement, promo). Les sélections sont conservées quand on change de filtre — utile pour étiqueter « tous les VAE de marque Trek + tous les casques en promo » sans recommencer.
Définir les quantités (avec +/− et compteur total) puis générer le PDF. Si plus de 100 étiquettes, une confirmation s’affiche (sécurité contre les clics accidentels).

Spécificités :

Les produits en promotion impriment le prix promo, pas le prix catalogue. Plus de risque de coller la mauvaise étiquette en période de soldes.
Les codes-barres EAN s’impriment automatiquement quand ils sont configurés sur la fiche produit — utile à la caisse pour les pièces qui n’ont pas leur EAN visible sur l’emballage.

Formats d’étiquettes : gabarits Avery, Herma, rouleaux thermiques

Le module Formats d’étiquettes permet de configurer chaque gabarit physique utilisé — feuilles Avery L7160, Herma 4200, ou rouleaux thermiques pour les Zebra/Brother. Pour chaque format :

Type (planche A4 vs rouleau thermique)
Dimensions d’une étiquette (largeur × hauteur en mm)
Nombre d’étiquettes par rangée et par colonne (planches A4)
Espacement horizontal et vertical entre étiquettes
Marges haut/gauche de la planche
Dimensions de la feuille entière (généralement 210×297 mm pour l’A4)

Une fois un format configuré, il devient sélectionnable dans le workflow d’impression. Toggle actif/inactif pour retirer un format obsolète sans le supprimer (préserve l’historique des impressions passées).

Imprimantes réseau : bouton « Tester la connexion »

Le module Imprimantes liste les machines disponibles dans le magasin avec une imprimante par défaut (présélectionnée à l’impression). Un bouton Tester la connexion vérifie en un clic que l’imprimante est accessible sur le réseau — évite de découvrir le problème au moment où on a besoin d’imprimer 200 étiquettes. Toggle actif/inactif standard.

2FA Authenticator : protéger les actions sensibles

La 2FA (authentification à deux facteurs) protège les comptes contre le simple vol de mot de passe : même avec le login + password, un attaquant ne peut pas se connecter sans le code à 6 chiffres généré par une app authenticator (Google Authenticator, Authy, 1Password, Bitwarden).

Côté CRM Cycles, la 2FA passe par des endpoints standardisés /two-factor/* :

/two-factor/setup — page d’activation avec QR code à scanner dans l’app authenticator. Une seule étape, ~30 secondes.
/two-factor/verify — vérification du code à 6 chiffres au login.
/two-factor/download-codes — PDF de codes de secours à imprimer et garder coffre-fort (utile si l’utilisateur perd son téléphone).
/two-factor/history — historique des actions liées 2FA (activation, login réussi, échec, régénération).
/two-factor/disable et /two-factor/regenerate — gestion fine pour le manager.

L’algorithme est le TOTP standard (Time-based One-Time Password, RFC 6238) — compatible avec n’importe quelle app authenticator du marché. Le module est internationalisé (fr, en, de, es) pour les équipes multilingues.

Politique magasin : la 2FA peut être obligatoire pour les rôles managers / administrateurs (configurable). Un commercial standard peut l’activer volontairement.

NFC : badge pour login + déverrouillage rapide

Saisir un mot de passe 40 fois par jour à la caisse, c’est l’ennemi du commerçant. CRM Cycles supporte l’authentification par tag NFC (carte ou badge) — approche standard sur les caisses pro :

Un commercial passe son badge sur le lecteur NFC du poste de caisse
Le système identifie son utilisateur et déverrouille la session
Pas de mot de passe, pas de saisie clavier

Endpoints : /nfc/manage (gestion des cartes inscrites), /nfc/list (liste des cartes actives), /nfc/generate-auth-token (token éphémère 120 secondes pour pairer une nouvelle carte), /nfc/login-verify (vérifie qu’une carte présentée est connue et active).

Cas d’usage typique : dans une équipe de 3 vendeurs qui se relaient à la caisse, chacun a son badge. Le changement de session prend une seconde et chaque vente est attribuée au bon commercial (pour les rapports + objectifs, cf article pilotage).

Sécurité : chaque tag stocke un identifiant unique, croisé en base avec un utilisateur. Une carte perdue est désactivable instantanément côté admin (équivalent du blocage carte bleue). Le module est aussi internationalisé (fr, en, de, es).

Biométrie : app Flutter + Face ID / empreinte

Sur l’app commerciale Flutter (utilisée par les vendeurs en mobilité dans le showroom, cf article catalogue / Radar BLE), CRM Cycles supporte l’authentification biométrique native du device : Face ID / Touch ID sur iOS, empreinte digitale / Face Unlock sur Android.

Workflow :

Le vendeur se connecte une première fois avec login + password (+ 2FA si activée)
L’app génère un token biométrique sécurisé stocké dans le Secure Enclave du téléphone
Aux connexions suivantes, l’app demande l’authentification biométrique du device, échange le token contre une session active
Si le device détecte un changement biométrique (nouveau visage enregistré, empreinte différente), le token est invalidé automatiquement

Endpoints back-end : /biometric/manage, /biometric/list (tokens actifs), /biometric/status, /biometric/register, /biometric/authenticate, /biometric/revoke. La logique cryptographique (création du token, signature) se fait côté app ; le back-end vérifie la signature du token avec la clé publique enregistrée à l’inscription. Pas de « biometric image » stockée serveur : tout reste dans le Secure Enclave du téléphone.

Pour les actions sensibles (validation d’une facture en mobilité, acceptation d’une reprise occasion sur le terrain), une re-confirmation biométrique est demandée — équivalent du « step-up authentication ». Évite qu’un téléphone non-verrouillé entre les mains d’un client/visiteur déclenche une action non autorisée.

Sous le capot

Étiquettes : génération PDF via TCPDF. Le moteur place les étiquettes selon le format choisi avec calcul des coordonnées (x, y) pour chaque case, à partir des marges/espacements définis sur le format. Code-barres EAN-13 généré via la lib intégrée TCPDF.
2FA TOTP : implémenté avec spomky-labs/otphp, secret stocké chiffré en BDD (clé applicative dans .env). Validation côté serveur d’une fenêtre ±1 (i.e. accepte le code de la période précédente et la suivante pour gérer le décalage d’horloge). Codes de secours générés à l’activation, stockés hashés (bcrypt) — usage unique chacun, retirés au premier usage.
NFC : protocole d’auth en 2 étapes. (1) Génération d’un challenge éphémère côté serveur (token signé HMAC SHA-256, valable 120s). (2) La carte présente son UID, le serveur croise avec sa table NfcCard + utilisateur associé. Pas de cryptographie sur la carte elle-même — la sécurité repose sur la révocation rapide côté serveur en cas de perte.
Biométrie : l’app Flutter utilise local_auth pour l’API biométrique native + flutter_secure_storage pour le Secure Enclave. La paire de clés asymétriques (publique stockée serveur, privée dans Secure Enclave) signe les requêtes d’auth. Vérification serveur via openssl. Approche similaire à FIDO2/WebAuthn sur le principe, sans les standards complets.
i18n : fichiers messages/<locale>/security.php pour les strings. Couvre fr, en, de, es. Les pages 2FA/NFC/biométrie ont toutes été testées dans les 4 langues sans erreur JS (smoke tests _TESTS/8.x_*.md).
Permissions par rôle : two-factor.manage, nfc.manage, biometric.manage, label.print.select, printer.manage, format.manage. RBAC custom (modèles ROLE et PERMISSION) plutôt que RBAC natif Yii — plus souple pour les rôles dérivés (Manager, Vendeur, Vendeur-Technicien, Technicien…).

Ce qu’on gagne au quotidien

Étiquettes en 5 minutes pour 50 références : position de départ + sélection filtrée + génération PDF, plus de gaspillage de planches A4.
Caisse sans saisie de mot de passe : badge NFC pour le changement de session, chaque vente attribuée au bon vendeur sans frottement.
App mobile en biométrie : le commercial en showroom déverrouille avec son visage / empreinte, pas de mot de passe à taper sur un écran tactile sous le regard d’un client.
Compte admin protégé : la 2FA TOTP rend inutile un vol de mot de passe — même un phishing réussi ne donne pas accès au système.
Codes de secours imprimables : pas de blocage si un téléphone est perdu — l’admin peut se reconnecter avec un code papier, désactiver l’ancien device, en enregistrer un nouveau.

Cette série de 8 articles termine ici. Vous avez parcouru les principaux modules de CRM Cycles : pipeline de vente → atelier → clients → catalogue / BLE → reprises occasion → stock multi-magasins → pilotage et RH → sécurité. Si vous êtes vélociste et que la couverture vous parle, ou que vous voulez voir ce que CRM Cycles peut faire pour votre boutique, contactez-nous.