En 2022, j'étais dans un entrepôt 3PL en Ontario à regarder un fournisseur faire tourner un POC de comptage cyclique basé sur la vision. Sur site, la démo a atteint 98,6 % de précision — ils ont scanné un rack, les chiffres à l'écran étaient tous bons. Le responsable d'entrepôt voulait signer sur-le-champ. Le contrat disait seulement "payment due upon acceptance". Trois mois plus tard, le système est passé en production, et sur les vrais racks la précision est tombée à 84 %. Les cartons avec film rétractable réfléchissant sur les niveaux du haut ? La moitié méconnaissables. Le responsable m'a demandé quoi faire. Je lui ai dit que le contrat ne définissait jamais comment l'acceptation se mesure, donc en cas de litige, il ne récupérerait pas un centime. Dans les projets IA, huit mines sur dix sont enterrées dans le contrat.
Avant que l'argent ne sorte, figez la règle de mesure
Un POC n'est pas une démo — c'est là qu'on fixe la règle de mesure. Il y a trois règles, et les trois doivent être écrites dans une annexe au contrat avant la signature. Sans exception.
Règle un : les métriques d'efficacité. Elles répondent à « est-ce que ça voit juste ? ». N'écrivez pas seulement « accuracy » — définissez le numérateur et le dénominateur. Pour le comptage par vision, quelque chose comme : « 500 SKU du jeu de test, scannés sur des racks réels pendant 5 jours consécutifs, précision de reconnaissance ≥97 % (un succès valide exige SKU et quantité corrects) ». Les métriques d'efficacité ont aussi besoin d'un budget d'erreurs : quelles erreurs sont tolérables (cartons abîmés) et lesquelles sont à tolérance zéro (SKU à forte valeur — une erreur compte comme un échec).
Règle deux : les métriques d'ingénierie. Elles répondent à « est-ce que ça tourne de façon fiable ? ». Trois chiffres comptent le plus : la disponibilité (uptime ≥99 % sur 30 jours consécutifs, hors fenêtres de maintenance planifiée), la latence (réponse de reconnaissance ≤2 secondes au 95e percentile) et le taux de faux positifs (≤1 % ; chaque faux positif retire des points du score d'acceptation). Beaucoup de fournisseurs font la démo à la vitesse de l'éclair puis s'effondrent dès que le réseau tousse. Si les métriques d'ingénierie ne sont pas dans le contrat, vous regarderez simplement le système planter trois fois par semaine sans aucun recours.
Règle trois : les métriques business. Elles répondent à « est-ce que ça vaut l'argent ? ». À la fin du POC, vous devez produire deux chiffres : les heures de main-d'œuvre économisées (par ex., le temps de comptage cyclique par personne-jour passe de 6 heures à 1,5, en moyenne sur 10 cycles de comptage) et une porte de ROI (le contrat stipule : si les économies de main-d'œuvre annualisées < 1,5× le coût total du projet, le client peut se retirer de l'achat sans pénalité). La métrique business est la ligne de fond du patron — et votre permis pour tuer un mauvais projet.
Les trois astuces préférées des fournisseurs
Première : ils ne testent que le chemin heureux. Le rack de la démo a des cartons standards, un éclairage parfait, des codes-barres bien en face. Exigez ceci : le jeu de test vient de vous, échantillonné parmi les SKU qui bougent vraiment dans votre entrepôt — cartons abîmés, film réfléchissant, piles de travers, tout y est. Le contrat doit dire que le jeu de test est fourni par le client et que le fournisseur ne peut pas voir les échantillons précis à l'avance.
Deuxième : la contamination du jeu de test. Le fournisseur règle son modèle sur vos données de test à l'avance, alors évidemment ça score bien. La parade : préparez deux jeux de test. L'un est révélé à la signature pour le réglage ; l'autre est scellé et révélé seulement le jour de l'acceptation. Écrivez-le ainsi : « L'acceptation utilise un jeu de test aveugle, scellé par le client, que le fournisseur n'a jamais vu ».
Troisième : les données d'acceptation ne correspondent pas à votre environnement réel. Le POC a parfaitement tourné dans le Bâtiment 1, mais vous déployez dans le Bâtiment 5 — éclairage différent, hauteurs de racks, mix de SKU. Le contrat doit dire « environnement d'acceptation = environnement de déploiement final », ou au minimum « l'acceptation se déroule dans deux zones ou plus désignées par le client ».
Le runbook d'acceptation : qui teste, combien de temps, qui gagne une dispute
Chaque métrique du contrat suit le même modèle en cinq parties : la base de référence (ce que le travail manuel ou le système actuel accomplit aujourd'hui), la valeur cible (précise à une décimale), la méthode de mesure (qui fournit les données, avec quel outillage on mesure), la fenêtre de mesure (combien de jours consécutifs, combien de passages par jour) et la règle de réussite/échec (la barre, la politique de retest, combien d'échecs comptent comme un POC raté). S'il manque une des cinq, l'acceptation devient un concours de cris.
Voici le runbook que j'utilise d'habitude : les tests sont menés par le client avec le soutien du fournisseur, et les exports du WMS sont le système de référence pour les données tierces. La fenêtre de mesure court 14 jours consécutifs, au moins 3 équipes par jour. Chaque partie peut contester un résultat sous 48 heures, ce qui déclenche un retest ; le résultat du retest est définitif. Si le retest échoue encore, le client peut résilier sans conditions et le fournisseur rembourse les frais de POC déjà payés. Écrivez la résolution des litiges comme retest-pas-dispute — c'est la clause qui compte.
Encore une chose du terrain : les fournisseurs acceptent verbalement les métriques d'acceptation pendant la vente, puis commencent à faire traîner quand il faut les écrire dans l'annexe du contrat. Mon expérience est simple — celui qui apporte le modèle en premier détient l'avantage. Préparez une feuille d'acceptation vierge avec le modèle en cinq parties et envoyez-la-leur pour qu'ils la remplissent. C'est ça, prendre les devants. Si vous attendez que le fournisseur la rédige, chaque métrique qui vous favorise reviendra comme « to be mutually agreed » — quatre mots qui ne veulent rien dire.
Voici la vérité honnête : avant de signer, vous avez tout l'avantage dans un POC. Après avoir signé, tout ce qu'il vous reste, c'est de l'espoir. Demain, faites une chose : sortez le contrat de tout projet IA que vous négociez en ce moment et vérifiez si l'annexe d'acceptation contient bien les cinq — base de référence, cible, méthode de mesure, fenêtre de mesure, règle de réussite/échec. S'il manque un morceau, renvoyez-le et faites-le remplir par le fournisseur ; pour ce dont vous n'êtes pas sûr, fiez-vous au contrat et à la documentation officielle du fournisseur. Cette annexe est la seule vraie police d'assurance que vous aurez sur tout le projet. Et une question qui vaut la peine d'être posée honnêtement : si ce système disparaissait le trimestre prochain, votre exploitation remarquerait-elle la différence ? Si la réponse est non, le POC n'aurait jamais dû avoir lieu.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
