Comment nous garantissons des REX légitimes sans équipe de modération
Miser sur l'identité vérifiée plutôt que sur la censure, protéger ceux qui témoignent : notre approche, les deux bugs qui nous ont fait douter, et ce qu'on en a tiré.
BlackMesa
26/09/2026
Contexte et enjeux
Show me the REX est un portail de retours d'expérience Tech, data et IA. Notre valeur tient à une seule chose : la confiance dans ce qui est publié. Un seul faux retour, un spam ou un contenu illégitime, et c'est la crédibilité de tout le corpus qui vacille.
Deux questions, en réalité — et la seconde est rarement posée : comment garantir la légitimité de chaque REX, à l'échelle, sans monter une équipe de modération ; et comment publier sans jamais exposer celui qui témoigne, ni le client dont il parle ?
Déroulement du Projet
Le défi : deux impasses
La modération manuelle ne passe pas à l'échelle : coûteuse, subjective, et elle ajoute un délai entre l'envie de publier et la mise en ligne. Confier le tri à une IA ne règle rien de fond : un modèle juge la forme d'un texte, pas la légitimité de celui qui le publie — il ne dit pas si l'entreprise existe vraiment.
Notre démarche : quatre barrières à la publication
Nous avons remplacé la modération de contenu par la vérification de l'émetteur, via quatre garde-fous :
- Pas d'entreprise, pas de REX — c'est la barrière la plus dure, et la première. Un simple visiteur ne peut rien publier : la création d'un REX exige un rattachement à une entreprise, et la publication le revérifie, côté serveur, à chaque fois. Un compte jetable ouvert en trente secondes avec une adresse e-mail temporaire n'a littéralement aucun chemin vers la mise en ligne — il n'a même pas accès au formulaire. Et un REX appartient à son entreprise : personne ne publie celui d'une autre.
- Substance minimale — un titre et un corps réels sont exigés (impossible de publier une coquille vide).
- Identité vérifiée — le numéro de TVA intracommunautaire de l'entreprise est validé auprès de VIES, le registre officiel de l'UE. Une entreprise réelle, qui publie sous son identité, ne saborde pas sa réputation avec un faux REX.
- Traçabilité — chaque REX est rattaché à un auteur et une entreprise ; chaque action sensible est consignée dans un journal d'audit.
Protéger le client, et le client du client
Un REX raconte un projet réel : il nomme une entreprise, souvent son propre client, parfois des chiffres qu'on ne publie pas à la légère. Vérifier l'émetteur ne suffit donc pas — encore faut-il que publier ne coûte rien à personne.
- REX privé sur invitation — l'auteur peut n'exposer publiquement qu'un teaser : le contenu n'est lisible que par lui, par les adresses e-mail qu'il a invitées (une fois connectées), et par un administrateur pour le support. Partout ailleurs — listings, recherche, page publique — le REX est réduit au teaser et à un cadenas. Un client qui ne peut pas tout dire publiquement peut quand même témoigner.
- Dépublication immédiate — un clic et le REX sort du site, mise en avant comprise. Le client garde la main sur sa parole, sans passer par nous ni attendre qui que ce soit.
- Lecteurs jamais nominatifs — un client voit quelles entreprises ont consulté ses REX, jamais quelle personne. Nos propres administrateurs et les consultations internes à l'entreprise sont exclus du décompte.
- Traces minimales — IP et user-agent ne sont jamais stockés en clair, seulement sous forme d'empreinte SHA-256, le temps de distinguer deux visiteurs. Un visiteur anonyme n'ouvre même pas de session serveur.
- Contenu assaini à l'écriture — le HTML sortant de l'éditeur est nettoyé à l'enregistrement, puis de nouveau à l'affichage : le REX d'un client ne peut pas devenir le vecteur d'attaque d'un autre.
Le piège qu'on n'avait pas vu venir
En branchant VIES, un vrai numéro de TVA — celui d'une entreprise bien réelle — s'est affiché « invalide ». Notre garde-fou accusait un client honnête.
La cause : quand le service européen est saturé, VIES répond HTTP 200 avec isValid: false et un code d'erreur (MS_MAX_CONCURRENT_REQ). Notre code lisait le booléen et concluait « invalide », alors que VIES disait en réalité « je n'ai pas pu vérifier ». Correctif : ne faire confiance qu'à un verdict explicite (VALID / INVALID), retenter une fois sur erreur transitoire, et traiter tout le reste comme « inconnu » — sans jamais bloquer un utilisateur pour une panne qui n'est pas la sienne.
Le même piège, une seconde fois
Quelques mois plus tard, en auditant notre propre promesse, on a tapé 0 dans le champ TVA. Le REX est parti en ligne.
Notre règle bloquait un numéro manquant ou explicitement invalide, et laissait passer tout le reste sous l'étiquette « inconnu ». Or « inconnu » recouvrait deux situations que rien ne distinguait : « VIES n'a pas pu vérifier maintenant » — temporaire, il faut être tolérant — et « VIES ne pourra jamais vérifier cette chaîne » — définitif, il faut refuser. BANANA, un numéro français tapé sans son préfixe FR, un préfixe hors UE : autant de valeurs condamnées à rester « inconnues » à vie, donc à franchir la barrière à vie.
Correctif : le numéro doit d'abord avoir la forme d'un numéro intracommunautaire pour que la tolérance s'applique. La leçon : un état d'erreur en cache souvent deux, et c'est celui qu'on n'a pas nommé qui ouvre la porte.
Ce que cette démarche ne garantit pas
Une barrière décrite sans ses angles morts n'est plus une barrière, c'est un argument commercial. Les nôtres :
- Un administrateur publie sans le contrôle : la garantie porte sur l'auto-publication client, pas sur l'équipe.
- Le pays est auto-déclaré : se déclarer hors UE lève l'exigence de TVA. C'est la contrepartie assumée de ne pas exclure les entreprises non européennes.
- En cas de panne VIES, un numéro bien formé mais non vérifié passe. On préfère ce risque à celui de bloquer un client pour une panne qui n'est pas la sienne.
Aucun de ces trous n'est un oubli : chacun est un arbitrage entre friction et étanchéité, écrit noir sur blanc pour pouvoir être rediscuté.
La légitimité vaut aussi pour les chiffres
Vérifier qui publie ne sert à rien si les compteurs, eux, sont gonflés. Nos propres entreprises publient et restent visibles comme n'importe quelle autre, mais elles sortent de toutes les métriques commerciales et marketing — revenus, funnel de conversion, comptes à relancer, intelligence d'audience. Elles ne comptent que là où elles sont légitimes : les vues et les visites, qui sont réelles.
Le contrôle tient en une manipulation : recalculer chaque indicateur deux fois, avec puis sans l'exclusion. Un chiffre qui ne bouge pas est un chiffre qui a oublié la règle.
Défense en profondeur
La légitimité repose sur un socle de sécurité : trafic derrière un WAF, origine verrouillée, journal d'audit des actions sensibles, alertes e-mail en temps réel, 2FA administrateurs, sauvegardes chiffrées. Le principe : accepter qu'aucune barrière n'est infaillible, donc tout tracer et tout alerter.
Résultats et prochaines étapes
- Zéro modérateur : aucune file de modération, publication autonome.
- Aucun chemin anonyme : un compte sans entreprise ne peut ni créer ni publier un REX.
- Témoigner sans tout dire : REX privé sur invitation, réduit à un teaser partout ailleurs.
- Lecteurs non nominatifs : audience agrégée par entreprise, IP et user-agent hachés.
- Identité vérifiée pour chaque entreprise publiante (registre VIES).
- 100 % tracé : auteur, entreprise et actions sensibles consignés.
- Chiffres non gonflés : nos propres entreprises sortent de toutes les métriques commerciales.
- Limites écrites : les trois angles morts de la barrière sont documentés, pas tus.
- Prouvé par les tests : chaque garantie est adossée à un test automatisé, rejouable à volonté.
Bonnes pratiques
- Vérifier l'identité de l'émetteur dissuade plus efficacement qu'une police du contenu.
- Faire porter la barrière la plus dure par le modèle de données (pas de REX sans entreprise) plutôt que par une vérification : ce qui est structurellement impossible n'a pas de contournement à chercher.
- N'accepter que les verdicts explicites d'un service tiers — et découper l'« inconnu » : « pas pu vérifier » et « ne pourra jamais vérifier » n'appellent pas la même réponse.
- Auditer sa propre promesse comme un attaquant : la première question à poser à une barrière, c'est « qu'est-ce qui passe ? », pas « qu'est-ce qui bloque ? ».
- Donner au client le bouton de sortie (dépublication immédiate, sans intermédiaire) : la confiance vient de la réversibilité, pas des promesses.
- Adosser chaque garantie à un test automatisé : la preuve reproductible vaut mille promesses.
Points de vigilance
- Un
200 OKd'une API tierce n'est pas un « oui » : lire le verdict, ne jamais l'inférer. - Ne jamais pénaliser un utilisateur pour une indisponibilité d'un service externe.
- Prévoir les entreprises hors UE (pas de TVA intracommunautaire) : la règle doit les exempter, pas les exclure.
- Un état « inconnu » fourre-tout finit en passe-droit : le découper jusqu'à ce que chaque cas ait sa réponse.
- Une donnée auto-déclarée (ici le pays) ne vaut pas une donnée vérifiée : en connaître le prix avant de s'appuyer dessus.
- Un REX parle aussi du client du client : prévoir dès le départ un mode « je témoigne sans tout dévoiler », sinon les meilleurs retours ne sortiront jamais.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Vous devez être connecté pour ajouter un commentaire.
Daté au niveau du modèle
- À revoir le
- 25/03/2027
Illustration isométrique : vérification de l'identité et traçabilité des REX — Show me the REX
Tags
REX produit par