Vous avez développé un algorithme qui constitue le cœur de votre avantage compétitif. Algorithme de scoring crédit, moteur de recommandation, méthode d'optimisation logistique, modèle prédictif, technique de matching. Cet algorithme représente plusieurs années de R&D et fonde votre valorisation. Vous voulez le protéger juridiquement. Vous tombez sur des contenus en ligne qui répètent que "votre algorithme est automatiquement protégé par le droit d'auteur". Cette affirmation est juridiquement fausse, et elle conduit chaque année des startups à découvrir, au moment où un concurrent les copie ou un ancien salarié emporte le savoir-faire, qu'elles n'avaient en réalité aucune protection efficace. La protection d'un algorithme propriétaire repose sur une combinaison de plusieurs régimes juridiques aux logiques distinctes : droit d'auteur, brevet, secret des affaires, contrats, protection technique. Aucun de ces régimes n'est suffisant à lui seul. Cet article expose chacune de ces voies, leurs limites, et la stratégie d'articulation par profil de startup.
Pourquoi le droit d'auteur ne protège pas l'algorithme en lui-même
L'idée selon laquelle le droit d'auteur protège un algorithme procède d'une confusion classique entre deux objets juridiques distincts. Le droit d'auteur protège la forme d'expression d'une œuvre. Il ne protège jamais l'idée, la méthode, le procédé ou le concept sous-jacent. Cette règle, dite du principe de libre parcours des idées, est posée par la jurisprudence française depuis le XIXe siècle et a été systématiquement réaffirmée par la Cour de cassation.
Appliquée au domaine logiciel, cette règle a une conséquence directe. Le code source, en tant qu'expression écrite originale d'une logique informatique, est protégé par le droit d'auteur conformément à l'article L. 112-2 13° du code de la propriété intellectuelle (CPI). Mais l'algorithme implémenté par ce code, c'est-à-dire la méthode logique abstraite, ne l'est pas. Un concurrent qui réécrit intégralement un nouveau code source mettant en œuvre le même algorithme ne commet pas de contrefaçon du droit d'auteur. Il a recopié l'idée, pas l'expression.
La Cour de cassation a confirmé cette doctrine à plusieurs reprises. Les fonctionnalités d'un logiciel, ses interfaces, ses langages de programmation et les principes mathématiques qui le sous-tendent sont expressément écartés de la protection par le droit d'auteur. Seules les éléments concrets qui matérialisent l'apport intellectuel humain (lignes de code, organigrammes, matériel de conception préparatoire) peuvent bénéficier de la protection, à condition de remplir le critère d'originalité.
L'exigence d'originalité ajoute une difficulté supplémentaire. La jurisprudence française est devenue particulièrement exigeante ces dernières années. Le titulaire qui agit en contrefaçon doit démontrer que son code traduit un effort personnalisé, un apport intellectuel propre allant au-delà de la mise en œuvre d'une logique technique contraignante. Cette preuve d'originalité est exigeante en pratique, et de nombreuses actions en contrefaçon échouent au stade de la recevabilité, sur ce seul motif.
L'enseignement opérationnel est sans appel. Si la valeur compétitive de votre startup repose sur un algorithme original mais réplicable, le droit d'auteur sur le code n'apporte qu'une protection cosmétique. Un concurrent qui dispose des spécifications fonctionnelles et d'une équipe technique compétente peut réimplémenter votre algorithme dans un nouveau code, sans encourir aucun risque juridique au titre du droit d'auteur. La protection véritable de l'algorithme se joue ailleurs.
Le droit d'auteur conserve son utilité pour deux objectifs distincts : protéger la forme du code contre la copie servile (cas typique : un ancien salarié qui emporte le code et l'utilise tel quel chez un concurrent) et conditionner l'éligibilité à des dispositifs fiscaux comme le régime IP Box, qui exige une démonstration d'originalité. Cette articulation est développée dans l'analyse de l'originalité du logiciel pour l'IP Box. Mais ce n'est pas la voie qui protège l'algorithme contre la réimplémentation.
Le brevet : protection conditionnelle si effet technique caractérisé
Le brevet est la seule voie qui peut protéger l'algorithme lui-même, indépendamment de sa forme d'expression dans un code particulier. C'est sa force structurelle : un brevet sur une méthode technique mise en œuvre par ordinateur est opposable à tout tiers qui réimplémenterait la même méthode, dans n'importe quel langage, sur n'importe quelle plateforme.
L'article L. 611-10 du CPI exclut cependant deux catégories qui touchent directement les algorithmes. Le 2° a) écarte les méthodes mathématiques en tant que telles. Le 2° c) écarte les programmes d'ordinateur en tant que tels. Ces exclusions reprennent celles de l'article 52 §2 de la Convention sur le brevet européen.
L'expression "en tant que tel" fonde l'exception développée par la jurisprudence de l'Office européen des brevets. Un algorithme qui produit un effet technique au-delà du simple calcul abstrait peut entrer dans le champ de la brevetabilité conditionnelle. La doctrine OEB Vicom-Comvik-Hitachi, exposée en détail dans l'analyse du brevet logiciel en France, structure cette appréciation.
Concrètement, plusieurs catégories d'algorithmes sont brevetables. Un algorithme de compression vidéo agissant sur des données techniques entre dans le champ. Un algorithme de cryptographie produisant un effet technique de sécurité est brevetable. Un algorithme de contrôle de processus industriel, de calibration de capteurs, d'optimisation énergétique, de routage réseau passe le seuil. Un algorithme d'IA appliqué à un domaine technique caractérisé (vision pour diagnostic médical, contrôle moteur, traitement signal) peut également être protégé.
À l'inverse, plusieurs catégories d'algorithmes restent exclues. Les algorithmes de scoring purement mathématique, sans effet technique, sont exclus. Les algorithmes de matching ou de recommandation pour usage commercial sont généralement écartés. Les méthodes statistiques abstraites, les modèles d'analyse comportementale, les algorithmes d'optimisation business (gestion de stocks, pricing dynamique) sont hors-champ.
Pour les startups dont l'algorithme entre dans le champ brevetable, le dépôt s'inscrit dans une stratégie de protection forte. Pour celles dont l'algorithme est exclu, le brevet n'est pas une option et la protection passe nécessairement par les autres régimes. Cette qualification doit être faite tôt par un conseil en propriété industrielle spécialisé, avant d'engager une stratégie qui s'avérerait inadaptée.
Le secret des affaires : le régime depuis 2018
La loi n° 2018-670 du 30 juillet 2018, transposant la directive (UE) 2016/943, a introduit en droit français un régime structuré de protection du secret des affaires, codifié aux articles L. 151-1 et suivants du code de commerce. Avant cette loi, le secret bénéficiait d'une protection éclatée et imprécise via la concurrence déloyale. Le régime actuel est plus solide et adapté à la protection des algorithmes.
L'article L. 151-1 du code de commerce définit l'information protégée par trois critères cumulatifs. Premier critère : l'information ne doit pas être généralement connue ou aisément accessible aux personnes familières du secteur d'activité concerné. Deuxième critère : l'information doit revêtir une valeur commerciale, effective ou potentielle, du fait de son caractère secret. Troisième critère : l'information doit faire l'objet de mesures de protection raisonnables prises par son détenteur légitime.
Un algorithme propriétaire remplit naturellement les deux premiers critères s'il constitue un avantage compétitif réel et n'est pas publiquement diffusé. Le troisième critère concerne les mesures de protection raisonnables, celui qui appelle le plus d'attention. Sans mesures concrètes et documentées, la protection juridique tombe.
Plusieurs catégories de mesures sont attendues par la jurisprudence. La sécurisation technique : accès restreint aux fichiers contenant l'algorithme, chiffrement des bases de données, segmentation des serveurs, journalisation des consultations. Les mesures organisationnelles : limitation du nombre de personnes ayant accès à l'algorithme, ségrégation des composants critiques (un développeur ne voit qu'une partie), formation des équipes à la confidentialité. Les mesures contractuelles : NDA systématique avec les salariés, prestataires et partenaires, clauses de confidentialité dans les contrats de travail, clauses de non-concurrence et de non-sollicitation pour les profils critiques.
L'article L. 151-4 du code de commerce caractérise l'obtention illicite du secret des affaires. Elle peut résulter d'un accès non autorisé à un document contenant le secret, d'une copie ou d'une appropriation non autorisée, ou plus largement de tout comportement déloyal et contraire aux usages commerciaux. Cette définition couvre largement les hypothèses pratiques : exfiltration par un salarié, intrusion informatique, captation par un partenaire dans le cadre d'une négociation rompue.
L'article L. 152-1 du code de commerce engage la responsabilité civile de l'auteur d'une atteinte. Les actions en cessation, en réparation et en prévention sont disponibles. Les juridictions peuvent ordonner des mesures fortes : interdiction de l'utilisation du secret sous astreinte, destruction des supports, publication du jugement, et indemnisation des préjudices subis.
La protection par le secret présente trois forces structurelles. La durée est potentiellement indéfinie tant que le caractère secret est maintenu. Le coût administratif est nul, contrairement au brevet. La portée est large, couvrant toutes les informations remplissant les critères, sans formalité préalable.
Elle présente aussi trois faiblesses. La protection s'effondre dès la première divulgation, intentionnelle ou accidentelle. La rétro-ingénierie licite, lorsqu'elle est techniquement possible, n'est pas constitutive d'une atteinte au secret. La preuve de la mauvaise foi du contrefacteur est parfois exigeante en pratique.
Pour une startup dont l'algorithme est exécuté exclusivement sur ses serveurs et n'est jamais distribué sous forme exécutable au client (typiquement, un SaaS), le secret des affaires constitue généralement la protection la plus efficace. La discipline contractuelle et organisationnelle qui le supporte recoupe la logique de sécurisation des contrats commerciaux et partenariats.
La protection contractuelle : NDA, clauses, contrats partenaires
Les contrats complètent toute stratégie de protection d'algorithme. Ils transforment des obligations générales (loyauté, bonne foi, secret des affaires) en obligations spécifiques, mesurables et sanctionnables.
Quatre catégories de stipulations contractuelles méritent attention pour une startup tech.
Les NDA (Non-Disclosure Agreements) ou accords de confidentialité sont le premier outil. Ils précèdent toute discussion avec un partenaire, un investisseur, un prestataire, un client stratégique. Un NDA solide définit précisément l'information confidentielle (et n'oublie pas d'y inclure l'algorithme et ses éléments dérivés), liste les usages autorisés et exclut tous les autres, fixe une durée d'engagement (généralement 3 à 5 ans après la fin de la relation), prévoit des exceptions claires (information déjà publique, information développée de manière indépendante, divulgation imposée par la loi), et stipule des sanctions en cas de violation. Les NDA mutuels sont plus équilibrés, les NDA unilatéraux peuvent générer des résistances en négociation.
Les clauses de confidentialité dans les contrats de travail engagent les salariés au-delà de leur obligation générale de loyauté. Elles couvrent typiquement le code source, les algorithmes, les processus internes, les données clients, la stratégie commerciale. Elles survivent à la rupture du contrat de travail pendant une durée définie (souvent 3 à 5 ans). Sans cette clause expresse, la protection après départ est plus fragile et repose principalement sur le secret des affaires, dont la preuve est plus exigeante.
Les clauses de non-concurrence ciblent les profils critiques (CTO, lead developers, data scientists ayant accès aux algorithmes). Elles sont strictement encadrées par la jurisprudence : elles doivent être limitées dans le temps, dans l'espace et par activité, indispensables à la protection des intérêts légitimes de l'entreprise, et assorties d'une contrepartie financière. Mal rédigées, elles sont nulles. Bien rédigées, elles préviennent le départ d'un développeur clé chez un concurrent direct pendant une période de 6 à 24 mois.
Les clauses de cession et de propriété dans les contrats de prestation visent les freelances, ESN et partenaires techniques. Elles doivent respecter le formalisme strict de l'article L. 131-3 du CPI pour être opposables. Elles précisent que tout développement réalisé pour la startup, y compris les algorithmes développés ou améliorés à l'occasion de la prestation, devient sa propriété exclusive. La distinction entre ce qui appartient au prestataire (savoir-faire général) et à la startup (livrables spécifiques) doit être clarifiée pour éviter les contentieux ultérieurs.
L'efficacité de la protection contractuelle dépend de la qualité de rédaction et de la documentation de la chaîne contractuelle. Un audit régulier des contrats, particulièrement avant une levée de fonds, permet d'identifier et de combler les lacunes. C'est un travail technique qui s'inscrit dans la stratégie globale de protection et valorisation de l'innovation.
La protection technique et organisationnelle
La protection juridique ne suffit pas si l'algorithme est techniquement accessible. La sécurisation matérielle est indispensable et conditionne d'ailleurs la validité de la protection par le secret des affaires (qui exige des "mesures de protection raisonnables").
Cinq mesures techniques structurent la protection.
Première mesure : exécuter l'algorithme exclusivement sur des serveurs propres, sans jamais distribuer le code exécutable au client. C'est l'architecture des SaaS B2B et des plateformes multi-tenant. L'algorithme reste invisible des utilisateurs, qui n'accèdent qu'à des résultats. Cette architecture neutralise la rétro-ingénierie et constitue la protection technique la plus puissante. Pour une startup dont la valeur réside dans un algorithme, cette architecture doit être un choix stratégique conscient dès la conception.
Deuxième mesure : l'obfuscation du code dans les composants nécessairement distribués. Lorsqu'une partie du code doit être livrée au client (application mobile, JavaScript côté navigateur, librairie embarquée), l'obfuscation rend la rétro-ingénierie plus coûteuse. Elle ne l'empêche pas absolument mais élève le seuil d'effort nécessaire. La combinaison avec le chiffrement, le code natif compilé et les contrôles anti-débogage renforce la protection.
Troisième mesure : la segmentation des accès. Aucun salarié ne doit avoir accès à l'intégralité de l'algorithme, sauf nécessité opérationnelle clairement justifiée. Les composants critiques sont isolés dans des modules dédiés, accessibles uniquement aux profils habilités. Cette segmentation limite l'exposition en cas de départ d'un collaborateur.
Quatrième mesure : la journalisation des accès et des consultations. Chaque consultation des fichiers sensibles fait l'objet d'une traçabilité datée et identifiée. Cette traçabilité dissuade les comportements opportunistes et constitue, en cas de contentieux, un élément de preuve déterminant pour caractériser une exfiltration ou une atteinte au secret.
Cinquième mesure : la documentation des choix de protection. Les politiques de sécurité, les décisions de segmentation, les formations dispensées aux équipes, les audits réalisés doivent être conservés et datés. Cette documentation établit la preuve des "mesures raisonnables" exigées par l'article L. 151-1 du code de commerce. Elle conditionne la possibilité d'agir efficacement en cas de violation.
Ces mesures techniques s'inscrivent dans une démarche organisationnelle plus large. Une politique formelle de protection des actifs immatériels, un référent dédié, des formations régulières, un audit annuel des accès et des contrats forment le socle d'une protection durable.
Stratégie d'articulation des protections : matrice par cas startup
Aucun régime de protection n'est universellement supérieur. La stratégie optimale combine plusieurs régimes selon le profil exact de l'algorithme et de l'entreprise.
Cinq configurations typiques permettent d'orienter le choix.
Configuration 1 : algorithme exécuté côté serveur d'un SaaS B2B, jamais distribué. La combinaison gagnante repose sur le secret des affaires comme protection principale, soutenu par des contrats stricts (NDA, confidentialité salariés, non-concurrence pour profils clés), une protection technique forte (exécution serveur, accès segmenté, journalisation) et le droit d'auteur sur le code source comme couche complémentaire. Le brevet n'est pas pertinent dans cette configuration si l'algorithme n'a pas d'effet technique caractérisé. Cette combinaison est typique des startups SaaS de scoring, recommandation, matching, automatisation.
Configuration 2 : algorithme embarqué dans un produit physique distribué (objet connecté, dispositif médical, matériel industriel). Le brevet devient l'outil de référence puisque l'effet technique est généralement caractérisé. Il s'accompagne d'une obfuscation du firmware embarqué, d'un secret sur les paramètres de tuning non divulgués, et de contrats de distribution rigoureux qui interdisent la rétro-ingénierie. Le droit d'auteur sur le code source vient en complément.
Configuration 3 : algorithme avec composante mathématique pure (modèle prédictif, scoring crédit, calcul actuariel). Le brevet est largement exclu par les articles L. 611-10 §2 a) et c) du CPI. La protection passe nécessairement par le secret des affaires, soutenu par une discipline contractuelle stricte. La protection technique est centrale puisque c'est le seul rempart contre la captation. Cette configuration est celle de nombreuses startups fintech, insurtech, healthtech.
Configuration 4 : algorithme distribué via API publique avec accès payant. La distribution publique fragilise la protection par le secret. La stratégie combine alors le brevet (si effet technique caractérisé), des contrats d'utilisation API très stricts encadrant les usages permis, des moyens techniques de détection des abus (rate limiting, fingerprinting), et le droit d'auteur sur le code source. Cette configuration est celle des startups d'API B2B (NLP, vision, géocodage).
Configuration 5 : algorithme d'IA avec modèle propriétaire entraîné sur des données spécifiques. La protection s'organise sur trois niveaux. Le modèle entraîné lui-même peut bénéficier du secret des affaires si jamais distribué, ou d'une protection technique forte (exécution serveur, accès segmenté). Les données d'entraînement bénéficient de la protection sui generis des bases de données de l'article L. 341-1 du CPI si l'investissement substantiel est démontré. L'architecture du modèle peut, dans certains cas, faire l'objet d'un brevet si elle apporte un effet technique caractérisé. Les contrats avec les prestataires d'annotation et de fourniture de données doivent encadrer la titularité.
L'arbitrage entre ces configurations s'effectue lors d'un audit complet de la chaîne de protection. Cet audit identifie les actifs critiques, qualifie chaque actif au regard des régimes disponibles, mesure les protections actuelles, identifie les écarts, et planifie les actions correctives. Cette démarche structurelle est plus efficace qu'une protection improvisée au coup par coup, et elle s'aligne avec la titularité préalable des droits sur le code, exposée dans l'analyse salariés, freelances, mandataires, IA : qui détient les droits sur le code.
FAQ : Algorithme propriétaire
Mon algorithme est-il automatiquement protégé par le droit d'auteur ?
Non. Le droit d'auteur protège la forme d'expression du code source, pas l'algorithme abstrait. Un concurrent qui réécrit intégralement le code en mettant en œuvre la même méthode logique ne commet pas de contrefaçon de droit d'auteur. Cette idée fausse, largement répandue en ligne, conduit régulièrement les startups à découvrir trop tard qu'elles n'avaient aucune protection efficace contre la réimplémentation. La protection véritable de l'algorithme passe par le brevet, le secret des affaires, les contrats et la sécurité technique.
Que vaut un secret des affaires si un employé part chez un concurrent ?
Le secret reste opposable après le départ. L'article L. 151-4 du code de commerce qualifie d'illicite l'accès ou la copie non autorisée, et l'exploitation engage la responsabilité civile. L'efficacité pratique dépend de la preuve des critères du secret, de l'exploitation avérée, et de mesures contractuelles spécifiques comme les clauses de confidentialité et de non-concurrence.
Faut-il déposer son algorithme à l'INPI pour le protéger ?
Non, sauf à le breveter. L'INPI ne reçoit pas de dépôts d'algorithme en tant que tels. Trois voies existent : le brevet si effet technique caractérisé, le dépôt probatoire auprès de l'APP ou enveloppe Soleau pour constituer une preuve de date, ou la protection par secret des affaires et contrats sans formalité.
Un NDA suffit-il à protéger un algorithme communiqué à un partenaire ?
Non, le NDA est indispensable mais insuffisant. Il crée une obligation contractuelle dont la violation engage la responsabilité du partenaire direct, mais ne protège pas contre les fuites ultérieures ni ne crée de droit privatif. Il doit s'accompagner de discipline pratique : communication minimale, versionnement, traçabilité et démonstrations à distance sur infrastructure contrôlée.
Mon algorithme d'IA peut-il être protégé indépendamment des données d'entraînement ?
Oui, selon des régimes distincts. L'algorithme (architecture, processus, hyperparamètres) peut relever du secret des affaires ou du brevet si effet technique. Les données d'entraînement bénéficient de la protection sui generis des bases de données si investissement substantiel démontré. Le modèle entraîné est protégé par le secret. La stratégie optimale combine ces trois protections, articulées par contrats avec les prestataires.
