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.

Qualification IA des demandes : En production, revue humaineSites spécialisés en rendu statique : En ligne depuis octobre 2026Mesure de la demande par période : Non instrumentée
Fiche du cas
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.

< 10 sentre la réception d’une demande et sa qualification enregistrée (9,2 s et 8,2 s)Exécutions de qualification, n = 2 : échantillon trop faible pour une moyenne
1version active du référentiel commercial, tracée dans chaque qualification avec l’empreinte du promptTable des versions du référentiel, approuvée le 4 septembre 2026

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.

Un système comparable à construire chez vous ?

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