Dépôt de logiciels en vertu du droit néerlandais

Si votre activité dépend d'un logiciel que vous n'avez pas développé, vous dépendez de l'entreprise qui l'a créé. Vous détenez le code objet et une licence ; le fournisseur détient le code source, la chaîne de compilation et le savoir-faire. Cette asymétrie est tolérable tant que le fournisseur est solvable et compétent, mais elle ne l'est plus dès qu'il ne l'est plus. Le dépôt fiduciaire de logiciels est la solution courante, mais elle n'est efficace que si elle est rédigée en tenant compte du droit néerlandais de l'insolvabilité – ce qui est rarement le cas.

Qu’est-ce qu’un compte séquestre et quel est le risque qu’il couvre ?

Le fournisseur dépose le code source et la documentation associée auprès d'un tiers indépendant, qui les conserve jusqu'à la survenance d'un événement défini, puis les remet au client. Ce dernier peut alors utiliser et modifier le code pour assurer la continuité du service. Le risque réside dans la continuité, et non dans la propriété : un client qui utilise le produit d'un fournisseur pour le traitement des commandes, les dossiers patients ou la planification de la production ne peut pas changer du jour au lendemain, car la migration prend des mois et nécessite généralement l'assistance du fournisseur sortant. Le dépôt fiduciaire permet de gagner du temps pour une transition en douceur. Trois situations sont à considérer :

• Insolvabilité. Le fournisseur est déclaré en faillite, un administrateur judiciaire est nommé, le personnel démissionne et le soutien cesse. C'est pour ce type de situation que la procédure de séquestre est prévue, et c'est là que le droit néerlandais intervient le plus.
• Arrêt. Le fournisseur retire le produit, abandonne votre version ou est racheté par une entité qui n'a aucun intérêt pour votre déploiement. Ce type d'incident est plus fréquent qu'une faillite et souvent omis de la clause de résiliation.
• Échec persistant de la maintenance. Le fournisseur existe toujours et continue à facturer, mais il ne corrige plus les défauts, n'envoie plus de correctifs de sécurité et ne maintient plus la compatibilité du produit avec ses dépendances.

Accords bilatéraux et tripartites

Un accord bilatéral est une promesse, inscrite dans le contrat principal, selon laquelle le fournisseur remettra le code source si un événement défini se produit. C'est une solution peu coûteuse mais fragile : aucun organisme indépendant ne vérifie que les fonds ont bien été déposés ou mis à jour, et surtout, en cas de faillite, vous demandez au syndic de s'acquitter d'une obligation de la masse, ce à quoi il n'est pas tenu.

Un accord tripartite introduit un agent fiduciaire comme partie contractante. Cet agent prend en charge le dépôt, le vérifie, le conserve et a l'obligation directe de vous le restituer. C'est la raison même de son mandat : la restitution est effectuée par un tiers solvable, agissant en vertu de son propre contrat, et non par une masse en faillite. L'agent décide également si un événement donnant lieu à la restitution a eu lieu, ce qui remplace la décision d'un syndic sans intérêt à vous aider.

Qu'est-ce qui est réellement déposé ?

L'erreur la plus fréquente est d'ordre légal : il s'agit d'un dépôt contenant uniquement le code source. Or, le code source seul ne compile pas : remis à un développeur sans instructions de compilation ni liste de dépendances, un code source volumineux peut nécessiter des semaines de rétro-ingénierie avant d'aboutir à un binaire fonctionnel – un temps précieux dont vous ne disposez pas lorsque le système n'est plus pris en charge. Un dépôt sans instructions de compilation est donc inutile.

Ajoutez une obligation de mise à jour. Un dépôt effectué une seule fois à la signature expire au bout d'un ou deux cycles de publication. Liez les dépôts au calendrier de publication (à chaque publication majeure ou à intervalle fixe) et exigez un droit d'être informé en cas de retard.

Vérification : ce pour quoi vous payez

Choisissez l'option intermédiaire ci-dessous comme option standard, ainsi que le test complet lorsque toute interruption de service serait critique. La vérification au niveau des fichiers seule est quasiment inutile.

• Vérification au niveau du fichier. L'agent confirme que le dépôt est lisible, exempt de virus et correspond à une liste de fichiers. Cela prouve qu'un fichier a été reçu, mais pas qu'il fonctionne.
• Examen de l'exhaustivité et de la documentation. L'agent vérifie les instructions de compilation et les dépendances par rapport au dépôt et signale les anomalies. Cette option intermédiaire convient à la plupart des clients : elle détecte les erreurs courantes (étapes de compilation manquantes, dépendances non documentées, composant non autorisé) à un coût bien inférieur à celui d'un test complet.
• Test complet de compilation et d'exécution. L'agent effectue le dépôt dans un environnement sécurisé et le teste avec des données de test. C'est le seul niveau de vérification qui confirme le bon fonctionnement du dépôt, mais il est plus lent, plus coûteux et nécessite d'être répété à chaque évolution du logiciel.

Événements de lancement, rédigés de manière à ce qu'ils ne puissent faire l'objet d'aucune contestation.

Une clause de libération est un mécanisme que l'agent fiduciaire doit appliquer sous la contrainte et sans avis juridique. Chaque événement doit pouvoir être établi par un document ou par la durée de son exécution, et non par une appréciation du comportement du fournisseur.

Deux points sont essentiels. Il faut faire peser la charge de la preuve sur le fournisseur : le client notifie l’agent en fournissant des éléments de preuve, le fournisseur dispose d’un délai court et fixe pour s’y opposer, et en l’absence d’opposition, l’agent livre le contrat. Il faut également définir à l’avance la procédure de règlement des litiges – expertise ou arbitrage dans des délais courts – afin qu’une objection ne permette de gagner que quelques jours, et non des mois.

La question de l'insolvabilité aux Pays-Bas

Tout ce qui précède concerne la conception du contrat. Ce qui suit détermine sa validité en cas de faillite du fournisseur.

Ce que le fiduciaire peut refuser

Aux termes de l'article 37 Fw, lorsqu'un contrat réciproque n'a pas été intégralement exécuté par l'une ou l'autre des parties au moment de l'ouverture de la procédure de faillite, la partie adverse peut accorder au syndic un délai raisonnable par écrit pour déclarer si elle entend exécuter ses obligations ; à défaut, elle perd son droit d'exiger l'exécution du contrat. L'article 37 Fw n'a pas pour effet de mettre fin au contrat ni de conférer au syndic le pouvoir de le résilier. Le contrat demeure valide ; le syndic n'est simplement pas tenu d'exécuter ses obligations, et la partie adverse conserve une créance dans le cadre de la procédure de faillite, conformément à l'article 37a Fw.

Pour les logiciels, cela signifie que le mandataire peut refuser la maintenance, le support, les mises à jour, l'hébergement et les dépôts supplémentaires : des prestations qui engendrent des frais pour la succession. Il faut s'attendre à un refus. La question est de savoir si cela peut aller plus loin et vous empêcher d'utiliser ce que vous possédez déjà.

Nebula, Berzona et Credit Suisse/Jongepier

Pendant une décennie, la situation est restée véritablement incertaine. Dans l' affaire Nebula (Hoge Raad, 3 novembre 2006, ECLI:NL:HR:2006:AX8838), la Cour suprême a jugé que, même si la faillite n'entraîne pas en soi la résiliation des contrats en cours, une contrepartie titulaire d'un droit d'usage ne pouvait continuer à l'exercer à l'encontre du syndic comme si la faillite n'avait pas eu lieu ; cela aurait permis à un créancier de faire fi de la faillite au détriment des autres. Cette décision a été largement interprétée comme autorisant un syndic à annuler un droit d'usage préexistant, ce qui a suscité l'inquiétude des titulaires de licences.

Cette interprétation n'a pas été retenue. Dans l'affaire ABN AMRO/Berzona (Hoge Raad, 11 juillet 2014, ECLI:NL:HR:2014:1681), la Cour suprême a jugé que la faillite n'a aucun effet sur les accords réciproques existants ni sur les obligations qui en découlent, et ne confère au syndic aucun pouvoir que la loi ou le contrat ne lui confère déjà ; il ne peut, par exemple, résilier un bail toujours en cours.

La question a été tranchée dans l'affaire Credit Suisse/Jongepier qq (Hoge Raad, 23 mars 2018, ECLI:NL:HR:2018:424). Le syndic peut refuser passivement d'exécuter une obligation, mais la faillite ne lui confère pas le pouvoir d'annuler une prestation rendue par le débiteur avant la faillite, ni de mettre fin à une prestation en cours, dans la mesure où celle-ci consiste à tolérer ou à s'abstenir de faire quelque chose.

C’est cette formulation qui importe pour les logiciels. Une licence constitue, en substance, un engagement du titulaire de droits à tolérer une utilisation qui, autrement, enfreindrait le droit d’auteur ; il s’agit d’une prestation continue consistant à tolérer cette utilisation. En vertu de la loi actuelle, une licence valablement accordée avant la faillite lui survit et le syndic ne peut la révoquer. Le syndic peut refuser toute prestation en vigueur, mais ne peut pas supprimer un droit d’utilisation que vous détenez.

Ce que cela signifie pour votre arrangement

Deux points importants en découlent. Il convient de maintenir l'obligation de libération sur le dépositaire fiduciaire, et non sur le fournisseur : dans le cadre d'une garde indépendante détenue par un tiers, la libération constitue l'exécution propre du dépositaire, et le pouvoir du fiduciaire en vertu de l'article 37 Fw s'exerce sur les prestations dues par la masse plutôt que sur celles d'un dépositaire solvable, alors qu'une promesse bilatérale exige une exécution par la masse, que le fiduciaire peut refuser. Enfin, il est essentiel d'accorder la licence dès le départ plutôt qu'au moment de la libération — point de rédaction primordial, abordé ci-dessous.

Dans le cadre d'une restructuration et non d'une faillite, l'article 373 Fw restreint l'utilisation des clauses de résiliation automatique – dispositions permettant à une contrepartie de modifier, suspendre ou résilier un contrat du seul fait du lancement d'une procédure de restructuration. Cette restriction s'applique à la procédure de restructuration, et non à la faillite, et la réponse est, là encore, structurelle : lorsque l'accord prévoit une garde indépendante par un tiers, le déclencheur de la libération s'appuie sur l'obligation propre du mandataire et ne constitue pas une clause de résiliation automatique susceptible d'être annulée, que ce soit dans le cadre d'une restructuration ou d'une faillite.

Structure de la licence

Le dépôt fiduciaire vous donne accès à une copie du code source, mais pas au droit de l'utiliser. Le code source est une œuvre protégée ; sa compilation, sa modification et l'exécution du résultat sont des actes interdits. Sans licence les couvrant, le dépôt débloqué est comme un dossier que vous ne pouvez pas ouvrir. Associez le dépôt fiduciaire à une licence autorisant expressément le client, dès la libération du code source, à l'utiliser, le compiler, le modifier et le développer, et à faire appel à un tiers pour ces opérations – en pratique, vous n'aurez pas à effectuer ces travaux vous-même.

Ensuite, il y a la question du calendrier. Une licence accordée lors de la libération est fragile. Si l'événement de libération est la faillite elle-même, l'octroi devrait être fait par un débiteur qui, dès le jour de l'ordonnance de faillite, a perdu le pouvoir de disposer des actifs de la masse ; les articles 23 et 35 de la loi fédérale sur la faillite (Fw) s'y opposent, et le syndic ne procédera pas à l'octroi pour vous. L'arrêt Credit Suisse/Jongepier signifie que le syndic ne peut pas révoquer une licence que vous déteniez déjà – mais il n'y a rien à révoquer si vous n'en avez jamais eu.

Accordez ce droit dans le contrat lui-même, avant toute insolvabilité, sous réserve d'une condition suspensive : il est accordé immédiatement et prend effet lors de la réalisation d'un événement libératoire. Le droit existe dès la date du contrat ; seul son effet est différé. Le droit néerlandais est généralement favorable à cette structure. Dans l'affaire Rabobank/Reuser (Hoge Raad, 3 juin 2016, ECLI:NL:HR:2016:1046), la Cour suprême a admis que lorsqu'un droit conditionnel a été créé avant la faillite, la réalisation ultérieure de la condition prend effet sans autre intervention du débiteur. Cette affaire portait sur un transfert conditionnel de marchandises et un nantissement sur le droit conditionnel. Son application à une licence de droit d'auteur accordée conditionnellement relève d'une extrapolation fondée sur la doctrine juridique plutôt que d'une jurisprudence établie, et doit être présentée comme telle.

Confirmez également que l'utilisation du matériel diffusé ne nécessite aucun autre consentement du fournisseur ou de son administrateur, et que la sous-licence à un développeur successeur est autorisée.

SaaS et cloud : le code source ne suffit pas

Pour un logiciel que vous gérez vous-même, le code source, les instructions de compilation et la licence constituent une solution quasi complète. Ce n'est pas le cas pour un service. Si la plateforme du fournisseur tombe en panne, vous perdez l'application, son environnement d'exécution et vos données ; or, le code source ne permet de restaurer que l'application, et ce, lentement. Un plan de continuité d'activité SaaS doit donc prévoir trois éléments supplémentaires :

• L'environnement opérationnel. Images de conteneurs, définitions d'infrastructure en tant que code, configuration, paramètres réseau et de sécurité, dépendances d'exécution — de quoi déployer la plateforme ailleurs.
• Les données. Exportation régulière de vos données dans un format documenté et non propriétaire, avec le schéma. Des données illisibles ne vous appartiennent pas ; ces exportations doivent être effectuées pendant toute la durée du contrat, et pas seulement lors de sa mise en production.
• La relation d'accueil. Une manière d'intervenir dans le contrat du fournisseur avec son hébergeur, ou d'informer ce dernier que vous souhaitez prendre le contrôle du compte et payer directement.

Des alternatives, et qui paie ?

Le dépôt fiduciaire n'est pas toujours la solution la plus avantageuse, notamment pour les produits standards où vous êtes un client parmi des milliers et où le risque réel est plutôt celui d'une interruption de service que d'une panne. Trois options plus légères sont souvent plus utiles : un droit de sortie des données (exportations périodiques dans un format documenté et testé au moins une fois), couvrant une grande partie des risques à un coût quasi nul ; un droit à une copie fonctionnelle (une image déployable utilisable pendant une période de transition, permettant une restauration du service bien plus rapide qu'une reconstruction complète) ; et un paiement direct au fournisseur d'hébergement , assurant la continuité de l'environnement pendant la migration (la solution de continuité cloud la plus économique et pourtant la plus souvent négligée).

Lorsque vous utilisez un service de séquestre, prévoyez des frais d'ouverture uniques, des frais de garde annuels récurrents et des frais distincts pour chaque vérification, proportionnels à l'étendue du contrôle. Le coût est à la charge de celui qui souhaite bénéficier de cette protection, généralement le client. Toutefois, un fournisseur proposant le séquestre comme argument de vente peut l'assumer, et un accord multi-bénéficiaires couvrant plusieurs clients d'un même produit permet de répartir les frais – ce qui constitue généralement le point de friction pour un fournisseur. Exigez que l'agent vous notifie tout défaut de paiement, en vous accordant le droit de payer à sa place.

Liste de contrôle pour la négociation d'un accord de séquestre

• S’agit-il d’un véritable accord tripartite avec un agent indépendant qui vous doit une obligation de libération directe ?
• La licence d'utilisation, de compilation, de modification et de développement ultérieur du code source est-elle accordée ? maintenant, sous réserve d'une condition suspensive, plutôt que d'être promis lors de la sortie ?
• La liste des dépôts inclut-elle les instructions de compilation, les dépendances, les clés de licence et la documentation, et pas seulement le code source, mis à jour à chaque version ?
• Quel est le niveau de vérification contractuel et à quelle fréquence est-il répété ?
• Les événements déclencheurs sont-ils déterminables à partir d'un document ou du simple écoulement du temps, avec un délai d'opposition court et une procédure de règlement des litiges rapide ?
• Pour les solutions SaaS : l’environnement, les données et la relation d’hébergement sont-ils couverts, ou seulement le code ?
• Qui paie, que se passe-t-il si le fournisseur cesse de payer, et l'accord de séquestre est-il conforme au droit applicable et aux clauses de propriété intellectuelle du contrat principal ?