Chercher un prestataire qui connaît déjà votre secteur rassure, mais rassure sur le mauvais critère. Ce qui détermine si un projet IA aboutit, c'est la capacité à résoudre un problème technique qui n'a pas de solution toute faite, pas la familiarité avec votre vocabulaire métier.
Donatien Lefranc
Fondateur & Président, Leando
Un dirigeant qui lance un projet IA cherche presque toujours une référence dans son secteur. Vous vendez du transport, vous voulez un prestataire qui a déjà fait du transport. Vous êtes dans l'agroalimentaire, vous cherchez qui a déjà travaillé pour un industriel agroalimentaire. La logique semble imparable : moins d'explications à donner, moins de risque de malentendu sur le vocabulaire, un prestataire qui comprend déjà les contraintes.
Cette logique fonctionne pour une prestation standard. Elle s'effondre dès que le projet touche à un problème technique qui n'a pas de solution existante à copier, ce qui est le cas de la plupart des projets IA sérieux en PME. À ce moment-là, la question qui détermine le succès n'est plus « connaît-il mon secteur » mais « a-t-il déjà résolu un problème technique aussi difficile que celui-ci, quel que soit le secteur où il l'a rencontré ».
La familiarité sectorielle est une compétence courante. Des dizaines de prestataires connaissent l'agroalimentaire, le transport, ou l'industrie. La capacité à construire une solution technique là où il n'existe encore aucune ressource publique pour s'appuyer, aucun tutoriel, aucun forum, est nettement plus rare. C'est cette deuxième compétence qui manque le plus souvent quand un projet IA patine, pas la première.
« Je m'attendais à être très loin de l'innovation globalement, du digital. Et en fait j'ai bien senti un dirigeant qui allait beaucoup s'inspirer de secteurs divers, automobile, vignoble, agroalimentaire, pour s'en inspirer dans son métier à lui. »
Ce sont souvent les dirigeants eux-mêmes qui comprennent le mieux cette logique, en regardant comment d'autres secteurs ont résolu un problème proche du leur. Un prestataire technique devrait raisonner de la même façon : chercher le problème structurellement proche, pas le secteur identique.
La computer vision en est l'illustration la plus nette. Chez une startup qui construisait un système de génération de personnages animés personnalisés, le problème central n'avait rien d'évident : faire en sorte qu'un personnage reste visuellement cohérent d'une image à l'autre, sans ressource publique disponible pour s'appuyer, trois ans avant que les outils de génération d'image actuels n'existent. Il a fallu construire l'état de l'art plutôt que l'appliquer, avec des masques de projection et une architecture capable de convaincre des investisseurs américains exigeants du fonds A16Z.

Ce même socle technique, reconnaître et classifier un objet de façon fiable malgré des variations de forme, de lumière ou d'angle, s'est retrouvé mobilisé quelques années plus tard sur un problème d'apparence totalement différent : trier automatiquement des coquillages sur une chaîne de production pour un industriel agroalimentaire de la côte atlantique. Rien de commun entre un personnage de dessin animé et un coquillage sur un tapis roulant, sauf le mécanisme technique sous-jacent. Sur ce projet, la précision de détection est passée de 50 à près de 95 %, un résultat qui doit davantage à la maîtrise technique du problème de perception qu'à une quelconque expérience préalable du secteur des produits de la mer.
Le réflexe le plus utile consiste à changer la question posée en entretien. Plutôt que de demander « avez-vous déjà travaillé dans mon secteur », demandez « racontez-moi un problème technique que vous avez résolu sans solution existante à copier ». La réponse à cette deuxième question distingue un prestataire qui applique des recettes connues d'un prestataire capable de construire quand rien n'existe encore. C'est aussi ce qui différencie un vrai travail de R&D d'une simple intégration d'API, une distinction qui compte autant pour une PME industrielle que pour une startup en levée de fonds.
À faire cette semaine
Une entreprise qui recrute sur la seule familiarité sectorielle prend un risque silencieux : elle ne le découvre que le jour où le projet touche un problème technique qui sort du cadre standard, et que le prestataire n'a jamais eu à en résoudre un comparable ailleurs. À l'inverse, une profondeur technique démontrée sur un secteur totalement différent du vôtre est un signal plus fiable qu'un catalogue de références dans votre niche.
Avant votre prochain rendez-vous avec un prestataire IA, préparez une seule question : demandez-lui de décrire le problème technique le plus difficile qu'il ait résolu sans solution existante à copier, peu importe le secteur. Sa réponse vous en dira plus que dix ans de références dans votre domaine.
Demandez-lui de décrire un problème technique qu'il a résolu sans solution toute faite disponible, pas un projet où il a assemblé des outils existants. La réponse révèle vite s'il a déjà construit quelque chose là où l'état de l'art n'existait pas, ou s'il applique des recettes connues. La deuxième posture n'est pas mauvaise en soi, mais elle ne vaut pas pour les problèmes vraiment spécifiques à votre activité.
30 minutes pour challenger la profondeur technique réelle avant de vous engager.
Réserver un échange de diagnostic