La démo n’est pas le produit

Vous l’avez probablement déjà vu : quelqu’un de votre équipe, ou une amie fondatrice, construit en un après-midi la démo fonctionnelle d’une vraie idée de produit. Il y a des écrans, des données, ça répond. Il y a cinq ans, cette démo était une conversation à 40 000 $ avec une agence. Aujourd’hui, c’est un prompt.

La question est donc légitime, et des acheteurs nous en posent une version chaque mois : si la démo est gratuite, pourquoi le logiciel sur mesure coûte-t-il encore des dizaines de milliers de dollars?

Ce qui s’est réellement effondré

La réponse honnête commence par être d’accord. Le coût de production d’un logiciel plausible s’est effondré. Générer des écrans, échafauder une base de données, brancher un formulaire sur une API : c’est exactement le travail où les outils d’IA excellent, et un studio qui ne transmet pas cette vitesse à ses clients facture un effort qui n’existe plus. Nos propres soumissions sont plus basses et nos échéanciers plus courts qu’ils ne l’auraient été en 2022, précisément pour cette raison.

L’argent a suivi. Menlo Ventures a mesuré des dépenses d’IA en entreprise qui ont à peu près triplé en un an, d’environ 11,5 à 37 milliards de dollars, dont plus de la moitié va aux applications plutôt qu’aux modèles eux-mêmes (Menlo Ventures, 2025). Les entreprises n’expérimentent plus; elles achètent du logiciel avec de l’IA dedans.

Ce qui ne s’est pas effondré

Un système en production, c’est une démo plus tout ce que la démo a eu le droit de sauter. Les vraies données, toujours plus sales que l’échantillon. Les permissions, parce que dans une vraie entreprise, tout le monde ne peut pas tout voir. Une migration depuis l’endroit où le processus vit aujourd’hui. Puis les cas limites, qui n’ont de limite que le nom : le client avec deux comptes, la commande annulée en plein paiement, l’accent dans un nom qui casse l’index de recherche. Quelqu’un doit savoir que la synchronisation de nuit a échoué avant que le client s’en aperçoive, et quelqu’un doit en répondre ensuite. C’est cette dernière partie qu’aucun modèle ne fournit.

La sécurité est la version mesurable de cet écart. La recherche de Veracode sur le code généré par IA a trouvé qu’environ 45 % des échantillons générés introduisaient des failles de sécurité connues, du type de celles du top 10 de l’OWASP (Veracode, 2025). Le code tournait. Il faisait belle figure en démo. Il était aussi, environ une fois sur deux, dangereux à mettre devant le public avec de vraies données derrière.

Rien de ce travail n’est spectaculaire, et presque rien n’apparaît dans une démo. C’est pourtant l’essentiel de ce que vous achetez quand vous achetez du logiciel qui touche vos revenus, vos données et vos clients.

Comment acheter dans ce marché

La conclusion pratique n’est pas « méfiez-vous du logiciel construit avec l’IA ». Nous construisons avec l’IA tous les jours, et la vitesse est réelle. La conclusion, c’est que la démo a cessé d’être une preuve. Avant, un prototype fonctionnel prouvait qu’une équipe savait construire; maintenant, il prouve qu’elle sait écrire un prompt. Les questions qui séparent un produit d’une démo doivent donc être posées directement :

1. Y a-t-il une spécification écrite, et qui l’a écrite? Pas une présentation commerciale : un document avec la portée, les données, les intégrations, les risques et les critères d’acceptation. Si personne ne peut le produire, personne n’a décidé ce que « terminé » veut dire.
2. À qui appartiennent le dépôt de code et l’infrastructure? La réponse devrait être vous, dès le premier jour. Toute autre réponse revient à payer pour devenir dépendant.
3. Qu’est-ce qui est livré avec le lancement? La surveillance des erreurs, les mesures d’utilisation et le chiffre que le système doit faire bouger devraient faire partie de la livraison, pas d’une phase future.
4. Qui répond quand ça casse à 21 h? Un nom, pas une file de billets. Si le plan du constructeur pour les incidents de production est « il n’y en aura pas », demandez ce qui arrivera la première fois qu’il se trompera.

Un vendeur qui a de bonnes réponses à ces quatre questions mérite d’être payé en argent réel, que ce soit nous ou non. Un vendeur qui ne les a pas vous vend une démo avec une date de livraison.

Nous avons écrit nos propres réponses dans la façon dont AetherWorks vend : une Découverte payante qui produit la spécification avant qu’un développement soit soumissionné, des prix fixes tirés de cette spécification, de l’instrumentation dans chaque livraison et des Opérations après le lancement pour que quelqu’un surveille. Cette structure existe parce que ces quatre questions méritent des réponses structurelles.

Si vous envisagez un projet de ce genre en ce moment, réservez une Découverte : une à deux semaines, une spécification écrite, une soumission ferme et une date. Au pire, vous repartez propriétaire de la spécification.