Shareadesk — location d’espaces de travail entre particuliers
Projet entrepreneurial que j’ai cofondé, de novembre 2021 à septembre 2023, arrêté depuis. L’enjeu : faire tenir entre inconnus des règles d’argent et de confidentialité.
Secteur : immobilier
Période : novembre 2021 – septembre 2023
Rôle : cofondateur, conception et développement du système
Statut : service arrêté
Le contexte
Deux inconnus, un local, de l’argent. L’un prête un bureau chez lui ou dans ses locaux, l’autre vient y travailler une journée. La plateforme se tient entre les deux, et c’est elle qui doit répondre de ce qui se passe.
Ce cadre a une conséquence qui commande tout le reste : aucune des deux parties ne peut être supposée de bonne foi par le système. Non parce qu’elles seraient malveillantes — la très grande majorité ne l’est pas — mais parce qu’une plateforme qui ne fonctionne que si ses utilisateurs se comportent bien n’est pas une plateforme, c’est un pari. La question n’est jamais « comment vérifier ce qu’on nous envoie », elle est « qu’est-ce que nous refusons de recevoir ».
C’est pourquoi les trois décisions ci-dessous portent toutes sur ce que le serveur refuse d’envoyer ou d’accepter, et aucune sur ce que l’interface affiche. Une protection qui vit dans l’écran protège de l’utilisateur distrait ; elle ne protège de personne d’autre.
Le périmètre, dit précisément
Projet cofondé : je ne l’ai pas fondé seul, et l’écrire autrement serait faux. Ce que décrit cette fiche est la construction du système — conception et développement —, dont les dépôts établissent que j’en suis l’auteur, à l’exception des robots de mise à jour de dépendances.
Le produit et le développement commercial revenaient à mes associés. Je m’en tiens ici à ce dont je réponds.
Les décisions
N’envoyer que ce qui est public, plutôt que de filtrer ce qui ne l’est pas.
Une annonce contient l’adresse exacte du local, le nom complet de son propriétaire, ses coordonnées. Un visiteur qui n’a pas encore réservé n’a rien à savoir de tout cela — le quartier lui suffit pour décider.
L’option écartée était de filtrer champ par champ au moment de l’envoi : on prend l’objet complet, on retire ce qui ne doit pas sortir. Elle fonctionne, et elle échoue le jour où quelqu’un ajoute un champ à l’objet sans penser au filtre. Ce jour-là, rien ne casse et rien ne prévient : l’adresse part, simplement.
Le serveur compose donc une réponse publique à partir de rien, en n’y mettant que les champs qu’il a explicitement nommés. Ajouter un champ à l’annonce n’a plus aucun effet sur ce qui sort : pour qu’il sorte, il faut l’écrire dans la réponse publique, c’est-à-dire le décider.
Refuser de recevoir un prix, plutôt que de le vérifier.
Au moment du paiement, l’interface connaît le montant : elle vient de l’afficher. Le réflexe est de l’envoyer au serveur, qui le compare à celui de la base et refuse s’ils diffèrent.
Cette vérification marche. Elle a le défaut de faire du montant reçu une donnée légitime, qu’un développeur pressé pourra un jour utiliser « puisqu’elle est là ». La demande de paiement n’accepte donc pas de montant du tout : elle ne reçoit qu’un numéro de réservation, et le prix est relu en base.
Un prix qui passe par l’écran du client est falsifiable — pas difficilement, avec les outils que tout navigateur embarque. Plutôt que de le vérifier, on refuse de le recevoir : il n’y a alors plus rien à vérifier, donc plus rien à oublier de vérifier.
Ne rien envoyer qu’on aurait à cacher à l’affichage.
La tentation symétrique de la première décision : envoyer l’objet complet et masquer à l’écran ce qui ne doit pas se voir. C’est la faute la plus banale du métier, et la plus facile à commettre parce qu’elle produit exactement le bon résultat visuel.
Ce qui est envoyé au navigateur est lisible par qui le demande, quelle que soit la mise en forme. Une donnée masquée par le CSS est une donnée publiée.
La règle qui en découle tient en une phrase et vaut bien au-delà de ce projet : si l’on doit cacher quelque chose à l’affichage, c’est qu’il ne fallait pas l’envoyer.
Ce que ce projet n’a pas prouvé
Le service est arrêté, et il n’a jamais porté de charge importante. Les trois décisions ci-dessus sont solides en conception ; elles n’ont pas été éprouvées par des années d’exploitation, ni par le volume qui fait apparaître les défauts qu’aucune relecture ne voit. Je les présente pour ce qu’elles sont : des choix que je referais, pas des garanties validées par l’usage.
LE PRINCIPE DIRECTEUR
Une protection qui vit dans l’écran protège de l’utilisateur distrait. Ce qui compte se refuse au serveur, là où l’oubli n’a pas d’effet.
C’est le cas qui montre le plus directement ce que signifie déplacer une protection de l’écran vers le serveur. Si vos règles tiennent aujourd’hui parce que personne n’a essayé de les franchir, ce sont les garde-fous qui les rendent infranchissables.
Poser les garde-fous : code, déploiement, agents IA — 5 jours, 4 000 € HT
Nous utilisons des cookies uniquement pour le bon fonctionnement du site. Avec votre accord, nous activons aussi le module de prise de rendez-vous Calendly, qui dépose ses propres cookies. Vous pouvez changer d’avis à tout moment depuis le pied de page. En savoir plus
