Les assistants IA s'attaquent aux automates programmables : ils lisent les projets, écrivent du ST et lancent eux-mêmes la compilation

La programmation des automates industriels est longtemps restée à l'écart de la vague d'assistants IA qui a déferlé sur Python, C++ et JavaScript. Cela change. Le tour d'horizon publié sur Habr constate l'apparition d'outils spécialisés : ils lisent les projets PLC, expliquent la logique à contacts en LAD, génèrent du code en Structured Text (ST) et, dans certains cas, lancent eux-mêmes la compilation. La tâche ressemble à du développement ordinaire : il y a un langage, des variables, des conditions, des temporisateurs et des blocs fonctionnels. Mais dans la pratique, tout se joue dans les détails.

En quoi un automate diffère du code classique

La norme IEC 61131-3 décrit cinq langages : LD (aussi appelé LAD), FBD, ST, SFC et IL. Seul le ST ressemble à du code textuel habituel, proche de Pascal. Les autres sont en grande partie graphiques : un schéma à contacts ou un diagramme de blocs fonctionnels se convertit mal en séquence de tokens. Pour un modèle de langage, c'est un problème de représentation des données.

Une deuxième difficulté s'ajoute. Les projets pour automates sont généralement fermés et stockés dans des formats et des environnements propriétaires (TIA Portal, Studio 5000, CODESYS et d'autres), et les exemples publics sont nettement moins nombreux qu'en développement web. Un modèle qui écrit très bien un service REST peut donc produire avec aplomb du code ST faisant appel à un bloc inexistant, ou reposant sur une sémantique de temporisateur erronée.

Troisième difficulté : le coût de l'erreur. Un bug dans une application se corrige par une nouvelle version, tandis qu'une logique défaillante sur une pompe ou un convoyeur peut arrêter une ligne ou endommager l'équipement.

Ce que savent faire les outils aujourd'hui

Un simple chat avec un modèle (« écris un algorithme de commande de pompe ») sert de point de départ. Les solutions spécialisées vont plus loin, car elles accèdent au projet lui-même. D'après la description du tour d'horizon, leurs capacités sont les suivantes :

• lecture du projet PLC : analyse de la structure, des blocs, des tags et des liens entre eux ;
• explication du LAD en langage courant, utile pour comprendre le code d'un tiers ou du code hérité ;
• génération de code ST à partir d'une description textuelle de l'algorithme ;
• lancement de la compilation dans certains outils, ce qui permet un cycle « écrire, compiler, obtenir les erreurs, corriger » sans intervention humaine ;
• limites : la qualité dépend fortement de l'environnement, du format du projet et du langage, et les langages graphiques sont moins bien pris en charge que les langages textuels.

C'est précisément la boucle fermée avec le compilateur qui semble l'étape la plus importante. Le retour de la chaîne d'outils réduit la part des erreurs de syntaxe et de typage. Une idée voisine a été explorée dans le travail de recherche LLM4PLC, où la génération de code était combinée à des étapes de vérification et de validation formelle. Les grands fabricants d'automatismes intègrent eux aussi des assistants génératifs à leurs propres environnements de développement. Siemens, avec Microsoft, a ainsi annoncé Industrial Copilot dès 2023.

Une compilation réussie ne dit toutefois rien de la justesse de la logique. Le code peut compiler et se comporter de travers : inverser la condition de démarrage, oublier un verrouillage, ne pas traiter un signal d'alarme.

Où cela mène

La direction probable : l'assistant cesse d'être un générateur de fragments et devient un acteur du processus d'ingénierie. Il lit le projet en entier, propose des corrections, compile, exécute le tout en simulation et présente le résultat à l'humain. La principale limite n'est pas la capacité à écrire du code, mais la vérification de la conformité au procédé industriel.

Les comparaisons détaillées d'outils précis se trouvent dans l'article original sur Habr. Ici, c'est le tableau d'ensemble qui compte : les automates programmables ne sont plus une zone où l'IA n'entre pas.

Comment aborder ces outils en pratique

Il est raisonnable de commencer par le ST : c'est là que les modèles sont les plus solides, et le résultat se lit plus facilement à l'œil nu. Les tâches à risque limité conviennent bien : analyse de code LAD tiers, documentation de blocs, premiers jets de fonctions types comme la commande de pompe ou les compteurs.

Tout code généré mérite d'être exécuté sur un simulateur avant la connexion au matériel, puis de passer par la relecture habituelle. Il vaut mieux écrire et vérifier à la main les arrêts d'urgence, les verrouillages et les fonctions de protection. Les projets fermés posent une question à part : avant de les confier à un assistant dans le cloud, il faut déterminer où partent les données et ce qu'autorise la politique de sécurité de l'entreprise.