Séquestre de code source : protéger un logiciel métier si l'éditeur ou le prestataire disparaît

Points clés

• Le séquestre (ou entiercement, escrow) consiste à confier le code source d'un logiciel à un tiers de confiance, qui ne le remet au client que si un événement prévu au contrat se produit : faillite de l'éditeur, arrêt de la maintenance, abandon du produit.
• Il n'a de sens que si vous n'êtes pas propriétaire du code : logiciel sous licence, SaaS, ou outils préexistants d'un prestataire. Si le code vous a été cédé et se trouve sur vos comptes, vous n'en avez pas besoin.
• Un dépôt simple (APP, enveloppe e-Soleau de l'INPI, commissaire de justice) date une création ; il ne vous donne aucun accès. Ne confondez pas les deux.
• En SaaS, le code seul ne suffit presque jamais : il faut aussi les scripts de déploiement, la documentation d'exploitation, le schéma de base de données et un accès aux données.
• Rédigez les déclencheurs autour de la défaillance (maintenance non assurée, service interrompu), pas seulement autour de l'ouverture d'une procédure collective, que le Code de commerce neutralise en partie.

Le séquestre de code source est un contrat à trois : l'éditeur (ou le prestataire) dépose le code source de son logiciel chez un tiers de confiance, le client utilisateur y est bénéficiaire, et le tiers ne libère le code qu'en cas d'événement défini à l'avance. C'est l'assurance qu'une entreprise prend lorsqu'elle fait reposer une activité critique sur un logiciel qu'elle ne possède pas. Ce guide explique quand il est utile, ce qu'il faut réellement déposer, comment rédiger les clauses, et pourquoi beaucoup de séquestres se révèlent inutilisables le jour où on en a besoin. Ce guide est pratique et ne constitue pas un conseil juridique : pour un contrat important, faites-le relire par un avocat.

Dépôt, séquestre, entiercement : de quoi parle-t-on ?

Les termes sont souvent mélangés dans les recherches et dans les contrats. Ils recouvrent pourtant deux besoins différents.

La Agence pour la Protection des Programmes propose les deux premiers : le dépôt, avec horodatage, et un service d'escrow (« accès conditionnel à un logiciel déposé pour les utilisateurs ou les clients »). L'enveloppe e-Soleau de l'INPI ne sert qu'à dater : selon l'INPI, elle est conservée 5 ans, prorogeable par périodes de 5 ans jusqu'à 20 ans, et l'option de conservation des pièces est limitée à 2 Go et 100 fichiers. Ni l'une ni l'autre ne vous donne un droit d'usage : le droit d'auteur sur un logiciel naît de sa création, sans formalité, comme nous l'expliquons dans à qui appartient le code.

Avez-vous besoin d'un séquestre ?

Posez-vous une seule question : si ce fournisseur disparaît demain, puis-je continuer à faire tourner et à faire évoluer ce logiciel ?

Un séquestre est utile quand :

• vous utilisez un logiciel sous licence ou un SaaS dont l'arrêt bloquerait votre activité (gestion de production, facturation, plateforme client, logiciel réglementaire) ;
• l'éditeur est une petite structure ou une jeune entreprise, ou dépend d'une ou deux personnes clés ;
• votre prestataire de développement sur mesure a intégré des briques préexistantes dont il garde la propriété et que vous utilisez sous licence ;
• un financeur, un acquéreur ou un grand compte exige une garantie de continuité. C'est le sens de la recherche fréquente « dépôt code source garantie créancier » : la demande vient souvent d'une banque, d'un investisseur ou d'un client public, pas du service informatique.

Il est inutile, ou presque, quand :

• le code a été développé pour vous et les droits vous ont été cédés par écrit ;
• les dépôts Git, l'hébergement et les comptes tiers sont à votre nom ;
• le logiciel est un produit grand public facilement remplaçable, ou un projet open source que vous pouvez reprendre.

Dans ces cas, la meilleure garantie n'est pas un dépôt chez un tiers : c'est d'avoir le code à jour, sur vos propres comptes, chaque jour. C'est notre position par défaut pour les projets sur mesure.

Ce qu'il faut déposer (et ce que tout le monde oublie)

Un séquestre qui contient une archive ZIP de code source vieille de dix-huit mois ne protège personne. Ce qui compte, c'est la capacité d'une autre équipe à reconstruire et exploiter le logiciel à partir du dépôt.

Pour un logiciel installé (sur site ou sous licence) :

1. Le code source complet, y compris les modules internes, les scripts et les fichiers de configuration types.
2. La liste des dépendances avec leurs versions exactes (fichiers de verrouillage), et la liste des composants tiers sous licence.
3. Les instructions de compilation et de déploiement, testées, avec les versions d'outils nécessaires.
4. La documentation technique : architecture, modèle de données, décisions importantes.
5. Les clés et certificats nécessaires à la compilation, ou la procédure pour les régénérer.

Pour un SaaS, ajoutez :

1. L'infrastructure décrite en code (Terraform, Docker Compose, manifestes Kubernetes) ou, à défaut, une procédure d'installation complète.
2. Le schéma de base de données et les scripts de migration.
3. Le runbook d'exploitation : sauvegardes, supervision, renouvellement des certificats, tâches planifiées.
4. Un export régulier de vos données dans un format documenté, ou un droit d'accès direct à leurs sauvegardes. Sans données, un code SaaS récupéré ne vous rend pas votre service.
5. La liste des services tiers (envoi d'e-mails, paiement, stockage) et la manière de les remplacer ou de reprendre les comptes.

Ce dernier bloc est ce qui distingue un séquestre SaaS utile d'un dépôt symbolique. Certains acteurs parlent de « séquestre de continuité » : le dépôt couvre alors aussi l'accès aux comptes d'hébergement pendant une période de transition.

Les déclencheurs : la clause la plus importante du contrat

Le contrat doit dire, sans ambiguïté, quand le tiers remet le code au client. Les déclencheurs habituels sont :

• l'éditeur cesse son activité ou est dissous ;
• l'éditeur n'assure plus la maintenance corrective prévue au contrat, après mise en demeure restée sans effet pendant un délai défini ;
• le produit est abandonné (fin de vie annoncée sans solution de migration) ;
• l'éditeur est racheté et le repreneur refuse de reprendre les engagements de maintenance.

Attention au cas de la faillite. L'article L622-13 du Code de commerce pose que, nonobstant toute clause contractuelle, aucune résiliation ou résolution d'un contrat en cours ne peut résulter du seul fait de l'ouverture d'une procédure de sauvegarde ; la règle s'étend au redressement et à la liquidation judiciaires. Nous n'avons pas trouvé de jurisprudence tranchant la question pour un séquestre de code source, mais un déclencheur rédigé uniquement autour de « l'ouverture d'une procédure collective » est exposé à la contestation, et l'administrateur peut choisir de poursuivre le contrat. Le réflexe prudent est de lier la libération à une défaillance constatée : maintenance non fournie, service interrompu, absence de réponse à une mise en demeure. C'est un point à faire valider par un avocat en droit des entreprises en difficulté.

Ce que le client peut faire du code une fois libéré

Recevoir le code ne suffit pas : il faut avoir le droit de l'utiliser. Le contrat de séquestre ou la licence doit prévoir, en cas de libération, une licence au profit du client pour :

• utiliser, corriger et faire évoluer le logiciel pour ses besoins propres ;
• confier ces travaux à un prestataire tiers de son choix ;
• le faire pour une durée suffisante, souvent celle de la licence initiale ou sans limite.

Sans cette licence, vous détenez une copie du code que vous n'avez juridiquement pas le droit de modifier.

La vérification : le maillon faible

La plupart des séquestres échouent parce que personne n'a jamais vérifié le contenu du dépôt. Trois niveaux de vérification sont courants :

Pour un logiciel vraiment critique, demandez au moins une compilation de contrôle à la signature, puis à chaque version majeure. C'est aussi ce que fait, de façon plus large, un audit technique : vérifier qu'un système peut être repris par une autre équipe.

La fréquence de mise à jour

Un dépôt fige une version. Si l'éditeur livre chaque semaine et met à jour le séquestre une fois par an, vous récupérerez un logiciel en retard d'un an, incompatible avec vos données actuelles. Prévoyez :

• une mise à jour à chaque version majeure, et au minimum chaque trimestre pour un SaaS actif ;
• une notification au bénéficiaire à chaque mise à jour ;
• idéalement, un dépôt automatisé depuis le système d'intégration continue de l'éditeur.

Combien ça coûte, et qui paie ?

Les tarifs varient selon l'agent, le volume, la fréquence de mise à jour et le niveau de vérification : consultez directement les grilles de l'APP ou des agents de séquestre spécialisés. En pratique, le coût est souvent négocié : le client paie quand il est seul à demander la garantie, l'éditeur l'intègre à son prix quand plusieurs clients l'exigent. Mettez ce coût en regard de ce que représenterait une interruption de votre activité pendant les mois nécessaires à une réécriture ; le guide reprendre ou réécrire une application donne un ordre d'idée de ce que coûte une reconstruction.

Checklist avant de signer

• Le logiciel est-il vraiment critique, et le fournisseur est-il un risque de continuité ?
• Le contenu du dépôt est listé, y compris instructions de compilation, infrastructure et données (en SaaS).
• Les déclencheurs reposent sur une défaillance constatée, pas seulement sur une procédure collective.
• Une licence d'utilisation et de modification au profit du client s'applique dès la libération, y compris via un tiers.
• La fréquence de mise à jour est fixée et les mises à jour sont notifiées.
• Au moins une vérification par compilation est prévue.
• La procédure de libération (délai, pièces à fournir, arbitrage en cas de contestation) est décrite.

Questions fréquentes

Le dépôt à l'APP ou l'enveloppe e-Soleau me protège-t-il si mon prestataire fait faillite ? Non. Ces dépôts datent une création et servent de preuve d'antériorité. Seul un contrat de séquestre tripartite, ou une cession de droits avec le code sur vos comptes, vous donne accès au code.

Je fais développer un logiciel sur mesure. Ai-je besoin d'un séquestre ? En général non, si les droits vous sont cédés par écrit et que le code est hébergé sur vos comptes dès le premier jour. Le séquestre reste utile pour les briques préexistantes que le prestataire garde en propriété. Voir notre guide sur comment choisir un prestataire de développement.

Un séquestre a-t-il un sens pour un SaaS ? Oui, à condition d'y inclure l'infrastructure, les procédures d'exploitation et un accès aux données. Un code SaaS seul est rarement exploitable par une autre équipe dans un délai raisonnable.

Que faire si le prestataire a déjà disparu et qu'il n'y a pas de séquestre ? Rassemblez tout ce qui est encore accessible (hébergement, dépôts, sauvegardes), sécurisez les accès, puis faites évaluer ce qui peut être repris. Notre checklist de reprise d'application détaille les étapes, et notre page reprise de logiciel décrit comment nous intervenons.

---

Chez FNB Solutions, le client est propriétaire du code et de la propriété intellectuelle dès le premier jour, et les dépôts comme l'hébergement restent sur ses comptes : un séquestre devient alors superflu pour le code que nous écrivons. Nos conditions contractuelles sont publiques. Si vous dépendez d'un logiciel dont vous ne maîtrisez pas le code, parlons-en.

Sources

• Agence pour la Protection des Programmes (APP) : dépôt horodaté et service d'escrow (accès conditionnel au logiciel déposé)
• INPI, se préparer au dépôt d'une e-Soleau : durée de conservation et limites de taille
• Code de commerce sur Légifrance, article L622-13 : sort des contrats en cours en cas de procédure collective
• Code de la propriété intellectuelle sur Légifrance : protection du logiciel par le droit d'auteur