### **10. Extensions Futures**

Ce chapitre existe pour que les fonctionnalités écartées du périmètre V1 ne soient ni oubliées, ni réintroduites par accident. Il décrit ce qu'il faudrait résoudre avant de les construire, sans les spécifier.

#### **10.1. Module IA « Page-Skill »**

Le principe est solide : extraire l'arbre des éléments interactifs d'une page, en déduire les actions possibles, et laisser un modèle de langage assembler un parcours en réponse à une question posée en langage naturel. Quatre problèmes doivent être résolus avant, et non pendant.

**Invention de sélecteurs.** Un modèle sollicité pour produire un parcours produira volontiers des sélecteurs plausibles mais inexistants. La contrainte est structurelle et non rédactionnelle : le modèle ne choisit pas un sélecteur, il choisit un **identifiant d'action** dans une liste finie fournie par le système, et la sortie est rejetée si elle contient autre chose. Une consigne dans l'invite ne remplacera jamais cette validation.

**Souveraineté, qui est le point le plus lourd.** Faire transiter la structure des pages d'un client par un fournisseur de modèle non européen contredit frontalement le différenciateur sur lequel Circuy se vend, et détruirait la valeur des chapitres 7 et 8. Les documents de travail évoquent des modèles américains ; ce choix est incompatible avec le positionnement du produit. L'ouverture de ce chantier suppose soit un fournisseur européen, soit un modèle hébergé sur l'infrastructure de Circuy, et exige un ADR argumenté avant toute ligne de code.

**Données personnelles.** L'extraction d'une page réelle capture des données affichées, et pas seulement des libellés d'interface : noms de clients dans un tableau, montants, adresses. Un filtrage par expressions régulières, tel que décrit dans le cahier fonctionnel, ne suffit pas à garantir l'absence de fuite ; il attrape les formes connues et laisse passer le reste. La règle protectrice est d'extraire uniquement les libellés des éléments interactifs et les attributs d'accessibilité, en excluant par construction tout contenu de données. Cette approche par liste blanche est la seule défendable devant un client qui achète de la conformité.

**Économie et latence.** Chaque question posée a un coût et un délai. Un modèle tarifaire et un plafond par organisation doivent exister avant l'ouverture de la fonctionnalité, sans quoi elle est un poste de dépense non borné.

#### **10.2. Synchronisation event-driven**

Le besoin annoncé consiste à conditionner une étape à un fait constaté côté serveur, par exemple la validation d'un dossier ou l'aboutissement d'un paiement.

Rien ne sera construit tant qu'un client n'aura pas exprimé un cas concret, avec le système émetteur et le fait à observer. Le jour venu, la solution la plus ennuyeuse est explorée en premier : une table d'événements attendus alimentée par un appel HTTP entrant, que le SDK interroge lorsqu'une étape le requiert. Un courtier de messages n'entrera dans la discussion que lorsque cette table aura démontré son insuffisance par des chiffres.

#### **10.3. Critères de déclenchement**

Aucun de ces chantiers ne s'ouvre avant que les trois conditions suivantes soient réunies :

1. La boucle V1 tourne en production chez au moins cinq clients payants.
2. Le taux de survie des sélecteurs (section 9.2) est mesuré et stable sur plusieurs mois. Une intelligence artificielle qui produit des parcours reposant sur un ciblage fragile ne fait que multiplier les parcours cassés.
3. La demande est formulée par écrit par plusieurs clients, et non déduite de la présence de la fonctionnalité chez des concurrents.

Ces critères sont réévalués aux mêmes échéances que les hypothèses de charge de la section 0.2.