9 min de lecture - Comment évaluer des prestataires IA (due diligence technique)

Le marché du conseil en IA regorge de discours pleins d'assurance, mais manque cruellement de preuves opérationnelles.

Si vous êtes fondateur, responsable achats ou dirigeant technique, le coût d'un mauvais choix de prestataire ne se limite pas à l'argent. C'est le trimestre perdu, la refonte sécurité, et la confiance interne que vous grillez quand l'« initiative IA » se révèle n'être qu'une démo fragile.

Évaluer des consultants IA revient donc à une seule question : peuvent-ils prouver qu'ils ont déjà mis en production et exploité des systèmes d'IA, avec des périmètres clairs et des résultats mesurables ?

Cet article vous propose un processus de due diligence technique que vous pouvez mener en quelques jours, pas en semaines.

Ce que vous allez apprendre

• Les 5 catégories de due diligence qui comptent pour les projets IA
• Les questions qui distinguent les « bâtisseurs de démos » des équipes capables de livrer
• Les artefacts à exiger (et pourquoi ils comptent)
• Une checklist prête à copier-coller, utilisable pour la sélection de prestataires et les entretiens

L'essentiel

Pour évaluer des prestataires ou consultants IA, jugez sur les preuves de livraison, pas sur les buzzwords. Demandez un plan de délimitation des données, une approche d'évaluation (golden set + seuils), un modèle de responsabilité opérationnelle (runbooks, journalisation, gestion des incidents), et des limites de périmètre claires dans le cahier des charges (SOW). Exigez des artefacts, lancez un pilote payant court, et méfiez-vous des signaux d'alerte du type « pas besoin d'évaluation » ou « on réglera la sécurité plus tard ».

Les 5 catégories (un framework de due diligence simple)

Utilisez ces catégories pour structurer votre évaluation :

1. Clarté du résultat et du workflow (que change-t-on, et comment le mesure-t-on ?)
2. Délimitation des données et permissions (quelles données sont autorisées, et qui peut voir quoi ?)
3. Évaluation et qualité (comment détecte-t-on les régressions et les « échecs silencieux » ?)
4. Réalité opérationnelle (journalisation, supervision, runbooks, gestion des incidents)
5. Gouvernance de la livraison (contrôle du périmètre, passation, et qui est responsable de la maintenance)

Si un prestataire est faible sur une seule de ces catégories, le projet finira par coûter cher.

Questions à poser (et à quoi ressemble une bonne réponse)

Nul besoin d'être chercheur en machine learning pour poser des questions à fort signal.

Posez-les et soyez attentif au niveau de précision des réponses :

• « Quel est votre plan d'évaluation ? » Bonne réponse : golden set, grille d'évaluation, seuils, tests de non-régression. Mauvaise réponse : « on le saura quand ce sera bon ».
• « Comment gérez-vous les permissions sur les données dans le retrieval ? » Bonne réponse : la gestion des permissions fait partie intégrante du retrieval. Mauvaise réponse : « on le masquera dans l'interface ».
• « À quoi ressemble votre runbook ? » Bonne réponse : étapes d'incident, rollback, responsable désigné. Mauvaise réponse : « on n'en a jamais eu besoin ».
• « Comment maîtrisez-vous le périmètre ? » Bonne réponse : backlog + déclencheurs de changement. Mauvaise réponse : « écrivez-nous à tout moment ».
• « Que se passe-t-il après la mise en production ? » Bonne réponse : plan de maintenance, SLA, responsabilités définies. Mauvaise réponse : « passation à votre équipe », sans plus de détails.

Signaux d'alerte (à traiter comme un refus)

Pas besoin d'être cynique, mais restez vigilant. Voici les signaux d'alerte les plus courants :

• « L'évaluation n'est pas nécessaire. » Elle l'est toujours.
• « La sécurité, on la traitera plus tard. » Elle sera effectivement traitée plus tard, au prix d'une refonte forcée.
• « Il nous faut des données de production pour démarrer. » Vous pouvez démarrer avec un sous-ensemble anonymisé et un périmètre défini.
• Un discours de « périmètre illimité », sans processus de cadrage ni contrôle des changements.
• Un refus de décrire comment les données sont stockées, journalisées et conservées.

Un seul signal d'alerte ne signifie pas toujours qu'il faille tout arrêter, mais il doit déclencher des questions plus poussées et un pilote réduit.

Artefacts à demander (les preuves valent mieux que les slides)

Si le prestataire est sérieux, il dispose de modèles et d'artefacts, car il a déjà fait ce travail auparavant.

Demandez :

• un exemple de rapport d'évaluation (même anonymisé)
• un schéma d'architecture (flux de données + périmètres)
• un exemple de registre des risques
• une checklist de passation ou une trame de runbook
• un exemple de cahier des charges (SOW) avec des limites de périmètre (ce qui est exclu compte tout autant)

S'ils ne peuvent rien partager (même sous forme anonymisée), c'est un acte de foi que vous achetez.

Transformer les réponses en score fournisseur (pour comparer équitablement)

La due diligence perd tout son sens quand c'est le prestataire le plus convaincant à l'oral qui l'emporte. Une grille de notation simple vous permet de rester objectif.

Utilisez un système de notation 0/1/2 :

• 2 : précis, montre des artefacts, assume ses compromis
• 1 : réponse raisonnable, mais surtout orale, peu étayée
• 0 : vague, désinvolte, ou reporte le risque sur vous

Exemples de catégories de notation :

Cela facilite aussi l'alignement en interne : vous pouvez montrer aux parties prenantes pourquoi un prestataire a bien (ou mal) noté, sans que cela devienne une question personnelle.

Le test le plus sûr et le plus rapide : un sprint pilote payant

Pour les projets IA à forte incertitude, un court pilote payant vaut généralement mieux que des semaines d'avant-vente non facturées.

Le pilote doit comporter :

• un workflow restreint,
• un périmètre de données défini,
• une base de référence pour l'évaluation,
• et une décision de fin de sprint (passer à l'échelle, itérer, arrêter).

Ce qu'il faut exiger d'un pilote (des livrables qui prouvent la compétence)

Un pilote, ce n'est pas « construire une démo ». Un pilote, c'est « prouver que vous pouvez livrer en toute sécurité ».

Les livrables qui trahissent une véritable équipe de livraison :

• Brief de workflow : entrées, sorties, responsables, et définition du « terminé »
• Pack d'évaluation : un petit jeu de données, une grille d'évaluation, et des résultats de référence
• Notes d'architecture : flux de données, périmètres, emplacement des logs, plan de rollback
• Processus de changement : ce qui constitue un changement significatif et qui l'approuve
• Mémo de décision de fin de sprint : ce qu'il faut passer à l'échelle, ce qu'il faut arrêter, et quels sont les risques

Si un prestataire ne peut pas produire ces éléments dans un pilote restreint, il ne les produira pas comme par magie dans une mission plus large.

Prise de références : demandez l'histoire de l'échec

Les prestataires adorent raconter leurs succès. Vous, vous voulez l'histoire où quelque chose a mal tourné.

Si le prestataire peut fournir des références, posez des questions comme :

• « Racontez-moi une fois où la qualité s'est dégradée après la mise en production. Comment l'ont-ils détecté, et qu'ont-ils changé ? »
• « Ont-ils respecté les périmètres de données, ou la sécurité a-t-elle dû intervenir par la suite ? »
• « Comment ont-ils géré les dérives de périmètre quand des parties prenantes réclamaient sans cesse “encore une” fonctionnalité ? »
• « La collaboration restait-elle simple quand les exigences changeaient ? »

Les bons prestataires répondent avec précision : ce qui a cassé, ce qu'ils ont mesuré, ce que prévoyait le runbook, et ce qu'ils ont changé pour éviter que cela se reproduise.

Rendez les responsabilités explicites (pour éviter un transfert de risque silencieux)

La due diligence n'est pas qu'une affaire technique. C'est aussi une question de « qui est responsable de quoi ».

Avant de signer quoi que ce soit, mettez par écrit :

• qui est responsable du jeu d'évaluation et des seuils
• qui est responsable de la gestion des incidents (et à partir de quand)
• qui est responsable de la revue sécurité de la journalisation, de la conservation des données et de l'usage fait par le prestataire
• qui est responsable de la maintenance après la passation

Si la réponse est toujours « le prestataire », vous achetez de la dépendance. Si la réponse est toujours « votre équipe », vous achetez une démo. La bonne réponse est en général partagée, mais explicite.

À copier-coller : checklist de due diligence technique

Utilisez-la dans vos entretiens, vos appels d'offres (RFP) ou votre notation des prestataires.

Due diligence checklist (AI vendor/consultant)

Outcomes
- Target workflow defined:
- Success metric defined:

Data boundary
- Allowed/prohibited data written:
- Permissions model described:
- Logging and retention defined:

Quality
- Golden set and scoring plan:
- Regression testing plan:
- Rollback plan:

Operations
- Monitoring (quality/latency/cost):
- Runbooks + incident response:
- Maintenance ownership/SLA:

Delivery
- Scope boundaries + change control:
- Handoff artifacts:
- Clear timeline and dependencies:

Misez sur la réalité opérationnelle

Évaluer des consultants IA revient surtout à exiger une réalité opérationnelle : délimitation des données, évaluation, responsabilités et périmètre clair. Si un prestataire est capable de montrer des artefacts et de parler concrètement de ses compromis, vous le sentirez. S'il ne le peut pas, vous paierez pour le découvrir plus tard. Besoin d'un second avis sur un prestataire ? Discutons-en.