Consultant IA : comment le choisir, et ce qu’il doit livrer

Un consultant IA est un prestataire qui aide une organisation à décider où l’intelligence artificielle crée de la valeur, puis, selon son profil, à construire le système, à le mettre en service et à en transférer la maîtrise aux équipes. Le titre ne dit pas lequel de ces trois métiers il exerce : seuls les livrables le disent.

Choisir un consultant IA revient donc à choisir un livrable. Une feuille de route, un prototype, un système en production et une équipe formée ne s’achètent pas au même endroit. Cet article compare les cinq profils du marché sans les opposer, donne dix questions à poser avant de signer, les signaux d’alerte, la trame d’un cahier des charges court et la frontière entre conseil et ingénierie.

Un consultant IA se choisit en partant du livrable attendu, puis en vérifiant les preuves que le prestataire a déjà produit ce livrable, sur des données comparables, dans un cadre de sécurité comparable.

La première question n’est pas « qui est le meilleur », mais « que doit-on avoir entre les mains à la fin ». Une direction qui doit arbitrer un budget a besoin d’une feuille de route chiffrée. Une équipe qui veut un assistant documentaire en service a besoin d’un système testé, déployé et maintenable. Une entreprise qui veut rendre ses équipes autonomes a besoin d’un transfert de compétences planifié.

La seconde question porte sur les preuves. Un consultant qui a mis des systèmes en production peut décrire ce qui a cassé, comment il l’a mesuré et ce qu’il a corrigé. Un consultant qui n’en a pas mis parle d’opportunités et de tendances. La méthode pour trier un projet avant même de chercher un prestataire est décrite dans juger un projet d’IA en cinq minutes.

Cinq profils se partagent le marché du conseil en IA : le cabinet de conseil stratégique, l’ESN, le consultant freelance, le Forward Deployed Engineer et l’éditeur, chacun avec un livrable fort et une limite connue.

Aucun n’est meilleur dans l’absolu. Chacun répond bien à une question précise et mal aux autres.

Le Forward Deployed Engineer est le profil le moins connu. C’est un ingénieur qui s’installe dans l’équipe cliente, construit le système avec elle et part quand elle sait le faire vivre. Le métier est détaillé dans Forward Deployed Engineer, le métier, pas le titre.

Dix questions suffisent à départager deux consultants IA : elles portent sur les preuves, les données, les livrables, le transfert, la propriété, la conformité, la sécurité, le coût et le critère d’arrêt.

Chaque réponse doit être précise et, si possible, écrite dans la proposition.

1. Quels systèmes avez-vous mis en production, et qu’est-ce qui y tourne encore ? Un prototype de démonstration n’est pas une preuve ; un système utilisé, mesuré et maintenu en est une.
2. De quel accès aux données avez-vous besoin, et à partir de quand ? La réponse révèle si le consultant travaillera sur vos données réelles ou sur des hypothèses.
3. Quels livrables nommés recevrons-nous ? Une liste de documents, de dépôts de code et de jeux de tests, chacun avec son format.
4. Comment transférez-vous les compétences à nos équipes ? Sessions de travail, revue de code commune, documentation d’exploitation, nombre de personnes formées.
5. Comment reprenons-nous la main si nous arrêtons ? La réversibilité se prévoit avant de signer : export, documentation, absence de composant propriétaire indispensable.
6. À qui appartiennent le code, les prompts et les jeux de tests ? La cession doit être écrite au contrat, sans quoi elle se discute après coup.
7. Comment traitez-vous la conformité ? AI Act, données personnelles, obligation de maîtrise de l’IA des équipes : qui fait quoi.
8. Où passent nos données, et avec quels contrôles de sécurité ? Hébergement, sous-traitants, journalisation, gestion des accès.
9. Quel est le coût par jour, et combien de jours par étape ? Le tarif seul ne permet aucune comparaison ; le décompte par étape, si.
10. Quel critère arrête le projet ? Un seuil mesurable, fixé avant de commencer, en dessous duquel on ne poursuit pas.

La question 9 est développée dans ce qu’un TJM élevé achète réellement, et l’évaluation des fournisseurs au-delà des performances annoncées dans évaluer un fournisseur d’IA hors capacités.

Les signaux d’alerte d’un consultant IA sont des réponses sans objet vérifiable : aucune référence en production, aucun livrable nommé, aucun critère d’arrêt et une solution proposée avant d’avoir vu les données.

Le premier signal est la solution qui précède le diagnostic. Un prestataire qui annonce l’outil ou le modèle avant d’avoir examiné les données et le processus vend ce qu’il sait déjà faire, pas ce dont le client a besoin.

Le deuxième est le livrable flou. « Accompagnement », « acculturation » ou « stratégie IA » sans document, code ni jeu de tests associés ne permettent pas de vérifier que le travail a été fait.

Le troisième est l’absence de mesure. Un projet d’IA sans jeu de tests ni seuil de qualité ne peut ni réussir ni échouer de façon démontrable ; il s’allonge. La mécanique de ces projets qui ne passent jamais le cap est décrite dans anatomie d’un POC qui ne passe jamais.

Le quatrième est la dépendance organisée : code non remis, composant propriétaire sans alternative, documentation promise « en fin de mission ». La réversibilité se négocie au début, jamais à la fin.

Un consultant IA doit livrer des objets vérifiables : une feuille de route chiffrée, un jeu de tests réutilisable, un système documenté lorsqu’il construit, et une équipe capable de le faire vivre sans lui.

La feuille de route chiffrée classe les cas d’usage par valeur, faisabilité et risque, et indique pour chacun le nombre de jours et les prérequis. Le Diag Data IA de Bpifrance, dispositif public de 8 jours d’intervention d’un expert agréé, suit cette logique : état des lieux, cas d’usage, priorisation, feuille de route.

Le jeu de tests est le livrable le plus sous-estimé. Il contient les cas réels, les réponses attendues et la façon de noter ; il resservira après chaque changement de modèle et pour comparer deux fournisseurs.

Le système documenté comprend le code, la configuration, les prompts, la procédure de déploiement et la procédure de retour arrière. Le transfert, enfin, se constate : les équipes savent modifier, tester et remettre en service sans appeler le prestataire.

Un cahier des charges de projet d’IA tient en une page s’il fixe six éléments : la question métier, le périmètre, les données disponibles, les livrables attendus, les contraintes et le critère de réussite.

Un document court oblige à trancher.

• Question métier : une phrase, formulée en résultat attendu, par exemple réduire le temps de recherche documentaire d’un service.
• Périmètre : une direction, un processus, des utilisateurs identifiés.
• Données : ce qui existe, où, sous quel format, et qui autorise l’accès.
• Livrables : la liste nommée, avec le format de chacun.
• Contraintes : hébergement, données personnelles, outils imposés, calendrier.
• Critère de réussite et critère d’arrêt : un seuil mesuré sur le jeu de tests.

Le cahier des charges ne fixe pas la solution. Il laisse au prestataire le soin de proposer une approche, et permet de comparer les réponses sur les mêmes critères. Le coût de la phase de diagnostic, qui découle de ce périmètre, est détaillé dans prix d’un audit IA : ce qui fait varier le coût.

Le conseil en IA produit une décision, l’ingénierie IA produit un système qui fonctionne ; la plupart des projets ont besoin des deux, dans cet ordre, et souvent du même interlocuteur.

Le conseil répond à « quoi et pourquoi » : quels cas d’usage, dans quel ordre, avec quel budget et quels risques. Son livrable est un document qui permet à une direction d’arbitrer.

L’ingénierie répond à « comment et est-ce que ça tient » : architecture, intégration, tests, déploiement, supervision. Son livrable est un système mesuré. Le cadre de gestion des risques du NIST, l’AI RMF 1.0 publié le 26 janvier 2023, organise ce travail en quatre fonctions : Govern, Map, Measure, Manage. Un prestataire qui ne sait pas dire comment il mesure n’en couvre qu’une partie.

La rupture entre les deux est la cause classique des recommandations restées sans suite. Ma méthode consiste à faire tenir les deux dans la même mission : un audit IA qui livre une feuille de route et un jeu de tests, puis une construction qui reprend ce jeu de tests comme critère de réussite.

Un freelance convient à un périmètre resserré qui exige une expertise pointue et un interlocuteur unique ; un cabinet convient à un programme multi-directions qui exige de la capacité et de la coordination.

La taille du prestataire doit suivre la taille du problème. Un assistant documentaire pour un service ne demande pas une équipe de dix personnes ; une transformation de groupe ne tient pas sur une seule personne.

Le Forward Deployed Engineer se situe entre les deux : un ingénieur qui construit dans l’équipe cliente, sur ses données, et transfère. Anand Candassamy, docteur en intelligence artificielle et ingénieur, exerce ce métier : audit IA en amont, construction, puis formation IA des équipes qui reprennent le système. Ce profil n’a pas vocation à remplacer un cabinet sur un programme de groupe.

Le plan national Osez l’IA, piloté par la Direction générale des Entreprises, fournit trois points d’entrée publics : les ambassadeurs IA, un catalogue de fournisseurs de solutions et les dispositifs de Bpifrance.

Selon la page de la DGE mise à jour le 28 septembre 2026, le réseau compte 615 ambassadeurs IA répartis dans 20 régions ou collectivités et 13 filières, et un catalogue réalisé avec Hub France IA recense 88 fournisseurs de solutions d’IA pour les PME et ETI de maturité numérique intermédiaire.

Ces annuaires donnent des noms, pas un verdict. Les dix questions ci-dessus s’appliquent à chacun d’eux, qu’il soit référencé ou non.

Côté sécurité, l’ANSSI a publié le 29 avril 2024 des recommandations de sécurité pour un système d’IA générative, utiles pour formuler la question 8 et lire les réponses.

Analyse et méthode proposées par Anand Candassamy au 13 octobre 2026.