Logiciel d’acquisition de données machines : que choisir en 2026 (et que laisser de côté)
Un logiciel d’acquisition de données machines est la couche entre une ligne de production et n’importe quel système qui veut faire quelque chose d’utile avec ce que la ligne fait. Il lit les signaux des SPS, des capteurs, des systèmes de vision, du MES, et de plus en plus des caméras pointées sur la machine, puis transforme ces signaux en un flux qu’une base de données, un tableau de bord ou un modèle d’IA peut consommer.
La catégorie est passée d’un ou deux acteurs dominants à une vingtaine en cinq ans. La moitié résout un problème qui n’existait pas en 2020. L’autre moitié résout un problème que les gros éditeurs MES réglaient avant et ne veulent plus régler. Cet article est pour le responsable opérations ou IT qui établit une short list d’outils et veut une carte claire.
Ce que fait vraiment un logiciel d’acquisition de données machines
Au fond, trois choses. Se connecter à la source de données (SPS, capteur, caméra, MES, ERP, saisie manuelle). Normaliser la donnée dans un format cohérent avec un horodatage et l’unité. La passer au système qui la consomme (un historian, un tableau de bord, une base cloud, un modèle d’IA, le tableur d’un ingénieur procédés).
Les différences entre éditeurs portent presque uniquement sur la première étape et la troisième. Le milieu est devenu une commodité. Les éditeurs se distinguent sur le nombre de protocoles parlés en natif (Siemens S7, Allen-Bradley, Modbus, OPC UA, MQTT, EtherNet/IP, Profinet, plus la longue traîne des protocoles propriétaires) et sur le nombre de consommateurs intégrés (SQL, bases time-series, Snowflake, BigQuery, Azure Data Explorer, Power BI, Grafana, endpoints REST sur mesure).
Pour une petite ou moyenne usine, la couche connexion compte plus que la couche consommation. Pour une grande usine avec une stack analytics existante, c’est l’inverse.
Les cinq catégories d’outils en 2026
Cinq familles couvrent l’essentiel du marché en 2026.
1. Middleware historique proche du SCADA
Des outils nés des workflows historian et SCADA : AVEVA PI, Inductive Automation Ignition, Wonderware/AVEVA System Platform, GE Proficy. Forts sur les gros volumes de données SPS, faibles sur les intégrations cloud modernes et sur la donnée caméra. Onéreux (le coût des licences par tag ou par connexion monte vite). Fiables. Le choix par défaut dans le pétrole et gaz, la chimie lourde et la grande manufacture discrète.
À choisir si : tu as un parc SPS et historian installé de longue date, l’IT usine sait le piloter, et tu n’essaies pas d’ajouter de la supervision caméra ou du cloud analytics dans l’urgence.
2. Stacks open source modernes
Node-RED + InfluxDB + Grafana, souvent avec Mosquitto pour le broker MQTT. United Manufacturing Hub pour un bundle open source plus opinioné. HiveMQ pour du MQTT industriel. Le coût total de possession, c’est ton temps d’ingénierie, pas une licence. Le plafond est haut et le plancher est bas (il te faut quelqu’un capable de le faire tourner).
À choisir si : tu as une équipe interne à l’aise avec l’auto-hébergement, tu veux éviter le verrouillage éditeur, et tu acceptes de payer en heures d’ingénieur plutôt qu’en dollars de licence.
3. Plateformes commerciales cloud-native
Tulip, Litmus Edge, HighByte, Cognite, Element, Cumulocity, AVEVA Data Hub. Le pitch est le même chez la plupart : TCO plus bas que les middlewares historiques, premier tableau de bord plus rapide, livraison cloud native, narratif IT acceptable pour les achats. La tarification est par device ou par flux de données et monte plus vite que ce que les éditeurs annoncent. L’UX et les intégrations IA varient énormément d’un éditeur à l’autre.
À choisir si : tu veux un outil moderne, tu ne veux pas auto-héberger, tu as un budget pour des frais récurrents par device, et tu as une liste claire de sources de données à connecter dans les douze mois.
4. Systèmes caméra et IA d’abord
Une catégorie plus récente. Des outils qui traitent la caméra comme une source de données de premier rang, pas comme un ajout tardif. La caméra alimente des modèles de vision qui comptent les pièces, classent les défauts et détectent les anomalies procédé, et les événements produits remontent dans le même pipeline que la donnée SPS. Enao Vision se range ici. Parmi les autres entrants : Augmentir, MakinaRocks, et plusieurs plug-ins de vision MES spécialisés.
À choisir si : ton goulot est la visibilité sur ce que la ligne fait vraiment (et pas seulement sur ce que la SPS pense qu’elle fait), et tu veux un outil qui traite donnée caméra et donnée SPS à parité.
5. Intégrations maison
Beaucoup d’usines tournent sur des scripts Python qui attaquent un client OPC UA, déversent des CSV sur un partage réseau, avec quelques rapports Power BI par-dessus. Ce n’est pas une catégorie d’outils, c’est l’absence d’outil, mais elle mérite d’être nommée parce qu’à petite échelle ça fonctionne. Ça s’arrête le jour où le script casse à 2 heures du matin et que personne ne sait le réparer.
À choisir si : tu as une ou deux lignes, un ingénieur qui maintient les scripts, et zéro budget. Passe à l’une des catégories 1 à 4 dès que la complexité grandit ou qu’une deuxième personne doit maintenir le système.
Où chaque catégorie se casse
Les middlewares historiques proches du SCADA se cassent sur la donnée caméra et sur la livraison cloud. Ajouter un système de vision à un serveur PI a un goût de bricolage. Sortir la donnée vers un data warehouse cloud ajoute des coûts de licence et d’ingénierie que la plupart des équipes sous-estiment.
Les stacks open source modernes se cassent sur l’humain, pas sur la technique. Elles tournent superbement quand un ingénieur précis est dans le bâtiment et s’arrêtent quand cet ingénieur part. Le coût pour que la deuxième personne apprenne la stack est presque toujours supérieur à un an de licence commerciale.
Les plateformes commerciales cloud-native se cassent sur la transparence tarifaire. Le prix affiché est rarement le prix réel, et le prix réel grimpe avec l’usage d’une manière qui n’apparaît pas dans le POC. Elles se cassent aussi sur les cas limites : le protocole SPS de longue traîne que l’éditeur ne supporte pas encore, la politique IT locale qui interdit la sortie cloud, la ligne qui tourne sur un automate de 1998 sans port Ethernet.
Les systèmes caméra et IA d’abord se cassent quand la donnée SPS existante est déjà suffisante et que la caméra ajoute du bruit sans valeur. Ils se cassent aussi quand l’éclairage et le montage à la ligne sont mauvais (le même problème que pour n’importe quel système de vision).
Les intégrations maison se cassent à la première semaine de congés de la personne qui les a écrites.
Comment choisir pour une usine donnée
Trois questions dans l’ordre. Quelles sources de données dois-tu connecter aujourd’hui, et lesquelles dans dix-huit mois ? Où la donnée doit-elle atterrir (un historian, un entrepôt cloud, un outil BI, un modèle d’IA) ? Qui maintient le système et quelle est sa tolérance à la complexité auto-hébergée ?
Une usine avec vingt machines connectées en SPS, un historian PI existant et une petite équipe IT a sans doute intérêt à étendre l’existant. Une usine avec cinq lignes, sans historian, qui veut du cloud analytics et accepte de payer par device, doit regarder la catégorie commerciale cloud-native. Une usine dont le plus gros trou de visibilité est ce qui se passe sur la ligne au-delà de ce que la SPS rapporte doit regarder les systèmes caméra et IA d’abord. Une usine avec un ingénieur et une ligne se débrouille très bien en maison jusqu’au prochain congé.
L’erreur, c’est de choisir par notoriété de marque plutôt que par la réponse à ces trois questions. La bonne réponse est rarement la même que celle de l’usine d’à côté.
Coûts en 2026
Ordres de grandeur pour une usine moyenne (10 à 30 machines connectées).
Middleware historique proche du SCADA : 100 000 à 400 000 EUR à l’achat plus 15 à 25 % de maintenance annuelle.
Open source moderne : 0 EUR de licence plus 1 à 2 équivalents temps plein ingénieurs (soit 100 000 à 200 000 EUR par an en coût complet).
Commercial cloud-native : 30 000 à 150 000 EUR par an d’abonnement selon le palier par device ou par flux de données.
Caméra et IA d’abord : 5 000 à 20 000 EUR par ligne et par an d’abonnement, plus un coût d’installation de 1 000 à 5 000 EUR par ligne pour le matériel qui fait tourner la caméra.
Maison : le temps d’un ingénieur et le risque d’arrêt critique quand il s’en va.
Ces fourchettes sont larges parce que les chiffres réels dépendent de la négociation, du volume et des remises de fin de trimestre. À prendre comme orientation, pas comme devis.
Petit guide terrain : ce qu’il y a vraiment dans un système d’acquisition de données
Un système d’acquisition de données qui fonctionne en 2026 est une pile, pas un produit unique. Nommer les pièces aide quand tu es en face d’un éditeur et que la démo passe sous silence la moitié d’entre elles.
Au niveau capteur, les entrées sont typiquement un mélange de thermocouples et de RTD pour la température, de transducteurs de pression, de vibration, de débit, et de transducteurs courant-tension pour l’analyse de puissance. Chaque signal de capteur est conditionné (le conditionnement inclut amplification, isolation et filtrage) puis converti de l’analogique au numérique par des convertisseurs analogique-numérique. Le flux converti porte ensuite un numéro de série de la source, un horodatage et l’unité physique, et remonte vers ce qui le consomme.
Le matériel DAQ qui fait cette conversion arrive sous trois formes. Des enregistreurs et data loggers autonomes qui stockent les mesures en mémoire interne pour téléchargement ultérieur (le workflow le plus simple, encore courant sur les pompes distantes, les groupes électrogènes et les centrales HVAC). Du matériel DAQ modulaire sur un bus Ethernet ou USB qui pousse vers un hôte (la forme dominante en labo d’essai et sur les bancs R&D). Et des automates programmables qui combinent une petite pile DAQ avec la logique de commande sur le même appareil (la forme dominante sur les lignes de production).
Au-dessus du matériel, le logiciel DAQ. Il fait trois choses qui recoupent ce qu’un outil d’acquisition de données machines fait à l’échelle de l’usine. Il configure les voies (cadence d’échantillonnage, plage, filtrage). Il enregistre et stocke les données procédé (souvent vers un hôte Linux qui fait tourner aussi l’historian). Et il restitue les mesures aux opérateurs via du graphique temps réel, des tableaux de bord et des alarmes. La couche utilisateur est construite dans une palette de langages : C et C# pour les stacks historiques, Python et JavaScript pour les dashboards web modernes, plus une longue traîne d’environnements de script éditeur (LabVIEW, structured text Codesys, Beckhoff TwinCAT).
Pourquoi ce petit guide compte pour l’acheteur à l’échelle usine : les mêmes mots veulent dire des choses différentes à des échelles différentes. Un ingénieur d’essai dans un labo batterie qui dit « DAQ » pense en général à un châssis National Instruments PXI avec une pile de modules d’entrée analogique et LabVIEW au-dessus. Un responsable opérations dans une usine de packaging qui dit « acquisition de données machines » pense en général à une brique middleware qui sort la donnée de vingt SPS pour la pousser vers un tableau de bord et un modèle d’IA. Les deux ont raison, les deux utilisent les mêmes mots, et les éditeurs qui vendent aux deux segments parlent dans des termes volontairement ambigus. Quand un commercial te parle DAQ, demande-lui s’il pense à la pile capteur-vers-convertisseur ou à la couche SPS-vers-tableau-de-bord. La réponse détermine si l’outil colle.
Les équipes contrôle qualité utilisent la donnée DAQ plus agressivement que n’importe quelle autre fonction. La donnée est la preuve dans chaque CAPA, chaque audit fournisseur, chaque réclamation client qui réclame une traçabilité. Une usine qui fait le contrôle qualité sur des registres manuscrits vit dans une autre décennie qu’une usine qui le fait sur le système d’acquisition de données. Le passage de l’un à l’autre est ce que ce logiciel vend vraiment, même quand il est vendu sous l’étiquette productivité ou visibilité.
FAQ
MQTT est-il la même chose qu’un outil d’acquisition de données machines ?
Non. MQTT est un protocole de transport. Un outil d’acquisition de données machines utilise typiquement MQTT (ou OPC UA, ou des protocoles propriétaires) comme l’une de ses couches de transport. Outils et protocoles sont deux choses différentes.
Faut-il un historian ET un outil d’acquisition de données machines ?
Dans une petite usine, non. Dans une grande usine avec de la donnée SPS à haute cadence, oui. L’historian est optimisé pour le stockage et la restitution time-series à haute fréquence. L’outil d’acquisition est optimisé pour acheminer la donnée vers lui et vers d’autres consommateurs.
Qu’est-ce qu’OPC UA et m’en faut-il ?
OPC UA est le standard ouvert moderne pour l’échange de données machine à machine. La plupart des outils d’acquisition le parlent. Il te le faut si tes machines le supportent (la majorité des SPS modernes le font). Pour les machines plus anciennes, on retombe sur les protocoles propriétaires de la marque.
Comment ça s’articule avec notre MES ou ERP ?
L’outil d’acquisition alimente le MES en donnée machine temps réel. Le MES alimente l’ERP en données de production agrégées. L’outil d’acquisition est en amont des deux.
Commence là où est le trou de visibilité
Le bon outil dépend du trou. Si le trou est sur les tableaux de bord à partir de la donnée SPS, vise commercial cloud-native ou open source. Si le trou est sur le reporting d’entreprise pour un grand parc de machines, reste sur la stack historique et étends-la. Si le trou est de savoir ce que la ligne fait vraiment au-delà de ce que la SPS rapporte, commence par la catégorie caméra et IA d’abord et règle le reste plus tard.
Pour un regard plus approfondi sur ce qu’apporte la supervision par caméra, voir supervision de production par caméra. Pour comment ça s’insère dans un programme de visibilité plus large, voir système de supervision de production.
Commence gratuitement ou rejoins la communauté pour comparer les stacks d’acquisition de données avec des pairs d’autres usines.
