La méthode · RealMock
Entrez dans l’application.
Rien de réel n’y est exposé.
Un RealMock est le double statique et complet d’une application : ses vrais écrans, les données d’une société inventée, une explication sur chaque bouton, et des parcours qui se rejouent pas à pas. Il se sert comme une simple page web, et il ne risque rien.
On y entre par l’écran de connexion de l’application, avec l’adresse et le mot de passe de son choix. Derrière, aucun serveur applicatif : les écrans sont des pages figées, les données viennent de fichiers statiques, et tout ce qui se tape reste dans le navigateur. Rien n’est envoyé, rien n’est écrit.
Les vrais écrans
Mêmes menus, mêmes formulaires, mêmes enchaînements que l’application en service. Les écrans sont relevés sur la recette, à la version en cours, puis rendus à l’identique.
Des données inventées
Une seule société fictive, Exemplia SAS, avec ses clients, ses comptes, ses domaines en
.example et ses clés marquées DEMO. Les noms des applications et des actions, eux, restent vrais.
Une aide à trois niveaux
Au survol, une bulle de quelques mots. Sur « + », l’explication en clair. Sur « ++ », la fiche complète pour les équipes techniques : l’action appelée, ses paramètres, ce qu’il faut savoir.
Des parcours rejoués
Un parcours guide d’écran en écran : la cible est entourée, les champs sont préremplis, et le panneau avance quand le formulaire mène à la page suivante.
À quoi il ressemble
On entre comme si c’était le sien
L’écran de connexion est celui de l’application. On y tape ce qu’on veut : la porte s’ouvre, puisqu’il n’y a rien derrière à protéger. Le visiteur arrive chez Exemplia SAS, une société qui opère sa propre plateforme.
Un univers inventé, et cohérent
Exemplia a ses clients : une menuiserie, un cabinet d’expertise comptable, une agence de voyages, un organisme de formation en attente de validation, un client suspendu. Ses adresses sont des adresses de documentation, ses dates tombent à l’automne 2026. Un seul univers sert tous les RealMock : les démonstrations se répondent entre elles.
Chaque élément dit ce qu’il fait
Bouton, champ, colonne : chacun porte sa bulle. Les identifiants de ces fiches sont choisis pour servir deux fois : demain, l’aide intégrée de la vraie application lira la même base.
Les parcours se rejouent dans les écrans
Le panneau d’étape montre ce qu’on fait et pourquoi. Quand un formulaire est validé, la démonstration montre la route et l’action que le vrai système exécuterait, avec ses paramètres, sans rien exécuter.
Pourquoi un RealMock
Montrer une application, c’est d’ordinaire ouvrir une vraie instance : il faut un serveur qui tourne, des comptes à créer, des données à inventer puis à remettre à zéro chaque nuit, et le risque qu’une donnée réelle apparaisse à l’écran. Le RealMock retire tout cela.
Montrer sans exposer
Aucune donnée réelle n’entre dans la démonstration, et un contrôle automatique le vérifie avant chaque publication. On peut l’ouvrir devant n’importe qui.
Voir avant de commander
Un prospect parcourt les écrans de sa future plateforme, à son rythme, sans rendez-vous ni compte d’essai. Il sait ce qu’il commande.
Former un utilisateur
Les parcours guidés racontent les gestes du métier un par un. L’utilisateur s’exerce sans craindre de casser quoi que ce soit.
Documenter pour un intégrateur
La fiche « ++ » de chaque élément va jusqu’à l’action appelée et ses paramètres : les mêmes actions qu’un agent IA appelle par MCP et qu’un programme appelle par REST.
Et il ne coûte rien à faire tourner : une page web statique, sans base, sans écriture, sans remise à zéro à surveiller.
Comment on le fabrique
La fabrication est une méthode écrite, outillée, et suivie par des agents IA. Elle se déroule en neuf lots, et s’arrête trois fois pour une décision du commanditaire.
Lot 0 — Situer
Relever la version qui tourne en recette, lire le code de cette version précise, vérifier que le compte de tests de la recette a bien accès à tout. Le RealMock décrit ce qui tourne, pas ce qu’on croit.
Lot 1 — Inventaire
Tous les écrans, champs, boutons, colonnes, actions et enchaînements, relevés dans le code et rangés par familles. Première validation : l’inventaire est-il complet ?
Lot 2 — Univers et contrôle
Compléter l’univers Exemplia, construire le dictionnaire qui remplace chaque valeur réelle par sa valeur fictive, dresser la liste des écrans sensibles. Le dictionnaire reste privé : il contient les vraies valeurs, il n’est jamais publié.
Lot 3 — Page modèle
Un seul écran, fait complètement : relevé, substitution, aide à trois niveaux, un enchaînement rejoué, vérifié dans un vrai navigateur. Deuxième validation, celle qui compte le plus : est-ce le bon niveau de fidélité et de détail ?
Lot 4 — Une chaîne en une commande
Toute la fabrication se rejoue d’une seule commande. Une fiche d’aide qui ne trouve plus son élément est signalée, jamais supprimée en silence.
Lot 5 — L’aide de tous les écrans
Un agent par famille d’écrans, en parallèle, sur des consignes communes. Chaque lot d’aide passe un vérificateur : forme, cible trouvée, aucune fuite, et ce qui reste sans aide.
Lot 6 — Les parcours
Cinq à neuf parcours de cinq à huit étapes, écrits comme des récits, puis vérifiés : chaque page existe, chaque cible est trouvée, chaque fiche citée existe.
Lot 7 — Publier
Le contrôle anti-fuite doit rendre zéro. Troisième validation : relecture et feu vert. Puis la démonstration est publiée comme une application derrière le Hub, en recette d’abord, et la même version ensuite en production.
Lot 8 — Mettre en avant
Une page « Essayer » sur chaque site : quatre captures, une carte par parcours, un lien vers la démonstration, un bandeau sur l’accueil et une entrée de menu.
Les trois validations
À chaque arrêt, on montre une capture, on pose une question, et on attend la réponse. Rien n’est publié avant le troisième.
① Après l’inventaire
L’inventaire est-il complet ? L’ordre des familles convient-il ? Un écran oublié ici serait absent de la démonstration.
② Après la page modèle
Est-ce le bon niveau de fidélité et de détail ? Tout le reste reproduit ce modèle : c’est le moment où une correction coûte le moins.
③ Après le contrôle
Relecture de la démonstration complète, puis feu vert de mise en ligne. C’est un humain qui décide, pas le script.
Le contrôle anti-fuite
Le relevé des écrans se fait en lecture seule, sur la recette, avec le compte de tests : aucun formulaire soumis, aucun bouton d’action cliqué. Les écrans « après une action » sont reconstruits, pas obtenus en agissant. Les écrans sensibles (messages, journaux, consignes des agents, secrets) ne reprennent aucune donnée réelle : leurs contenus sont écrits pour la démonstration.
Puis un script relit tout ce qui va être publié, et bloque la publication à la moindre trace d’une valeur du dictionnaire, d’un nom exclu, d’un domaine réel, d’une adresse de courrier réelle, d’une adresse réseau routable, ou d’un jeton qui n’annonce pas qu’il est faux.
Le script constate, un humain relit
Sur la démonstration du Hub, le contrôle final a porté sur 4 941 fichiers : zéro fuite. Avant d’en arriver là, il avait arrêté deux raisons sociales réelles, cachées dans une liste déroulante qu’aucune relecture à l’œil n’avait vue.
L’exemple en ligne : le Hub TheSocle
Le premier RealMock est celui du Hub, la plateforme qui sert toutes nos applications. Il a été fabriqué en trois jours de travail effectif, du 28 octobre au 2 novembre 2026 : l’inventaire et la page modèle le premier jour, la chaîne, l’aide des huit familles et les neuf parcours le deuxième, la publication après les arrêts du commanditaire.
- 120+
écrans reproduits - 9
parcours rejoués pas à pas - 61
étapes racontées - 8 785
éléments expliqués
Chaque parcours s’ouvre directement à sa première étape.
Accueillir un nouveau client
Créer son espace, son administrateur et ses droits. Six étapes.
Installer une application
Choisir une application du catalogue, l’installer sous un nom propre au client, vérifier sa route et son authentification unique. Cinq étapes.
Brancher le domaine d’un client
Enregistrement DNS, certificat, route du proxy, puis cache. Six étapes.
Monter le courrier d’un domaine
Confier le domaine au serveur de courrier, vérifier son DNS et sa signature, créer les boîtes, faire monter la réputation. Huit étapes.
Publier une API
La déclarer à la passerelle, lui donner sa portée, la mettre en service, attribuer un plan au client, qui crée ensuite sa clé. Huit étapes.
Ouvrir l’accès à un développeur
Son compte, un rôle aux portées choisies, une clé rangée au coffre, et la documentation des actions qu’il va appeler. Sept étapes.
Confier une tâche à Alfred
Choisir les actions que l’agent pourra appeler, lui confier un relevé quotidien des certificats, puis le suivre. Six étapes.
Mettre la plateforme sous sauvegarde
Déclarer un stockage, le tester, planifier, lancer un passage tout de suite, puis lire son résultat. Huit étapes.
Surveiller la plateforme
Le tour du matin : l’état des workers, la supervision externe et ses alertes, les sondes du courrier, les journaux. Sept étapes.
Le sommaire de la démonstration mène à tous les parcours et à tous les écrans : ouvrir le sommaire.
Ce qui est éprouvé, et ce qui ne l’est pas encore
Éprouvé : les pages rendues par le serveur
Le Hub construit ses pages côté serveur. On relève donc le HTML de chaque écran, et on publie des pages figées. C’est le chemin qui a produit la démonstration en ligne.
Conçu : les applications en React
Nos applications construisent leurs écrans dans le navigateur. Il faudra relever leurs réponses de données et faire répondre une couche à la place du serveur. Ce chemin est écrit, pas encore éprouvé : un premier RealMock d’application servira de pilote avant de le généraliser.
Une application de la flotte compte de dix à trente écrans, quand le Hub en a plus de cent vingt. Le pilote, lui, demandera davantage que le chemin déjà éprouvé : nous le dirons quand il sera mesuré.
Questions fréquentes
Faut-il un compte pour entrer ?
Non. L’écran de connexion accepte l’adresse et le mot de passe de votre choix : il n’y a rien derrière à protéger.
Ce que je tape est-il envoyé quelque part ?
Non. La démonstration est une suite de pages statiques. Les formulaires montrent ce que le vrai système ferait, sans rien envoyer ni rien écrire.
Les noms et les chiffres sont-ils réels ?
Les noms de personnes, de clients, de domaines, les adresses et les clés sont inventés. Les nombres gardent leur ordre de grandeur, arrondi. Les écrans, les menus et les actions sont ceux de l’application en service.
La démonstration suit-elle les nouvelles versions ?
Elle décrit une version précise, relevée sur la recette. La fabrication se rejoue d’une seule commande : une nouvelle version donne une nouvelle démonstration, publiée sous une étiquette neuve.
Le RealMock de votre application ?
Nous partons de la version qui tourne, et nous nous arrêtons trois fois pour vous la montrer.