Évaluer les promesses IA des fournisseurs dans les RFP et les démos

Un fournisseur de network analytics annonce à votre CTO : « Notre IA réduit les interruptions réseau de 47 % grâce à de la détection d'anomalies par deep learning. » La démo est impeccable. Le RFP (request for proposal, le document qu'un opérateur télécom publie pour solliciter des offres) contient une page de promesses du même style. Personne dans la salle ne peut dire quelle phrase correspond à un résultat validé et laquelle est une paraphrase marketing de « nous collectons des métriques ». Cette leçon vous apprend à faire la différence.

Pourquoi c'est important maintenant

Les opérateurs télécoms sont submergés de pitchs IA pour les opérations réseau, le service client, la détection de fraude et l'optimisation du RAN (radio access network). Les budgets sont finis. Un mauvais pari sur un fournisseur coûte 12 à 18 mois de temps d'intégration, pas seulement des frais de licence. Les équipes achats ont de plus en plus besoin d'évaluateurs qui comprennent l'IA, pas seulement d'évaluateurs techniques, parce que ces promesses sont écrites pour résister à une lecture rapide, pas à un audit.

Anatomie d'une promesse gonflée

Extrait de RFP réaliste, paraphrasé à partir de formulations courantes chez les fournisseurs de network analytics :

« Notre plateforme utilise le machine learning pour prédire les pannes réseau avant qu'elles ne se produisent, réduisant le MTTR (mean time to repair) jusqu'à 40 % et permettant une maintenance proactive sur l'ensemble du RAN. »

Décomposez en éléments testables :

1. « Utilise le machine learning » : vague. Quelle technique ? Un arbre de gradient boosting qui signale des dépassements de seuil, c'est du « machine learning ». Une random forest aussi. Comme une simple régression rebaptisée pour le deck commercial.
2. « Prédire les pannes avant qu'elles ne se produisent » : la prédiction exige un jeu de données historiques labellisées de pannes et un horizon de prédiction défini (prédire à 5 minutes n'a rien à voir avec prédire à 48 heures). Demandez : prédit combien de temps à l'avance, avec quelle precision et quel recall ?
3. « Jusqu'à 40 % » : le « jusqu'à » est le signal. Il décrit un meilleur cas, peut-être issu d'un seul site pilote, d'un seul trimestre, sélectionné à dessein. Demandez la distribution, pas le plafond.
4. « Sur l'ensemble du RAN » : validé sur de la 4G, de la 5G, les deux ? Macro-cellules urbaines, rural, small cells indoor ? Un modèle entraîné sur des profils de trafic RAN urbain dense se dégrade souvent sur des cellules rurales aux profils de bruit différents.

Cinq questions qui séparent la preuve du vernis

1. Quel est le baseline ?

« 40 % de réduction du MTTR » par rapport à quoi ? Un triage manuel ? Un système legacy à base de règles ? Demandez le comparateur précis et la période de mesure.

2. Sur quelles données le modèle a-t-il été entraîné et testé ?

Demandez directement : combien de sites cellulaires, combien de mois, quel équipementier (le matériel RAN Ericsson, Nokia, Huawei ne se comporte pas de la même façon), et le jeu de test provenait-il d'une période différente de celle du jeu d'entraînement (validation out-of-time) pour écarter l'overfitting.

3. Quels sont la precision et le recall, pas seulement l'accuracy ?

Pour la prédiction de pannes ou la détection d'anomalies, l'accuracy est souvent dénuée de sens parce que les pannes sont des événements rares. Si seulement 1 % des fenêtres temporelles contiennent une panne réelle, un modèle qui prédit toujours « pas de panne » affiche 99 % d'accuracy tout en étant inutile. Exigez la precision (parmi les pannes signalées, combien étaient réelles) et le recall (parmi les pannes réelles, combien ont été détectées).

4. Cette validation a-t-elle été faite par un tiers ou seulement en interne ?

Une validation indépendante, une référence client prête à s'exprimer, ou une étude de cas publiée avec sa méthodologie, pèse plus lourd qu'un white paper interne. Demandez la ressource publique analogue : le TM Forum publie des frameworks de maturité neutres pour l'IA dans les opérations télécoms, utiles comme benchmark externe.

5. La démo reflète-t-elle les conditions de production ?

Les démos tournent sur des données choisies. Demandez : pouvons-nous faire tourner ça sur nos propres données mises de côté avant de signer ? Un fournisseur confiant dans ses promesses acceptera un proof of concept (PoC) avec vos données, vos KPIKPIKey Performance Indicator : une valeur mesurable qui montre l'efficacité avec laquelle vous atteignez un objectif précis, suivie dans le temps par rapport à une cible.Voir la définition complète → et un seuil de succès convenu à l'avance.

Un framework simple : le test des quatre couches

Si une promesse échoue sur deux couches ou plus, traitez-la comme du marketing, pas comme un résultat technique, et valorisez le deal en conséquence (contrat plus court, gate de PoC, clauses de pénalité liées à de vrais KPI).

Exemple chiffré : dimensionner une promesse avant d'y croire

Un fournisseur affirme que sa maintenance prédictive basée sur l'IA réduit les coupures non planifiées de 30 %, soit une économie estimée à 2 M$ par an (estimation du fournisseur, non vérifiée) pour un opérateur de taille moyenne avec 10 000 sites cellulaires.

Vérifiez l'arithmétique vous-même :

Assume: 10,000 sites, average 0.5 unplanned outages/site/year
        = 5,000 outages/year
Assume: average cost per outage (truck roll, SLA penalty, churn risk)
        ≈ $1,500 (illustrative estimate, verify with your own ops data)
Baseline annual outage cost ≈ 5,000 × $1,500 = $7,500,000

Vendor claims 30% reduction:
Savings ≈ 0.30 × $7,500,000 = $2,250,000

Cela correspond à peu près au chiffre de 2 M$ du fournisseur, bon signe : la promesse est cohérente en interne. Mais la cohérence n'est pas une preuve. Il vous faut encore votre propre taux de coupures et votre propre coût par coupure, pas ceux supposés par le fournisseur, et un PoC pour tester si les 30 % tiennent sur votre réseau.

Clauses contractuelles et d'évaluation sur lesquelles insister

• PoC avant engagement : 60 à 90 jours, sur vos données, contre votre KPI défini, avec une sortie « pas d'achat » explicite si le seuil n'est pas atteint.
• Exigence d'explicabilité : pour tout modèle influençant des décisions visibles par le client (ex. prédiction de churn affectant les offres de rétention), demandez comment le fournisseur traite les obligations de transparence de l'AI Act européen pour les systèmes d'IA concernés, et s'il peut produire des explications au niveau des features, pas seulement un score.
• Provenance des données : d'où viennent les données d'entraînement, incluent-elles les données anonymisées de vos concurrents (courant dans les plateformes de network analytics multi-tenant), et cela soulève-t-il des questions d'antitrust ou de confidentialité.
• Suivi de la dégradation des performances : le fournisseur s'engage-t-il sur une cadence de réentraînement et sur le reporting du model drift (performances qui se dégradent quand les conditions réseau évoluent) ?

🎬 [VIDEO: "How to Read an AI Vendor's Whitepaper Critically" - youtube.com - cherchez des interventions de conférences MLOpsMLOpsMachine Learning Operations : combinaison des pratiques ML et DevOps pour industrialiser, déployer, monitorer et réentraîner les modèles de façon fiable en production.Voir la définition complète → ou applied ML sur l'évaluation des promesses ML des fournisseurs ; privilégiez celles qui détaillent les pièges precision/recall et les comparaisons de baseline dans les supports de vente IA en entreprise]

À quoi ressemble une vraie bonne preuve côté fournisseur

• Des références clients nommées, idéalement chez des opérateurs comparables en taille et en géographie.
• Une matrice de confusion ou un tableau precision/recall, pas juste un chiffre unique d'« accuracy ».
• La divulgation du type de modèle (même à haut niveau : gradient boosting, LSTM pour les séries temporelles, détection d'anomalies à base de transformers) et pourquoi il convient au cas d'usage.
• Un benchmark publié ou audité par un tiers, ou la volonté d'être benchmarké contre un concurrent sur des données partagées.
• Un énoncé clair des limites : là où le modèle sous-performe (ex. « l'accuracy baisse sur les small cells 5G récemment déployées avec moins de 3 mois d'historique »).

Les fournisseurs qui exposent spontanément leurs limites sont, contre-intuitivement, plus crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édibles. Surpromettre sans réserve est en soi un signal.

Points clés

• Traitez chaque chiffre de performance IA dans un RFP comme une hypothèse, pas comme un fait, jusqu'à voir le baseline, le jeu de données et le détail precision/recall derrière.
• La formule « jusqu'à X % » signale un meilleur cas, probablement non représentatif ; demandez la distribution des résultats par site et par période.
• Exigez un proof of concept sur vos propres données avec un seuil de KPI convenu à l'avance avant de signer ; les démos sur données sélectionnées par le fournisseur ne prouvent presque rien.
• Utilisez un test simple à quatre couches (définition, baseline, preuve, transférabilité) pour trier rapidement les promesses pendant la revue du RFP.
• Les fournisseurs qui divulguent les limites de leurs modèles et proposent une validation indépendante sont généralement plus fiables que ceux qui affichent des promesses lissées sans aucune réserve.