Activité opérée par la direction de QORAM · Croissance et distribution
L’Architecte ERP : vendre un problème d’exploitant, pas des formalités
Repositionnement d’une expertise réglementaire (établissements recevant du public) en système de demande, avec une qualification IA en production et une revue humaine systématique.
- Nature
- Activité opérée par la direction de QORAM
- Durée
- Référentiel commercial approuvé le 4 septembre 2026 ; premières demandes qualifiées en production les 15 et 16 septembre 2026
- Équipe
- Conception et construction par la direction de QORAM
- Stack
- Site historique : Wix
- Orchestration : n8n Cloud
- Base de données : Supabase Postgres (Irlande)
- Modèle : OpenAI gpt-4o, sortie JSON stricte
Situation
L’Architecte ERP, marque d’architecture de la direction de QORAM, traite la conception, les autorisations et les travaux des établissements recevant du public. Le savoir-faire existait ; il était présenté comme une suite de formalités.
Problème
Un métier réglementaire attire des recherches très techniques et des demandes fragmentées. Il fallait rendre visible la chaîne de valeur complète et distinguer tôt les dossiers qui justifient une intervention senior.
Décision
Positionner l’offre sur le problème de l’exploitant (ouvrir, transformer, faire autoriser, exploiter) plutôt que sur la procédure, puis construire une distribution qui intercepte des intentions fortes et une qualification qui trie avant le rendez-vous.
Système construit
- Repositionnement du site et page dédiée au dossier ERP
- Chaîne lisible : faisabilité → conception → autorisation → projet détaillé → consultation → maîtrise d’œuvre → ouverture
- Architecture SEO par intention et règles de qualification commerciale
- Qualification IA des demandes : sortie structurée, référentiel commercial versionné, revue humaine imposée par le code
- Depuis octobre 2026, sites spécialisés en rendu statique (dont dossier-erp-paris.fr), lisibles par les moteurs génératifs
Résultat
Les demandes du formulaire ont été qualifiées par IA en moins de dix secondes après réception, avec revue humaine systématique. Le volume reste trop faible pour publier un chiffre de demandes ou de conversion.
Mesures.
Requêtes en lecture seule sur la base de production, agrégats uniquement, le 9 octobre 2026. Aucune donnée personnelle n’a été extraite.
Non mesuré.
- Demandes par période avant / après : historique antérieur non instrumenté
- Part des demandes hors zone historique : la ville n’était pas collectée
- Taux de qualification, rendez-vous, valeur du pipeline : non mesurés à ce jour
Limites.
- Le site historique, construit sur Wix, s’est révélé mal lu par les robots des moteurs génératifs lors d’un test : c’est l’une des raisons des nouveaux sites en rendu statique
- Depuis le 3 octobre 2026, les demandes ERP rejoignent la source de vérité FIXIA ; les volumes y sont encore faibles et en partie des tests
Les systèmes de ce cas.
Décrits avec leur fonctionnement, leurs données, leur contrôle humain et leurs limites.
Architecture d’offreL’architecture d’offre est la structure qui organise ce que l’entreprise vend : offres, niveaux, périmètres, prix et portes d’entrée, lisibles par l’acheteur comme par l’équipe.
- Le problème traité
- L’offre s’est construite par accumulation de demandes clients. Les commerciaux improvisent les périmètres, les prix varient sans logique, et l’acheteur ne comprend ni ce qu’il achète ni pourquoi choisir cette entreprise.
- Comment il fonctionne
- On inventorie ce qui est réellement vendu et livré, avec la marge de chaque prestation. On regroupe le tout en un petit nombre d’offres nommées, chacune avec un périmètre, des exclusions, un prix ou une règle de prix, et une porte d’entrée simple. Les offres peu rentables ou mal livrées sont arrêtées.
- Les données nécessaires
- Historique des ventes et des devis, marges par prestation, temps passés, retours clients, motifs de perte. La comptabilité analytique fait foi pour la marge ; le CRM, pour ce qui se vend réellement.
- Le contrôle humain
- Le dirigeant décide des offres arrêtées, des prix et des exclusions : ce sont des choix de positionnement. L’équipe commerciale est consultée sur la vendabilité de chaque offre avant sa mise en œuvre.
- Le résultat attendu
- L’acheteur comprend plus vite ce qu’il achète. Les devis partent d’une base commune, les écarts de prix s’expliquent et la marge devient pilotable offre par offre.
- Quand ne pas le construire
- Quand l’activité repose sur des projets uniques sans aucune récurrence, ou quand le vrai problème est la capacité de livraison, pas la lisibilité de l’offre.
- Exemple
- Exemple type : une société de maintenance d’équipements industriels vend des dizaines de variantes de contrats. Elle les regroupe en quelques niveaux de service aux périmètres et exclusions explicites, ce qui simplifie à la fois la vente, le devis et la facturation.
Pages d’intentionUne page d’intention est une page conçue pour répondre à une recherche précise d’un acheteur, avec la réponse, la preuve et la prochaine étape adaptées.
- Le problème traité
- Le site parle de l’entreprise, pas des situations de ses clients. Un acheteur qui cherche une réponse à un problème précis tombe sur une page générique, ne se reconnaît pas et repart sans rien demander.
- Comment il fonctionne
- On recense les intentions réelles : questions posées aux commerciaux, recherches observées, motifs de demande. Chaque intention distincte reçoit une page : réponse directe en tête, conditions d’application, preuves, limites, puis une prise de contact qualifiante. Les intentions trop proches sont regroupées pour éviter les pages quasi identiques.
- Les données nécessaires
- Questions entendues par les commerciaux, requêtes remontées par la Search Console, motifs de contact enregistrés dans le CRM. La source de vérité reste ce que les clients demandent réellement, pas une liste de mots-clés.
- Le contrôle humain
- Un expert métier valide le fond de chaque page avant publication : exactitude technique, conditions, limites. Le dirigeant tranche la liste des intentions à couvrir, car chaque page engage la promesse de l’entreprise.
- Le résultat attendu
- Les visiteurs arrivent sur une réponse à leur question, pas sur une plaquette. Les demandes entrantes sont plus précises et le commercial sait d’emblée quel problème il doit traiter.
- Quand ne pas le construire
- Quand l’entreprise vend une seule offre à un seul type d’acheteur, ou quand personne en interne ne peut valider le contenu technique des pages.
- Exemple
- Exemple type : un bureau d’études fluides reçoit surtout des demandes vagues. Il crée des pages distinctes pour la mise en conformité d’un établissement recevant du public, la rénovation énergétique d’un plateau tertiaire et l’audit technique avant acquisition, chacune avec sa réponse, ses limites et un formulaire adapté.
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.
Qualification encadréeLa qualification encadrée est un tri des demandes fondé d’abord sur des règles explicites, où l’IA peut proposer un classement et où l’humain décide des cas importants.
- Le problème traité
- Les commerciaux trient les demandes à la main, chacun avec ses critères. Les bons dossiers attendent derrière les mauvais, et les demandes hors cible consomment un temps senior qui manque ailleurs.
- Comment il fonctionne
- Les critères éliminatoires sont codés en règles : zone, taille, type de besoin, délai. Au-delà, un modèle de langage propose une catégorie et sa justification. Il démarre en mode observation : il propose en parallèle sans agir, et ses propositions sont comparées aux décisions humaines pour mesurer sa fiabilité avant de lui faire confiance.
- Les données nécessaires
- Critères de cible validés par la direction, historique des demandes avec leur issue (gagnée, perdue, écartée), contenu de chaque demande. Le CRM fait foi pour l’issue réelle, qui sert à vérifier les règles et le modèle.
- Le contrôle humain
- Le responsable commercial décide de toute demande au-dessus d’un seuil de valeur ou classée « incertaine ». Il revoit chaque mois les écarts entre propositions de l’IA et décisions humaines, puis ajuste les règles.
- Le résultat attendu
- Les demandes hors cible sont écartées tôt et proprement. Les commerciaux passent leur temps sur les dossiers qui correspondent, et la confiance accordée à l’IA repose sur des écarts mesurés.
- Quand ne pas le construire
- Quand les critères de cible ne sont pas écrits, ou quand le volume est assez faible pour qu’un commercial lise chaque demande en quelques minutes.
- Exemple
- Exemple type : un bureau d’études techniques reçoit des demandes de missions très hétérogènes. Les règles écartent les projets hors zone, le modèle propose un type de mission, et le directeur technique valide chaque demande importante avant affectation.
Autres cas.
- FIXIA : une source de vérité commerciale avant toute IACaptation des demandes, idempotence, regroupement par dossier, décision humaine tracée, qualification IA conçue puis désactivée : le cas technique de référence de QORAM, mesuré.
- Groupe suisse de design & build : une même offre, trois languesSite en français, allemand et anglais, référencement multilingue, plaquette et supports de proposition pour un groupe suisse de design & build.
- QORAM construit QORAM : le site comme systèmeComment ce site est conçu, rendu, mesuré et relié à un pipeline de demandes : architecture, décisions, démonstrateurs et état réel du déploiement.
Un système comparable à construire chez vous ?
On commence par vérifier que c’est le bon problème.