À qui appartient le firmware que vous avez écrit ?

Voici une croyance répandue et dangereuse : « j'ai été payé pour développer ce firmware, donc il appartient à mon client. » En droit français, ce n'est pas automatique. Le code source que vous écrivez est une œuvre protégée. Sans clause de cession de droits explicite dans votre contrat, vous conservez, en tant qu'auteur, une partie des droits patrimoniaux.

Pour l'ingénieur systèmes embarqués, le sujet est d'autant plus sensible que le firmware finit gravé dans un produit que le client va vendre, peut-être en grande série, parfois pendant des années. Si la cession des droits est floue, deux risques apparaissent :

• Le client estime tout posséder (y compris vos briques réutilisables, vos outils internes, votre savoir-faire) et vous reproche de les réemployer ailleurs.
• Vous estimez avoir conservé des droits sur des composants que le client exploite sans limite. Le litige naît du non-dit.

La règle d'or : une clause écrite précise qui distingue ce qui est cédé (le firmware spécifique au produit du client) de ce qui reste votre propriété (vos bibliothèques génériques, vos outils, vos méthodes réutilisables).

Aucun firmware moderne n'est écrit intégralement à la main. Vous intégrez des bibliothèques, des pilotes, un noyau temps réel, des composants tiers. Chacun vient avec sa licence, et toutes ne sont pas compatibles entre elles ni avec l'usage commercial que votre client en fait.

Le cas le plus piégeux est celui des licences copyleft (type GPL). Si vous embarquez un composant sous GPL dans le firmware, vous pouvez contaminer l'ensemble du code livré : la licence peut alors exiger que tout le firmware, y compris vos parties propriétaires, soit rendu disponible sous la même licence. Pour un industriel qui voulait garder son firmware fermé, c'est une catastrophe commerciale.

Si vous livrez un firmware comportant un composant GPL sans en avertir le client, et qu'un tiers le révèle après commercialisation, votre responsabilité de prestataire est directement engagée. La RC Professionnelle couvre les conséquences de ce type de faute de prestation.

Le scénario le plus coûteux n'est pas le bug technique : c'est la revendication de propriété intellectuelle. Un tiers affirme que le firmware que vous avez livré reprend du code, un algorithme breveté ou une bibliothèque dont il détient les droits. Tant que le litige n'est pas tranché, le client peut être contraint de suspendre la commercialisation du produit qui embarque votre firmware.

Les conséquences en chaîne sont lourdes :

1. Immobilisation commerciale du produit du client, avec pertes de chiffre d'affaires.
2. Frais de défense juridique pour établir l'origine du code et le bien-fondé (ou non) de la revendication.
3. Réécriture du firmware pour purger le composant litigieux, avec re-validation complète.

Face à cela, deux garanties comptent. La protection juridique professionnelle prend en charge les frais de défense et l'accompagnement dans le litige. La RC Pro couvre les préjudices financiers subis par le client du fait de votre faute. Une réclamation de ce type peut atteindre plusieurs centaines de milliers d'euros entre pertes d'exploitation et coûts de réécriture.

Réutiliser des composants tiers n'est pas seulement un sujet de licence : c'est aussi un sujet de sécurité. Une bibliothèque obsolète, un composant comportant une vulnérabilité connue, un pilote non maintenu : tout cela peut introduire une faille dans le firmware que vous livrez, sans que vous l'ayez écrite vous-même.

Or, le client vous tiendra pour responsable du firmware dans son ensemble, y compris des briques que vous avez intégrées. Si une vulnérabilité présente dans un composant tiers est exploitée et provoque une compromission du dispositif ou une fuite de données, votre responsabilité de prestataire peut être engagée.

Deux réflexes :

• Tenez un inventaire des composants (SBOM). La « software bill of materials » liste tous les composants tiers et leurs versions. C'est l'outil qui vous permet de réagir vite quand une vulnérabilité est publiée.
• Couvrez le volet cyber. Une assurance cyber intervient sur les conséquences d'une atteinte aux données ou d'une compromission liée à votre prestation, là où la RC Pro classique peut atteindre ses limites.

La propriété du firmware est un champ de mines, mais quelques pratiques le désamorcent largement. Avant chaque livraison :

• Clarifiez la cession par écrit. Distinguez le code cédé au client de vos briques génériques réutilisables. Une clause précise évite 90 % des litiges de propriété.
• Auditez vos licences. Listez tous les composants tiers, vérifiez la compatibilité de leurs licences avec l'usage commercial du client, et signalez explicitement tout composant copyleft.
• Maintenez un SBOM à jour. Inventaire des composants et versions, pour la sécurité comme pour la traçabilité juridique.
• Souscrivez les bonnes garanties. RC Pro pour la faute de prestation, protection juridique pour les litiges, volet cyber pour les vulnérabilités. Découvrez l'offre adaptée à votre métier sur la page assurance ingénieur systèmes embarqués.

Le code que vous livrez vous suit pendant toute la durée de vie du produit. Ce que vous documentez aujourd'hui sur sa propriété et ses licences vous protège des années plus tard.