Trois rêves pour une usine différente

Il y a trois choses que quiconque a jamais mis en marche une machine industrielle s'est demandé au moins une fois. Trois choses que l'on ne dit pas à voix haute car elles semblent utopiques. Cet article les aligne.

Une scène, pour commencer

Travail de nuit, atelier X. Une ligne s'arrête. Le panneau HMI affiche un code : E-1423. Le manuel se trouve dans un placard à trois bâtiments de distance. Le technicien qui connaît cette machine est en vacances. L'opérateur a deux options : appeler le service d'assistance — qui répondra peut-être le matin — ou deviner. Dans le monde industrialisé entier, des scènes comme celle-ci se répètent des centaines de fois par nuit.

Le problème n'est pas qu'il manque un manuel. Il y a trop de manuels. Le problème est que la machine sait très bien ce dont elle a besoin — le capteur de pression lui indique depuis trente secondes que quelque chose ne va pas — mais elle n'arrive pas à parler une langue que l'opérateur comprenne, et quand elle arrive à le faire, elle raconte le problème au lieu de la solution. "Pression hors plage" n'est pas une phrase utile à trois heures du matin. "Vérifiez la vanne V12 du circuit d'air, elle s'est probablement bloquée" l'est.

C'est à partir de là que nous travaillons. Pas un nouveau PLC. Pas un IHM plus esthétique. Une façon différente de penser à ce que devrait être, en 2026, le logiciel qui fait fonctionner une machine. Et trois idées fixes — appelez-les rêves — que nous essayons de maintenir ensemble.

Rêve numéro un : automatiser sans programmer

L'automatisation industrielle, telle qu'elle est faite aujourd'hui, nécessite une figure très particulière : quelqu'un qui sait programmer dans un langage — la famille IEC 61131-3, avec ses dialectes ladder, function block, structured text — qui n'est pratiquement utilisé nulle part ailleurs dans le monde du logiciel. Ceux qui connaissent ces langages sont rares, coûteux et sont presque toujours en retard de trois semaines.

Le paradoxe est que ceux qui connaissent vraiment la machine ne sont souvent pas les programmeurs. C'est le chef d'atelier, le technicien de maintenance expérimenté, l'intégrateur qui a installé vingt installations similaires. Ces personnes savent quoi la machine doit faire. Elles n'ont aucune envie d'apprendre un langage de programmation né dans les années 90 pour l'expliquer.

L'idée est de renverser la chaîne. Les développeurs logiciels écrivent des composants réutilisables — contrôle de mouvement, gestion des capteurs, séquences opérationnelles — une seule fois, dans des langages modernes et à usage général. L'intégrateur de machines ne les programme pas : il les assemble, en spécifiant à l'oral ou par écrit ce que la machine doit faire. Un modèle linguistique de grande taille — un LLM — fait office de traducteur : il prend la spécification fonctionnelle de l'intégrateur et la transforme en une configuration exécutable, en assemblant les composants déjà écrits et testés.

Ce n'est pas la fantaisie de "l'IA qui écrit le code à votre place". C'est quelque chose de plus modeste et de plus réaliste : l'IA qui lit votre spécification et choisit, parmi des composants certifiés, comment les combiner. Le code critique — celui qui déplace un axe avec un cycle de 5 millisecondes — continue d'être écrit par un être humain, dans un langage qui garantisse le déterminisme et la fiabilité. Mais ce code est écrit une fois pour toutes et réutilisé cent fois.

Rêve numéro deux : la machine qui se connaît elle-même

Aujourd'hui, les machines parlent peu, et mal. Une alarme est un code numérique. Un diagnostic est une série de LED. Un journal est un fichier binaire que seul le fabricant sait ouvrir. La connaissance du fonctionnement de cette machine, avec ces tolérances, après ces deux mille cycles, réside dans l'esprit d'une personne, ou dans un PDF quelque part.

Le deuxième rêve est que ce soit la machine qui se connaisse elle-même. Pas dans un sens mystique — mais dans un sens très concret : la documentation technique, les paramètres de processus, les cas de panne typiques, les procédures d'intervention ne se trouvent plus dans un placard ou sur un serveur documentaire séparé, mais à l'intérieur de la machine elle-même, lisibles par son propre logiciel. Et quand quelque chose ne va pas, la machine ne dit pas "erreur 1423". Elle dit "la vanne V12 est probablement grippée, vous devriez la vérifier ; entre-temps, je peux continuer en mode dégradé à 60 % de la vitesse".

La différence est entre un objet passif qui signale et un objet actif qui propose. Le premier laisse le problème à l'opérateur. Le second l'affronte avec lui.

Cela nécessite deux choses peu évidentes. Premièrement, que la connaissance de la machine – historiquement conservée dans des manuels, des schémas électriques, des dessins CAO et l'expertise des techniciens – soit formalisée et intégrée dans le système. Deuxièmement, que le système ait un interlocuteur capable de tenir une conversation : à nouveau, un LLM, utilisé ici non pas pour générer du code mais pour traduire les symptômes en actions compréhensibles, dans la langue de celui qui se trouve devant le panneau.

Une fois de plus, il n'y a pas de magie. Il s'agit d'une documentation mieux écrite, mieux indexée, et d'une interface conversationnelle au-dessus. Mais cela change tout pour ceux qui font le quart de nuit.

Rêve numéro trois : le logiciel qui fonctionne partout

Le troisième rêve est le plus technique et, paradoxalement, le plus politique. Aujourd'hui, l'automatisation industrielle est un monde d'écosystèmes fermés. Chaque grand fabricant de PLC a son propre langage, son propre environnement de développement, son propre matériel, ses propres pilotes, son propre réseau de revendeurs. Changer de fournisseur signifie tout réécrire.

L'ambition ici est de construire un système logiciel qui fonctionne sur du matériel générique — un mini-PC industriel, un contrôleur embarqué, un serveur au sous-sol — en choisissant le matériel en fonction du budget et des performances nécessaires, et non en fonction de la marque de PLC qui a remporté le contrat. Un système d'exploitation Linux en version temps réel, des cartes de communication basées sur des standards ouverts (EtherCAT pour toutes), des composants logiciels en langages modernes pour les parties déterministes et en langages plus agiles pour celles qui ne le sont pas.

La règle, et c'est là que l'utopie devient concrète : le matériel doit influencer les performances, jamais la fiabilité. La même logique, sur une machine moins puissante, doit fonctionner de manière identique — seulement plus lentement. Si le temps de cycle passe de 5 à 10 millisecondes, l'axe se déplace avec la même précision mais à moitié de la vitesse. Jamais "presque pareil". Jamais "ça fonctionne sauf dans ce cas". Même système, mêmes décisions, mêmes garanties.

C'est à ce moment-là que les ingénieurs expérimentés se mettent à rire. Ils savent très bien que le temps réel est difficile, que Linux n'est pas né comme un système temps réel, que les LLM ne fonctionnent pas sur un Raspberry Pi, que le mélange de différents langages dans la même pile a plus de pièges que les tutoriels ne le promettent. Ils ont raison. Mais la direction est celle-ci, et les briques pour la construire — les extensions temps réel du noyau Linux, les piles EtherCAT open source matures, les LLM qui commencent à fonctionner sur du matériel modeste — existent, aujourd'hui, pour la première fois tous ensemble.

Pourquoi "utopie"

Utopie est un mot honnête. Aucune de ces trois choses n'est, aujourd'hui, un produit fini. La première nécessite des LLM suffisamment fiables pour être utilisés dans un contexte de production, et nous n'en sommes qu'aux premiers pas. La seconde nécessite un énorme travail de formalisation des connaissances industrielles, qui sont aujourd'hui presque toutes informelles. La troisième nécessite de construire des alternatives ouvertes face à des écosystèmes fermés qui ont vingt ans d'avance.

Mais les trois rêves ensemble, alignés, dessinent une direction précise : une automatisation où le matériel est standard, les logiciels sont réutilisables, les connaissances sont intégrées à la machine, et la figure du programmeur PLC — aujourd'hui goulot d'étranglement d'une industrie entière — ne disparaît pas, mais se déplace là où il est vraiment nécessaire, c'est-à-dire à l'écriture des composants de base une fois pour toutes.

Dans les articles qui suivront, nous vous raconterons les pièces que nous sommes en train de construire de ce puzzle. Une par une, sans promettre que le puzzle soit complet. Il ne l'est pas. Mais le dessin commence à se dessiner.