---
title: "Développement logiciel & développement physique, un PLM à 2 vitesses?"
categories: 
  - "plm"
draft: true
---

Je suis ingénieur en électronique de formation. Très orienté numérique plus qu'analogique dans ma formation j'ai appris à faire des cartes et du logiciel en parallèle, puis on a appris à faire des systèmes. Dans ma première expérience en ingénierie Process dans le monde de l’électronique, j'étais assez protégé de cette cohabitation. En faisant des bases de temps thermostatés, pas de logiciel ! pas de mises à jour! pas trop de problème ! Par la suite, dans l'industrie de la défense sur des systèmes plus complexes et enfin dans les discussions avec mes clients PLM, j'ai pu mieux comprendre la confrontation/collaboration de ces deux mondes.

## Des vitesses intrinsèques différentes

La principale différence entre le temps qui s'écoule de la conception à la livraison pour un logiciel ou pour un produit physique, se base sur la problèmatique de fabrication. On raccourci les temps maintenant quand on peut faire de l'impression 3D "assez" rapide. Mais on n'atteindra pas une bonne intégration continue qui sur un commit de code, compile votre application, la test automatiquement, et la déploie.

## Des capacités de collaboration plus importantes

Je suis preneur de tout projet de mécanique ou d'une carte électronique ou vous pouvez avoir des centaines de contributeurs. C'est assez rare et pourtant dans le logiciel c'est monnaie courante. Prenez l'exemple de la librairie Open-source Lodash (librarie javascript qui permet de manipuler des objets et des tableaux).

https://github.com/lodash/lodash

- 222 contributeurs
- 372 releases
- 5 branches
- 7569 commits

La première chose que l'on peut comparer c'est la vitesse de mise à jour.

## Une démarche logicielle bien outillée

## Des réticences à mélanger les deux?
