La plupart des consultations de prestataires IA se jouent sur une démo, ce qui est à peu près le pire signal disponible. Une démo prouve qu’un modèle sait accomplir une tâche une fois, dans des conditions choisies par le prestataire. Ce que vous achetez, c’est un système qui l’accomplit dix mille fois, dans des conditions qu’il n’a pas choisies. Voici les neuf questions qui font réellement la différence, ce que chacune vérifie en profondeur, et la forme que prend une réponse évasive.
Elles comptent parce que le taux de réussite de départ est mauvais : 95 % des pilotes d’IA générative en entreprise n’ont aucun impact mesurable sur le compte de résultat (MIT Project NANDA, 2025). La même étude a identifié ce qui fait mieux : acheter auprès de prestataires spécialisés ou s’associer avec eux a réussi dans environ 67 % des cas, soit à peu près trois fois plus souvent que les développements internes. S’appuyer sur un partenaire fonctionne. Un partenariat mal engagé explique l’essentiel des 95 %.
1. Qu’avez-vous mis en production, et que fait ce système aujourd’hui ?
Pas ce qu’ils ont développé : ce qui tourne aujourd’hui, avec des utilisateurs qui en dépendent. Demandez le workflow, le volume et depuis combien de temps le système est en service.
Mauvaise réponse : un portfolio de pilotes, de prototypes et de preuves de concept racontés au passé. Tout le monde sait faire une démo. Mettre en production et maintenir en service, c’est tout le métier, et un prestataire qui l’a fait a des détails précis à donner. Les nôtres figurent sur la page Références, avec l’investissement et le retour pour chaque projet.
2. Qui fera exactement le travail, et vais-je rencontrer ces personnes avant de signer ?
C’est dans l’écart entre les personnes présentes à la présentation commerciale et celles qui écrivent le code que la plupart des missions déraillent. Demandez des noms, des niveaux d’expérience, et si ces personnes travaillent en même temps pour d’autres clients.
Mauvaise réponse : « notre équipe », un organigramme, ou un associé qui « suivra le projet de près ». Si ceux qui cadrent le projet ne sont pas ceux qui le développent, chaque élément de contexte que vous transmettez doit être transmis une seconde fois. C’est tout l’argument en faveur d’ingénieurs intégrés à votre équipe (forward-deployed), un modèle que nous expliquons aux acheteurs (en anglais).
3. Quel est le prix total, et qui supporte un dépassement ?
Un seul chiffre, par écrit, avec la réponse à ce qui se passe quand le projet dure plus longtemps que prévu. C’est la question de la liste qui trie le plus vite les modes de collaboration, régie ou forfait.
Mauvaise réponse : une grille de taux journaliers, une fourchette, ou « cela dépend du périmètre ». Cela dépend toujours du périmètre. La question est de savoir qui porte ce risque. Nous avons décrit le mécanisme dans Bait-and-Bill (en anglais), et nos propres prix sont publiés pour que vous puissiez nous appliquer la même exigence.
4. Comment saurons-nous que cela fonctionne ?
Vous attendez un indicateur et une méthode de mesure, convenus de préférence avant le développement. Une précision, mais sur quel jeu de test ? Un taux de résolution, mais par rapport à quelle référence ? Mesuré par qui, à quelle fréquence ?
Mauvaise réponse : des résultats qualitatifs, des chiffres d’adoption, ou « nous définirons le succès ensemble pendant la phase de cadrage ». Un prestataire dont le métier est de développer de l’IA a un avis sur la façon de la mesurer. C’est à cela que sert un jeu d’évaluations (en anglais), et ne pas avoir d’avis sur le vôtre est un signe qui ne trompe pas.
5. Que se passe-t-il quand le modèle se trompe ?
Tout système probabiliste commet des erreurs. Vous vérifiez s’ils ont réfléchi aux modes de défaillance avant que vous posiez la question : garde-fous, chemins d’escalade, points de contrôle humains, et étendue des dégâts un mauvais jour.
Mauvaise réponse : « le modèle est très précis », ou toute réponse qui fait de la fiabilité une propriété du modèle et non du système qui l’entoure. La vraie réponse décrit des contraintes écrites dans le code, pas la confiance accordée aux benchmarks d’un fournisseur.
6. Que se passe-t-il quand le modèle sous-jacent change ?
Les fournisseurs de modèles retirent des versions, les réajustent et en modifient le comportement selon leur propre calendrier. Demandez ce qui casse, comment ils s’en apercevraient et en combien de temps ils pourraient revenir en arrière.
Mauvaise réponse : un regard vide, ou une indépendance vis-à-vis des modèles affirmée sans rien derrière. La version crédible comprend des versions de modèle figées, des prompts versionnés, une suite de tests de non-régression et un chemin de retour vers un état connu et sain. Ce sont les couches que nous décrivons dans la pile technique d’un agent en production (en anglais).
7. À qui appartiennent le code, les prompts et les évaluations ?
Posez la question explicitement pour les trois, ainsi que pour l’infrastructure et les données. Les prompts et les jeux d’évaluations concentrent le savoir accumulé pendant la mission, et c’est la partie qui a le plus de chances d’être conservée discrètement par le prestataire.
Mauvaise réponse : la propriété des « livrables », ou la propriété du code alors que l’orchestration reste sur la plateforme du prestataire. Si partir oblige à tout reconstruire, le prix de la mission inclut le fait de ne jamais partir.
8. Combien coûte l’exploitation après la mise en production, et qui s’en charge ?
Un système IA en service dérive, et quelqu’un doit le surveiller. Demandez le montant mensuel et le nom de celui qui en répond.
Mauvaise réponse : présenter l’exploitation comme facultative, ou comme une simple ligne de support au catalogue. L’inférence elle-même coûte peu, quelques centimes par transaction, et son prix baisse vite. La supervision, les régressions d’évaluation et la gestion de la dérive sont en revanche un vrai travail. Chez nous, cela coûte 3 000 à 20 000 $ par mois selon le nombre de systèmes suivis, et nous préférons le chiffrer dès le départ plutôt que de le découvrir après coup.
9. Dans quel cas nous déconseilleriez-vous de développer ce projet ?
C’est la question la plus révélatrice de la liste, et celle que presque personne ne pose. Vous vérifiez si le prestataire a un avis sur l’adéquation du projet, ou si tous les problèmes se trouvent, comme par hasard, pouvoir être résolus par ce qu’il vend.
Mauvaise réponse : l’enthousiasme. Un prestataire qui mérite d’être retenu nomme les conditions dans lesquelles il ne faut pas y aller : les données manquent, le volume du workflow est trop faible, la bonne réponse ne peut pas être connue, personne n’est responsable de l’indicateur. S’il n’a jamais dissuadé un client de quoi que ce soit, vous n’êtes pas son client, vous êtes son pipeline commercial.
Comment exploiter les réponses
Posez les neuf questions à chaque prestataire, nous compris, et notez les réponses côte à côte. Le schéma d’ensemble compte plus que n’importe quelle réponse isolée : les prestataires qui mettent en production donnent des réponses précises, un peu ennuyeuses, avec des chiffres, et ceux qui font des démos donnent des réponses assurées sur ce dont la technologie est capable. Pour la version structurée de cette comparaison, nous détaillons les arbitrages face aux cabinets de conseil traditionnels et aux agences d’automatisation, y compris les cas où chacun est réellement le meilleur choix.
