Comment comparer deux devis de prestations IA ?.

Deux propositions IA peuvent afficher des prix proches sans répondre au même besoin. Avant de choisir un prestataire, il faut vérifier la pertinence de l’IA, reconstruire un périmètre commun et comparer les coûts, engagements et dépendances.

Vous avez reçu deux propositions pour automatiser un processus, exploiter vos données ou assister vos équipes. La première propose, par exemple, un agent conversationnel. La seconde prévoit un développement spécifique. Les technologies, les périmètres et les prix diffèrent.

Avant d’acheter une voiture, on commence généralement par se demander si l’on a besoin de se déplacer. À quelle fréquence ? Sur quelle distance ? Avec quelles contraintes de disponibilité, de prévisibilité ou de transport ?

Il devrait en aller de même pour tout achat numérique, intelligence artificielle comprise.

La blockchain et les ETF aussi devaient révolutionner l'économie et la société. Ils sont restés des outils.

Je pratique l'IA depuis plus de dix ans, quand ça s'appelait encore le machine learning. C'est un outil, si performant soit-il.

Les solutions qui vous sont proposées sont probablement très abouties techniquement. Elles peuvent produire une démonstration convaincante et mobiliser des technologies réellement performantes. Et elles le sont. Mais si elles ne répondent pas à votre besoin, vous aurez surtout investi dans une réponse à une question que vous ne vous posiez pas.

Comparer deux propositions IA n’a donc de sens qu’après avoir clarifié le besoin, envisagé les solutions avec et sans intelligence artificielle, puis reconstruit un périmètre commun de comparaison.

S’assurer que le besoin justifie un investissement dans l’IA

L’étude du besoin ne doit jamais être formulée à partir de la technologie proposée.

Autrement dit, le besoin ne devrait pas être exprimé ainsi :

Il pourrait plutôt être formulé de la manière suivante :

Réduire le temps nécessaire pour retrouver une information fiable dans les dossiers antérieurs ou la jurisprudence.

Cette seconde formulation ne présume pas encore de la solution. Elle permet d’envisager plusieurs réponses : améliorer le classement documentaire, revoir les règles d’indexation, enrichir un moteur de recherche, automatiser certaines extractions ou, lorsque cela est pertinent, déployer un outil reposant sur de l’intelligence artificielle.

À lire également : Expérimentation de l'IA dans le système judiciaire.

Cette distinction paraît simple. Elle est pourtant essentielle.

Lorsqu’une organisation formule directement son besoin à partir d’une technologie, elle demande aux prestataires de proposer différentes manières de mettre en œuvre une solution déjà choisie. Elle ne leur demande plus de résoudre le problème.

Les premières questions devraient donc porter sur l’activité elle-même :

Pour enbi, l'objectif n'est pas d'écarter l’intelligence artificielle par principe, mais de vérifier sa valeur ajoutée par rapport aux autres options, afin d'éviter que l'organisation ne s'engage dans des engagements techniques, organisationnels et contractuels qui la dépassent pour répondre à un effet de mode.

Décliner le besoin selon une méthode commune

Une fois le problème clarifié, l’analyse peut être organisée autour de trois questions successives.

Quelle est la problématique et quelle décision doit être éclairée ?

Il faut d’abord préciser la situation actuelle, le résultat recherché, les utilisateurs concernés et les décisions ou actions que la solution est supposée faciliter.

Cette étape doit également permettre de définir les critères qui serviront à juger la réussite du projet.

Une promesse générale de gain de productivité ne suffit pas. Il faut déterminer ce que l’on cherche concrètement à réduire, augmenter ou améliorer : un délai de traitement, un taux d’erreur, un volume d’opérations manuelles, une capacité de recherche ou la qualité d’une décision.

La technologie ne produit pas elle-même cette définition. Elle ne peut intervenir qu’une fois l’objectif qualifié.

De quelles informations avons-nous besoin ?

Il faut ensuite déterminer quelles données ou informations seront nécessaires pour répondre à la problématique.

Où se trouvent-elles ? Qui les produit ? Sous quelle forme existent-elles ? Sont-elles fiables, homogènes, actualisées et suffisamment contextualisées ?

Une information peut être disponible sans être immédiatement exploitable. Elle peut être enfouie dans un document, formulée différemment selon les équipes ou répartie entre plusieurs systèmes.

À l’inverse, une donnée parfaitement structurée peut être très facile à mesurer tout en étant sans rapport avec la question posée.

Quel traitement technique est réellement nécessaire ?

Le besoin technique dépend de l’écart entre l’information recherchée et la forme sous laquelle elle est actuellement disponible.

Selon les situations, il peut suffire de :

Une information déjà structurée et associée à des règles stables ne nécessite pas nécessairement un modèle génératif. Une automatisation classique pourra parfois produire un résultat moins coûteux, plus prévisible et plus facilement contrôlable.

À l’inverse, l’intelligence artificielle peut être justifiée lorsqu’il est nécessaire de traiter des formulations variables, d’extraire des informations dispersées dans des textes ou de rapprocher des contenus difficilement qualifiables par des règles prédéfinies.

Ce n’est qu’à ce stade que les propositions techniques peuvent utilement être évaluées.

Vérifier que les prestataires répondent au même problème

Tout le monde fait de l’IA aujourd’hui. Ou tout le monde s'en prévaut.

Il s’agit pourtant d’un périmètre technologique extrêmement large, qui va des modèles prédictifs aux agents susceptibles d’agir dans le système d’information au nom de l’utilisateur, et sous la responsabilité de son organisation.

Le terme peut également être employé comme une qualification commerciale pour désigner des fonctionnalités qui reposent surtout sur des règles automatisées ou des traitements statistiques plus classiques.

Deux propositions utilisant le mot « IA » peuvent par conséquent couvrir des réalités très différentes :

Ces différences décrivent simplement des incarnations qui n'auront pas les mêmes conséquences pour vous. Faire un footing, prendre le TGV ou conduire une voiture ont toutes le même résultat, à savoir se déplacer. Mais elles n'ont, concrètement, pas les mêmes conséquences sur l'énergie, le temps, la disponibilité physique et mentale ou les responsabilités associées.

Il faut donc reconstruire un périmètre indépendant des présentations commerciales.

Pour chaque offre, il convient notamment de déterminer :

Une proposition moins chère peut, par exemple, laisser au client la préparation des données, l’intégration technique ou la supervision des résultats. Son prix n’est pas nécessairement inférieur : une partie de son coût a simplement été déplacée vers l’organisation.

Reconstituer un périmètre commun de comparaison

Une fois les propositions ramenées au problème initial, elles doivent être examinées selon les mêmes catégories.

Les fonctionnalités et les usages

Les fonctionnalités et les usages

Il faut comparer les cas d’usage couverts, les utilisateurs concernés, les volumes prévus, les langues prises en charge, les interfaces et le niveau de personnalisation.

Il faut également vérifier ce que la solution ne fera pas. Les exclusions sont parfois aussi importantes que les fonctionnalités mises en avant.

Les données

Les données

La comparaison doit préciser les sources utilisées, le niveau de qualité attendu, les opérations de nettoyage ou d’annotation, les besoins de migration, les durées de conservation et les droits d’utilisation.

La question n’est pas uniquement de savoir si les données existent, mais si elles peuvent être utilisées dans le contexte et avec le niveau de fiabilité attendus.

L’intégration technique

L’intégration technique

Il faut identifier les connexions nécessaires avec les outils existants, les modalités d’authentification, les exigences de sécurité, le choix de l’hébergement, les phases de test et les conditions de mise en production.

Une démonstration réalisée sur un environnement isolé ne permet pas de présumer de la complexité de l’intégration dans le système d’information réel.

L’exploitation

L’exploitation

La maintenance, la supervision, la correction des erreurs, les mises à jour, le support et le suivi des performances doivent également être comparés.

Une solution ne cesse pas de produire des coûts ou des risques au moment de sa mise en production. Elle doit ensuite être exploitée, contrôlée et adaptée.

L’organisation

L’organisation

Enfin, le projet peut nécessiter de la formation, une documentation, un contrôle humain, une gouvernance spécifique et un transfert de compétences.

Ces éléments sont parfois présentés comme périphériques. Ils conditionnent pourtant l’adoption de la solution et la capacité de l’organisation à ne pas dépendre entièrement du prestataire.

Comparer le coût total et les hypothèses de réussite

Le prix affiché ne suffira pas à vous éclairer.

Il faut également intégrer :

L’analyse doit aussi rendre visibles les hypothèses sur lesquelles chaque offre repose.

Le prestataire peut, par exemple, supposer que les données sont déjà disponibles et propres, que les équipes internes pourront être rapidement mobilisées, que les volumes resteront stables ou que la performance observée pendant le prototype sera conservée en production.

Ces hypothèses ne sont pas nécessairement irréalistes. Elles doivent simplement être explicitées et confrontées à la situation réelle de l’organisation.

Une intelligence artificielle, même très sophistiquée, ne répondra pas correctement à vos besoins si elle s’alimente à partir d’une base de données incohérente, obsolète ou mal gouvernée depuis plusieurs années.

Elle pourra produire un résultat techniquement élaboré, sans que celui-ci soit suffisamment fiable pour être utilisé dans une décision.

Comparer les engagements et les dépendances

Une promesse commerciale doit également conduire à s’interroger sur les incidences en cascade que le déploiement de la technologie aura sur l’organisation et les pratiques de travail.

Il faut notamment examiner :

Une démonstration montre ce que la solution est capable de produire dans un contexte déterminé. Elle ne décrit pas nécessairement ce que le prestataire s’engage à fournir, ni ce qui se produira lorsque les données, les volumes et les utilisateurs réels seront intégrés au dispositif.

La bonne proposition n’est donc pas nécessairement celle qui promet le plus.

De mon expérience, les outils qui prétendent tout faire en même temps sont souvent les moins adaptés à un besoin précis. Leur déploiement oblige l’organisation à s’aligner sur l’ensemble des fonctionnalités, des catégories et des processus embarqués dans le logiciel.

À l’inverse, des briques plus autonomes peuvent parfois répondre plus précisément au problème, tout en réduisant la dépendance au fournisseur.

La richesse fonctionnelle n’est donc pas une valeur en soi. Elle ne le devient que lorsque les fonctions proposées sont réellement nécessaires.

Produire une décision : retenir, négocier ou écarter

Une fois les offres replacées sur une base commune, trois décisions deviennent possibles.

Retenir

Retenir

La proposition répond au besoin, ses hypothèses sont réalistes, ses engagements sont suffisamment précis et son coût total est acceptable.

Négocier

Négocier

La solution paraît pertinente, mais son périmètre, son prix, ses responsabilités, ses engagements ou ses conditions de sortie doivent être ajustés.

La négociation peut également conduire à réduire le projet, à limiter le pilote ou à demander des preuves supplémentaires avant un déploiement plus large.

Écarter

Écarter

L’offre répond mal au besoin, repose sur des hypothèses incompatibles avec la situation de l’organisation ou crée une dépendance disproportionnée au regard de la valeur attendue.

Écarter une proposition techniquement aboutie ne signifie pas que la technologie est mauvaise. Cela signifie qu’elle ne constitue pas, dans ce contexte, une réponse suffisamment adaptée.

Conclusion

Comparer deux propositions IA ne commence pas par un tableau de prix.

Il faut d’abord vérifier que le problème appelle réellement une réponse reposant sur l’intelligence artificielle. Il faut ensuite définir la décision à éclairer, identifier les informations nécessaires et déterminer le niveau de traitement technique approprié.

Les offres peuvent alors être replacées sur un périmètre commun, afin de comparer leur coût total, leurs engagements, leurs hypothèses et les dépendances qu’elles créent.

Ce n’est qu’après ce travail qu’une proposition peut être retenue, négociée ou écartée.

Autrement, le risque est de comparer très précisément les prix de plusieurs réponses, sans avoir préalablement vérifié que l’une d’entre elles répondait à la bonne question.


Vous devez comparer plusieurs propositions IA ou SI ?

Voir l’analyse indépendante d’une proposition →

Questions fréquentes

Pourquoi ne faut-il pas commencer par un tableau de prix ?

Parce qu’un tableau de prix donne une impression de comparabilité qui peut être trompeuse. Deux propositions peuvent afficher des montants proches tout en couvrant des périmètres, des responsabilités et des hypothèses très différents. Selon enbi, il faut d’abord reconstruire ce que chaque offre promet réellement de produire, ce qu’elle exclut, ce qu’elle suppose et ce qu’elle laisse à la charge de l’organisation cliente.

Comment savoir si le besoin justifie vraiment l’IA ?

Il faut formuler le besoin sans présumer de la technologie. Si le problème peut être résolu par une meilleure organisation, une automatisation simple, un moteur de recherche ou une règle métier classique, l’IA n’est pas nécessairement la meilleure réponse. Selon enbi, une solution IA ne se justifie que si elle apporte une valeur spécifique par rapport aux alternatives disponibles.

Une automatisation classique peut-elle être préférable à une IA générative ?

Oui, dans certains cas. Une automatisation classique peut être plus simple, plus stable, moins coûteuse et plus facile à contrôler qu’une solution d’IA générative. Le choix dépend du besoin, du niveau de variabilité des tâches, des données disponibles, des contraintes de sécurité et du niveau d’erreur acceptable. Selon enbi, il faut comparer l’IA avec les alternatives non IA avant de choisir une solution.

Comment formuler un besoin sans présumer de la solution ?

Il faut décrire le problème opérationnel, la décision à améliorer ou le résultat attendu, sans imposer d’emblée un outil. Par exemple, “déployer un chatbot IA” présume déjà de la réponse. “Réduire le temps de réponse à des questions récurrentes avec un niveau de fiabilité contrôlé” permet de comparer plusieurs solutions. Selon enbi, une bonne formulation du besoin élargit les options au lieu de les fermer trop tôt.

Pourquoi les exclusions d’une offre IA sont-elles aussi importantes que ses fonctionnalités ?

Parce que les exclusions indiquent ce qui restera à la charge de l’organisation cliente. Une offre peut promettre de nombreuses fonctionnalités tout en excluant la préparation des données, les tests, la maintenance, la documentation, la formation ou la réversibilité. Selon enbi, une proposition IA doit être lue autant par ce qu’elle ne couvre pas que par ce qu’elle annonce.

Transformer une lecture en décision.

Si cet article éclaire une décision que vous devez prendre, le sprint de cadrage est le bon premier pas.

Demander un sprint