Séquestre De Code Source : Qui en a Vraiment Besoin

Le séquestre de code source, aussi appelé entiercement ou software escrow, répond à une crainte légitime : le prestataire qui a construit et exploite votre système critique disparaît, et vous restez avec un outil dont vous dépendez et que vous ne savez pas maintenir. Un contrat de séquestre confie le code source à un tiers, qui vous le remet si cela se produit.

La crainte est fondée. L’instrument, lui, est souvent mal compris, et l’écart entre les deux produit des contrats qui coûtent de l’argent chaque année et qui n’aideraient pas le jour où on en aurait besoin.

La question gênante à poser avant de signer : si le code vous était remis demain, quelqu’un saurait-il seulement le faire tourner ? Un dépôt de code source sans instructions de compilation, sans définition d’infrastructure, sans identifiants pour les services tiers qu’il appelle et sans données n’est pas un plan de continuité. C’est un dossier. Les contrats de séquestre jamais vérifiés libèrent exactement cela, et régulièrement.

Ce que couvre le séquestre de code source

Un contrat tripartite entre vous, le prestataire et un agent de séquestre. Le prestataire dépose le matériel chez l’agent, l’agent le conserve, et des conditions de libération définies déterminent le moment où vous le recevez.

Les conditions de libération sont la partie qui mérite d’être négociée. L’insolvabilité est le cas évident et le plus facile à prouver. D’autres comptent davantage en pratique : le prestataire qui cesse de maintenir le produit, qui n’assure plus ses obligations de support, ou qui se fait racheter par l’un de vos concurrents. Une liste de déclencheurs trop étroite signifie que l’agent refusera de libérer précisément dans les situations ambiguës où vous voulez le plus obtenir le matériel.

Le dépôt lui-même doit contenir plus que du code. Au minimum : des instructions de compilation assez précises pour produire un système qui tourne, les versions des dépendances, la configuration de l’infrastructure, la documentation des services externes et l’emplacement des identifiants, ainsi qu’un contact technique nommé. Sans cela, le code source ne vaut presque rien.

Et le dépôt doit être mis à jour. Une copie prise à la signature et jamais rafraîchie est le portrait fidèle d’un logiciel que plus personne n’exploite.

Pourquoi la plupart des séquestres échouent à la libération

Parce que personne n’a vérifié.

Le contrat standard est un document juridique qui suppose que le contenu technique est correct. Les agents de séquestre proposent des services de vérification qui vont de la simple confirmation que le support est lisible jusqu’à la compilation du dépôt et son exécution dans un environnement propre. Le bas de gamme ne prouve presque rien. Le haut de gamme est la seule version qui répond à la question que vous posez réellement.

Constats fréquents lorsqu’un dépôt est vérifié correctement : il ne compile pas sans un outil que personne n’a documenté, il dépend d’un dépôt de paquets privé qui n’existera plus après le prestataire, il exige des identifiants pour des services jamais listés, ou il correspond simplement à une version plus ancienne que celle qui tourne en production.

Si vous payez pour un séquestre, payez pour la vérification. Un contrat non vérifié transfère le sentiment du risque sans transférer le risque, et l’écart de prix est plus faible que le coût de la découverte au pire moment.

Le problème du SaaS

Le séquestre traditionnel suppose que vous exploiteriez le logiciel vous-même. Pour un logiciel hébergé, cette hypothèse ne tient généralement pas.

Recevoir le code source d’une plateforme à laquelle vous accédiez par Internet vous laisse avec un besoin d’infrastructure, d’outils de déploiement, de savoir-faire d’exploitation et de vos propres données, dont l’essentiel ne figure pas dans le dépôt. Même avec un paquet complet, la mise en service prend des semaines qu’une entreprise dépendante du système a rarement devant elle.

C’est pourquoi les protections utiles pour un logiciel hébergé sont d’une autre nature. Le droit d’extraction des données compte plus que le code : un droit contractuel à un export complet dans un format documenté, exercé régulièrement plutôt que promis. Un engagement de continuité, par lequel le prestataire accepte d’exploiter le service pendant un préavis défini après la résiliation, achète le temps de migration que le code seul ne procure pas. Un export vérifié que vous avez réellement testé vaut plus que n’importe quel dépôt que vous n’avez jamais ouvert.

Pour la plupart des logiciels hébergés, le contrat de séquestre est le mauvais instrument, acheté par habitude, et l’argent est mieux employé à des exports réguliers dont vous avez prouvé que vous savez les lire.

Ce que cela coûte et à qui cela convient

Le séquestre est une dépense annuelle, allant en général de quelques centaines à quelques milliers de livres sterling par an selon la taille du dépôt, le nombre de bénéficiaires et le niveau de vérification. La vérification est facturée à part, et c’est là que se situe la dépense qui compte.

Cela convient vraiment : aux systèmes dont une interruption nuirait réellement à l’activité, aux prestataires assez petits pour que la défaillance soit une possibilité concrète, aux logiciels installés chez vous ou auto-hébergeables que vous pourriez plausiblement exploiter, et aux situations où un régulateur ou un contrat client l’exige.

Cela convient moins : aux logiciels hébergés dont vous n’exploiteriez de toute façon pas le code, aux systèmes banalisés faciles à remplacer, et aux petits prestataires pour qui le coût annuel représente une part visible de la valeur du contrat.

L’alternative à examiner en premier est simplement de posséder le code. Si le travail est sur mesure et que vous l’avez commandé, négociez la cession de la propriété intellectuelle et une copie du dépôt à chaque livraison. Cela supprime le besoin d’un agent, et les points de notre guide de due diligence technique sont exactement ceux qui rendent une telle reprise exploitable.

Comment le rendre utile si vous l’achetez quand même

Négociez les déclencheurs de libération au lieu d’accepter la liste standard, et incluez l’abandon du produit par le prestataire autant que l’insolvabilité.

Précisez le contenu du dépôt dans le contrat lui-même, pas dans une annexe que personne ne lit. Instructions de compilation, définition de l’infrastructure, manifeste des dépendances, inventaire des services externes et un contact nommé.

Exigez des mises à jour à un rythme défini ou à chaque version majeure, et exigez la preuve qu’elles ont bien eu lieu.

Payez la vérification au niveau où l’agent compile et exécute le dépôt, puis lisez le rapport. Une vérification qui a trouvé des problèmes fait exactement son travail.

Et testez votre propre préparation. Si le matériel arrivait demain, qui le recevrait de votre côté, et que ferait cette personne en premier ? Un contrat de séquestre sans responsable interne est une facture, pas un plan. Le raisonnement de notre guide de reprise après sinistre s’applique directement.

Mecanik a déposé du code en séquestre et a aussi aidé des clients à juger s’ils en avaient besoin, dans le cadre de notre activité de développement logiciel. Le plus souvent, la réponse honnête est que le même budget achète davantage de protection s’il va vers des sauvegardes vérifiées et une propriété intellectuelle clairement attribuée.

Questions fréquentes

Qu’est-ce que le séquestre de code source ? Un contrat tripartite entre un client, un éditeur de logiciel et un agent de séquestre. L’éditeur dépose le code source et le matériel d’accompagnement chez l’agent, qui le remet au client si des conditions définies sont réunies, le plus souvent l’insolvabilité de l’éditeur ou l’arrêt de la maintenance du produit.

Pourquoi les contrats de séquestre échouent-ils à la libération ? Parce que le dépôt n’a jamais été vérifié. Les constats fréquents sont un matériel qui ne compile pas sans un outil non documenté, des dépendances à un dépôt de paquets privé qui disparaît avec l’éditeur, des identifiants manquants pour des services externes, ou une version plus ancienne que celle en production. Seule une vérification qui compile et exécute le dépôt répond à la vraie question.

Le séquestre de code source fonctionne-t-il pour le SaaS ? Mal. Recevoir le code source d’une plateforme hébergée vous laisse toujours un besoin d’infrastructure, d’outils de déploiement, de savoir-faire d’exploitation et de vos données, et la mise en service prend des semaines. Un droit d’extraction des données, une période de continuité contractuelle après la résiliation et des exports testés régulièrement protègent un service hébergé bien mieux qu’un dépôt de code.

Combien coûte un séquestre de code source ? En général de quelques centaines à quelques milliers de livres sterling par an selon la taille du dépôt, le nombre de bénéficiaires et le niveau de vérification, la vérification étant facturée à part. C’est dans la vérification que se situe la dépense qui compte, et un contrat sans elle transfère le sentiment du risque plutôt que le risque.

Existe-t-il une alternative au séquestre ? Pour un travail sur mesure que vous avez commandé, négocier la cession de la propriété intellectuelle et une copie du dépôt à chaque livraison supprime entièrement le besoin d’un agent. Pour un logiciel hébergé, un export documenté dont vous avez réellement testé la lecture vaut d’ordinaire plus que n’importe quel dépôt que vous n’avez pas testé.