Votre espace arrive…
Votre espace arrive…
Dans les coulisses
Cette page explique les technologies et les mécanismes derrière Foundly, en essayant d’éviter le jargon inutile. Si un mot te paraît obscur, regarde le glossaire tout en bas : il est probablement dedans.
La grande image
Imagine un restaurant. Toi, à ta table, tu es le client : c’est ton navigateur, sur ton téléphone ou ton ordinateur. Tu passes commande (« montre-moi le catalogue de mon camp »). Cette commande part vers la cuisine, le serveur : un ordinateur, quelque part, qui reçoit ta demande, va chercher les bons ingrédients dans le garde-manger (la base de données) et te renvoie un plat déjà préparé : une page web prête à afficher.
Foundly fait ça pour chaque page : quand tu ouvres le catalogue d’un événement, le serveur va chercher les objets qui te concernent dans la base de données, vérifie que tu as le droit de les voir, puis construit la page que tu vois à l’écran.
Les briques du projet
Personne ne réécrit tout depuis zéro. Un projet moderne assemble des briques déjà solides, un peu comme des Lego, et n’invente que ce qui est vraiment spécifique au projet.
Next.js et React
Le frameworkReact sert à découper l’interface en petits morceaux réutilisables (un bouton, une carte d’objet). Next.js organise ces morceaux en pages et décide quel code s’exécute sur le serveur et lequel s’exécute dans le navigateur.
TypeScript
Le garde-fouUne version de JavaScript qui oblige à préciser le type de chaque donnée (un texte, un nombre, une date...). Ça évite plein d’erreurs bêtes avant même de lancer le code, un peu comme une relecture automatique.
Tailwind CSS
Le stylePlutôt que d’écrire des fichiers de style séparés, on colle des petites classes directement sur chaque élément (bg-teal-600 pour un fond vert, par exemple). C’est rapide et ça évite les styles orphelins qu’on oublie de supprimer.
Supabase
Le backendUn service qui regroupe trois choses dont une application a presque toujours besoin : une vraie base de données PostgreSQL, un système de connexion (Auth) et un espace pour stocker des fichiers (Storage, pour les photos).
Vercel
L’hébergeurL’endroit où le site tourne réellement. Chaque fois que du code est mis à jour, Vercel reconstruit et republie automatiquement une nouvelle version.
Brevo
L’envoi d’e-mailsLe service qui envoie réellement les e-mails d’invitation nominative. Supabase peut aussi envoyer des e-mails pour les liens de connexion, mais un service dédié est nécessaire pour envoyer beaucoup d’e-mails de façon fiable.
Comment on se connecte
Se connecter sans mot de passe peut sembler étrange, mais c’est en fait très sûr : Foundly propose trois façons d’entrer, qui aboutissent toutes à la même chose, une session stockée dans un cookie sécurisé sur ton appareil.
Le lien magique
Tu reçois un e-mail avec un lien à usage unique. Cliquer dessus prouve que tu as bien accès à cette boîte mail : c’est suffisant pour te faire confiance.
Tu délègues la vérification à Google, qui te connaît déjà. Foundly ne voit jamais ton mot de passe Google : juste la confirmation « oui, c’est bien cette personne ».
Le mot de passe
Optionnel, pour les habitué·es. Il n’est jamais stocké tel quel : seule une empreinte mathématiquement irréversible (un « hash ») est conservée.
La base de données et la sécurité
Foundly héberge plusieurs organisations et plusieurs événements dans la même base de données (on appelle ça une architecture « multi-tenant », multi-locataires). Le risque évident, c’est qu’une organisation voie par erreur les données d’une autre.
La base de données de Foundly (PostgreSQL) a une fonctionnalité qui s’appelle Row Level Security (« sécurité au niveau de la ligne », RLS). Imagine un videur posté devant chaque ligne de chaque table : avant de te laisser lire ou modifier quoi que ce soit, il vérifie ta carte d’identité (qui es-tu ?) et une règle précise (« es-tu membre de cet événement ? es-tu responsable ou simple participant·e ? »). Sans RLS, il faudrait faire confiance à chaque bout de code de l’application pour ne jamais se tromper. Avec RLS, même une erreur de programmation ne peut pas faire fuiter les données d’un autre événement : c’est la base de données elle-même qui refuse.
Les actions sensibles (créer une invitation, rejoindre un événement, réviser une revendication) passent par des fonctions écrites directement dans la base de données plutôt que dans le code de l’application. Ça évite qu’une personne malintentionnée puisse contourner les vérifications en appelant directement l’API.
Comment Foundly compare les objets
Le « Match Lab » peut donner l’impression d’être magique, mais c’est en réalité un calcul simple et entièrement transparent : chaque paire d’objets (un perdu, un retrouvé) de la même catégorie reçoit des points selon ce qu’ils ont en commun.
Le total donne un score sur 100, traduit en trois niveaux de confiance (à explorer, piste intéressante, forte ressemblance). Ce score sert uniquement de suggestion : ce sont toujours des humains, dans le Match Lab, qui décident si c’est vraiment le même objet.
Les photos
Une photo prise avec un téléphone peut peser plusieurs mégaoctets et contenir des informations cachées (le modèle de l’appareil, parfois même la localisation GPS exacte). Dès qu’une photo est envoyée, Foundly la traite automatiquement, côté serveur :
Le fichier original envoyé n’est jamais conservé. Le résultat est stocké dans un espace privé (« bucket »), et n’est jamais accessible par une simple adresse web publique : chaque affichage passe par une URL signée, un lien temporaire qui expire après une heure.
Comment on évite de casser le site
À chaque modification du code, une série de vérifications automatiques se déclenche avant que quoi que ce soit ne soit mis en ligne (on appelle ça de l’« intégration continue », CI) :
Le linter relit tout le code à la recherche d’erreurs de style ou de pièges classiques, sans même l’exécuter.
TypeScript vérifie que chaque donnée est utilisée avec le bon type, du début à la fin.
Des tests automatisés rejouent des scénarios précis (« le calcul de correspondance donne-t-il le bon score ? ») et comparent le résultat à ce qui est attendu.
Des tests de base de données vérifient spécifiquement que les règles de sécurité (RLS) empêchent bien ce qu’elles doivent empêcher.
Glossaire