Application Pro (cles.app)

Où : l'application elle-même est un autre dépôt — une PWA installée sur cles.app, code dans arpara75/clesapp (en local : htdocs/clesapp). Darsy en tient le catalogue, les droits et l'encours.

Cette page a longtemps dit « hors du dépôt », ce qui se lisait comme « hors d'atteinte ». Le code est là, versionné, et les deux moitiés se modifient ensemble : une règle ajoutée côté Darsy demande souvent un écran côté application.

Dans l'ERP : Outils → Pro APP.

À quoi ça sert

Un serrurier professionnel a besoin de faire reproduire des clés. Il ouvre l'application sur son téléphone, choisit dans un catalogue qui lui est propre, dépose les justificatifs quand la clé est protégée, et valide.

Il ne paie pas tout de suite. La facture part immédiatement, l'argent arrive plus tard. C'est le cœur du fonctionnement, et ce qui demande de l'attention.

Qui a le droit d'y entrer

Un compte WordPress qui porte le rôle client_pro dans la boutique, et que quelqu'un a explicitement activé dans Darsy.

Un client_pro sans ligne dans Darsy n'est pas activé. L'activation est un geste, pas un effet de bord.

Le garde annonçait un contrôle de rôle et n'en faisait pas. Jusqu'au 20/09/2026, on pouvait poser des réglages Pro — plafond de crédit compris — sur n'importe quel compte WordPress, y compris un client de détail.

Le catalogue Pro

Ce n'est pas le catalogue de la boutique. C'est une liste à part, tenue dans Darsy, avec pour chaque clé ses règles propres.

Comment ça s'applique à une commande

D'abord le brevet. Une clé qui n'est pas brevetée ne demande que son numéro : l'application ne pose même pas la question de la carte, et ne réclame aucune pièce. Les cases de sa fiche ne sont pas lues.

Sur une clé brevetée :

Si le pro a la carte — il en envoie la photo, et rien d'autre n'est demandé. La photo, elle, est exigée : l'application refuse l'ajout au panier sans elle, et le serveur refuse la commande.

S'il ne l'a pas — le fabricant ne doit pas imposer la carte, sinon la commande est refusée : son code est propre au cylindre, et aucune pièce ne le remplace. Si la carte n'est pas imposée, le pro fournit chacune des pièces que le catalogue exige pour cette clé.

Répondre « oui, j'ai la carte » dispensait de tout. Cette réponse sautait le bloc entier des contrôles, la photo de la carte comprise : c'était le chemin le plus court pour commander une clé protégée sans fournir la moindre pièce. L'écran affichait bien « Photo de la carte », mais rien n'en exigeait le dépôt. Corrigé le 09/10/2026, des deux côtés.

Un justificatif inconnu, déjà rattaché à une autre commande, appartenant à un autre pro, ou purgé : la commande est refusée en le disant. L'ignorer laisserait le pro croire qu'il a fourni ses pièces, et la commande partirait sans elles.

Les justificatifs

Types acceptés : carte, pièce d'identité, justificatif de domicile, attestation. Formats : JPEG, PNG, WebP, PDF. Taille maximale : 12 Mo.

Vingt pièces en attente, pas plus

Le plafond ne porte que sur les pièces non rattachées. Une pièce se rattache à sa commande à la création, quelques minutes après le dépôt.

L'historique d'un pro, aussi long soit-il, ne l'empêche jamais de commander.

Elles sont sensibles, et elles se purgent

Ce sont des pièces d'identité. Elles s'effacent après 60 jours, à la main. Voir sécurité.

La commande Pro

Une commande WooCommerce, par l'API du plugin, avec :

• chaque ligne résolue vers un vrai produit de la boutique — un SKU qui ne se résout pas bloque la commande ;
• le prix HT du tarif pro ;
• le supplément carte manquante en ligne séparée ;
• le port offert ;
• les métadonnées de suivi du paiement différé.

Les prix sont HT, et WooCommerce ajoute la TVA

La boutique doit être réglée « prix hors taxes ». L'estimation du TTC — dont dépend le contrôle d'encours — applique le même taux, pour que le contrôle et la facture parlent du même chiffre.

Le statut, et pourquoi il est celui-là

La commande naît processing, non payée. WooCommerce émet la facture et l'e-mail ; l'encaissement est suivi séparément, dans le paiement différé.

Les plafonds de quantité

La quantité n'avait aucune borne haute. Un compte pro compromis pouvait commander cinq cents clés sur une seule ligne, en paiement différé, facture émise. Ces valeurs sont larges pour un reprographe de clés : elles arrêtent l'absurde, pas le gros client.

Les deux plafonds descendent avec le catalogue, et l'application les affiche : le « + » s'arrête à vingt, et le panier refuse la ligne qui ferait passer la commande au-dessus de cent. Ils ne sont pas recopiés dans l'application — c'est le serveur qui refuse, donc c'est lui qui dit où est la barre.

L'encours

Avant de créer une commande, Darsy regarde ce que le pro doit déjà.

déjà dû (factures pro non encaissées) + TTC estimé de la nouvelle commande
    ≤  plafond de crédit

Au-dessus, la commande est refusée, avec les trois chiffres.

Sans plafond renseigné, rien ne change

L'absence de valeur veut dire « pas de limite ». Poser une limite implicite couperait des clients qui n'ont jamais rien demandé.

Le plafond était stocké et n'était lu nulle part. L'écran laissait le saisir, la colonne existait depuis toujours, mais aucun chemin de code ne la consultait avant de créer une commande. Un pro plafonné à 500 € avec trois factures impayées continuait de commander.

Le pro le voit avant de commander

Depuis le 25/09/2026, l'écran d'accueil de l'application affiche ce que le pro doit, combien il lui reste, et où est la barre.

Le chiffre n'était affiché nulle part. Le pro composait son panier, saisissait ses numéros de clé, déposait ses justificatifs — et découvrait le refus en validant. Pour un modèle où la facture part à la commande et l'argent arrive en fin de mois, « combien puis-je encore commander » est la question qu'on se pose avant.

L'écran qui l'annonce et le contrôle qui refuse lisent le même code. Deux copies auraient fini par donner deux chiffres, et le pro aurait vu 340 € disponibles pour se faire refuser à 200 €.

Le panier se vérifie avant d'être validé

Le panier vit dans le téléphone du pro, et il vieillit. Trois choses y périssent, et aucune ne se voit de l'intérieur :

Et une quatrième que l'application ne peut pas deviner : l'encours, qui bouge à chaque facture réglée ou émise.

L'application soumet donc son panier au serveur sans rien créer, à l'ouverture du panier. Le serveur le passe dans le même constructeur que la création de commande : mêmes règles de justificatifs, même résolution de SKU, même contrôle d'encours. Rien n'est recopié, et une règle ajoutée plus tard vaudra là sans qu'on y pense.

Tant que le serveur n'a pas répondu, le bouton de validation attend. Mais un aller-retour raté ne bloque pas la commande : la création refait le même contrôle, et le refus tombera là. Bloquer sur un réseau instable empêcherait de commander sans rien protéger.

Se déconnecter déconnecte vraiment

Le jeton Pro vit huit heures et rien ne pouvait l'interrompre. « Se déconnecter » effaçait les cookies et s'arrêtait là. Sur l'application iOS, le jeton est aussi conservé par le client : un jeton récupéré continuait d'ouvrir la porte des heures après que son propriétaire ait cru fermer.

Il existe maintenant une liste de refus.

Le drapeau « bloqué » reste l'interrupteur de l'administrateur, vérifié à chaque requête, et il coupe toutes les sessions d'un pro d'un coup. Les deux répondent à deux questions différentes.

Et il y a maintenant un bouton pour s'en servir

La liste de refus existait, et rien ne l'appelait. La table, la route, la révocation par jeton : tout était construit — mais l'application n'offrait aucun moyen de se déconnecter. Une session de huit heures, sur un téléphone prêté ou une tablette d'atelier partagée, restait ouverte. Corrigé le 25/09/2026 : le bouton est en bas de l'écran d'accueil.

Le panier part avec la session. Il porte des numéros de clé et les identifiants des justificatifs déposés par ce pro : sur un appareil partagé, le suivant n'a rien à voir avec eux. Le trousseau reste — ce sont des références d'un catalogue que tous les pros voient.

Un réseau coupé n'empêche pas de sortir. Le serveur est prévenu d'abord, parce que c'est lui qui inscrit le refus ; s'il ne répond pas, le jeton local part quand même et expire de lui-même.

Ce qui protège le jeton dans le téléphone

L'application s'authentifie par jeton porteur, pas par cookie : cles.app et l'API sont sur deux domaines différents, et Safari bloque les cookies tiers. Le jeton est donc conservé par l'application — lisible par n'importe quel script qui parviendrait à s'exécuter dans la page.

La contrepartie, c'est qu'aucun script ne peut s'y exécuter : la Content-Security-Policy de l'application n'autorise que ses propres fichiers, sans unsafe-inline. Un script injecté, un onclick= glissé dans une donnée : refusés par le navigateur.

Cette contrepartie était annoncée et absente. Le commentaire du client HTTP désignait sa protection — « keep the app free of injected scripts » — mais rien ne l'appliquait. C'était une intention. Depuis le 25/09/2026, c'est une règle.

Ce qu'un <meta> ne peut pas porter : la protection contre l'encadrement de la page de connexion (frame-ancestors) demande un en-tête du serveur qui sert l'application. Elle n'est pas encore posée — voir le carnet de bord.