Système propriétaire qui bloque : testez avant de le remplacer

Un composant à deux mille euros que personne ne comprenait vraiment

Sur un projet de remplacement d'un système de vision industrielle propriétaire, l'équipe technique s'est retrouvée bloquée par un composant que personne ne savait vraiment expliquer. Un boîtier de capture d'image, facturé environ deux mille euros par le fournisseur historique, semblait indispensable au fonctionnement de la ligne de tri, sans que personne dans l'équipe ne puisse dire précisément à quoi il servait ni pourquoi son remplacement coûterait si cher.

Le réflexe naturel, dans cette situation, aurait été de rassembler la documentation technique du fournisseur, d'organiser des ateliers de compréhension, ou de commander directement un composant de remplacement équivalent avant même d'avoir vérifié s'il était réellement nécessaire. Ce système propriétaire bloquait déjà le projet depuis plusieurs semaines, sur une ligne à haute cadence où chaque composant semblait interdépendant du suivant.

La décomposition plutôt que la documentation

Un composant technique incompris est le plus souvent un symptôme de manque d'expérimentation, pas de manque de documentation. Plutôt que de continuer à chercher une explication théorique au rôle exact de ce boîtier, l'équipe a testé une hypothèse simple, débrancher les caméras et les buses concernées pour observer si le reste du système continuait à fonctionner sans lui. Ce test ne coûtait rien, ne nécessitait aucun accord du fournisseur, et donnait une réponse en quelques minutes là où des semaines de documentation n'en avaient donné aucune.

Remplacer une caméra à plusieurs milliers d'euros par une GoPro

La même logique a été appliquée à un deuxième composant du système, une caméra linéaire industrielle dont le remplacement standard représentait un investissement lourd. Avant d'engager cette dépense, l'équipe a testé la chaîne de détection avec une GoPro grand public, à quelques centaines d'euros, pour vérifier si la qualité d'image suffisait aux besoins réels du modèle de détection. Le test a permis de trancher une question que des mois de discussion théorique n'auraient pas résolue aussi vite, ni aussi honnêtement.

Avant de remplacer un système, la vraie question n'est pas ce qu'il fait sur le papier, c'est ce qui, dans ce qu'il fait, est réellement utilisé. Souvent, une fraction seulement de la complexité d'un système hérité sert l'essentiel du besoin réel, le reste n'est qu'une architecture accumulée au fil du temps, jamais remise en question parce que personne n'avait testé ce qui se passait si on la retirait.

Ce réflexe de décomposition n'est pas propre au hardware. Un logiciel propriétaire hérité pose exactement la même question, quelle proportion de ses fonctions sert réellement l'activité, et laquelle n'est qu'un héritage jamais remis en cause. Sur les stratégies pour sortir progressivement d'une dépendance à un éditeur logiciel sans tout casser d'un coup, l'article sur la dépendance aux éditeurs de logiciels détaille une méthode d'audit similaire, appliquée cette fois au logiciel plutôt qu'au matériel.

Le test à bas coût, et pourquoi il exige du courage

Chez Leando, nous appelons ce principe le test à bas coût, avant d'investir dans le remplacement d'un composant ou d'un système propriétaire qui bloque un projet, tester la moins chère des hypothèses de contournement possible, plutôt que d'attendre l'autorisation ou la solution du fournisseur qui, précisément, cause le blocage. Le principe exclut d'attendre une validation externe avant de vérifier soi-même ce qu'on peut vérifier en une heure et pour quelques centaines d'euros.

Ce type de test suppose une forme de courage rarement enseignée, celui d'agir sans demander la permission à qui bloque le projet. Sur ce même dossier, face à un fournisseur historique jugé peu réactif après des mois de retard non tenu, la décision a fini par être tranchée sans attendre une nouvelle validation.

« On va tout débrancher, puis on va remplacer par quelque chose d'autre. »

Cette décision n'a été possible que parce que le test à bas coût avait déjà, en amont, validé que le système pouvait fonctionner autrement. Sans ces essais préalables à quelques centaines d'euros, une décision aussi radicale que débrancher un système propriétaire en place depuis des années aurait relevé du pari plutôt que d'un choix informé.

Le vrai coût de ne pas tester

L'argument le plus fréquent contre ce type de test reste le temps qu'il prend à organiser, même minime. Cet argument oublie de comparer ce coût à celui de l'alternative réelle, rester bloqué en attendant une réponse d'un fournisseur qui n'a montré, jusque-là, aucun signe d'urgence partagée. Sur ce dossier, chaque semaine de blocage supplémentaire rapprochait l'équipe de la fin de la saison de production du client, un délai qu'aucun remboursement ni aucune excuse contractuelle ne pouvait compenser une fois la fenêtre refermée.

Un test à quelques centaines d'euros qui échoue ne coûte presque rien, il élimine simplement une hypothèse et en libère une autre. Un mois d'attente passive qui échoue coûte une saison entière. La comparaison, posée en ces termes, rend la décision de tester nettement moins risquée qu'elle ne le paraît au premier abord, surtout face à une équipe qui hésite encore par respect excessif pour un fournisseur qui, de son côté, ne montre pas le même égard pour le calendrier du client.

Cette même hésitation explique pourquoi tant d'équipes préfèrent commander un devis de remplacement complet plutôt que de tester une hypothèse à quelques centaines d'euros, un devis se justifie facilement en interne, il ressemble à une décision sérieuse. Un test rapide et bricolé, même s'il coûte dix fois moins cher et répond à la question plus vite, ressemble davantage à de l'improvisation aux yeux d'une direction habituée à valider des investissements documentés. C'est pourtant souvent l'inverse qui est vrai, un devis rassure sans rien prouver, un test, même modeste, prouve quelque chose de concret avant d'engager le moindre budget.

Ce que ce principe n'autorise pas

Le test à bas coût ne veut pas dire tester n'importe quoi n'importe comment. Chaque hypothèse testée sur ce dossier l'a été hors production ou sur une fenêtre courte et maîtrisée, jamais directement sur la ligne en fonctionnement, et toujours avec un plan pour revenir en arrière si le test échouait. Le principe exclut de confondre l'audace de tester à moindre coût avec l'imprudence de tester sans filet sur un système critique.

Ce même dossier illustre aussi pourquoi cette question dépasse le seul composant qui bloque en apparence, la propriété intellectuelle d'une solution qui commence à fonctionner mérite d'être cadrée avec la même discipline, avant que le résultat ne change le rapport de force, l'article sur la propriété intellectuelle d'un pilote industriel détaille pourquoi. Et sur la manière de structurer méthodiquement une phase de validation technique avant d'industrialiser une solution d'IA, l'article sur le POC industriel avant industrialisation détaille les sorties contractuelles à prévoir dès cette étape.

Ce réflexe se heurte souvent à un obstacle qui n'est pas technique mais hiérarchique, la peur de froisser un fournisseur historique ou de devoir justifier une initiative prise sans validation formelle. Sur ce dossier, l'équipe a anticipé les scénarios d'échec avant de tester, en préparant à l'avance la manière dont elle expliquerait la démarche si le test devait mal tourner. Cette préparation n'a rien coûté de plus, et elle a suffi à lever l'hésitation qui aurait autrement retardé le test de plusieurs semaines supplémentaires.

Avant votre prochaine décision de remplacer un système qui vous bloque, cherchez d'abord l'hypothèse la moins chère à tester. Si elle n'existe pas encore dans votre réflexion, c'est probablement le signe que vous êtes passé directement à la solution, sans avoir vérifié ce que le problème exigeait vraiment.