J'ai travaillé pendant des années avec des systèmes PLM — SOLIDWORKS PDM, 3DExperience, Teamcenter, le stack habituel. Depuis quelque temps, je travaille sérieusement avec Git.

Même problème fondamental : coordonner le travail de plusieurs personnes sur des fichiers partagés. Approches complètement différentes.

Le contraste est difficile à ignorer. Une équipe logicielle peut avoir cinq développeurs qui éditent le même fichier en parallèle, et leurs modifications sont fusionnées automatiquement. En ingénierie, on attend encore que le collègue libère le fichier pour pouvoir l'ouvrir.

Pourquoi cette divergence ?

Trois raisons structurelles

1. Le format. Le code est du texte. Une ligne, un caractère, une fonction — tout est lisible et comparable. Un assemblage CAO est binaire et opaque. On ne peut pas regarder deux versions et « voir » la différence sans outil spécialisé. Et même avec un outil, la différence visuelle ne dit pas quel paramètre a changé — seulement quel pixel.

2. Les dépendances. Dans un projet logiciel, les liens entre fichiers sont explicites — un import ou un include, écrits noir sur blanc. Dans un assemblage paramétrique, les dépendances sont implicites : une cote dans une pièce contraint la position d'une autre, qui contraint un congé sur une troisième. Modifier un seul paramètre peut casser dix fichiers en aval, sans que rien dans le fichier source ne le signale.

3. Le déterminisme. Compiler du code donne le même résultat aujourd'hui qu'hier. Régénérer un assemblage CAO peut produire des géométries légèrement différentes selon la version du noyau, l'ordre des opérations, ou un calcul à virgule flottante qui tombe juste de l'autre côté d'un seuil. Cela rend la fusion automatique très difficile : il n'y a pas de « bonne » réponse calculable.

Ce que le modèle logiciel donne — et que l'ingénierie n'a pas

Pas de check-out. Pas d'attente. La capacité de bifurquer son travail (créer une branche), explorer une idée, et soit la jeter soit la fusionner — sans bloquer personne pendant ce temps. La capacité de revenir en arrière précisément, ligne par ligne. La capacité de demander un avis sur un changement avant qu'il soit intégré, via une pull request.

Aucun PLM grand public ne propose ces capacités. Pas parce que les éditeurs ne le veulent pas — mais parce que les fichiers CAO ne s'y prêtent pas.

Et si on essayait de les ouvrir ?

La vraie question n'est peut-être pas quel PLM choisir. C'est : et si les assemblages paramétriques pouvaient un jour s'ouvrir comme du code ?

Lisibles. Diffables. Mergeables. Avec des dépendances explicites, des opérations reproductibles, des modifications atomiques attribuables à une personne et à un instant.

Ce n'est pas une question d'outils. C'est une question de représentation. Tant que la géométrie reste enfermée dans un format binaire propriétaire, le PLM continuera de simuler la collaboration en empêchant la collaboration simultanée. Le jour où la représentation change, tout le reste devient possible — y compris des choses qu'on n'imagine pas encore parce qu'elles n'ont jamais été essayées dans ce monde.

C'est le pari.