Le marché des prestataires en IA s’est rapidement développé ces dernières années. On y trouve des éditeurs de logiciels qui ont ajouté « IA » à leur catalogue, des agences de marketing digital qui proposent des « solutions d’IA », de grands cabinets de conseil dotés de pôles IA de taille variable et des équipes spécialisées qui ont une expérience réelle des projets d’intelligence artificielle.
Pour une entreprise qui cherche un partenaire pour un projet d’IA, distinguer ces catégories n’est pas simple, et un mauvais choix a des conséquences. Cet article propose des critères concrets et des questions directes pour mener cette évaluation correctement.
Le problème du marché actuel
Il est très facile de se présenter comme une « entreprise d’IA ». N’importe quelle société peut ajouter l’IA à son site web sans avoir mené un seul projet jusqu’en production. Il ne s’agit pas de se méfier de tous les prestataires, mais l’étiquette ne suffit pas : les critères d’évaluation doivent aller plus loin.
Le profil le plus courant de prestataire qui ne possède pas les compétences qu’il annonce est celui qui vient du développement logiciel ou du marketing digital et qui a ajouté des outils d’IA générative à son offre sans jamais avoir travaillé sur des projets de machine learning supervisé, de données, d’intégration en production ou de conduite du changement.
Les questions qui font la différence
« Combien de projets d’IA avez-vous menés jusqu’en production, et combien y sont encore aujourd’hui ? » C’est la question la plus importante. Non pas combien ont été lancés, mais combien fonctionnent dans les systèmes réels d’un client et produisent une valeur mesurable. Un prestataire incapable de citer des projets en production, dans les systèmes réels de clients réels, a une expérience limitée de ce qui est le plus difficile : faire fonctionner le projet au-delà de la démonstration.
« À quels moments un projet d’IA s’est-il déroulé autrement que prévu, et comment avez-vous réagi ? » Cette question est très instructive, car les projets d’IA réservent toujours des surprises : les données n’ont pas la qualité attendue, le modèle ne converge pas comme prévu, les utilisateurs n’adoptent pas le système comme il avait été conçu. Un prestataire expérimenté a des exemples concrets de la manière dont il a géré ces situations. Un prestataire sans expérience réelle donne des réponses génériques.
« Comment mesurez-vous la réussite une fois le système en production ? » Si la réponse ne porte que sur des indicateurs techniques (précision du modèle, temps de réponse) et non sur des indicateurs métier (heures gagnées, baisse des erreurs, amélioration d’indicateurs clés précis), le prestataire a une vision trop technique pour un projet qui doit créer de la valeur pour l’entreprise.
« Avez-vous des accords commerciaux avec des éditeurs de logiciels ou d’outils particuliers ? » Un prestataire lié par des accords de revente avec certains outils a intérêt à les recommander, qu’ils soient ou non la meilleure option pour le cas d’usage. L’indépendance vis-à-vis des fournisseurs de technologie est une qualité importante pour une équipe chargée de mettre en œuvre l’IA.
Les signaux d’alerte dans les argumentaires
Certaines formules des argumentaires commerciaux des prestataires en IA appellent des questions complémentaires.
« Nous mettons en œuvre l’IA en X semaines. » Les projets d’IA bien conçus n’ont pas de délais garantis, car ils dépendent de facteurs qui se révèlent en cours de projet (qualité des données, complexité des intégrations). Un prestataire qui garantit des délais très précis avant d’avoir audité la situation de l’entreprise simplifie à l’excès le périmètre ou nourrit des attentes peu réalistes sur ce qu’il va trouver.
« Notre retour sur investissement documenté est de X fois. » Le retour d’un projet d’IA dépend du cas d’usage, de l’état des données et de la taille de l’entreprise. Citer un retour générique, sans contexte, ne renseigne pas sur ce qu’une entreprise donnée peut attendre.
« Vous n’avez rien à changer dans vos systèmes. » L’intégration de l’IA aux systèmes existants est l’un des aspects les plus complexes et les plus coûteux. Un prestataire qui affirme qu’il n’y a rien à changer sous-estime peut-être le travail d’intégration, ou propose une solution déconnectée du reste de l’infrastructure.
Ce qui distingue les équipes réellement expérimentées
Les équipes qui ont une expérience réelle des projets d’IA présentent des traits reconnaissables. Elles posent des questions sur les données avant de proposer des solutions. Elles expliquent ce qui pourrait se passer autrement que prévu. Elles ne promettent pas de résultats qui dépendent de facteurs qu’elles n’ont pas encore audités. Et elles ont des références de projets achevés, pas seulement de projets lancés.
Elles sont aussi franches sur les limites de l’IA pour certains cas d’usage. Une équipe qui dit « pour ce cas précis, une solution d’analyse de données classique peut être plus efficace que le machine learning » est plus crédible qu’une équipe qui propose l’IA pour tout.
L’importance de l’indépendance technologique
Pour une entreprise qui confie un projet d’IA, l’indépendance du prestataire vis-à-vis des outils qu’il recommande est un critère important. Une équipe qui ne vend pas d’outils et n’a pas d’accords de revente a des intérêts alignés sur ceux du client : recommander l’outil le plus adapté au problème, et non celui qui lui rapporte la meilleure marge.
Questions fréquentes
Vaut-il mieux faire appel à un prestataire local ou à un acteur plus largement implanté ? L’implantation compte moins qu’il n’y paraît : la plupart des projets peuvent être menés à distance. Ce qui compte, c’est l’expérience du prestataire sur des cas comparables au vôtre et dans votre secteur, pas sa localisation.
Comment savoir si le prestataire restera disponible après le lancement ? C’est une question légitime. Il convient de demander quel est le dispositif de support et de maintenance après le lancement, combien de projets sont actuellement en phase de maintenance et quelle équipe en serait chargée. Un prestataire qui a de nombreux projets en maintenance montre que ses clients continuent de lui faire confiance une fois le système en production.
Quelle documentation demander à la fin du projet ? La documentation technique du système (architecture, flux de données, paramètres du modèle), la documentation utilisateur (comment exploiter et maintenir le système), la documentation du processus de réentraînement du modèle et les indicateurs de performance de référence qui permettront de détecter une dégradation en production.