Contrats de séquestre logiciel, expliqués : comment le séquestre du code source vous protège lorsqu'un fournisseur critique fait défaut

Imaginez ce lundi matin : la petite société éditrice du logiciel qui fait tourner votre facturation, votre gestion des stocks ou vos dossiers clients a fermé ses portes du jour au lendemain. La ligne de support ne répond plus, la facture de renouvellement n'arrivera jamais, et un bug critique que vous avez signalé la semaine dernière ne sera jamais corrigé. Vous payez ce logiciel depuis des années — mais vous n'avez jamais possédé le code source ; impossible donc de le corriger, de le déplacer ou même de le maintenir en fonctionnement sur un nouveau serveur. C'est précisément cet écart entre payer un logiciel et le maîtriser que comble un contrat de séquestre logiciel.

Ce qu'est réellement un contrat de séquestre logiciel​

Un contrat de séquestre logiciel est un contrat tripartite entre vous (le licencié ou bénéficiaire), votre éditeur de logiciel (le déposant) et un tiers neutre appelé l'agent de séquestre. L'éditeur dépose une copie de son code source et des éléments associés auprès de l'agent, qui les conserve en toute sécurité et ne vous les libère qu'en cas de survenance de l'un des déclencheurs de libération spécifiques prévus au contrat — généralement l'insolvabilité de l'éditeur, sa défaillance dans le support du produit ou un autre manquement défini.

L'arrangement protège les deux parties à la fois. L'éditeur conserve la pleine propriété de sa propriété intellectuelle en fonctionnement normal ; rien n'est partagé et le développement se poursuit comme d'habitude. Vous obtenez un filet de sécurité de continuité : si l'éditeur ne peut plus maintenir le logiciel en vie, vous recevez les éléments nécessaires pour le maintenir vous-même ou le confier à un autre développeur.

Voici ce que le séquestre n'est pas, car chaque malentendu a coûté cher à de vrais acheteurs :

• Ce n'est pas un transfert de propriété. Vous recevez, au mieux, une licence conditionnelle d'utilisation des éléments libérés pour soutenir vos propres opérations — pas le droit de revendre le produit ni de revendiquer la PI.
• Ce n'est pas automatique. Il n'y a pas de séquestre tant que les trois parties n'ont pas signé un contrat, que l'éditeur n'a pas effectivement déposé les éléments et que les dépôts ne restent pas à jour. Une clause de votre licence indiquant que « l'éditeur devra entrer en séquestre » sans suite ne protège rien.
• Ce n'est pas un substitut aux droits sur vos données. Le code sans vos données n'est qu'une coquille vide. Le séquestre couvre les éléments de l'éditeur ; votre droit d'exporter vos propres données dans un format exploitable relève de la licence ou du contrat SaaS lui-même.

Ce que contient le dépôt​

Le dépôt comprend tout ce dont un développeur compétent aurait besoin pour reconstruire, installer et maintenir le logiciel sans l'aide de l'éditeur. Le code source seul suffit rarement. Un dépôt complet inclut généralement le code source de la version de production courante, les scripts de build et les instructions de compilation, les bibliothèques tierces et les listes de dépendances, les schémas de base de données et les scripts de migration, les fichiers de configuration, les suites de tests, la documentation système, ainsi qu'une description de l'environnement de développement, y compris les versions de compilateur et les détails de la chaîne d'outils.

Aussi important que le contenu est la fréquence des mises à jour. Le logiciel change constamment, et un dépôt datant de deux ans peut ne pas correspondre à la version que vous utilisez aujourd'hui. Les contrats solides exigent de l'éditeur qu'il dépose chaque nouvelle version — ou au minimum chaque version majeure et mineure — dans un délai défini, par exemple 30 jours après la disponibilité générale. Certains agents de séquestre prennent en charge des dépôts automatisés synchronisés depuis le référentiel de l'éditeur, ce qui élimine entièrement le mode de défaillance « on a oublié de mettre à jour le séquestre ». Lors de la négociation, demandez comment les dépôts sont livrés et qui confirme leur réception ; « l'éditeur s'engage à envoyer les mises à jour » sans étape de confirmation est un maillon faible qu'il vaut la peine de corriger avant de signer.

Les déclencheurs de libération : la clause qui décide de tout​

Les conditions de libération sont le cœur du contrat : les événements spécifiques qui amènent l'agent à vous remettre les éléments. Si la liste des déclencheurs est trop étroite, le séquestre reste inactif précisément pendant la crise pour laquelle vous l'avez souscrit. Les déclencheurs que les acheteurs négocient le plus souvent incluent :

• L'insolvabilité ou la faillite de l'éditeur, y compris les cessions au bénéfice des créanciers.
• La cessation d'activité, que ce soit par fermeture, dissolution ou arrêt prolongé des opérations.
• La défaillance dans le support ou la maintenance du logiciel pendant une période définie, par exemple 30 ou 60 jours après notification écrite.
• Le manquement substantiel à la licence ou au contrat de maintenance que l'éditeur ne corrige pas dans le délai de remédiation.
• L'arrêt de la gamme de produits dont vous dépendez, même si l'éditeur lui-même survit.
• Le changement de contrôle, par exemple l'acquisition par un concurrent direct — les éditeurs y résistent souvent car cela complique leurs propres fusions-acquisitions, attendez-vous donc à une négociation.

Deux points de rédaction comptent plus que les acheteurs ne l'imaginent. Premièrement, les déclencheurs doivent être objectivement vérifiables — « défaut de fournir le support pendant 45 jours après notification » se prouve, tandis que « perte de confiance dans la viabilité de l'éditeur » invite à un litige avec l'agent coincé au milieu. Deuxièmement, les déclencheurs liés à la faillite méritent attention : les dispositions qui se déclenchent uniquement parce qu'une requête en faillite a été déposée peuvent soulever des questions d'opposabilité devant le tribunal de la faillite. Des conseils expérimentés ancrent donc au moins certains déclencheurs à des défaillances de performance concrètes — rejet de la licence, non-support prolongé, manquement non corrigé — qui résistent à l'examen parce qu'ils décrivent ce que l'éditeur a cessé de faire, et non devant quel tribunal il a déposé.

Confirmez également les mécanismes de libération : comment vous notifiez l'agent, combien de temps l'éditeur a pour s'y opposer et ce qui se passe pendant la fenêtre d'opposition. Un cycle de notification et d'opposition de 10 à 15 jours est typique, et le contrat devrait préciser que les oppositions futiles ne gèlent pas indéfiniment la libération.

La vérification : prouver que le dépôt permettrait réellement de reconstruire​

Un dépôt de séquestre que vous n'avez jamais testé est une promesse, pas une garantie. La vérification est le service — généralement assuré par l'agent de séquestre ou un auditeur technique — qui contrôle si les éléments déposés fonctionneraient réellement en cas de libération. Elle se décline généralement en trois niveaux :

• Niveau 1 : inventaire et exhaustivité. L'agent confirme l'existence du dépôt, en liste le contenu et vérifie que les catégories d'éléments promises sont présentes et lisibles. Cela détecte les dépôts vides ou partiels, mais ne dit rien sur la compilation du code.
• Niveau 2 : vérification du build. L'auditeur compile le code source déposé dans un environnement propre et confirme qu'il produit un logiciel fonctionnel. Cela détecte les dépendances manquantes, les scripts de build cassés et les exigences de chaîne d'outils non documentées.
• Niveau 3 : tests de fonctionnalité complets. Le dépôt est compilé, déployé et comparé au produit en service — parfois appelé comparaison binaire ou test complet d'utilisabilité — pour confirmer que les éléments libérés reproduisent le logiciel que vous utilisez réellement.

Chaque niveau coûte plus cher que le précédent, alors adaptez le niveau aux enjeux. Pour un logiciel dont la défaillance arrêterait votre facturation ou vos opérations, une vérification de niveau 2 au moins annuelle est le minimum raisonnable ; le niveau 1 seul laisse sans réponse la question centrale — est-ce que cela compile ? —. Quel que soit le niveau choisi, planifiez la vérification comme un événement récurrent lié aux versions majeures, et non comme une case à cocher unique à la signature. La défaillance de séquestre la plus courante n'est pas un éditeur véreux mais un dépôt obsolète et non vérifié que personne n'a regardé pendant trois ans.

Ce que cela coûte et qui paie​

La tarification s'est scindée en deux marchés. Les agents de séquestre traditionnels facturent généralement des frais de mise en place uniques plus des frais annuels par contrat : les points de départ publiés tournent autour de 995 $ de mise en place et 1 595 $ par an pour un contrat à bénéficiaire unique, les services de vérification et les structures à bénéficiaires multiples étant facturés en sus. Les plateformes de séquestre en libre-service destinées aux plus petites entreprises affichent des tarifs d'abonnement à partir d'environ 139 $ par mois pour le séquestre logiciel et environ 199 $ par mois pour le séquestre SaaS, avec les dépôts automatisés et la vérification par niveaux en options. Les contrats d'entreprise avec dépôts fréquents et vérification complète du build peuvent atteindre cinq chiffres par an.

Qui paie est négociable et suit généralement le rapport de force. Les éditeurs paient souvent lorsque le séquestre fait partie de leur processus standard de vente aux entreprises — surtout dans le cadre d'un contrat à bénéficiaires multiples qui couvre de nombreux clients à faible coût par tête. Les acheteurs paient souvent lorsqu'ils sont ceux qui exigent le séquestre d'un éditeur qui ne le propose pas couramment. Dans tous les cas, prévoyez un filet de paiement dans le contrat : la raison la plus fréquente de l'effondrement discret d'un séquestre est que quelqu'un cesse de payer les frais annuels de l'agent. Les contrats tripartites accordent couramment au bénéficiaire le droit de régulariser un paiement manqué et de le déduire des autres sommes dues, ce qui maintient la protection en vie précisément pendant la détresse de l'éditeur pour laquelle elle existe.

Le séquestre SaaS : ce que reçoivent les acheteurs de cloud​

Le séquestre traditionnel a été conçu pour un logiciel que vous installez et exécutez vous-même. Pour un logiciel en cloud, un tas de code source sans l'infrastructure, les bases de données, les pipelines de déploiement et le savoir opérationnel de l'éditeur peut être quasi inutile — on ne peut pas « compiler et exécuter » un produit SaaS multi-régions sur un ordinateur portable. C'est pourquoi le séquestre SaaS est devenu une catégorie de produit à part entière, avec des dépôts plus larges.

Un dépôt de séquestre SaaS va généralement bien au-delà du code : images de conteneurs ou packages de déploiement, modèles d'infrastructure-as-code, schémas de base de données plus procédures de sauvegarde et de restauration, inventaires de configuration et de secrets avec procédures de remise documentées, manuels opérationnels de déploiement et dépendances vis-à-vis de services tiers. La vérification évolue en conséquence : de « est-ce que cela compile » à « le service peut-il être reconstitué » — certains prestataires testent réellement la restauration de l'application dans un environnement isolé.

Au sommet du marché se trouve le séquestre de continuité, où l'agent maintient un environnement de reprise pour que le service du client continue de fonctionner pendant une fenêtre définie après un événement de libération, généralement jusqu'à 90 jours, le temps que le client migre. Et quel que soit le niveau, associez tout séquestre SaaS à des droits solides sur les données dans le contrat sous-jacent : des exports planifiés que vous contrôlez, un format documenté et une fenêtre d'accès après résiliation. Le séquestre protège l'application ; seules vos propres sauvegardes et vos droits d'export protègent vos données avec certitude.

Le filet de sécurité de la faillite que vous devriez connaître​

Le droit des faillites américain accorde aux licenciés de logiciels une protection spécifique qu'il vaut la peine de comprendre dans les grandes lignes. Aux termes de l'article 365(n) du Code des faillites, si votre éditeur dépose le bilan et que son administrateur rejette votre contrat de licence, vous pouvez choisir de conserver vos droits contractuels sur la propriété intellectuelle pour le reste de la durée de la licence plutôt que de considérer le rejet comme la fin de l'accord. Les tribunaux ont traité les contrats de séquestre comme des accords complémentaires couverts par cette élection, ce qui est une raison de plus de faire explicitement référence à votre licence dans le contrat de séquestre.

Gardez à l'esprit les limites pratiques. L'article 365(n) préserve votre droit d'utiliser ce que vous avez ; il n'oblige pas l'éditeur en faillite à continuer de vous soutenir, à livrer des mises à jour ou à répondre au téléphone. La loi protège la licence, mais seul un dépôt de séquestre à jour et vérifié met les éléments réels entre vos mains. Voyez la loi comme le laissez-passer juridique et le dépôt de séquestre comme ce qu'elle vous autorise à utiliser — vous avez besoin des deux, et aucun ne fonctionne sans l'autre.

Comment comptabiliser les frais de séquestre dans votre grand livre​

Les frais de séquestre sont des dépenses professionnelles ordinaires, mais leur calendrier mérite un peu de soin comptable. Les frais de mise en place et les frais de vérification liés à une mission spécifique sont généralement passés en charges lorsqu'ils sont engagés. Les frais annuels de séquestre qui achètent douze mois de couverture sont une charge payée d'avance classique : payer l'année entière d'avance et passer un mois à la fois en charges garde le compte de résultat de chaque mois fidèle, au lieu de charger janvier de toute la facture.

Si vous tenez vos comptes en texte brut, le schéma ressemble à ceci :

2026-01-15 * "EscrowTech" "Source-code escrow annual fee - ERP vendor"
  Assets:Prepaid:Escrow-Fees  1,595.00 USD
  Assets:Checking
 
2026-01-31 * "Amortize January escrow coverage"
  Expenses:Professional-Services:Legal  132.92 USD
  Assets:Prepaid:Escrow-Fees

Répétez l'écriture d'amortissement mensuel — ou automatisez-la avec une transaction planifiée — et le solde des charges payées d'avance atteint zéro juste au moment où l'avis de renouvellement arrive, ce qui sert aussi de rappel pour confirmer que les dépôts de l'éditeur sont à jour avant de payer une année de plus. Si les frais de séquestre sont intégrés à un contrat logiciel plus large plutôt que facturés séparément, isolez-les dans leur propre compte afin de voir ce que la protection de continuité coûte réellement lorsque les négociations de renouvellement arrivent. Des écritures mensuelles linéaires suffisent à la plupart des petites entreprises ici ; la documentation Beancount couvre des schémas d'enregistrement plus sophistiqués pour les technophiles.

Les erreurs courantes qui anéantissent la protection​

La plupart des séquestres qui échouent échouent de manière ennuyeuse et évitable. Parcourez cette liste avant de signer, puis une fois par an :

1. Ne jamais vérifier le dépôt. Un séquestre non testé est le type de fausse assurance le plus coûteux. Prévoyez au moins une vérification au niveau du build pour les logiciels critiques.
2. Laisser les dépôts devenir obsolètes. Liez les obligations de dépôt aux versions avec un décompte de jours, exigez que l'agent confirme la réception et planifiez un contrôle trimestriel de correspondance entre la version déposée et votre version de production.
3. Accepter des déclencheurs qui ne se déclenchent jamais. « Faillite de l'éditeur » seul manque le lent déclin : le support qui se dégrade, la gamme de produits discrètement abandonnée, l'acquisition après laquelle votre contrat n'est honoré que de nom. Exigez des déclencheurs de défaillance du support et d'arrêt de gamme avec des délais de remédiation clairs.
4. Aucun droit de régularisation sur les frais. Si seul l'éditeur peut payer l'agent et que l'éditeur est défaillant, le séquestre s'éteint au moment où vous en avez le plus besoin. Conservez le droit du bénéficiaire de payer et de déduire.
5. Traiter le séquestre comme tout le plan de sortie. Le séquestre vous remet des éléments, pas une migration. Maintenez vos propres exports de données, documentez vos intégrations et sachez — avant la crise — qui reconstruirait et exploiterait réellement le système à partir d'une libération.

Avez-vous réellement besoin d'un séquestre ?​

Toute relation avec un fournisseur ne justifie pas le coût et la négociation. Le séquestre vaut son prix lorsque le logiciel est critique pour l'activité, que l'éditeur est petit ou financièrement opaque, que les coûts de changement sont élevés, ou qu'un régulateur ou un client grand compte l'exige de vous en pratique. Un SaaS banal, avec une concurrence saine, un export de données en un clic et des conditions mensuelles, en a rarement besoin — votre levier y est la capacité de partir, et le plan de sortie est un manuel de migration plutôt qu'un dépôt.

Lorsque vous en avez besoin, abordez la négociation avec une courte liste de contrôle : définition complète du dépôt avec des éléments nommés, dépôts à chaque version dans les 30 jours, déclencheurs de défaillance du support et d'arrêt de gamme en plus de la faillite, votre droit de régulariser les frais d'agent manqués, une vérification au niveau du build au moins annuelle, et — pour le SaaS — les éléments d'infrastructure plus une restauration testée. Obtenez ces six conditions et le contrat fait ce que les acheteurs supposent que tout séquestre fait déjà. Votre dernière étape est la plus simple : une fois le contrat signé, planifiez la première vérification et le premier contrôle de confirmation de dépôt avant de classer le dossier, car un séquestre que personne n'entretient n'est qu'une taxe de dépôt avec de la paperasse.