Une facture arrive, l’assistant la comprend, retrouve le contrat et prépare le paiement. Sur l’écran du stand, tout s’enchaîne sans accroc. Dans l’entreprise, le contrat dort peut-être dans un ancien répertoire, le fournisseur possède trois identifiants et personne n’a autorisé une machine à déclencher un virement. Entre la démonstration et le déploiement, le véritable sujet n’est pas la magie du logiciel, mais les conditions de son fonctionnement. De VivaTech au CES, voici comment transformer l’émerveillement en protocole d’évaluation.
Le salon montre une possibilité, pas une garantie
Les démonstrations reposent généralement sur un environnement préparé : données propres, comptes configurés, réseau disponible et scénario répété. Rien de scandaleux à cela. Un exposant dispose de quelques minutes pour rendre son produit compréhensible. Mais cette mise en scène peut masquer précisément ce qui occupera ensuite la DSI : raccordements, exceptions, sécurité, exploitation et assistance aux utilisateurs.
La vague d’IA générative engagée depuis le lancement public de ChatGPT, fin 2022, a accentué ce décalage. Les interfaces conversationnelles rendent les logiciels immédiatement accessibles, tandis que la qualité des réponses dépend de composants moins visibles : recherche documentaire, modèles, règles métier, outils connectés. Une réponse convaincante n’atteste ni l’exactitude des données ni la légitimité de l’action proposée.
À l’horizon de septembre 2026, l’hypothèse à examiner est celle de logiciels toujours plus capables d’agir, et non seulement de répondre. Cette perspective ne doit pas être confondue avec un bilan des salons de 2026. Elle prolonge une tendance déjà observable dans les assistants et les architectures dites « agentiques » : plus l’outil dispose d’autonomie, plus sa démonstration doit exposer ses limites.
Première épreuve : l’intégration sans les raccourcis
La bonne question n’est pas « Avez-vous un connecteur ? », mais « Que fait exactement ce connecteur ? ». Lit-il les données ou peut-il les modifier ? Respecte-t-il les champs personnalisés ? Comment gère-t-il les doublons, les changements de version et les limitations de débit ? Un logo Microsoft, Salesforce ou SAP sur une diapositive ne répond à aucune de ces questions.
Pour un outil de traitement des factures, le test utile consiste à fournir un petit corpus représentatif, anonymisé si nécessaire : document mal scanné, avoir, devise inhabituelle, référence absente. On observe ensuite le parcours complet, jusqu’au système comptable. Une extraction réussie mais suivie d’une ressaisie manuelle ne constitue pas le même gain qu’une opération réellement intégrée.
Il faut aussi provoquer une panne : couper l’accès à une application, faire expirer un jeton, envoyer deux fois la même demande. Le logiciel reprend-il proprement ? Signale-t-il les opérations incomplètes ? Évite-t-il de créer deux paiements ? Une démonstration d’échec maîtrisé est souvent plus instructive qu’une réussite parfaite.
Deuxième épreuve : les droits, utilisateur par utilisateur
Un assistant qui retrouve « tout » peut impressionner une direction commerciale et inquiéter immédiatement le responsable sécurité. La recherche dans les documents internes doit conserver les restrictions des sources. Un salarié ne devrait pas obtenir, par reformulation, une information issue d’un dossier auquel il n’a pas accès.
Le protocole le plus parlant utilise plusieurs profils : salarié, manager, administrateur et prestataire externe. Tous posent une question similaire. L’évaluation porte sur les réponses, les sources citées et les traces conservées. Puis un droit est retiré : combien de temps faut-il pour que ce changement soit effectif, y compris dans les index et les caches ?
Lorsque le logiciel agit, distinguer consultation, préparation et exécution devient indispensable. Préparer un remboursement n’équivaut pas à le valider. Les actions sensibles doivent pouvoir exiger une confirmation humaine et rester attribuables. Il faut également tester un document contenant une instruction malveillante : un contenu consulté ne doit pas devenir une autorisation de contourner les règles.
Le RGPD reste une référence concrète dès que des données personnelles sont concernées. Le règlement européen sur l’IA, entré en vigueur en 2024 avec une application progressive, renforce aussi la nécessité de qualifier les usages. Cela ne signifie pas que tout assistant relève du même régime : le contexte, la finalité et le rôle de l’entreprise comptent.
Troisième épreuve : calculer le coût du travail terminé
Le prix affiché par utilisateur raconte rarement toute l’histoire. Peuvent s’ajouter les appels aux modèles, l’indexation, le stockage, les connecteurs premium, les environnements de test et l’accompagnement. Dans certaines architectures, une seule demande déclenche plusieurs traitements facturés. Une conversation courte à l’écran peut donc cacher une chaîne technique coûteuse.
Pour comparer les offres, mieux vaut choisir une unité métier : facture correctement comptabilisée, ticket résolu, dossier vérifié. On y ajoute le temps de contrôle, les corrections et la maintenance. Un service peu cher à la requête peut devenir onéreux s’il exige une relecture systématique ou multiplie les tentatives.
Le pilote doit distinguer volume courant, période de pointe et cas difficiles. Demandez des plafonds, des alertes et une simulation contractuelle de montée en charge. Vérifiez aussi ce qui arrive quand le budget est atteint : arrêt, dégradation du service ou dépassement automatique. La prévisibilité financière fait partie de la qualité opérationnelle.
Quatrième épreuve : organiser la sortie avant l’entrée
La réversibilité ne se résume pas à télécharger un fichier CSV. L’entreprise doit savoir récupérer ses documents, leurs métadonnées, les historiques utiles et, selon le produit, les configurations et règles métier. Pour un assistant documentaire, récupérer les fichiers sans leur structure ni leurs autorisations peut rendre la migration laborieuse.
Un exercice simple consiste à demander un export pendant le pilote, puis à l’ouvrir dans un environnement indépendant. Les formats sont-ils documentés ? Les relations entre objets restent-elles compréhensibles ? Quels éléments devront être reconstruits ? Cette vérification révèle mieux la dépendance qu’une clause promettant une coopération future.
Le contrat doit préciser délais, frais, assistance et suppression des données, avec le traitement des sauvegardes. Il faut aussi examiner la dépendance aux sous-traitants : changer de modèle ou d’hébergeur peut modifier performances et conditions de traitement. L’acheteur doit savoir quels changements lui seront signalés et quelles options il conservera.
Une grille courte, mais des preuves obligatoires
Pour éviter le concours de présentations commerciales, la DSI peut imposer une fiche identique à chaque fournisseur. Chaque critère associe une promesse, un test, une preuve et un responsable de validation :
- Intégration : exécuter un parcours métier complet, puis vérifier la reprise après incident.
- Droits : comparer plusieurs profils et contrôler une révocation d’accès.
- Coûts : mesurer la dépense par opération réussie, contrôle humain inclus.
- Réversibilité : exporter les données et vérifier leur réutilisation hors du produit.
Les critères éliminatoires doivent précéder la notation : une fuite de données ne se compense pas par une belle interface. Le pilote gagne aussi à avoir une durée limitée, un périmètre explicite et un processus existant comme référence.
Et maintenant ? Si les assistants gagnent en autonomie, les salons pourraient devenir moins des vitrines de réponses que des démonstrations de contrôle. Aux DSI d’encourager cette évolution : demander les journaux, provoquer les exceptions, examiner la facture et tester la sortie. La promesse intéressante n’est pas celle qui résiste le mieux aux questions sur un stand, mais celle qui reste valable une fois confrontée au travail réel.
