Arrêtez de choisir Excel par habitude : itérez votre hardware dans Koddex, puis publiez-le dans votre PLM

Dans un article récent publié sur Beyond PLM, Oleg Shilovitsky a donné un nom à une habitude que tout ingénieur hardware connaît : le « usualing », choisir un outil parce que c'est celui qu'on utilise d'habitude plutôt que le bon (lire son article). Son exemple est Excel pour la nomenclature, et sa question mérite d'être posée dans chaque équipe d'ingénierie : est-ce que je choisis cet outil parce que c'est le meilleur pour ce travail, ou parce que c'est ce qu'on fait toujours ?

Nous partageons ce diagnostic. Cet article regarde d'où vient cette habitude dans les équipes hardware, et la phase où elle coûte le plus cher : l'itération, ces semaines et ces mois avant qu'une conception soit assez mûre pour entrer dans le PLM.

Excel n'est pas le problème partout

Excel est un bon outil pour certains usages, et il faut le dire :

• —Une petite BOM simple, qui changera peu.
• —Une analyse ou un rapport ponctuel.
• —Une collecte rapide de données avant leur entrée dans un vrai système.

Les difficultés commencent quand le tableur devient l'endroit où le produit est conçu : quand plusieurs équipes le modifient chaque jour, quand chaque modification a des effets sur les exigences, la masse, le coût et les essais, et quand le produit devra ensuite prouver sa conformité dans l'aéronautique, le médical ou l'automobile.

Pourquoi les équipes reviennent à Excel pendant les itérations

La plupart des entreprises hardware ont un PLM, ou prévoient d'en avoir un. Alors pourquoi la BOM vit-elle dans un tableur pendant des mois ?

Parce qu'un PLM est conçu pour les données publiées. Il gère très bien ce qui a été décidé : les pièces sous contrôle, les révisions approuvées, les ordres de modification, la configuration qui part en production et chez le fournisseur. Il n'est pas conçu pour la phase où la conception change dix fois par semaine. Faire passer chaque modification précoce par un processus formel ralentit l'équipe, alors les ingénieurs itèrent ailleurs, dans l'outil qu'ils ont déjà ouvert.

Le résultat suit un schéma connu :

• —Des copies partout. « BOM_v12_final_JD.xlsx » circule par e-mail. Personne ne sait quelle version est la bonne.
• —Une personne à la fois. La conception, la certification et les achats s'attendent au lieu de travailler en parallèle.
• —Aucune vue de l'impact. Quand une pièce change, retrouver les exigences, les essais et les assemblages qu'elle touche demande des réunions et des recherches manuelles.
• —Un passage de relais douloureux. Quand la conception est enfin prête, quelqu'un ressaisit ou réimporte le tableur dans le PLM, et l'historique des décisions reste dans les fichiers.

Cette habitude n'est pas irrationnelle. Elle comble un vrai manque entre le tableau blanc et le PLM. La question est de savoir si un tableur est le bon outil pour le combler.

Ce dont l'itération a vraiment besoin

Itérer vite sur un produit hardware réglementé demande quelques éléments qu'un tableur et un PLM orienté publication n'apportent pas seuls :

1. 1.Une structure dès le premier jour. La BOM est un arbre de pièces avec leurs attributs, reliées aux exigences et aux essais, pas une liste de lignes.
2. 2.Une collaboration en direct. Plusieurs équipes modifient le même produit en même temps, et tout le monde voit les mêmes données.
3. 3.L'impact de chaque modification. Quand quelqu'un modifie une pièce, l'équipe voit immédiatement quelles exigences, quels assemblages et quels budgets de masse et de coût sont touchés.
4. 4.Des révisions peu coûteuses. Essayer une option, la comparer et revenir en arrière ne doit pas coûter un ordre de modification.
5. 5.Une sortie propre. Quand la conception est prête, l'équipe fige une baseline et la transmet au PLM avec son historique et ses liens.

Itérez dans Koddex, publiez dans votre PLM

C'est le rôle que joue Koddex à côté du PLM. Koddex est le système d'ingénierie IA du hardware réglementé : l'endroit où l'équipe conçoit et fait itérer le produit sur des données structurées et tracées. Le PLM reste le système de référence pour les données publiées. Koddex s'y connecte, ainsi qu'à votre CAO et à votre ERP, lors de l'intégration via son API (intégrations) : rien n'est saisi deux fois.

Concrètement, la phase d'itération se déroule ainsi :

1. Partez de votre tableur. Importez la BOM existante dans Koddex et donnez-lui une vraie structure : l'arbre produit, les attributs qui comptent pour vous (masse, coût, fournisseur, statut) et les liens vers les exigences. Chez notre client de référence, assembler une structure produit complexe prend 15 minutes dans Koddex, au lieu de 2 à 3 jours dans Excel.

2. Itérez ensemble et voyez l'impact de chaque modification. La conception, la certification et les achats travaillent sur les mêmes données en même temps. Quand une pièce change, Koddex montre ce qu'elle touche (analyse d'impact) : les exigences, les essais, les assemblages et les budgets qui en dépendent. Chez notre client de référence, une analyse d'impact prend un jour au lieu de deux semaines de réunions et de tableurs, et toute l'équipe la voit en direct.

3. Confiez le travail répétitif à des agents IA. Les agents travaillent comme des coéquipiers, dans vos droits : vous leur assignez une tâche, par exemple vérifier la couverture des exigences ou mettre à jour un plan d'essais après une modification, ils proposent la mise à jour et un ingénieur la valide. Chaque action est tracée. Sur les déploiements accompagnés, les équipes passent jusqu'à 50 % de temps en moins sur les tâches d'ingénierie répétitives.

4. Figez une baseline et publiez-la dans le PLM. Quand la conception est prête, l'équipe verrouille une baseline dans Koddex : un état figé du produit, avec ses révisions, ses liens et la raison de chaque décision. C'est cette baseline qui part dans le PLM pour la publication. Le PLM reçoit une configuration propre et cohérente au lieu d'un tableur à ressaisir.

Chaque outil fait ce qu'il fait de mieux. Koddex couvre l'itération rapide, collaborative et tracée. Le PLM couvre la publication contrôlée et la production.

Cinq questions à poser à votre équipe

Avant que le prochain projet démarre dans un tableur, posez-vous ces questions :

1. 1.Combien de copies de la BOM existent en ce moment, et laquelle fait référence ?
2. 2.Quand une pièce change, combien de temps faut-il pour savoir quelles exigences et quels essais elle touche ?
3. 3.La conception, la certification et les achats peuvent-ils travailler sur le produit en même temps ?
4. 4.Quand la conception entre dans le PLM, quelle part est ressaisie à la main ?
5. 5.Si un auditeur demande pourquoi une décision a été prise il y a six mois, où se trouve la réponse ?

Si les réponses sont inconfortables, l'équipe fait probablement du « usualing », pour reprendre le mot d'Oleg Shilovitsky.

Conclusion

Excel ne va pas disparaître, et ce n'est pas nécessaire. Mais la phase d'itération d'un produit hardware réglementé est trop importante pour vivre dans des fichiers auxquels personne ne peut se fier. Itérer sur des données structurées et tracées, avec l'impact de chaque modification visible et des agents IA qui prennent le travail répétitif, puis publier une baseline propre dans le PLM : c'est ainsi que les équipes réduisent leur délai de mise sur le marché sans perdre le contrôle.

Pour le voir sur un produit comme le vôtre, réservez une démo de 20 minutes : nous vous montrons un cas d'usage dans Koddex, et votre premier cas d'usage est en production en un mois.