L'IA s'attaque aux automates programmables. Des assistants d'ingénierie qui lisent les projets et écrivent du code

Évolution : des chats aux agents intégrés

Les programmeurs en Python, C++ et JavaScript sont habitués aux assistants IA. Pour les automates programmables, la situation était différente. Il y a trois ans, les premières expérimentations semblaient prometteuses mais restaient pratiquement inutilisables : ChatGPT pouvait générer un régulateur PID en ST ou un bloc de transmission TCP en TwinCAT, mais il fallait vérifier le résultat avec méfiance. Le contexte manquait, les exemples d'entraînement étaient rares, et la complexité d'intégration dans un projet existant considérable.

Aujourd'hui, l'approche a changé. Au lieu de modèles généralistes, des outils spécialisés apparaissent, capables de comprendre l'architecture des projets, intégrant la documentation des plateformes et pouvant lire la structure d'un programme directement depuis l'IDE. La bascule de l'assistant à l'agent est concrète : on ne se contente plus de suggestions, on exécute une chaîne d'actions — lire le projet, apporter une modification, compiler, corriger les erreurs détectées.

Cinq outils, cinq approches différentes

PLC Copilot — le premier outil de cette catégorie à avoir reçu des fonctionnalités avancées. Il prend en charge Rockwell Studio 5000, Siemens TIA Portal et AutomationDirect Productivity Suite (CODESYS figure sur la liste d'attente). Il peut expliquer la logique, rechercher les liens entre les tags, préparer de la documentation et générer du code à importer. Tarifs : Pro 99 $/mois, Ultra 499 $/mois, licence perpétuelle à 720 $ par appareil (support à 270 $/an).

Copia AI/Copilot — se distingue par sa source de contexte. Il travaille à partir des projets issus de Copia Source Control et des sauvegardes DeviceLink. Cela permet de comparer les versions et les modifications, de générer des fragments de code et de convertir entre LAD et ST. Le tarif n'est pas public ; il faut s'adresser aux équipes commerciales de Copia.

L'assistant Structured Text (sans nom de marque précisé dans le texte) — met l'accent sur une connexion locale à l'IDE. Un pont Python pour CODESYS et une application dédiée pour TwinCAT lisent la structure, appliquent les modifications et transmettent les résultats de compilation à l'agent dans le cloud. CODESYS V3.5 SP18+ et TwinCAT 3.1+ sont pris en charge (TIA Portal arrive bientôt). L'outil affiche les modifications et corrige les erreurs à partir des diagnostics du compilateur. Tarifs : Pro 24 €/mois, Power 49 €/mois, version d'essai gratuite.

L'Eigen Engineering Agent de Siemens — un agent intégré à TIA Portal V19, V20 et V21. Il peut générer du code pour automates, créer des IHM, configurer des équipements. L'outil revendique la lecture de schémas électriques en XML et AML, ainsi que la génération de la structure d'un projet à partir d'une description de machine. L'intégration directe à l'IDE constitue un avantage en termes d'intégration, mais le prix reste élevé : 2100 $/an pour une seule licence (attribuable à trois utilisateurs, mais un seul peut l'utiliser à la fois). La période d'essai est d'un mois.

Le TwinCAT 3 CoAgent for Engineering de Beckhoff — présenté comme un assistant pour le développement d'automates, la configuration des E/S et des IHM. L'outil promet des suggestions tenant compte de la structure du projet et un accès au Beckhoff Information System. Son statut est « bientôt disponible » ; les délais restent à confirmer auprès du fabricant.

D'autres solutions

Ces cinq outils ne sont pas les seuls. Sont actuellement en développement : • Factory Agent, de Software Defined Automation • FactoryTalk Design Studio Copilot, de Rockwell Automation

Tous proposent un ensemble de fonctionnalités similaire : analyse de la logique, documentation, aide à l'écriture de code. Les fonctionnalités réellement disponibles dépendent du produit et de l'environnement pris en charge.

Architecture : quatre composants

La réponse apportée par un outil d'IA ne se définit pas par l'interface (« projet — champ de requête — réponse »), mais par ce qui se passe en coulisses. L'architecture comprend quatre parties :

1. Lecture du projet : extraction des blocs, des réseaux, des variables, des types, des appels, de la configuration. Pour un texte en ST, la tâche est une chose ; pour un LAD ou un FBD graphique, c'en est une autre.

2. Sélection du contexte : recherche du bloc lié, du programme appelant, des types de données, de la documentation de bibliothèque. Transmettre simplement plus de texte au modèle n'est pas toujours la meilleure méthode. On utilise ici un graphe de dépendances ainsi qu'une approche RAG (Retrieval-Augmented Generation) : le modèle reçoit la question accompagnée des documents trouvés.

3. Transformation de la réponse : conversion du résultat en une modification de l'objet d'ingénierie ou en un fichier d'importation, en conservant la structure du projet.

4. Boucle de rétroaction : compilation, diagnostic, correction des erreurs. Une construction réussie ne confirme que la syntaxe ; la logique de fonctionnement du nouveau bloc doit être vérifiée séparément.

La valeur pratique d'un outil dépend de la qualité de mise en œuvre de ces quatre étapes, et non du volume des annonces marketing.