Un escrow agreement (entiercement) protège le code source d'un SaaS en confiant un dépôt à un tiers de confiance neutre (souvent l'Agence pour la Protection des Programmes), avec une clause de remise au client en cas de défaillance définie de l'éditeur (faillite, arrêt de l'exploitation, manquement grave). Sans cet outil, un client critique reste exposé à la disparition de son fournisseur. Mécanisme contractuel standard, à coût modeste (500 à 3 000 euros par an).
Le besoin auquel répond l'escrow
Un client utilisant un SaaS critique pour son activité dépend de la pérennité de son fournisseur. Si l'éditeur fait faillite, est racheté avec arrêt du service, ou cesse simplement d'exploiter le produit, le client peut perdre brutalement l'accès aux fonctionnalités essentielles à son métier.
L'escrow apporte une garantie de continuité : en cas d'événement déclencheur, le client reçoit le code source pour :
- Maintenir l'application en conditions opérationnelles.
- Faire évoluer le produit jusqu'à migration vers une autre solution.
- Confier le maintien à un tiers prestataire.
Les acteurs de l'escrow
Le dispositif repose sur un montage tripartite :
- Le déposant : l'éditeur du SaaS, qui dépose le code source et la documentation.
- Le bénéficiaire : le client SaaS, qui pourra récupérer le dépôt en cas d'événement déclencheur.
- Le tiers séquestre : organisme neutre qui conserve le dépôt et arbitre la remise. En France, l'Agence pour la Protection des Programmes (APP) est l'acteur historique. Existent aussi des notaires, certains commissaires de justice, ou des tiers internationaux (Iron Mountain, NCC Group).
Le contenu du dépôt
Pour être utile, le dépôt doit comprendre tous les éléments nécessaires à la reprise opérationnelle :
- Code source complet : dans un format compilable (incluant scripts de build).
- Documentation technique : architecture, schémas de base de données, procédures de déploiement.
- Documentation fonctionnelle : description des fonctionnalités, cas d'usage, paramétrages.
- Outils et scripts d'installation : capacité à reconstituer un environnement.
- Identifiants critiques chiffrés : clés API tierces, certificats (avec procédure de récupération en cas de remise).
- Configuration de l'infrastructure : fichiers Terraform, scripts Ansible, manifests Kubernetes le cas échéant.
- Dépendances : versions des bibliothèques utilisées (lockfiles), licences.
Un dépôt incomplet ou non testé n'a aucune valeur opérationnelle. Le contrat doit prévoir des dépôts réguliers (souvent trimestriels) et idéalement un test de validité périodique.
Les événements déclencheurs
L'événement déclencheur conditionne la remise du dépôt au client. Liste type :
- Liquidation judiciaire de l'éditeur : événement le plus consensuel.
- Cessation d'exploitation : arrêt volontaire du service ou abandon du produit.
- Manquement grave et persistant aux obligations contractuelles : par exemple, indisponibilité prolongée non corrigée malgré mises en demeure.
- Refus de fournir le support technique : défaillance manifeste sur les obligations de maintenance corrective.
- Reprise par un tiers avec arrêt du produit : événement à intégrer même si difficile à caractériser.
Chaque événement doit être défini avec précision pour limiter les contestations en exécution.
La procédure de remise
- Notification de l'événement par le bénéficiaire au tiers séquestre, avec justifications (jugement de liquidation, courriers de mise en demeure, captures de panne).
- Information du déposant par le tiers séquestre, ouvrant un délai de contestation (souvent 15 à 30 jours).
- Examen contradictoire : l'éditeur peut contester la qualification de l'événement.
- Décision du tiers séquestre selon la procédure prévue : validation immédiate (cas évident comme la liquidation) ou recours à un tiers expert pour les cas litigieux.
- Remise du dépôt au bénéficiaire, contre signature d'engagement de confidentialité.
L'étendue des droits du bénéficiaire
Le bénéficiaire ne devient pas propriétaire du code. Il reçoit une licence d'usage limitée à :
- L'usage interne pour les besoins propres du bénéficiaire.
- La maintenance et l'évolution du code pour son usage interne.
- La sous-traitance auprès d'un tiers pour le maintien, sous engagement de confidentialité.
Le bénéficiaire ne peut pas :
- Distribuer ou commercialiser le produit.
- Concurrencer l'éditeur sur le marché des SaaS similaires.
- Divulguer le code source à des tiers en dehors du cadre prévu.
Le respect de ces limites est garanti par une clause pénale ou des dommages-intérêts forfaitaires en cas d'usage abusif.
L'articulation avec le secret des affaires
Le code source remis au bénéficiaire reste protégé par le régime du secret des affaires des articles L. 151-1 et suivants du Code de commerce. Le bénéficiaire est tenu de mettre en œuvre des mesures de protection raisonnables : accès restreint, marquage, NDA avec ses propres prestataires.
Les coûts et la facturation
- Frais de mise en place : 500 à 1 500 euros HT (rédaction du contrat, premier dépôt).
- Abonnement annuel au tiers séquestre : 500 à 2 000 euros HT par an, selon le volume et la fréquence des dépôts.
- Frais de remise : souvent quelques milliers d'euros, à la charge du bénéficiaire.
- Test périodique du dépôt : 1 000 à 3 000 euros HT par session, fortement recommandé.
La répartition des coûts est négociée : souvent l'éditeur supporte les frais de mise en place et l'abonnement annuel, le bénéficiaire les frais de remise et de test. Variantes selon les contrats.
Quand mettre en place un escrow
- SaaS critique pour la continuité d'activité : ERP, CRM cœur de métier, outil de production industrielle.
- Éditeur jeune ou de petite taille : risque de défaillance non négligeable.
- Éditeur unique sur sa technologie : pas d'alternative simple en cas de disparition.
- Demande explicite d'un grand compte : politique de gestion des risques fournisseurs.
- Contrats de longue durée : 3 ans et plus, où la stabilité de l'éditeur ne peut être garantie.
Les alternatives à considérer
- Open source du produit : l'éditeur publie son code en open source (souvent à licence duale, gratuite pour les usages internes, payante pour les usages commerciaux). Solution radicale mais qui supprime le besoin d'escrow.
- Multi-cloud avec exportabilité : garantie de pouvoir migrer les données vers une autre solution équivalente. Plus pertinent pour les SaaS standardisés.
- Réversibilité contractuelle : l'éditeur s'engage à fournir, en cas de fin de contrat, l'export complet des données dans un format documenté.
- Contrat de maintenance secondaire : un tiers prestataire est pré-positionné pour reprendre la maintenance en cas de défaillance.
Pièges à éviter
- Dépôt sans test : le code peut s'avérer non compilable, incomplet ou obsolète au moment de la remise.
- Événements déclencheurs trop restrictifs : si seule la liquidation déclenche, le bénéficiaire reste exposé en cas d'arrêt volontaire du produit ou de manquement grave.
- Événements déclencheurs trop larges : l'éditeur peut redouter une remise abusive en cas de litige mineur.
- Absence de procédure d'arbitrage : en cas de désaccord sur la qualification de l'événement, le tiers séquestre est paralysé.
- Périmètre licence trop large : le bénéficiaire pourrait commercialiser le produit récupéré en concurrence directe.
- Périmètre licence trop étroit : le bénéficiaire ne peut pas faire évoluer le code, qui devient obsolète rapidement.
- Absence de mise à jour régulière : le dépôt date de plusieurs versions, inutilisable lors d'une remise.
L'escrow agreement est un outil simple à mettre en œuvre mais à calibrer précisément. Il rassure les clients critiques sans coûter cher à l'éditeur, à condition que le contrat soit rédigé avec rigueur et que les dépôts soient maintenus à jour. Chaque situation est particulière et appelle une analyse au cas par cas.
Pour aller plus loin
Notre dossier complet : Avocat SaaS.
