Blog Peut-on utiliser Git ou SVN pour des fichiers CAO ? Ce qui fonctionne, les limites et quand passer au PDM
Peut-on utiliser Git ou SVN pour des fichiers CAO ? Ce qui fonctionne, les limites et quand passer au PDM
Git et SVN peuvent conserver les révisions de fichiers CAO, mais ils ne comprennent pas automatiquement la géométrie, les assemblages, les références ni les processus de validation et de publication. Ce guide explique quand un outil généraliste suffit et quand un PDM conçu pour la CAO devient plus pratique.
Réponse courte : Oui, Git ou SVN peuvent versionner des fichiers CAO, mais dans certaines limites. Git LFS facilite le stockage des gros fichiers binaires, tandis que SVN propose un modèle centralisé et le verrouillage. Aucun des deux ne comprend nativement la géométrie CAO, les assemblages, les plans, les références, les validations ou la revue fournisseur. Quand la collaboration et la complexité augmentent, un PDM adapté à la CAO devient généralement plus pratique.
Les équipes d’ingénierie posent souvent une question légitime : peut-on utiliser Git ou SVN pour gérer des fichiers CAO au lieu de déployer un système PDM ?
Git et Apache Subversion peuvent conserver l’historique, indiquer qui a modifié un fichier, associer des commentaires aux changements et restaurer une version antérieure. Mais les fichiers CAO mécaniques natifs ne sont pas du code source. Ils sont souvent binaires, contiennent des relations complexes entre pièces, assemblages et plans, et ne peuvent généralement pas être fusionnés comme du texte.
La distinction la plus utile est la suivante :
Git ou SVN comme archive contrôlée des versions validées : souvent pertinent pour des instantanés approuvés, surtout si l’équipe maîtrise déjà le contrôle de version.
Git ou SVN comme système quotidien de collaboration CAO : possible dans des processus limités, mais de plus en plus difficile avec la taille des assemblages, le nombre de contributeurs, les fournisseurs et les validations.
Pourquoi les équipes envisagent Git ou SVN
Ces outils sont intéressants parce que beaucoup d’équipes les utilisent déjà, savent les administrer ou peuvent les déployer à faible coût.
Un dépôt peut fournir :
Un historique des versions validées
L’identité des utilisateurs et les horodatages
Des messages de commit servant de journal des changements
Des tags ou branches pour les releases et variantes
La restauration d’un fichier antérieur
Un accès centralisé ou distant
L’auto-hébergement
Des permissions d’accès
Un processus réduisant les écrasements accidentels
Ces fonctions répondent à des questions courantes : quel fichier est à jour ? Qui a modifié le modèle ? Peut-on restaurer l’état précédent ? Comment préserver une release approuvée ?
Dans la discussion Reddit « I’m thinking of using Git to manage CAD drawings with a revision change log », l’objectif est de conserver les révisions et un journal des changements, ainsi que des PDF, STEP et images. Ce cas est réaliste si le dépôt sert d’archive contrôlée, plutôt que d’environnement principal de collaboration quotidienne.
La distribution des versions entre utilisateurs et organisations
Le contrôle de version CAO n’est donc pas qu’un problème de stockage : il implique aussi la traçabilité, les dépendances, la collaboration, les accès et l’interprétation des changements techniques.
Quand Git ou SVN peuvent convenir à la CAO
Ils peuvent suffire lorsque la plupart de ces conditions sont réunies :
Une personne contrôle l’essentiel des modifications.
L’équipe est petite et techniquement expérimentée.
Les fichiers sont indépendants ou ont des références simples et stables.
Le dépôt sert surtout à archiver des versions validées.
Deux personnes modifient rarement le même fichier en parallèle.
La comparaison visuelle est réalisée manuellement dans l’application CAO.
Les validations sont gérées en dehors du dépôt.
Les fournisseurs n’ont pas besoin d’un accès contrôlé dans le navigateur.
L’équipe peut maintenir des règles strictes de nommage, tags et verrouillage.
La charge d’un PDM formel dépasserait le besoin actuel.
Un lot de version validée pourrait par exemple contenir :
Contenu de la version validée
Exemple
Objectif
Assemblage natif
gearbox-assembly.SLDASM
Conserver l’assemblage modifiable
Pièces natives
gearbox-housing.SLDPRT, gearbox-shaft.SLDPRT
Conserver les composants référencés
Plan validé
gearbox-drawing.pdf
Fournir un plan approuvé et accessible
Export CAO neutre
gearbox-export.step
Faciliter fabrication et interopérabilité
Journal des changements
CHANGELOG.md
Expliquer ce qui a changé et pourquoi
Le commit ou le tag identifie la révision approuvée et les fichiers correspondants. La difficulté commence lorsque le dépôt doit aussi coordonner le travail actif de plusieurs personnes sur des fichiers interdépendants.
Pourquoi les fichiers CAO diffèrent du code source
Ils sont souvent binaires
Git excelle avec le texte, où il peut afficher précisément les lignes modifiées :
- hole_diameter = 10
+ hole_diameter = 12
Pour un fichier CAO natif, il peut seulement indiquer :
Binary file changed
Git peut utiliser des attributs et outils de conversion externes, mais il ne comprend pas lui-même la géométrie. Il ne peut pas expliquer automatiquement si un diamètre a changé, si une fonction a été supprimée, si un composant a bougé ou si une référence a été remplacée.
Les modifications CAO ne se fusionnent généralement pas comme du code
Deux développeurs peuvent modifier des lignes différentes et fusionner leurs changements. Deux versions binaires d’une même pièce CAO doivent généralement être départagées ou réconciliées manuellement. C’est pourquoi un processus d’extraction, de réintégration et de verrouillage est souvent plus utile qu’une fusion parallèle.
L’archivage/extraction empêche plusieurs personnes de créer des versions incompatibles d’un fichier CAO non fusionnable.
La gestion des nomenclatures ou des modifications techniques
Une expérience pensée pour les utilisateurs non techniques
📌
Git LFS facilite le stockage des fichiers CAO volumineux, mais ne permet pas à Git d’en comprendre la structure ni les dépendances.
SVN est-il meilleur que Git pour la CAO ?
SVN peut être plus naturel pour certains workflows traditionnels grâce à son modèle centralisé et au verrouillage explicite.
Apache Subversion permet d’imposer un verrou avant modification, applique les commits de façon atomique, associe un message à la révision complète et utilise la différenciation binaire pour les transferts et le stockage.
SVN peut être intéressant lorsque :
L’équipe veut une source de vérité centrale.
Les fichiers ne sont pas fusionnables.
Une seule personne doit modifier un fichier à la fois.
L’équipe préfère checkout/commit aux branches et fusions.
Le dépôt contient beaucoup de binaires.
L’organisation dispose déjà d’une infrastructure SVN.
Cependant, SVN reste généraliste. Il peut mieux convenir au versionnage binaire centralisé et au verrouillage, mais ce n’est pas un PDM adapté à la CAO.
Git vs Git LFS vs SVN vs stockage cloud vs PDM
Capacité
Git
Git LFS
SVN
Stockage cloud
PDM adapté à la CAO
Historique des versions
Oui
Oui
Oui
Généralement
Oui
Restaurer une version
Oui
Oui
Oui
Généralement
Oui
Notes de changement
Commits
Commits
Journaux
Limitées
Généralement
Gros binaires
Limité
Meilleur
Bon
Bon
Variable
Verrouillage
Selon le workflow
Configurations compatibles
Intégré
Limité
Généralement
Diff/fusion texte
Fort
Fort pour le texte
Pris en charge
Non
Pas l’objectif principal
Fusion CAO native
Non
Non
Non
Non
Généralement limitée
Comparaison géométrique
Non par défaut
Non par défaut
Non par défaut
Non
Variable
Connaissance des références
Non
Non
Non
Non
Variable
Visualisation CAO web
Non
Non
Non
Généralement non
Variable
Validation/release
Manuelle
Manuelle
Manuelle
Limitée
Variable
Revue fournisseur
Accès dépôt
Accès dépôt
Accès dépôt
Liens partagés
Contrôlée ; selon le produit
Facilité pour non-techniciens
Faible
Faible
Moyenne
Élevée
Généralement supérieure
Auto-hébergement
Oui
Oui
Oui
Variable
Variable
Les fonctions disponibles varient d’un PDM à l’autre, notamment pour les formats, les relations entre fichiers, les nomenclatures et les validations.
Trois scénarios pratiques
Git LFS suit un workflow distribué de commit et push, SVN privilégie le verrouillage centralisé, et un PDM ajoute extraction, revue et release.
1. Un concepteur archive des révisions validées
Git LFS ou SVN peuvent suffire. Le dépôt conserve le package approuvé — fichiers natifs, PDF, STEP et données de fabrication — avec un tag de révision et une sauvegarde externe. Il sert d’archive contrôlée, pas de plateforme de collaboration en temps réel.
2. Une petite équipe technique travaille sur des fichiers simples
Git LFS ou SVN restent possibles avec des règles strictes :
Verrouiller les fichiers non fusionnables avant modification.
Éviter les modifications simultanées.
Attribuer la responsabilité des assemblages et pièces.
Définir les règles de nommage, dossiers et release.
Valider ensemble les fichiers liés.
Vérifier les références avant release.
Éviter les déplacements et renommages non contrôlés.
Former toute l’équipe au processus.
Prenons une équipe de quatre personnes travaillant dans SOLIDWORKS sur un assemblage de 350 pièces. Si deux personnes modifient le même carter à partir d’une révision commune, Git LFS peut conserver les deux fichiers binaires, mais il ne peut pas réunir une modification du perçage et un changement d’épaisseur de paroi, ni indiquer quels plans doivent être mis à jour. Le coût logiciel peut rester faible, mais l’équipe le compense par davantage de discipline, de formation et de coordination manuelle.
3. Une équipe multi-CAO collabore avec des fournisseurs
Un PDM devient plus approprié lorsque plusieurs personnes travaillent sur des fichiers interdépendants, que les assemblages comportent de nombreuses références, que l’équipe exige une collaboration fournisseur contrôlée et que des utilisateurs sans CAO doivent participer aux revues dans le navigateur.
Comment décider si Git ou SVN suffisent encore
Git ou SVN peuvent suffire si :
Vous archivez surtout des versions validées.
La structure CAO est simple.
Une personne contrôle la majorité des changements.
Toute l’équipe maîtrise le contrôle de version.
Vous n’avez pas besoin de revue CAO dans le navigateur.
Vous n’avez pas besoin de comparaison géométrique.
Les validations sont gérées ailleurs.
Les fournisseurs n’ont pas besoin d’accès direct contrôlé.
Vous acceptez de gérer manuellement les relations.
Envisagez un PDM si :
Les écrasements sont fréquents.
Les assemblages contiennent de nombreux fichiers liés.
Vous avez besoin de revue visuelle ou d’annotations.
Les données validées doivent être séparées du travail en cours.
La traçabilité et l’historique des validations sont importants.
Les opérations du dépôt freinent les utilisateurs non techniques.
Où se situe CAD ROOMS
CAD ROOMS réunit historique des versions CAO, états, revue 3D et collaboration d’ingénierie dans un espace PDM cloud.
CAD ROOMS devient pertinent lorsqu’une équipe a dépassé les dossiers partagés, feuilles de calcul, services de stockage cloud génériques, Git ou SVN, sans vouloir la lourdeur d’un PDM traditionnel sur site. Un workflow PDM structuré pour les révisions, validations et releases peut remplacer de nombreux contrôles manuels.
Pour une équipe qui ne gère que quelques fichiers indépendants, Git LFS ou SVN peuvent encore suffire. Dès que les assemblages, les revues fournisseurs et les publications formelles se multiplient, les fonctions PDM les plus utiles sont :
Historique des versions CAO
Archivage/extraction
Édition locale via l’application de bureau
Gestion multi-CAO
Revue de conception dans le navigateur
Commentaires et partage contrôlé
Relations entre fichiers
Rôles et permissions
Historique d’audit
Collaboration avec fournisseurs et réviseurs externes
Git ou SVN peuvent rester préférables pour le code source, les fichiers de conception textuels ou les archives personnelles simples. Le PDM devient plus pertinent lorsque la question n’est plus « comment stocker des versions ? », mais « comment coordonner données, personnes, références, revues, permissions et releases ? »
Conclusion : peut-on utiliser Git ou SVN pour la CAO ?
Oui. Git et SVN peuvent gérer les fichiers CAO au niveau du versionnage. Git LFS améliore le traitement des gros binaires ; le modèle centralisé et le verrouillage de SVN peuvent mieux convenir à certains workflows.
Mais aucun ne comprend automatiquement la géométrie, les dépendances d’assemblage, les plans, les états de release, les revues fournisseur ou les validations.
Utilisez Git ou SVN si vous avez surtout besoin d’un historique technique et pouvez gérer le processus d’ingénierie manuellement.
Utilisez un PDM si le système doit prendre en charge le processus autour des fichiers.
Questions fréquentes
Git peut-il gérer les fichiers SOLIDWORKS ?
Oui. Git peut stocker les fichiers .SLDPRT, .SLDASM et .SLDDRW, et Git LFS facilite les gros volumes. Il ne comprend pas les assemblages, références, fonctions ou changements géométriques. Voir le partage de fichiers SOLIDWORKS avec des fournisseurs.
Git LFS peut-il stocker des fichiers CAO ?
Oui. Il stocke le contenu binaire hors de la base d’objets Git tout en conservant des pointeurs texte. Il améliore le stockage, pas le workflow CAO.
SVN est-il meilleur que Git pour la CAO ?
Il peut être plus simple pour une équipe privilégiant un dépôt central et un verrou avant modification. Il reste toutefois généraliste.
Deux ingénieurs peuvent-ils fusionner leurs changements CAO ?
Généralement pas comme du code. Deux modèles binaires modifiés séparément nécessitent habituellement une réconciliation manuelle dans l’application CAO.
Git peut-il suivre les assemblages et références CAO ?
Git suit des fichiers et des chemins, mais ne sait pas qu’un fichier est un assemblage et un autre son composant ou son plan. Les systèmes adaptés à la CAO exposent ces relations dans le visualiseur.
Git convient-il au contrôle des révisions CAO ?
Oui pour un concepteur seul, une petite équipe technique, des projets simples ou des archives de versions validées. Il devient plus difficile à gérer avec les assemblages, utilisateurs, validations et partenaires externes.
Peut-on utiliser Git uniquement pour des instantanés CAO approuvés ?
Oui. C’est l’un des cas les plus pratiques : valider un package complet, ajouter un tag et conserver fichiers natifs, formats neutres, plans et journal des changements.
Quand faut-il passer de Git ou SVN à un PDM ?
Lorsque la coordination manuelle, la formation, les références cassées, les accès, les releases ou la collaboration fournisseur consomment trop de temps ou augmentent le risque.
Quelle différence entre Git et un PDM ?
Git suit principalement le contenu et l’historique d’un dépôt. Un PDM gère les données d’ingénierie et leur contexte : relations, verrouillage, permissions, revue, release et audit.
Un PDM est-il toujours nécessaire pour la CAO ?
Non. Une personne seule ou une petite équipe avec des fichiers simples peut ne pas en avoir besoin. Tout dépend de la complexité, des dépendances, de la conformité et de la fiabilité du processus manuel.
CAD ROOMS est-il une alternative à Git ou SVN pour la CAO ?
Oui, pour les équipes qui ont besoin de plus qu’un historique de fichiers. Le contrôle de version dans CAD ROOMS combine archivage/extraction, historique, relations, revue web, permissions et collaboration externe.
Guide pratique de la gestion des données d'ingénierie pour les équipes CAO, et pourquoi le PDM cloud est la façon moderne de contrôler fichiers, révisions et validations.
Un guide neutre pour choisir une alternative à Onshape en PDM pour les équipes multi-CAO, et comment une couche de PDM cloud neutre gère les données CAO mixtes et le partage avec les fournisseurs.