L'automne dernier, je conseillais un entrepôt 3PL dans l'Inland Empire — environ 120 000 pieds carrés — qui venait de déployer un modèle d'IA pour la prévision de réapprovisionnement. Le procès-verbal de réception était signé. L'équipe du fournisseur est partie à la troisième semaine. Au jour 96, le responsable de l'entrepôt m'a appelé : « Lao Mi, je crois que le système est cassé. Ses suggestions de réapprovisionnement deviennent de plus en plus folles chaque semaine. »
Je lui ai posé trois questions. Quelle était la précision de prévision du modèle la semaine dernière ? Il ne savait pas. Où vont les e-mails d'alerte ? Il est allé vérifier — et a découvert qu'ils continuaient d'arriver dans la boîte aux lettres que l'équipe projet du fournisseur avait configurée. Cette équipe avait été dissoute depuis deux mois. Les alertes tombaient dans une boîte de réception que personne n'ouvrait. Troisième question : qui a fixé les seuils de dérive ? Silence à l'autre bout du fil.
Ce n'est pas une histoire isolée. J'ai vu plusieurs projets d'IA mourir de la même façon ces dernières années — pas pendant la sélection, pas pendant le développement, mais dans les trois mois suivant la mise en service. Quand vous réceptionnez un équipement, un chariot élévateur ne change pas de voie tout seul. L'IA est différente. Elle mange de nouvelles données chaque jour, et quand les données changent, le modèle change avec elles. Sans personne pour surveiller, le « système d'IA » que vous possédez trois mois plus tard n'est plus celui que vous avez validé.
Le jour de la mise en service est le jour le plus risqué du projet
Voici un point de vue contre-intuitif : pour un projet d'IA, la signature de réception marque le début, pas la fin.
Les tests de réception se déroulent dans des conditions statiques. Les données ont été nettoyées par le fournisseur à l'avance, le jeu de test a été sélectionné avec soin, et le mix saisonnier a été choisi à la main. Bien sûr que le fournisseur veut que les métriques de réception soient belles — le paiement final est en jeu. Ce n'est pas de la malhonnêteté ; c'est la nature humaine.
Mais une fois que les vraies données commencent à affluer, tout change. De nouveaux clients apportent de nouveaux modèles de commandes. Le mix de SKU change. Les spécifications d'emballage sont remplacées. Les hautes et basses saisons alternent. Ce sont les « données sales » que le modèle n'a jamais vues pendant l'entraînement. J'ai vu un entrepôt passer de 92 % de précision de prévision à la réception à 78 % deux mois plus tard. La cause racine était presque drôle : les données d'entraînement ne contenaient aucune combinaison de SKU de la saison de pointe du Q4, alors le modèle s'est mis à deviner n'importe comment dès le début de la haute saison.
Mon verdict est donc brutal : les critères de réception doivent inclure une clause de retest à 90 jours. Signez deux fois — une fois à la mise en service pour confirmer que le système fonctionne, et une deuxième fois au jour 90 pour confirmer que le modèle tient toujours face aux vraies données. S'il échoue au second test, le paiement final reste sur la table et le fournisseur revient l'ajuster. Une clause dans le contrat vaut mieux que dix métriques supplémentaires le jour de la réception.
Beaucoup d'acheteurs ont peur de le demander. Ils craignent que le fournisseur le prenne comme de la méfiance. Je vois les choses à l'inverse : un fournisseur prêt à signer cette clause est un fournisseur qui croit vraiment en son modèle.
Les modèles ne meurent pas d'un coup. Ils deviennent bêtes lentement.
C'est la plus grande différence entre l'exploitation de l'IA et l'exploitation IT traditionnelle. Une panne de serveur est brutale — l'alarme sonne et tout le monde sait. La dérive du modèle est une maladie chronique. Un peu pire aujourd'hui, un peu pire demain, et trois mois plus tard vous réalisez qu'il est devenu discrètement inutile.
La dérive se présente sous deux formes, en termes simples. D'abord, les données ont changé : vous expédiiez 8 000 commandes par jour, maintenant c'est 12 000. Le client A représentait 60 % du volume ; maintenant c'est le client B qui domine. Le modèle a appris les schémas des anciennes données, et les nouvelles données ne les suivent pas. Ensuite, les relations ont changé : « les week-ends sont chargés » était vrai, puis les clients ont changé leurs habitudes de commande et les week-ends se sont calmés. Les données elles-mêmes ont l'air identiques, mais ce que les données signifient a bougé.
Le plus effrayant n'est pas la dérive elle-même — c'est que personne ne regarde. Dans cet entrepôt de l'Inland Empire, le système envoyait des alertes depuis des semaines. Les métriques de dérive avaient déjà dépassé le seuil. Mais les alertes allaient dans une boîte que personne ne lisait, ce qui revient à n'avoir aucune alerte. C'est le vide opérationnel dont je parle : le système parle, et personne n'écoute.
Comment le combler ? Le tableau des responsabilités doit être fixé avant la réception, et il doit nommer des personnes réelles — « le client est responsable » ne compte pas. Je recommande trois niveaux.
L'exploitation de l'entrepôt surveille les métriques métier quotidiennement. Personne ne ressent la qualité de prévision plus vite que l'exploitation — quand les suggestions de réapprovisionnement sont absurdes, les préparateurs se plaignent les premiers. Donnez-leur une règle simple : si les quantités suggérées s'écartent de la réalité au-delà d'un ratio fixe trois jours de suite, escaladez. Aucune connaissance d'algorithme nécessaire. Il suffit de lire les chiffres.
L'IT — ou le fournisseur — surveille les métriques du modèle chaque semaine. Scores de dérive, distributions des caractéristiques, confiance des prédictions. Il faut quelqu'un qui sache ce qu'il regarde. Si vous n'avez pas cette personne en interne, achetez du support modèle à distance du fournisseur dans le contrat ; la facturation trimestrielle convient. Ne lésinez pas ici. Si vous l'omettez, les centaines de milliers déjà dépensés peuvent partir en fumée.
Le management revoit la tendance mensuellement. La courbe de précision monte-t-elle ou descend-elle ? Combien a coûté le réentraînement, et cela valait-il le coup ? Trente minutes suffisent, mais la réunion doit avoir lieu. Sinon vous découvrez à la revue trimestrielle que le modèle est cassé depuis trois mois. Trop tard.
Qui fixe les seuils de dérive ? Ma réponse : le fournisseur propose, l'acheteur décide. Le fournisseur connaît le modèle et ce qui compte comme fluctuation normale. L'acheteur connaît le métier et le niveau d'erreur inacceptable. Fixez-les ensemble, écrivez-les dans le SOP et affichez-le au mur.
Un transfert qui n'est pas dans le contrat n'a pas eu lieu
C'est le trou le plus profond dans lequel je suis tombé. Dans un entrepôt, un projet d'inspection qualité par IA, le contrat disait « le fournisseur fournira une formation ». Avant la réception, le fournisseur a bien fourni une formation — une présentation de deux heures. Trois mois plus tard, le modèle s'est mis à dérailler, et l'ingénieur d'exploitation ne savait même pas où vivait le pipeline de caractéristiques. De quelle table venaient les données, sur quel serveur étaient les fichiers du modèle — trois questions, zéro réponse. Il a appelé le fournisseur. L'équipe projet avait disparu. Un représentant du support a dit qu'ils pouvaient « ouvrir un ticket de support payant ».
Alors maintenant je fais vérifier aux acheteurs une liste de transfert point par point avant de signer la réception. Quatre points. Il en manque un, on ne signe pas.
Premièrement, la documentation du modèle. Quelle est la liste des caractéristiques, quelle version des données d'entraînement a été utilisée, sur quelles hypothèses la modélisation reposait — des choses comme « suppose que le nombre de SKU reste constant » ou « suppose que la structure des commandes est stable ». Ces hypothèses sont vos futures lignes d'alerte de dérive. Dès qu'une hypothèse se brise, le modèle a besoin d'un réentraînement. Les documents n'ont pas besoin d'être élégants. Ils doivent être lisibles.
Deuxièmement, la configuration des alertes. Qui reçoit les alertes, qui est en copie, à quelle fréquence elles sont revues, qui escalade. Écrivez chaque adresse e-mail, et envoyez une alerte de test le jour de la réception pour confirmer qu'elle arrive. Ne riez pas — j'ai vu un projet où l'adresse d'alerte était mal orthographiée et personne ne l'a découvert avant la mise en service.
Troisièmement, le processus de réentraînement. Qui déclenche le réentraînement, quelles sont les conditions de déclenchement, qui l'exécute et qui paie. Le réentraînement n'est pas gratuit — la préparation des données, le calcul et la validation coûtent de l'argent. Si vous ne réglez pas cela à l'avance, les deux parties commencent à se renvoyer la balle quand quelque chose casse. J'ai vu un différend traîner pendant quatre mois. Le modèle est simplement resté là à pourrir pendant quatre mois.
Quatrièmement, le plan de retour arrière. Quand le modèle déraille, comment revenir à l'ancien moteur de règles d'un seul basculement ? Où est l'interrupteur, qui a le droit de le basculer, et comment le métier continue-t-il à tourner après le basculement ? C'est celui qu'on saute le plus souvent, mais quand les choses tournent mal, c'est celui qui vous sauve.
Le contrat a besoin de deux autres clauses : le support à distance du fournisseur pendant 6 à 12 mois après le départ de l'équipe, avec des délais de réponse écrits ; et la propriété des données — les données d'entraînement, les fichiers du modèle, le pipeline de caractéristiques — l'acheteur reçoit une copie complète de tout cela. Le fournisseur peut partir. Les actifs restent.
Voici le bilan. Un projet d'IA diffère de l'achat d'un équipement sur un point fondamental : l'équipement est une livraison unique, mais l'IA est quelque chose qui continue d'évoluer. Ce que vous réceptionnez n'est pas une machine. C'est une chose vivante qui a besoin d'être nourrie en continu. Si le contrat ne dit pas qui la nourrit, ce n'est qu'une question de temps avant qu'elle meure de faim.
Une question pour finir : si votre projet d'IA est mis en service demain, pouvez-vous nommer la boîte de réception à laquelle les e-mails d'alerte iront au jour 90 — et qui est responsable de les ouvrir ? Si ce n'est pas le cas, ne signez pas encore le formulaire de réception.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
