Source code escrow : pourquoi la plupart des fondateurs non techniques se font vendre la mauvaise protection

Le source code escrow a été conçu pour des acheteurs corporatifs averses au risque qui se protègent contre la faillite de gros éditeurs. C’est le mauvais instrument pour une startup early-stage qui fait développer un logiciel sur mesure par un petit studio. La vraie protection ne coûte rien et tient à trois choses mises en place dès le premier jour.

La fondatrice a poussé le PDF annoté de l’autre côté de la table. Son avocat avait surligné en jaune une clause nouvelle et noté “ajoutée selon la pratique courante” dans la marge. La clause était un contrat de source code escrow de trois pages, joint comme Exhibit C au contrat qu’elle s’apprêtait à signer avec un studio de trois personnes qui développait son produit seed-stage. “Il dit qu’il nous le faut au cas où ils feraient faillite”, a-t-elle expliqué. “Vraiment ?”

L’avocat la protégeait contre un risque qui n’existe pas dans sa situation. Le studio qu’elle s’apprêtait à embaucher n’était pas en faillite au sens où la clause d’escrow l’imaginait. Ce contre quoi elle voulait vraiment se protéger, c’était autre chose. Elle ne savait juste pas comment le nommer, et son avocat a sorti le seul instrument pour lequel il avait un template.

Cela arrive en permanence. Une fondatrice non technique boucle une seed round. Elle entame la négociation du contrat de son premier vrai build logiciel. Son avocat ajoute le source code escrow comme “protection standard”. Le studio accepte parce qu’il veut signer. Six mois plus tard le contrat est signé, les dépôts se font selon le calendrier prévu, et rien de tout cela ne fait ce que la fondatrice imaginait.

Cet article est pour cette fondatrice.

Qu’est-ce que le source code escrow

Le source code escrow est un accord juridique tripartite par lequel un éditeur logiciel dépose une copie du code source, des scripts de build et de la documentation associée chez un agent tiers neutre. L’agent conserve le dépôt. Si certaines conditions de release prédéfinies surviennent, en général l’éditeur tombe en faillite, cesse de supporter le produit, ou manque à une obligation matérielle du contrat de licence, l’agent remet le dépôt au client. Tant que cet événement déclencheur n’a pas lieu, le client n’a pas accès au code.

C’est le modèle standard. Trois parties : le déposant (l’éditeur), le bénéficiaire (le client) et l’agent (un cabinet spécialisé comme Escode d’Iron Mountain ou NCC Group, plus des acteurs plus petits). Un dépôt, rafraîchi périodiquement. Une liste fermée et étroite de conditions de release. Un jeu d’attente.

C’est un instrument juridique, pas technique. Les mécaniques qui comptent vivent dans des clauses contractuelles, pas dans le codebase.

Pourquoi le source code escrow existe

L’instrument a été conçu pour un problème d’entreprise. Dans les années 80 et 90, une entreprise du Fortune 500 prenait sous licence un progiciel critique pour son activité, souvent tournant sur mainframe, auprès d’un éditeur unique dont la survie était incertaine. L’acheteur n’avait aucun moyen réaliste de changer d’éditeur en cours de route. Si l’éditeur disparaissait, l’acheteur restait avec un binaire qu’il ne pouvait plus maintenir, modifier ou faire tourner sur du nouveau matériel. Le source code escrow a été la réponse juridique : le licencié payait une petite prime pour savoir que, si l’éditeur disparaissait, le code source remonterait à la surface.

Ce problème existe encore, sous une forme plus étroite, pour les grandes entreprises qui prennent sous licence des logiciels packagés auprès d’éditeurs de taille intermédiaire. Il n’existe pas pour une startup early-stage qui fait développer un logiciel sur mesure par un studio de cinq personnes. Les deux situations se ressemblent en surface (quelqu’un d’autre développe un logiciel pour moi, et s’il disparaît) mais l’instrument juridique ne sert que la première.

Quand une SaaS Series B prend sous licence un logiciel de paie auprès d’un éditeur régional, l’escrow est raisonnable. Quand une fondatrice seed-stage embauche un studio pour bâtir son produit en partant de zéro, l’escrow est le mauvais outil. L’éditeur ne lui met pas un logiciel sous licence. L’éditeur est payé pour développer un logiciel qui lui appartient à elle dès l’instant où le code est écrit, ou en tout cas devrait lui appartenir.

L’instrument s’est retrouvé dans le mauvais contexte parce que les templates de contrat voyagent plus vite que le raisonnement qui les sous-tend.

Les trois problèmes que les fondateurs non techniques croient que l’escrow résout

Quand un fondateur me demande s’il faut ajouter de l’escrow à un contrat de logiciel sur mesure, l’angoisse de fond est presque toujours l’une de ces trois :

“Et si le studio met la clé sous la porte ?” La peur est qu’un studio de cinq personnes ferme, qu’un ingénieur clé parte, que les founders pivotent vers le conseil, et que le codebase disparaisse avec eux. Ce risque est réel. C’est la version la plus courante de la question.

“Et s’ils refusent de me remettre le code ?” La peur est que la relation tourne mal, que le fondateur arrête de payer, que le studio invoque une clause et reparte avec le travail. C’est réel aussi, surtout avec des prestataires qui facturent au jalon plutôt qu’à l’ownership.

“Et si mon seul dev démissionne ?” C’est la question du bus factor habillée autrement. Le contrat est signé avec un studio mais le build dépend fonctionnellement d’un ingénieur précis à l’intérieur de ce studio.

Maintenant regardons ce que fait l’escrow. Il libère un dépôt si un éditeur entre en faillite ou cesse formellement de supporter le produit. Le premier scénario, le studio ferme, peut parfois qualifier pour un release si vous pouvez prouver la faillite dans un sens juridique défini. Le deuxième et le troisième, non. Une dispute relationnelle n’est pas un release event. Un dev solo qui part n’est pas un release event. Quand la fondatrice découvre son vrai problème, le compte d’escrow est posé là, plein d’un dépôt qu’elle ne peut pas récupérer.

Il y a aussi un problème plus silencieux. Les release conditions dans un contrat type d’escrow sont rédigées étroitement pour protéger l’éditeur contre des releases abusifs. On attend de l’agent qu’il vérifie que le déclencheur a effectivement eu lieu, ce qui peut prendre des semaines. Dans le timeline d’une startup, ce délai à lui seul peut être fatal.

Ce que le source code escrow fait réellement, et ce qu’il ne fait pas

Le dépôt, c’est ce que l’éditeur décide de déposer, selon le calendrier que prévoit le contrat. L’agent d’escrow, par défaut, ne vérifie pas que le dépôt est un build fonctionnel. Certains agents proposent un service de vérification moyennant un supplément. La plupart des contrats sautent cette étape.

Du coup, ce qu’il y a dans le coffre, six mois après, c’est généralement un dossier zippé. Il peut contenir le code de production le plus récent, ou une copie d’il y a six semaines, ou un build qui ne compile pas. Le contrat standard d’escrow protège contre l’éditeur qui refuse de déposer quoi que ce soit, mais pas contre l’éditeur qui dépose quelque chose d’inutilisable.

Le release livre du code, pas du contexte. Pas de schémas, pas de notes d’architecture, pas de documentation d’onboarding, pas de variables d’environnement, pas de secrets de production, pas de scripts de déploiement. Le coffre contient du code source. Le code source n’est pas un système. Une équipe de trois ingénieurs à qui on remet un repo propre sans documentation et sans continuité de mémoire regarde un codebase qu’elle ne connaît pas, pas un produit en production qu’elle peut continuer à exploiter.

C’est l’écart entre ce que les fondateurs pensent que l’escrow fait et ce qu’il fait vraiment. L’escrow vous protège de l’éditeur qui refuse de vous donner un snapshot. Il ne vous protège pas d’hériter d’un snapshot impossible à déployer, à modifier ou à comprendre sans l’équipe qui l’a construit.

Ce dont vous avez vraiment besoin à la place

Pour une startup early-stage qui fait développer un logiciel sur mesure, quatre éléments en place dès le premier jour rendent l’escrow inutile.

1. Le dépôt vivant est à vous, pas un snapshot dans un coffre. Le repo vit dans une organisation GitHub ou GitLab détenue par la société de la fondatrice, pas par le studio. Les ingénieurs du studio sont ajoutés comme collaborators avec droit de commit. Chaque push est dans votre compte, en temps réel, avec l’historique complet. Si le studio s’en va demain, vous avez ce que le coffre d’escrow finirait par livrer, sauf que vous l’avez maintenant, avec historique complet, entièrement buildable, sans agent à appeler et sans release event à prouver.

C’est la protection isolée à plus forte palanche qu’une fondatrice non technique peut mettre en place et elle coûte zéro. La plupart des studios l’acceptent sans négocier si vous la demandez avant le démarrage du build. Ceux qui refusent vous disent quelque chose d’utile.

2. Cession d’IP propre, vestée au paiement. Le contrat cède la propriété intellectuelle des livrables à la société de la fondatrice au moment du paiement, pas au moment de la clôture du projet. Chaque facture payée transfère l’ownership du travail fait jusqu’à ce point. Pas de clause “nous céderons à la fin du projet”, parce que la fin du projet est une cible mobile et la palanche du studio pendant un différend, c’est précisément l’écart entre le travail livré et l’IP cédée.

Une bonne structure de contrat pour un build sur mesure règle ça en un paragraphe. Une mauvaise repousse la cession et crée exactement la palanche qui pousse les fondateurs à chercher l’escrow en filet de sécurité.

3. Une documentation d’onboarding qui survit à l’équipe. Le livrable n’est pas que du code. C’est un README qui mène un ingénieur inconnu à faire tourner le système en local en moins de trente minutes, un schéma d’architecture sur une page, une liste de chaque service tiers dont le système dépend avec le contact et le billing seat de chacun, et un inventaire des variables d’environnement. Rien d’exotique. Tout studio qui construit pour durer le produit. Les studios qui résistent à le produire ne sont pas intéressés à être remplaçables.

Si votre studio est incapable de livrer cette documentation, le code source dans le coffre est du théâtre. La documentation est ce qui rend le code transférable.

4. Des sauvegardes réelles sous votre contrôle. La base de production a des sauvegardes automatisées qui atterrissent dans un cloud storage que vous possédez et payez, pas dans une sauvegarde configurée à l’intérieur du compte du studio. Pareil pour les logs, pour le stockage de fichiers, pour tout ce qui contient des données clients. Si le compte cloud du studio est suspendu pour défaut de paiement, votre activité ne s’arrête pas.

Ces quatre éléments réunis, repo vivant, IP propre, vraie documentation d’onboarding, vos propres sauvegardes, vous donnent tout ce que l’escrow promet et plus. Ils ne coûtent rien au-delà du temps de les demander. Et contrairement à l’escrow, ils vous protègent le jour où le studio cesse de répondre, pas trois mois plus tard après qu’un agent a vérifié un release event.

Quand le source code escrow est vraiment le bon choix

Il y a des cas étroits où l’escrow a du sens, même pour une startup.

Vous prenez sous licence un produit packagé, pas un build sur mesure. Un éditeur SaaS vous vend son logiciel, vous le faites tourner sur votre infrastructure, vous en dépendez pour une opération critique. L’éditeur ne va pas vous donner le repo vivant parce que le repo vivant, c’est son entreprise. Là, l’escrow fait exactement ce pour quoi il a été conçu. Si l’éditeur disparaît, vous récupérez le code et vous continuez à tourner.

Vous êtes dans une industrie réglementée où l’audit l’exige. Certains contrats dans les services financiers, la santé régulée et la défense imposent l’escrow comme condition. Si le régulateur l’exige, la question est tranchée.

Vous êtes l’acheteur important dans une relation de type entreprise. Vous avez signé un contrat logiciel à six chiffres avec un petit éditeur spécialisé, le logiciel est désormais cœur de votre opérationnel, et l’éditeur ne va pas vous donner le repo vivant parce qu’il licencie le même produit à d’autres clients. L’escrow est la protection résiduelle. C’est le cas d’usage original, et la seule situation dans laquelle la fondatrice early-stage que je décris au début de cet article devrait raisonnablement finir avec une clause d’escrow.

Si rien de tout cela ne s’applique, et que vous payez un studio pour bâtir un logiciel qui devrait vous appartenir dès qu’ils l’expédient, l’escrow règle le mauvais problème.

Combien coûte le source code escrow

Le coût dépend de l’agent et du périmètre du dépôt. En 2026, les tarifs en cours pour les services standards d’escrow aux États-Unis ressemblent approximativement à ceci. Un contrat à formulaire standard avec un seul bénéficiaire et des dépôts trimestriels coûte entre 1 000 et 3 000 dollars par an. Un contrat rédigé sur mesure avec plusieurs bénéficiaires, des dépôts plus fréquents ou des release conditions particulières peut grimper à 5 000 à 15 000 dollars par an. Les services de vérification, où l’agent confirme que le dépôt compile bien en un build fonctionnel, sont typiquement un supplément de 3 000 à 8 000 dollars par événement de vérification.

Pour une entreprise Series B+ qui prend sous licence un SaaS critique, ces montants sont des arrondis. Pour une fondatrice seed-stage qui dépense 150 000 dollars sur un build, non. Le plus gros coût n’est pas l’argent. C’est le temps passé à négocier la clause, les allers-retours entre les deux équipes d’avocats sur les release conditions, et les mois de revue contractuelle absorbés par le deal.

Si vous payez pour de l’escrow sur un build sur mesure, faites le calcul face à l’inventaire en quatre étapes ci-dessus. L’inventaire est gratuit. L’inventaire vous protège mieux. L’inventaire n’a pas besoin d’un avocat pour être négocié.

FAQ

Qu’est-ce que la source code review et l’escrow ? Ce sont deux choses distinctes que les vendors d’escrow vendent souvent ensemble. Le source code escrow est l’arrangement de dépôt-et-release décrit plus haut. La source code review est un service par lequel un tiers audite périodiquement le code déposé pour vérifier sa complétude, sa capacité à être buildé et sa qualité. La review est ce qui confirme que le dépôt est réellement utilisable. Sans review, le coffre peut contenir un snapshot non fonctionnel. La plupart des contrats standards d’escrow n’incluent pas la review par défaut. Si vous allez utiliser de l’escrow, le service de review est en général la partie qui compte.

Que devrait toujours contenir un contrat de source code escrow ? Une définition claire du dépôt (code source, scripts de build, documentation, dépendances tierces, configuration d’environnement), un calendrier de dépôts avec vérification, une liste fermée de release conditions, un processus de release défini avec un délai maximal de réponse de l’agent, la survivance de la licence après release et une clause d’indemnisation pour l’agent. Si l’un de ces éléments manque, le contrat est décoratif.

Qu’est-ce qu’un escrow code ? C’est un concept totalement différent. Un escrow code, parfois appelé escrow recovery code, est une clé de secours utilisée dans les systèmes d’identité pour déverrouiller un compte quand les autres méthodes de récupération échouent. Ça n’a rien à voir avec le source code escrow. Les termes voyagent ensemble dans les recherches parce qu’ils contiennent tous deux le mot “escrow”, mais les systèmes ne sont pas liés.

Puis-je juste garder ma propre copie du code ? Oui, et c’est la bonne réponse pour un build sur mesure. Si le repo vivant vit dans l’organisation GitHub de votre société et que les ingénieurs du studio y sont ajoutés comme collaborators, vous avez quelque chose de mieux que l’escrow sans aucun agent et sans release condition. Les studios qui résistent à cet arrangement vous racontent quelque chose sur leur façon de penser l’ownership.

Ajouter de l’escrow me protège-t-il si mon developer freelance démissionne ? Non. L’escrow se déclenche par la cessation d’activité de l’entité fournisseur (la société du freelance), pas par le départ de l’individu. Un freelance peut quitter votre projet demain, vous remettre un tarball, et ne jamais déclencher aucune release condition. La protection contre un seul developer qui part, c’est la documentation, l’onboarding prêt et une relation de successeur alignée avant que vous en ayez besoin, pas un coffre que vous ne pouvez pas ouvrir.

La fondatrice avec laquelle j’ai commencé cet article n’a pas signé la clause d’escrow. Elle a demandé au studio l’inventaire en quatre points et l’a eu en deux semaines. Dix-huit mois plus tard le studio est toujours son partenaire, le repo est dans l’organisation GitHub de sa société avec l’historique complet, les sauvegardes atterrissent dans son compte cloud chaque nuit, et la documentation d’onboarding a déjà servi deux fois pour intégrer de nouveaux ingénieurs au projet sans qu’aucun d’eux ait eu à parler à l’équipe d’origine. Son avocat continue d’inclure la clause d’escrow dans le template. Elle continue de la rayer. Ils ont arrêté de discuter.

Le source code escrow existe pour un vrai problème. C’est le mauvais problème pour la plupart des fondateurs non techniques. Le bon problème a une réponse plus simple.