La gouvernance des données en ingénierie ne doit pas s’arrêter à la connexion au partage sécurisé de fichiers

La plupart des fabricants ne disposent pas d’une seule politique de gouvernance des données. Ils en ont plusieurs : une pour le système PLM, une autre pour la messagerie électronique, une différente pour le partage de fichiers, et souvent aucune politique cohérente pour le canal le plus récent, à savoir les outils d’ingénierie assistée par l’IA ou les intégrations orientées fournisseurs. Chaque politique a été élaborée par une équipe différente, à une période différente, selon des exigences distinctes. Prises individuellement, elles peuvent sembler raisonnables. Mais ensemble, elles créent des failles involontaires que peu de personnes perçoivent.

Ces failles ne restent pas longtemps théoriques. Un fichier de conception classé comme propriétaire dans le système PLM peut circuler librement en pièce jointe d’un e-mail dès qu’il est transféré, car la politique du PLM ne suit pas le fichier hors du système. Un jeu de données bloqué au partage externe dans un système peut sortir via une intégration fournisseur que personne n’a pensé à couvrir. Cet article explique pourquoi la gouvernance par canal garantit l’existence de ces failles chez les fabricants, et ce qu’il faut réellement mettre en place pour les combler.

Résumé exécutif

La gouvernance des données chez les fabricants, construite canal par canal, aboutit inévitablement à une protection incohérente, car chaque outil a été conçu et configuré indépendamment, souvent par des équipes différentes pour répondre à des problèmes immédiats distincts. Le résultat n’est pas une série de risques acceptables pris séparément. Il s’agit d’un risque global équivalent au canal le plus faible, car les données d’ingénierie circulent régulièrement entre les canaux et une politique qui s’arrête à la frontière d’un canal ne protège plus rien une fois la donnée transférée. Pour les responsables ingénierie et IT, cela signifie que l’audit de chaque canal séparément ne permet pas d’identifier ce risque. Il faut auditer le parcours d’un fichier de conception précis lorsqu’il passe d’un canal à l’autre.

Résumé des points clés

1. Une gouvernance fragmentée signifie qu’un même fichier de conception peut être protégé sur un canal et non sur un autre. Une règle de classification ou d’accès appliquée dans un système accompagne rarement la donnée lorsqu’elle circule ailleurs.
2. Les pièces jointes sont l’endroit le plus courant où une politique cesse silencieusement de s’appliquer. Un fichier strictement gouverné dans un système PLM peut être joint à un e-mail et envoyé sans aucune des restrictions du système d’origine.
3. Chaque canal supplémentaire, y compris les intégrations orientées fournisseurs, constitue un point où une faille peut se cacher, et une seule faille suffit.
4. La classification doit être une propriété de la donnée, et non du système où elle se trouve à un instant donné. Un tag ne protège efficacement les données de conception que s’il reste attaché à la donnée lorsqu’elle circule entre les canaux, y compris vers les fournisseurs.
5. Un moteur de politique unique couvrant tous les canaux comble la faille que les outils par canal laissent subsister. L’application de la politique doit être évaluée de la même façon, quel que soit le canal par lequel la donnée transite.

Pourquoi la gouvernance par canal était la norme, et pourquoi elle ne fonctionne pas pour les fabricants

La plupart des fabricants se retrouvent avec une gouvernance fragmentée à la suite d’une série de décisions individuelles, chacune paraissant logique sur le moment. Un système PLM a été choisi et sécurisé, puis la messagerie a été choisie et sécurisée séparément, chaque projet ayant son propre budget, son responsable et sa définition de réussite.

Chaque outil gère son canal, pas le parcours complet de la donnée

Les contrôles d’accès d’un système PLM déterminent qui peut ouvrir, télécharger ou partager un fichier dans ce système. Ils n’ont aucune visibilité ni autorité sur ce qui se passe une fois que le fichier quitte le système en pièce jointe d’un e-mail, est copié dans un autre système ou transféré via une intégration fournisseur. Chaque outil a été conçu pour bien gérer son canal. Aucun n’a été conçu pour suivre la donnée une fois sortie du système.

Les politiques sont rarement harmonisées entre les canaux a posteriori

Une fois chaque canal doté de son propre outil de gouvernance et de ses propres administrateurs, l’harmonisation des politiques entre eux devient un projet sans propriétaire. Il faudrait comparer des jeux de règles écrits dans des langages différents, appliqués par des systèmes différents, couvrant des catégories de données de conception qui se recoupent sans être identiques. En pratique, cette harmonisation n’a quasiment jamais lieu de façon globale.

Où la faille se manifeste concrètement chez les fabricants

Le risque théorique d’une gouvernance fragmentée devient concret à des points précis et prévisibles, lorsque les données de conception franchissent la frontière d’un canal.

Le problème des pièces jointes

Un fichier stocké dans un système PLM strictement gouverné n’est, du point de vue de la plupart des messageries, qu’un fichier qu’un utilisateur a choisi de joindre. Les règles d’accès, de conservation et de partage du système ne suivent pas le fichier dans l’e-mail. Une fois joint et envoyé, le fichier est alors soumis à la politique, généralement bien plus légère, de la messagerie.

Le problème des intégrations et portails fournisseurs

Les fabricants connectent constamment leurs systèmes, via des intégrations fournisseurs et, de plus en plus, des outils d’ingénierie assistée par l’IA qui lisent et synthétisent les données de conception pour les ingénieurs. Chacun de ces canaux permet à des données propriétaires de circuler, avec sa propre configuration d’accès, souvent minimale, plutôt qu’avec la politique réelle de l’entreprise sur ses données.

Pourquoi la classification doit accompagner la donnée

Pour combler ces failles, il faut changer d’approche : au lieu de demander à chaque canal d’appliquer sa propre version d’une politique, il faut évaluer la politique de la même façon, quel que soit le canal où circule la donnée.

Tags et classification comme propriétés portables

Lorsqu’un fichier est tagué comme propriétaire dès son entrée dans un système, cette classification doit l’accompagner dans tous les canaux qu’il traverse, y compris vers les fournisseurs, afin que la même restriction s’applique partout.

L’application de la politique doit couvrir le transfert, pas seulement chaque extrémité

Le moment le plus risqué pour un fichier de conception est le transfert entre canaux, pas son stockage dans l’un ou l’autre. Une gouvernance qui ne prévoit rien pour le partage d’un fichier avec un fournisseur n’a pas réellement comblé la faille.

Auditer la fragmentation plutôt que canal par canal

Le changement à opérer pour les équipes ingénierie ou IT consiste à ne plus se demander « notre système PLM est-il sécurisé » ou « notre messagerie est-elle sécurisée » séparément, mais à s’intéresser au parcours d’un fichier de conception propriétaire lorsqu’il passe d’un canal à l’autre, puis vers les fournisseurs.

Comment un plan de contrôle des données comble la faille entre les canaux

Combler la fragmentation ne nécessite pas de remplacer tous les outils spécifiques à chaque canal sur lesquels un fabricant s’appuie déjà. Il s’agit d’ajouter une couche de gouvernance transversale, qui évalue la même politique sur la même donnée, quel que soit le canal par lequel elle transite.

Le Data Control Plane de Kiteworks applique un ensemble unique de règles zero-trust sur tous les canaux par lesquels circulent les données sensibles, notamment la messagerie, le partage de fichiers, les API et les agents IA. La classification appliquée automatiquement à l’entrée dans le système accompagne la donnée, de sorte que la même restriction qui s’applique à un fichier de conception dans le PLM s’applique à nouveau dès qu’une personne tente de l’attacher à un e-mail ou de le partager avec un fournisseur. Chaque décision d’application, sur chaque canal, est enregistrée dans un journal d’audit infalsifiable et sans limitation, qui s’intègre directement aux outils SIEM.

Les fabricants qui souhaitent identifier leurs propres failles entre canaux peuvent demander une démo personnalisée pour voir comment une politique unique appliquée de façon cohérente sur tous les canaux se compare à leur approche actuelle, canal par canal.