Comme la plupart des équipes, nous avons d'abord payé un outil de démo vidéo clé en main. Puis nous avons fait le compte des combinaisons : deux thèmes, sept langues, et une interface qui change presque chaque semaine. Le calcul ne tombait pas juste. Alors nous avons construit notre propre studio de démonstration — et qu'une équipe de deux personnes ait pu le faire, en quelques jours, en dit plus long que l'outil lui-même.
Le problème : une démo, ce n'est pas 1 vidéo mais 14
promptShield existe en thème clair et thème sombre, et en sept langues — anglais, français, allemand, espagnol, italien, néerlandais et portugais. Une seule démo produit — « voici comment caviarder un contrat » — n'est donc pas un simple clip. C'est 2 thèmes × 7 langues = 14 rendus, montrant chacun exactement les mêmes gestes sur une interface qui doit sonner juste dans la langue et rester exacte dans le thème.
Multipliez maintenant par chaque démo du site marketing, puis n'oubliez pas que l'application, en dessous, est une cible mouvante. Nous revoyons des mises en page, renommons des boutons, resserrons les espacements et ajoutons des fonctionnalités chaque semaine. Chacun de ces changements périme en silence des enregistrements tournés sur les anciens écrans.
Pourquoi l'approche SaaS a fini par craquer
Les outils du type Arcade / Storylane / Supademo / Trupeer excellent dans leur domaine : vous parcourez votre application en cliquant, ils filment l'écran, et vous ressortez avec une visite guidée soignée. Mais ils reposent tous sur un même postulat — celui qu'une démo est une capture de pixels figée. Et c'est exactement ce postulat qui vole en éclats à notre échelle :
- L'explosion combinatoire se fait à la main. Quatorze variantes d'une démo, c'est quatorze prises tournées à la main. Personne n'enregistre le même parcours quatorze fois de suite sans écarts, et retourner la version allemande en mode sombre six semaines plus tard pour qu'elle s'aligne sur les autres n'a rien d'un après-midi réjouissant.
- Le moindre remaniement de l'interface rend tout caduc d'un coup. Déplacez un bouton, et chaque enregistrement qui s'appuyait dessus devient subtilement faux. Comme l'enregistrement n'est que des pixels, impossible de le « rejouer » — vous refaites la prise, à la main, quatorze fois, pour chaque démo touchée par le changement.
- La localisation, c'est un second métier. Le SaaS filme la langue qui se trouvait à l'écran, quelle qu'elle soit. Garder sept versions linguistiques d'une douzaine de démos parfaitement synchronisées avec le produit, c'est un poste de rédaction à temps plein que nous n'avons pas et ne voulons pas.
La conclusion, en toute franchise, c'est que cette catégorie d'outils est pensée pour un monde où l'on réalise une démo une fois et où elle reste fidèle pendant des mois. Notre monde est l'inverse : la démo doit être régénérée en permanence, dans chaque thème et chaque langue, à partir d'un produit qui ne tient jamais en place.
L'atout que nous avions déjà
Voici l'élément qui a rendu la fabrication maison raisonnable plutôt que téméraire. Notre page publique /demo ne fait pas semblant d'être l'application — elle monte le vrai frontend de l'application de bureau dans le navigateur : les mêmes composants React, le même CSS, la même i18n, avec les appels au backend remplacés par des mocks. Chaque modification d'interface apportée à l'application de bureau se retrouve déjà automatiquement dans la démo, parce que la démo est l'application.
Autrement dit, nous n'avions pas besoin d'un outil pour « capturer » notre application. Il nous fallait un outil pour la piloter — et puisque l'application tourne déjà dans le navigateur et sait déjà s'afficher dans n'importe quel thème et n'importe quelle langue, les axes du thème et de la langue étaient offerts d'emblée.
Ce que nous avons construit
En interne, nous l'appelons Demo Studio. Le changement de perspective est minime et il change tout : nous enregistrons un script d'actions, pas une vidéo de pixels.
Enregistrer par démonstration
Vous activez le mode capture et parcourez le flux une fois, dans une langue, un thème. Le Studio ne filme pas l'écran. Il enregistre ce que vous avez fait — une liste d'événements sémantiques : « cliquer sur cet élément », « faire défiler jusqu'ici », « ouvrir ce panneau » — chacun rattaché à un sélecteur identifiable, aux conditions préalables dont il a besoin et à un horodatage. À la relecture, l'élément cliqué clignote pour que le spectateur suive l'action, sans rien du suivi de curseur saccadé auquel les enregistreurs d'écran se heurtent.
Un script, quatorze rendus
Ce script unique est ensuite confié à un navigateur sans interface qui le rejoue et en capture le résultat — une fois par thème, une fois par langue. Une seule session d'enregistrement produit les quatorze vidéos WebM et les images fixes correspondantes, de façon déterministe, parce que c'est le même script qui pilote la même application réelle, le thème et la langue étant réglés à chaque passage. La version allemande en mode sombre et la version anglaise en mode clair montrent forcément les mêmes gestes, puisqu'elles sortent du même script.
Une timeline d'effets — et une IA qui les propose
Par-dessus la relecture brute s'ajoute une timeline pour les finitions qu'exige une bonne démo : zoomer sur une zone, faire clignoter une commande, poser un sous-titre en surimpression. Il y a aussi une étape « Ask Claude » qui suggère une piste d'effets pour un script, si bien que le premier jet du « où faut-il zoomer ? » vous est proposé tout fait, au lieu d'être calé image par image.
Des emplacements qui restent fiables tout seuls
Chaque endroit où une démo apparaît sur le site est un <DemoMedia slot="..."/> dans le code. Le Studio balaie tout le code source à leur recherche et vous montre, d'un coup d'œil, quels emplacements sont entièrement enregistrés dans chaque thème et chaque langue, lesquels attendent encore un rendu, et quels dossiers de médias sont devenus orphelins parce que l'emplacement auquel ils étaient rattachés a été supprimé. C'est l'outil qui vous signale ce qui est périmé, plutôt que de l'apprendre d'un client.
L'économie s'est discrètement retournée
L'essentiel, dans tout cela, ce ne sont pas les fonctionnalités. C'est ce qu'est devenue la courbe des coûts. Avec le SaaS, le coût marginal d'une modification d'interface, c'était « retourner chaque démo concernée, quatorze fois chacune, à la main ». Avec Demo Studio, le coût marginal d'une modification d'interface, c'est appuyer sur « re-render ». Le script reste valable — il décrit des actions, et les actions existent toujours — donc le correctif coûte du temps machine, pas du temps humain.
Ajouter une nouvelle langue, cela voulait dire autrefois retourner chaque démo dans cette langue. Ce n'est plus qu'une valeur de plus sur l'axe des langues. Ajouter un thème, même histoire. Le travail qui croissait autrefois de façon linéaire avec (thèmes × langues × démos × cadence des versions) croît désormais avec le nombre de parcours distincts, et tout le reste n'est que du rendu.
Le phénomène plus large dont tout ceci n'est qu'un symptôme
Pendant des décennies, la réponse par défaut à « il nous faut un outil pour X » était « louons-le ». Le construire soi-même coûtait cher, prenait du temps et détournait de votre vrai produit ; toute une industrie a donc prospéré en vendant des outils spécialisés, facturés au poste, chacun faisant à peu près l'affaire pour tout le monde. La ligne de partage entre faire soi-même et louer penchait nettement du côté « louer », et la plupart des outils internes se retrouvaient du mauvais côté d'un coût de fabrication que personne ne pouvait justifier.
Cette ligne s'est déplacée. Avec un agent de codage IA dans la boucle, une petite équipe peut aujourd'hui construire un outil interne sur mesure — taillé pour son problème précis, et non pour la moyenne des problèmes d'un millier de clients — dans le temps qu'il fallait naguère pour comparer des fournisseurs. Demo Studio n'a pas été un chantier d'un trimestre. Ce fut une poignée de journées bien ciblées, et il colle à notre réalité — deux thèmes, sept langues, en mouvement perpétuel — mieux qu'aucun produit généraliste ne le pourra jamais, parce qu'il a été bâti pour exactement cela et rien d'autre.
Voilà la partie sur laquelle il vaut la peine de s'arrêter. Une grande part de l'écosystème du logiciel-service (SaaS) repose sur l'ancienne économie du faire ou louer — sur l'idée que construire sa propre version d'un outil spécialisé n'est pas rentable, et que vous paierez donc à l'utilisateur indéfiniment. Quand le coût de fabriquer la chose sur mesure s'effondre, cette idée cesse de tenir. Les outils les plus exposés ne sont pas les plateformes profondes, difficiles à reproduire ; ce sont les plus minces — les produits « nous faisons un seul flux, bien propre, et le facturons à chaque utilisateur » qu'une équipe compétente peut désormais monter en interne, ajustés pile à sa propre forme, en un après-midi.
Nous n'avons pas construit un studio de démonstration par envie de faire le métier des outils de démo. Nous l'avons construit parce qu'il est soudain revenu moins cher de bâtir la bonne chose que de continuer à nous débattre avec celle que nous louions. Ce calcul va se faire, discrètement, dans beaucoup d'entreprises ces prochaines années — et chaque fois qu'il se fera, un peu plus de ce qui était un abonnement deviendra un week-end de code qui vous appartient pleinement.
Le lien avec ce que nous faisons
C'est le même réflexe qui anime promptShield lui-même. La réponse dominante à « laissez l'IA vous aider avec vos documents » consiste à confier vos fichiers à un service cloud et à vous en remettre aux conditions d'utilisation. Nous pensons que la meilleure réponse, dès lors que l'outil est assez peu coûteux à bien construire, est de garder les données sur votre machine et de n'envoyer à l'IA que le strict nécessaire. Demo Studio, c'est ce même réflexe tourné vers l'intérieur : quand fabriquer la chose sur mesure devient bon marché, cessez de louer le compromis.
