ValueAdservio — Manuel d'utilisation

Démonstrateur de gouvernance de portefeuille IA

Auteur : Olivier Vitrac, PhD, HDR Head of Adservio Innovation Lab · Adservio · La Défense ✉ olivier.vitrac@adservio.fr

Édition : Avril 2026 · v0.1 URL publique : https://valueadservio.pages.dev

1. Vue d'ensemble

ValueAdservio est un démonstrateur de gouvernance de portefeuille IA. Il n'est pas une application classique : c'est un noyau scientifique déterministe ($\mathit{\text{kernel}}$$\textit{kernel}$) entouré d'une interface humaine et d'une API REST publique (/api/kernel/*, OpenAPI 3.1). Le même noyau peut être appelé par une analyste devant son écran, par un agent LLM autonome, ou par un script batch — les trois voies produisent exactement les mêmes nombres pour les mêmes entrées.

Le démonstrateur permet, à partir d'une simple description d'un cas d'usage IA, d'estimer :

• la valeur ajustée annuelle attendue (€/an),

• la valeur cumulée à 3 ans (€),

• le retour sur investissement à 3 ans (%),

• le délai de retour ($\mathit{\text{payback}}$$\textit{payback}$, mois),

• la matrice de fragilités du scénario (10 règles déterministes),

• l'action recommandée par le noyau (11 valeurs : pilot, fund_full, redesign, stop, …),

• le suivi du réalisé vs le projeté (M+3, M+6, M+12).

Toutes ces sorties sont reproductibles et traçables : aucun appel sortant, aucun aléa, aucune boîte noire.

2. Architecture du noyau

2.1 Principe de conception

Le noyau ValueAdservio diffère d'une application web classique par sa discipline architecturale :

                ┌──────────────────────────────────┐
                │   NOYAU DÉTERMINISTE             │
                │   (kernel/*.js)                  │
                │                                  │
   humain  ───→ │   • aucune sortie réseau         │ ───→ JSON
   LLM     ───→ │   • aucun état persistant        │ ───→ JSON
   service ───→ │   • aucune source d'aléa         │ ───→ JSON
                │   • formules figées en code      │
                │   • testé par 162 tests unitaires│
                └──────────────────────────────────┘

Trois invariants non négociables :

1. Le noyau ne peut pas appeler vers l'extérieur (ni LLM, ni base de données, ni service tiers). Il prend du JSON, il rend du JSON.

2. Le noyau n'a pas de mémoire. Chaque appel est indépendant ; deux appels identiques produisent des sorties identiques.

3. Le noyau est l'unique source de vérité numérique. L'interface affiche, le LLM propose, mais c'est le noyau qui calcule.

Cette discipline rend le système auditable (un commit = un comportement) et gouvernable (un changement de politique passe par un fichier data/policy.*.json versionné, jamais par un prompt).

2.2 Modules du noyau

xxxxxxxxxx
kernel/
  constants.js       SCEN, PRISMES, MONET, KERNEL_VERSION
  schema.js          types JSON-Schema-lite
  validator.js       validation entrée bundle
  migrations.js      legacy → canonique (v0 → v1)
  scoring.js         cScore(p), scoreDecomp(p)
  value.js           cVal(p), cPrime(p), cPAdopt(p), cValAdj(p)
  roi.js             cVal3(p), cROIprog(p), cPayback(p), cValCurve, cCostCurve
  lifecycle.js       LIFECYCLE_TRANSITIONS, transitionLifecycle, recordDecisionEvent
  falsification.js   falsifyProject(p, options) — 10 règles
  recommendation.js  recommendAction(p, options) — 11 actions
  reconciliation.js  reconcileClaims(claims, output, taxonomy)
  realization.js     realizationReport(p) — M+3 / M+6 / M+12
  comparison.js      compareProjects(projects, references)
  simulation.js      evaluateProject, evaluateProjectVariant, generateSimulationOutput
  index.js           API publique

2.3 Deux modes de consommation

Le même noyau, deux transports :

​x
Mode A — Sans humain dans la boucle (REST)
  agent ⇄ /api/kernel/*  → JSON déterministe
  Cas d'usage : évaluation par lots, sweeps de régression,
                boucle agentique LLM ↔ noyau.

Mode B — Avec humain dans la boucle (cockpit)
  LLM produit un scénario → encode l'URL → utilisateur clique →
  cockpit ouvre l'assistant → humain révise / valide / ajoute.
  Cas d'usage : démonstration interactive, négociation d'hypothèses,
                revue exécutive.

L'interface graphique est un consommateur parmi d'autres du noyau, au même titre qu'un LLM externe ou qu'un script batch. Voir docs/wave-5-plan.md pour la spécification de la couche REST.

3. Équations sous-jacentes

Toutes les formules ci-dessous sont implémentées textuellement dans kernel/*.js. Les notations sont conservées pour la lisibilité ; les noms canoniques sont donnés en regard.

3.1 Valeur brute annuelle

où :

Les caps $min(1,g/100)$$\min(1, g/100)$ et $min(1,a/100)$$\min(1, a/100)$ traduisent la borne physique : on ne peut pas gagner plus de 100 % d'une activité, ni adopter plus de 100 % de la population.

3.2 Multiplicateur des prismes stratégiques

avec cinq prismes booléens $\{\text{data},\text{souv},\text{grp},\text{exec},\text{quick}\}$$\{\text{data}, \text{souv}, \text{grp}, \text{exec}, \text{quick}\}$ et leurs coefficients $b_k$$b_k$ figés dans kernel/constants.js. La plage résultante est $cPrime\in [1,0;\mathrm{1,756}]$$cPrime \in [1{,}0\,;\,1{,}756]$.

3.3 Probabilité d'adoption (facteur de confiance)

où $C$$C$ est le score RICE de confiance (1–5), $a$$a$ le taux d'adoption attendu, $cm$$cm$ la maturité du change management (1–5). Le plafond à 0,95 reflète qu'aucune adoption n'est jamais certaine.

Note ADOPT-001. Le taux $a$$a$ intervient deux fois — dans $cVal$$cVal$ comme « adoption attendue » et dans $cPAdopt$$cPAdopt$ comme « facteur de confiance ». Ce comportement hérité de la version v0 est préservé pour la compatibilité de régression et est documenté dans docs/intentional-behavior.md. Les puces de sensibilité ±10% sur le palier Adoption × scénario du waterfall rendent cette double application visible (asymétrie typique : +16 k€ / −15 k€).

3.4 Valeur ajustée annuelle

C'est la grandeur principale affichée dans toutes les vues du cockpit.

3.5 Score composite

avec les coefficients $w_{\ast }$$w_*$ figés dans kernel/scoring.js. $R,I,C,S,E,CR$$R, I, C, S, E, CR$ sont les sept scores qualitatifs (1–5) inspirés de la méthode RICE. ${\mathrm{\Delta }}_{\text{prismes}}$$\Delta_{\text{prismes}}$ et ${\mathrm{\Delta }}_{\text{risque}}$$\Delta_{\text{risque}}$ sont les ajustements liés aux prismes stratégiques activés et au niveau de risque IA Act.

3.6 Trajectoire de valeur cumulée (36 mois)

La courbe de valeur ajustée mois-à-mois suit une rampe d'adoption :

où $\mathit{ramp}(m)$$\mathit{ramp}(m)$ encode la montée en charge progressive (logistique sur 12 mois, plateau ensuite). Le payback est défini par :

avec $B$$B$ le budget build et $r$$r$ le taux de run annuel.

3.7 ROI à 3 ans

3.8 Réconciliation kernel ↔ LLM (AC5)

Soit $v^{\text{kernel}}$$v^{\text{kernel}}$ la valeur calculée par le noyau et $v^{\text{LLM}}$$v^{\text{LLM}}$ la valeur revendiquée par un agent LLM. Pour chaque champ avec une tolérance $\tau$$\tau$ déclarée dans data/taxonomy.json, l'écart relatif est :

Le verdict de réconciliation est :

Règle d'or (AC8) : la valeur du noyau n'est jamais écrasée par la revendication du LLM. La divergence est affichée, la décision revient à l'humain.

3.9 Action recommandée (politique pré- et post-déploiement)

L'action recommandée est calculée par recommendAction(p, options). La politique est externalisée dans data/policy.recommendation.json et est spécifique au cycle de vie du projet :

• Pré-déploiement ( $\mathit{statut}\in \{\text{evaluation},\text{priorise}\}$$\mathit{statut} \in \{\text{evaluation}, \text{priorise}\}$) : seuils sur $cScore$$cScore$ → reject / park / pilot / fund_full ; règles de garde sur les fragilités HIGH.

• Post-déploiement ( $\mathit{statut}\in \{\text{valide},\text{encours},\text{deploye}\}$$\mathit{statut} \in \{\text{valide}, \text{encours}, \text{deploye}\}$) : règles sur l'écart relatif $\mathrm{\Delta }=(v^{\text{réel}}-v^{\text{projeté}})/v^{\text{projeté}}$$\Delta = (v^{\text{réel}} - v^{\text{projeté}})/v^{\text{projeté}}$ → scale / continue / correct / rebaseline / stop.

Les seuils sont audités et sont publiés en JSON dans le dépôt — pas dans un prompt.

4. Parcours utilisateur

4.1 Cockpit (page d'accueil)

La page d'accueil présente cinq tuiles KPI globales (nombre de projets, valeur ajustée annuelle agrégée, budget 3 ans, projets à fort score, projets à risque) et la matrice de portefeuille Valeur × Score.

Chaque point de la matrice est un projet ; sa couleur indique le statut de cycle de vie, sa taille la racine carrée du budget. Cliquer un point ouvre la vue Simulation du projet correspondant.

Le bouton + Nouveau projet lance l'assistant de définition pour un projet vierge ; le bouton + Importer scénario LLM ouvre la modale d'import d'un bundle JSON produit par un agent LLM externe.

4.2 Bibliothèque

La bibliothèque expose les 7 fiches d'amorçage synthétiques (les scenario cards de data/scenario-cards.json). Elles servent de few-shot examples à un agent LLM : c'est en lisant ces fiches qu'un LLM apprend la convention de modélisation du démonstrateur.

Chaque fiche affiche :

• la famille IA (chip de couleur — RAG, RPA, Chat, Fraude…),

• la valeur ajustée annuelle (vert / bleu / gris selon le palier),

• un mini-graphe de la trajectoire de cash cumulé sur 36 mois,

• le confiance RICE et le payback,

• l'action recommandée par le noyau (chip de couleur),

• trois boutons : Ouvrir (vue simulation), Modèle (clone vers un brouillon utilisateur — voir §4.6), JSON (tiroir détail).

4.3 Simulation

La vue Simulation est la plus dense ; elle expose toutes les sorties déterministes du noyau pour un projet donné :

• Sélecteur de variante (Prudent / Central / Ambitieux) — applique les multiplicateurs SCEN à $g$$g$, $a$$a$ et $k_{\text{scen}}$$k_{\text{scen}}$ avant recalcul. La vue d'origine (state.evaluated) n'est pas modifiée.

• Carte de valeur — quatre KPI principaux ($cValAdj$$cValAdj$, valeur 3 ans, ROI 3 ans, payback) avec badges de provenance ($✓$$\checkmark$ noyau).

• Décomposition (waterfall) — décomposition pas-à-pas de $cValAdj$$cValAdj$ avec les puces de sensibilité ±10% : pour chaque entrée principale (population, gain, adoption), l'impact d'une variation de ±10% sur la valeur ajustée. C'est la version « bornée » de la règle v1 §10 every number explains itself.

• Graphique 36 mois — courbe de valeur totale, courbe de cash, coût cumulé, marqueur de payback. Animations d'entrée déterministes.

• Carte de décision — action recommandée par le noyau avec raisonnement et gates requis.

• Cycle de vie — état courant + boutons des transitions autorisées par kernel/lifecycle.js. Chaque transition recalcule l'action recommandée et ajoute un événement lifecycle_transition à decision_events (AC11).

• Affiner ce scénario — boutons + Bundle d'itération (export vers LLM) et Modifier (clone ou édition en place).

Variante ambitieuse

En cliquant sur Ambitieux, les multiplicateurs SCEN deviennent $g\times 1,2$$g \times 1{,}2$, $a\times 1,3$$a \times 1{,}3$, $k_{\text{scen}}=0,9$$k_{\text{scen}} = 0{,}9$. Toutes les sorties sont recalculées en temps réel — y compris le waterfall, le ROI, le payback et les fragilités. La vue d'origine reste intacte ; on peut donc explorer plusieurs hypothèses sans polluer l'enregistrement canonique.

4.4 Priorisation

La vue Priorisation combine la matrice du portefeuille avec une table triable sur huit colonnes : titre, famille, valeur ajustée, confiance RICE, risque, effort, score, statut. La colonne Action affiche le verdict du noyau (chip de couleur) — pas une étiquette manuelle.

C'est la vue à présenter en revue de portefeuille : elle permet en un coup d'œil de hiérarchiser les projets et d'identifier les quick wins (haut/droite de la matrice).

4.5 Comparaison

La vue Comparaison superpose deux projets sur :

• une trajectoire 36 mois (deux courbes + marqueurs de payback),

• un tableau métrique avec colonne $\mathrm{\Delta }$$\Delta$ codée par couleur (vert = amélioration, rouge = dégradation),

• un guide vertical de survol JS qui affiche les valeurs mois par mois.

C'est l'outil à utiliser pour arbitrer entre deux options similaires (par exemple : RAG conformité vs Voicebot relation client).

4.6 Suivi & Contrôle

La vue Suivi & Contrôle ne montre que les projets actifs (statut $\in \{\text{validé},\text{en cours},\text{déployé}\}$$\in \{\text{validé}, \text{en cours}, \text{déployé}\}$). Pour chaque projet avec des données de réalisation (realized_values), le noyau émet une action recommandée post-déploiement :

Le tableau Valeur réalisée vs projetée détaille les écarts à M+3, M+6, M+12 sur quatre métriques (utilisateurs, adoption, gain IA, valeur ajustée).

Le bouton + Enregistrer une décision ouvre une modale dédiée qui expose la suggestion du noyau et son raisonnement, puis demande à l'utilisateur de confirmer ou de surcharger. Une décision enregistrée n'altère jamais le statut du cycle de vie (invariant AC11) ; elle est purement consultative et auditée.

4.7 Définition (assistant 4 blocs)

L'assistant de définition remplace le copier-coller JSON par une interface en quatre blocs.

Bloc A — Problème métier

Champs textuels et listes déroulantes : titre, famille IA, domaine métier, entité, description courte, hypothèse de valeur en une phrase. Les champs textuels ne déclenchent pas de recalcul du noyau (le texte ne déplace pas les nombres).

Bloc B — Population & baseline

Curseurs numériques pour $N$$N$, $J$$J$, $t$$t$, $c$$c$ avec étiquettes en français et codes techniques en gris. Le rail Aperçu en direct recalcule à chaque mouvement de curseur ($\sim$1 ms).

Bloc C — Hypothèses de valeur

Curseurs pour $g$$g$, $a$$a$, $k_{\text{scen}}$$k_{\text{scen}}$, budget, run, taux de monétisation. Quatre curseurs (N, c, g, a) ont un bouton Justifier qui ouvre un panneau de saisie d'hypothèses :

Le panneau capture :

• Source (business_estimate, benchmark_or_hypothesis, observed_data, regulatory_benchmark),

• Confiance (low / medium / high),

• Évidence (texte libre),

• Gate de falsification (critère mesurable qui invaliderait l'hypothèse).

Ces données sont écrites dans assumptions.{champ} et survivent à l'export / réimport (AC-W4A-7).

Bloc D — Gouvernance & recevabilité

Cinq cases readiness gates ($el[5]$$el[5]$), cinq cases prismes stratégiques, quatre options de risque IA Act, sept curseurs RICE-like.

Barre d'actions

xxxxxxxxxx
Annuler · Enregistrer le brouillon · Exporter JSON · Ajouter au portefeuille

• Annuler — abandonne le brouillon (avec confirmation si modifié).

• Enregistrer le brouillon — stocke en sessionStorage (perdu à la fermeture de l'onglet).

• Exporter JSON — produit un bundle conforme au schéma data/schema.llm-input.json, téléchargeable.

• Ajouter au portefeuille — valide via le schéma, lance le noyau, ajoute à state.evaluated avec provenance.kind = "user_authored".

4.8 Importer un scénario LLM

La modale d'import accepte un bundle JSON conforme à la version 0.1.1 du schéma. Le bloc optionnel llm_analysis est restitué dans le tiroir d'analyse mais n'est jamais lu par le noyau (AC3).

Le bouton Charger l'exemple insère un bundle de démonstration (data/sample-llm-input-with-analysis.json) qui illustre la convention attendue d'un agent LLM.

⚠ Ne jamais coller de données confidentielles d'entreprise dans un LLM public. Utiliser un environnement LLM privé approuvé pour les données sensibles (gate G2).

4.9 Tiroir JSON

Le tiroir { } JSON (en haut à droite) affiche, pour le projet sélectionné, trois onglets :

• Input — l'entrée canonique normalisée par le noyau,

• Output — la sortie complète d'evaluateProject (métriques, décomposition, fragilités, action recommandée),

• Session — le bundle complet (entrée + sortie + comparaisons + métadonnées).

C'est le seul endroit du cockpit où apparaissent les codes bruts du schéma (scenK, cm, el[5], …). L'interface partout ailleurs utilise des étiquettes françaises.

4.10 Aide en ligne

Le bouton ? dans la barre du haut (ou la touche ? du clavier) ouvre un panneau d'aide qui glisse depuis la gauche, sans masquer le reste du cockpit. Trois onglets :

• Sans LLM — explorer le portefeuille (Bibliothèque, Priorisation, Comparaison, Suivi & Contrôle), manipuler un projet (Variante, Cycle de vie, sensibilité ±10%), créer ou éditer (+ Nouveau projet, Modèle, Modifier, Justifier), sauvegarder ou partager (brouillon, JSON, tiroir).

• Avec LLM — Mode A REST avec liens directs vers /api/openapi.json, /api/tools et /api/kernel/version ; Mode B URL avec les formats #importz= (compact) et #import= (simple), et les limites de taille ; importation et raffinement (+ Importer scénario LLM, + Bundle d'itération, URL partage).

• Concepts clés — provenance (✓ ✎ ✏), invariants AC3/AC4/AC8/AC11/G7, architecture du noyau, variantes SCEN low/base/high, note ADOPT-001, lien vers le présent manuel.

Touche Esc pour fermer. Visible sur toutes les vues. Le panneau ne capte pas les clics tant qu'il est fermé (pointer-events: none).

5. Provenance — la primitive centrale

Toute valeur affichée dans le cockpit porte exactement un des trois marqueurs de provenance :

Règle de conflit (AC8) : lorsqu'une revendication LLM diverge d'une sortie noyau, les deux sont affichées côte-à-côte avec un tag ⚠ Divergence et l'écart en pourcentage. La valeur du noyau n'est jamais écrasée. L'arbitrage revient à l'humain.

6. Modes d'utilisation

6.1 Mode A — sans humain (REST)

Cette voie (Wave 5A, livrée — déployée à https://valueadservio.pages.dev/api/) expose le noyau verbatim sous HTTP. Elle permet à un agent LLM, à un script batch ou à un service tiers de tester des centaines de variations sans intervention humaine. Le noyau ne stocke rien ; chaque appel est une fonction pure de son entrée.

18 endpoints — 4 GET (métadonnées) + 14 POST (compute) :

xxxxxxxxxx
GET  /api/kernel/version                    → { kernel_version, generated_at }
GET  /api/kernel/lifecycle/transitions      → table des transitions autorisées
GET  /api/kernel/policy/recommendation      → seuils de recommandation
GET  /api/kernel/policy/falsification       → seuils de fragilité

POST /api/kernel/normalize                  → applique alias legacy + défauts
POST /api/kernel/validate                   → validation JSON-Schema-lite
POST /api/kernel/evaluate                   → évaluation déterministe complète
POST /api/kernel/evaluate-variant           → SCEN low / base / high
POST /api/kernel/evaluate-portfolio         → agrégat sur N projets
POST /api/kernel/aggregate                  → agrégation à partir de projets déjà évalués
POST /api/kernel/falsify                    → 10 règles de fragilité
POST /api/kernel/recommend                  → action recommandée (pré- ou post-déploiement)
POST /api/kernel/reconcile                  → kernel ↔ revendications LLM (AC5/AC8)
POST /api/kernel/realize                    → écart projeté/réalisé M+3/M+6/M+12
POST /api/kernel/compare                    → similarité entre projets et références
POST /api/kernel/simulate                   → bundle simulation-output complet
POST /api/kernel/lifecycle/transition       → mutation lifecycle (deep-clone, AC11-clean)
POST /api/kernel/lifecycle/event            → événement de décision (deep-clone, AC11-clean)

Découverte automatique pour agents LLM :

• GET /api/openapi.json — spec OpenAPI 3.1 complète (compatible Swagger UI, Stoplight, Anthropic Tool Use, OpenAI function calling).

• GET /api/tools — descripteurs prêts à coller : format Anthropic ({name, description, input_schema}) et format OpenAI ({type:"function", function:{...}}), tous générés depuis la même source de vérité (functions/api/_registry.js).

Enveloppe de réponse uniforme :

xxxxxxxxxx
{ "ok": true,  "operation": "evaluate", "kernel_version": "0.1.0",
  "created_at": "2026-04-29T22:30:00Z", "result": { ... } }

{ "ok": false, "operation": "evaluate",
  "error": { "code": "VALIDATION_ERROR", "message": "...", "details": [...] } }

Codes d'erreur : VALIDATION_ERROR · UNSUPPORTED_MEDIA (415) · METHOD_NOT_ALLOWED (405) · PAYLOAD_TOO_LARGE (413, > 1 MiB) · KERNEL_THREW (500). Aucune trace d'exécution n'est jamais retournée. Voir docs/api.md pour le contrat de transport complet et les exemples curl.

6.2 Mode B — avec humain (cockpit + URL)

xxxxxxxxxx
1. agent LLM produit un scénario JSON conforme au schéma
2. agent encode le bundle dans une URL fragment
   https://valueadservio.pages.dev/#importz=<base64url(deflate(JSON))>
3. utilisateur clique sur l'URL
4. cockpit ouvre l'assistant pré-rempli avec le scénario proposé
5. humain révise (curseurs, panneaux de justification),
   décide d'enregistrer brouillon, d'exporter JSON, ou d'ajouter au portefeuille
6. cockpit n'envoie rien au serveur — toute persistance est locale
   (sessionStorage) ou explicite (export JSON)

Cette voie (Wave 5B, livrée) supprime le copier-coller tout en gardant l'humain dans la boucle : l'agent propose, l'humain dispose.

Deux formats de fragment :

• #importz=<base64url(deflate(JSON))> — compact, par défaut (~36% plus petit que la forme simple ; ≈ 500 octets pour un projet typique).

• #import=<base64url(JSON)> — compatibilité, sans déflation (utile pour les LLM qui n'ont pas d'exécution de code et ne peuvent pas appliquer deflate).

Limites : 8 000 caractères par fragment ; 128 KiB de JSON décodé ; mono-projet uniquement (mode: "project"). Au-delà, préférer l'API REST (Mode A) ou l'import JSON manuel.

Génération depuis le cockpit : un bouton « URL partage » est disponible à deux endroits — sur la barre d'actions de l'assistant Définition (à côté d'Exporter JSON) et sur la carte d'affinement de la vue Simulation (à côté de + Bundle d'itération). Il copie automatiquement l'URL dans le presse-papiers.

Garanties : le fragment d'URL n'est jamais envoyé au serveur (contrairement à un paramètre ?import=...). Il est validé contre le schéma data/schema.llm-input.json avant tout chargement ; un bundle invalide affiche une bannière d'erreur sans modifier l'état. Le fragment est nettoyé de la barre d'URL après chargement (history.replaceState) — un rafraîchissement n'importe pas une seconde fois.

7. Garanties et limites

7.1 Ce que le démonstrateur garantit

• Reproductibilité : entrée identique → sortie identique, à toutes les versions taggées du dépôt. Le noyau in-process (cockpit) et le noyau REST (/api/kernel/*) produisent les mêmes nombres pour les mêmes entrées.

• Auditabilité : chaque commit est une politique. Les seuils sont externalisés dans data/policy.*.json. La spec REST est régénérée depuis un registre unique (functions/api/_registry.js) — pas de dérive possible entre exports kernel, handlers HTTP, et descripteurs OpenAPI/tools.

• Non-pollution LLM : aucune sortie numérique du cockpit ne provient d'un LLM. Le LLM propose, le noyau dispose. AC8 : la valeur du noyau n'est jamais écrasée par une revendication LLM.

• Souveraineté : aucun appel sortant depuis le noyau. Aucune clé API stockée côté client. Aucun service tiers requis. L'URL fragment (#importz=) ne quitte jamais le navigateur.

• Sans build : le démonstrateur fonctionne sur un simple serveur HTTP statique. Aucun Webpack, aucun Vite, aucun React. Les Pages Functions de Cloudflare exécutent directement les modules ES du noyau (V8 sans transpilation).

7.2 Ce que le démonstrateur ne garantit pas

• Exactitude économique des coefficients par défaut (les valeurs de $b_k$$b_k$ pour les prismes, les seuils de recommandation, les tolérances de réconciliation). Ces paramètres ont été calibrés pour produire des résultats vraisemblables sur les 7 fiches d'amorçage ; ils doivent être ré-étalonnés sur des données réelles avant tout usage en pilote.

• Confidentialité sur le déploiement public *.pages.dev : l'URL n'est pas authentifiée. Pour des données sensibles, ajouter Cloudflare Access ou déployer sur un endpoint privé (gate G2).

8. Aller plus loin

Pour toute question, ré-implémentation, ou ré-étalonnage : olivier.vitrac@adservio.fr

ValueAdservio — Adservio Innovation Lab — Groupe Adservio, France. Privé — développé pour l'usage interne d'Adservio. Non redistribuable.