Évaluer les fournisseurs d'IA et les pilotes avant de passer à l'échelle

Trois fournisseurs viennent de présenter le même cas d'usage : de la computer vision pour repérer les colis mal étiquetés sur une ligne d'embouteillage. Le fournisseur A a fait une démo à 99,7 % de précision. Le fournisseur B a annoncé une installation en deux semaines. Le fournisseur C a proposé le prix par caméra le plus bas. Six mois plus tard, un seul de ces déploiements tournera encore. Cette leçon vous donne la grille d'évaluation pour savoir lequel, avant de signer.

Pourquoi les démos mentent (un peu)

Toutes les démos fournisseurs fonctionnent. C'est bien l'objet d'une démo. Le modèle a été entraîné et ajusté sur des séquences sélectionnées, souvent tournées dans le laboratoire du fournisseur ou lors de la meilleure journée de production d'un client.

La vraie question n'est pas « est-ce que ça marche sur scène ». C'est « est-ce que ça marche sur votre ligne, avec votre éclairage, votre support d'étiquette, votre fréquence de changement de série, dans trois mois, à 2 h du matin en équipe de nuit ».

Cet écart entre performance en démo et performance en production est parfois appelé « demo-ware » : un système qui semble prêt pour la production mais qui n'a jamais été mis à l'épreuve du désordre d'une usine réelle. L'industrie manufacturière y est particulièrement exposée parce que les conditions varient d'une ligne à l'autre : vibrations, poussière, reflets, changements de SKU (stock keeping unit, une référence produit/conditionnement distincte) et comportement des opérateurs diffèrent tous du site de référence du fournisseur.

La grille d'évaluation en trois volets

Notez chaque proposition fournisseur sur trois dimensions avant de lancer un pilote.

1. Data readiness

Demandez : de quelles données ce modèle a-t-il besoin, et les avez-vous réellement, dans le bon format, au bon volume ?

• Pour la computer vision (détection de défauts, vérification d'étiquettes) : combien d'images de défauts annotées le fournisseur exige-t-il ? Les défauts rares (un bouchon rayé qui survient 1 fois sur 20 000 unités) sont difficiles à apprendre. Demandez comment le fournisseur gère le déséquilibre de classes (quand une issue, par exemple « pièce conforme », est très largement majoritaire par rapport à l'autre, « défaut », dans les données d'entraînement).
• Pour la maintenance prédictive : disposez-vous de données capteurs historiques (vibration, température, intensité absorbée) associées aux événements de panne réels ? Sans labels de panne, le modèle n'a rien à apprendre. Beaucoup d'usines ont des logs capteurs mais pas de relevés de maintenance propres les reliant aux arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êts.
• Pour l'optimisation qualité/procédé : vos données d'historian (enregistrements de séries temporelles issus de votre SCADA ou MES, soit Supervisory Control and Data Acquisition / Manufacturing Execution System) sont-elles propres, horodatées de façon cohérente et exemptes de dérive capteur ?

Un fournisseur qui dit « on verra pour les données pendant le pilote » vous annonce que le pilote est en réalité un audit de données déguisé. C'est acceptable, mais tarifez-le et cadrez-le comme tel.

2. Effort d'intégration

C'est là que budgets et calendriers cassent le plus souvent.

Posez des questions concrètes :

• Faut-il une nouvelle caméra, une connexion à l'automate PLC (programmable logic controller, l'ordinateur industriel qui pilote les machines) ou un équipement edge, ou le système lit-il l'infrastructure existante ?
• Qui est responsable du réseau OT (operational technology, les systèmes de contrôle industriels), et la sécurité IT/OT a-t-elle validé ? Les usines séparent de plus en plus les réseaux OT et IT pour des raisons de cybersécurité, et tout système d'IA qui touche aux deux relève d'une revue, pas d'un branchement.
• Quel est l'impact réel sur le temps de cycle ? Un système de vision qui ajoute 200 millisecondes par unité peut être invisible ou catastrophique selon la cadence de votre ligne.
• Faut-il arrêter la ligne pour installer, et pendant combien de temps ?

Un bon test instinctif : si le fournisseur ne peut pas répondre à ces questions dans le détail (pas « en général », mais « sur votre ligne, cela signifie X »), il n'a pas cadré votre usine, seulement son produit.

3. Conception du proof-of-concept (PoC)

Un PoC (proof of concept, un test à petite échelle pour valider la faisabilité avant un investissement plus large) n'est utile que s'il est conçu pour échouer de façon informative. Les PoC faibles sont conçus pour réussir.

Un PoC crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édible doit préciser, par écrit, avant de démarrer :

• Une métrique de succès chiffrée. Pas « meilleure détection des défauts » mais « réduire le taux de faux négatifs sur les défauts de bouchon du niveau de référence actuel à moins de 0,5 %, mesuré sur 10 000 unités ».
• Une durée suffisante pour rencontrer la variabilité réelle. Un pilote d'une semaine pendant une production stable ne vous dit à peu près rien de la performance pendant une semaine de changements de série ou un changement de matière fournisseur.
• Un baseline défini. Quel est le taux d'erreur réel de l'inspecteur humain actuel ou du système existant ? Beaucoup d'usines ne le savent pas précisément, ce qui rend « l'IA améliore la précision » infalsifiable.
• Une clause de sortie. Que se passe-t-il, contractuellement, si le PoC échoue sur la métrique ? Les bons fournisseurs l'acceptent. Ceux qui résistent à un seuil d'échec ferme signalent une faible confiance.

Pour une introduction utile à la structuration des métriques d'évaluation des systèmes de classification (la logique qui sous-tend la plupart des outils de détection de défauts), voyez cette explication accessible du Machine Learning Crash Course de Google : Classification: Accuracy, recall, precision.

Un mini-exemple chiffré

Supposons que la démo du fournisseur A revendique 99,7 % de précision sur la détection de défauts. Votre ligne expédie actuellement 500 000 unités par mois avec un taux d'échappement de défauts en inspection humaine (les défauts qui passent) estimé en interne à 0,3 %, soit environ 1 500 unités défectueuses qui arrivent chez les clients chaque mois.

L'accuracy seule est trompeuse ici, car la plupart des unités sont « conformes » : un modèle paresseux qui prédirait toujours « conforme » obtiendrait un score d'accuracy élevé tout en ne détectant aucun défaut. Ce qui compte, c'est le recall sur la classe « défaut » spécifiquement : sur l'ensemble des défauts réels, quel pourcentage le modèle a-t-il attrapé ?

Si le chiffre de 99,7 % du fournisseur A correspond à l'accuracy globale mais que son recall sur les défauts déclaré n'est que de 80 %, cela signifie que 20 % des défauts réels passent toujours, soit ici environ 300 unités par mois qui échappent encore. Cela peut battre ou non votre baseline humaine actuelle, mais vous ne pouvez pas le savoir sans demander au fournisseur de communiquer le recall et la precision (sur tout ce qui a été signalé comme défectueux, quel pourcentage l'était vraiment) séparément, et pas seulement une accuracy agrégée.

Checklist des signaux d'alerte

• Une accuracy annoncée sans baseline précisé ni détail par classe
• Aucune mention de la façon dont le modèle traite les cas limites (nouveau SKU, nouveau design d'étiquette, changement d'éclairage)
• Une tarification basée sur le nombre de caméras/capteurs sans mention du data engineering ni de la main-d'œuvre d'intégration
• Une proposition de PoC sans critères d'échec fermes
• Le fournisseur ne peut citer aucun déploiement en production comparable (pas une démo, une usine réellement en fonctionnement) que vous puissiez appeler en référence

🎬 [VIDEO: "How to Evaluate AI Vendors" - youtube.com/results?search_query=how+to+evaluate+ai+vendors+manufacturing - cherchez des interventions récentes sur l'évaluation des fournisseurs orientées industrie lors de conférences sectorielles comme Hannover Messe ou MODEX, qui publient régulièrement les enregistrements de sessions]

Les réalités de l'adoption après un pilote réussi

Réussir un PoC n'équivaut pas à être prêt pour le passage à l'échelle. Deux vérifications supplémentaires comptent avant un déploiement sur plusieurs lignes ou plusieurs usines :

Est-ce que ça généralise ? Un modèle ajusté sur l'éclairage et l'angle de caméra de la ligne 3 peut nécessiter un ré-entraînement, et pas un simple redéploiement, pour la ligne 7. Demandez au fournisseur ce que coûte réellement le « scaling » : est-ce du copier-coller, ou un mini-projet par ligne ?

Qui l'entretient ? Les modèles dérivent (la performance se dégrade à mesure que les conditions réelles s'écartent des conditions d'entraînement). Demandez qui surveille la performance du modèle en production, à quelle fréquence a lieu le ré-entraînement, et ce que cela coûte annuellement. Ce coût récurrent est fréquemment absent de la proposition initiale et peut rivaliser avec le coût d'implémentation d'origine sur deux à trois ans (il s'agit d'un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → général observé dans les déploiements d'IA en entreprise, pas d'un chiffre sectoriel fixe : validez-le sur votre contrat spécifique).

Points clés

• Notez chaque proposition fournisseur sur trois dimensions : data readiness (avez-vous les données annotées dont le modèle a besoin), effort d'intégration (ce qu'il faut pour se connecter à votre environnement OT/IT réel) et conception du PoC (le succès/échec est-il défini à l'avance avec des chiffres).
• Exigez des métriques par classe (recall, precision) pour les problèmes déséquilibrés comme la détection de défauts, et non une accuracy agrégée, qui peut masquer une mauvaise performance sur le terrain.
• Un PoC crédible comporte un seuil de succès chiffré, une durée réaliste qui capte la variabilité de production, un baseline énoncé et une sortie contractuelle en cas d'échec.
• Réussir un pilote sur une ligne ne garantit pas un passage à l'échelle peu coûteux sur les autres ; interrogez les coûts de ré-entraînement par ligne et la maintenance continue du modèle avant d'engager du budget.
• Appelez en référence des déploiements réellement en production, pas des démos, et méfiez-vous des fournisseurs qui refusent de s'engager sur des critères d'échec fermes.