Robotique industrielle : « Si on laisse Enact Intelligence définir les standards, on ne sera plus que des consommateurs »

# Robotique industrielle : « Si on laisse Enact Intelligence définir les standards, on ne sera plus que des consommateurs »

*En 2026, la robotique industrielle ne se résume plus à des bras mécaniques sur une ligne d'assemblage. Elle s'appuie désormais sur des couches logicielles d'orchestration, d'analyse et de décision autonome. Enact Intelligence, acteur américain spécialisé dans ce domaine, s'est imposé comme référence dans plusieurs secteurs manufacturiers européens. Un DSI d'une ETI industrielle française — qui a souhaité rester anonyme — nous explique pourquoi cette dépendance l'inquiète, et ce que son organisation fait concrètement pour ne pas y succomber.*

Pouvez-vous expliquer simplement ce qu'est Enact Intelligence et pourquoi on en parle autant en 2026 ?

Enact Intelligence, c'est une plateforme américaine qui combine ce qu'on appelle le MES — Manufacturing Execution System, soit le logiciel qui pilote et surveille la production en temps réel — avec des couches d'intelligence artificielle. L'idée, c'est de connecter les machines, de collecter leurs données, et d'automatiser certaines décisions : ajuster un réglage, détecter une anomalie, prédire une panne.

Ce qui a rendu cet acteur visible en Europe, c'est sa capacité à s'intégrer rapidement dans des environnements industriels existants. Beaucoup d'ETI — les Entreprises de Taille Intermédiaire, celles qui ont entre 250 et 5 000 salariés — ont des parcs machines hétérogènes, parfois vieux de vingt ans. Enact Intelligence a su leur parler. Et le bouche-à-oreille a fait le reste.

Le problème, c'est qu'on a importé une dépendance sans vraiment le mesurer.

Quel est concrètement le risque pour une ETI industrielle européenne qui adopte cette solution ?

Il y en a plusieurs, et ils s'empilent.

Le premier, c'est le risque de localisation des données. Quand vos machines envoient leurs données de production vers une plateforme américaine, ces données tombent sous juridiction américaine. Le Cloud Act — une loi fédérale américaine de 2018 — permet aux autorités américaines d'accéder à ces données, même si elles sont stockées en Europe. Ce n'est pas une hypothèse. C'est du droit positif.

Le deuxième risque, c'est la dépendance aux mises à jour et aux évolutions tarifaires. Quand un acteur américain détient votre couche d'orchestration robotique, il contrôle aussi votre capacité à évoluer. Si demain ils changent leur modèle de licence, ou s'ils décident de ne plus supporter certaines versions, vous êtes contraints de suivre.

Le troisième — et c'est celui qu'on sous-estime le plus — c'est la perte de compétences internes. À force de déléguer la compréhension du système à un éditeur extérieur, vos équipes techniques deviennent des opérateurs, pas des pilotes.

Côté européen, est-ce qu'il existe des alternatives crédibles ?

Oui, et c'est là où la situation évolue favorablement depuis dix-huit mois. Ce n'est pas encore au niveau de maturité commerciale d'Enact Intelligence, mais des acteurs européens commencent à proposer des briques sérieuses.

Je pense notamment à des éditeurs comme Forcam — allemand, spécialisé dans le MES industriel — ou encore Aenova côté orchestration. Ce ne sont pas encore des noms que tout DSI cite spontanément, mais leurs approches architecturales respectent mieux les exigences de souveraineté : hébergement en Europe, conformité RGPD native, et surtout une logique d'interopérabilité ouverte.

Le vrai sujet, c'est que ces alternatives européennes ont besoin qu'on leur fasse confiance maintenant, pas quand elles auront la taille d'un acteur américain. Parce qu'à ce moment-là, soit elles auront été rachetées par un fonds américain, soit elles auront perdu leur ADN ouvert.

Vous parlez de compétences internes. Quelles sont celles qu'une ETI doit absolument conserver en maison ?

C'est la question centrale, et c'est celle que la plupart des directions évitent parce qu'elle implique des décisions RH difficiles.

La première compétence à ne jamais externaliser totalement, c'est la connaissance des protocoles industriels. OPC-UA, MQTT — ce sont des standards de communication entre machines. Si personne dans votre équipe ne comprend comment vos machines parlent entre elles, vous êtes aveugles dès que l'éditeur tiers n'est plus là.

La deuxième, c'est ce que j'appelle la gouvernance de la donnée machine. Savoir quelles données sont produites, où elles vont, qui y a accès, dans quel format. Ce n'est pas de l'informatique pure, c'est de la gouvernance. Et ça doit rester dans la main d'un responsable interne — un data owner opérationnel, pas un titre symbolique.

La troisième, c'est la capacité à auditer un système qu'on n'a pas construit soi-même. Former un ou deux ingénieurs à lire des flux de données, à comprendre ce qu'une IA décide et pourquoi — c'est ce qu'on appelle l'explicabilité. Sans ça, vous signez des contrats les yeux fermés.

Ces trois compétences ne nécessitent pas une armée. Dans une ETI de taille moyenne, deux à trois personnes formées et bien positionnées dans l'organigramme suffisent à changer radicalement la posture.

Comment organiser la gouvernance autour de ces sujets ? Qui doit décider ?

C'est là que beaucoup d'organisations se plantent. On met la robotique dans le giron de la DSI — Direction des Systèmes d'Information — ou dans celui de la direction industrielle, et les deux ne se parlent pas.

Ce que je recommande, c'est de créer une instance de gouvernance transverse, légère, qui réunit le DSI, le directeur de production, et idéalement un juriste ou quelqu'un qui maîtrise les enjeux de conformité réglementaire. On l'appelle comité de souveraineté opérationnelle dans certaines organisations. Le nom importe peu. Ce qui compte, c'est que ce comité ait un droit de regard sur tout contrat qui touche aux données de production et à l'orchestration des systèmes physiques.

Ce comité doit poser trois questions simples avant tout déploiement : Où vont les données ? Qui peut les voir ? Peut-on sortir de ce système sans perdre nos données et nos historiques ? Si l'éditeur ne peut pas répondre clairement à ces trois questions, c'est un signal d'alarme.

Concrètement, comment avez-vous procédé dans votre organisation pour réduire cette dépendance ?

On a commencé par un audit de souveraineté de notre parc logiciel industriel. Pas un audit de sécurité classique — un audit de dépendance. On a cartographié chaque brique logicielle, son éditeur, sa juridiction, et le niveau de criticité si elle devenait indisponible.

On a ensuite identifié nos trois ou quatre dépendances les plus risquées. La robotique logicielle en faisait partie. On a lancé un projet pilote avec un éditeur européen sur une ligne de production non critique — pour monter en compétence sans risquer la continuité d'activité.

Et on a formé deux ingénieurs internes sur les protocoles d'interopérabilité ouverts. Pas pour remplacer un éditeur, mais pour ne plus être otages d'un seul.

Le changement culturel, c'est ça : passer de « l'éditeur gère » à « l'éditeur supporte, mais on comprend ».

Un dernier message pour un DSI d'ETI qui découvre ce sujet aujourd'hui ?

Ne confondez pas la facilité d'adoption et la sécurité stratégique. Un outil américain peut être bien fait, bien supporté, facile à déployer. Ça ne veut pas dire qu'il est sans risque pour votre autonomie à cinq ans.

La souveraineté numérique industrielle, ce n'est pas du nationalisme. C'est de la gestion de risque. C'est s'assurer que demain, si un acteur américain change ses conditions, si une loi extraterritoriale s'applique à vos données de production, ou si une tension géopolitique perturbe les flux de licences — vous avez une option de repli.

Cette option, il faut la préparer maintenant. Pas dans trois ans, quand le contrat sera renouvelé pour la troisième fois et que vos équipes auront tout oublié de ce qu'elles savaient faire sans cet outil.

*Propos recueillis par la rédaction de RiffLab Media.*