Un mardi matin, une directrice de livraison tape cinq mots dans la barre de recherche : outil d'analyse d'affaires IA. Elle ne magasine pas. Son équipe vient de perdre onze semaines sur une fonction de paiement livrée sans chemin de remboursement pour les commandes déjà parties, le genre de trou qui sort dans la file du support trois semaines après le lancement et jamais dans les tests, et elle a un budget approuvé jusqu'à la fin du trimestre pour que ça n'arrive pas deux fois. La première page charge. Des tableaux de bord.
Faites la recherche vous-même, vous allez tomber sur à peu près la même affaire. Des constructeurs de graphiques, de l'analytique conversationnelle, un produit qui transforme un chiffrier en tableau de bord, deux suites de rapports et un palmarès qui les classe, ce qui est une réponse parfaitement raisonnable à une tout autre question que celle qui était posée. Aucun de ces produits ne touche à la conversation que personne n'a eue avec la personne qui gère la facturation. Deux sens. Le plus bruyant gagne.
Donc : une liste de vérification pour acheteur. Écrite par quelqu'un qui vend dans cette catégorie, vous en ferez ce que vous voulez, et qui vous donne quand même les questions, parce que l'autre option c'est un marché où le mot « intelligence » veut dire ce que la page de prix a besoin qu'il veuille dire ce trimestre-là. Six questions. Un tableau. Une règle dure sur les projets pilotes. D'abord, la définition que les résultats de recherche manquent : un outil d'analyse d'affaires IA, c'est un logiciel qui lit la matière brute de la découverte (entrevues, billets, politiques) et fait ressortir les exigences, les contradictions et les hypothèses que personne n'a écrites, au lieu de mettre en graphique des données déjà produites par un système bâti. La raison d'être aussi strict, ce n'est pas la pureté. La plupart de ce qui s'achète ne sert jamais.
Pourquoi la plupart des « outils d'analyse d'affaires IA » sont-ils des tableaux de bord analytiques ?
Parce que deux métiers différents partagent un adjectif, et que le plus gros budget est arrivé le premier dans les résultats. L'analytique d'affaires lit des données qui existent déjà : le chiffre d'affaires par région, l'attrition par cohorte, un graphique qui vous apprend que mars a été ordinaire. L'analyse d'affaires décide ce qu'un système devrait faire avant que quiconque le construise, ce qui veut dire s'asseoir avec du monde, trouver l'endroit où deux personnes tiennent pour acquis le contraire l'une de l'autre, puis écrire la règle qui tranche. L'une lit l'histoire. L'autre décide de la suite, et elle produit du texte et des contraintes plutôt que des graphiques, ce qui est pas mal plus dur à démontrer en onze minutes.
Le moteur de recherche n'est pas mélangé. Les budgets le sont. L'analytique est une catégorie mature avec des milliers de pages qui se battent pour la même expression, alors ce qui se classe sur « outil d'analyse d'affaires IA » vend plus souvent de la visualisation que de la découverte. Ça resterait une petite irritation si les acheteurs bâtissaient encore leur liste courte à la main, en lisant les sites des fournisseurs et en appelant deux collègues. Presque plus personne ne fait ça.
Mettez ce chiffre à côté de la collision de vocabulaire et le problème change de forme. Un modèle qui résume le web hérite de ce que le web a déjà mélangé, puis vous le remet sous forme de liste courte classée, avec assurance et sans note de bas de page. Vos trois premiers candidats ne sont peut-être pas les mauvais fournisseurs. C'est la mauvaise catégorie. J'ai vu une évaluation rouler six semaines avant que quelqu'un dise tout haut que l'outil évalué ne lisait même pas une transcription d'entrevue, parce que personne n'avait pensé à vérifier quelque chose d'aussi élémentaire.
Que devrait vraiment faire un outil d'analyse d'affaires IA ?
Il devrait réduire le nombre de choses que vous ignorez sans savoir que vous les ignorez, avant qu'une ligne de code existe. C'est ça, la job. Le reste de la liste de fonctionnalités, c'est de l'emballage : les formats d'export, les intégrations, l'espace de travail avec les beaux raccourcis clavier, tout ça est agréable et rien de tout ça n'est la raison d'acheter. Un outil mérite le nom quand il change ce que votre équipe sait le jeudi par rapport à ce qu'elle savait le lundi, et le vrai test, c'est de voir s'il a produit une question que votre meilleure analyste n'avait pas déjà écrite.
Je présentais ça comme « écrire de meilleures exigences plus vite ». Ça se vend bien et c'est faux, ou au moins mal ordonné, parce que la vitesse sur la moitié documentation du travail multiplie l'erreur au lieu de la corriger. Mauvais goulot. Une équipe qui écrit une spécification en deux jours au lieu de neuf a gagné sept jours et gardé chaque trou qu'elle avait au départ, ce qui est exactement le marché que propose à peu près tous les produits d'exigences sur le marché.
Quatre verbes comptent. Découvrir : lire la matière brute (transcriptions, billets, la politique que personne n'a ouverte depuis le dernier audit) et faire ressortir ce qui manque au lieu de résumer ce qui est là. Contester : pousser sur une hypothèse au lieu de la mettre en forme. Tracer : relier chaque règle à la décision et à la personne derrière. Transférer : transformer chaque question ouverte en quelque chose qu'un humain nommé peut trancher cette semaine. Une démo qui en montre trois sur quatre, c'est déjà un vrai produit. Une démo qui n'en montre aucun, c'est un très bon assistant de rédaction, et on a déjà argumenté que corriger les phrases qui existent n'est pas la même chose que trouver celles que personne n'a écrites.
Quelles questions distinguent un outil de documentation d'un outil de découverte ?
Six. Et elles marchent mieux posées en direct, avec votre matériel à vous plutôt que le jeu de données de démo du fournisseur. Insistez là-dessus. Un corpus de démo a déjà eu ses ambiguïtés réglées par la personne qui l'a préparé, ce qui enlève tranquillement le signal exact que vous essayez de tester, et un fournisseur confiant dans son produit va dire oui sans négocier.
- Est-ce qu'il documente seulement, ou est-ce qu'il découvre ? Donnez-lui une transcription vraiment incomplète. Un outil de documentation retourne une belle spécification. Un outil de découverte retourne un document plus court et une liste plus longue de ce qu'il n'a pas pu déterminer. Regardez lequel des deux rend l'ingénieur de vente fier.
- Peut-il faire ressortir une exigence manquante ? Demandez un exemple concret tiré de votre propre matériel, à voix haute, pendant la séance. L'esquive sonne comme « il capture tout ce que vos parties prenantes disent ». Capturer ce qui a été dit, c'est la moitié facile. Le chemin de remboursement, personne ne l'avait dit.
- Produit-il un pourquoi traçable ? Prenez une exigence au hasard dans le résultat et demandez d'où elle vient. Vous voulez une décision, une source, une date, idéalement un nom. Vous ne voulez pas la même exigence reformulée avec d'autres mots.
- Va-t-il contester une hypothèse de partie prenante ? Plantez une fausse prémisse dans l'entrée, quelque chose de plausible et faux, comme l'idée que chaque client a exactement un compte de facturation. Voyez si l'outil bâtit dessus ou s'il la signale. La plupart bâtissent dessus.
- Le résultat est-il prêt pour un audit sans qu'un humain le réécrive ? C'est la section suivante, et c'est la question qui sépare un outil utilisable dans un programme réglementé d'un outil qui ne l'est pas.
- Est-ce qu'il s'adapte à votre façon de travailler, ou est-ce à vous de devenir l'outil ? C'est la question chère. C'est là que l'argent part.
La question six mérite plus de méfiance qu'elle en reçoit d'habitude. Tout le monde hoche la tête devant « c'est configurable » pendant la démo, puis découvre qu'adapter le produit à un vrai processus veut dire une demande de changement, un consultant et un trimestre. Demandez plutôt : quelle est la seule chose de notre processus que ce produit ne peut pas accommoder ? Un fournisseur incapable d'en nommer une n'y a pas réfléchi, ou ne vous le dit pas. Les deux sont éliminatoires.
En 2011, Lidl s'est mis à remplacer le système de gestion des marchandises maison qu'il roulait depuis les années 1990, une plateforme SAP pour le détail baptisée eLWIS, et ce n'était pas un petit chantier : environ mille employés et des centaines de consultants y ont travaillé. SAP a publicisé le déploiement en 2015 et a remis un prix client à Lidl en 2017. Puis juillet 2018. Après environ sept ans et 500 millions d'euros rapportés, Lidl a arrêté le projet et est retourné à son ancien système.
La cause rapportée à l'époque est presque trop belle. Deux modèles de prix. Lidl valorisait ses stocks au prix d'achat, et le logiciel de détail standard les valorisait au prix de vente. Plutôt que de changer une pratique interne vieille de décennies, Lidl a demandé qu'on modifie le logiciel pour s'ajuster, et les modifications se sont multipliées jusqu'à ce que les coûts montent et que la performance descende. Le patron du groupe d'utilisateurs SAP germanophone a résumé la leçon en une ligne : une entreprise qui veut utiliser un logiciel standard doit adapter ses propres processus.
Personne là-dedans n'était négligent. Un décalage aussi fondamental, ça ne se voit pas dans une démo, parce que ça vit un étage en dessous de la liste de fonctionnalités, dans ce que le produit tient pour acquis à propos de votre entreprise. C'est la question six. Elle vaut une journée de votre évaluation, pas un hochement de tête.
Sources : Consultancy.uk, « Lidl cancels SAP introduction having sunk 500 million euros into it » et RetailDetail, « Lidl's failed IT project cost half a billion ». Secteur : logiciel d'entreprise en commerce de détail. Le montant de 500 millions d'euros et la durée de sept ans sont ceux rapportés par la presse spécialisée, pas divulgués par Lidl.
Comment évaluer la traçabilité et la préparation à un audit ?
Demandez un export. Lisez-le à froid, et pas à partir d'une capture d'écran d'un joli graphe de dépendances dans le produit, parce que ça a toujours l'air convaincant : un vrai fichier, ouvert par quelqu'un qui n'était pas dans la démo, avec chaque exigence, sa source, son auteur, sa date et la décision d'où elle vient. Si l'export ne peut pas répondre à « pourquoi cette règle existe et qui l'a dit » pour une exigence prise au hasard, la traçabilité est une visualisation, pas un registre.
Trois vérifications. Est-ce qu'une modification d'exigence laisse un historique, ou est-ce qu'elle écrase ? Est-ce que la piste se reconstruit une fois l'outil parti, ou vit-elle dans un format propriétaire qui ne s'affiche que dans le produit ? Et est-ce que l'outil consigne ce qu'un humain a décidé, séparément de ce que le modèle a suggéré ? Cette dernière compte un peu plus chaque trimestre. Le règlement européen sur l'intelligence artificielle impose aux systèmes à haut risque des obligations de journalisation qui présument que vous pouvez montrer votre travail, et l'échéance bouge pendant que l'obligation d'avoir un registre, elle, ne bouge pas.
Une dernière, celle que les acheteurs sautent parce qu'elle a l'air impolie : à qui appartient le résultat, et qu'arrive-t-il à vos transcriptions d'entrevues ? Lisez les clauses de traitement des données en premier. Avant le prix. Un corpus d'exigences, c'est un des artefacts les plus sensibles qu'une entreprise produit, puisqu'il décrit ce que le commerce s'apprête à faire et ce qu'il ne sait pas encore gérer, et il mérite le même examen qu'un flux de données clients.
À quoi ressemble la liste de vérification au complet ?
Le tableau ci-dessous, c'est tout, sur une page. Imprimez-le. Amenez-le en séance et notez chaque fournisseur sur les mêmes lignes, y compris celui que vous pensez tranquillement renouveler, parce qu'un renouvellement, c'est un achat que personne n'a réévalué.
| Demandez ceci | Une vraie réponse ressemble à | Drapeau rouge |
|---|---|---|
| Montrez-moi une exigence manquante dans mon propre matériel | Un trou précis, nommé, avec la raison pour laquelle il compte | « On capture tout ce que vos parties prenantes disent » |
| D'où vient cette exigence ? | Document source, personne, date, décision | L'exigence reformulée autrement |
| Contestez cette hypothèse pour moi | L'outil signale la fausse prémisse que vous avez plantée | Une belle spécification bâtie par-dessus |
| Exportez le registre de traçabilité | Un fichier lisible, avec historique, utilisable sans l'outil | Un graphe dans le produit et aucun export |
| Qu'est-ce que ce produit ne peut pas accommoder chez nous ? | Une limite honnête et précise | « C'est entièrement configurable » |
| À qui appartiennent nos transcriptions et nos résultats ? | Une clause que vous pouvez pointer au contrat | Une assurance verbale et un courriel de suivi |
| Combien coûte un pilote payant de deux semaines sur une capacité ? | Un montant, une portée, une mesure de succès définie | Licence annuelle d'abord, pilote après signature |
La dernière ligne travaille plus fort que les six autres ensemble. Achetez un pilote, pas une plateforme, et choisissez une capacité où une exigence manquée coûte vraiment cher : les paiements, les droits d'accès, tout ce qu'un régulateur lit. Définissez ce que veut dire réussir avant que ça commence, dans une phrase qu'un partenaire des finances accepterait, puis vérifiez honnêtement à la fin même quand la réponse est gênante. Surtout là.
Les finances seront là. Dans la même recherche de G2, leur implication dans les décisions logicielles est passée de 31 % à 46 % en un an, et près de la moitié des acheteurs disent qu'un chef des finances a bloqué une entente déjà approuvée. Voyez ça comme une occasion plutôt qu'un obstacle. Un pilote avec un résultat mesuré survit à cette rencontre. Un deck de vision, non. Et c'est correct de même.
Découverte ou documentation. Le reste, c'est de l'emballage.
La plupart des résultats pour « outil d'analyse d'affaires IA » sont des produits analytiques, et comme 82 % des acheteurs demandent maintenant leurs recommandations à un robot conversationnel qui a appris la même confusion, la mauvaise catégorie arrive sur votre liste avec un air d'autorité. Une question règle ça. Est-ce que l'outil répète ce qu'on vous a déjà dit, ou est-ce qu'il trouve ce que personne n'a dit ?
Ensuite, les six questions, sur votre matériel à vous, pas sur un corpus de démo. Exigez un export. Un que vous pouvez lire sans le produit. Demandez ce que l'outil ne peut pas accommoder chez vous, parce que c'est exactement là que les 500 millions d'euros de Lidl sont partis. Et achetez un pilote payant de deux semaines sur une capacité coûteuse avant d'acheter une plateforme, avec une mesure de succès écrite d'avance, parce que 36 % des licences logicielles d'entreprise restent inutilisées par rapport aux niveaux d'utilisation recommandés et qu'aucune démo n'a jamais prédit lesquelles.
Quelles sont les questions les plus fréquentes sur le choix d'un outil d'analyse d'affaires IA ?
