À l'automne 2022, un ami qui dirige un entrepôt de distribution de pièces automobiles à Fontana m'a appelé, enthousiaste. Il venait de déployer l'inspection visuelle par IA à la réception : des caméras industrielles au-dessus de la voie d'entrée, détectant automatiquement les pièces manquantes, les étiquettes erronées et les cartons endommagés, bien plus vite que les contrôles manuels. Je l'ai félicité, mais quelque chose me tracassait : la société derrière le système était une startup qui venait de boucler sa série A.
Un an plus tard, cette startup a fait faillite. Les services cloud se sont éteints, les mises à jour du modèle ont cessé et, pire que tout, le système d'inspection était lié à l'API cloud du fournisseur. Quand le service est mort, toute la ligne d'inspection s'est éteinte du jour au lendemain. Mon ami a passé plus de trois mois à relancer les appels d'offres et à redéployer. La haute saison est venue et repartie. Ce qu'il a perdu, m'a-t-il dit plus tard, ce n'était pas le coût du système : c'étaient trois mois de travail manuel pendant la haute saison et les clients qui sont partis.
Depuis, j'ai ajouté une question obligatoire pour chaque client qui envisage l'IA : que se passe-t-il si votre fournisseur disparaît ? Ce n'est pas une question de pessimisme. Acheter de l'IA n'est pas comme acheter un équipement. Quand vous achetez un convoyeur, il vous appartient. Avec un système d'IA, les modèles, les données et le code source appartiennent par défaut au fournisseur. Tant que le fournisseur est en vie, tout va bien. Quand il a disparu, vous ne pouvez même plus ouvrir le système.
Un contrat sans clauses de sortie n'est pas un contrat
La plupart des contrats avec des fournisseurs d'IA ont exactement une ligne sur la sortie : "Les services cesseront dans les 30 jours suivant la résiliation." Autant dire rien. En réalité, quatre choses doivent y figurer.
Premièrement, l'entiercement du code source. Le code source, les poids du modèle et la documentation de déploiement sont confiés à un tiers entierceur neutre, avec des déclencheurs de libération précisés : faillite du fournisseur, interruptions de maintenance au-delà d'un nombre convenu de jours, ligne de produit abandonnée après une acquisition. Dès que l'un de ces cas survient, l'entiercement vous est remis. Sans cela, le jour où votre fournisseur fait faillite, vous ne pouvez même pas voir à quoi ressemble le système à l'intérieur.
Deuxièmement, la restitution des données. Le format, le délai et l'exhaustivité doivent être précisés : sous quel format les jeux de données brutes et étiquetées reviennent (pas un format propriétaire que vous ne pouvez pas ouvrir), combien de jours après la résiliation, et le fournisseur doit détruire ses copies après. Omettez cette clause et vos données d'exploitation sont un cadeau gratuit.
Troisièmement, la propriété des poids du modèle. Un modèle entraîné sur vos données : à qui appartiennent les poids ? Beaucoup de contrats les attribuent par défaut au fournisseur, ou utilisent des formules évasives comme "propriété conjointe". Exigez un langage clair : les modèles et les poids dérivés entraînés sur les données du client appartiennent au client. Si le fournisseur refuse, obtenez au minimum une licence perpétuelle et irrévocable qui survit à la résiliation.
Quatrièmement, le support de transition. Après la résiliation, le fournisseur fournit plusieurs mois de support opérationnel en lecture seule, ou accorde le droit d'auto-héberger. La migration ne se fait pas du jour au lendemain. Sans fenêtre de transition, l'ancien système est mort avant que le nouveau soit en service, et personne ne couvre l'intervalle entre les deux.
Les commerciaux vous diront à la signature que c'est une grande entreprise, qu'ils viennent de lever des fonds, qu'ils ne feront jamais faillite. N'y croyez pas. Beaucoup de startups IA bien financées ont disparu ces dernières années, et beaucoup d'autres ont été rachetées pour voir leur ligne de produit abandonnée. Pour vous, le résultat est le même : personne ne maintient votre système.
La seule chose qui vous appartient vraiment, ce sont les données
Prenons du recul : même avec un contrat parfait, si le fournisseur a vraiment disparu, qu'est-ce qui fait tourner votre exploitation ? Les données. Les modèles peuvent être remplacés, les fournisseurs peuvent être remplacés. Ce qui ne peut pas être remplacé, ce sont les données étiquetées et les règles métier que vous avez accumulées au fil des années.
Les données étiquetées sont votre actif principal. Les échantillons de défauts de l'inspection visuelle, les journaux de corrections du picking vocal, les commandes historiques qui alimentent la prévision de la demande : le fournisseur a construit tout cela sur votre activité, et le contrat doit dire que cela vous appartient. Avec les données en main, le réentraînement avec un nouveau fournisseur prend des mois. Sans elles, vous repartez de zéro, et cela prend des années. Pendant la haute saison, cet écart est la différence entre survivre et ne pas survivre.
Les règles métier sont tout aussi précieuses. Les seuils, la logique de traitement des exceptions et les règles spécifiques au processus intégrées dans le système d'IA — quelles catégories de produits ont quels standards d'inspection, par exemple — doivent être exportées sous forme de documentation selon un calendrier régulier, et non rester dans le système du fournisseur. Le pire cas que j'ai vu n'était pas un modèle perdu ; c'étaient trois années de standards d'inspection vivant entièrement dans la base de données de configuration du fournisseur. Quand le fournisseur est parti, les standards sont partis avec lui, et le fournisseur de remplacement a dû tout réapprendre.
Alors, les modèles open source peuvent-ils prendre le relais ? Mon avis : cela dépend du cas d'usage. Les scénarios matures comme l'inspection visuelle et l'OCR regorgent d'options open source, et le coût de migration se résume principalement à ré-étiqueter et ré-intégrer : quelques ingénieurs ML internes peuvent s'en charger. Mais les cas d'usage profondément couplés comme l'optimisation de la planification ou la prévision de la demande, où la logique métier est enchevêtrée avec vos systèmes d'entrepôt, c'est une autre histoire. Changer de fournisseur là-bas, c'est reconstruire la moitié du projet. Demandez ceci pendant la sélection : si ce fournisseur disparaissait, pourrais-je prendre la relève à un coût raisonnable ? Si la réponse est non, soit ne le déployez pas, soit intégrez le coût de sortie dans le coût total de possession.
Faites un exercice de sortie chaque année — pour de vrai
Clauses rédigées, données sécurisées, il reste une étape : la pratique. Personne ne pense qu'un exercice d'incendie est un mauvais présage, et un exercice de sortie, c'est la même chose. Une fois par an, exercice simple : supposez que le fournisseur disparaît demain, et consacrez quelques jours à vérifier trois choses : les données peuvent-elles être exportées en totalité, les modèles peuvent-ils tourner dans votre propre environnement, et les processus métier critiques ont-ils un repli manuel qui ne dépend pas du fournisseur ?
Le premier exercice échoue presque toujours : les données exportées manquent de champs, le modèle dépend des bibliothèques propriétaires du fournisseur, un rapport critique n'existe que dans le portail du fournisseur. L'échec est une bonne nouvelle : cela signifie que le plan a des failles, et vous pouvez les corriger pendant que le fournisseur est encore là. Essayer de les corriger après la disparition du fournisseur, c'est trop tard.
Inutile d'en faire des tonnes. Votre responsable informatique le dirige, l'exploitation participe, une fois par an, d'une demi-journée à une journée entière. Une assurance bon marché, et la seule preuve que le plan n'est pas que du papier. Un avantage bonus : conservez le rapport d'exercice. La prochaine fois que vous renouvellerez, c'est un levier : quand le fournisseur sait que vous pouvez partir, les augmentations de prix deviennent beaucoup plus modestes.
Revenons donc à la question initiale : l'IA en vaut-elle la peine ? Oui, mais seulement si vous avez une porte de sortie. Lors de la sélection du fournisseur, ne vous contentez pas d'admirer la démo. Posez une question de plus : si votre entreprise n'existe plus l'année prochaine, que devient mon système ? La réponse vous dit si ce fournisseur mérite votre signature.
Trois choses à faire dès demain : premièrement, ajoutez une clause d'entiercement du code source avec déclencheurs de libération à tout contrat IA que vous négociez ; deuxièmement, pour les systèmes déjà en service, demandez une exportation complète des données et vérifiez qu'elle est réellement exploitable ; troisièmement, inscrivez un exercice de sortie annuel au calendrier, avec le premier le mois prochain. N'attendez pas : quand ce jour arrivera, personne ne vous enverra d'avertissement.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
