Une question saisie, quelques secondes d’attente, une réponse impeccable : la démonstration a fait son effet. Mais qui a préparé les documents ? Que se passe-t-il quand une donnée manque ? Et combien coûte la centième utilisation ? De VivaTech au RAISE Summit, les vitrines de l’innovation rendent les promesses tangibles. Elles montrent moins volontiers la plomberie qui les rend durables. Le vrai passage à l’échelle commence quand le prototype quitte son environnement protégé.
À l’horizon de septembre 2026, cette question fournit une grille de lecture des annonces technologiques. L’analyse qui suit s’appuie sur des tendances déjà documentées, notamment depuis l’essor de l’IA générative, et propose des perspectives ; elle ne prétend pas rendre compte d’annonces vérifiées des éditions 2026. L’enjeu dépasse d’ailleurs l’IA : robotique, logiciels industriels et services connectés rencontrent souvent les mêmes obstacles.
Le salon expose une possibilité, pas un système
VivaTech, rendez-vous parisien lancé en 2016, rassemble startups, grands groupes et investisseurs autour d’un éventail technologique large. Le RAISE Summit, dont la première édition s’est tenue à Paris en 2024, se concentre sur l’intelligence artificielle. Leur fonction est précieuse : rapprocher des acteurs qui ne se rencontreraient pas nécessairement, provoquer des essais, accélérer des décisions. Mais leur format récompense d’abord la lisibilité immédiate.
Sur un stand, le parcours est court, les entrées souvent sélectionnées, l’équipe technique à proximité. Dans une entreprise, les utilisateurs improvisent, les fichiers changent, les logiciels tombent en panne. Un assistant peut résumer brillamment un contrat et échouer sur une annexe scannée. Un robot peut réussir un geste répétitif et perdre ses repères face à un emballage déformé. La démonstration prouve qu’une tâche est possible dans certaines conditions ; l’industrialisation exige de définir lesquelles.
Les données : présentes, mais pas forcément utilisables
Premier malentendu : posséder des données ne signifie pas pouvoir les exploiter. Dans beaucoup d’organisations, l’information est dispersée entre messageries, dossiers partagés, logiciels métiers et bases historiques. Les doublons côtoient des versions périmées. Une référence client peut changer d’un système à l’autre. Avant même de choisir un modèle, il faut déterminer quelle source fait autorité et qui répond de sa qualité.
Prenons un cas fictif : un assistant destiné au service après-vente. Le prototype fonctionne sur un lot de notices nettoyées. Pour le déployer, il doit distinguer les générations de produits, retrouver les conditions de garantie applicables et respecter les droits d’accès. S’il fournit une procédure obsolète avec aplomb, la fluidité de sa réponse devient un risque plutôt qu’un progrès.
La génération augmentée par récupération, ou RAG, s’est imposée comme une approche courante pour relier un modèle à un corpus documentaire. Elle peut améliorer la pertinence et faciliter l’affichage des sources. Elle ne corrige toutefois ni un document erroné ni une permission mal configurée. Indexer, actualiser, supprimer et tracer les contenus reste un travail d’ingénierie et de gouvernance, pas un simple branchement.
L’intégration : là où commence le véritable produit
Deuxième épreuve : entrer dans les outils existants. Une interface séparée peut séduire pendant un essai, puis être abandonnée parce qu’elle oblige à recopier des informations. La valeur apparaît lorsque le service intervient au bon moment dans le logiciel de relation client, la gestion des stocks ou le traitement des dossiers. Encore faut-il disposer d’interfaces techniques stables et d’autorisations adaptées.
Les assistants capables d’exécuter des actions rendent ce chantier plus sensible. Suggérer un remboursement et le déclencher sont deux responsabilités différentes. Il faut fixer des plafonds, demander une validation humaine pour certaines opérations et empêcher qu’une instruction malveillante contenue dans un document soit traitée comme un ordre légitime. L’autonomie utile n’est pas l’absence de contrôle : c’est un périmètre d’action explicite.
À cela s’ajoutent des exigences rarement spectaculaires : journaliser les opérations, surveiller les erreurs, revenir à une version antérieure, maintenir un mode dégradé. Si un fournisseur modifie son modèle ou son tarif, qui teste les conséquences ? Si le service devient indisponible, le travail peut-il continuer ? Un produit industrialisé se reconnaît aussi à sa manière d’échouer.
Le coût réel se cache après la première réponse
Troisième filtre : l’économie. Le prix d’un appel à un modèle n’est qu’une ligne du budget. Il faut compter la préparation des données, les connecteurs, l’hébergement, la sécurité, l’assistance et la supervision humaine. Une baisse du coût unitaire peut être absorbée par davantage d’utilisations ou par des traitements plus longs. La facture dépend du service complet, pas seulement de son moteur.
Le bon indicateur n’est donc pas nécessairement le nombre de requêtes. Pour un support client, mieux vaut regarder le coût d’un dossier effectivement résolu, sans réouverture ni dégradation de satisfaction. Pour un outil de programmation, la vitesse de production du code doit être rapprochée du temps de relecture, des défauts et de la maintenance. Gagner quelques minutes visibles peut déplacer davantage de travail ailleurs.
Un modèle économique défendable suppose aussi de comprendre ce que le client achète durablement. Une interface autour d’un modèle tiers peut être utile, mais reste exposée si son fournisseur propose une fonction similaire. La différenciation peut venir d’une intégration métier difficile à reproduire, d’un savoir-faire opérationnel ou d’un accès légitime à des données spécifiques. Encore faut-il que cet avantage survive au renouvellement du contrat.
Passer du pilote à une preuve mesurable
Pour éviter le prototype perpétuel, l’expérimentation doit annoncer ses critères de sortie avant de commencer. Un périmètre réduit suffit, s’il représente le travail réel : utilisateurs ordinaires, cas incomplets, contraintes de temps. Il faut comparer le résultat à une situation de référence et prévoir une décision possible d’arrêt. Un essai qui révèle une impasse peut éviter un investissement bien plus coûteux.
Les questions à poser après la démonstration
- Données : quelles sources sont utilisées, avec quels droits et quelle fréquence de mise à jour ?
- Fiabilité : quels échecs sont connus, comment sont-ils détectés et qui reprend la main ?
- Intégration : quels outils doivent changer et qui assurera la maintenance ?
- Économie : quel coût complet par résultat utile, supervision comprise ?
Ces questions déplacent la discussion du prestige technologique vers la responsabilité opérationnelle. Elles obligent aussi à réunir métiers, informatique, sécurité, achats et représentants des utilisateurs. Sans propriétaire clairement identifié, les arbitrages s’enlisent : chacun apprécie la démonstration, personne ne porte le service. Le passage à l’échelle est autant une transformation du travail qu’une augmentation de capacité informatique.
Et maintenant ? Pour la suite de 2026, une hypothèse paraît raisonnable : la sélection pourrait se déplacer des démonstrations les plus impressionnantes vers les solutions capables de documenter leur fonctionnement quotidien. VivaTech et RAISE Summit resteraient alors des lieux de découverte, mais la décision se jouerait ailleurs, sur des dossiers réels et des coûts complets. Le prochain avantage concurrentiel ne sera pas forcément de promettre davantage d’autonomie. Il pourrait être de prouver, limites comprises, qu’une innovation tient ses engagements.
