Peut-on vraiment utiliser Git pour le versioning des automates ?
Dans presque tous les ateliers de fabrication, la scène se répète régulièrement. Un technicien d’astreinte intervient en urgence à deux heures du matin pour ajuster une temporisation ou forcer une condition de cycle. Le lendemain, le bureau d’études recharge un projet issu d’un poste d’ingénierie et écrase sans le savoir la modification nocturne. Sur le serveur de l’usine, les répertoires regorgent de copies aux noms approximatifs, mêlant dates, initiales et la mention « final ».
Dans le développement logiciel classique, cette situation a disparu grâce à des outils standardisés. Pourtant, dans l’industrie, le suivi du code reste une source majeure de frictions entre maintenance et bureau d’études. Beaucoup d’ingénieurs s’interrogent : peut-on enfin utiliser Git pour piloter les programmes d’un automate programmable, ou s’agit-il d’une méthode inadaptée au terrain ?
Le verrou technique des formats propriétaires
Pour comprendre cette difficulté, observons la structure interne des projets. Loin d’un script informatique ordinaire, un programme d’automate ne se résume pas à du texte brut. Des environnements comme Siemens TIA Portal, Rockwell Studio 5000 ou Schneider EcoStruxure compilent l’application dans une archive fermée.
Copia Automation – Solution de backups multimarques (© copia.io)
Ce format constitue un binaire propriétaire volumineux. Il regroupe logique de commande, configuration matérielle, réseaux de terrain, blocs de données et pupitres opérateurs. Or, Git compare des fichiers texte ligne par ligne. Face à un bloc binaire, l’outil ne peut identifier la modification d’un simple contact dans un réseau Ladder.
Toute fusion de modifications simultanées génère alors un conflit bloquant. Git ne pouvant réconcilier deux archives binaires, un fichier écrase l’autre, ce qui interdit le travail collaboratif en parallèle.
Les approches intermédiaires : export textuel et interfaces dédiées
Pour contourner ce verrou, les constructeurs ont développé des passerelles afin d’extraire la logique sous une forme lisible par un gestionnaire de sources.
Chez Siemens, l’interface TIA Portal Openness permet d’automatiser l’exportation des blocs de programme en fichiers XML. Siemens propose également la Version Control Interface (VCI). Cet outil relie directement l’arborescence du projet à un dossier local synchronisé avec un dépôt Git. Les blocs logiques y sont suivis individuellement en tant que fichiers distincts.
De son côté, Beckhoff propose une structure textuelle avec TwinCAT 3. Intégré dans Visual Studio, il sépare programmes, variables et configurations dans des fichiers XML distincts. L’utilitaire TcProjectCompare permet de visualiser les écarts et de résoudre les conflits sans altérer les identifiants internes.
Toutefois, cette méthode exige une grande rigueur. L’export et l’import successifs alourdissent les cycles de travail, et la moindre incohérence de structure bloque la compilation ou le chargement dans l’automate.
Les plateformes de gestion dédiées aux parcs industriels
Face à la complexité d’adapter des outils de développement purs, des plateformes dédiées se sont imposées. La solution historique versiondog, intégrée à la suite octoplant, domine ce marché dans les grandes usines.
Contactez nos experts pour intégrer et mettre en service vos automates programmables
Ces systèmes adoptent une vision globale axée sur la résilience opérationnelle. Le serveur dialogue directement avec les automates, les robots et les variateurs du site. À intervalles programmés, le logiciel extrait le code exécuté dans la mémoire de l’automate et le compare au projet de référence stocké sur le serveur.
En cas de modification non déclarée, le système émet une alerte immédiate. Ce fonctionnement sécurise les installations sans imposer de manipulation particulière lors des dépannages. En contrepartie, ces plateformes se focalisent sur la sauvegarde et la détection d’écarts plutôt que sur la co-conception de programmes.
La convergence DevOps : adapter Git aux langages graphiques
Pour réconcilier la rigueur de Git et les besoins des automaticiens, de nouvelles plateformes ont émergé, à l’image de Copia Automation. Cette solution conserve le moteur de Git tout en intégrant des moteurs de rendu capables d’interpréter les fichiers natifs des constructeurs.
L’atout majeur réside dans le diff graphique. Au lieu d’afficher des balises XML illisibles, l’outil présente les réseaux Ladder ou les diagrammes fonctionnels GRAFCET côte à côte. Les contacts modifiés, ajoutés ou retirés apparaissent en surbrillance de couleur.
Vous retrouvez ainsi les atouts du développement moderne : isolation des fonctions sur des branches dédiées, relecture croisée avant validation et traçabilité complète de chaque version.
Exemples d'application
Deux situations d’atelier illustrent ces approches.
D’abord, un bureau d’études de huit automaticiens concevant une ligne de conditionnement robotisée. En adoptant une solution Git dotée d’un visualiseur graphique, l’équipe a créé une branche pour l’encaissage et une autre pour la palettisation. Les automaticiens ont programmé en parallèle sans risque d’écrasement mutuel. Lors de la mise en service, le temps de regroupement des programmes a diminué de 30 heures par rapport aux méthodes classiques sur dossier partagé.
Ensuite, une usine agroalimentaire exploitant 70 automates multimarques s’est dotée d’un serveur de sauvegarde automatisée. Chaque nuit, l’ensemble des programmes est scanné pour vérifier la conformité avec la base centrale. En une année, le dispositif a tracé 12 modifications effectuées en quart de nuit sans rapport d’intervention. Ces correctifs ont été validés avant l’arrêt technique annuel, évitant des pertes de production au redémarrage.
Limites et contraintes
Déployer une vraie démarche de gestion de versions sur vos équipements impose de surmonter plusieurs contraintes.
La configuration matérielle reste délicate. Si la logique de commande se prête aux comparaisons, les bus de terrain (Profinet, EtherNet/IP) et les tables d’adresses supportent mal les fusions automatiques. Une incohérence sur un réseau d’entrées-sorties bloque le démarrage de l’installation.
Le facteur humain pèse lourdement. Lors d’un arrêt critique en pleine production, le technicien doit rétablir la machine au plus vite. Lui imposer des manipulations de branches sous la pression de la cadence s’avère irréaliste. L’outil retenu doit donc proposer un archivage immédiat sans étape superflue.
Enfin, l’aspect économique est déterminant : les plateformes industrielles complètes impliquent des licences annuelles notables, tandis qu’une solution libre exige des compétences logicielles solides en interne.
Conclusion
Peut-on utiliser Git en automatisme ? Oui, à condition d’employer des passerelles capables de décoder les formats des fabricants. Le fichier binaire restera la norme industrielle, mais les outils actuels rendent enfin accessible la traçabilité du code.
Pour démarrer, harmonisez vos règles de nommage et sécurisez vos sauvegardes d’équipe. Si vous concevez de nouvelles machines, explorez les outils Git avec visualisation graphique. Si vous exploitez un parc existant, privilégiez un système de télé-sauvegarde automatique pour fiabiliser durablement vos installations.
