Architecture d'un site conversationnel : ce qui se passe entre la question et la réponse

Le 16 novembre 2026, la page d'accueil de sfeir.com devient un champ de saisie. Le visiteur pose sa question dans ses mots. Le Worker envoie une colonne de pages en 2,7 secondes au plus : offres, fiches, articles, postes ouverts, agences. Puis vient une réponse de 120 mots au plus, qui cite ses sources. Le principe tient en une phrase : des règles écrites choisissent les pages montrées, un petit modèle de classification les aide à trier, et un seul modèle rédige, ce dernier paragraphe, à partir des seuls contenus publiés. Il s'adresse aux architectes et aux CTO qui veulent interroger leurs propres contenus de cette façon. Il ne traite pas des assistants de support branchés sur un CRM, qui posent d'autres questions : identité, données personnelles, actions.

Des pages statiques et un Worker

Le site lui-même n'a pas changé de nature. Astro génère au build des pages statiques (1 626 URL dans le plan du site au 13 novembre 2026), que Cloudflare Pages sert telles quelles depuis le printemps 2026 : aucun serveur d'application, aucune base de données au moment de la lecture. La matière vit dans le dépôt Git : 363 fiches de la base de connaissances en YAML, 384 articles en Markdown, les offres, expertises et secteurs décrits en données. Nous avons décrit en juillet comment cette matière devient des pages et des présentations, dans « Une matière, plusieurs représentations ». La conversation en est une représentation de plus. Comment la base s'est construite fait l'objet d'un article sur la base de connaissances du site.

À chaque build, un export prépare la matière de l'agent, à côté des pages :

• un catalogue de 1 096 entrées : chaque page qu'une réponse a le droit de citer, avec son titre, son résumé et ses liens vers les autres contenus ;
• 7 132 passages, les paragraphes découpés dans ces pages, qui servent à rédiger ;
• un lexique pour la recherche par mots ;
• une empreinte de tout le texte vectorisé.

Les index vectoriels (Cloudflare Vectorize) se mettent à jour en deux temps : les nouveaux vecteurs avant le déploiement, les suppressions après. Un commit qui ne change aucun texte vectorisé ne touche pas aux index. L'agent ne lit que ce que le build a publié : un passage absent des fichiers déployés n'est jamais lu, même si l'index le connaît encore.

Le chemin d'une question, étape par étape

1. Les contrôles d'entrée

La requête doit venir du site, passer le contrôle anti-robot de Cloudflare (Turnstile) et rester sous un quota par visiteur. Le quota se compte sur une empreinte de l'adresse IP, salée et renouvelée chaque jour : l'adresse elle-même n'est jamais stockée. Les adresses e-mail et les numéros de téléphone que contiendrait la question sont masqués avant toute autre étape, modèle compris.

2. La recherche

La question devient un vecteur de 1 024 dimensions (modèle bge-m3, sur Workers AI), cherché dans l'index des pages. En parallèle, une recherche par mots interroge le lexique. Les deux classements sont fusionnés par rang réciproque (RRF, une méthode publiée en 2009¹), et 24 pages candidates sont retenues. Le même vecteur interroge l'index des passages, qui fournit les paragraphes que lira le modèle de rédaction. La recherche par mots rattrape ce que les vecteurs manquent : un acronyme, un nom propre, le code d'une formation.

3. La décision

Un petit modèle de classification, Clef-flash, lit la question et les candidates. Il choisit une intention parmi sept (découvrir une offre, comprendre une expertise, cas sectoriel, actualité, recrutement, contact commercial, hors sujet) et trie les candidates. Il dispose de 1,8 seconde. S'il ne répond pas à temps, l'ordre de la recherche s'applique et la suite continue. Nous avons comparé les modèles de décision de Cloudflare avant de retenir celui-ci.

4. La colonne, composée par des règles

Cette étape distingue le site d'un chatbot. Aucun modèle n'écrit la colonne : à partir des candidates triées à l'étape précédente, des règles écrites et testées choisissent les blocs et leur ordre. Ce que la question nomme passe en tête : une fiche de la base (« FDE », pour Forward Deployed Engineer), une ville où SFEIR a une agence (« Lille »), un partenaire (« Google Cloud »), une formation, un événement, une personne. Le reste suit trois niveaux. D'abord ce qui prépare un achat : offres, accompagnements, formations, cas clients. Puis les appels à l'action : contact, postes ouverts. Enfin l'information : articles, fiches, chiffres du groupe. La colonne s'affiche au plus tard 2,7 secondes après la question, que la rédaction ait commencé ou non.

Ces règles se corrigent une à une, et chaque correction laisse un test. Un exemple : « assurance qualité » ouvrait la page du secteur de l'assurance. L'expression est désormais rangée parmi les faux amis, avec « l'énergie des équipes », qui ouvrait celle de l'énergie.

5. La rédaction

Llama 3.3 70B, sur Workers AI, reçoit la question, les trois derniers échanges et les passages retenus. Ses consignes tiennent en quelques lignes :

• répondre uniquement à partir des passages, et dire ce qui manque quand ils ne couvrent qu'une partie de la question ;
• sans passage utile, écrire : « Je n'ai pas cette information dans les contenus publiés sur sfeir.com. » ;
• ne jamais attribuer à SFEIR une offre, une expertise ou un client absents des passages ; ne citer un chiffre, un prix ou un nom de client que s'il y figure ;
• 120 mots au plus, sans lien, sans adresse ni numéro de téléphone ;
• finir par la liste des passages utilisés.

La question, l'historique et les passages lui sont transmis comme des données, jamais comme des consignes. Le Worker convertit la liste finale en une à quatre pages du catalogue déployé : une source absente du site ne peut pas s'afficher. La température est basse (0,2), pour que deux visiteurs qui posent la même question lisent à peu près la même réponse.

Le premier fragment de texte doit arriver dans les 5 secondes. Sinon, l'échange se termine sur la colonne avec « Voici nos contenus sur cette question. » Le visiteur a déjà ses pages ; il ne lit aucun message d'erreur.

6. Les sources et les relances

Sous la réponse s'affichent trois questions de relance : approfondir le sujet, regarder à côté, passer à l'étape suivante selon le profil que la colonne laisse deviner (client, candidat, personne qui veut se former). Elles sont calculées sans modèle, à partir des questions écrites pour chaque page.

Le cache et la mesure

La première question d'une conversation, quand sa réponse est complète et sourcée, est rangée sept jours dans un cache. La clé porte la version du contenu : chaque publication rend les anciennes réponses inaccessibles, sans purge à organiser. Une question déjà posée ressort donc sans appel au modèle.

Chaque échange laisse une ligne de mesure, gardée trois mois : la question nettoyée une seconde fois (adresses, numéros de téléphone et autres longs numéros remplacés), son rang dans la conversation, son origine (saisie, suggestion, lien) et la colonne reçue. Jamais la réponse rédigée, l'adresse IP, le navigateur ni un identifiant de visiteur. La politique de confidentialité du site le précise.

Pourquoi le modèle n'écrit que la fin

Les liens. Un modèle qui choisit les pages à montrer finit par en inventer, ou par pousser une page sans rapport. Ici, chaque lien vient du catalogue, et chaque bloc d'une règle qu'on peut lire, tester et corriger.

Le délai. La colonne arrive avant le texte. Si le modèle est lent ou indisponible, le visiteur n'attend pas devant un écran vide.

La réversibilité. Le modèle de rédaction est un paramètre de déploiement, et le code prévoit déjà un second fournisseur. Changer de modèle ne touche ni la recherche, ni la colonne, ni la mesure.

Le revers : chaque cas que la colonne traite mal demande une règle de plus. En échange, la colonne s'explique à un client, à un directeur commercial ou à un auditeur. Les contrôles qui entourent ces règles sont décrits dans l'article sur les garde-fous d'un site écrit par des agents.

En production : Pages devant, le Worker derrière

Le nom de domaine reste chez son registraire, hors de Cloudflare : www.sfeir.com pointe vers Cloudflare Pages par un enregistrement CNAME. Sans zone Cloudflare, aucune route ne peut placer un Worker sur ce nom. La solution retenue garde une seule origine. Pages sert les pages, et une fonction Pages relaie tout ce qui commence par /api/ vers le Worker de l'agent, par une liaison de service². Le Worker n'a pas d'adresse publique : on ne l'atteint qu'à travers le site.

Le déploiement passe par une seule commande, la même depuis le pipeline GitLab et depuis un poste :

1. build et trois suites de tests ;
2. ajout des nouveaux vecteurs ;
3. déploiement du Worker, puis de Pages ;
4. première porte de santé, sur l'adresse propre du nouveau déploiement : trois réponses correctes de suite, sinon retour arrière automatique du Worker et de Pages ;
5. suppression des vecteurs périmés et écriture de la nouvelle version des index ;
6. seconde porte : sous dix minutes, le point de santé doit trouver la même empreinte dans le site, le catalogue et les passages ; sinon, une alerte.

Pourquoi deux portes ? Un index vectoriel ne rend pas visible tout de suite ce qu'on vient d'y écrire : lors de nos essais, environ quatre-vingt-dix secondes séparaient l'écriture de la lecture. Une porte unique placée après le nettoyage des index aurait déclenché des retours arrière pour rien.

Ce que cette architecture ne fait pas

• Elle ne sait que ce qui est publié. Une question hors du corpus reçoit la phrase prévue pour ce cas, et la colonne montre les pages les plus proches. La qualité des réponses dépend de la couverture de la base plus que du modèle.
• Sa mémoire est courte. Le modèle relit les trois derniers échanges, pas davantage.
• Le modèle peut être lent. Lors des premiers essais en préversion, fin octobre, le premier fragment de Llama 3.3 dépassait 2,5 secondes quatre fois sur dix. D'où le délai de 5 secondes et la fin sur la colonne.
• Les agents de page dépendent du modèle. Ces champs de question, posés sur les pages d'offre, d'expertise, d'agence ou d'article, ne répondent que par du texte rédigé : sans modèle, ils sont masqués, et la page reste une page.
• Pas de compte, pas de cookie, pas de personnalisation. Deux visiteurs qui posent la même question voient la même colonne.

Ce que ça change, selon votre rôle

CTO, architecte. Le cœur du système est l'export : un catalogue des pages citables, des passages, une empreinte de version. Commencez par là, avant de choisir un modèle. Prévoyez dès le départ la version des index et les portes de santé : elles évitent de servir une réponse fondée sur un contenu retiré. Pour la partie recherche, nos retours d'expérience sur le RAG en production restent valables.

RSSI. La surface exposée est petite : des pages statiques, un Worker sans adresse publique, un contrôle anti-robot et des quotas devant chaque appel coûteux. Les adresses e-mail et les numéros de téléphone sont masqués avant le modèle, et la mesure ne garde ni IP ni réponse. Cloudflare indique ne pas utiliser les contenus traités par Workers AI pour entraîner ses modèles, et ne les conserver que le temps nécessaire au service³. Le risque d'injection demeure : des consignes qui traitent tout texte reçu comme une donnée et des sources limitées aux pages du catalogue le contiennent, sans le supprimer.

DSI. L'exécution dépend de Cloudflare ; les modèles sont à poids ouverts et remplaçables. Ce que coûte un échange, nous l'avons mesuré dans un article sur le coût d'un site conversationnel.

Cet article fait partie d'une série sur la construction de sfeir.com, qui commence par l'histoire du site, du CMS à la conversation.