Site QORAM · Le site comme démonstrateur

QORAM construit QORAM : le site comme système

Fiche du cas

Nature: Site QORAM
Durée: Refonte d’octobre 2026
Équipe: Direction de QORAM
Stack: Next.js (App Router)
TypeScript
Vercel
GitHub
Supabase Postgres (Paris)
n8n Cloud

Situation

La première version du site exposait une doctrine juste, mais la preuve restait déclarative : aucun cas chiffré, aucune offre d’exécution, rien sur les données. Le formulaire écrivait dans une base mise en pause.

Problème

Un cabinet qui vend des systèmes ne peut pas se présenter avec une brochure. Le site devait prouver par son propre fonctionnement ce qu’il affirme.

Décision

Refondre sur la même base technique plutôt que tout reconstruire ailleurs : préserver les 40 URL existantes (conservées ou redirigées une à une), réécrire l’architecture d’offre, publier des preuves mesurées et brancher un vrai pipeline de demandes.

Système construit

Pages rendues côté serveur ou générées à la construction : le contenu ne dépend pas du JavaScript
Redirections permanentes URL par URL, chaque ancienne adresse publiée vers son meilleur équivalent (l’accueil seulement pour les versions linguistiques abandonnées)
Données structurées reliées : organisation, dirigeant, services, fil d’Ariane
Deux démonstrateurs utiles : la carte du système et le diagnostic des frictions
Pipeline de demandes : validation, stockage, déduplication, score, notification, prochaine action
Aucun traceur publicitaire ni cookie de mesure

Résultat

Le site est en ligne dans cette version. Les mesures de trafic et de conversion seront publiées ici quand elles existeront ; aucune n’est affichée avant.

Non mesuré.

Trafic, demandes et conversion de la nouvelle version : trop tôt

Limites.

Aucune mesure de performance n’est encore publiée : elle viendra des visiteurs réels, pas d’un test de laboratoire

État du site.

Données réelles, figées au moment de la construction de cette version. Aucun secret, aucune donnée de visiteur.

Construction en cours de serviceProduction

Construite le: 10 octobre 2026 à 10:24
Version (commit): bad9eb2
Branche: main
Cadre: Next.js 16.2.4, React 19.2.4, TypeScript
Rendu: Pages générées à la construction ; seules les routes d’API s’exécutent à la demande
Redirections permanentes: 15 anciennes adresses, chacune vers son meilleur équivalent
Traceurs: Aucun cookie de mesure ou de publicité

Les systèmes de ce cas.

Décrits avec leur fonctionnement, leurs données, leur contrôle humain et leurs limites.

Site comme actif de distributionLe site comme actif de distribution est un site conçu pour produire des demandes qualifiées et les transmettre au système commercial, et non pour présenter l’entreprise.

Le problème traité: Le site a été pensé comme une vitrine. Il est refait périodiquement, n’est relié à aucun outil commercial, et personne ne sait quelles pages produisent des demandes ni lesquelles n’en produisent aucune.
Comment il fonctionne: L’ordre est fixe : business, demande, offre, positionnement, architecture, puis site. Chaque page a un rôle (capter, rassurer, convertir), chaque formulaire alimente le CRM avec sa source, et chaque conversion est mesurée. Le site devient un composant du système, maintenu et amélioré page par page.
Les données nécessaires: Offres et segments validés, preuves disponibles, intentions prioritaires, structure du CRM prête à recevoir les demandes. Le CRM fait foi pour la qualité des demandes ; l’outil d’analytics, pour le comportement de navigation.
Le contrôle humain: Le dirigeant valide la promesse et l’arborescence. Le responsable commercial valide les champs de formulaire et les règles de transmission, car ils déterminent la qualité des demandes que son équipe recevra.
Le résultat attendu: Le site est jugé sur les demandes qu’il produit et sur leur qualité, plus sur son apparence. Chaque évolution part d’une page mesurée, pas d’une refonte globale.
Quand ne pas le construire: Quand les ventes passent exclusivement par un réseau fermé de prescripteurs, ou quand l’offre et la cible ne sont pas encore arrêtées.
Exemple: Exemple type : une entreprise de design & build de bureaux dispose d’un site soigné mais muet. On réorganise les pages autour des situations de ses clients (déménagement, regroupement de sites, réaménagement), on relie les formulaires au CRM et on mesure les demandes par page.

Architecture SEO / GEOL’architecture SEO / GEO est l’organisation du site, des contenus et des signaux d’entité qui rend l’entreprise trouvable dans Google et citable par les moteurs génératifs.

Le problème traité: Le site accumule des pages sans hiérarchie, des messages contradictoires et peu de preuves vérifiables. Les moteurs de recherche le comprennent mal, et les moteurs génératifs citent d’autres sources quand on les interroge sur le métier.
Comment il fonctionne: Le SEO structure l’arborescence, le maillage et les données structurées. Le GEO vise la visibilité dans les réponses des moteurs génératifs. La GEA (Generative Engine Authority, discipline interne à QORAM, pas un standard officiel) construit les preuves, la cohérence de l’entité et les sources citables qui conduisent un moteur génératif à retenir l’entreprise comme source.
Les données nécessaires: Pages existantes, Search Console, requêtes réelles, profils externes de l’entreprise (annuaires, réseaux, fiches), références publiables. La source de vérité de l’entité est une fiche interne unique : nom, activités, zones, dirigeants, preuves.
Le contrôle humain: Le dirigeant valide la fiche d’entité et chaque affirmation publiée. Un expert relit les contenus de réponse avant mise en ligne : une erreur reprise par un moteur génératif est difficile à corriger ensuite.
Le résultat attendu: L’entreprise est décrite de la même façon partout. Les pages répondent clairement aux questions du métier, ce qui rend l’entreprise plus facile à indexer, à comprendre et à citer. Aucune citation n’est garantie.
Quand ne pas le construire: Quand le site souffre de problèmes techniques de base non résolus, ou quand l’entreprise n’a aucune preuve publiable : il faut d’abord produire la matière.
Exemple: Exemple type : une PME de services informatiques est décrite différemment sur son site, ses annuaires et ses profils. On unifie la fiche d’entité, on restructure les pages par question client et on publie des références vérifiables. Les moteurs disposent enfin d’une version cohérente à reprendre.

Captation unifiée des demandes (lead intake)La captation unifiée des demandes est le point d’entrée unique qui reçoit chaque demande, quel que soit son canal, la normalise et l’enregistre au même endroit.

Le problème traité: Les demandes arrivent par formulaire, e-mail, téléphone, salon ou partenaire. Elles vivent dans des boîtes de réception différentes, certaines sont oubliées, et personne ne peut dire combien de demandes l’entreprise a reçues ce mois-ci.
Comment il fonctionne: Chaque canal envoie sa demande vers un même flux, souvent porté par un orchestrateur de workflows (par exemple n8n ou Make). Le flux normalise les champs, conserve la source, contrôle les doublons, enregistre la demande dans le CRM ou une base, puis notifie la bonne personne. Les demandes incomplètes rejoignent une file d’exceptions.
Les données nécessaires: Formulaires du site, boîte e-mail dédiée, saisies manuelles des appels et des salons, flux des partenaires. Un schéma commun fixe les champs obligatoires ; le CRM ou la base dédiée fait foi.
Le contrôle humain: Un responsable désigné traite chaque jour la file d’exceptions : demandes incomplètes, sources inconnues, cas ambigus. C’est là que les demandes se perdent ; un humain doit en être propriétaire.
Le résultat attendu: Aucune demande ne dépend plus de la boîte de réception d’une seule personne. Le volume réel est connu, chaque demande a une source et un propriétaire, et les délais de réponse deviennent mesurables.
Quand ne pas le construire: Quand l’entreprise reçoit quelques demandes par mois, par un seul canal : une boîte partagée bien tenue suffit.
Exemple: Exemple type : un fabricant d’équipements reçoit des demandes par son site, ses distributeurs et des salons professionnels. Toutes passent désormais par le même flux, sont enregistrées dans le CRM avec leur origine et attribuées au commercial du secteur concerné.

Déduplication et idempotenceLa déduplication et l’idempotence sont les règles qui empêchent qu’un même contact, une même demande ou un même événement crée plusieurs enregistrements.

Le problème traité: Un prospect remplit deux fois le formulaire, écrit ensuite par e-mail, et une automatisation se relance après une erreur. Résultat : plusieurs fiches, deux commerciaux sur le même dossier et un pipeline faussé.
Comment il fonctionne: Chaque contact est rapproché sur des identifiants stables : e-mail normalisé, numéro SIREN, domaine de l’entreprise. Chaque événement reçoit une clé d’idempotence, c’est-à-dire une empreinte unique : si le même événement est traité deux fois, il ne produit qu’un seul enregistrement. Les rapprochements incertains sont mis de côté pour vérification.
Les données nécessaires: Identifiants disponibles (e-mail, SIREN, domaine, téléphone), fiches existantes, journal des événements déjà traités. Le CRM ou la base porte la fiche de référence ; le journal fait foi pour savoir ce qui a été traité.
Le contrôle humain: Une personne de l’administration des ventes valide chaque semaine les fusions incertaines, par exemple deux contacts homonymes dans des sociétés proches. Une fusion erronée détruit de l’historique ; dans le doute, elle n’est jamais automatique.
Le résultat attendu: Une personne correspond à une fiche, une demande à une opportunité. Les automatisations peuvent être relancées sans risque de doublon, et les chiffres du pipeline redeviennent crédibles.
Quand ne pas le construire: Pas de chantier dédié sur une petite base saisie à la main ; un dédoublonnage ponctuel suffit. En revanche, l’idempotence est indispensable dès qu’un flux est automatisé.
Exemple: Exemple type : dans une société de conseil, un formulaire renvoie la même demande après une coupure réseau. La clé d’idempotence permet de reconnaître et d’ignorer le second envoi : une seule demande est créée, un seul commercial est notifié.

Mesure et attributionLa mesure et l’attribution sont le dispositif qui relie chaque demande à sa source, puis la suit jusqu’à l’opportunité, la signature et le chiffre d’affaires.

Le problème traité: Les rapports parlent de visites, de clics et de formulaires. Personne ne sait quel canal produit des clients signés : les budgets se décident à l’intuition, et de bons canaux sont parfois coupés.
Comment il fonctionne: Chaque demande reçoit sa source à l’entrée : paramètres de campagne, page d’origine, déclaration du contact. Cette source est conservée dans le CRM jusqu’à la signature. Un tableau croise sources, opportunités, taux de transformation et délais. Le modèle d’attribution reste simple et documenté, pour être compris par ceux qui décident.
Les données nécessaires: Paramètres de campagne, événements du site, champs source du CRM, montants signés. Le CRM est la source de vérité du résultat ; les plateformes publicitaires ne sont jamais juges de leur propre performance.
Le contrôle humain: Le responsable marketing ou commercial vérifie chaque mois les demandes sans source et corrige les règles de collecte. La direction interprète les écarts : un chiffre d’attribution éclaire une décision, il ne la prend pas.
Le résultat attendu: Les décisions de budget reposent sur des clients signés et des délais observés, plus sur des volumes de trafic. Les canaux faibles comme les canaux sous-estimés deviennent visibles.
Quand ne pas le construire: Quand le volume de demandes est trop faible pour conclure, ou quand le CRM n’est pas tenu : la mesure ne vaut que ce que vaut la donnée.
Exemple: Exemple type : un organisme de formation inter-entreprises finance plusieurs canaux sans lien avec ses inscriptions. Chaque demande garde sa source jusqu’à la facture, et la direction compare enfin les canaux sur les contrats signés plutôt que sur les clics.

Autres cas.

Un système comparable à construire chez vous ?

On commence par vérifier que c’est le bon problème.

Demander un échange de 30 min Découvrir la Review