Vision par ordinateur pour lignes de production : développer ou acheter ? Guide de décision honnête

Vos ingénieurs ont vu les démos. Un modèle YOLO pré-entraîné encadre des produits sur un ordinateur portable en un après-midi. La question revient donc dans chaque usine qui veut des comptages par caméra pour son TRS : pourquoi payer un fournisseur si les modèles sont gratuits ?

La question est légitime, et développer est parfois la bonne réponse. Ce guide montre ce qu'implique un développement interne, où partent les heures et comment décider poste par poste. Il ne couvre que la couche caméra ; pour le logiciel TRS en général, voir développer ou acheter un logiciel TRS.

Ce que vous décidez vraiment

Il s'agit ici de compter la production et d'alimenter le TRS, souvent sur des postes sans signal machine exploitable : conditionnement manuel, machines anciennes, encaisseuse sans sortie automate disponible. Le contrôle qualité (défauts, étiquettes, codes, niveaux de remplissage) est un autre sujet, avec sa propre décision. Si vous n'êtes pas sûr qu'un poste ait besoin d'une caméra, voir caméra ou capteur pour le TRS, machine par machine.

Le vrai choix se fait donc entre trois voies :

• Développer : votre équipe choisit les caméras et les boîtiers edge, entraîne des modèles open source, écrit la logique de comptage et la relie à vos données TRS.
• Acheter un module caméra : un fournisseur apporte le comptage et sa liaison au TRS, et vous installez, alimentez et raccordez au réseau les caméras avec lui.
• Acheter une plateforme de vision, développer le modèle : votre équipe annote et entraîne dans l'outil d'un fournisseur. Nos pages alternatives à Landing AI et alternatives à Elementary comparent les acteurs de ce segment, tels que chacun se présente.

Ce qu'implique un développement interne

Les outils open source rendent la première étape facile. OpenCV, l'Open Source Computer Vision Library, est publiée sous licence Apache-2.0. Ultralytics YOLO fournit des modèles de détection pré-entraînés à affiner sur vos produits. Un prototype sur une caméra est un objectif réaliste pour un ingénieur compétent. Mais un système de comptage auquel une usine peut se fier à chaque équipe exige toutes ces briques :

• Caméras, objectifs, éclairage et supports qui résistent au lavage, aux vibrations et aux chariots élévateurs. Le placement et l'éclairage pèsent plus sur la précision que le modèle ; voir placement des caméras et éclairage sur une ligne de production.
• Un boîtier edge par ligne ou pour quelques caméras, avec GPU, système d'exploitation, pilotes et correctifs de sécurité, plus le réseau pour remonter les résultats.
• Des données d'entraînement annotées. Le guide Ultralytics sur la collecte et l'annotation des données (EN) indique que quelques centaines d'objets annotés par classe suffisent pour commencer à expérimenter l'apprentissage par transfert, et recommande au moins 1 500 images et 10 000 instances annotées par classe pour des performances fiables en conditions réelles.
• Une logique de comptage au-dessus de la détection : suivre chaque unité dans une zone, pour qu'un paquet qui s'arrête ou touche son voisin soit compté une fois, pas deux.
• La liaison au TRS : états machine, équipes, produits et cadences idéales, pour qu'un comptage devienne performance et qualité, pas seulement un chiffre à l'écran.
• L'exploitation des modèles : gestion de versions des modèles et des données, suivi de la précision des comptages et moyen de revenir en arrière après un mauvais modèle.

Les chercheurs qui exploitent l'apprentissage automatique en production alertent sur cet écart depuis des années. Dans « Hidden Technical Debt in Machine Learning Systems » (EN), des ingénieurs de Google estiment qu'il est « dangereux de considérer ces gains rapides comme gratuits ». Le gain rapide, c'est la démo. La dette, c'est tout ce qui l'entoure.

Les changements d'emballage, la charge cachée

Sur une ligne de produits de grande consommation, le produit change sans cesse : nouveau visuel, manchon promotionnel, nouveau format, autre film. Pour la caméra, chacun est un objet d'aspect nouveau.

L'apprentissage automatique a un nom pour cela : la dérive. Une revue publiée dans IEEE Transactions on Knowledge and Data Engineering, « Learning under Concept Drift: A Review » (EN), définit la dérive conceptuelle comme des « changements imprévisibles, au fil du temps, de la distribution sous-jacente des données en flux ». Sur une ligne de conditionnement, les changements sont souvent prévisibles, car planifiés, mais l'effet est le même. Un modèle entraîné sur les emballages de l'an dernier peut manquer ou compter deux fois ceux de cette année.

La dérive est silencieuse. Rien ne plante ; le comptage est simplement un peu bas, et le TRS paraît plus faible qu'en réalité. L'exemple chiffré ci-dessous montre de combien. Le guide sur la précision du TRS par caméra explique comment tester les comptages face à une référence.

Qui répare à 3 h du matin ?

Les lignes tournent la nuit et le week-end. Quand un boîtier edge se fige ou qu'une caméra est heurtée à 3 h du matin, les données TRS de cette ligne s'arrêtent ou deviennent fausses jusqu'à ce que quelqu'un répare. En développement interne, ce quelqu'un fait partie de vos effectifs.

Une seule personne ne peut pas être d'astreinte toutes les nuits de l'année. Une vraie astreinte exige au moins deux personnes qui connaissent le système, plus des procédures écrites pour l'équipe en poste. Si votre équipe data se résume à un ingénieur qui gère aussi l'historian de l'usine, c'est un risque, pas un détail, et il s'aggrave le jour où cet ingénieur part.

Licences : la facture de l'open source

Gratuit au téléchargement ne veut pas toujours dire gratuit à l'usage en usine. La page des licences d'Ultralytics (EN) indique : « Une licence Enterprise est requise si vous souhaitez utiliser Ultralytics YOLO sans publier en open source l'intégralité de votre projet. » La même page cite les outils métier internes et les déploiements embarqués sur équipements edge et caméras parmi les cas concernés. OpenCV lui-même est sous Apache-2.0, une licence permissive. Ceci n'est pas un conseil juridique : soumettez la liste exacte des bibliothèques et des modèles à votre service juridique avant toute mise en production, et budgétez une éventuelle licence commerciale en plus des heures.

Développer ou acheter : le tableau de décision

Développer vous donne la maîtrise. Acheter transfère le travail récurrent (annotation, réentraînement, correctifs, astreinte de nuit) à quelqu'un dont c'est le métier. Ce qui vaut le plus dépend de votre équipe et de vos postes.

Vous voulez voir comment un module caméra alimente le TRS avant de décider ? Demandez une démo et apportez votre liste de postes.

Modèle d'effort d'exemple : la première année d'un développement

Exemple illustratif, données fictives. Une usine équipe de caméras 4 lignes qui produisent 4 formats d'emballage. L'équipe annote selon la recommandation d'Ultralytics de 1 500 images par classe et passe 1 minute par image. Le marketing change les emballages 8 fois par an. Ce sont des hypothèses d'exemple, pas des références : remplacez-les par les vôtres.

• Annotation initiale : 4 formats × 1 500 images × 1 minute = 6 000 minutes = 100 heures.
• Entraînement du modèle et tests de réception : 80 heures (exemple).
• Logique de comptage, suivi et liaison aux états TRS, équipes et cadences idéales : 320 heures (exemple).
• Entretien des boîtiers edge et des caméras : 4 lignes × 2 heures × 12 par an = 96 heures.
• Réentraînement après changements d'emballage : 8 changements × 1 500 images × 1 minute = 200 heures, plus 8 essais × 6 heures = 48 heures, soit 248 heures.

Total de la première année : 100 + 80 + 320 + 96 + 248 = 844 heures. Sur une année de travail d'exemple de 1 700 heures, cela représente environ un demi-ingénieur. La deuxième année, l'annotation et la logique sont faites, mais l'entretien et le réentraînement restent : 96 + 248 + 80 heures de corrections et d'évolutions (exemple) = 424 heures, soit environ un quart d'ingénieur, chaque année. Ces heures n'incluent pas les interventions de nuit.

Ce que la dérive silencieuse fait au TRS

Exemple illustratif, données fictives. Une ligne, une équipe : 450 minutes de temps de production planifié, 400 minutes de temps de fonctionnement, une cadence idéale de 100 unités par minute. La ligne produit réellement 34 000 unités, dont 680 rebuts.

• Disponibilité = 400 ÷ 450 = 88,9 %.
• Performance = 34 000 ÷ (400 × 100) = 85,0 %.
• Qualité = 33 320 ÷ 34 000 = 98,0 %.
• TRS = 88,9 % × 85,0 % × 98,0 % = 74,0 %. Vérification : 33 320 unités bonnes ÷ (450 × 100) = 74,0 %.

Arrive un nouveau manchon, et le modèle manque 3 % des unités sans que personne ne s'en aperçoive. Il compte 32 980 unités. La performance tombe à 82,5 %, la qualité (avec les mêmes 680 rebuts) à 97,9 %, et le TRS à 71,8 %. La ligne ne s'est pas dégradée. Le comptage, si. Une équipe qui chercherait ces 2 points de TRS perdus courrait après un problème de modèle. C'est pourquoi les audits de comptage et un plan de réentraînement ont leur place dans le dossier d'investissement, quelle que soit l'équipe qui développe le système.

Quand développer est le bon choix

Développer n'est pas une mauvaise réponse en soi. Cela convient bien à un petit nombre d'usines.

Choisissez de développer si :

• Le poste est unique : un produit inhabituel, un procédé qu'aucun fournisseur n'a vu, ou un comptage qui exige une logique sur mesure.
• Vous avez déjà une équipe data qui exploite des modèles en production, avec astreinte et documentation.
• La vision fait partie de votre avantage concurrentiel, donc maîtriser le modèle compte plus que les heures.
• Votre service juridique a validé les licences, et vous êtes prêt à financer ce travail chaque année, pas une seule fois.

Choisissez d'acheter si :

• Vos lignes traitent des paquets, caisses et barquettes standard, et l'objectif est un comptage pour le TRS, pas un projet de recherche.
• Vos ingénieurs sont plus utiles sur les changements de format et les pertes que sur l'entretien de modèles.
• Personne ne peut garantir pendant des années une astreinte de nuit pour le système de caméras.

Faites les deux si : la plupart des postes sont standard, sauf un. Achetez le comptage pour les lignes standard, et affectez votre équipe au seul poste qu'aucun fournisseur ne couvre. Si vous développez quelque part, menez-le comme un pilote avec des critères de sortie clairs ; le guide pilote de vision par ordinateur pour le TRS les définit.

Questions à poser à tout fournisseur, ou à votre propre équipe

Les mêmes questions valent dans les deux sens. Si votre équipe ne sait pas y répondre, vous avez votre réponse sur le développement interne.

1. Qui annote les données d'entraînement, et combien d'images par produit le premier modèle demande-t-il ?
2. Quand l'emballage change, qui réentraîne le modèle, en combien de temps, et comment le comptage est-il vérifié avant la nouvelle production ?
3. Comment la précision du comptage est-elle testée face à un comptage de référence, et à quelle fréquence après la mise en service ?
4. Qui applique les correctifs au boîtier edge et aux caméras, et qui remarque quand l'un d'eux est hors ligne ?
5. Qui répond à 3 h du matin un dimanche, et qu'est-ce qui est documenté pour l'équipe en poste ?
6. Quelles bibliothèques et quels modèles open source sont utilisés, et sous quelles licences ?
7. Comment les comptages se rattachent-ils aux états machine, aux équipes et aux cadences idéales pour devenir du TRS ?
8. La vidéo est-elle stockée, où, et qui peut la voir ? Voir le stockage vidéo des lignes et des caméras sans surveillance.

La place de Fabrico

Fabrico est une plateforme cloud de logiciel TRS (OEE) et de MES léger. Les arrêts et les comptages proviennent du signal machine (automate, capteur ou compteur), et l'opérateur saisit la cause d'arrêt sur la ligne, sur tablette ou téléphone. Le TRS, les arrêts et les pertes s'affichent par ligne et par équipe, avec les pertes chiffrées en argent.

Pour les postes sans signal exploitable, Fabrico propose sur demande un module caméra de vision par ordinateur. Le module caméra compte la production sur la ligne, y compris aux étapes manuelles, et ces comptages alimentent le même TRS que les données machine. Avec le module caméra, vous pouvez ouvrir la vidéo de n'importe quel moment sur la chronologie de l'équipe ; dans la configuration standard, la vidéo est diffusée à la demande, pas stockée. Le fonctionnement du comptage est expliqué dans le comptage visuel par IA en production.

Feuille de route, clairement signalée : la détection des arrêts par caméra et les suggestions de causes d'arrêt que l'opérateur confirme figurent sur la feuille de route, pas disponibles aujourd'hui. Fabrico ne vend pas de contrôle qualité. Des modules d'IA sur mesure sont proposés en développement spécifique sur demande, pour le rare poste qui en a besoin.

Les données sortent de Fabrico par une API REST, des webhooks et un export Excel ou CSV. La gestion des changements d'emballage, et la possibilité d'intégrer les comptages de votre propre modèle, sont des questions pour la démo. Testez ces affirmations comme celles de tout fournisseur. Pour savoir où les caméras se justifient dans les produits de grande consommation, voir la vision par ordinateur pour l'industrie des produits de grande consommation.

Questions fréquentes

Est-il moins cher de développer la vision par ordinateur en interne ?

Le code et les modèles peuvent coûter peu, voire rien. Les heures, elles, ont un coût. Dans le modèle d'exemple de cette page, une équipe passe 844 heures la première année puis 424 heures chaque année suivante, surtout en intégration et en réentraînement. Mettez vos propres heures à côté du devis de chaque fournisseur, et demandez à chaque fournisseur de chiffrer la même liste de postes pour que les chiffres soient comparables.

Peut-on commencer avec YOLO en open source et passer à un fournisseur plus tard ?

Oui, et un essai court est un moyen peu coûteux de mesurer la difficulté de comptage de vos produits. Vérifiez la licence avant toute mise en production : Ultralytics indique qu'une licence Enterprise est nécessaire si vous voulez utiliser ses modèles YOLO sans publier en open source l'ensemble de votre projet. Conservez les comptages et les définitions de votre essai, pour pouvoir les comparer aux comptages d'un fournisseur sur les mêmes équipes.

Combien d'images faut-il annoter ?

Ultralytics indique que quelques centaines d'objets annotés par classe suffisent pour commencer à expérimenter l'apprentissage par transfert, et recommande au moins 1 500 images et 10 000 instances annotées par classe pour des performances fiables en conditions réelles. Chaque format d'emballage d'aspect différent peut justifier sa propre classe ou des données d'entraînement supplémentaires.

Que devient un modèle de comptage quand l'emballage change ?

Le produit n'a plus le même aspect pour la caméra, donc le modèle peut manquer des unités ou en compter une deux fois. Prévoyez de nouvelles images, de nouvelles annotations et un essai avant que le nouveau visuel n'arrive sur la ligne. Si vous achetez, demandez à chaque fournisseur qui gère un changement d'emballage, en combien de temps, et comment il prouve ensuite que le comptage est juste.

Peut-on utiliser notre propre modèle avec le logiciel TRS d'un fournisseur ?

Souvent, si le logiciel TRS accepte des comptages provenant de sources externes. Demandez à chaque fournisseur comment les comptages externes arrivent et comment ils se rattachent aux états machine et aux équipes. Pour Fabrico, la possibilité d'intégrer les comptages de votre propre modèle sur une ligne donnée est une question à poser pendant la démo.

Un module caméra pour le TRS remplace-t-il nos caméras d'inspection ?

Non. Les systèmes d'inspection contrôlent les défauts, les étiquettes, les codes et les niveaux de remplissage. Un module caméra pour le TRS compte la production. Les deux coexistent, et les rebuts d'un système d'inspection peuvent alimenter le taux de qualité du TRS via le comptage ou le signal de rebuts de la ligne.

Vous voulez comparer l'achat avec votre projet de développement ? Demandez une démo et voyez-le sur une ligne comme la vôtre.