IA cosmétique ou IA utile : le test avant de signer

Vous ouvrez une proposition pour moderniser une plateforme métier. Le dossier comporte douze fonctions IA : analyse prédictive du carnet de commandes, agent de recherche dans les archives fournisseurs, classification automatique des tickets support, génération de rapports de clôture, résumé des échanges clients, extraction de données depuis les factures. Chaque bloc technique est illustré, chiffré, documenté. La question n'est pas de savoir s'il y a de l'IA, la question est de savoir ce qui change si on la retire.

Le réflexe standard consiste à demander le ROI de chaque module. C'est nécessaire, mais insuffisant : un ROI se calcule après avoir fixé le périmètre, et c'est justement le périmètre que vous êtes en train de valider. Avant de chiffrer le retour sur investissement, vous avez besoin d'un instrument qui sépare, fonction par fonction, ce qui est porteur de ce qui est décoratif. Ce test existe, il tient en quatre questions, et il s'applique à tout bloc IA d'une proposition, quel que soit le secteur ou la technologie.

Cet article vous livre le test à quatre questions, le contre-test symétrique rarement formulé (demander au fournisseur où l'IA n'apporte rien chez vous), et une grille de notation prête à joindre à votre consultation. Il est écrit strictement côté acheteur : l'objectif n'est pas d'évaluer le prestataire, mais d'évaluer la proposition elle-même, et de conclure si nécessaire qu'un bon prestataire vous a proposé trois fonctions IA de trop. Chez ClaroDigi, nous accompagnons cette évaluation via notre service de transformation IA et notre offre de conseil digital qui inclut l'audit critique des propositions fournisseurs avant signature.

La question n'est pas 'y a-t-il de l'IA' mais 'que perd-on en la retirant'

Une proposition contient douze fonctions IA. Vous retirez mentalement la fonction numéro 3. Que se passe-t-il ? Si la réponse est « quelqu'un doit reprendre cette tâche manuellement, mais on continue à avancer », la fonction est accessoire. Si la réponse est « un processus métier s'arrête, une décision ne peut plus être prise, ou un délai réglementaire est manqué », la fonction est porteuse.

La distinction ne porte pas sur l'utilité théorique, elle porte sur le fait qu'une tâche ou une décision disparaît sans cette fonction. Un module de résumé d'email est utile si vous recevez 200 emails par jour ; il est porteur si sans lui votre équipe support ne peut pas traiter les demandes dans les SLA contractuels. Un agent de recherche dans les archives est pratique si vous cherchez souvent dans les anciens dossiers ; il est porteur si sans lui vous ne retrouvez pas les informations nécessaires pour répondre à un audit ou à une mise en demeure.

Le test de retrait permet de repérer immédiatement deux catégories de fonctions qui gonflent les propositions sans valeur structurante :

1. Les doublons technologiques : deux modules différents qui couvrent la même décision ou la même tâche critique. Exemple : un moteur de recommandation produit et un chatbot qui recommande également des produits à partir du même catalogue. Vous retirez l'un des deux, le processus métier continue. Un seul suffit.

2. Les modules de confort : une fonction qui améliore l'expérience utilisateur sans bloquer aucune décision. Exemple : un résumé automatique en haut de chaque rapport. Si ce résumé disparaît, le lecteur passe trois minutes de plus à lire le rapport complet, mais aucune décision n'est retardée et aucun SLA n'est menacé. C'est un confort, pas une fonction porteuse.

Le critère de retrait n'élimine pas ces fonctions définitivement, il les renvoie en phase 2. Une phase 1 doit concentrer les budgets et les risques sur les fonctions sans lesquelles le système ne fonctionne pas. Les modules de confort peuvent arriver après, quand vous avez vérifié que les fonctions porteuses tiennent la charge.

Le test à quatre questions, appliqué fonction par fonction

Le test de retrait est le premier filtre. Si une fonction le passe (quelque chose s'arrête sans elle), vous appliquez ensuite quatre questions qui séparent une fonction IA porteuse d'une fonction qui finira désactivée après trois mois. Ces quatre questions s'appliquent à chaque fonction IA de la proposition, module par module.

1. Quelle décision ou quelle tâche disparaît si on retire cette fonction ?

Si la réponse est floue ou commence par « ça facilite », « ça accélère », « ça améliore », c'est un signal d'alerte. Une fonction porteuse a une réponse claire et factuelle. Exemples de bonnes réponses :

• « Sans ce module, l'équipe achats ne peut plus identifier les fournisseurs en retard de livraison dans les 24 heures. »
• « Sans ce module, le contrôleur de gestion ne peut plus rapprocher les engagements budgétaires et les factures reçues avant la clôture mensuelle. »
• « Sans ce module, le service client ne peut pas retrouver les conditions commerciales applicables à chaque dossier dans le délai contractuel. »

Si la réponse n'identifie pas une tâche ou une décision précise qui disparaît, la fonction n'est pas porteuse. Elle peut être utile, mais elle ne doit pas entrer dans le périmètre de phase 1.

2. Qui déclenche cette fonction, et à quelle fréquence réelle ?

Une fonction IA qui n'est jamais appelée en production coûte exactement comme une fonction qui tourne en permanence, mais elle ne crée aucune valeur. Vous devez donc exiger du fournisseur un scénario d'usage nominal avec un acteur identifié et une fréquence réaliste.

Exemples de fréquences réalistes à demander :

• Un agent de recherche dans les archives fournisseurs : déclenché par qui (acheteur, gestionnaire de contrats, auditeur interne) ? combien de fois par semaine ?
• Un module de classification automatique des tickets support : combien de tickets entrants par jour ? est-ce que ce volume justifie une automatisation, ou est-ce qu'un responsable support peut encore trier manuellement en 20 minutes ?
• Un résumé automatique des rapports mensuels : combien de rapports par mois ? combien de lecteurs par rapport ? est-ce que ces lecteurs lisent effectivement le résumé, ou est-ce qu'ils vont directement aux tableaux de chiffres ?

Si le fournisseur vous répond « ça dépend », « selon les besoins », ou « on verra à l'usage », la fonction n'a pas de cas d'usage nominal. Vous êtes en train de payer pour une option qui ne sera peut-être jamais utilisée. Mettez-la en phase 2 ou retirez-la.

3. Que se passe-t-il quand cette fonction se trompe ?

Toute fonction IA se trompe. La question n'est pas de savoir si elle se trompe, mais ce qui arrive quand elle se trompe. Une fonction porteuse a une réponse documentée à cette question, avec un plan de détection et de correction. Une fonction décorative n'a pas de plan, parce que personne n'a pensé au risque.

Exemples de scénarios d'erreur à demander :

• Un agent de génération de contrats : si le contrat généré contient une clause erronée ou une valeur mal calculée, qui le détecte avant signature ? dans quel délai ? avec quel impact si l'erreur n'est pas détectée avant signature ?
• Un module de classification automatique des tickets : si un ticket urgent est classé à tort en priorité basse, dans combien de temps le détecte-t-on ? est-ce qu'un SLA est menacé ?
• Un résumé automatique d'un rapport mensuel : si le résumé omet un point critique ou contredit un chiffre du rapport, qui s'en rend compte ? quel est l'impact si le résumé erroné circule en interne ou en externe ?

Si le fournisseur répond « le modèle est très fiable », « on va surveiller les métriques », ou « on pourra toujours corriger après », vous n'avez pas de plan de gestion d'erreur. Une fonction IA qui n'a pas de plan de détection et de correction des erreurs n'est pas prête pour la production. Mettez-la en phase 2, le temps de construire ce plan.

4. Combien coûte cette fonction à l'usage, et non à la construction ?

La plupart des devis décrivent le coût de construction d'une fonction IA (jours de développement, paramétrage, tests, formation). Très peu décrivent le coût d'usage : combien coûte chaque appel API au modèle, combien coûte le stockage des données en entrée et en sortie, combien coûte la supervision humaine nécessaire pour détecter et corriger les erreurs.

Le coût d'usage peut être dix fois supérieur au coût de construction sur trois ans, et il apparaît souvent comme une surprise en phase de run. Avant de valider une fonction, vous devez exiger deux lignes séparées dans le devis :

1. Coût de construction : combien pour développer, tester et déployer la fonction (forfait ou régie).
2. Coût d'usage estimé : combien par mois en production, sur la base du volume d'usage nominal décrit à la question 2.

Si le fournisseur ne peut pas estimer le coût d'usage, c'est qu'il n'a pas modélisé le volume d'appels ni le coût unitaire des API. Vous êtes en train d'acheter une fonction dont vous ne connaissez pas le coût total. Demandez une fourchette basse et haute, et prévoyez un mécanisme de révision si le volume réel s'écarte de plus de 30 % du volume estimé.

Une fonction qui passe les quatre questions (tâche ou décision identifiée, acteur et fréquence réalistes, plan d'erreur documenté, coût d'usage estimé) est une fonction porteuse. Une fonction qui tombe sur l'une des quatre est une fonction qui doit sortir du périmètre de phase 1 ou être clarifiée avant signature.

La fréquence réelle d'usage : le critère que personne ne vérifie avant de payer

Vous avez un module IA qui coûte 25 000 € à développer et 400 € par mois à faire tourner. Le fournisseur vous dit qu'il sera « très utile pour les cas complexes ». Vous signez. Trois mois après le go-live, vous regardez les logs d'usage : le module a été appelé quatre fois. Coût par usage réel : 6 475 €. Vous venez de payer un module qui aurait pu être remplacé par un email au prestataire à chaque fois que le cas complexe se présentait.

Ce scénario est fréquent, et il est évitable si vous posez la question de la fréquence réelle avant de signer. La question n'est pas « est-ce que ce module est utile », la question est « combien de fois par semaine ce module sera-t-il réellement appelé en production ». Si le fournisseur ne peut pas répondre, c'est qu'il n'a pas modélisé le volume d'usage.

Voici comment obtenir une estimation de fréquence réaliste :

1. Identifier l'acteur déclencheur : qui appelle cette fonction ? Un utilisateur final ? Un processus automatisé ? Un administrateur ? Combien d'acteurs de ce type avez-vous dans l'organisation ?

2. Reconstituer le volume actuel : combien de fois aujourd'hui cette tâche est-elle effectuée manuellement ou via un autre outil ? Si vous automatisez une tâche que personne ne fait aujourd'hui, la fonction ne sera pas utilisée après le déploiement.

3. Appliquer un coefficient de friction : même si la fonction automatise une tâche fréquente, tous les utilisateurs ne vont pas l'adopter immédiatement. Un coefficient de 50 % la première année est réaliste (la moitié des usages théoriques deviennent des usages réels). Un coefficient de 100 % suppose une formation parfaite et une adoption instantanée, ce qui n'arrive jamais.

4. Vérifier l'alignement avec le coût d'usage : si la fonction sera appelée 10 fois par mois et que chaque appel coûte 8 € en API, le coût mensuel est de 80 €. Si elle sera appelée 500 fois par mois, le coût mensuel est de 4 000 €. Les deux scénarios ne justifient pas le même budget de construction.

Si le fournisseur résiste à cet exercice, c'est un signal d'alerte. Un prestataire sérieux a modélisé les volumes d'usage, ne serait-ce que pour dimensionner correctement son infrastructure. S'il ne peut pas vous donner de fourchette, vous êtes en train d'acheter une fonction dont personne ne sait si elle sera utilisée.

Coût à l'usage contre coût de construction : les deux lignes à séparer dans le devis

Un devis standard pour un projet IA présente le coût de développement : tant de jours de conception, tant de jours de développement, tant de jours de tests, tant de jours de formation. Ce que le devis ne montre pas, c'est combien coûte la fonction une fois qu'elle tourne en production. Ce coût d'usage est composé de trois postes :

1. Coût d'API : chaque appel à un modèle de langage (GPT-4, Claude, Gemini) coûte entre 0,01 € et 2 € selon la taille du modèle et la longueur des entrées et sorties. Si une fonction est appelée 1 000 fois par mois avec un coût moyen de 0,50 € par appel, le coût mensuel d'API est de 500 €, soit 6 000 € par an.

2. Coût de stockage : si la fonction IA génère ou ingère des documents (fiches produit, rapports, factures), ces documents doivent être stockés. Un volume de 10 To coûte environ 200 € par mois en stockage cloud standard, soit 2 400 € par an. Si le volume croît de 30 % par an, le coût de stockage en année 3 est de 4 056 € par an.

3. Coût de supervision humaine : toute fonction IA qui produit un contenu à destination d'un client, d'un partenaire ou d'une autorité de régulation doit être supervisée. Un superviseur à mi-temps coûte environ 24 000 € par an. Si la fonction génère 50 documents par mois et que chaque document nécessite 10 minutes de relecture, le coût de supervision est de 8,3 heures par mois, soit 0,2 ETP, soit environ 4 800 € par an.

Coût total d'usage pour cette fonction sur trois ans : (6 000 + 2 400 + 4 800) × 3 + ajustement stockage = environ 42 000 €. Si le coût de construction était de 30 000 €, le coût total sur trois ans est de 72 000 €, dont 58 % en coûts d'usage. Si vous n'aviez budgété que les 30 000 € de construction, vous êtes en dépassement de 140 % à l'année 3.

Avant de signer, exigez du fournisseur un devis séparé en deux sections :

• Section 1 : coût de construction (forfait ou régie, avec détail des phases).
• Section 2 : coût d'usage estimé (mensuel et annuel, avec détail API + stockage + supervision, sur la base du volume d'usage décrit à la question 2 du test).

Si le fournisseur ne peut pas remplir la section 2, vous n'avez pas de visibilité sur le coût total du projet. Refusez de signer tant que cette section n'est pas documentée. Un bon prestataire a déjà calculé ces chiffres pour dimensionner son infrastructure ; il n'a aucune raison de les cacher.

Ce qui doit sortir de la phase 1, et pourquoi le refus de périmètre est un bon signal

Une phase 1 doit se concentrer sur les fonctions sans lesquelles le système ne peut pas fonctionner. Tout le reste, aussi utile soit-il, doit sortir du périmètre ou passer en phase 2. Ce tri est la mission de l'acheteur, pas celle du fournisseur : un fournisseur a intérêt à maximiser le périmètre, vous avez intérêt à le minimiser.

Voici trois catégories de fonctions qui doivent systématiquement sortir d'une phase 1 :

Les modules de confort

Un module de confort améliore l'expérience utilisateur sans débloquer aucune décision critique. Exemples : un résumé automatique en haut de chaque rapport, un chatbot de FAQ interne, une génération automatique de titres pour les documents partagés. Ces modules sont utiles, mais ils ne changent pas structurellement la capacité de l'organisation à fonctionner.

Critère de tri : si vous retirez ce module, est-ce qu'un processus métier s'arrête ou est-ce qu'un SLA est menacé ? Si la réponse est non, le module va en phase 2. Vous le ferez après avoir vérifié que les fonctions porteuses tiennent la charge.

Les doublons technologiques

Deux modules différents qui couvrent la même décision ou la même tâche critique. Exemple : un moteur de recommandation produit basé sur l'historique d'achat, et un chatbot qui recommande également des produits à partir des préférences déclarées. Les deux modules sont porteurs si vous les prenez isolément, mais ensemble ils sont redondants. Un seul suffit.

Critère de tri : identifiez toutes les décisions et toutes les tâches critiques couvertes par la proposition. Si deux modules couvrent la même décision ou la même tâche, gardez celui qui a le meilleur ratio (valeur métier / coût + complexité), et mettez l'autre en phase 2 ou retirez-le.

Les fonctions sans acteur identifié

Une fonction IA qui n'a pas d'acteur déclencheur clair (qui l'appelle, quand, pourquoi) ne sera jamais utilisée en production. Exemple : un module de génération de rapports avancés « pour les cas exceptionnels » sans préciser qui les demande ni à quelle fréquence. Si le fournisseur ne peut pas nommer l'acteur et estimer la fréquence, la fonction n'a pas de cas d'usage nominal.

Critère de tri : appliquez la question 2 du test (qui déclenche cette fonction, et à quelle fréquence réelle ?). Si le fournisseur ne peut pas répondre avec un acteur nommé et une fréquence chiffrée, la fonction sort du périmètre.

Le refus de périmètre est souvent interprété comme un signe de rigidité. En réalité, c'est un signal de maturité acheteur : vous avez compris que la phase 1 n'est pas un catalogue de toutes les fonctions possibles, mais un socle minimal qui doit fonctionner en production avant d'ajouter quoi que ce soit d'autre. Un fournisseur qui accepte de réduire son périmètre de phase 1 sans résistance vous montre qu'il a compris cela. Un fournisseur qui résiste à toute réduction de périmètre est en train de maximiser son chiffre d'affaires à court terme, pas de maximiser vos chances de succès.

Le contre-test : demander au fournisseur où l'IA n'apporte rien chez vous

Le test à quatre questions identifie les fonctions IA porteuses. Le contre-test symétrique, rarement formulé, consiste à demander au fournisseur : « Dans mon dossier, où est-ce que l'IA n'apporte rien ? » Un fournisseur qui répond « partout où on l'a proposée, elle apporte quelque chose » est en train de vendre, pas de diagnostiquer.

Un bon prestataire a une réponse précise à cette question. Exemples de bonnes réponses :

• « Votre équipe achats fait déjà un bon travail de suivi fournisseurs avec un fichier Excel actualisé chaque semaine. Automatiser ce suivi avec de l'IA ne vous fera gagner que 2 heures par semaine, ce qui ne justifie pas les 18 000 € de développement. On peut garder l'Excel et investir ce budget ailleurs. »

• « Vous avez 15 tickets support par semaine. Un agent de classification automatique ne sert à rien à ce volume, votre responsable support peut trier manuellement en 20 minutes. On retire ce module. »

• « Votre catalogue produit contient 80 références. Un moteur de recommandation IA n'a pas assez de données pour être meilleur qu'une règle métier simple (par exemple : recommander les trois produits les plus vendus de la même catégorie). On peut faire ça avec une requête SQL, pas besoin d'un modèle. »

Ce contre-test a deux vertus :

1. Il révèle la posture du fournisseur. Un fournisseur qui refuse de répondre ou qui balaie la question (« tout est utile », « on verra à l'usage ») n'est pas en train de vous conseiller, il est en train de maximiser son périmètre. Un fournisseur qui identifie spontanément deux ou trois fonctions inutiles dans votre contexte est en train de faire un diagnostic honnête. Vous pouvez lui faire confiance sur les fonctions qu'il recommande.

2. Il force le fournisseur à argumenter ses choix. Une fonction IA qui survit au contre-test (« non, dans votre cas celle-ci est vraiment nécessaire, et voici pourquoi ») a été validée deux fois : une fois dans le sens positif (elle apporte quelque chose), une fois dans le sens négatif (retirer l'IA ici serait une erreur). Ce double filtre élimine les fonctions décoratives.

Posez systématiquement cette question dans vos consultations : « Dans notre dossier, où est-ce que l'IA n'apporte rien, et pourquoi ? » Si le fournisseur ne peut pas répondre, mettez-le en concurrence avec un fournisseur qui peut.

La grille de notation à joindre à votre consultation

Vous lancez une consultation pour moderniser une plateforme métier avec des fonctions IA. Vous recevez cinq offres. Chacune propose entre huit et quinze fonctions IA. Comment comparer ces offres de manière objective, sans se laisser impressionner par le volume de fonctions proposées ?

La grille ci-dessous note chaque fonction IA de 0 à 4 points selon les réponses aux quatre questions du test. Une fonction qui totalise 4 points est porteuse. Une fonction qui totalise 0 ou 1 point est décorative ou insuffisamment spécifiée. Une fonction qui totalise 2 ou 3 points est en zone grise : elle peut devenir porteuse si le fournisseur clarifie certains points.

Notation d'une offre : additionnez les points de toutes les fonctions proposées. Une offre avec 12 fonctions à 2 points en moyenne (24 points au total) est moins bonne qu'une offre avec 6 fonctions à 4 points (24 points au total aussi, mais avec deux fois moins de complexité et de risques).

Seuil de qualification : toute fonction qui totalise moins de 3 points doit être clarifiée avant signature, ou retirée du périmètre de phase 1. Si un fournisseur refuse de clarifier, éliminez l'offre.

Cette grille peut être jointe à votre cahier des charges comme critère de recevabilité : « Toute offre doit documenter, pour chaque fonction IA proposée, les quatre éléments suivants : tâche ou décision couverte, acteur déclencheur et fréquence d'usage, plan de gestion d'erreur, coût d'usage estimé. Les offres qui ne documentent pas ces éléments ne seront pas évaluées. »

FAQ

Peut-on appliquer ce test à une plateforme SaaS qui intègre déjà de l'IA ?

Oui. Une plateforme SaaS avec IA intégrée (par exemple Salesforce Einstein, HubSpot AI, ou Monday.com AI) doit passer le même test fonction par fonction. Identifiez chaque fonction IA proposée par la plateforme, posez les quatre questions (quelle tâche disparaît, qui l'utilise et à quelle fréquence, que se passe-t-il en cas d'erreur, combien ça coûte à l'usage), et décidez si vous activez cette fonction ou non. Le fait qu'une fonction soit incluse dans l'abonnement ne signifie pas qu'elle est utile dans votre contexte. Beaucoup de plateformes SaaS facturent des suppléments pour les modules IA avancés ; appliquez le test avant de payer.

Comment évaluer une fonction IA qui améliore la qualité d'une décision sans la rendre possible ?

Une fonction IA qui améliore la qualité d'une décision déjà prise manuellement (par exemple : un moteur de recommandation qui suggère trois fournisseurs au lieu d'un seul) doit être évaluée selon le gain de qualité mesurable. Posez la question : combien de décisions incorrectes ou sous-optimales sont prises aujourd'hui sans cette fonction, et quel est le coût de ces erreurs ? Si ce coût est supérieur au coût total de la fonction sur trois ans, la fonction est justifiée. Si ce coût est inférieur ou non mesurable, la fonction va en phase 2.

Un fournisseur nous dit que certaines fonctions IA ne peuvent pas être chiffrées avant d'avoir testé en production. Est-ce normal ?

Non. Un fournisseur peut avoir une marge d'incertitude sur le coût d'usage (par exemple : entre 300 € et 600 € par mois selon le volume réel), mais il ne peut pas refuser de donner une fourchette. Si le fournisseur refuse de chiffrer, c'est qu'il n'a pas modélisé le volume d'appels ni le coût unitaire des API. Vous êtes en train d'acheter une fonction dont vous ne connaissez pas le coût total. Exigez une fourchette basse et haute avec les hypothèses de volume, et prévoyez une clause de révision si le volume réel s'écarte de plus de 30 % des hypothèses.

Que faire si une fonction obtient 2 ou 3 points sur 4 au test ?

Une fonction à 2 ou 3 points est en zone grise. Elle a des éléments de valeur, mais elle n'est pas complètement spécifiée. Demandez au fournisseur de clarifier les points manquants avant de la valider. Par exemple : si la fonction a 1 point sur le critère « acteur et fréquence » (pas de fréquence chiffrée), demandez une estimation de fréquence avec les hypothèses de calcul. Si le fournisseur refuse ou ne peut pas, retirez la fonction du périmètre de phase 1. Une fonction en zone grise peut devenir porteuse si elle est clarifiée, ou décorative si elle reste floue.

Comment gérer un fournisseur qui résiste à la réduction de périmètre ?

Un fournisseur qui résiste systématiquement à toute réduction de périmètre est en train de maximiser son chiffre d'affaires, pas de maximiser vos chances de succès. Deux options : soit vous imposez le périmètre réduit et vous vérifiez que le fournisseur accepte sans friction (un bon prestataire comprend l'intérêt d'une phase 1 concentrée), soit vous mettez ce fournisseur en concurrence avec un autre qui accepte le découpage phase 1 / phase 2. La résistance au découpage est un signal d'alerte : un prestataire mature sait qu'une phase 1 trop chargée augmente les risques d'échec, et il a intérêt à ce que vous réussissiez pour décrocher la phase 2. Notre offre AI Transformation Sprint adopte précisément cette approche de périmétrage incrémental.