Choisir un prestataire IA : analyser ce que sa proposition engage réellement.

Ce que nous analysons

ENBI intervient côté acheteur pour analyser une proposition ou remettre plusieurs offres sur une base comparable. Cette démarche correspond à une problématique de sélection fournisseur — vendor selection — mais elle ne consiste pas à produire un simple classement : l'objectif est de comprendre ce que chaque choix implique réellement pour l'organisation.

Selon les offres, nous mobilisons les dimensions susceptibles de modifier la décision — données & technologie, économie & stratégie, droit & gouvernance, organisation & contrôle — sans les examiner mécaniquement.

La comparaison porte sur les dimensions qui rendent les propositions réellement différentes.

1. Reconstruire un périmètre commun

Avant de comparer les prix, il faut comparer ce qui est réellement fourni : le besoin effectivement couvert, les utilisateurs concernés, les fonctionnalités incluses et exclues, les données nécessaires, leur préparation et leur migration, les intégrations, les éventuels développements spécifiques, le calendrier, les critères de recette, les livrables, les responsabilités respectives, les conditions de support et d'exploitation.

Cette reconstruction peut faire apparaître que deux propositions supposées concurrentes ne répondent pas exactement à la même question. Dans ce cas, le premier résultat de l'analyse est précisément de rendre la comparaison possible.

2. Examiner la faisabilité dans votre contexte

Une démonstration réussie ne suffit pas : une solution peut fonctionner dans l'environnement du fournisseur sans être directement transposable dans votre organisation. Nous examinons les hypothèses techniques de la proposition, la compatibilité avec le système d'information, les données réellement disponibles, les volumes, les dépendances à des modèles, API ou infrastructures tierces, les performances promises et leurs conditions, la sécurité et la continuité, les besoins de supervision, les conditions réelles d'exploitation.

La richesse fonctionnelle n'est pas une valeur en soi. Elle ne devient utile que lorsque les fonctions proposées répondent à un besoin réel et peuvent être exploitées dans votre environnement.

3. Reconstituer le coût complet

Le prix annoncé peut représenter une petite partie de ce que le choix engage. Nous reconstituons, lorsque c'est pertinent, le coût d'entrée (licence, paramétrage, développement, intégration, reprise des données), le coût d'exploitation (infrastructure, API, modèles, maintenance, support, supervision, contrôle humain, formation), le coût d'évolution (nouvelles fonctionnalités, changements de volume, interfaces supplémentaires, adaptations réglementaires ou organisationnelles) et le coût de sortie (récupération des données, migration, transfert de connaissances, reconstruction d'intégrations, assistance du fournisseur sortant, interruption éventuelle du service).

Deux offres peuvent alors changer complètement de position une fois comparées sur leur cycle de vie plutôt que sur leur coût initial.

4. Identifier les dépendances créées

Choisir un prestataire, c'est aussi choisir les marges de manœuvre que l'on conservera. Certaines dépendances sont normales ; le problème commence lorsqu'elles restent implicites au moment de la décision — dépendance au fournisseur, à une technologie propriétaire, à un modèle particulier, à une API, à un format de données, à des intégrations spécifiques, à des compétences difficiles à transférer, ou à un processus organisationnel imposé par la solution.

C'est notamment ce que recouvre la notion de vendor lock-in lorsqu'un changement de fournisseur devient techniquement ou économiquement prohibitif. La dépendance n'est toutefois pas synonyme d'absence de réversibilité.

Si vous devez changer de solution dans deux ou trois ans, que faudra-t-il réellement transférer, reconstruire ou renégocier ?

5. Examiner les responsabilités et le fonctionnement réel

Une proposition technologique ne décrit pas seulement un outil : elle répartit aussi du travail et des responsabilités. Selon le projet, nous examinons qui prépare et maintient les données, qui valide les résultats, qui contrôle les erreurs, qui intervient en cas d'incident, qui documente le système, quelles compétences doivent rester chez vous, ce qui dépend du fournisseur, ce qui devra être organisé en interne.

Une solution techniquement pertinente peut devenir une mauvaise option si son fonctionnement suppose des ressources ou des processus que l'organisation ne peut pas durablement mobiliser.

Ce que le croisement permet de révéler

La valeur de l'analyse apparaît lorsque les dimensions cessent d'être examinées séparément.

• Prix × architecture × volumes — l'offre la moins chère sur le devis devient la plus coûteuse lorsque l'usage augmente.
• Fonctionnalités × organisation — la solution la plus complète impose aussi le plus de changements de processus et de charge interne.
• Architecture × dépendance × sortie — une intégration très efficace aujourd'hui rend un changement de fournisseur particulièrement coûteux demain.
• Engagement fournisseur × besoin réel — une fonction impressionnante dans la démonstration ne correspond à aucun usage suffisamment important pour justifier son coût.
• Données × responsabilités — la performance promise repose en réalité sur un travail de préparation ou de contrôle qui reste intégralement à la charge du client.

C'est ce type de conséquence qui permet de comparer les offres sur leur valeur réelle plutôt que sur leur présentation commerciale.

Le verdict

L'analyse aboutit à trois conclusions possibles.

RETENIR

La proposition répond au besoin. Ses hypothèses sont suffisamment crédibles, son coût complet est acceptable et les dépendances créées restent compatibles avec les marges de manœuvre recherchées. Le verdict précise les conditions à préserver lors de la contractualisation.

NÉGOCIER

La solution paraît pertinente, mais certains éléments doivent être ajustés avant engagement : le périmètre, les fonctionnalités, le prix, les engagements, les critères de recette, les données, les responsabilités, les niveaux de service, la documentation, les conditions de migration ou de sortie. NÉGOCIER peut aussi signifier réduire le projet, limiter un pilote, demander des preuves supplémentaires, ou séparer certains lots.

ÉCARTER

La proposition ne répond pas suffisamment au besoin, son coût réel est disproportionné ou les dépendances qu'elle crée ne sont pas justifiées par la valeur attendue. Écarter une offre n'implique pas nécessairement d'abandonner le projet : une autre solution — y compris plus simple ou moins technologique — peut être préférable.

Ce que vous recevez

Sous 5 jours ouvrés après réception des éléments nécessaires :

• la reconstitution du périmètre réel ;
• une grille de comparaison lorsque plusieurs offres sont examinées ;
• les hypothèses structurantes de chaque proposition ;
• les principaux coûts directs et indirects ;
• les dépendances et conditions de sortie ;
• les points à clarifier ;
• les questions à poser au prestataire ;
• les conditions à exiger ou à négocier ;
• les alternatives pertinentes ;
• un verdict RETENIR / NÉGOCIER / ÉCARTER.

Le document reste confidentiel.

Une décision située entre deux autres

Cette intervention répond à une question précise : quelle proposition retenir, négocier ou écarter ? Elle ne remplace ni l'évaluation du projet en amont ni l'audit détaillé du contrat en aval.

En amont — si la question reste de savoir si le besoin, la valeur attendue et les conditions de réussite justifient l'investissement, voir l'évaluation indépendante de projet IA.

Ici — une fois la décision de principe suffisamment établie, l'analyse compare la manière dont différents prestataires proposent d'y répondre.

En aval — une fois la solution choisie, certaines questions deviennent spécifiquement contractuelles : responsabilités, propriété, garanties, niveaux de service, clauses de sortie, portabilité, réversibilité. Voir l'audit de contrat IA / SI avant signature.

Projet → fournisseur → contrat : trois moments, trois décisions différentes.

Et dans la commande publique ?

L'analyse peut également intervenir en amont d'une consultation publique pour aider à comprendre le marché, clarifier les options disponibles et construire des critères de comparaison utiles. L'article R.2111-1 du Code de la commande publique permet à l'acheteur d'effectuer des consultations, de réaliser des études de marché ou de solliciter des avis afin de préparer la passation d'un marché, sous réserve de ne pas fausser la concurrence et de respecter les principes de la commande publique.

L'objectif n'est pas de choisir à la place de l'acheteur. Il est de lui permettre de comprendre ce qu'il devra réellement comparer lorsqu'il choisira.

Ce que cette analyse n'est pas

Cette intervention n'est pas une évaluation générale de l'opportunité du projet, une procédure de passation de marché, une notation automatique des fournisseurs, une négociation menée à votre place, un audit juridique exhaustif du contrat, une mission d'intégration, ni une recommandation rémunérée par un fournisseur. ENBI intervient en appui de la décision de l'acheteur.

ENBI n'est partenaire d'aucun éditeur ou intégrateur et ne perçoit aucune commission sur la solution retenue. La rémunération ne dépend donc ni du choix d'un prestataire, ni de la conclusion du contrat, ni du montant de la solution — ce qui permet de considérer comme équivalentes les trois conclusions RETENIR / NÉGOCIER / ÉCARTER.