IA et programmation d'automates : ce que permet TIA Portal

En bref : dans TIA Portal, l'IA sait aujourd'hui générer des blocs en SCL et en LOG, les compiler, les vérifier par rapport à une analyse fonctionnelle, les tester en simulation et tenir la documentation à jour. Elle ne devient fiable qu'au sein d'un déroulement fixe : une analyse fonctionnelle convenue avec le donneur d'ordre au départ, un test en simulation à l'arrivée. Les parties de programme liées à la sécurité sont écrites par l'ingénieur lui-même, et le chargement dans une CPU réelle est toujours fait par une personne.

Cet article s'adresse aux acheteurs, chefs de projet et responsables maintenance qui doivent décider s'ils confient un projet d'automatisme à un prestataire travaillant avec l'IA. Il décrit comment notre bureau d'ingénierie utilise des agents IA, où nous fixons des limites claires, ce qui se cache derrière les objections les plus fréquentes et en quoi cette approche diffère de l'Eigen Engineering Agent de Siemens.

1.Fenêtre de chat ou chaîne d'outils : deux façons d'utiliser l'IA

Quand on parle d'IA et d'automates, on pense d'abord à ChatGPT ou à un outil similaire : on décrit une tâche, on récupère du code SCL et on le colle dans le projet. Pour une petite fonction isolée, cela peut suffire. Pour le programme d'une installation, non. Le modèle ne connaît pas le projet, ne compile rien et ne teste rien. Vérifier que le code respecte les types de données, les interfaces de blocs et les conventions de nommage existants reste un travail manuel.

La seconde approche repose sur des agents IA qui travaillent directement dans l'outil d'ingénierie, au lieu de fournir du code depuis une fenêtre de chat. Ils connaissent la structure du projet, reçoivent les retours du compilateur et peuvent y réagir. Ils travaillent dans le projet, pas à côté. C'est cette différence qui fait de l'IA un véritable outil d'ingénierie plutôt qu'une curiosité.

2.Comment nous utilisons des agents IA dans TIA Portal

Chez nous, des agents IA travaillent directement dans TIA Portal. Chaque projet suit le même déroulement :

1. L'analyse fonctionnelle d'abord. Avant la première ligne de code, une analyse fonctionnelle (FDS) est établie et convenue avec vous. C'est la référence pour tout ce qui suit.
2. Générer et compiler les blocs. Les agents écrivent du SCL pour les calculs et le traitement de données, du LOG pour la logique de combinaison, puis compilent le projet. Si le compilateur signale des erreurs, le bloc repart en reprise.
3. Revue par rapport à l'analyse fonctionnelle. Chaque bloc est confronté à la FDS : chaque fonction décrite est-elle réalisée, et le code fait-il quelque chose que la FDS ne demande pas ?
4. Test fonctionnel en simulation. Le programme tourne sur un automate simulé. Les tests peuvent être rejoués après chaque modification.
5. Test de la conduite. La conduite de l'installation depuis la supervision est vérifiée face à l'automate simulé, comme le fera plus tard l'opérateur : appuyer sur un bouton, acquitter une alarme, modifier une consigne, vérifier la réaction.

La supervision elle-même découle de la structure de l'automate. Vues, alarmes et variables WinCC Unified sont générées à partir des blocs et des types de données, de même que la migration de projets Comfort Panel existants vers Unified. Plus de détails sur la page IHM et visualisation avec WinCC Unified. La façon dont nous structurons et livrons les programmes est décrite sous programmation API dans TIA Portal, les essais avant mise en service sous mise en service et tests de bout en bout.

Un exemple de travail préparatoire qui peut sinon mobiliser plusieurs jours : à partir d'un schéma électrique en PDF, les agents établissent la liste des E/S puis la table des variables API pour TIA Portal. Nous l'avons mesuré sur un dossier de 51 pages, traité en onze minutes environ. Le résultat est ensuite tout de même contrôlé par rapport aux plans.

3.Installations existantes : redocumenter un programme sans mnémoniques

Le gain le plus important ne se trouve souvent pas dans les installations neuves, mais dans l'existant. Beaucoup d'automates S7-300 tournent depuis des décennies avec un programme dont il ne reste qu'une sauvegarde récupérée en ligne : du code LIST sans mnémoniques ni commentaires, des mémentos et des blocs de données réduits à des adresses brutes. Avant de moderniser une telle installation, il faut comprendre ce qu'elle fait.

Pour cette analyse de l'existant, les agents lisent le code bloc par bloc, suivent les signaux d'un bloc à l'autre et en déduisent une analyse fonctionnelle. C'est là que s'applique notre règle la plus stricte, l'obligation de preuve : chaque affirmation sur l'installation doit renvoyer à un endroit précis du code ou de la documentation. Ce qui ne peut pas être prouvé figure dans le document comme question ouverte et se clarifie sur site ou avec l'exploitant. Le modèle ne comble pas les lacunes avec des hypothèses plausibles.

Le nouveau programme est ensuite construit à partir de cette analyse, de préférence en LOG et en CONT pour les migrations, afin que la maintenance voie en mode en ligne quelle condition manque. C'est la démarche que nous suivons pour le retrofit d'automates S5 et S7-300 comme pour la migration de CODESYS vers TIA Portal. Ce que doit contenir une documentation d'installation utile est expliqué dans notre article sur la documentation API.

4.Garde-fous : ce que l'IA n'a pas le droit de faire

Une erreur dans un programme d'automate n'est pas un simple défaut esthétique. Un participant du forum r/PLC l'a résumé ainsi : « In our industry, a 99% success rate is a catastrophic failure. » Autrement dit, dans notre métier, 99 % de réussite équivaut à un échec complet. Mon expérience de mise en service me le confirme. C'est pourquoi cinq règles s'appliquent chez nous, sans exception :

• Pas de programmation sans analyse fonctionnelle. Sans FDS convenue, il n'existe aucune référence pour contrôler un résultat.
• Tout est testé en simulation. Aucun bloc n'est livré sans avoir été testé en simulation.
• La sécurité reste l'affaire de l'ingénieur. Les parties de programme liées à la sécurité sont programmées par l'ingénieur lui-même et validées de manière classique.
• Le chargement dans la CPU réelle est fait par une personne. Charger un programme sur l'installation est toujours un acte délibéré d'une personne, jamais d'un agent.
• Obligation de preuve sur l'existant. Ce qui n'est pas prouvé reste ouvert.

5.Pourquoi l'IA améliore la qualité, pas seulement la vitesse

Le débat sur l'IA porte le plus souvent sur le gain de temps. Pour le donneur d'ordre, un autre effet compte souvent davantage : on contrôle plus.

Davantage de tests. Dans beaucoup de projets classiques, une grande partie des essais n'a lieu qu'à la mise en service, sous pression et sur l'installation. Les tests en simulation peuvent au contraire être rejoués après chaque modification. Ce qui fonctionnait ne se dégrade pas discrètement à la modification suivante.

Un meilleur travail préparatoire. Listes d'E/S, tables de variables et textes d'alarme consomment des heures d'ingénieur qui manquent ensuite pour la logique de l'installation. Si l'agent se charge de la saisie, il reste plus de temps pour les questions qui demandent de l'expérience : que se passe-t-il en cas de rupture de fil ? Comment l'installation redémarre-t-elle après une coupure de courant ?

Une documentation conforme au programme. Analyse fonctionnelle, programme et supervision proviennent de la même source. Quand le programme évolue, la documentation est mise à jour dans la foulée, au lieu d'être reconstituée de mémoire en fin de projet.

Nous ne chiffrons volontairement pas le temps gagné sur l'ensemble d'un projet. Nous avons mesuré des étapes isolées, comme la liste d'E/S ci-dessus. L'ampleur de l'effet sur un projet complet dépend de l'installation, de la documentation disponible et de l'état du code existant.

6.Les objections des acheteurs et ce qu'elles recouvrent

Les réticences face à l'IA sont bien documentées. Pour son étude Künstliche Intelligenz 2025, la fédération allemande du numérique Bitkom a interrogé 604 entreprises. Parmi les freins cités : l'incertitude juridique (53 %), la protection des données (48 %), la crainte que les données tombent entre de mauvaises mains (39 %), le manque de traçabilité (38 %) et la qualité des résultats (36 %). Les constructeurs de machines voient les choses de la même façon : dans une enquête IA de la fédération allemande VDMA, 39 participants sur 144 citent des questions juridiques comme l'accès aux données et la responsabilité.

Ces objections sont fondées, et elles appellent des réponses concrètes :

7.Protection des données : ce que deviennent vos données de projet

Un projet TIA Portal contient le savoir-faire procédé d'une installation. Nous appliquons donc des règles fixes :

• Pas d'entraînement avec vos données. Vos données de projet ne servent pas à entraîner des modèles d'IA.
• Nos propres systèmes, pas d'outils de chat publics. Les projets sont enregistrés sur nos propres systèmes et ne sont pas copiés dans des outils de chat publics.
• Chemins des données convenus avant le démarrage. Quels documents entrent dans le traitement assisté par l'IA et lesquels en restent exclus, nous le convenons avec vous avant le début du projet.
• Anonymisation lorsque c'est possible. Noms d'entreprise, désignations de sites et autres informations identifiantes sont supprimés ou remplacés avant traitement, dans la mesure où cela ne gêne pas le travail.
• Accord de confidentialité sur demande. Si vous le souhaitez, nous signons un accord de confidentialité (NDA) avant le début du projet.

Ceci ne constitue pas un conseil juridique et ne remplace pas une analyse juridique de votre côté. Si votre service informatique ou votre délégué à la protection des données a des exigences envers les prestataires externes, c'est lors de cet échange préalable qu'elles doivent être abordées.

8.Siemens Eigen Engineering Agent : un outil, pas une prestation

Le 20 avril 2026, Siemens a rendu l'Eigen Engineering Agent disponible pour tous, en tant que successeur de l'Industrial Copilot for Engineering. Siemens le présente comme une solution d'IA pour la programmation d'automates, la visualisation IHM et la configuration des appareils (communiqué de presse). Il nécessite TIA Portal V19, V20 ou V21 ainsi qu'un Industry Organization Account (page produit). La licence prend la forme d'un abonnement SaaS annuel, un poste (« seat ») couvrant trois utilisateurs attribués (licences). Sur la boutique américaine de Siemens, un poste coûte 2 100 dollars US par an (Siemens Store).

Pour un service d'ingénierie disposant de ses propres programmeurs TIA Portal, cela peut être un outil pertinent. Il s'intègre à l'environnement habituel, vient du fabricant de l'automate et est maintenu par lui. Il faut toutefois le considérer pour ce qu'il est : un outil destiné à ceux qui programment eux-mêmes. Analyse fonctionnelle, tests, réception et responsabilité restent à la charge de l'utilisateur.

Deux points méritent réflexion :

• Le point de départ est V19. Les installations sous S5 ou STEP 7 Classic se situent en amont. Ce sont souvent justement celles dont il ne reste qu'une sauvegarde en ligne sans mnémoniques, et le programme doit être compris et reconstruit avant qu'un outil intégré à TIA Portal puisse intervenir.
• Un outil n'apporte pas de capacité. Sans programmeurs en interne, ou sans pouvoir les libérer pour un projet, il faut une prestation, pas un outil de plus.

Les deux ne s'excluent pas. Une entreprise peut utiliser l'agent pour de petites modifications en interne et confier malgré tout un projet plus important à l'extérieur.

9.Cinq questions à poser à un prestataire qui programme avec l'IA

Quelques questions suffisent pour savoir si un fournisseur utilise l'IA de manière responsable. Les réponses doivent être précises, pas rassurantes :

1. Existe-t-il une analyse fonctionnelle, convenue avec nous, avant le début de la programmation ?
2. Comment le programme est-il testé avant d'arriver sur l'installation, et quels résultats de test recevons-nous ?
3. Qui programme et valide les fonctions de sécurité ?
4. Où sont stockées nos données de projet, passent-elles par des outils de chat publics, et servent-elles à entraîner une IA ?
5. Qui charge le programme dans l'automate réel, et qui répond du résultat ?

Si les réponses restent vagues, c'est en général le déroulement fixe qui manque, celui qui rend les résultats de l'IA vérifiables. Les questions 1, 2 et 5 devraient d'ailleurs trouver réponse chez tout prestataire, y compris chez celui qui travaille sans IA.

10.Conclusion : le déroulement compte plus que le modèle

L'IA est aujourd'hui utilisable en pratique pour la programmation d'automates dans TIA Portal. Qu'elle soit utile ou qu'elle devienne un risque dépend moins du modèle que du déroulement qui l'encadre : l'analyse fonctionnelle avant le code, la simulation avant l'installation, la sécurité entre les mains de l'ingénieur et une personne qui charge le programme dans l'automate.

Prybisch Automation est un bureau d'ingénierie luxembourgeois spécialisé dans l'automatisation Siemens (TIA Portal, WinCC Unified, retrofit), avec une ingénierie assistée par IA, actif dans la Grande Région et dans toute l'Europe. Nous travaillons à un ingénieur expérimenté, épaulé par un ensemble rodé d'agents IA qui prend en charge le travail préparatoire, les tests et la documentation, tandis que les décisions et la responsabilité restent humaines.

11.Sources

• Bitkom Research : Künstliche Intelligenz 2025, enquête auprès de 604 entreprises (en allemand)
• VDMA : enquête sur l'IA, 144 participants (en allemand)
• Reddit r/PLC : fil de discussion sur la tolérance aux erreurs en automatisme, avis individuel d'un praticien, pas une étude
• Siemens : communiqué de presse sur l'Eigen Engineering Agent, page produit, licences et achat et Siemens Store (États-Unis)

Toutes les sources ont été consultées le 26 octobre 2026.

---

À propos de l'auteur : cet article a été rédigé par David Prybisch, dirigeant de Prybisch Automation. Prybisch Automation est un bureau d'ingénierie luxembourgeois spécialisé dans l'automatisation Siemens (TIA Portal, WinCC Unified, retrofit), avec une ingénierie assistée par IA, actif dans la Grande Région et dans toute l'Europe. David Prybisch programme des automates depuis plus de douze ans et travaille en milieu industriel depuis 20 ans. Le déroulement d'un retrofit Siemens est décrit dans l'article Retrofit S5 et S7-300 vers S7-1500 et WinCC Unified.