Quand une TPE veut un site professionnel, le parcours doit rester simple : décrire son activité, valider, obtenir une page claire. Beaucoup d'outils « tout IA » promettent de tout deviner. En pratique, deux écueils reviennent : soit l'outil pose des questions incohérentes ou hors sujet, soit il oublie des informations pourtant indispensables (zone d'intervention pour un artisan, horaires pour un restaurant, tarification pour un SaaS).

Chez MERCUR, nous avons tranché une règle simple pour la phase de collecte du brief — celle qui précède la génération du site : l'IA sert à comprendre et formuler ; le code sert à décider et trancher. Ce n'est pas une posture anti-IA. C'est une décision d'architecture pour un produit destiné à des dirigeants qui n'ont ni le temps ni l'envie de corriger un assistant imprévisible.

Le problème : un brief trop rigide ou trop flottant

Un formulaire figé frustre : même questionnaire pour un plombier lyonnais, un restaurant parisien et une micro-SaaS en ligne. L'utilisateur abandonne ou répond au hasard. À l'inverse, un dialogue 100 % piloté par un modèle de langage peut sembler fluide… tout en variant d'un jour à l'autre : ordre des questions, champs jugés « critiques », ton employé.

Pour une TPE, cette imprévisibilité se paie en confiance. Si la prochaine question n'a pas de lien évident avec son métier, le doute arrive vite : « Est-ce que cet outil comprend vraiment mon activité ? » Or le brief alimente toute la génération du site one-page : textes, structure, signaux locaux. Une mauvaise collecte en amont se répercute sur la clarté de la vitrine.

Ce que nous avons mis en place : une architecture hybride

La collecte du brief (phase qui précède la génération) existe en deux modes — collecte depuis des URLs (site existant, fiche Google, réseaux) et dialogue voix/texte — qui convergent vers la même structure de session. Dans la version actuelle de la collecte, chaque cycle de dialogue suit un pipeline explicite :

  • Normalisation de la saisie (déterministe).
  • Extraction des données structurées (IA).
  • Détection du contexte métier : usage (test, démo, réel), secteur, modèle économique (IA).
  • Calcul de criticité des champs selon ce contexte (code — règles versionnées).
  • Validation de complétude avec champs manquants pondérés (hybride).
  • Classement des questions restantes par pertinence (IA).
  • Choix de la prochaine question avec stratégie anti-frustration (code — limite de 8 questions, priorisation des champs critiques après 5 échanges).
  • Formulation de la question en langage naturel, adaptée au secteur (IA).

Concrètement : si quelqu'un tape « Test » pour essayer l'outil, le système détecte un contexte d'essai et ne bloque pas sur la localisation — peu pertinente pour un simple test. Un restaurant italien à Paris verra la carte et les horaires remonter en priorité. Une activité SaaS en ligne verra la tarification traitée avant une adresse physique secondaire. Ces arbitrages ne sont pas laissés au hasard du modèle : ils passent par des règles explicites dans le code, ajustées selon le contexte détecté.

Avant toute génération de site, une étape de validation finale du brief est obligatoire : le brief est gelé, lisible, modifiable champ par champ si besoin, puis validé explicitement. MERCUR ne génère pas un site « en direct » sur un brouillon instable.

Pourquoi séparer IA et code

Prévisibilité pour l'utilisateur

Un dirigeant de TPE n'a pas à deviner pourquoi l'outil lui demande soudain son adresse ou, au contraire, l'ignore. Même contexte détecté, mêmes règles de criticité et mêmes garde-fous décisionnels ; l'IA conserve une marge pour classer et formuler les questions. Le comportement se teste, se débugue, se documente — comme n'importe quelle fonction métier.

Règles métier sous contrôle

Les pondérations (artisan local vs activité en ligne, test vs création réelle) vivent dans le dépôt, versionnées. On peut les faire évoluer sans réécrire tout un prompt opaque. Le score de confiance produit par le classement IA sert au logging interne, pas à une décision critique : une question essentielle ne disparaît pas parce qu'un modèle est « peu sûr ».

Coûts et latence maîtrisés

En confiant les tranches décisionnelles au code, nous réduisons la surface d'appels IA par cycle de dialogue — moins d'appels modèle qu'un flux entièrement piloté par l'IA, sans inventer un pourcentage public. Les modèles légers restent réservés à ce qu'ils font le mieux : interpréter une phrase libre, classer un secteur, reformuler une question courte — pas arbitrer seuls la conformité métier.

Alignement avec la promesse produit

MERCUR aide à créer un site one-page à partir d'un brief, hébergé et modifiable ensuite — pas à « remplacer votre cerveau ». L'IA accélère la rédaction et la structuration ; le code garantit que les informations utiles à une vitrine locale (activité, zone, contact, preuves) sont traitées avec cohérence. C'est la même philosophie que pour la suite du parcours : le site est généré pour vous, puis vous gardez la main sur le contenu via l'éditeur.

Les limites — ce que cette architecture ne promet pas

  • L'IA reste imparfaite sur des formulations ambiguës ou des activités atypiques. Le dialogue peut demander une clarification ; il ne garantit pas une compréhension parfaite du premier coup.
  • Huit questions maximum dans le flux conversationnel : au-delà, l'utilisateur peut finaliser ou générer avec un brief partiel — parce qu'un parcours sans fin nuit plus qu'il n'aide.
  • Contexte « test » allégé ; pour une création réelle, MERCUR demande une validation explicite du brief avant génération, même lorsqu'il reste volontairement incomplet.
  • Pas de garantie SEO : un brief mieux structuré prépare une page plus claire (titres, zone, contact) ; cela n'équivaut ni à un ranking, ni à une visibilité dans les moteurs de réponses IA.
  • La validation humaine reste centrale : l'utilisateur relit la synthèse et valide avant génération. MERCUR automatise la collecte et la mise en forme, pas la responsabilité éditoriale du dirigeant.

Ce que cela change pour vous, dirigeant de TPE

Si vous créez votre site avec MERCUR, vous n'avez pas à connaître cette architecture. Vous la ressentez simplement : des questions qui collent à votre métier, un nombre limité d'échanges, une synthèse lisible avant lancement, puis un site one-page professionnel — textes, structure, design — généré à partir de ce brief validé.

Notre conviction : pour des petites entreprises, la technologie doit réduire la charge cognitive, pas en ajouter. Séparer « comprendre » et « décider » est une façon concrète de tenir cette promesse — sans transformer le parcours en boîte noire, ni en formulaire administratif figé.

Capacités produit alignées sur l'inventaire marketing MERCUR — création depuis un brief, site one-page, validation avant génération.